Hi, I can see everywhere that those LCD I2C adapter with PCF8574T chip can be used to run 4 bits with only 2 signal connections SDA and SCL pins.
Can anyone advise me if those LCD I2C adapter with PCF8574T chip can run 8 bits too with the same 2 connections on SDA and SCL pins? Or they do need another extra 4 cables from Arduino Uno or Leonardo?
Do you have any suggestions which type of chip or adapter that can run 8 bits?
Thanks.
The PCF8574T has only 8 I/O pins so it cannot be used to connect an LCD in the 8-bit mode since you need at least two more I/O pins.
The MCP23017 chip has two sets of 8-bit I/O ports so an adapter using that chip could do the job with the proper library. Check out I2C LCD Interface v3 - Assembled [SPL-002101] - $15.75 : SpikenzieLabs, Great electronics kits . There's also a kit version available.
Why do you want to use 8-bits?
Don
From the post it isn't clear if the desire is to run the LCD in 8 bit mode or whether it is to control 8 bits (pins) as in use the backpack as an generic 8 bit i/o expander rather than to control an lcd.
In terms of using an i/o expander to control the LCD in 8 bit mode, there really wouldn’t be much of a reason to do so.
The MCP series i2c i/o expanders has more i2c overhead than the PCF8574 since you have to send it the register # before sending it the data.
So while you could run the LCD in 8 bit mode using a MCP23017, the total number of bytes transferred across the i2c bus ends up being more than with the PCF8574 when the PCF8574 runs the LCD in 4 bit mode.
This is what you would send with the MCP23017, assuming you put the device into byte mode with bank mode=0 which would be the most efficient for this purpose.
MCP23017: [0x12] [data-byte] [control-byte] [data-byte] [control-byte]
PCF8574: [high nibble with EN high] [high-nibble EN low] [low-nibble with EN HIGH] [ low-nibble with EN low]
LCD in 8 bit mode requires sending 5 bytes across i2c to send a byte to the LCD
LCD in 4 bit mode requires sending 4 bytes across i2c to send a byte to the LCD.
When using the MCP23017 you end up having to send the full 8 bits twice as that is the most efficient way to alter the control byte pin outputs (it avoids having to go through another i2c bus arbitration and send the register number again).
So while 8 bit mode on the LCD can potentially be faster than 4 bit mode, when using i2c expanders like PCF8474 vs the MCP23017, 8 bit mode will be slower because you have to transfer more bytes across the i2c bus to run the lcd in 8 bit mode than to run it in 4 bit mode using a PCF8574.
--- bill
I have never used a MCP23017. But from the data sheet, you seem to be able to disable the SEQOP bit in IOCON.
Then having addressed a register, you should be able to write data continually to the same register. i.e. much like the PCF8574.
Untested.
I must admit. I can't see much point in using 8-bit on an LCD. You can't read an LCD very fast anyway.
David.
david_prentice:
I have never used a MCP23017. But from the data sheet, you seem to be able to disable the SEQOP bit in IOCON.Then having addressed a register, you should be able to write data continually to the same register. i.e. much like the PCF8574.
David.
That is "byte mode" that I was talking about earlier.
The transfers and the example I showed earlier was taking advantage of that capability.
But an MCP chip in byte mode doesn't work quite like the way the PCF8574 works.
You still have to send a register address as the first byte of data transfer to the chip after establishing a connection, to tell it what register to write to for all the remaining bytes transferred in that i2c connection.
(i.e. after each i2c start followed by the i2c address of the chip you must transfer a byte to indicate the register where the i/o operation is to start accessing)
In order to run in the optimum mode you would use byte mode and set bank mode to 0 which allows bytes to write to GPIOA then GPIOB, then back to GPIOA, etc... (after telling it to start at GPIOA)
I was assuming the 8 LCD data lines connected to GPA and the control signals like E and backlight to GPB so that the data bits get set before the control bits get set when doing back to back byte write transfers so that you can set the data signals for the LCD before altering the E signal.
So in byte mode along with bank mode = 0, the first byte sent would be 0x12 to point to GPIOA, then the next bytes would be:
[LCD data byte], [PORTB ctl data to raise E], [LCD data byte again], [PORTB ctl data to lower E]
For a total of 5 bytes across the I2C to send a single byte to the LCD.
Whereas, when using a PCF8574 with the LCD in 4 bit mode you only have to transfer 4 bytes.
I use byte mode on the MCP23008 in my latest hd44780 i/o expander library and while it does make the chips work similar to a PCF8574 there will always be more overhead on the MCP chips for this type of application since you have send the register address before sending the data bytes.
One saving grace for an application like this is that if your wiring allows it, and you don't have any other slow devices on the bus, you can crank up the speed to a higher rate than the PCF8574 to make of the added data transfer overhead.
However, if you bump the clock rate up you now start reduce the transfer overhead enough that you can't depend on the slowness of the i2c transfer to hide the execution time of the LCD commands and must deal with it on the host side.
Note: it is probably possible to flip the port usage around such that the LCD control signals were on GPA and the data were on GPB in which case you would then send:
[0x12] [ctl] [data] [ctl]
For a total of 4 bytes instead of 5.
Then it would at least be a wash with the PCF8574 in 4 bit mode.
Still not a win for using 8 bit mode.
--- bill
From the post it isn't clear if the desire is to run the LCD in 8 bit mode or whether it is to control 8 bits (pins) as in use the backpack as an generic 8 bit i/o expander rather than to control an lcd.
The title implies controlling an LCD.
I have to admit that I don't often read or remember what's in the title once I have opened the thread.
Don
WOW, thank you floresta for answering so fast. Thanks bperrybap for so much details.