enjoyneering:
try to use my library. it's much faster than others - GitHub - enjoyneering/LiquidCrystal_I2C: This is an Arduino library for HD44780 LCD display, operated in 4 bit mode over I2C bus with 8-bit I/O expander PCF8574
It isn't faster from what I've seen.
From my testing your library is quite a bit slower than others.
When using a 16Mhz AVR board like an UNO and the default 100kHz i2c clock:
The IDE bundled LiquidCrystal_I2C library v1.1.2 transfers a byte to the LCD display in 1455us
My hd44780 library v0.9.4 (hd44780_I2Cexp i/o class) transfers a byte to the LCD display in 549us
You LiquidCrystal_I2C library v1.2.0 transfers a byte to the LCD display in 7381us
Your library is 5x slower than the IDE bundled LiquidCrystal_I2C library
and is a bit over 13x slower than my hd44780 library using the hd44780_I2Cexp i/o class.
That is quite a bit slower than other libraries.
--- bill
Wow. You've made quite a library. Challenge accepted. 
I'll try to make my faster.
Haven't you guys heard about 'alternative facts'?
Don
floresta:
Haven't you guys heard about 'alternative facts'?
Sure. Not sure I understand the reference here.
Perhaps a reference to the claim made in post #19 that was obviously false.....
--- bill
Tweaked my library. Time to transfers a byte to the LCD:
-
my LiquidCrystal_I2C v1.2.1 does it in 1088us, ATmega328 16MHz, i2c 100KHz
902us, STM32 72MHz, i2c 100KHz
854us, ESP8266 80MHz, i2c 100KHz
-
Bill's hd44780 v0.9.4 552us, ATmega328 16MHz, i2c 100KHz
But my code uses less global memory 436 bytes vs 477 bytes.
I've used my sketch SpeedTest.ino to test both libraries
So far my library 1.3x times faster than IDE bundled LiquidCrystal_I2C library v1.1.2, but still 1.97x times slower then Bill's.
I have not yet gave-up. Stay tuned.
Hi,
Manged to get 1056us from LiquidCrystal_I2C v1.2.2 , ATmega328 16MHz, i2c 100KHz
Bill's hd44780 v1.0.0 ~500us, ATmega328 16MHz, i2c 100KHz
But my code uses 5010 byte of storage & 456 bytes of dynamic memory.
Bill's code uses 6924 byte of storage & 540 bytes dynamic memory.
I've used my sketch SpeedTest.ino to test both libraries.
Hi.
The further speed improving uses a lot of memory. So I decided to stop. Bill won. His memory monster is the fastest.
enjoyneering:
Hi.
The further speed improving uses a lot of memory. So I decided to stop. Bill won. His memory monster is the fastest.
Just as an FYI, the hd44780 library and i/o classes have not been optimized yet.
I have looked closely enough to know know of many areas that can be optimized but wanted to wait until after the 1.0 release.
Two main things cause the hd44780_I2Cexp code to be larger than other implementations. Auto detection and virtual functions.
The recent versions of the gnu compiler removed the ability to have the linker remove virtual functions that are never referenced.
I know how to work around this but it is a big effort.
This will reduce the code by about 1.5 to 1.8k for simple/small sketches that don't reference some of the more advanced capabilities such as reads from the LCD.
virtual functions also consume RAM. That RAM will also be freed up in the new library design.
My plan is to put this in a future 2.x release that uses C++ templates rather than C++ virtual functions to avoid the virtual function overhead.
Once that is done, the hd44780 code will be smaller and faster and use less RAM than it currently does so its flash and RAM usage should be closer to other implementations. And if not using auto detection, it should be close to parity.
--- bill