Garbled LCD screens

[printbus]

On to the i2c or i^2c stuff. For the unfamiliar reader, a simple overview first.

The larger Atmel AVR microcontrollers support a serial transfer over what Atmel calls the two-wire interface, or TWI. You can read about TWI in the AVR ATMEGA datasheet of your choosing. This is compatible with the Inter-Integrated Circuit (i2c or i^2c) interface. Read about THAT on wiki or other resource. It's a slick interface that allows support chips to interface with a microcontroller through serial data transfers and device addressing. Communication only requires a couple of pins, and addressing means you share the same signal pins for multiple devices. The Arduino world took this a step farther. The Wire library allows you to perform i2c communication but without committing to having or using the TWI function in the ATMEGA chip, albeit with a substantial amount of software overhead.

Functionally, there's no reason why you couldn't use TWI/i2c for the LCD interface. In fact, there are i2c "LCD backpacks" from sources like Adafruit and Sparkfun that solder directly onto the pins of the LCD module and turn it into an i2c node. The one's I've seen of these still require you to use the LCD in 4-bit mode. Why? The i2c adapters use a shift register chip that decodes the serial data stream into the parallel lines needed to drive the display. This chip can only accept a number of bits at a time. In addition to data lines, the RS signal, E signal, and usually a backlight on/off signal have to be sent. There aren't enough shift register bits to send 8 bits of data, so only 4 get sent. RS and E aren't passed over discrete wires subject to noise and static, so maybe this is still an improvement with regards to the garbled display issue with nibbles getting out of sync. I don't know.

Personally, however, I think it is hard to have an LCD interface that is efficient over i2c, and incredibly so with the Arduino library if it is used. Remember that we need to be setting data lines and toggling RS and E pins to send data and commands to the display. The flexible bit-bang nature of Arduino means everything is being done in software (ie, the ATMEGA TWI hardware isn't used), and there's also i2c overhead involved in setting up each transfer. Send an i2c command to confirm the bus is available. Send i2c commands to address a specific device and set up a data transfer with it. Send four of the display data bits with RS set to the desired level and E not asserted. Resend the same data bits but with E now asserted. Resend the data bits but now toggle E back to inactive. Send the next four data bits with E de-asserted. Send them again with E asserted. Again with E now toggled off. This is coming from dated memory and might not be totally correct, but this should convey a sense of the number of transfers required to send simple messages to the display. BTW, then when done with the transfer, send an i2c command to relinquish the i2c bus. And if I recall my dated research into the Arduino Wire library, acquisition of the i2c bus and addressing a device occurs on every byte or display character sent over the Wire library. Keep in mind that software is dealing with all this one serial bit at a time. Yes, one bit at a time. Very inefficient from a software overhead perspective. I've never used the Wire library, but I've read how this leads to a really slow update for anything but the smallest size display.

FOLLOWUP COMMENT: To be fair, not all of my concerns are with the Arduino Wire library. The software-intensive effort in handling i2c is exasperated by the need to toggle control pins on the LCD display - that's driven by the nature of the LCD modules, not the Wire library. After knocking the dust off more brain cells, I also now remember that the i2c bus acquisition on every character was something done in sample software provided by AdaFruit for their i2c LCD backpack board. The Wire library wouldn't likely require every byte to be handled individually.