LCD to use to have the least impact on the execution speed of the arduino

Other Hardware Displays
1

Hi Folks,

I need to display some parameters on my arduino, but it is IMPERATIVE that the data is processed as fast as possible.

What kind of LCD can I use that will add a minimun delay? Data should be printed at the loop exacution speed.

I have tried so far - coulours LCDs both SPI and parallel - the glaciars move faster than my arduino refreshes
I2C HD44780 - Little delay noticed but still some.

Am I right to think that using a 4 line x 20 Characters HD44780 in 4 bit parallel mode will be any faster than i2C for such a display or is there any other sugestion? An even so will it be fast enough?

2

you have already reduced it to refresh only the characters that are changing in the loop() function?

you could also reduce the number of updates by a) toggling it do update the LCD on a timer or b) every X executions of the loop() function...

that doesn't answer the question of pushing the output to the display as fast as possible, but the less you push, the faster you go.

3

BulldogLowell:
you could also reduce the number of updates by a) toggling it do update the LCD on a timer or b) every X executions of the loop() function...

I did that on a different project, but it will still reduce the execution rate, just less often

4

just curious, how many characters are you sending out to the display?

5

Likelly filling the 4 lines with variables, however the variable name is printed on the setup, so the main loop only prints the digits changing, Say 20 characters being updated at execution rate + LCD commands (Line selection, etc).

6

casemod:
.... LCD commands (Line selection, etc).

this stuff would be non-blocking, mainly. I'd focus on updating less, like you have in the past, while you try to sort out what works fastest.

7

I think I'd go for one that had an SPI interface - allows you to send data quickly, and offloads the processing to the chip on the LCD module.
Browse around here for ideas

8

CrossRoads:
I think I'd go for one that had an SPI interface - allows you to send data quickly, and offloads the processing to the chip on the LCD module.
Browse around here for ideas
http://www.newhavendisplay.com/

All SPI displays I've seen are graphical, so yes, the interface is faster, but i would have a higher CPU overload processing data to the display, right?

9

Riva:
Only update one line at a time through loop for a 75% reduction in print times at the cost of slower updates. If the loop is so fast you would never read the individual values anyway.

Could do with that.

Im going to write a piece of code just to check how long the loop is taking.
I need an update at least 10 times a second, however for smooth operation 100x a second would be ideal, however the display would only need to update 3x a second.

10

Many of these have SPI interface and are just 2-line or 4-line character displays.
http://www.newhavendisplay.com/serial-displays-c-253.html

11

CrossRoads:
Many of these have SPI interface and are just 2-line or 4-line character displays.
http://www.newhavendisplay.com/serial-displays-c-253.html

Oh, didnt knew those! Need to have a look out on eBay to see if they sell something similar.

I just clocked the function, depending on the loop takes anything between 384 and 414ms using an ST7735 display.
Im going to see if i can speed up the library to full speed SPI (comes default on half speed) and then will compare with some other displays

12

that is slow.

13

It is.
These colour displays are very convenient, but refresh is quite slow.
I believe the graphics library sends data as a whole, instead of using the chipset built in commands, for example asking the chipset to write a letter instead of "graphing" a letter

with SPI @ 8MHz i am down 55ms from the readings on last post, down to 337 to 362ms

14

well, you have to figure out how to send fewer characters, less often...

10X per second update... why so many? you can't do 3X now

if you have a display like this

Rotation: 100 rpm

just update this:

100

are you also doing an lcd.clear() type function?

perhaps you could post your code and see what folks can offer as assistance.

15

casemod,
Believe it or not, the majority of the overhead is not to the LCD.
In fact in most cases it isn't even do to the interface to the LCD.
(Well i2c is DOG slow so that interface is an issue).
The majority of the overhead is how the LiquidCrystal library code talks to the LCD and
the Arduino core code itself.
The biggest overhead is due to the way the LiquidCrystal library works.
Since it doesn't look at the ready status, it does blind waits that have to be much
longer than needed since they must accommodate the slowest LCDs.
Also, there are some delays in there that are simply no needed.

If you want to cut down the overhead and speed up the output, dump the
stock LiquidCrystal library for a better/faster library.
Here is one you can try:
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
It has been optimized to eliminate the unneeded overheads and uses raw port i/o
when using a shift register.
Most of the optimizations were done for the shift register code and that
is why you can see that even using a single Arduino pin (yes you read that correctly)
with a shift register you get LCD updates that are almost 4 times faster
than the stock LiquidCrystal library that uses 6 pins.
And a shift register using 3 pins is about 6 times faster than the stock
LiquidCrystal code using 6 pins.
and by switching to fm's code from the stock library for 4 bit mode,
you can get a bit over 3x improvement.

Another thing to keep in mind is that clear() is REALLY slow due to the blind
wait overhead for that command. You can erase the screen manually by printing
spaces to all of it many times faster than using the clear() function.

This is because there is no additional command overhead for outputing characters
or to position the currsor. So those complete as fast as the interface will allow you
shove them at the LCD, vs clear() which sends a CLEARDISPLAY command which is
executed by the processor on the LCD module which is not very fast. Since the
LiquidCrystal library doesn't read the busy status, it blind waits the worst case delay
of 20ms

You can find the benchmark numbers comparing the various libraries on fm's wiki.
Look down near the bottom of the home page for the "BenchMark II" numbers.
The numbers are for the LCDiSpeed sketch that I wrote that will normalize
the numbers for any interface and LCD screen size.
It is very useful to compare different libraries.
It reports how long it takes to send an individual byte as well as update
a 16x2 display (regardless of the actual display size) and then the update
time for the actual display size (this was left out of the table) and only
comes into play if the display is different than 16x2.

Here is another library that polls the busy status so there are not any blind
delays. I haven't benchmarked it so I don't know how fast it really is.
https://www.pjrc.com/teensy/td_libs_LiquidCrystal.html
(LiquidCrystalFast is what you are looking for)

And just to be clear, all the interfaces, with the exception of a async serial interface,
will be synchronous.
i.e. the library will not return from write(), print() etc... until all the characters
have been sent to the display.
If you are using a async serial interface then up to the last 32 characters
can be buffered in the HardwareSerial library buffers.

--- bill

16

casemod:
with SPI @ 8MHz i am down 55ms from the readings on last post, down to 337 to 362ms

I have no idea what type of display, geometry, h/w interface, or library you are using
what exactly you are doing but 300+ms ??? That seems VERY slow.

If you wan't to use a glcd (like a ks0108 or sed1520) vs a hd44780 type display
and you want/need speed, have a look at my openGLCD library.
https://bitbucket.org/bperrybap/openglcd/wiki/Home

It will use a lot of pins but you will get high performance.

In terms of using SPI, and getting an LCD with SPI that isn't necessarily the fastest interface.
It depends on many factors.
With highly optimized code, s/w bit banging can be faster than using
the Arduino SPI library.
It all depends on what you are doing and what you are talking to.
Also, most devices that call themselves SPI aren't really SPI at all.
They are really just a shift register and still require a latch signal.
With a true SPI interface, you could slam bits at it all day long and not
have to worry about latch signals.

--- bill

17

BulldogLowell:
well, you have to figure out how to send fewer characters, less often...

As someone sugested I could breakdown the data and print a line at the time. I doubt i could get a decent refresh tough, since printing everything takes 200ms, so I would perhaps have an update rate of 4 seconds if i were to delay the loop only 20ms, giving it a loop execution rate of 50Hz.

Now, its up to try different displays and see what i could get.

BulldogLowell:
10X per second update... why so many? you can't do 3X now

Is that suposed to be a constructive argument?
Why is the speed limit inside London 30mph when the average speed is only 8mph?

BulldogLowell:
if you have a display like this
Rotation: 100 rpm
just update this:
100
are you also doing an lcd.clear() type function?

Mind you, this topic was opened with the intent of finding the refresh rate for different types of displays. There is litle data being sent and I should be able to do what i need with the right display.
If you read the whole topic you'll realize the loop is what i want to update every 10-100x a second.
I am fine with a refresh rate of 2 or 3Hz for the LCD.

lcd clear and variable names are printed once at setup with the actual data being refreshed as per your sugestion

BulldogLowell:
perhaps you could post your code and see what folks can offer as assistance.

The point is not about the code it is about what LCD to use that can have the least delay possible to print some characters.

Having said that, does someone know of a graphical library for the ILI9341 or ST7735 that actually prints caracters using the graphical driver commands? That would considerably speed things up

18

bperrybap:

casemod:
with SPI @ 8MHz i am down 55ms from the readings on last post, down to 337 to 362ms

I have no idea what type of display, geometry, h/w interface, or library you are using
what exactly you are doing but 300+ms ??? That seems VERY slow.

If you read the question it is indicated - ST7735 which is an SPI display clocked at 8MHz (Max).
That should clarify some other things. Ill have a look at your library, what displays does it support?
[/quote]

19

Good Stuff bperrybap,

I knew most of them, but thanks for pointing out that the arduino library is that bad. I will certainly avoid it.
I dont clear screen. I simply clear whatever digits I am printing.

Say on setup I print (once) all the variable names. For example: rpm
The loop only updates the actual value, for example 845. So its not a lot.

20

casemod:
If you read the question it is indicated - ST7735 which is an SPI display clocked at 8MHz (Max).
That should clarify some other things. Ill have a look at your library, what displays does it support?

I saw a mention of that display in reply # 11 but so many different interfaces were mentioned earlier
that I wasn't sure which display you were referring to in reply #13 since
reply #11 mentioned 384ms and 414ms but reply #13 said things were now faster
but didn't mention the actual display so I wasn't sure.

openGLCD currently has full support for the ks0108 and sed1520 type displays
but not the ST7735 so it is of no use for the ST7735.

I think it would helpful if you stated your needs for the project.
Knowing the requirements will help lead to the solution.
For example, is the real requirement a particular refresh rate or minimizing
the time for an individual LCD update to provide more cycles for other things?

Ggraphic LCDs are cool but if you don't need graphics,
you may want to stick to a hd44780 character display
as it should update faster with less overhead (double win)
than a graphic LCD because everything is simpler with text
based LCDs and less data has to be communicated with character
based LCDs.
But it all depends on your real requirements.

100x per second updates?
Most of the LCDs out there don't have a liquid inside them that can
transition that fast. Many of these LCDs can't display pixel changes faster than 150ms to 200ms
It isn't that the LCD can't be updated faster than that (it can),
but rather it is a physics problem of the actual display.
(See the attached image from a typical 16x2 LCD display)
The liquid inside the display simply can't rotate the molecules inside it
fast enough to transition a pixel cell that fast.
So updating the LCD faster than about 5 times per second isn't of any practical value
since the pixels can't transition that fast.

And even if the display does have a faster liquid,
eventually you start to bump into limitations of the human eye
at much above 50 to 60 times per second.

Then there is a practical matter of usability of rapidly changing data.
A more frequent update rate would provide a more responsive update,
but beyond about 2 or 3 times per second can make the display unreadable
particularly if the data is rapidly changing.
For example, if you were printing something like RPMs.
If you update it too quickly (more than about 2-3 times/second)
and the data is rapidly changing all you will see
is a jumble of pixels where the digits are supposed to be.

For hd44780 displays,
you can look at the LCDiSpeed benchmark numbers on the link I provided to calculate
how long each of your updates will take based on the transfer time of a single byte
and how much data you are sending.
That byte transfer time is the time from when the write() is called until the write() returns
which includes the total overhead of everything, library, interface, lcd, etc...

Setting the cursor position takes the same time as a sending a data byte/char.
You can see from the table that the library can update a full 16x2 display hundreds of
times per second on all interfaces except i2c.
The table shows you how long it takes to push a byte through the library, through the
interface all the way to the HD44780 display.

You can do the math to see how long your updates will take on your desired
interface and from that you can calculate the maximum refresh rate for your application.

--- bill

Screenshot.png
Screenshot.png1025×529 43.9 KB