Slow LCD Redraw Rate

I just hooked up my first 20x4 LCD. Ideally I would like to update one of the lines at a pretty high rate (every 33ms). However, it seems as though the display does not redraw fast enough (time it takes to update a single character).

I changed the logic to do the updates less often but the effect is the same. I guess I was expecting more “snap” with the redraw.

Is this expected for this kind of device?

Hello johnr,

I never played with 20x4 LCD but 16x2. In here the refresh rate is just very fast, tested with a simple sketch updating millis(); in massively form and seemed just like "real time". Maybe something related to the hardware itself? Are you using the default library? in 4 or 8 bit mode ?

Maybe a nice thing to test, configure the sketch as if it is a 20x1 or 20x2 display and see if it makes some difference, maybe you can start sorting things out this way.

Another point is: It´s not the sketch itself being laggy for some reason?

Salute,

Rodrigo

If you are running it in 4-bit mode, using 8-bit mode would probably give you twice the refresh rate, as it can transfer many more bits at the same time ...

johnr:

Ideally I would like to update one of the lines at a pretty high rate (every 33ms).

What are you trying to update? It's designed as a character display that is designed to display words that are read by human beings. You send it the data you want to display and that's that. There's no need to update anything until you want to display new data.

If you are trying to do something something like a bar graph than that's a different story. In that case you probably don't want to mess around with high level languages, and should go with assembly language programming using the busy flag (requiring implementation of the R/W line).

Don

Things:

If you are running it in 4-bit mode, using 8-bit mode would probably give you twice the refresh rate, as it can transfer many more bits at the same time ...

It's not really that much faster. It does takes twice as long to transfer the data, but that time (or twice that time) is short compared to the time it takes the LCD controller to deal with the data.

Don

The standard LCD library does not read the status of the LCD before writing to it. Simply all it does is put in a delay to make sure the LCD is ready before it receives the next display character. This can take a long time with commands like clearing the display. You can modify the library to read the "ready" flag and replace this with the delays. Also if you can dedicate four adjacent pins for the interface you can make the writing out to the pins faster with a bit of direct port manipulation. I have found you can double the speed of writing this way. Note writing a single character is a lot faster than clearing the display.

Thanks to all that responded!

I am using the default library in 8 bit mode. I have been trying to display a value in real time but am now questioning that approach based on comments (I was thinking the human brain would be able to extract the info as it was generally increasing values).

What I may do now is more of a “peak hold” approach where I display the maximum value for a moment and then have it “decay”. This is for low level debugging/tuning.

The comments above have been helpful and will I refer back to them I am sure!

Thanks again!

johnr:

I would like to update one of the lines ...

Is it really necessary to update the entire line?

I have been trying to display a value in real time ...

If you were using an analog meter (whose mechanism effectively averages out quickly changing values) this approach might work. With a digital display of a quickly changing value the display would probably be an unreadable jumble.

Don

Mike:

Also if you can dedicate four adjacent pins for the interface you can make the writing out to the pins faster with a bit of direct port manipulation. I have found you can double the speed of writing this way.

In my opinion this is a poor tradeoff since, as I mentioned in reply #4, the amount of time it takes to write the data is insignificant compared to the time it takes the LCD to deal with the data. This is especially true when using time delays as opposed to using the busy flag. Also, you can't just use [u]any[/u] four adjacent pins, they must be on the same port. In other words you couldn't use this technique with Arduino pins D6, D7, D8 and D9 even though they are numerically 'adjacent'.

Don

In my opinion this is a poor tradeoff

I disagree for my system where I could plan in advance what I was doing and I didn't want to make it a universal library.

Also, you can't just use any four adjacent pins, they must be on the same port.

I didn't say you could use ANY adjacent pins, in my book pins on different ports are not adjacent.