works the same as the included/standard LiquidCrystal at the API level
Well so does the I2C option.
We are in total agreement. In my original comment:
The shift register implementations (2wire, 3wire, and I2C)
have LiquidCrystal API compatible libraries available.
I mistyped "shift register" when I meant "serial".
meaning all the 2wire, 3wire and i2c implementations
have Liquidcrystal API libraries available.
Sorry about any confusion/mis-understanding there.
No other low wire count interface is this easy to make for a DIY project.
No it is the same level of complexity and cost to have an I2C chip as to have a shift register.
Going to have to disagree here.
While a circuit design using an i2c i/o expander chip is similar in complexity,
a shift register implementation only uses 4 components
for a total component cost (without PCB) of 24 cents
0.01 4.7k resistor
0.01 1N4148 diode
0.01 0.1uf cap (bypass cap for 595)
0.01 0.1uf cap (bypass cap for lcd)
Add backlight control:
0.01 4.7k resistor
0.01 0.1uf cap
0.08 2N7000 mosfet
0.01 150 ohm resistor (lcd current limiting)
0.35 (total with backlight control and current limiting)
NOTE: the backlight circuit could be modified to cut 6 cents off the cost if it used a cheaper transistor.
I have this working today and those are the actual QTY 1 pricing prices I paid from Tayda:http://www.taydaelectronics.com/
I would be very interested to see an i2C implementation for a component
cost of less than 24 cents or less than 35 cents with backlight control.
From a software perspective, the software to run a shift register is substantially
smaller and less complex than the code needed to run an i2C i/o expander.
(especially when you look at all the needed code including the wire library for the i2c implementation)
You and I are in total agreement. I think something I typed didn't come across
very well. (I think the part of having/using a LiquidCrystal API threw everyone)
This is my guess as to why I think the 74HC595 is popular.
It is cheap (seems to be cheaper than some of the other shift registers - hard to beat 20 cents per chip).
It is easy to find
It is easy to understand and can be debugged with a simple logic probe or even a simple LED (poorman's logic probe).
While there isn't that much to really fail with i2c especially when the hardware is wired up correctly
and there is a working library,
if something does go wrong with I2c, most folks will be out of luck trying to debug it.
Don't get me wrong, I like many of the i2c implementations
and intelligent async serial backpacks, but they typically will cost more than a DIY 595 board.
If you are buying a lcd backpack they are all about $10-20 USD and
the performance of any one of them is good enough for most applications.
a 2wire or 3wire shift register interface can (depending on the library)
allow LCD updates to be faster than i2C or Asnyc serial.
The limiting factor is how fast the LCD can respond to the commands. The slightly slower speed of the I2C interface does not actually slow down the rate of update of the LCD. In fact the standard library doesn't read the ready flag from the LCD and so has to insert large delays for some LCD commands where as in practice the display does not need this long to be ready. The LCD clear display can be up to twice as fast by reading the ready flag. The reason why this is not done is to save a pin, a factor that is not important when you dedicate an I2C chip to it. With shift registers you would need input and output registers.
Again, I am going to disagree here.
I have real world experience and math that I believe proves otherwise.
It isn't just about the time the LCD takes to process a command.
The time it takes to transfer the data/cmd to the lcd also matters because the lcd
can't start processing the command for the update until it actually receives the data/cmd.
The transfer time is pure latency overhead that can never be recovered
so it directly impacts how fast the LCD can be updated.
I think your are underestimating the impact of this transfer time especially
since in many cases the transfer time can be longer than the time it takes for the LCD to process
About the polling READY. Sure, polling READY is ideal. But it takes extra hardware to do it
(which is why it usually isn't done)
and for all but a few commands (clear, home) the needed "blind wait" is short (37uS) and
with a good library implementation it can often be hidden under
other code or the i/o transfer time. For example, with 2wire, i2c, and serial interfaces, the 37uS blind wait after
issuing a command or writing data can be eliminated or drastically reduced since it can
occur in parallel with (underneath) the transfer of the next command or data write.
There is no need to do a blind wait of 37uS if it takes longer than that to transfer the next
command/character, yet I see libraries that do this, which clearly shows the authors
don't understand the transfer/latency overheads and protocols involved.
Lets look at something more real.
Say the time of a real API call that the sketch would use:
lcd.write() to send out a character to the display.
Now lets go back and look at some real world transfer times:
A serial interface is often running at 9600 but lets assume 115200 at that rate, each character transmits
at about 87uS and this is in addition to any of the other s/w overhead from lcd.write(), the lcd library, or hardwareSerial code.
For this interface the 37uS blind delay after sending a command or data
is not needed since the serial interface can't send bytes faster than 87uS.
(The actual time for lcd.write() for Async Serial will *always* be longer than 87uS)
i2c using the default 400kbit/sec clock rate and 8 bit addressing is similar.
This is because with an i2c you not only have the overhead of the i2c physical layer protocol overhead
but also the overhead of using an i/o expander which requires a minimum of 2 output register
updates. (1 with E high, and then 1 with E low).
Ignoring start/end i2c overheads you have minimum of 3 bytes (i2c device addr, reg addr, data) to update
the output i/o expander latches.
And it takes two latch cycles to strobe E.
assuming you violate the LCD spec by setting E high at the same time you set the control and data lines.
If you don't violate the LCD spec it takes three latch cycles (E low with control and data lines set, E high, E back low)
So that is a minimum of 6 bytes. (assuming you want to save time by violating the spec)
At 400kbit/sec that is 120us of data bit transfer time.
There is more overhead.
(The actual time for lcd.write() for 400k i2C will *always* be longer than 120uS)
I believe that you can speed up i2c quite a bit but I believe that by default that the Arduino wire library
sets it to 400k/sec.
lcd.write() using an optimized 2wire implementation (not using the Arduino core teams shiftout() function)
can update the LCD in 76uS on AVR and 50us on pic32 Arduino (I have this working today).
And that is everything including strobing E and the needed blind wait.
That is the measured time of the full lcd.write() API call and returning back to the sketch.
For actual LCD commands the ascync serial interface can get slower depending on the async serial lcd backpack
Async devices typically accept data as characters so to write a character to the display you simply
send the character.
For commands, some devices use control codes and some and need a escape code to issue a command.
For those devices that use an escape code, the latency doubles (potentially 4x for cursor positioning)
over the character write time since it takes extra bytes to perform the commands.
In the grand scheme of things it doesn't much matter.
All the devices and interface are usually fast enough for the application.