Adafruit 16×32 LED matrix on Arduino Due (4)

I’m finally making some progress with introducing a higher color depth. Using BCM I’m now more or less on a 12-bit color depth. In the Adafruit driver I found parts of code that first were not very clear to me. There are methods like Color888(uint8_t r, uint8_t g, uint8_t b) and Color333(uint8_t r, uint8_t g, uint8_t b) but than I found that these are actually related to how colors are kept in memory bit wise. You see, with 333 colors you’re using 3 bits for the red value, 3 for green and 3 for blue. So this means there is a total bit depth of 0…7 for each RGB value resulting in a total 9-bit color depth which gives us 512 colors. 8/8/8 colors are 24-bit large in total and are the so called True Colors. They’re often used on PC’s in results in different colors. The 5/6/5 colors, also called High Colors, are 5+6+5 = 16 bits wide and result in 65536 different colors. This is also often used on computers. The awkwardness here is that the green portion has one bit extra compared to the red and blue portion. This is done because there was otherwise one bit unused (better to use it right!) and because of our perception is green is different that for red/blue one bit extra for green would be best suited (don’t ask me the exact scientifical reason, look for it on wikipedia). This 16-bit color depth is also used for storing images in the Adafruit driver. But so far it’s used only for storing, to display these images the driver falls back to a 12-bit color depth in 4/4/4 format and this because of two reasons. More colors would be kind of hard to do because it would dramatically reduce refresh rate and this you certainly don’t want. Although LEDs are used, refresh rates in between 25 and 50MHz are still not high enough for the human eye to experience the display as smooth. So it’s better to stuck at 12-bits deep. Also, in the 5/6/5 setup, if you use BCM modulation, there is one moment where you’ll be displaying only the green portion because red and blue are not equally in bit size.

But BCM, what is this exactly. BCM is a modulation technique like PWM is. With PWM you define the percentage of on and off time. Say you’re having a pulse of 70% on and 30% off during the total period, if you have a LED connected to that pulse you’ll experience it as slightly dimmed. With BCM you’re not giving any percentages, you’re using the bit value instead. Let’s say you’re using 2-bit BCM, for this the 2 bits are divided over the total period and so the more ‘1’s you have in your binary BCM value the more the LED will be pulsed on during the period, and the brighter it will look. Let’s say you’ve the value 11, the LED will be set on for the total period of time and will look very bright. 00 means it will be off all the time. But what about 01 and 10? Well, here the bit-value comes into play otherwise both codes would result in 50% on and 50% off. Using the bit-value the ‘1’ in ’10’ has a higher bit value than the ‘1’ in ’01’ and so it will stay on longer depending on the weight of the bit. There is a nice introduction to BCM found here.

And so the Adafruit driver uses 4-bit BCM, using only the 4 most significant bits of their 16-bit (5/6/5) representation in memory. I’ve gone the same direction and got it more or less functional:


This lowres picture doesn’t exactly show you a lot, I’ll have to look for better photo footage. The higher color depth is now possible using BCM but it’s still not finished yet. Resetting the timer each time kind of screws up the refresh rates so instead of using the due timer library I talked of before I’ll have to write the timer code myself and cut off an overhead. Also I noticed that I’m doing a lot of digital writes (6) to set just the RGB pins, where in the Adafruit driver they can set all 6 pins altogether. If a could do this it would also greatly reduce the timer interrupt time and allow me to bump up the refresh rate. So, more work ahead…


About Arduino’s DigitalWrite – Adafruit 16×32 LED matrix on Arduino Due (3)

In the previous article I already noticed how the display was starting to get less bright when I bumped up the refresh rate. Reading some parts of the Arduino Uno driver I noticed this one comment hinting to the slow Arduino DigitalWrite function. I never knew or red about this function not being very fast, I was expecting maybe a little impact but not as much as described in some online articles. And so I began to think of also looking for a way to faster manipulate pin outputs so that the driver works faster and better, and maybe allow us to do more than before. For Arduino Uno there is tons of information to find, however for Due you have to look a lot better. On the Arduino forums however I found this thread where faster port manipulation code has been presented:

inline void digitalWriteDirect(int pin, boolean val){
  if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
  else    g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;

inline int digitalReadDirect(int pin){
  return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);

void setup() {                
  pinMode(13, OUTPUT);     
  pinMode(12, INPUT);     

void loop() {
  digitalWriteDirect(13, HIGH);   
  digitalWriteDirect(13, LOW);    

In my current driver I swapped all digitalWrite methods with the digitalWriteDirect methods from above and than compared how fast writing one (double) row of LEDs goes. Time was measured by calling the micros() method before and after writing on row of data, taking the difference of both and next report back by doing a single Serial.write(). Here is a comparison:
digitalWriteDirect: 91us
digitalWrite: 661us
So as you can see the direct implementation gives us nearly 7 times better performance, or the other way around I kind nearly draw the entire display this time where before I could draw only one row. I also now noticed that in my display only the last rows of each half screen were illuminating very bright while others where nearly not illuminating at all. The reason is because now we switch so fast from one row to the next that the HIGH time of the pixels in a row is very small compared to before when using the slow Arduino implementation. The reason why the last row was however bright is because it get’s drawn as last and from here on it takes nearly 5000us before the next interrupt is being called, so it is really obvious that it was appearing really bright. In my last update I changed to drawing only one row per timer interrupt. This way rows get painted on a steady time base, and with using the faster digitalWriteDirect method we can easily bump up the refresh rate of the display so now the interrupt routine gets called 8 times more than before.
Next problem I get is that I need to call the interrupt code each 1250us in order to get a steady image. That is a 800MHz refresh rate per pixel row, and so 100Hz for the entire display, which kinds of bothers me because now interrupt code will interrupt normal program flow a lot of times, and I’m still at only 3 bit colors and I don’t have any support for dimming. I guess there is more reading ahead of me…

Adafruit 16×32 LED matrix on Arduino Due (2)

Not to much time spend so far on this display, but before I continued I wanted to make sure I can make the display illuminate asynchronously with the rest of the program flow. To do this we need to use interrupts which is launched after a certain timer expires. This way we can for example make sure that every 5ms the pixels are refreshed so that we get a clear non-flickering image. This also allows us to program our normal program code in the loop method without having to worry about the display code not being called in time (because then the display would go black for some time). For Arduino Uno the code is already there in the IDE to use, for Due a guy named Ivan Seidel already did some testing and programming and so we can also make use of interrupts on Due really easy (library on

Here is a 3-bit colors version of the British flag displayed with the Adafruit 16×32 RGB LED matrix and Arduino Due.

2014-03-07 00.05.08I notice though that the LED’s do not really shine so powerful as they should, and also altering the interrupt timer to display at 50 or 100Hz intervals really ruins the picture (also this I can not explain). So more work ahead… may God save the Queen!

Adafruit 16×32 LED matrix on Arduino Due

Beginning of January I saw a video demonstrating a clock which also plays Game of Life during displaying the clock. This so called Clock of Life uses the Adafruit 16×32 LED matrix and a Arduino Uno microcontroller board. I never came across this LED matrix before but it seems like a nice and popular display to tinkle around with, so off course it was only days later that I owned my own copy of it. As far as the clock goes, I’d very much like to achieve using it as a clock too, but the Game of Life option I’d  like to skip, instead I want it to be wireless connected to the internet so that NTP servers can help me keeping the time more or less correct and thrust worthy over longer periods of time, maybe even years. With this wireless connection of course come a lot more possibilities, like setting a alarm clock to wake you up by using your smart phone, set background images and let the user configure the clock remotely. Well off course there is lots of more features I could add, but let’s not start to think to wide before we can even get it working.

For the wireless connection I opted for using the Adafruit C3300 Wifi adapter. After receiving both this unit and the 16×32 LED matrix I noticed that combining both on a Arduino Uno was going to be pretty hard on pin usage. Furthermore I was also not very sure how processor intensive everything combined was going to be, and keeping in mind I might want to add even more features I opted for a more speedier and advanced solution: the Arduino Due. It’s a 84MHz processor with a lot more in- and outputs. First thing I did back in January was making sure NTP server requests indeed do work using the C3300 on Arduino Due as a standalone solution. Next: make another standalone version where I test the LED matrix, but it was then that I noticed the Adafruit 16×32 LED matrix is currently not supported for Arduino Due. Nooo!

After some googling I found out the display does take quite some processing power to display full colors. Some of the code has been really optimized for using the Arduino Uno/MEGA internal functionality. So it was more or less at this time that I started to notice this project was going to take a lot more time since I’d be writing the display driver myself. The Adafruit tutorial tells you some of the details of how the boards works, and if you read it very carefully you’ll notice it’s not so very difficult to do some basic stuff like lighting some LED in either a red, green, blue or white color, or not light it at all. However, for mixing colors and dimming the display more advanced programming is needed. But first something about the display.

Without getting to much into the details on how the display works electrically here are the available pins we should take care of:


A, B, C => row address select pins
R1, B1, G1 => red, green, blue led on/off pin of a pixel of an upper row
R2, B2, G2 => red, green, blue led on/off pin of a pixel of an lower row
CLK => clock pin
OE => output enable pin
LAT => data latch pin

For the display to work you’ll have to send data at a constant rate as the display itself does not have any memory. This implies a lot of other stuff which I’ll get into more detail later. The A, B, C row address pins (3 pins = 3 bits) allow us to select 8 different addresses. For each address not one but two rows are being selected. So setting the bits for address 000 does not only select row 1, it also select another row being it the 9th. The 9th and not the second, because it allows to have less scan rate. For each row we have 32 pixels, so with 2 rows selected each time we set an address we now have 64 pixels available to manipulate (where each pixel has 3 LEDs, for red, green and blue color). Setting the pixel color however happens in a serial way, first one has to set a appropriate signal on the R, G, B pins, but because we have 2 rows selected at the same time we also have these R, G, B pins twofold. R1, B1, G1 for pixels in the upper region, and R2, G2, B2 for pixels in the lower region. Next the CLK (clock pin), LAT (data latch pin) and OE (enable pin) should be used to send the RGB LED’s On/Off state for each of the 32 pixels per line in a serial way.


While this might not seem to complicated to understand, there is more than meets the eye. For drawing in either red, green, blue or white colors it’s as sample as setting only the correct bits at the RGB pins, though when one wants to set a yellow or purple or any other color more complex methods will be needed because we have only 3 bits per drawing cycle to our disposal. We will have to fool our user by setting a pixel first red, than blue, than red again, than back to blue, … nnd this very quickly so that for the user the different colors mix up into something that might look like purple. So let’s say with 3 bits we can have 8 colors, 2 drawing cycles would make 2 times 2 bits resulting in 6 bit color (= 64 colors), and 3 cycles would result in 9 bit color which represents 512 colors.

But it gets more complicated. What if we want to dim our display? We not only need to mix for the correct color, we also need more drawing cycles for PWM dimming the display (if the goal is to implement it). So Let’s say we mix to get to the correct color in 3 drawing cycles, we’ll probable need another 2-3 drawing cycles where all LEDs per pixel or not illuminating to get to the a 50% duty cycle. This however is a layman implementation because not all colors are evenly bright. Red for example requires only one LED, while white requires all LEDs to be illuminating and thus the white color will always be a lot brighter the full red. For this and other technical difficulties I did not yet think of I still need more time to work it out, for now I can only show you some basic code where the Arduino Due is used to show 3 bit color on the Adafruit 16×32 LED matrix:

2014-03-03 23.00.53