casemod:
thanks for pointing out that the arduino library is that bad. I will certainly avoid it.
There is a current thread about a new library to get fast data to a 5110. Using large fonts on TFT screen can slow things down quite noticeably.
http://forum.arduino.cc/index.php?topic=236843.msg1719779#msg1719779
casemod:
I knew most of them, but thanks for pointing out that the Arduino library is that bad. I will certainly avoid it.
"It's worse than that — he's dead, Jim!"
bperrybap has pointed out two very important things.
One is that the display itself - the liquid crystal - is so slow to respond, that updating more often than three times a second is pretty useless. This is readily demonstrated on a 1602 display with the "Mario" demonstration code. Of course, the LCD used in your video monitor is very different stuff.
The other is that the interface chips such as the HD44780 are also slow to process commands, so the library code deliberately introduces substantial delays. It is generally understood or expected that your application considers the display itself the "end goal" and is content to wait.
Now if you actually want to do something else concurrently, you have to write multi-threading ("state machine") code, probably by decomposing the libraries themselves into steps where each point which implies a wait of any sort, defers to the alternate processing you are performing.
Paul__B:
The other is that the interface chips such as the HD44780 are also slow to process commands, so the library code deliberately introduces substantial delays. It is generally understood or expected that your application considers the display itself the "end goal" and is content to wait.
Also, keep in mind that writing a character, or setting cursor position is not one of the slow commands
that adds a deliberate command delay.
Writing a character or setting the cursor position
can happen for the most part happen at the speed of the underlying interface to the hd44780 pins.
So when updating the display, if you want to avoid any added delays, don't do anything
but cursor positioning and character output.
Avoid using home() and clear() which will block the sketch for several milliseconds.
There are also some inefficient code and deliberate low level delays in the default LiquidCrystal
library that are much longer than needed particularly when it comes to the low level interface code,
how the enable signal is handled, and when running in 4 bit mode.
--- bill
This could be relevant: When updating the data, generally I write a loop to add a zero or two depending on how many decimal places there are. For example asssume the result is 8, jumps to 68 and then to 255. When it goes back to 55, the last digit is not updated so I get 555 and the same when it goes back to a single decimal place: Example x55.
What would be the most effective way to deal with this? The one I am using? Something else?
Generally you set the cursor; if the value is less than 100, write a space; if it is less than 10, write a space; finally write the number.