Arduino Adventures :: Day 6

Published March 03, 2010
Advertisement
I had been thinking about how to achieve individual addressing using demultiplexers even before I gave Charlieplexing a shot. But during my preliminary research the stumbling block was that the largest demux I could find was only a 4 to 16. If I wanted to individually address 64 LEDs I would need four of these, thats 16 I/O pins required to drive them all (I only have 14 on the Arduino).

So that wouldn't work. I continued to mull about this because there was an itch in the back of my skull telling me it could still work. And then it hit me! As you may or may not know, demultiplexers have a given number of inputs to select which output pin to activate. But they also have an enable pin that can disable the entire demux (so no output pins are active).

My idea was to hook up all of the four demux inputs up in parallel with each other. So pin 1 for each demux would be hooked up in parallel together to one I/O pin on the Arduino, and same for pin 2, 3, and 4. So to drive all four demux's you only need 4 I/O pins on the Arduino. Now the problem with this of course is that if you select pin 8 for output, then pin 8 on every demux will go active.

My solution is to use a smaller 2 to 4 demux, and hook these outputs up to the enable pins on each 4 to 16 demux. So with only 2 I/O pins on the Arduino I can select which Demux is active, and only that one will have an output pin going active.

When all is said and done, I only need 4 pins to drive the 4x16 inputs, and 2 to drive the 2x4 inputs. Thats 6 I/O pins to individually address 64 LEDs :D

Demux Select Addressing

Now my previous exploration of Charlieplexing was far from a waste of time because it got me thinking about Persistence of Vision as a valid way of presenting a static image. Using this demux method for individual addressing of the LEDs, and Persistence of Vision to present a static image, I have a perfect method for engineering my display! Some bonuses of this method over Charlieplexing are:
  1. The circuit complexity increases linearly as you add more LEDs
  2. LEDs always get the same amount of current
  3. The layout lends itself very well to being in a grid!

So with this rough sketch I set forth! It's a real shame that "The Shack" (Formerly known as Radio Shack, they re-branded them selves, seriously) doesn't carry the stuff they used too. They have just a single cabinet of fairly worthless components. It's a real let down. So finding ICs and other small electronics is a real pain these days. Ordering them from sites is an option, but it took some research to find sites that sell in small quantities. I did find a few good ones finally. Shipping time and cost kinda suck, but what can you do.

The Shack

The first issue I ran into was that nearly every demux was active LOW. Meaning, all unactive output pins were putting out 5V (HIGH), and when you activated one, it would go to 0V (LOW). Thats fine if you have a logic circuit that is all active LOW. But in my case, that would mean that every LED would always be on, and when I addressed one of them, it would actually turn OFF... Not what I wanted :P

So the only one I found that was active HIGH had a 4bit transparent latch for the input. Not a big deal, kinda cool actually, but it means I need an extra I/O pin for the latch strobe. That puts me at 5 pins rather then 4 for the 4x16 demux's (since i will be hooking all the strobes up in parallel as well), which makes it 7 pins total, well within bounds. The inputs were active HIGH as well, but oddly the enable was active LOW. So if I'm pushing 5V (HIGH) into the enable pins, it DISABLES the demux, and if I drop that to 0V (LOW) it ENABLES the demux.

This actually worked to my advantage because every 2x4 demux i could find (whos output would feed into the 4x16 demux's enable pin) were active LOW logic, so every output pin would propagate HIGH until I activated one, which itself would then go LOW.

2 to 4 Demultiplexer : CD74HC139E
2x4 Demux Block Diagram

4bit Transparent Latch/4 to 16 Demultiplexer : MC14514BCP
4x16 Demux Block Diagram

As I was saying, the thing that sucks with Radio Shack and every other small eletronics outfit going the way of the Dinosaurs, is the shipping time. If i got a dead IC, or burned one out my self, I'd have to wait another two weeks for a replacement. So i ordered double of everything I needed. (Each IC was only like $0.75, so not a big deal). And to be extra careful, I'm ordering IC sockets, so I won't be soldering the ICs directly.

Now I ordered and received the demultiplexers already. And hooked one of the 2x4s up to my Arduino to test it all out. I haven't worked with ICs let alone demux's in years, so I wanted to test out my self as well as the hardware, to know for sure they all work:
2x4 Demux Test

This is being controlled by my computer via serial input, so i can flip the inputs manually, and see the output state instantly. I plan on modifying the program to run through each state automatically and verify the output for each input state. Sort of unit testing the ICs. Then I will do the same for my 4x16's.

Still quite a bit to do before I'm ready to begin the build, but it feels good to have a solid design finally.
0 likes 4 comments

Comments

benryves
I may be missing something obvious, but is there a reason this is necessary? The ATmega168 has at least two full 8-pin ports (port B and port D) so one port to drive the rows and another the columns would seem the easiest solution. Does the Arduino "steal" lots of the pins for its own nefarious purposes?
March 04, 2010 05:58 AM
Wavesonics
Oh possibly, not sure, but on the board I have here, I have 2 8pin blocks, but 2 of the pins are not I/O, they are GND & AREF, which only leaves me the 14 :/

You can flash it via USB and do serial communication via USB, so I bet some of the ports were consumed for stuff like that.

(There is another block of assorted 5V, 3.3V, Vin, RESET, and GND pins, and another block of Analog Input pins)
March 04, 2010 08:44 AM
benryves
The ADC pins are PC0 to PC5 and reset is PC6. I suppose the two UART pins (RXD and TXD) are in port D, so you won't have a full eight-bit port there. I'd be very surprised if you couldn't use the analogue pins as digital I/O pins, though.

Still, your workaround should free up some pins to connect other devices. [smile]
March 04, 2010 09:40 AM
Wavesonics
Thats interesting about the Analog Input pins I'll have to look into that, I thought I remembered reading you couldn't but tbh i don't really know. If so, I could address a whole boatload using my method + those extra pins :D

I'm planning on looking into individual addressing for RGB LEDs later, so I can do multi-color for a V 2.0 of this project.

Or maybe one of those fancy 4x4x4 LED Cubes with RGB LEDs!
March 04, 2010 12:38 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement