Show Posts
Pages: [1] 2 3 ... 181
1  Using Arduino / Displays / Re: ShiftLCD and wire length on: Today at 02:48:22 am
I'd recommend filing a bug report.
It isn't hard to do and the arduino team really does read them and fix things,
particularly if the report is concise and either includes or proposes the fix/solution.

--- bill
2  Using Arduino / Displays / Re: openGLCD and extended ASCII danish letters ... on: Today at 02:43:50 am
I can't really try it since I don't have your font.
But I'm  guessing the problem is here:

Code:
unsigned char tegn = aString;

This is  assigning the lower 8 bits of the aString[] array base address
to the variable tegn. Then, just below it you are trying to
print those 8 bits as a character.

What you probably meant to do was index into the array and pull out the character:
Code:
unsigned char tegn = aString[i];

But rather than loop and pull out the character 1 by 1, why not use the print() function?
Was it not working?
i.e.
Code:
GLCD.print(aString);
or directly as a literal:
Code:
GLCD.print("Æøå");
or you can print the individual characters:
Code:
GLCD.print('Æ');

--- bill

3  Using Arduino / Programming Questions / Re: GLCD Font Format help. on: September 01, 2014, 06:32:17 pm
Ok. I understand.
Have you looked closely at your font tool for data format options?
Many of them have the ability to change how the data is saved
and have the ability to save the data horizontally in the bytes.

But even if you get the font data in the format you want,
the rendering is still going to be a bit of pain
since you have to grab each row of pixel data for each character that is being printed
on the text line as you fill in the pixels for each of the graphic lines.

Not sure which Arduino you are using but
the code could be easier/simpler on something like a teensy 3 where you have tons of memory
and no goofy proprietary AVR PROGMEM to deal with.
With that board, you could have a graphic pixel buffer where you could render multiple graphic lines at a time
that way you  could render each full character across the full text line first.
Then send the pixel buffer out graphic line at a time to the printer.
Once you have a buffer, and don't have to deal with PROGMEM, things will get simpler
and whether the font data is horizontal or vertical doesn't  matter as much and things
like font scaling (wide, tall, double size, etc..)  becomes fairly easy to do.

--- bill
4  Using Arduino / Programming Questions / Re: GLCD Font Format help. on: September 01, 2014, 04:40:42 pm
Sounds like you may have printer similar to this:
http://www.adafruit.com/products/597
You might be able to use their s/w or at least could use use a base
as I'm guessing if it isn't the same, it wouldn't be that difficult to tweak it to work
with yours.
https://learn.adafruit.com/mini-thermal-receipt-printer

Looks like the s/w  has some decent capabilities.

--- bill
5  Using Arduino / Programming Questions / Re: GLCD Font Format help. on: September 01, 2014, 02:14:02 pm
btw, doesn't that tool let you alter how the font data is stored?
It's been several years since I've used it but I thought it had some options as to how to store the data.
like 16 bit vs 8 bit data elements, horizontal vs vertical, etc...
6  Using Arduino / Programming Questions / Re: GLCD Font Format help. on: September 01, 2014, 02:10:53 pm
Convert the hex values to binary. 0x06 = 0b001100. Now look at the picture. Compare the black and white squares in the top row to the 0 and 1 pattern. See a relationship?
Doesn't look like any sort of relationship to me other than both happen to have 2 consecutive "1" bits.
Compared on top of each other:
Code:
000XX000 - top row
00001100 - 0x06

To me, the 6 looks like some kind of font size indicator then the pixel data follows.
It looks to be stored vertically, where bit 0 is at the top
and the pixels are mapped from bottom to top and then left to right.
For non multiple of 8 sized fonts like this one, it looks like the pixel data
is adjusted down so the unused bits in the pixel data will be off the bottom
or will be the upper data bits of that data byte.

So skip over the 6. you will need to figure out what the byte is later by looking at different font sizes.

Then if you look at the data, it looks like each column moving from left to right is two bytes of data.
In the data pair, the first byte is the lower pixels, and next byte is upper pixels.
In the first byte, bits 6 and 7 are not used (the font size of 14 is not a multiple of 8 ),
then the bits lay down going up.
In the second byte, all 8 bits are used and go up from where the first byte stops
and is the upper 8 vertical pixels.
i.e. the bottom pixel will be bit 5 of first byte the pixel byte pair and the upper pixel will be bit 0
of the 2nd byte of the pixel byte pair.


GLCDs like the ks0108 vertically map their pixels like this. However, for speed you really
want to write the pixel data horizontally within the 8 bit pixel page.
This font format would require that you scramble your read accesses to get the pixel data in that order.

It can be a real challenge to do this along with taking into consideration arbitrary y pixel coordinate alignment.
My openGLCD library takes all this into consideration to minimize glcd data writes
when doing its rendering which is why the font rendering code  is so complex.

--- bill



7  Using Arduino / Displays / Re: Problem with 20x4 LCD & i2c backpack from Uctronics on: September 01, 2014, 01:22:18 pm
Any thoughts on what the difference is between the 16 x 2 working and the 20 x 4 not? 
Are you using the exact same single i2c backpack on both displays?
i.e. moving it between the two LCDS?
If not, are the two backpacks exactly the same?
i.e. the output port wiring on the PCF8574 to the LCD pins the same?
If not, then the constructor for the two backpacks will need to be different.

If you are sharing the same single backpack, then it could be soldering problem.

If there are two backpacks and they are the same, then it could be as Don
suggested a Constrast control issue, or it also could be a soldering problem.

At a minimum, if you download a non lcd sketch (like say the blink sketch),
then when you power up the arduino, the LCD should display some boxes
if the contrast circuit is working properly.

--- bill
8  Using Arduino / LEDs and Multiplexing / Re: Do I need a resistor on a 40 mA pin when all I need is 40 mA? on: August 26, 2014, 01:22:19 pm
If you want to power two LEDs you not only need a resistor but you need two resistors.
Not necessarily. You can use a single resistor. The issue will be that when both are on
each will not be as bright as when it is on individually.
Depending on the application, this may or may not be acceptable.
In some cases it is perfectly fine.
For example, suppose you have a RGB led and will only need to have
a single color on at a time. In that case, you could use a single resistor
on the common lead instead of using 3 resistors.


--- bill
9  Using Arduino / Displays / Re: ERM19264SBS-2-TC and openGLCD on: August 26, 2014, 01:08:38 pm
Tryed to setup openGLCD but without luck...
doesn't give much information.
That could be anything from, I couldn't get the library installed, to the board caught on fire.

Nearly all the cases of issues of a glcd not working are from two main causes:
- incorrect wiring
- incorrect configuration.

192x64 ks0108 glcds are a little more tricky  than 128x64,
in that the module can use either 2 chip selects or 3 chip selects.
And then, as is true with all ks0108 modules,  the chip selects can be active high, or active low.

You must look at the datasheet for your glcd to determine how many chip select pins there are
and how to interface to your glcd.

Sometimes there can be errors in the data sheets, but all of them will properly indicate
how many chip select pins there are and most of them will properly tell you
if the  chip selects are active high or active low.
Once you know that, you can select the proper ks0108 config file or create your own
if an existing one doesn't match your glcd.
Then you can wire up the glcd to match the pins in the configuration file.

Everything is based on the datasheet. You must have a proper datasheet for the
glcd to get the wiring and configuration correct.
This is not something to guess, since incorrect wiring can damage the glcd or arduino.

After a quick search, I was unable to find a datasheet for that part number.
I could find one for the ERM19264SBS-1
if it is the same as the -2 then this display appears to work the same as the HJ29264A module
and there is a config file for that module included in the library.

But before proceeding any further you should find the datasheet for your display
to make sure everything is wired up appropriately.
For additional information,
there is a section in the wiring section of the included openGLCD documentation for details on how
to wire up the connections from the pins specified in the datasheet.


--- bill
10  Using Arduino / Displays / Re: GLCD ks0108 coordinates problem on: August 25, 2014, 12:24:58 am
I'm assuming you mean the left and right sides are swapped?
This is a wiring issue.
It is documented in troubleshooting section of the included html documentation.
The chip select wires are backwards.

I would consider switching to openGLCD
https://bitbucket.org/bperrybap/openglcd/wiki/Home
as it is  actively maintained and has many bug fixes and improvements over GLCD v3.

--- bill
11  Using Arduino / Displays / Re: Best and cheapest solution to digitally control LCD contrast on: August 25, 2014, 12:16:55 am
My actual concern was the misunderstanding that there would be a need to control the contrast voltage using PWM as the contrast is a "set and forget" function.  Unless something happens such as variation of the supply voltage, in which case that is what should be controlled.
I don't find it to be "set and forget" as I do often see varying supply voltage.
This is particularly true when using batteries.
I also see that the contrast can vary quite a bit on these ks0108 displays
depending on the USB cable used because the back-lights draw so much current,
often 500+ ma, that you end up with voltage drop that can vary depending on the cable
and its length.

I have a custom shield that I built and I also see voltage variation depending
on which base Arduino board I I use as some boards use on board power powesupplies,
diodes, or voltage regulators which also create voltage drops.
So when moving the shield between Arduino base boards, the contrast will change.

I use a pot, and adjust it to make the adjustment to compensate.



--- bill
12  Using Arduino / Displays / Re: lcd.createChar before and after lcd.begin on: August 25, 2014, 12:05:01 am
Quote
I use custom characters all the time and have used them on every hd44780 library and interface
I've been able to get my hands on.

Bill: Is the rest of stuff I mentioned in reply #2 essentially correct?

Don
It depends on which library is being used, which we don't know.
The order of begin() vs createChar() can be significant depending on which
library is being used.
If it is the LiquidCrystal library that comes with the IDE then yes the comments
in your reply #2 are correct;
however, if it were an i2c version of the library then begin() must be called
before you can create custom characters since begin() is what initializes
the interface (i.e. Wire/i2c) as well as the LCD and begin() will not  not called by
the constructor.

That is why I'd recommend always calling begin() first, including
before creating custom characters since that sequence order will work on other libraries
and any interface.

If I had to guess, I'd say it is likely that this issue is the same issue that I've seen,
and that is that after sending a custom character using createChar() no characters
will show up on the LCD until a cursor repositioning is done.
I use home() to do this.
I've not taken the time to fully track down what the real issue is.

I'm assuming that  the LCD is stuck in CGRAM address mode until some sort
of command that sets the mode back to DDRAM address mode is done.
The createChar() function sets CGRAM address mode and then sends
the 8 bytes.
Code:
// Allows us to fill the first 8 CGRAM locations
// with custom characters
void LiquidCrystal::createChar(uint8_t location, uint8_t charmap[]) {
  location &= 0x7; // we only have 8 locations 0-7
  command(LCD_SETCGRAMADDR | (location << 3));
  for (int i=0; i<8; i++) {
    write(charmap[i]);
  }
}
I'm assuming that all futures writes to the LCD are now going to CGRAM and that is why
print() doesn't work .


I would suggest using begin() first, then create your custom char(s),
then do a home() and see if that fixes the problem.
This is the sequence that I use.

setCursor(0,0) instead of home() would also probably work, and would be alot faster.

--- bill
13  Using Arduino / Displays / Re: Best and cheapest solution to digitally control LCD contrast on: August 24, 2014, 03:16:06 pm
Quote
This discussion seems to be mostly missing the original topic of s/w control of the contrast using PWM.

That was only one of the two topics posed in the original post.  If you look at my first reply you can easily tell which one I was referring to.  On the other hand ....

Don


Yep, the potentiometer comments seemed out of place to me, since this is about digital control.

From my reading of the topic and original post
I only see only one topic, and that was as the title asks,
essentially how to cheaply do s/w control of contrast.
The first post does talk about using an approach of smoothing out the PWM single with a filter, and
then asks how to use that filtered variable positive voltage to create the larger
ranged voltage that also has to be negative.
My thought is that this is not a hard requirement; the real desire is  to be able to do
as the title suggests: cheaply control the contrast in s/w
So my understanding is that it isn't about multiple topics and that the final solution
doesn't necessarily have to be anything like what was mentioned in the original post.

My comment was to consider an alternate approach.
Since ks0108 already has the negative voltage, try to use it rather than re-create it.
So I'd use Vee as part of a filter or rc circuit to create the variable voltage in the needed range
rather than create a variable positive voltage
that then has to be converted again to the needed range.


--- bill
14  Using Arduino / Displays / Re: Best and cheapest solution to digitally control LCD contrast on: August 24, 2014, 12:51:56 pm
This discussion seems to be mostly missing the original topic of s/w control of the contrast using PWM.
While I haven't done it , it would seem doable using an FET transistor like a 2n7000 along
with a low pass filter / RC circuit that connects its low side (FET source)  to Vee instead of ground.

--- bill
15  Using Arduino / Displays / Re: lcd.createChar before and after lcd.begin on: August 24, 2014, 12:14:41 pm
Quote
I'm surprised that .createChar() works before .begin() sets the interface to 4-bit mode.

That's because it's the constructor LiquidCrystal lcd(. . .) that sets the interface to 4-bit mode, but you knew that already!

Don
Actually we don't know enough to say either way since we don't know what library or interface abdallah is using.

If you look at the LiquidCrystal library that ships with the IDE it is begin() that sets up the interface
and initializes the LCD. However, (and I just noticed this), the constructor routines call the init() routine
and at the very bottom of init() there is a a call to  begin(16,1);
(never noticed that extra begin() call)
So while the constructor, ends up initializing the LCD, it is the begin() function that is actually doing it.

That said, nearly all various LCD libraries I've seen do the LCD initialization in begin()
(a few still use the init() function)  and some of them do not end up calling begin() from their constructors.

The LCD and interface will not be initialized by the constructor for i2c based interfaces since the Arduino code
does not properly set up all the hardware to allow i2c to work prior to calling the LCD constructors.
Because of this, a i2c LCD library can't call the Wire library code until later which is why it is deferred
until begin() and begin() is not called from the constructor.

The safest best thing to do is to never try to to talk to the LCD (which includes trying to set custom characters)
until after you have initialized the LCD using the appropriate begin() or init() function for the library.

I use custom characters all the time and have used them on every hd44780 library and interface
I've been able to get my hands on.
I have seen one issue that I've not bothered to track down and that is in some cases the LCD will not work properly
after sending custom characters until a home or clearscreen command is issued to the display.

The sequence that I've seen and use  that always seems to work  is
- initialize the LCD with begin()/init() as needed
- load your custom characters
- clear the screen

--- bill


Pages: [1] 2 3 ... 181