{"id":130,"date":"2013-02-15T00:19:32","date_gmt":"2013-02-15T00:19:32","guid":{"rendered":"http:\/\/richardalbritton.wordpress.com\/?p=130"},"modified":"2015-01-16T00:14:07","modified_gmt":"2015-01-16T00:14:07","slug":"130","status":"publish","type":"post","link":"https:\/\/www.richa1.com\/RichardAlbritton\/130\/","title":{"rendered":"I2C protocol for LED matrix"},"content":{"rendered":"

Wow this will come in handy when I get around to configuring the Imp to send I2C\u00a0commands\u00a0to the Adafruit 8×8 LED matrix backpack. Hopefully I can map the LED addresses\u00a0easily\u00a0so I can make an icon library to drive the matrix.<\/p>\n

From Philip Hazelden<\/a>:<\/p>\n

using an Adafruit LED Matrix with the Raspberry Pi<\/a><\/p>\n

Adafruit sells an\u00a08×8 LED matrix<\/a>\u00a0which you can control from a Raspberry Pi using I2C. Unfortunately they only provide Arduino code; I’ve only used I2C through the programs\u00a0i2cset<\/code>,\u00a0i2cget<\/code>,\u00a0i2cdump<\/code>\u00a0and\u00a0i2cdetect<\/code>available from the\u00a0i2c-tools<\/code>\u00a0package; and it wasn’t immediately obvious how to use Adafruit’s code to control the matrix from the Pi.<\/p>\n

Fortunately, it turns out to be quite simple.\u00a0i2c-tools<\/code>\u00a0seems to assume a register-based model of I2C devices, where the target device has up to 256 pointers which can be read and written. This doesn’t seem to suit the HT16K33 chip (datasheet<\/a>) that the matrix backpack uses. For example, when I ran\u00a0i2cdump<\/code>, which gets the value of each register, it started to blink a picture at me. At least I knew it was working.<\/p>\n

Setting individual LEDs works much as you might expect. Every row has a single register, the eight bits of that register correspond to the eight LEDs on a row. (It’s not 100% intuitive. If you label the LEDs 0 through 7 from left to right, and the bits 0 through 7 from LSB to MSB, then bit n corresponds to LED n+1 mod 8.) The registers in question are\u00a00x00<\/code>,\u00a00x02<\/code>, …,\u00a00x0e<\/code>. Registers\u00a00x01<\/code>,\u00a00x03<\/code>, etc. seem to correspond to other LED rows that don’t exist on this matrix, but presumably do on the\u00a0bicolour version<\/a>.<\/p>\n

So to turn on the top-left pin for example, run\u00a0i2cset -y 0 $ADDRESS 0x00 0x80<\/code>. (By default, the address of the device is\u00a00x70<\/code>. This can be set up to\u00a00x73<\/code>\u00a0using two address-set pins, but I’m not sure how to use these. Each pin seems to be a pair of conductive plates close to each other on the backpack. My guess is connecting these will turn the pin on, but I’m not sure if there’s a standard thing I’m meant to connect them with.)<\/p>\n

But you can also turn the whole matrix on\/off, set blink rate, and set brightness. Each of these commands also corresponds to a register, but not in the same way. Interacting with the register in any way will run a command. For example, register\u00a00xe0<\/code>\u00a0is “turn brightness all the way down”, so any of the following will do that:<\/p>\n

i2cget -y 0 $ADDRESS 0xe0\r\ni2cset -y 0 $ADDRESS 0xe0\r\ni2cset -y 0 $ADDRESS 0xe0 $val # for any legal $val, e.g. 0x00, 0xff\r\n<\/code><\/pre>\n
Similarly,\u00a00x87<\/code>\u00a0is the “turn display on and blink at 0.5 Hz” register, and is the highest-address register of that nature. So running\u00a0i2cdump<\/code>\u00a0will cycle through all combinations of on\/off and blink modes, and finish on that one.<\/p>\n
Here are the registers that I’ve found that I care about (except the LED registers):<\/p>\n