Question: Hippy's LCD Routine

[EPAIII]

Hippy or anyone who understands his routine for parallel LCDs.

The LCDs data sheets which I have read require an initialization routine that repeats the 8 bit mode command three times with time delays before each of them. The first requires the longest delay after power up, I guess to allow the chip to initialize. But the other two are supposed to be preceeded by a delay also. It took me a while but I see the trick used to transmit the 8 bit command three times. The first two "byte" variables consist of two nibbles. The first three nibbles are 0011 and the fourth is 0010. The sub that sends them to the LCD sends each nibble in turn so the three 8 bit commands are sent. But, as far as I can see, there is no delay between the first and second nibble. By calling the sub a second time, a delay is provided before the third 8 bit command and then the 4 bit command immediately follows it.

Am I missing something or is the second delay really not necessary? Or was it not necessary for the LCD used to set up the routine but it is needed for mine? In case you haven't guessed, the routine is not working with my LCD, a 2 X 20 from Cryatalfontz. I am also using an 18X but I don't think that matters.

Can anyone shed some light?

 

[hippy]

You're right, the code works as you have determined. The HD44780 displays starts up in 4-bit mode and needs nibbles to initialise. Two nibbles in a byte simplified the code, which doesn't include the 'necessary delay' between two consecutive bytes.

You've probably missed the comment in the midst of all the other commentary on my page ...

<i>The initialisation routines for an LCD are very clearly defined, and those familiar with them will observe that the initialisation used in this code <b>does not conform </b> entirely to the sequence and timing specified. This has not been shown to be a problem in practice, and all HD44780-based LCD's which I have tested have initialised and worked fine with the code, although it may not work with all HD44780-based devices or non-Hitachi chipsets, even those which claim to be 100% compatible. </i>

It could be the Cryatalfontz LCD isn't using Hitachi chips and needs more rigorous initialisation. I believe the code has worked for some KS???? chipsets, but that doesn't mean it will work for al LCD's.

My hardware configuration is the same as required for Rev-Ed's own LCD driving code in Manual 3, and Rev-Ed respects the timing requirements. I'd suggest trying Rev-Ed's code and seeing if that works.

Also, double check your hardware connections. Not adjusting the contrast pot is the equivalent of forgetting to turn something 'not working' on. Getting E and RS crossed over is a mistake I've frequently made, as is mis-counting pins and cross-wiring connections generally. The connections in my Web Page circuits are correct. LCD's can also be very picky about voltage, and may not work at 4.5V or 5.5V.

What results are you actually seeing when the code runs ? That can someimes give big clues about what does and doesn't work.

 

[EPAIII]

Yes, I did see your disclaimer, but I did want to confirm that there were no other tricks at play here.

I have tried to scrupulously copy your schematic and I did double-check the wiring, but I will check it again. Breadboards are notorious for goof ups.

Voltage should be dead on as I am using a 7805, on board regulator.

What does happen? The loader does report a successful download. The LED backlight does come on. I did adjust the contrast control. And the top row lights up with all pixels illuminated while the bottom row is completely dark.

.........

Oh, errr, dumb mistake. No +5 power to the LCD. I&#8217;ll make that connection and try again.

 

[EPAIII]

So, OK. A bit more work adding the missing connection and triple checking all the others and everything now works OK.

Apparently, the delay is not that crucial between the first and second 8 bit commands. Now on to programming.