I think it might be useful to restate my problem.
I am looking for device-level specifications on the I2C interface to the DFR0154 LCD.
I do not use any Arduino technology. I wish to interface the LCD to a Microchip controller.
I would like to know the device-level message protocol that allows the DFR1054 to distinguish between commands (move cursor, clear display, etc) and data to be displayed.
To explain, I also have a DFR0556 (1602 LCD in green). Its message protocol is specified in the AiP31068 LCD Driver Specification (version 2013-03-A3). To distinguish between sending a command and sending display data, the AiP31068 requires a “control byte” to be inserted in the I2C message between the device address and any data being sent. Bit 6 of the Control Byte mimics the RS (Register Select) signal of the ubiquitous HD44780 LCD chip. For commands, RS = 0; for display data, RS = 1.
I have been unable to find a similar protocol definition for the DFR0154. The DF Robot website gives the datasheets for the HD44780 and the PCA8574 Expander chip. From my reading, these do not explain what has to be sent over the I2C interface to distinguish between transmission of commands and data. I have read (many!) Arduino code samples, but these are always written at the function level, not the device level.
I have tried a number of alternate message formats and so far the LCD does not display anything. The LCD acknowledges all I2C messages properly, but there is no indication that the LCD is processing the messages sent to it. Interestingly, I can send the DDRAM Set Command to the LCD followed by a read of the device. The DDRAM address returned by the LCD appears to be correct.
So, could someone tell me the contents and order of bytes (the actual 1s and 0s – not a function call) that have to be sent to the DFR0154 to accomplish the following tasks:
- Move the cursor one place to the right, ie. a command message.
- Display “Mary had a big lamb” on the display, ie. a data display message.
CRO waveforms showing SDA and SCL would be equally useful.
From this, I should be able to reverse engineer the DFR1054 I2C message protocol.
Any help is gratefully received.