tack:
fm:
If you look in the project's wiki you will see that the 2 wire SR version of the library is about 4,5 times faster than the stock parallel LiquidCrystal an almos 40 times faster than the I2C versio.Wow, that's some difference. I actually expected it to be slower for some reason. No real basis for that though, other than I guess some intuition that a cheaper method using generic SR would be slower than a specific implementation like I2C, or a parallel interface using a lot more pins.
There are some things to consider as well. The default i2c clock 100 khz - That is according to the I2C spec.
And that is the clock rate that Arduino programs the i2c interface to clock at. That is pretty slow.
Some of the newer i2c chips support higher speed and can can clock up to 10mhz.
(I bet wiring and pullups/termination becomes much more critical at those speeds)
So there is some room there if you use a faster i2c chip and put in an Arduino hack to speed up the i2c bus.
(But that might interfere with other slower i2c devices if present).
On the parallel mode, it is a bit unfair in that the serial shift register code is using indirect port i/o
while not as fast as direct port i/o, it is MUCH faster than using the SLOW digitalWrite() functions
in the Arduino core code. Currently the 4bit code is not using the indirect port i/o functions. This would be
a small change to the code and would speed up the 4bit code quite a bit.
I'll definitely give that a try at some point as I have plenty of 595N's coming. I think I'll be off to design a new 2W SR based backpack.
I guess the only difference is with controlling multiple LCD's. With 2W SR would I need another 2 pins for a an LCD displaying different data?
How does the library handle daisy chained SR? Does it, or would it be possible, to support multiple LCD's by writing 16, 24, 32 bits across multiple SR to display the same or different data on each? I'm thinking of this from the way ShiftPWM works. If you actually have 2 SR connected, but specify only 1 then the data gets repeated on the second.
Maybe the SR constructor could include a NUM_SR data to effectively specify how many LCD's. I suppose you'd need some kind of reference to each one for lcd.write() etc, such as lcd1.write, lcd2.write like you would if declaring multiple constructors normally.
There are three different SR device layer interfaces.
SR - output bits and wiring is hard coded but supports 2 wire or 3 wire mode. Currently no backlight support.
SR2W - (I did this this one) output bits and wiring is hard coded for 2 wire mode (clock, data) but
supports backlight control and has ASCII wiring diagrams in the header file for using various shift registers
and a sample backlight control circuit. Because the output bits/pins are hard-coded and can take advantage of certain
optimizations, it is actually faster than the SR3W code.
As expected, less flexibility = faster. (byte xfer time of 76us for SR2W vs 102us for SR3W)
SR3W - runs with 3 wires (data, clock, latch) and allows configuring output bits to allow any wiring - supports backlight.
The obvious down side of SR modes vs i2c is the number of pins.
I2c adds no additional pins for additional devices whereas SR modes do.
For driving multiple LCDs with the the existing SR code, you can share data and latch pins but not clock pins.
So the total numbers of Arduino pins doesn't have to be replicated for each additional LCD.
It will be I+(N-1) pins. Where I is the initial number of pins (2 or 3) and N is the total number of displays.
So for 4 displays in 2 wire mode it would be 2+(4-1) or 5 pins.
--- bill