Pimoroni ScrollPhat using Adafruit IS31FL3731 Library

December 29, 2018 at 11:08 pm (computers) (, , , , , , )

I finally got myself a genuine Adafruit IS31FL3731 driver board and LED matrix (that I mentioned in a previous post) and glued an Arduino Nano on the back, thus creating a very neat little self-contained USB-driven 16×9 matrix of surface mount LEDs, which is great.

This uses the same driver chip as the Pimoroni ScrollPhat HD board for the Raspberry Pi, which is another great board I have, but I wanted to drive it from an Arduino too, so set about looking to see if the Adafruit libraries would work for the Pimoroni board too.  Four connections are required, as usual for I2C – VCC, GND, SDA, SCL as defined in the pinout here.

In summary, yes, but the Pimoroni has an odd LED configuration, as can be seen in the provided Python library:

class ScrollPhatHD(Matrix):
    width = 17
    height = 7

    def _pixel_addr(self, x, y):
        if x > 8:
            x = x - 8
            y = 6 - (y + 8)
            x = 8 - x
        return x * 16 + y

So the key feature is getting this translation over into the Adafruit IS31FL3731 library in the correct place.  So, taking a copy of the Adafruit_IS31FL3731.cpp and Adafruit_IS31FL3731.h files there were a number of changes to make.

First of all, the Adafruit boards provide a matrix of 16×9 (total 144) leds, compared to the ScrollPhat’s 17×7 (119) leds, so everywhere there is a reference to a width of 16 and height of 9, that needs changing to 17 and 7 respectively.  Unfortunately, there were a number of hard-coded “16”s and “9”s that needed updating.

Then, the translation function is required as follows (added to the .cpp and defined in the .h files):

// ScrollPhat LED Mapping taken from:
// https://github.com/pimoroni/scroll-phat-hd/blob/master/library/scrollphathd/is31fl3731.py
uint8_t ScrollPhat_IS31FL3731::xy2led (uint8_t x, uint8_t y) {
  if (x>8) {
    x = x-8;
    y = 6-(y+8);
  } else {
    x = 8-x;
  return x*16 + y;

This function is responsible for translating the x,y values into a serialised led offset number (0 to 144 in the case of a fully populated matrix like the Adafruit).  There is one place where this has to be called – in the function ScrollPhat_IS31FL3731::drawPixel the following line needs to be changed as indicated:

  setLEDPWM(x + y*16, color, _frame);

  setLEDPWM(xy2led(x,y), color, _frame);

Assuming all the 16×9 references have been updated correctly to 17×7, and no special rotations or anything were required (I’ve not tested all options in the Adafruit GFX libraries), then this largely seems to work, at least it works with the Adafruit Swirl and gfx demos (although there might be some sorting out still to do in terms of handling rotations).




Permalink 2 Comments

8×7 LED Array and MCP23017

December 7, 2018 at 8:21 pm (computers) (, , , , , , )

I can’t resist playing with an LED array, especially a surface mount one, so when I stumbled across some cheap (<$2) surface mount 8×7 LED arrays, charlieplexed onto 8 IO pins on ebay, I had to grab some.

Now I should say, I can’t really imagine why anyone would bother doing what I’m about to describe, as you already have many other options, including:

But as I say, I can’t resist a surface mount LED board, so I started to play.  When these arrived and I started poking around, I soon found out they were actually a cheap knock-off of the Sparkfun 8×7 LED Array, something I didn’t even know existed!  Apologies to Sparkfun for not getting an official board, but many thanks to them for open sourcing the design.

Initially they are fairly easy to hook-up and drive.  I used an Arduino Uno for my first experiments, as they could be paired straight away with pins 2-9 and then driven directly using the Arduino Charlieplex library (the Sparkfun Tutorial uses the Chaplex library and a special Sparkfun library for the board, but I was just doing fairly simple things for now).

With the neat serial interface to the Pi-Lite in the back of my mind, I wanted a better way to connect to the board.  Ideally, something that could be soldered onto the back to make it a single unit.  Some options I explored were:

  • Using an IO expander – such as the MCP23017 (the subject of this post).
  • Using an Arduino Mini Pro – to provide a serial interface (bit more on that later).
  • Using an LED driver module.

For this first experiment, I thought having an I2C addressable LED module would be quite neat (I didn’t know about the IS31FL3731 used on the Adafruit and Pimoroni boards at this time – that is an experiment for another day), so I grabbed some cheap MCP23017 breakout boards and after breadboarding it, ended up simply soldering one on the back.  It overlaps ever so slightly, but I think I could still place a few of these side by side to chain them.


Link-up wise, this ties the 8 IO pins of the matrix to port A pins 0 to 7 on the MCP23017.  The 7 pins with header connections are (in order top to bottom):

  • VCC
  • GND
  • SDA/SI
  • NC/CS
  • NC/SO

And the three connections with no header pins are the three address encoding pins.  As I’m using I2C I only need four connections: VCC, GND, SCL and SDA (I could have left off the other three header pins really).

In terms of the code, there are libraries for the MCP23017, Charlieplexing and even the aforementioned Sparkfun library for this module, but to link them all together is quite inefficient.  The simple approach would be to replace the low-level pin setting/clearing code in the charlieplex library with commands for the MCP23017.  But as every setting of a single LED, even when triggered as part of a ‘scan’ managing a display buffer, requires I2C commands to be sent over the bus, and each command requires bit manipulation to process the IO pins individually, this is massively inefficient.

However, the MCP23017 is really only be driven by two registers: GPIOA to set the IO pins HIGH or LOW, and IODIRA to set the pins to INPUT or OUTPUT.  Recall that for Charlieplexing, all three states of pins are significant: INPUT, OUTPUT+HIGH, OUTPUT+LOW.

To work out which pins do what, we need to refer to the wiring layout of the LEDs on the board, for which the Sparkfun schematic is key (my thanks again for the open source design).  Here is an annotated version showing which IO pins (numbered 1 to 8 on the schematic) are connected to which LED in the matrix.


The key thing to notice is how for every column listed, there is, naturally, a gap in the numbering of the rows (you can’t have an LED connected with both leads to the same IO pin).

So a more efficient scanning algorithm would thus run something like this:

// IODIRA = INPUT (1) or OUTPUT (0)
// GPIOA  = HIGH (1) or LOW (0)

FOREACH col (0 to 7)  // scan one column at a time
  gpiomask = (1<<col) // only pin that is HIGH in the col pin
  dirmask = 0         // default to all OUTPUTS
  FOREACH iopin (0 to 7)
    led = iopin
    IF (iopin == col) SKIP
    IF (iopin > col) THEN
       // led we want is one less than iopin due to charlieplex mapping
    IF (led for col is OFF) THEN
       dirmask |= (1<<iopin)  // set this one to an INPUT i.e. OFF
  NEXT iopin
  IODIRA = dirmask
  GPIOA  = gpiomask
NEXT col

The basic principle being that for a single scan, set one pin HIGH/OUTPUT (for one column in the matrix) and then work out which other LEDs need to be active by setting the direction of the pins accordingly – LOW/OUTPUT will light the LED for that pin combination; INPUT will mean the led for that combination is off.  Then on the next scan, do the same for the next column.

The following is some basic code, based on a whole range of sources (and to be honest, not particularly well structured in terms of functional separation) to provide an I2C optimised scanning function for the MCP23017 and LED array combination.

Usual caveats apply – I’m not really a cpp person, use at your own risk, etc, etc.

Key gotchas from doing this:

  • You can set the I2C bus to run at a higher speed, which is well worth doing in this case.  Note that I don’t know what happens if you have lots of things on the bus – this was working with just this LED array and nothing else.  See Wire.SetClock() in the Arduino Wire library.
  • You can’t do I2C from an interrupt routine.  I wanted the scanning routine to run off a timer interrupt, but nothing works if you try to do that – in fact, everything actually completely locks up.

So that’s it for now.  It scans quite well and with not a bad refresh rate, but as I said right at the start, with so many options of LED array available, not quite sure why anyone would want to do this.

Next, I’ll see if I can get the Pi-Lite firmware onto an Arduino Pro Mini and solder that on the back of one of these too.  That will create a standalone, drivable over serial port, module similar to the original Pi-Lite (ish).  Not really sure why anyone would want to do that either.



 * Charlieplex Example for the Sparkfun LED Array board connected
 * to an MCP23017 IO expander chip and accessed via I2C.
#include "I2CCharlieplex.h"
#include "Wire.h" // required for I2CCharlieplex.h

#define MCPADDR  0   // 0 to 7 for 0x20 to 0x27 for MCP23017 expander

// Define the pins in the order you want to address them.
// Note: for the MCP23017, pin numbers are as follows:
//         Port A pins 0 to 7 = pins 0 to 7
//         Port B pins 0 to 7 = pins 8 to 15
#define NUMBER_OF_PINS 8
byte pins[] = {0,1,2,3,4,5,6,7};

I2CCharlieplex charlieplex = I2CCharlieplex(MCPADDR, pins, NUMBER_OF_PINS);

void setup(){

int x=0;
int y=0;
int scan=0;
int clr=0;

void loop(){

  // Update the LED pattern from time to time
  if (scan > 200) {
    scan = 0;

    if (clr) {
    } else {
      charlieplex.led (x, y, HIGH);
      if (x>=8) {
        if (y>=7) {


 * I2C MCP23017 I2C IO Expander Charlieplex
 * Based on elements of MCP23017 Library from Adafruit and
 * the Charlieplex library by Alexander Brevig
 * Pins are numbered as follows:
 *   0-7  Port A 0-7
 *   8-15 Port B 0-7

#include "I2CCharlieplex.h"
#include "Wire.h"

// Default address
#define MCP23017_ADDRESS 0x20

// registers (using same definitions as Adafruit_MCP23017.h)
// Note: MCP23017 can be configured for interleaving registers or
//       sequential, depending on the setting of IOCON[AB].BANK.
//       By default on power up IOCON.BANK = 0; i.e. interleaved
//       as defined below..
#define MCP23017_IODIRA 0x00
#define MCP23017_IPOLA 0x02
#define MCP23017_GPINTENA 0x04
#define MCP23017_DEFVALA 0x06
#define MCP23017_INTCONA 0x08
#define MCP23017_IOCONA 0x0A
#define MCP23017_GPPUA 0x0C
#define MCP23017_INTFA 0x0E
#define MCP23017_INTCAPA 0x10
#define MCP23017_GPIOA 0x12
#define MCP23017_OLATA 0x14

#define MCP23017_IODIRB 0x01
#define MCP23017_IPOLB 0x03
#define MCP23017_GPINTENB 0x05
#define MCP23017_DEFVALB 0x07
#define MCP23017_INTCONB 0x09
#define MCP23017_IOCONB 0x0B
#define MCP23017_GPPUB 0x0D
#define MCP23017_INTFB 0x0F
#define MCP23017_INTCAPB 0x11
#define MCP23017_GPIOB 0x13
#define MCP23017_OLATB 0x15

#define MCP23017_INT_ERR 255

// Address in range 0 to 7.  MCP23017 address set in the range
//  0x20 to 0x27 using the A0, A1, A2 pins
I2CCharlieplex::I2CCharlieplex(uint8_t address, byte* userPins, byte numberOfUserPins){
  pins = userPins;
  numberOfPins = numberOfUserPins;

  // Initialise the MCP23017 IO Expander using I2C
  if (address > 7) {
    addr = MCP23017_ADDRESS;  // default to first address if not sure
  } else {
    addr = MCP23017_ADDRESS + address;

void I2CCharlieplex::init () {
  Wire.begin();  // We are the bus master

  // Note on I2C clock speed - as a synchronous comms, the clock is set
  // by the master and the slave will be triggered by it.
  // The default is 100kbit/s (standard); many devices will also support 400kbit/s (full speed).
  // Some might support 1Mbit/s (fast mode) or 3.2Mbit/s (high speed).
  // See https://www.i2c-bus.org/speed/
  // 400000 bps is 400000/8 = 50 KB/s
  Wire.setClock(400000); // Use I2C in full speed mode

  // Clear all leds (set all pins to INPUT)

// LED Buffer access routines
void I2CCharlieplex::led(uint8_t x, uint8_t y, bool state) {
  if ((x<NUMXLEDS) && (y<NUMYLEDS)) {
    if (state == HIGH) {
      leds[y] |= (1<<x);
    } else {
      leds[y] &= ~(1<<x);

void I2CCharlieplex::clr() {
  for (uint8_t i=0; i<NUMYLEDS; i++) {
    leds[i] = 0;

// WARNING: This cannot be called from an ISR if it is using I2C
//          (everything locks up if you do)
void I2CCharlieplex::scan() {
  // Only scan one column at a time

  // Scan according to the following algorithm:
  //  IODIRA = INPUT (1) or OUTPUT (0)
  //  GPIOA  = HIGH (1) or LOW (0)
  //  FOREACH col (0 to 7)  // scan one column at a time
  //    gpiomask = (1<<col) // only pin that is HIGH in the col led
  //    dirmask = 0         // default to all OUTPUTS
  //    FOREACH iopin (0 to 7)
  //      IF (iopin == col) SKIP
  //      IF (iopin > col) THEN
  //         led we want is one less than iopin due to charlieplex mapping
  //      IF (led for col is OFF) THEN
  //         dirmask |= (1<<iopin)  // set this one to an INPUT i.e. OFF
  //    NEXT iopin
  //    IODIRA = dirmask
  //    GPIOA  = gpiomask
  //  NEXT col

  // First kill all LEDS

  uint8_t ledmask = (1<<col);
  uint8_t dirmask = 0;
  for (uint8_t p=0; p<NUMPINS; p++) {
    uint8_t y = p;
    if (p == col) {
      // skip this one
    } else if (p > col) {
      // LED index will be one less than pin value due to charlieplex pattern
    // check the 'col'th LED in each 'y' row to see if pin 'p' is IN or OUT
    if ((leds[y] & (1<<col)) == 0) {
      // Want IO pin to be low to illuminate the LED
      // So only set IO pin if LED is OFF
      dirmask |= (1<<p);
  // Always need "col" pin as an OUTPUT (low) though
  dirmask &= ~(1<<col);
  // Only High pin will be the col being scanned
  mcpWrite (MCP23017_GPIOA, ledmask);
  // All other pins are low, so direction will determine if they are
  // a low OUTPUT or INPUT (which will disable that LED)
  mcpWrite (MCP23017_IODIRA, dirmask);
  // next column
  if (col >= NUMXLEDS) {
    col = 0;

// I2C MCP23017 IO Handling
// Not: No DigitalRead as yet

void I2CCharlieplex::mcpPinMode (uint8_t p, uint8_t mode) {
  if (mode == INPUT) {
    // Set appropriate bit in register
    mcpBitUpdate(p, 1, pin2reg(p, MCP23017_IODIRA, MCP23017_IODIRB));
  } else {
    // Clear appropriate bit in register
    mcpBitUpdate(p, 0, pin2reg(p, MCP23017_IODIRA, MCP23017_IODIRB));

void I2CCharlieplex::mcpAllInputs () {
    // Set all pins to INPUT at once
    // (makes a full clear much quicker than setting individual bits)

void I2CCharlieplex::mcpDigitalWrite (uint8_t p, uint8_t val) {
  // Need to read current I/O states from the latch,
  // set/clear the appropriate bit and
  // write it back to the GPIO register
  uint8_t io;
  io = mcpRead(pin2reg(p, MCP23017_OLATA, MCP23017_OLATB));
  bitWrite(io, pin2bit(p), val);
  mcpWrite(pin2reg(p, MCP23017_GPIOA, MCP23017_GPIOB), io);

// I2C MCP23017 Register Handling

void I2CCharlieplex::mcpWrite(uint8_t reg, uint8_t val) {
  // Write sequence:
  //    Send register address to write
  //    Send the byte of data

uint8_t I2CCharlieplex::mcpRead(uint8_t reg) {
  // Read sequence:
  //    Send register address to read
  //    Request 1 byte of data from the device
  //    Read the byte of data
  Wire.requestFrom(addr, (uint8_t)1);
  return Wire.read();

void I2CCharlieplex::mcpBitUpdate (uint8_t bit, uint8_t val, uint8_t reg) {
  uint8_t regval;
  regval = mcpRead(reg);
  bitWrite(regval,bit, val);
  mcpWrite(reg, regval);

// Register and pin helper functions
uint8_t I2CCharlieplex::pin2bit(uint8_t pin){
  // Returns bit 0 to 7 for range of pins 0 to 7 and pins 8 to 15
  return pin%8;
uint8_t I2CCharlieplex::pin2reg(uint8_t pin, uint8_t portAaddr, uint8_t portBaddr){
  if (pin < 8) {
    return portAaddr;
  } else {
    return portBaddr;



#include <Arduino.h>

class I2CCharlieplex {

// LED matrix is 8 across by 7 deep
// Wired up in a charlieplex mode to map to 8 IO pins
#define NUMXLEDS 8
#define NUMYLEDS 7
#define NUMPINS  8

  I2CCharlieplex(uint8_t address, byte* userPins,byte numberOfUserPins);
  void init ();

  // LED buffer handler functions
  void led(uint8_t x, uint8_t y, bool state);
  void clr();
  void scan();

  // MCP23017 handler functions
  void    mcpPinMode(uint8_t p, uint8_t mode);
  void    mcpAllInputs();
  void    mcpDigitalWrite(uint8_t p, uint8_t val);
  void    mcpWrite(uint8_t reg, uint8_t val);
  uint8_t mcpRead(uint8_t reg);
  void    mcpBitUpdate (uint8_t bit, uint8_t val, uint8_t reg);
  uint8_t pin2bit(uint8_t pin);
  uint8_t pin2reg(uint8_t pin, uint8_t portAaddr, uint8_t portBaddr);

  byte    numberOfPins;
  byte*   pins;
  uint8_t addr;
  uint8_t leds[NUMYLEDS];
  uint8_t col;


Permalink 2 Comments

Adafruit 8×8 Backpack, HT16K33, RPi

July 20, 2013 at 11:20 pm (computers) (, , , , )

I have recently acquired one of the great little 8×8 LED matrix boards from Adafruit, that uses the HT16K33 driver chip to give you access to the 8×8 matrix using the I2C bus.  With just four wires between your GPIO 5v, GND, SDA, SCL and the equivalent pins on the matrix board, you are ready to go. I wanted to use it with my Raspberry Pi and whilst their tutorials are excellent for getting you going quickly, I like to know a little more about what is actually going on when I call some of their higher-level functions. For this, I wanted to know what was actually going out on the I2C bus to make the magic happen.  However, apart from the data sheet for the chip itself, this information wasn’t actually that easy to come by! From looking through their sample C (for the Arduino) and Python (for Raspberry Pi) code, and messing around with i2cdump, and then comparing that with the datasheet, I seem to have got into the position of being able to drive the matrix using i2cset. My board appears on I2C bus number 1 (I have the second edition board that changed the GPIO I2C bus address from 0 to 1) at address 0x70, so all the following commands assume those values. The following commands are the main ‘initialisation’ commands:

i2cset -y 1 0x70 0x21

i2cset -y 1 0x70 0x81

i2cset -y 1 0x70 0xe0

The first turns on the oscillator – setting bit S in the “system setup” register – labelled D8 in the data sheet. The next enables the display with no blinking – setting bit D in the “display setup register” – D8 again in the data sheet.  To enable blinking then B1+B0 must be set to 01, 10 or 11 – i.e. replace 0x81 with 0x83, 0x85 or 0x87 respectively. The last command sets the brightness level – in this case, leaving the brightness to the dimmest setting, P0, P1, P2, P3 are all zero in the “digital dimming data input”.  Use a different value instead of 0 in the 0xe0 value – e.g. 0xef would be the brightest setting (all 1s). Now in order to actually turn on some LEDs, the rows are found at even addresses, starting from address 0x00, so the 8 rows of my matrix can be set using:

i2cset -y 1 0x70 0x00 0xaa

i2cset -y 1 0x70 0x02 0xaa

i2cset -y 1 0x70 0x04 0xaa

and so on up to

i2cset -y 1 0x70 0x0e 0xaa

In this case, I’m setting all rows to the value 0xaa (i.e. binary 10101010).  However, there is a complication – the bits are actually offset against the LEDs, so writing 0x01 actually illuminates the 2nd LED of each row.  So you actually need to do the following (taken from the source code of the library):

bitnum0to7 = (LED + 7) mod 8

So to set the first LED, write the hex pattern 0x80.  For the second LED, use 0x01; the third 0x02; fourth 0x04 and so on up to the last LED on the row being 0x40. I assume this is quirk of the wiring of the LED matrix to the driver pins of the HT16K33.

So thats it.  To turn off the display, turn off the oscillator or turn of the display (or both):

i2cset -y 1 0x70 0x20

i2cset -y 1 0x70 0x80

Everything else is built up from these basic commands.  And with this knowledge, the data sheet for the chip makes a lot more sense! One final note – the data sheet has an input mode too – the chip can be used to scan a simple keyboard.  Obviously in the case of the 8×8 LED matrix displays, this is not used. So, I’ll take another look at the C and Python code, but at least now I know what is going on underneath all that. Kevin.

Permalink 1 Comment

Minimus usb and 64 LEDs

May 22, 2012 at 7:47 pm (computers) (, , )

This is the last post on this for a bit (it will probably be a while before I get my next chance to tinker).  Once I’d got my minimus wired up I wanted to flash some LEDs!  After all, that’s the whole point right?

I got hold of a 8×8 LED matrix.  Some some initial confusion about common-anode matrix vs common-cathode matrix then realising that for a single colour matrix, actually it doesn’t really matter, I got hold of one of these – a Kingbright – 8×8 LED Matrix (TC15-11EWA) (around £5 from Spiratronics on ebay)

Then I had to work out how to drive it!  Well finding the data sheet was a start, and then I found some application notes for arduinos to drive an 8×8 matrix:

Neither really explained what I wanted to know – the nuts and bolts of wiring one up to a minimus …

Then the following data sheet on oomlout give me more clues:

This described the scanning approach to getting a picture on the display.  So, to connect the matrix to my minimus, I’d use 8 IO pins for the rows and 8 for the columns, then set a value across the columns, then activate that row only.  Doing this quickly for all rows would give me a display.

The pinouts for the LED matrix are quite peculiar – no logical order, so I had a choice – wire it up in a more complex way to bring them out in a logical order or wire them simply and use software to map IO pins to LEDs.  I really couldn’t entertain having anything other than a simple port to LED mapping,  and I wanted my IED ribbon cable nicely soldered to the edge of my stripboard, so I put together a simple circuit to map the LED pins to tracks on the stripboard.

I also needed some current limiting resistors, so as I get all my electronics knowledge either from first principles physics or wikipedia – in this case I just followed the formula for LEDs on the wikipedia page and decided I needed ~120 Ohm resistors.  Well, I had 150 in an old electronics box, so that’s what I used.

Now shown on this circuit (I don’t have any real circuit drawing tools) – I added the resistors as bridges/links prior to the R (rows) connectors then connected it up to my IDE cable so that:

  • R1-R8 -> PB0-7
  • C1-C4 -> PC4-7
  • C5-C8 -> PD1-4

I didn’t use PD0-7 because of the aforementioned problem I had with pin PD0.

So to drive the matrix, I used the following code

// row = 0 to 7
// col = 0x00 to 0xff
void led (int row, int col)
  PORTB = 0;   // turn all rows off prior to this scan

  // Cols = must be set low to activate LED matrix,
  //        so will need to inverse logic
  // Bits 0-3 = PORT C4-7
  // Bits 4-7 = PORT D1-4
  int portc = (~(col & 0x0f))<<4;
  int portd = (~(col & 0xf0))>>3;

  PORTC &= ~ (0xf0);
  PORTC |= portc;
  PORTD &= ~ (0x1e);
  PORTD |= portd;

  // PORTB = bit per row
  // must be active to set the row
  PORTB = (1<<row);

Notice how I bit-shift and split the col value across ports C (4-7) and D (1-4). I just set a single bit to activate the row.  Also notice how for an LED to light up the row (port B) must be high and the col must be low (ports C and D).

To turn all rows off, I just send a 0 to PORTB.

Also, I need to initialise the ports appropriately for outputs:

PORTB = 0b00000000;
DDRB  = 0b11111111;   // all outputs
PORTB = 0b00000000;   // start low

PORTC = 0b00000000;
DDRC  = 0b11110000;   // 4-7 outputs
PORTC = 0b11110000;   // start high

PORTD = 0b00000000;
DDRD  = 0b01111110;   // 1-4 outputs for matrix, 5,6 for onboard LEDs
PORTD = 0b01111110;   // start high

At this point I can start playing.  By repeating the following in a loop, it will output the display in the picture below!

led (7, 0b00000000);
led (6, 0b00000000);
led (5, 0b01100110);
led (4, 0b01100110);
led (3, 0b00000000);
led (2, 0b10000001);
led (1, 0b01111110);
led (0, 0b00000000);

Its not perfect – for some reason the LEDs are brighter at the edges than in the centre.  And I’m sure what I thought was going to be a row has turned out to be column!  But its a pretty good start.

At the end of the day – I have 64 LEDs and a smiley face.  Could I want for more?

And with that, I think my minimus tinkering will take a short pause.


Permalink 1 Comment