HD44780 compatible,only 8 digit displayed?why?

44780 chip thinks all lcds are 2 lines of 64 chars. Address of 2nd line starts at ram addr 0x40

People figured out a long time ago that they could save a 2nd column driver IC (paired with the HD44780) if they built a display that was *electrically* 2x8 even though it was *mechanically* still 1x16.

Assuming you've set up the LCD to automatically increment the cursor's position, write yourself a loop that just writes "0123456789012345..." to the display, and have it output, say, 256 characters. You'll probably find that -- around memory location 40, if I remember correctly -- you'll get a character at the 9th column on your display (i.e., the 9th column is really the 1st column of the "second line").

4 bit mode is a little more difficult, but it's definitely worth it for the pin reduction. Try to get a couple of different documents and study the initialization in 4 bit mode carefully... what they often don't make clear is that, even you power up the LCD, it is in 8 bit mode and the fancy initialization scheme you use to get it into 4 bit mode is really just a handful of 8 bit commands (where 4 bits are "don't care"), with the last 8 bit command setting the part into 4 bit mode.

---Joel

If it will help you, I can send you 8051 Assembler Code to initialize and use LCD's in 4-bit mode. Just let me know....

The only thing I can can think of is make sure you're waiting the required times between the upfront initialize commands... I don't think you can check the busy flag while you are switching to the 4-bit mode.(?) And as others have mentioned, verify the character address for position #9. It may not be #8+1.

Also, once you are in 4-bit mode, remember that all Commands and Data are sent high-nibble first. Good luck. We've all been there.... - mpm

Thanks to Bob and Joel

driver IC

2x8

do you mean i have to cheat the address ?in wich way?

and why with 8 bits all was ok?

Bob wrote

44780 chip thinks all lcds are 2 lines of 64 chars. Address of 2nd line starts at ram addr 0x40

the

really

looptest

movlw '1' call send_data movlw '2' call send_data movlw '3' call send_data movlw '4' call send_data movlw '5' call send_data movlw '6' call send_data movlw '7' call send_data goto looptest

strangely this loop gives me 12345671 and nothing else i hoped that at the 40th send_data a char in the 9th coulmn would be appeared,is this that you mean?

the

is

bit

i spent the NIGHT reading documents .. i'm using the 8 bit sequence suggested by the constructor of the lcd module

i guess i 'm fully in the 4 bit modes because when i want '1' i read the char '1' on my LCD.Do you think is it enough to be sure?....

still thinking that solution is trivial ......

Thanks again

Hmm... if it worked in 8 bit mode, it probably really is electrically 1x16 (and not 2x8). My only guess as to what would cause it not to work, then, would be if during initialization something went wrong.

...

Yeah, that's what I meant... so as mentioned above, apparently my initial guess as to the problem was wrong.

Yes, I believe that's enough to confirm that you're really in 4 bit mode (since your characters come out correctly). Hence the only suspect left is the configuration registers you write to at start-up.

Do you have another module (different brand, but still 44780 compatible) around to test with? I used a module only than was only "roughly" 44780 compatbile -- it *only* supported 4 bit interface mode (it didn't have pins for the other 4 bits), it didn't do customer characters, but it did have a handful of little annuciators that bits that were unused in the 44780 controlled.

---Joel

it looks that the problem was due to the checking of the busy flag

the loop (pseudo code) check db7 -gobackthere if still high

was simply too long,shortening it seems enough to solve the problem

the strange thing is that checking the signal with my logic state nalyzer( a vintage 8 bit tektronix 308) it looks that once the enable pin is turned high the DB7 becames low noramlly,but because of the low depth of the machine i can suppose that in some case it misses it,eventough i used dummy pulses to trigger it in the zone most likely problematic

Thank you all again,once this Ng is very useful even for a not-so-skilled guy as i am

i assure you that i post questions only after more than 3 hours of depression about the problem

Glad you fixed it. I had a product once with a (HD44780 compatible) LCD that was working just fine when we switched to a (HD44780) Noritake VFD for a nicer look (this was an obscenely expensive piece of semiconductor inspection equipment... it had polished stainless steel sides that cost something like $4k!). It was supposed to be a drop-in replacement, but nooooo... it didn't work at all. After some debugging, it turned out my LCD code was buggy, and it was just the fact that the timing of the LCD was different than the VFD's that had let me get away with it originally. I think it was related to busy flag checking...

What you see reminds me of a bug I discovered several years ago. I do not remember exactly all the details now, but I can tell you that if you are using a PIC processor, and using the code that Microchip suggested in an ap note about driving LCD numeric displays, it may be wrong. It went something like, "enable reading status, disable reading status, read the bit" instead of "enable reading status, read the bit, disable reading status." Most of the time the first one worked, because the tri-state bus had enough capacitance to hold the correct value, but sometimes it failed, and the failure could be consistent because of other things going on. It could be influenced by the difference between 8 bit and 4 bit modes. The last time I checked, quite some time ago, but also quite some time after I reported the bug to Microchip, it was still in the ap note the same way. I wonder how many people have used their code and not caught the error. -- Yes, I think it's still there in AN587, at code lines

419-421. If this isn't the problem you're having, maybe someone else will see it and be saved some agony. ;-)

Cheers, Tom