Again, I am going to disagree here.
I have real world experience and math that I believe proves otherwise.
And so have I and I believe you are wrong.
I don't buy into what you wrote, you are misunderstanding things.
Anyway it is all a bit academic, you go with your solution and I will continue to build stuff with mine.
Grumpy_Mike:
Again, I am going to disagree here.
I have real world experience and math that I believe proves otherwise.And so have I and I believe you are wrong.
I don't buy into what you wrote, you are misunderstanding things.
Anyway it is all a bit academic, you go with your solution and I will continue to build stuff with mine.
Maybe this was misinterpreted:
No other low wire count interface is this easy to make for a DIY project.
What I meant was:
No other low wire count interface is this easy to use for building a DIY lcd backpack.
Perhaps that threw things in the ditch.
If so, Ignore the rest of this post.
If not......
--- bill
Remember my original comment was that building a DIY 2 wire SR register lcd backpack implementation
is cheaper, simpler, and depending the library, can be faster updating the display
than 115200 baud async serial or i2c in 400k/sec mode when using a LiquidCrystal compatible API.
So here are some facts:
A 74hc595 Serial chip can be purchased for 20 cents QTY 1 (how much is an i2c i/o expander chip QTY 1?)
A working 2wire SR lcd backpack can be built for under $1 with QTY 1 prices from tayda including 70 cents for a strip board.
(as low as 42 cents each if you build 4 backpacks from the single 70 cent strip board)
The time it takes the LCD to process a data write or a simple command is not more than 37us.
All apl calls but home() and clear() in the LiquidCrystal API use simple/fast commands (< 37 us)
The LCD cannot start processing data/cmd until it receives the data/cmd on the hd44780 interface.
The LCD cannot be updated faster than it can receive data/cmd(s) on the hd44780 interface.
The total time to update the display can not be shorter than either the transfer time or LCD processing time.
If the transfer time is longer than the LCD processing time, then LCD updates cannot occur faster than the transfer time.
Transfer time can be "hidden" under the LCD processing time when it is shorter than the processing time.
(This only applies to back to back data/cmd(s))
-It takes 87uS just to transmit a byte at 115200 baud, so the LCD cannot be updated faster than
87uS with asynchronous serial as the interface no matter what is handling the serial to hd44780 conversion
even if all the other overhead is zero, which it isn't.
When using 4 bit mode, the hd44780 interface cannot be strobed for the next first nibble for a new data/cmd
until the previous data/command has been fully processed.
A 2 wire SR interface can send a nibble to the hd44780 interface in 24uS.
The above 24uS can potentially "hide" under the 37uS processing time of a previous data/cmd.
a 3wire SR interface can transfer data faster to the hd44780 interface than a 2 wire SR interface.
a 3wire interface could transfer a full byte to the hd44780 interface in about 15us.
(when running the hd44780 interface in 8 bit mode vs 4 bit mode)
The above 15uS can potentially "hide" under the 37uS processing time of a previous data/cmd
I'll further and present a few actual logic analyzer traces in support of the timing numbers.
In the first picture, you can see the time it takes to transmit a byte using asynchronous serial at 115200.
It shows up as 85uS which is within 2% of the calculated 87us theoretical data bit rate.
The rest of the captures are based on capturing 2 back to back data writes
using a HC595 run with two wires with the hd44780 interface in 4bit mode.85
When using two wires on a shift register, it has to be zeroed first then the nibble with
control data can be sent.
You can see the 4 enable strobes (2 enables for each nibble) of the two bytes.
You can also see two clock bursts for each nibble strobe. The first burst is the
zero, followed by the nibble data and control bits.
Here is a brief desription of each capture: (see time between T1 and T2)
Based on those numbers you can see that back to back data writes could be as fast as
125.8uS/2 or 62.9uS.
The measured 76uS data write xfer time I mentioned before is the measured time
of a single lcd.write() through all the software
(which is why it is higher than the 62.9uS low level SR/hd44780 timing)
It sends the data to the hd44780 interface but the low level code
does not wait for the write to finish as it only needs to wait long enough to ensure
that another immediate data/write will not violate the 37us data/cmd timing.
However, since the small blind wait is enough to ensure that that the transfer time +
the blind wait is 37us, then each lcd.write() will always be the same amount of time.
The reason that the lcd.write() time is not 37uS is that while it
is possible to hide some of overhead like the transfer time it is not possible to hide all
the overhead underneath the data/command processing time, with my current
library.
Note: I'm working on an implementation, where all the overhead not just
the transfer time can potentially be hidden under the 37uS timing so the
back to back time will be 37 uS or the total overhead (transfer + s/w)
whichever is longer.
Grumpy Mike,
If you have a source for less than 20 cent i2c i/o expanders I'd love to get some.
Also, if you have analyzer shots of the hd44780 interface driven by an i2c i/o expander, I'd
love to see the timing to see how an i2c implementation compares to a 2 wire SR
implementation.
If you want, I can even PM you a sketch that will report the byte transfer time in uS on the LCD display
using the lcd.write() api call of the LiquidCrystal API.
(It can run on any LCD interface that uses the LiquidCrystal API)
That timing in itself is quite useful as it indicates the true end to end
data transfer time as seen to the sketch, which is all that really matters when it comes
to updating the LCD display.
--- bill
Just a final follow up.
Here are actual numbers measured using real hardware for different ways
of talking to a hd44780 LCD and updating the LCD display.
Interface ByteXfer 16x2FPS Ftime
----------------------------------------------
4BIT 338uS 86.92 11.51ms (original Liquid Crystal library)
4BIT 98uS 298.58 3.35ms
SR2W 76uS 388.62 2.57ms
SR_2W 72uS 406.90 2.46ms
SR_3W 61uS 480.03 2.08ms
SR3W 102uS 287.92 3.47ms
I2C 957uS 30.74 32.25ms
ByteXfer is the time it takes to get a character updated to the LCD.
The FPS (frames per second) are the number of times a 16x2 display can be updated per second.
Ftime is the amount of time it takes to fully update a 16x2 display.
updates to the LCD were done using a 16Mhz AVR, using fm's LiquidCrystal replacement
library https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home and the
LCDiSpeed sketch that is included in the examples.
A "frame" udpate is:
set cursor to 0,0
write 16 characters
set cursor to 1,0
write 16 characters.
You can see the times for each interface and can clearly see that
the speed of the interface getting to the hd44780 LCD interface does matter.
It is the limiting factor of how fast the LCD can be updated.
The replacement LiquidCrystal library is about 3.5 times faster than the original
when using 4bit mode and using individual wires as in the OP that started this thread.
You can also see that an i2c interface using a pcf8574 can update a 16x2 display about 30 times
per second while a shift register can update a 16x2 display 400 to 500 times per second
depending on two wire or 3 wire modes.
Is the extra speed needed? maybe not, but clearly a shift register is much faster at
updating the LCD display than i2c.
As far as code size goes. The shift register also uses less code.
The final sketch using i2c was 834 bytes larger than when using
a shift register in 2 wire mode and 858 bytes larger than when
using a shift register in 3 wire mode.
So overall, using a shift register to talk to a hd44780 LCD interface is:
than using a pcf8574 i2c i/o expander.
--- bill
Just to corroborate Bill's figure, here is a scope capture of a write I2C transaction.
Setup:
Full transaction, physically takes 924us, additional software overhead for interrupt management routing and time stamping.
I2CTransaction_character write.bmp (146 KB)
pls send me a schematic or link thet i found for SR_3W 61uS 480.03 2.08ms
thx
Or forget about all the goofy libraries and programming.
Unified Microsystems ATS-1 shield uses digital pins D0 and D1 which are used for serial communication.
http://www.unifiedmicro.com/ats1-arduino-shield.html
or available on Tindie.com:
Just plug it in and don't use ANY open digital pins.
JD3:
Or forget about all the goofy libraries and programming.
Unified Microsystems ATS-1 shield uses digital pins D0 and D1 which are used for serial communication.Arduino ATS-1 Terminal Shield | Unified Microsystems
or available on Tindie.com:
https://tindie.com/shops/garysxt/lcd-terminal-shield-for-arduino-model-ats-1/
Just plug it in and don't use ANY open digital pins.
"Goofy libraries and programming"????? Hm......
I guess your idea of "goofy" and "programming" are different than mine.
I consider a LCD with a LiquidCrystal library to be very attractive and much less work to use than trying
to write sketch code to use a proprietary interface.
When a device has a LiquidCrystal compatible library, all the LiquidCrystal examples and 3rd party code
will "just work" with the devices library.
Yes there may be a slight tweak that has to be done to get the constructor correct but that is a one time thing
and does not affect any of the actual sketch code.
The ats-1 LCD solution uses the hardware serial pins, it is proprietary with no LiquidCrystal compatible library.
So the user will either have to write their own LiquidCrystal compatible library or send proprietary character
sequences to the device to control it.
It also means none of the existing lcd example sketches out there or 3rd party code that uses the LiquidCrystal
library API will work with it and will require a considerable amount of re-programming to get
an existing LiquidCrystal sketche to work with the ats-1.
Intelligent devices with "smart" interfaces are a mixed blessing.
While they often do some things for you like beep a buzzer or light an led,
often they don't implement the full capabilities of the LCD as is the case for this one.
For example, I see no way to use the the LCD "scroll" (pan) modes or the ability to define custom characters.
While many people don't use the scroll/pan modes, many do use custom characters.
The major draw back to intelligent devices is that not only do they tend cost more than the simpler (dumb devices)
but when the device does not implement needed functionality or has an issue, there is typically
no way for the user to correct it or update it.
Just my opinion but I consider that board pretty expensive given its limited functionality, missing capabilities, and its speed.
At 4800 baud it will take around 40ms to paint a 16x2 screen whereas even i2c can do it in 32ms.
(at 40ms it would be a more than 15x slower than the 2 wire shift register solution)
It doesn't seem to support automatic line wrapping or vertical scrolling - which some other intelligent serial based shields in this price range or lower have
It doesn't support large font text or numbers which other intelligent shields or LCD backpacks support.
It doesn't have the ability to control the contrast from the serial interface like many other intelligent boards have
It doesn't have the ability to control the backlight or backlight brightness from the serial interface like many other intelligent boards have
It runs a slow baud rate and does not seem to have the ability to change it.
It is missing the ability to define custom characters,
It is missing LCD pan/scroll modes.
In terms of LCD support using a ready made backpack, for the money, i2c (PCF8574) based backpacks are a very good value.
They are not as fast as a Shift Register implementation, but can be had for as little as 1/10 the cost of the ATS1,
i2c will be a bit faster than the ATS1 at 4800 baud.
i2c offers more LCD functionality (full LCD functionality), and a LiquidCrystal API compatible library is already available.
Most of the PCF8574 based backpacks out there also support backlight control (on/off).
--- bill
To Bill - I get that you know what you are talking about.
That said, I wasn't asking for a long winded product review. I was just giving an option to the original poster.
