Our Raspberry Pi friends will know the Building a Low Power Compact LCD Display project that shabaz published a while ago. He designed a £5 LCD module and the source code for Raspberry Pi.
|
What data is flowing according to the code?
Our code tries to send 9 bytes.
- 1: the 7-bit I2C address + read/write bit
- 2 - 6: config and commands
- 7 - 9: data for the segments and dots
#define LCD_ADDR 0x38 // ... // Commands (these can be 'continued' by setting the MSB #define DEVICE_ADDR 0x62 #define BLINK_OFF 0x70 #define BANK_CMD 0x78 // BANK_CMD bit values #define WR_BANK_A 0x00 #define WR_BANK_B 0x02 #define DISP_BANK_A 0x00 #define DISP_BANK_B 0x01 // ... unsigned char mode, device, bank, blinkmode; mode=0xc9; // Set static mode, display enabled, continuation enabled device=DEVICE_ADDR | 0x80; // Select the device, continuation enabled bank=BANK_CMD | 0x80 | WR_BANK_A | DISP_BANK_A; blinkmode=BLINK_OFF | 0x80; buf[0]=mode; buf[1]=device; buf[2]=blinkmode; buf[3]=bank; buf[4]=0x00; // pointer buf[5]=progval->byte0; buf[6]=progval->byte1; buf[7]=progval->byte2;
What's really flowing to the LCD Controller
These two captures are the result of sending ' . . ' and ' 0.0' to the display:
Everything looks as expected. On the odd lines from 3 to 17 we find exactly what's defined in the code.
Line 3 in the screen captures, with value 0xc9, is exactly what's assigned to buf[0]in the code.
mode=0xc9; // Set static mode, display enabled, continuation enabled //... buf[0]=mode;
The only thing that may need some more clarification is the I2C address, on line 1.
We've set it to 0x38, but in the transfers there is 0x70.
That's part of the I2C protocol.
The address isn't 8 bit, but 7 bit.
That 7 bit value is appended with a read/write bit. 1 if we're reading, 0 if we're writing.
Because we're writing to the LCD, we append the address with a 0.
The value 0x38 left shifted and with the last bit set to 0 equals 0x70.
