Could one of you explain why it is so important to speed up the byte transfer speed when you then have to wait a much longer time for the device to be ready for the next piece of information?Couldn't you simply subtract the extra time the I2C implementation takes from the delay times that you insert between the bytes that you send to the LCD controller?
You could look into using the MCP23017 I/O expander. Use one 8-bit port for an 8-bit LCD interface and the other to implement the RS, RW, and E. This makes the programming a lot simpler and you can implement more than one E pin to run several LCDs if you wish. It would also get rid of half of your overhead.
Could one of you explain why it is so important to speed up the byte transfer speed when you then have to wait a much longer time for the device to be ready for the next piece of information?Couldn't you simply subtract the extra time the I2C implementation takes from the delay times that you insert between the bytes that you send to the LCD controller? That would take care of half the problem with the single-port I2C devices and all of the problem with the two-port devices.
Interesting. I thought about trying that to see if worked.but since it is way beyond the specs on the datasheets I've seen, I never actually tried it.I wonder how stable it is, particularly with multiple devices on bus.
All the datasheets that I've been able to find (TI, Philips, & NXP) show 100khz as maxwhich is probably for the max for the lower voltages.I'm curious which manufactures were you able to find that show 400khz?
31 fps == 33 millis/char53 fps == 19 millis/char130 fps == 7.7 millis/char
* - Single byte transfer speed (ByteXfer) * This is the time it takes for a single character to be sent from * the sketch to the LCD display. * * - Frame/Sec (FPS) * This is the number of times the full display can be updated * in one second. * * - Frame Time (Ftime) * This is the amount of time it takes to update the full LCD display. * * The sketch will also report "independent" FPS and Ftime values. * These are timing values that are independent of the size of the LCD under test. * Currently they represent the timing for a 16x2 LCD * The value of always having numbers for a 16x2 display * is that these numbers can be compared to each other since they are * independent of the size of the actual LCD display that is running the test. * i.e. you also get 16x2 timing information even if the display is not 16x2 * * All times & rates are measured and calculated from what a sketch "sees" * using the LiquidCrystal API. * It includes any/all s/w overhead including the time to go through the * Arduino Print class and LCD library. * The actual low level hardware times are obviously lower.
Good work kowalski, an interesting thread.Although I think no one will use 130 frames per second on a character based display. I would prefer to think of this optimization as minimizing the average time per char...Faster times means more time to make measurements and to do math.Note the recent divmod10() optimization discussion which decreased the time to print numbers substantially - http://forum.arduino.cc/index.php?topic=167414.0 - As the print.cpp class is the base class for lcd.print combining these efforts could be very interesting.For graphics displays the increased performance is evident.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16