0
\$\begingroup\$

I went to http://www.elm-chan.org/docs/lcd/hd44780_e.html in an attempt to find out how to make an LCD module work with the shortest timings. While the site does help with the initialization of the LCD, I feel as if it is not helping me enough.

Various sources state that for each LCD command or data processed, there is roughly a 40uS to 1.7mS delay before the command is complete.

The website mentions that I could poll the busy flag on the LCD but that would be too long of a delay (Its mentioned under the CPU load heading on the site).

So what I want to do is create a fixed delay in software so that the software continues to function even if the LCD gets disconnected from the circuit during operation.

The question is, where exactly do I implement the long microsecond delay in the code?

Do I insert the delay after I set enable to high (where green question mark is) or do I insert the delay after I set enable to low (where blue question mark is)?

I think its the latter, but I want to make sure.

LCD timing

\$\endgroup\$
  • \$\begingroup\$ For most operations you need both, before and after. And for some operations you need at least 1.52 ms \$\endgroup\$ – Maple Sep 20 '18 at 21:47
0
\$\begingroup\$

You should be looking at the datasheet for the LCD module, not at a typical application.

Anywhere the datasheet says you must meet a minimum delay time you need to make sure that you meet that delay. For the example timing diagram you provide, it looks like enable must be high for at least 450ns and its period must be at least 1000ns. You also need to make sure you meet the setup and hold times for R/S, RW, and DATA. Depending on how fast your processor can toggle a GPIO line you may need several short delays in the software.

\$\endgroup\$
  • \$\begingroup\$ I should be able to meet minimum delays easy. I'm using an AT89S52 with a 20Mhz crystal attached, so each instruction will execute at 0.54uS minimum, so if anything I could get away with a couple nop's \$\endgroup\$ – Mike Sep 21 '18 at 3:09
0
\$\begingroup\$

Since you need milli-second delays for the 'blue' part which is the LCD enable line set up some long term timers by doing this:

  1. Set up a real time clock (RTC) of 1 KHZ using a spare hardware timer. Resolution is 1 mS. It creates an interrupt (ISR) every mS to update any timers you have running or want to run.

  2. Set up a second hardware timer (countdown) controlled by 2 bytes. Byte 'A' is the time you want to delay, which is loaded into the delay timer when you make a call to it. It also sets a control flag in a status byte 'B' which starts and stops the timer. Exit ISR when done. The RTC ISR needs to do as little as possible to maintain the timers and status bytes, then exit so the main program can run between interrupts. Since we are using only bytes the maximum delay is 256 milli-seconds, just over 1/4 of a second.

  3. They are updated by the ISR that runs at a 1 KHZ rate. It checks the status bytes of all long-term timers and presets it first time and sets a 'preset done' flag in the status byte. If already preset it check to see if the count is zero, so it sets the 'done' flag for that timer and clears the 'delay' byte. Exit ISR when done.

  4. If timer is running and not = zero then it is decremented by 1 and the 'busy' flag is set to '1' to let the main program (MPU) know it has to hold a certain pin in a high or low state. Exit ISR when done.

  5. Honestly these LCD's are so slow I reserved some MPU pins just for the 40 char by 4 line display. I created extra pins for RD, WR, CS, ALE, 8 bits data port just for the LCD and bit-bashed the LCD control pins to get what I wanted. I was using a PIC17C756 MPU with 64 pins so I had plenty to have a 'fast' data bus and a dedicated LCD bus-it was that slow.

I still have the assembler code I wrote in 2001 for that test device but it is 13,000 lines of code. The LCD handler consumed 3,000 lines of code plus almost 1 KB of ram. I created 3 layers for the LCD so I had a fixed background layer, a layer with variable data, and a top layer for the pointer and warning messages. Another 3,000 lines of 'canned' messages ended my code.

I would print some of the code in my answer but I do not know what parts might help you.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.