I have an extra pin; the R/W pin of the LCD is tied low so output always
works - but I could use that pin to control the line.
Does anyone read from the LCD; and if so, why?
Jan Panteltje said: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.
Jan Panteltje said: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.
Sorry, don't know what you mean here.
Jan said:And I do not see how you can select a line in a 4 line display with one bit.
John Devereux said: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.
Are you talking about one bit on the interface or one bit in the LCD
control registers ??
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.
http://ouwehand.net/~peter/lcd/lcd0.shtml
Huh?That was the OP's idea: 'to use the RW pin to control the line'.
That was the OP's idea: 'to use the RW pin to control the line'.
Joel Koltner said: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.
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.
No, it was to use the extra Pic pin to control the R/W line.
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.
Spehro Pefhany said: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.
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.
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- Hide quoted text -
- Show quoted text -
_ said:I have an extra pin; the R/W pin of the LCD is tied low so output
always works - but I could use that pin to control the line.
Does anyone read from the LCD; and if so, why?
