Do you bother with reading from the LCD (HD44780)?

On a sunny day (Wed, 06 Feb 2008 15:50:43 GMT) it happened _ wrote in :

You make a mistake, you need to *read* to check the 'busy flag'.

You don't *have* to - you could assume a "worst case" timing instead. I used to do this, it means the program can still carry on even if there is no LCD working. (Without needing timeouts on every operation). Text output is usually so slow the extra delay does not matter.

--

John Devereux

On a sunny day (Wed, 06 Feb 2008 16:07:56 +0000) it happened John Devereux wrote in :

That depends, if you are on RS232 and a small buffer (say 3 characters), you will be more limited in baudrate if you use a fixed delay. Your delay will have to accomodate worst case parameters, and be long.

And I do not see how you can select a line in a 4 line display with one bit.

Sure, it's not always a good idea.

When I did it I had a separate task for the user interface and the serial comms. An extra ms will make no difference in the UI task, and could save a pin and some complexity.

Sorry, don't know what you mean here.

--

John Devereux

On a sunny day (Wed, 06 Feb 2008 16:34:55 +0000) it happened John Devereux wrote in :

That was the OP's idea: 'to use the RW pin to control the line'.

Are you talking about one bit on the interface or one bit in the LCD control registers ??

Pin number Symbol Level I/O Function

1 Vss - - Power supply (GND) 2 Vcc - - Power supply (+5V) 3 Vee - - Contrast adjust 4 RS 0/1 I 0 = Instruction input/1 = Data input 5 R/W 0/1 I 0 = Write to LCD module/1 = Read from LCD module 6 E 1, 1->0 I Enable signal 7 DB0 0/1 I/O Data bus line 0 (LSB) 8 DB1 0/1 I/O Data bus line 1 9 DB2 0/1 I/O Data bus line 2 10 DB3 0/1 I/O Data bus line 3 11 DB4 0/1 I/O Data bus line 4 12 DB5 0/1 I/O Data bus line 5 13 DB6 0/1 I/O Data bus line 6 14 DB7 0/1 I/O Data bus line 7 (MSB)

I think the OP was wanting to use one bit on his micro to toggle the R/W line.

As far as reading the busy bit, any character write to the display takes about 40 uSec to process. In the past when I used these controllers, I has used a 1mSec interrupt to control a FIFO out to the LCD.

No looping at all.

If the display was large enough, you might see a flicker. But a 20x2 display looks solid.

See:

donald

This is true, although personally I always checkeded the busy flag just because it grated on my nerves to have a CPU sitting there in an idle loop to wait out the "worst case timing" that was usually something like 20x longer than the "typical" timing. I'd usually have one routine that checked whether or not the LCD was responding when the system first powered up and, if not, didn't bother even trying to display anything later. After that if you yanked out the LCD or it failed, the system would hang until the watchdog timer reset everything some milliseconds later.

On a sunny day (Wed, 06 Feb 2008 09:42:26 -0700) it happened donald wrote in :

Yo uwil lhave to ask the OP,., but I think he was referring to the interface.

? Maybe the OP will be back.

Nice site, very informative.

Huh? Still not getting it. If you mean select the line on the display, that is done by moving the cursor to the memory location of the start of a line. You can do that with just writes to the command register. It is selected with the R/S line.

No, it was to use the extra Pic pin to control the R/W line.

Hi Joel,

Sounds like a good compromise.

I don't use character LCDs much anymore, but in olden times I used them on a shared bus with memory. When the system was dead, it made fault finding a lot easier to have the rest of the system keep going without the screen.

--

John Devereux

You don't need to spin in an idle loop you know, there are lots better ways to handle things if it's desirable (interrupts, polling loop with timer etc.)

Sometimes you might want it to limp along even if the display failed. The display is probably relatively prone to failure since it's generally pretty exposed. Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On a sunny day (Wed, 06 Feb 2008 17:04:09 GMT) it happened _ wrote in :

That line, OK.

On a sunny day (Wed, 6 Feb 2008 11:59:10 -0500) it happened James Beck wrote in :

bit.

Sure, I know that, you know that, and now it seems the OP also knows that.

Hi Spehro,

Indeed, although unfortunately LCDs fall into that category where interrupts don't really look all that attractive because the "typical" LCD write time is often around 1us per character. For your "run of the mill" "some MHz" microcontroller, making such an interface interrupt driven may actually end up slower than polling!

Agreed, in some systems that would be preferable

---Joel

I avoid checking ready flags unless it's really necessary, so the program won't hang if the peripherial does. If you must spin on a ready bit, it's prudent to add a timeout on top of that!

You can always pipeline display logic: fetch the next character and housekeep pointers or whatever in the right place in the loop.

Poke: compute : spin...

is better than

Compute: poke: spin...

but best is

Compute: poke...

John

op to

ger

ot,

anked

reset

I allways buffer them, then write a character from the buffer on a timer interrupt. If the display is busy just return without doing anything. Next interrupt tries again. It makes editing very easy and no delays to the main program whatever the display is doing.

Yes, I do it when I can. It's wayyyyyyyyyyy faster than doing the fixed delay thing, depending upon the particular LCD. Beware: you can't try to read the BUSY flag until _after_ you get done initializing the LCD.

Neat idea, I'll try that some time... at least in microcontrollers that have enough RAM to keep a "framebuffer" around (I've used some that didn't!).