you can dispense with the begin() statement if you have the size display it assumes.
Speed testingAll of the interface modes go faster than the eye can follow. This version of the software is significantly slower than previous versions when using timed delays. I found an LCD (Axman) that needed longer delays and in the interests of making the code foolproof, I lengthened the delays to make that LCD work. However Paul Stoffregen has significantly speeded up the code when testing the busy flag and so those options run significantly faster than before. I compared the speeds of the different interfaces--writing 80 characters to the screen then 80 blanks and looping through that 20 times. The results on a Mega are:Axman 4 data pins no RW 1349 milliseconds | nonAxman 1349Axman 4 data pins + RW 565 milliseconds | nonAxman 468Axman 8 data pins no RW 1314 milliseconds | nonAxman 1314Axman 8 data pins + RW 520 milliseconds | nonAxman 500Axman 4 pins + user busy 369 milliseconds | nonAxman 316I also have a Teensy++2.0 board. One of the interesting things about that board is that the software that comes with it includes considerable optimization of digitalRead, digitalWrite etc. The board runs at 16 megaHz, just like the Mega, but speeding up those commands results in an impressive change in the benchmarks:Axman 4 data pins no RW 1207 milliseconds | nonAxman 1207Axman 4 data pins + RW 327 milliseconds | nonAxman 219Axman 8 data pins no RW 1212 milliseconds | nonAxman 1212Axman 8 data pins + RW 361 milliseconds | nonAxman 296Axman 4 pins + user busy 241 milliseconds | nonAxman 189
1 usec is adequate there.
nice work! I have only quickly looked at the code. The standard LiquidCrystal initializes the display when you declare the LiquidCrystal object; you can dispense with the begin() statement if you have the size display it assumes. I don't see that in your code.
Current lines of activity: - backlight support - under consideration. - making the I2C be more generic by having a similar design as the LCD, i.e. a control "layer" and an "access" layer, i.e. the IO expansion chip. - improve documentation - SPI LiquidCrystal support - Serial support - under consideration since they tend to be more - make it usable to other platforms.
Well, it is interesting that the LIquidCrystal library did not follow the API recommendations in the LCD API:
1. Remove the IO remaping from imput to output on every single 4/8 bit write transaction.Since there is no part in the code that reads from the LCD, you simply configure the IOs during initialization and then simply write.