Mr RB
Well-Known Member
... The first and most important part is the delays, there are none for the last four commands. Unless the clock is really really slow the μC would be hammering the LCDM with command after command before it had time to complete them.
...
Take a look in the Hitachi 44780 LCD driver IC datasheet, int he commands table it should list the delays needed for certain commands.
...
Second is that, as you pointed out, 160us could/should be 1.6ms. We can't know from the code shown since they didn't have the forethought to let us know how this "Delay()" function actually works.
...
Agreed! SInce you are coding in C you could just use the C functions for delays in actual mS, like Delay_mS(x) and match or exceed the delays required by the datasheet.
...
The last details aren't really deal breakers, they are more conceptual problems. Calling command() three times in a row while passing the same exact data to it each time is inefficient and unnecessary IMO. All that really needs to be done is to load the command once, then just |Delay|->|Strobe E|->|Delay|->|Strobe E|->|Delay|.
...
True, but in C the compiler will be reasonably efficient for multiple calls with the same argument. It should load the data value once on the C stack and then just call the function 3 times. In the interest of good coding personally I would just leave it as 3 function calls.
...
Finally, and I could be totally wrong, but I don't think the entire sequence shown is necessary. I have been down this road with them before, followed their sequence to the letter, couldn't get the thing to work for weeks. I finally broke down and went to their forums where they gave me an entirely different sequence than the suggested one. It worked on the first try.
...
The datasheet should have the correct startup sequence, it looks something like the code you posted. You can sometimes eliminate some of it and get a working LCD but again for good coding practice following their sequence should hopefully ensure good compatibility with all brands of display etc.
...
I have a cute little "interlock" routine now that I hope works. Just as the name implies, it is designed in such a way that you (mostly) can't do LCD/PORT operations without going through these routines, and there is no combination of calls to them that can lead to both devices being Low-Z simultaneously. I also have two simple checks and a "panic room" catch all that can be used independently should one be forced to bypass the interlock system. ...
Sounds like a clever solution. Congrats.