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.

Nothing wrong with that if it works for you. It is an extra pin that you need to wire and monitor but as you pointed out it is more efficient.

Most of my projects are that time sensitive. A few microseconds wasted on waiting for an LCD that is ready to accept data is not going to matter to me.

 

Nothing wrong with that if it works for you. It is an extra pin that you need to wire and monitor but as you pointed out it is more efficient.

Good point. I thouht about that after I make my post.

 

If one is using a serial backpack on the LCD, then reading the busy flag would require a separate lead from D7 to the μC, bypassing the backpack. Yes?

 

I have never used one but from what I have read you communicate to them via serial at a given baud rate and they handle everything for you. So monitoring the pin might be useless if not impossible.

Now if you rolled your own with a shift register then yes you could monitor the pin just like you do now.

 

I have never used one but from what I have read you communicate to them via serial at a given baud rate and they handle everything for you. So monitoring the pin might be useless if not impossible.

Now if you rolled your own with a shift register then yes you could monitor the pin just like you do now.

You are probably right. I was just thinking that I could talk to the LCD through the backpack, but listen to the LCD directly. Then I could build in my code to the backpack the requirement that the busy flag from the LCD (that was connected directly to an input on my uC) be low before additional data was sent. Probably a lame idea. I have been somewhat successful lately with getting a 12F683 to control the serial backpack, but in order to do so, I have had to build in some significant delays between serout commands.

Thanks.

 

Just try lowering your baud rate.

 

Just try lowering your baud rate.

Try sending 2 stop bits as well i.e. 9600,N,8,2. The backpack code shown previously needs time to process between chars.

 

...
You correctly point out why and where reading an LCD is useful and/or necessary,

It is NOT "necessary". The only thing that is necessary is to allow the correct amount of time for LCD operations, as specified in the datasheet.

...
but those who have already concluded the opposite will never admit your point.

Was that aimed at me? My comments so far are based on the facts and my professional experience, not personal bigotry or stubborness. Please keep this on topic and not start a personal attack.

...
Quote; "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.

Now you are asking the right question; WHY?

Reading from the LCD requires tri-stating the port pins. This is a possible situation to cause error. You can get pin latchup if something happens when changing from input back to output, which can cause latchup or damage to either the LCD or the micro.

There are good reasons why I would avoid changing pin directions between a micro an another processor in a commercial design. If you don't have to take the risk, don't do it. This is another reason the more recent types of LCD and TFT don't have read facility. It's just one more thing to go wrong. The data to a display device only needs to go one way.

Now to finish off answering "why" you have to look at the gains from doing a flag read. Well they are not much. In both cases the display WILL take the required time to complete its operation, so a flag read doesn't really save time. Doing a flag read requires the same LCD time, then additional time to change port pin directions and allow pin voltages to safely stabilise, then time to read the flag, then more time to change the pins back safely.

After all that, you could have just waited the required time as specced in the datasheet.

As for "adjusting the delays in the code" that is all automatic and your compiler does it.

Just use a compiler function like Delay_uS(50); and your compiler will compile it to be a 50uS delay no matter which micro or xtal you are using.

 

I wouldn't have any issue changing port direction in any product. At Cisco, we had multiple masters on our busses, all of which had to arbitrate and use the same bus. Modern electronic processes has mitigated latchup to a very large degree, at least to the point I'm not afraid to use all the features of a product. These days, if a product is experiencing latchup issues, it's probably a layout or power error that is the root cause. All tristate means is the driver turns off so a different driver can drive the data pins. The process is fast and no additional time is needed for the pins to stabilize. There is a small amount of overhead, but so does using delays require a little overhead. In the final analysis, it matters little which method is used.