I read 132 us to put a character on an LCD using a 74HC164 shift register.
I use shiftout,clock on D3,data&RS on D4 and enable on D2.
I don't consider this slow. The attached scope photo has the enable on the top and the 8 clock pulses below.
I have posted full details on http://projects.worsleyassociates.com
I didn't see anything about LCDs there. Did I miss it? Is that link to the details correct?
In terms of "slow", it depends on your view of what "slow" is. Every thing is relative.
To me, 132 us is VERY slow compared what an AVR at 16mhz is capable of doing.
It is the Arduino core code that is so slow. shiftout() calls digitalWrite() to set the pins
and the digitalWrite() code implementation in the core code is quite slow compared to what can
be done even when the Arduino pins are configurable and not constants.
(if using constants the clock on the SR could be strobed every 125ns)
shiftOut() itself is not very optimized code. It runtime checks on shift direction and doesn't
do its loops as well as it could (should).
Just re-rewriting shiftout(), even when still using the slow Arduino core code digitalWrite()
functions can speed things up.
The shiftout code used in fm's library (which does not use any Arduino core code) can shift out a byte
and strobe a separate E/Strobe line in under 16us. - see the attached analyzer shot.
It reduces to a couple of microseconds on the Chipkit Uno32.
It is isn't clear what is represented by the 132us analyzer shot.
I can't tell if it is the full amount of time to put a character on the display
or just the time it takes to shift out a byte, set up RS and strobe E.
i.e. can you sustain that time/rate for back to back character writes?
In order to measure that time, it is best to measure between two back to back character writes.
I say "character writes" because there is more timing overhead than just the shift operation and the E strobe to the LCD.
There is also LCD timing overhead that must be honored to ensure that the lcd is given enough time to process the
operation before another operation can be done to the lcd.
The best time measurement is the time between to back to back lcd.write() calls.
This measures all the overhead as seen by the sketch. It includes all overheads including
any s/w overhead in the library as well as the the time to get the data to the lcd.
It is a true measurement of how long it takes to write something on the lcd.
I noticed that you are using 8 bit mode but most of these 8 bit shift register LCD libraries
are usually operating in 4 bit mode to have other capabilities like backlight control.
For 4 bit mode it means you have to do a minimum of 2 shiftout operations just to get the data there.
And then there are 2 more shift register register loads to raise lower E.
So in 4 bit mode there are a minimum of 4 shiftout() operations that must be done in order to transfer a single character to the lcd vs the one that is possible when the LCD is in 8 bit mode and RS and Data share a line.
However, if even if the lcd library is using 4 bit mode it can still be faster than 8 bit mode if it avoids
using Arduino core code shiftOut() function.
I have measured back to back lcd.write() timing with an analyzer and now have a sketch that can do it.
With fm's library the back to back write times are:
72us - using only 2 wires, 4 bit mode and a fixed SR pin wiring
102us - using 3 wires, 4 bit mode and a fully flexible SR pin wiring
These numbers are doing 4 shiftout operations per byte transfered to the LCD.
They represent the full and total overhead of back to back lcd.write() operations.
i.e. you can write to the display with back to back writes
forever with each byte taking the shown time away from the sketch.
For comparison, here is the total timing overhead for the Standard Arduino 4 bit parallel library:
338 us - Standard LiquidCrystal library using 4 bit mode with directly connected pins.
You can see the effects of how slow digitalWite() is.
Setting up the pins directly is slower then all the many additional toggles that must be done to shift out the bits.
The difference is using better i/o code vs the Arduino core code to do i/o operations and optimizing the lcd
processing timing to strictly match the hd44780 spec.
Luckily in most cases, such low level timing is not an issue for typical Arduino stuff.
But when time really matters, you must avoid using the Arduino core code.