RGB LED matrix multiplexing

[dingari]

Hi, I'm trying to work out a solution for multiplexing a small RGB LED array. The size constraints are very tight (maybe 5x5mm).

Charlieplexing would be the obvious choice regarding minimization of IO pins, but it does constrain the mixing of colors (since each color LED can only be ON or OFF, no easy way to use PWM to mix). This is also a very power-limited project, so I want to minimize CPU time.

Standard matrix multiplexing seems like a better approach. While occupying more IO pins, the brightness of each LED should be controllable via PWM (apply positive voltage to a row and pulse the corresponding column to light up an LED). The idea is to set up a timer that wakes the device up with a certain interval (depending on number of LEDs), and cycle through the rows and columns.

I'm aiming for maybe a 5x4 matrix (40 RGB LEDs, 120 LEDs total), requiring 22 IO pins by standard matrix multiplexing (10x12 matrix). 12-16 channel PWM LED driver chips seem to be commonly found, so two chips required.

So I guess my questions are:

• Does this seem reasonable?
• Which low-power, small footprint PWM driver chips are available?
• Will the multiplex PWM multiplex method introduce any obvious issues?
• If I accept only being able to mix a few colors (Red, Green, Blue, Red+Green, Red+Blue, Green+Blue), what are my options in external ICs, since the micro I'm using doesn't really have tri-state GPIOs?

[Ian.M]

Use smart LEDS.  Depending on the matrix spacing, either WS2812 5050 'Neopixel' or APA102-2020 'Dotstar' LEDs.   The latter should be viable down to a 3 mm grid, and has a SPI style interface with a buffered daisychainable clock out so doesn't have the critical timing constraints of WS2812 or similar single wire protocols.   Both are stocked by Adafruit + many other suppliers.

[dingari]

Use smart LEDS.  Depending on the matrix spacing, either WS2812 5050 'Neopixel' or APA102-2020 'Dotstar' LEDs.   The latter should be viable down to a 3 mm grid, and has a SPI style interface with a buffered daisychainable clock out so doesn't have the critical timing constraints of WS2812 or similar single wire protocols.   Both are stocked by Adafruit + many other suppliers.

That's an interesting alternative. But it seems like the dimensions are a bit too much (2 x 2 mm). I'm thinking more in line with 0606 (1.6 x 1.6 mm) or even 0404 (1 x 1 mm) LEDs.

I'll keep it in mind, though.

[mikeselectricstuff]

No muxing scheme inherently prevents dimming. PWM isn't a good approach as it doesn't scale well. Instead use binary code modulation:

For <n> bits of intensity control :

Turn on all LEDs which have bit 0 of their intensity value set for time <t>
Turn on all LEDs which have bit 1 of their intensity value set for time <t>*2
Turn on all LEDs which have bit 2 of their intensity value set for time <t>*4
etc. for all <n> bits.

It helps a lot if you ave a hardware timer/compare peripheral that can turn all LEDs on/off for a precise time, but it can be done in software, you just need to make sure all LEDs get turned on for the same time, and the time accurately doubles on each bit. Minimum on time and bit depth determines achievable framerate. 

[mikeselectricstuff]

Use smart LEDS.  Depending on the matrix spacing, either WS2812 5050 'Neopixel' or APA102-2020 'Dotstar' LEDs.   The latter should be viable down to a 3 mm grid, and has a SPI style interface with a buffered daisychainable clock out so doesn't have the critical timing constraints of WS2812 or similar single wire protocols.   Both are stocked by Adafruit + many other suppliers.

That's an interesting alternative. But it seems like the dimensions are a bit too much (2 x 2 mm). I'm thinking more in line with 0606 (1.6 x 1.6 mm) or even 0404 (1 x 1 mm) LEDs.

I'll keep it in mind, though.

TI do some 48 channel LED drivers (e.g. TLC5948), which might be easier than muxing.

[dingari]

No muxing scheme inherently prevents dimming. PWM isn't a good approach as it doesn't scale well. Instead use binary code modulation:

For <n> bits of intensity control :

Turn on all LEDs which have bit 0 of their intensity value set for time <t>
Turn on all LEDs which have bit 1 of their intensity value set for time <t>*2
Turn on all LEDs which have bit 2 of their intensity value set for time <t>*4
etc. for all <n> bits.

It helps a lot if you ave a hardware timer/compare peripheral that can turn all LEDs on/off for a precise time, but it can be done in software, you just need to make sure all LEDs get turned on for the same time, and the time accurately doubles on each bit. Minimum on time and bit depth determines achievable framerate.

This is quite clever. I'll have to read up a bit on the subject.

But as I understand, this could be achieved with a Charlieplexed matrix, right?

Edit: quoted the wrong reply.

[mikeselectricstuff]

No muxing scheme inherently prevents dimming. PWM isn't a good approach as it doesn't scale well. Instead use binary code modulation:

For <n> bits of intensity control :

Turn on all LEDs which have bit 0 of their intensity value set for time <t>
Turn on all LEDs which have bit 1 of their intensity value set for time <t>*2
Turn on all LEDs which have bit 2 of their intensity value set for time <t>*4
etc. for all <n> bits.

It helps a lot if you ave a hardware timer/compare peripheral that can turn all LEDs on/off for a precise time, but it can be done in software, you just need to make sure all LEDs get turned on for the same time, and the time accurately doubles on each bit. Minimum on time and bit depth determines achievable framerate.

This is quite clever. I'll have to read up a bit on the subject.

But as I understand, this could be achieved with a Charlieplexed matrix, right?

Edit: quoted the wrong reply.

Yes. All you need is the ability to turn all enabled channels on for a specific time. With charlieplexing you probably need to do it all in software. Also beware of the differing voltage drops of R and G/B for charlieplexing.
IMO it;s often much easier to use a simple X/Y matrix rather than more elaborate muxing schemes. Especially as for RGB you're typically constrained by the fact that the anodes are commoned in the LED package.

[dingari]

Yep, standard matrix multiplexing seems more viable. Then I can tie R's together, B's together, and G's together with a single resistor to keep the current constant.

I'm not quite sure my MCU can handle sourcing and sinking allt the current through GPIOs, though. That has got me thinking about using shift registers or an LED driver as a source/sink. TI has some small QFN shift registers. The only problem will be the supply voltage. Ideally, I'd like to run the MCU and logic on 1.8V, but that's not enough for the G/B LEDs. And I don't think shift registers with logic level independent of supply voltage.

[mikeselectricstuff]

Yep, standard matrix multiplexing seems more viable. Then I can tie R's together, B's together, and G's together with a single resistor to keep the current constant.

I'm not quite sure my MCU can handle sourcing and sinking allt the current through GPIOs, though. That has got me thinking about using shift registers or an LED driver as a source/sink. TI has some small QFN shift registers. The only problem will be the supply voltage. Ideally, I'd like to run the MCU and logic on 1.8V, but that's not enough for the G/B LEDs. And I don't think shift registers with logic level independent of supply voltage.

considering how much power the LEDs will take I doubt there would be much advantage running the logic at 1.8v

[dingari]

Yep, standard matrix multiplexing seems more viable. Then I can tie R's together, B's together, and G's together with a single resistor to keep the current constant.

I'm not quite sure my MCU can handle sourcing and sinking allt the current through GPIOs, though. That has got me thinking about using shift registers or an LED driver as a source/sink. TI has some small QFN shift registers. The only problem will be the supply voltage. Ideally, I'd like to run the MCU and logic on 1.8V, but that's not enough for the G/B LEDs. And I don't think shift registers with logic level independent of supply voltage.

considering how much power the LEDs will take I doubt there would be much advantage running the logic at 1.8v

There might be a point there. Although the matrix will probably never be totally lit (all LEDs on), maybe just a single column for a few seconds.

[mikeselectricstuff]

For low-power use most constant-current drivers aren't very good due to quiescent draw - devices like 74HC595 and NPIC6c595 can be more useful.
Also look at matrix drivers from ISSI and AMS designed for lower-power applications

[dingari]

Yep, I found some 74HC595 from TI in 2.5x2.5mm QFN packages. Seems like that route is a lot more viable than CC drivers.

I'll have a look at ISSI and AMS, thanks!

[mikeselectricstuff]

Yep, I found some 74HC595 from TI in 2.5x2.5mm QFN packages. Seems like that route is a lot more viable than CC drivers.

NXP also do the HC595 and NPIC6C595 in a small package - don't recall offhand what they call it but it's a rectangular DFN