I'm designing up a little dev/edu board and I'm down to assigning my last bit. The choices are (a) LCD R/W signal, or (b) a 4th LED.
Now I never use LCD R/W myself (always wire it low), but I'm curious what others do. Do you use R/W always? Sometimes? Never?
I never use the LCD read feature. I always write to LCD in a 50..100 uS timer ISR and never use such slow LCD commands as HOME/CLEAR.
Used it for experimenting only - several times triggered by questions here at 'freaks. If the "slow" instructions are used, one can/should easily encapsulate them in a function anyway and that function can do the specific wait for the instruction to finish by a timed loop.
One place where reading might become interesting is for scrolling contents. Saves the need for a display buffer in a RAM-challenged AVR/app.
Never had the need to read an LCD memory. But, as Johan suggests, I can see where it might be useful in a scrolling display. However, most scrolling displays (that I know about) are LED, not LCD. Maybe there are some, but it would probably want to be pixel-based rather than segment-based.
Jim
Are you talking about the R/W control line or internal LCD RAM?
If you are simply timing and waiting for display latency and never attempting to read data from the LCD, ground the R/W control line. But if you are attempting to use the "Busy" flag, you will need to use the R/W control signal to put the LCD in the read mode before reading the "Busy" flag.
I have read back cursor position out of the LCD and so, there too, the R/W control signal will be required.
Do you use R/W always?
Probably mostly because I started with the CodeVision provided driver, and haven't seen fit to change.
With all the threads over the years, especially with hand-crafted "drivers" by newbies instead of "proven", I'd say the BUSY-flag method adapts to a wider range of conditions.
MBedder's approach doesn't make you sit and wait. But what is the overhead of a fast timer tick? Say 20 clocks overhead, and then maybe that many for the buffer work?
We have a couple boards where we use the D4-D7 pins for other uses between LCD operations. I can't remember, though, what we had connected.
I've encountered some displays that take longer when going from the "left half" to the "right half". Busy-flag? No problem. Pure timing? Hmmm...
Anyway, there is a class of apps where having a live display is critical to the app. I don't want to start motion or engage contactors or the like when the operator cannot see the display. In the startup diagnostics on that board I put out the splash screen, do some stuff, and then read back a couple characters from the display memory and make sure they match. (Yeah, I guess the screen could be smashed or the contrast turned all the way down or ...)
I don't want to start motion or engage contactors or the like when the operator cannot see the display.
It depends. Most recently I used a 5V LCD connected to an Xmega. The Xmega has a max of 3.3V, so reading the 5V LCD would have required a level converter. Too much pain (and money) hence that project did not implement the read.
