Many LCD's can be read from, but I can't think of a purpose for that capability. What do you use it for?

 

One is to read the Busy flag, rather than using arbitrary wait delay routines.
Less used in the eprom data & cursor address can be read if needed.
Max.

 

Say you have something like a 20 character by 4 line display, and you want to remember what's on it. Either you can keep a copy of the text data in an 80 byte buffer, or you can read it back off your device.

Then there's also reading back the busy flag.

 

Say you have something like a 20 character by 4 line display, and you want to remember what's on it. Either you can keep a copy of the text data in an 80 byte buffer, or you can read it back off your device.

Then there's also reading back the busy flag.

that's no longer relevant with today's controllers.
Early one's only had small RAM, let's say, 128 bytes, or even less than that.

On the other hand, due to the timing and strobing, you need additional ROM space if you use these RAM areas for reading.

In the 1980s when these LCDs were introduced, it was common to program controllers in assembler.

 

In the 1980s when these LCDs were introduced, it was common to program controllers in assembler.

I still do

I just use the 'read busy' signal to avoid wait loops.
Max.

 

i still have all my assembler sources but even looking at the larger one's makes me a headache.

For LCD, I first write to a RAM buffer with LCD commands, and then I send them to the LCD via timer interrupt scheduler.

Depends on the circuit, sometimes I only send a slice each time (or the main program becomes too much disrupted from the delays).

 

Many LCD's can be read from, but I can't think of a purpose for that capability. What do you use it for?

I once used the unused character space as auxiliary RAM after a tussle with creeping featureism on a 16C5x system. The Hitachi 44780 has 80 bytes of character RAM but only the physical number of displayed chars have to be used as such (that's why you have to reset the address pointer when changing lines on a shorter than 40ch display). Any display RAM that is 'off the screen' is available.

Just watch how you use Clear Display..

EDIT: you probably could use the CG RAM as well, another 64 (partial) bytes, but I didn't need to..

 

Reading from LCDs is pretty much obsolete these days.

Most of the newer generation LCDs/TFTs etc don't have read capability at all.

It's not necessary to read the busy flag, LCDs are very fast in normal operations apart from the slow "clear display" command mentioned above by JohnInTX.

 

I use it mainly for extracting the cursor-position just before the MCU goes into ISR;

I'm not skilled enough with ISR that most of the routine ended up messes with LCD writing process. i.e. after ISR, the characters randomly placed on the screen.

 

It's not necessary to read the busy flag, LCDs are very fast in normal operations apart from the slow "clear display" command mentioned above by JohnInTX.

Without reading the busy flag, one of every 3rd character was being displayed on the 2x16 LCD in my current project.

 

Without reading the busy flag, one of every 3rd character was being displayed on the 2x16 LCD in my current project.

You are doing something wrong. Are you certain all characters are being sent?

What happens when you step through your code and send a character at a time?

Where is your code that writes to the lcd?

 

Yes, all the characters are sent. I changed my code to read the busy flag before sending the characters, and it works.

//Copy second line to top line
for(i=0; i<16; i++) {
while(BusyXLCD() );
WriteDataXLCD_local(topline);
} 

 

Without reading the busy flag, one of every 3rd character was being displayed on the 2x16 LCD in my current project.

Did you exceed the timing spec as shown in the Hitachi 44780 datasheet?

Most likely you were sending the characters too fast and ignoring the required timing.

 

If you use the simple read of the LCD busy flag, there is no need for time delays.
Max.

 

That's why I read the busy flag in my code.

 

That's why I read the busy flag in my code.

Obviously people are responding to your post without taking the time to actually read your post where you quite correctly point out the use of the busy flag to give the display time to process your character data.

You correctly point out why and where reading an LCD is useful and/or necessary, but those who have already concluded the opposite will never admit your point.

Aside@Brownout: Is that the Microchip XLCD library you are using? I've been using that for years now, it works well but I've made several tweeks to it, such as placing the BusyXLCD() routine inside every other LCD function that should call it first. That way it never gets forgotten.

While I always use the read function I've been meaning to go back and do a conditional compile to add a delay when you don't use that line.

 

Aside@Brownout: Is that the Microchip XLCD library you are using?

I use a hacked up version of it. I used the libs as examples, along with other code, to create my own version. When I was trying to get my LCD to work, I had long delays so I could see the data change and verify it is what I expected. I never went back to using the standard libraries yet.

While I always use the read function I've been meaning to go back and do a conditional compile to add a delay when you don't use that line.

That's a great idea. I'm gonna look into that.

 

Obviously people are responding to your post without taking the time to actually read your post where you quite correctly point out the use of the busy flag to give the display time to process your character data.

You correctly point out why and where reading an LCD is useful and/or necessary, but those who have already concluded the opposite will never admit your point.

BrownOut tried doing without the flag and and mentioned it was not working. People are just trying to get his code to work without reading the busy flag. It can be done. While it might be necessary in some applications like sleep as was pointed out above, it certainly isn't necessary in a typical application if proper timing is done. And no one is saying the feature is not useful in certain situations.

Stepping through the code and sending one character at a time would have revealed a timing issue.

 

BrownOut tried doing without the flag and and mentioned it was not working.

I only forgot to put in the line that reads the busy flag and observed it doesn't work without it. Then I read a comment that said LCD's are fast and don't need the busy flag read.

People are just trying to get his code to work without reading the busy flag.

Why? It works great, and if I change the clock frequency, I don't need to adjust the dealys in the code. This is the prefered method, IMO.

Stepping through the code and sending one character at a time would have revealed a timing issue.

In the beginning,when I first attempted to get the LCD to work ( and I was brand new to PIC programming ) I connected 8 LED's and stepped through the code to make sure correct data was sent to the LCD. I also wrote in long delays so I could observe the data wihtout needed single step. But in my real code, I read the busy flag because that eliminates the need for delay timing.

 

BrownOut tried doing without the flag and and mentioned it was not working. People are just trying to get his code to work without reading the busy flag. It can be done. While it might be necessary in some applications like sleep as was pointed out above, it certainly isn't necessary in a typical application if proper timing is done. And no one is saying the feature is not useful in certain situations.

Stepping through the code and sending one character at a time would have revealed a timing issue.

Sorry meant to say there are other useful features of the LCD that you don't need in typical situations. The cursor position for example could be used to remember the cursor position during sleep.

Busy is useful too if you want to output as fast as the LCD can handle data.

But the typical application (at least from the hobbyist) don't usually need to implement them.