floresta:
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.
While it may be a bit simpler, I don't think it really makes programming a lot simpler.
Running in 4 bit mode, and having to share the output port between the 4 data lines
and the control lines and baclight control is not that difficult.
The MCP23017/MCP23008 will have more i2c overhead than the PCF8574.
This is because those chips are more flexible.
Because of that flexibility, they have control/configuration registers.
Because of these registers,
the first byte transfered always to the chip goes to the address pointer to select which register
you really wanted to write.
This address register normally increments after every write.
You can put the MCP chips into BYTE mode which disables this increment.
This allows writing to the OLAT register with back to back writes to the chip
the way the PCF8574 works.
However, even if you put the chip into BYTE mode, you still have to send an
extra byte to the chip each transmission to initially select the OLAT register.
So I don't think using a MCP23017 in 8 bit mode would be faster than using a PCF8574
in 4 bit mode.
ex:
4 bit PCF8574 to transfer a byte/command to LCD:
- start
- data byte: 4 bit LCD data/control E high
- date byte: 4 bit LCD data/control E low
- data byte: 4 bit LCD data/control E high
- data byte: 4 bit LCD data/control E low
- end
4 bit mode MCP23008 in BYTE mode:
- start
- data byte: 0x0A to point to OLAT
- data byte: 4 bit LCD data/control E high
- date byte: 4 bit LCD data/control E low
- data byte: 4 bit LCD data/control E high
- data byte: 4 bit LCD data/control E low
- end
8 bit mode PCF23017 in bank = 1, BYTE mode:
- start
- data byte: 0x0A to point to OLATA
- data byte: LCD data byte
- end
- start
- data byte: 0x1A to point to OLATB
- date byte: LCD control byte with E high
- date byte: LCD control byte with E low
-end
Oddly enough, while counter intuitive,
it looks like 4 bit mode on a MCP23008 will be faster
than 8 bit mode on the MCP23017. But both MCP chips will be slower
than the PCF8574 because there is simply more i2c overhead with those
chips.
One thing that could really speed things up on the MCP chips would be to bump
the speed of the i2c bus up since those chips can handle 1.7Mhz clock rates vs
the standard/default 100kHz.
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.
In fm's NewLiquidCrystal library, the byte/command delays are inside the interface layers themselves and do
take into consideration the interface transfer time as well as the actual time
of the LCD library code as well.
So for example on i2c there is no added delay between LCD data byte transfers.
Because of the optimizations already in place, the only area left to optimize for LCD data transfers
for i2c, is the time to get the control and data information to the LCD.
The times I quoted are not actual byte transfer times but an averaged and normalized
effective byte transfer time based on updating the full display. This time includes
all the overhead to get from the sketch through the LCD code, over the i2c bus and
to the LCD.
Eliminating extra i2c starts/stops and extra byte transfers is actually pretty significant
as you can see from the 16x2 frame rate numbers.
It goes from 31 to 54 FPS on the PCF8574.
Just having to do the send for the extra byte for the address register on the MCP23008 drops the 54FPS to 45FPS.
--- bill