HD44780 LCD - Minimum Enable (Read/Write) Rise time question.

[johankj]

Hi,

Does anyone have any experience with these LCD Panels (Or ASCII panels in general) and their Enable (E) minimum rise time?

According to the data sheet, tcycE is minumum 1000nS (Enable cycle time), and must remain in high a minimum 450nS (Enable Pulse Width - PWEH). The address must be set in advance (Read or Write) tAS, and is 40nS.

I'm running my MCU at 4Mhz, which gives one instruction per uS. I set the address ~seven instructions prior to enabling (E). This should be enough satisfy tAS. Before setting (E), I write to the DATA lines. My question is then, after this:

How long do you reckon i should delay between enabling (E) and disabling (E)?

Edit: Mis phrase here, I did not mean rise time, but 'high' time.

 

[ericgibbs]

hi,
I have seen different versions of the datasheet, do you have these two pages.

If you print out fig27 and fill in the times from the table you should be able to work it out.

Hope this helps.

 

[Nigel Goodwin]

You might try my LCD tutorial?, that works fine and one of them is exceptionally fast as it reads the 'device ready' flag rather than crude delays.

 

[johankj]

hi,
I have seen different versions of the datasheet, do you have these two pages.

If you print out fig27 and fill in the times from the table you should be able to work it out.

Hope this helps.

Yes, this is where I have taken my figures from. Working out from them, 40nS (RS/RW) prior to setting E, which should be enabled for a minimum 1000nS. But that is just one NOP minimum, so two NOPs should do it, right?

 

[johankj]

You might try my LCD tutorial?, that works fine and one of them is exceptionally fast as it reads the 'device ready' flag rather than crude delays.

Not necessarily, I agree with you that reading the busy flag is far more elegant, but if the enable time (E) is only 1000ns, that corresponds to only one clock cycle at 4MHz.

 

[ericgibbs]

Not necessarily, I agree with you that reading the busy flag is far more elegant, but if the enable time (E) is only 1000ns, that corresponds to only one clock cycle at 4MHz.

hi,
Do not confuse the 'Enable' status with the 'BUSY' status.

Its easy enough to stretch the Enable by using NOP's.

The problem is after you have written to the LCD, is if you attempt to write again, if the LCD is BUSY, this second write will be ignored.

To avoid this you have to use a delay loop long enough to allow for the slowest command/LCD, before you write a second time.
This can slow the program execution down.

To optimise the PIC to LCD control use the BUSY flag from the LCD, this avoids the use of the wait delays.
You must have the delays required during the LCD initialise.

Where it says LCD in my text, it means the Controller.

Are you having problems with LCD or is it just an enquiry?

 

[johankj]

hi,
Do not confuse the 'Enable' status with the 'BUSY' status.

Its easy enough to stretch the Enable by using NOP's.

The problem is after you have written to the LCD, is if you attempt to write again, if the LCD is BUSY, this second write will be ignored.

To avoid this you have to use a delay loop long enough to allow for the slowest command/LCD, before you write a second time.
This can slow the program execution down.

To optimise the PIC to LCD control use the BUSY flag from the LCD, this avoids the use of the wait delays.
You must have the delays required during the LCD initialise.

Where it says LCD in my text, it means the Controller.

Are you having problems with LCD or is it just an enquiry?

Thanks for your answer, I will probably implement reading the busy flag from the LCD. I understand your point that Enable is not the same as the LCD "Execution" time for various commands.

I was not having problems with the LCD, I just want to write to it as fast as possible. This is why I asked, because if this 'busy' time is less than a couple of microseconds, then it could be faster to use delays.

 

[Nigel Goodwin]

Thanks for your answer, I will probably implement reading the busy flag from the LCD. I understand your point that Enable is not the same as the LCD "Execution" time for various commands.

I was not having problems with the LCD, I just want to write to it as fast as possible. This is why I asked, because if this 'busy' time is less than a couple of microseconds, then it could be faster to use delays.

Any of the requirements for 'busy' are temperature dependent, amongst other things - if you're using delays you have to ensure the delay is longer than the longest possible busy time - so using the busy flag will always be faster.

You don't need to get obsessed about the speed, LCD's are very slow devices anyway - and my routine using the busy flag is probably as fast (or usually faster) as most others.

 

[ericgibbs]

Thanks for your answer, I will probably implement reading the busy flag from the LCD. I understand your point that Enable is not the same as the LCD "Execution" time for various commands.

I was not having problems with the LCD, I just want to write to it as fast as possible. This is why I asked, because if this 'busy' time is less than a couple of microseconds, then it could be faster to use delays.

hi,
In my experience the BUSY flag test is much faster than delays.
The problem with delays you always have to consider the worst case.
The LED's do vary slightly in speed from one LCD to another of the same type.
You may write a delay that suits that LCD, change the LCD and you can get problems.

 

[johankj]

hi,
In my experience the BUSY flag test is much faster than delays.
The problem with delays you always have to consider the worst case.
The LED's do vary slightly in speed from one LCD to another of the same type.
You may write a delay that suits that LCD, change the LCD and you can get problems.

Any of the requirements for 'busy' are temperature dependent, amongst other things - if you're using delays you have to ensure the delay is longer than the longest possible busy time - so using the busy flag will always be faster.

You don't need to get obsessed about the speed, LCD's are very slow devices anyway - and my routine using the busy flag is probably as fast (or usually faster) as most others.

Thank you for sharing your experience and knowledge.

I will use the BUSY flag for my program, I think this is the best solution.

Thanks ericgibbs and Nigel.

 

[wschroeder]

I would like to poke a hole (in a nice way of course) into the advantages of the Busy Flag versus delays. Agreed... the Busy Flag speeds up LCD data transfers... but.... how fast do you need all of this to be? Consider that 40us is the recommended delay for a single character write, and it works very well, take my word for it. You can write a full 4x20 screen in approximately 80 x 40us = 3.2ms + some code overhead.

Now give your eyes a chance to respond. The way I "see" it delays are just as good as utilizing the Busy Flag for the sake of LCD readability, and save the pin for something else.

 

[johankj]

I would like to poke a hole (in a nice way of course) into the advantages of the Busy Flag versus delays. Agreed... the Busy Flag speeds up LCD data transfers... but.... how fast do you need all of this to be? Consider that 40us is the recommended delay for a single character write, and it works very well, take my word for it. You can write a full 4x20 screen in approximately 80 x 40us = 3.2ms + some code overhead.

Now give your eyes a chance to respond. The way I "see" it delays are just as good as utilizing the Busy Flag for the sake of LCD readability, and save the pin for something else.

It's a good thing I had my project still on the weriboard. Luckily I had one free pin, which I originally intended to use for turning on/off the MAX232. I did get a little upset when I saw that I had to set the RW, because I had it wired to ground (always write).

This issue with writing to display only arose when I started to consider write times for high baud rates. 9600 baud (8N1) gives ~10ms per byte. At 115kBaud this is ~0.1ms per byte, so timing then becomes an issue.

Edit: Thank you for you comment by the way. Also, I seem to have less problems with commands now that I use the busy flag, though writing characters was never a problem.

 

[wschroeder]

Edit: Thank you for you comment by the way. Also, I seem to have less problems with commands now that I use the busy flag, though writing characters was never a problem.

Certain commands, Home and Clear, require extra attention. This is noted in the datasheet and 1.7ms is considered enough. Otherwise, 40us is sufficient for most everything.

If you are having problems with delays in your LCD project then I recommend the use of the Busy Flag. It is my opinion that most MCU applications that use a character LCD only 6 data/control lines is enough.

Here's a video demonstration that uses the 6-wire connection on a 4x20:

https://www.youtube.com/watch?v=6i0IK64oh8Q

 

[eblc1388]

Using the BUSY flag, your program will normally hang waiting for the flag to go LOW if the LCD is bad or disconnected.

Using delays would allow the program to get through the LCD code part and perhaps lights a LED or beeps to indicate the MCU is much alive while the LCD is faulty without any display.