GPIO LED matrix?


23 posts
by edyb » Sun Jul 01, 2012 8:53 pm
I'm new to GPIO and not sure if this is right place to ask. However, as I understand there are 26 pins but only 17 can be used as GPIO.

I want to control a board with say 36 lights. I want to be able to toggle them on and off.

So, can I arrange a matrix 6x6 and attach GPIO using 12 pins... 6 running horizontal and 6 vertical, to make an addressible grid?

So say horizontal numbered 1-6 and vertical numbered 7-12, for example when I turn on GPIO 2 and GPIO 8 it criss-crosses over 1 element in my 6x6 grid and turns it either on or off. Doing this repeatedly I can turn any point of my grid on or off.

Alternatively, given that I can use GPIO to represent a binary digit, if I have a 36 matrix I need 6 bits total... 2x2x2x2x2x2 = 64 possible unique combos. 5 GPIO pins not enough, only gives 32 options. Then I can send a binary digit based on GPIO on/off combo and have it turn on/off a unique element in my display.

Am I doing this all wrong? Is there a chip that I should be using to multiply the number of unique elements I can control with the GPIO pins?

Help please! Thanks!
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by MattHawkinsUK » Sun Jul 01, 2012 9:11 pm
I've never used one but I think you can probably use a Shift Register to give you more outputs.
My Raspberry Pi blog and home of the BerryClip Add-on board : http://www.raspberrypi-spy.co.uk/
Follow me on Google+, Facebook, Pinterest and Twitter (@RPiSpy)
User avatar
Posts: 486
Joined: Tue Jan 10, 2012 8:48 pm
Location: UK
by mahjongg » Sun Jul 01, 2012 9:44 pm
Yes, you could do this, as longs as you put sufficient current limit resistors in series with the GPIO pins.

As another trick you can use use LED's in "antiparallel" That is the anode of one LED connected to the cathode of the other LED, so with a 4 x 4 matrix (using 8 GPIO pins) you can control not 16, but 32 LED's! Which LED will burn depends on the polarity of the active row and columns signals, all others row and colum lines must be must be turned to inputs (or high impedance) for this trick to function.

Beware that the total amount of current through all GPIO pins is limited just as the current through a single GPIO is limited (and software controllable)

Another useful trick is to use any analog n to 1 mux (CD4051) to select 1 of n LED columns (cathodes) to connect to ground through a current limiting resistor, and then put a high GPIO out signal on the rows of the LEDs (anodes) you want to light. Especially useful for ticker displays.

To overcome the output power problem somewhat you could use an I2C I/O expander, or use one of the many other "dirty tricks" available, such as indeed using shift registers, to expand the number of I/O's available.

Matrix scanning is indeed a very useful technique, as long as you understand that just a single LED at a time will be actually burning!
User avatar
Forum Moderator
Forum Moderator
Posts: 5479
Joined: Sun Mar 11, 2012 12:19 am
by Lorian » Sun Jul 01, 2012 10:00 pm
Maxim MAX6955 i2c LED Driver is another option.
Posts: 112
Joined: Sun Mar 11, 2012 10:09 am
by pygmy_giant » Sun Jul 01, 2012 10:59 pm
wonder if anyone will make a pi controlled 3d led cube?
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by edyb » Mon Jul 02, 2012 1:03 am
Thanks for the replies.

What I actually want to do is make something like the Qlocktwo which is a text clock.

The face of the clock is a static text template but depending on the time, different words light up. Based on the algorithm, there are a finite number of words that could ever light up, they are:

IT IS (always lit)
FIVE
TEN
A HALF
A QUARTER
TWENTY
TWENTY FIVE
PAST
TO
O CLOCK
AM
PM
ONE
TWO
THREE
FOUR
FIVE
SIX
SEVEN
EIGHT
NINE
TEN
ELEVEN
TWELVE

I have already made an app for this, relatively simple to convert the time value to the text equivalent to determine which lights should turn on behind the clock face.

However, GPIO output being limited to 17 unique outputs I don't have enough.

So I figured if I used even a 5x5 matrix to toggle on/off up to 25 possible switches that would be enough to turn on or off the lights behind any of the possible words behind such a clock face.

The Raspberri Pi would be mostly idle and just counting time, updating the state of the matrix. A different circuit at higher current would be reading the matrix to determine the state of the 25 nodes to know what lights should be on/off at any given time.

Maybe there is an easier way to do this?
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by mahjongg » Mon Jul 02, 2012 1:22 am
For this matrix scanning is probably too complicated, the way I would do it would only use 5 (or six) GPIO, to drive a one a one out of 32 decoder with binary codes, using the decoder to turn the 5-bit binary pattern into 1 of 32 signal lines going active, each line driving one or more LED's.

Unfortunately such decoders only go up to 16 outputs, (the CD54HC154), but you can use two, connect the A lines together, and only select one to go "on". You can use an inverter to switch between the two or connect the select lines of the two chips to separate GPIO (you then need six GPIO).
One small disadvantage is that you need a series resistor for each LED (or group of LED's)
User avatar
Forum Moderator
Forum Moderator
Posts: 5479
Joined: Sun Mar 11, 2012 12:19 am
by gordon@drogon.net » Mon Jul 02, 2012 9:36 am
edyb wrote:Am I doing this all wrong? Is there a chip that I should be using to multiply the number of unique elements I can control with the GPIO pins?

Help please! Thanks!


It's certianly possible - there's no real trick to it all - the hard part is the physical wiring.

The next hard part is the software to code your potential 36 outputs and drive them - and drive them fast enough so that you don't percieve any flickering... And then Linux might get in the way and decide to do something else while you're scanning the LEDs.

However with care it's possible.

Actually, I fancy a challenge - And I can feel another Gordon Project coming up this afternoon! I should be able to drive 12 LEDs with 7 GPIO outputs (3x4 grid) Can I fit them on a breadboard though...

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by edyb » Tue Jul 03, 2012 8:28 pm
A similar related problem which I thought I'd post is my desire to control a 7-element LED array. This is the product:

http://www.rohm.com/products/opto_devic ... bp-602ma2/

It is ROHM LBP-602MA2, which has 2 numeric digits.

There is a common ground for each digit on pin 13 or 14, and the rest of the pins are to control which LED gets turned on and off. I wanted to hook up to the RaspPi and create a program which turns them on in the right order to display numbers.

It says they are 20mA or 25mA current forward to I wonder what resistors I need. I assume I would have to put a resistor in series with each and every LED of the element, I don't think they are built-in. What rating do you think is good for this based on spec sheet?

Controlling the 2-digit display would use up all my GPIO practically, even if just using 14 LED I would have to buy 14 resistors and use 14 GPIO to control them.

Any thoughts on the resistors I should be using and if I have to use one for each LED in this numeric display? I also am thinking maybe a way to save on GPIO outputs I need by using a chip driver that will accept a binary code and convert it to the appropriate LED-light-on combination to just turn on the display to the correct number based on what the binary code from RasPi is provided. Then I can use 8 GPIO... 4 for each digit to allow up to 16 possible "numbers" (only need 0...9 digits and maybe decimal point) that will be enough to run the display.
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by gordon@drogon.net » Tue Jul 03, 2012 8:48 pm
edyb wrote:A similar related problem which I thought I'd post is my desire to control a 7-element LED array. This is the product:

http://www.rohm.com/products/opto_devic ... bp-602ma2/

It is ROHM LBP-602MA2, which has 2 numeric digits.

There is a common ground for each digit on pin 13 or 14, and the rest of the pins are to control which LED gets turned on and off. I wanted to hook up to the RaspPi and create a program which turns them on in the right order to display numbers.

It says they are 20mA or 25mA current forward to I wonder what resistors I need. I assume I would have to put a resistor in series with each and every LED of the element, I don't think they are built-in. What rating do you think is good for this based on spec sheet?

Controlling the 2-digit display would use up all my GPIO practically, even if just using 14 LED I would have to buy 14 resistors and use 14 GPIO to control them.

Any thoughts on the resistors I should be using and if I have to use one for each LED in this numeric display? I also am thinking maybe a way to save on GPIO outputs I need by using a chip driver that will accept a binary code and convert it to the appropriate LED-light-on combination to just turn on the display to the correct number based on what the binary code from RasPi is provided. Then I can use 8 GPIO... 4 for each digit to allow up to 16 possible "numbers" (only need 0...9 digits and maybe decimal point) that will be enough to run the display.


You can do it with 2 resistors and 10 GPIO pins. Your program will need to work out the sequence to turn on each LED in turn based on the number each digit is to display. The down-side of this is that the program has to run constantly - stop the program (or make the program do something else!) and the display stops, or flickers.

Or you can do it with 16 resistors and 16 GPIO pins. (you'll need to use one of the serial lines as a GPIO) This way it will produce a static display, but at the expense of more GPIO pins required (and it's not expandable) (or just 14 if not using the decimal points)

Or there are shift registers you can use - one with an 8-bit output per digit would allow you to to have a static display (8 resistors per digit again)

And so on.

There are also dedicated driver chips, but these often require parallel inputs, so using more GPIO pins again. The shift-register method might be able to use as little as 2 GPIO pins per digit, or even 1 pin per digit (separate strobe) plus one pin (common data)

I did start something yesterday doing exactly this on a Pi, but work got in the way. Maybe in a few days...

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by edyb » Wed Jul 04, 2012 1:43 am
I've been looking at a few posts on Youtube about multiplexing and I thought maybe it would be possible to do so by using some transistors and flicking the LED's on really quickly in software to simulate the digital display. That works if you have the individual LEDs and can arrange them either in a matrix or to look like a 7-element LED numeric display.

However, if I used an LED numeric display already made (like the ROHM LBP-602MA2) it has all of the 8 LED's per number (7 for number and 1 decimal point) all connected to a common ground within the package. So I can't really "index" a particular LED in this package by using a matrix layout.

On the other hand, if I construct my own LED display an keep the grounds separate, I could theoretically light up any one of the group of 8 LED's using a 3x3 matrix (with one to spare). If I connect up 16 LED's for a 2-digit display then I have 16 LED's which I can index individually using a 4x4 array perfectly. Therefore I would require 8 GPIO pins total, and 4 PNP and 4 NPN transistors.

My program would know the position of each LED element in the display and turn on/off the appropriate ones based on the number one wishes to display. This would just be a translation table that knows for each number at each digit which LED's should be lit up as it maps to the 4x4 array, so my function could be made as simple as "displaynumber(var num)" and it would figure out what LED's to cycle through to display the number "num" on the display.

As long as it switches fast enough it should be able to do this without noticable flicker.

However, I am not sure based on the current part I have (with common ground) if it is possible to do this. Unless I can still create a 4x4 matrix and wire it up in a way where each node (16 in all) somehow links up to either feed current to or switch each of the LED inputs for the digital display.
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by gordon@drogon.net » Wed Jul 04, 2012 7:09 am
edyb wrote:I've been looking at a few posts on Youtube about multiplexing and I thought maybe it would be possible to do so by using some transistors and flicking the LED's on really quickly in software to simulate the digital display. That works if you have the individual LEDs and can arrange them either in a matrix or to look like a 7-element LED numeric display.

However, if I used an LED numeric display already made (like the ROHM LBP-602MA2) it has all of the 8 LED's per number (7 for number and 1 decimal point) all connected to a common ground within the package. So I can't really "index" a particular LED in this package by using a matrix layout.

On the other hand, if I construct my own LED display an keep the grounds separate, I could theoretically light up any one of the group of 8 LED's using a 3x3 matrix (with one to spare). If I connect up 16 LED's for a 2-digit display then I have 16 LED's which I can index individually using a 4x4 array perfectly. Therefore I would require 8 GPIO pins total, and 4 PNP and 4 NPN transistors.

My program would know the position of each LED element in the display and turn on/off the appropriate ones based on the number one wishes to display. This would just be a translation table that knows for each number at each digit which LED's should be lit up as it maps to the 4x4 array, so my function could be made as simple as "displaynumber(var num)" and it would figure out what LED's to cycle through to display the number "num" on the display.

As long as it switches fast enough it should be able to do this without noticable flicker.

However, I am not sure based on the current part I have (with common ground) if it is possible to do this. Unless I can still create a 4x4 matrix and wire it up in a way where each node (16 in all) somehow links up to either feed current to or switch each of the LED inputs for the digital display.


In the simplest case, you can do it without transistors.

With a single LED 7-segment digit, you can wire 7 GPIO pins to 7 resistors and wire the common to ground and off you go. You can turn on each segment individually and all that's needed is a lookup table to make segments to digits.

With 2 digits, just double up on this, but as you are seeing, you run out of GPIO pins fairly quickly.

So... Rather than that method, you wire the 7 (or 8) GPIO outputs directly to the 7 LEDs and one resistor on the common pin and wire that to ground.

Now you can light the LED segments individually by setting the GPIO on each one in-turn to 1. You can light more than one LED, but the current is halved as there is only one resistor to the brightness is affected, so you can't reliably do that.

You can put the resistors on the other side, so back to 7 resistors again and light them all at once, but it's 6 more reistors.

Doing it that way (one resistor) then allows you to have some code that lights the segments in-turn in a loop, to make up each digit - but remember to only light up one segment at a time.

The next stage is to work out how to do more than one digit. So we need a way to turn the entire digit off or on... So to do this, we can wire the common via a resistor not to ground, but to another GPIO pin. This GPIO then becomes the "enable" for that particular digit. Set it to 1 and none of the segments will light, set it to 0 and the segments enabled will light - but remember to only light one at a time.

Then, if you parallel up the 7 GPIOs to a 2nd 7-segment digit and use one more resistor and one more GPIO pin (so now 7+2 = 9 pins) you can then control which digit is enabled and which segment on that digit gets lit up.

The programming becomes slightly more complex and remember that you need to keep the program running, but you only need one more GPIO pin per digit. So with 17 GPIOs avalable, then in-theory, using the full 8 segments, you can have 17 - 8 = 9 digits. And a program running a big, fast loop to keep them all lit-up without flickering.

If you've ever seen some of the older micros - zx80/81 for example - their screens used to flicker when you pushed a key as the CPU had to stop genrating the screen and deal with the key - same for some old calculators... you'll end up with something like that unless you're very clever with the program..

An optimisation (in terms of efficiency) is to go back to 7 (or 8) resistoed per digit - then you can concurrenty light up more than one segment, however the issue then is the current your sinking into the common GPIO pin for that digit may be too much for the GPIO pin to allow - that's when you may need to use a buffer of some sort (transistor, etc.) to increase the current capacity, however it simplifies the code a little, but you still need to keep the loop going to make sure all the digits get lit-up in turn.

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by edyb » Wed Jul 04, 2012 12:52 pm
Thank you for the suggestions.

So I think I am understanding that if I use another GPIO pin instead of ground for the voltage "sink" on the ground side of my LED display, then if I set it to zero it acts as a ground? And if I set to 1 it is the same voltage as the GPIO's driving the LED display so no current flows and therefore that display is off?

In that case using one resistor between the GPIO "sinks" and display should be enough (2 resistors) and I just have to make sure I cycle my program to turn off the GPIO properly not to turn on more than 1 LED at a time to avoid passing too much voltage through to the GPIO "sink"? Otherwise as better protection maybe I should buy a resistor for each LED and put it just before each LED just in case. Resistors are cheap anyways.

I guess by wiring up in parallel then I just cycle between my two GPIO "sinks" to switch between each of my LED 7-segment displays.

I am just not sure how much current comes out of a GPIO usually, is it 3.3V considered the "1" state and 0 V considered the "0" state (which is a grounding source)? No problems with the RasPi doing this?

If that is the case, I could theoretically use the GPIO pins themselves to build up my MATRIX because I could connect say 4 GPIO horizontally and 4 GPIO vertically in a matrix to drive a 4x4 LED matrix. Then the default state of the horizontal rows can be OFF or "0" and default state of the vertical columns can be all "1". The LED will be polarized only to flow from horizontal to vertical with a resistor for each (or I can use only 4 resistors if I am cycling one LED at a time anyways).

Then I can cycle the state of a horizontal to "1" to drive the row of LED, but select which one of the LED in that row is lit by choosing a state of "0" for the GPIO that is acting as the sink in the verticals. This is in effect the same idea as using the transistors, but instead we are choosing to ground.

Any thoughts about this? That sounds like it should be pretty easy then, and we can drive 16 LED in a 4x4 matrix by cycling on/off just using 8 GPIO (4 driving the horizontals, 4 driving verticals) with nothing more than 4 resistors either placed at the start of each horizontal row or vertical column to limit current based on the LED that is being lit up.

I don't have the parts yet to try this, but planning on picking up some stuff from the electronics store soon (breadboard and a package of resistors). I have an old IDE 40-pin hard-drive ribbon cable which fits the GPIO header pins just fine and I can modify that to link up to the breadboard and have easier access to my GPIO. My 40-pin has all 40 pins accessible (it isn't the one that has a missing or blocked pin to ensure correct connection orientation)... so I can just chop off the extra or have it hanging off the end of the RasPi.
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by gordon@drogon.net » Wed Jul 04, 2012 1:35 pm
edyb wrote:Thank you for the suggestions.

So I think I am understanding that if I use another GPIO pin instead of ground for the voltage "sink" on the ground side of my LED display, then if I set it to zero it acts as a ground? And if I set to 1 it is the same voltage as the GPIO's driving the LED display so no current flows and therefore that display is off?


Yes.


edyb wrote:In that case using one resistor between the GPIO "sinks" and display should be enough (2 resistors) and I just have to make sure I cycle my program to turn off the GPIO properly not to turn on more than 1 LED at a time to avoid passing too much voltage through to the GPIO "sink"? Otherwise as better protection maybe I should buy a resistor for each LED and put it just before each LED just in case. Resistors are cheap anyways.

I guess by wiring up in parallel then I just cycle between my two GPIO "sinks" to switch between each of my LED 7-segment displays.

I am just not sure how much current comes out of a GPIO usually, is it 3.3V considered the "1" state and 0 V considered the "0" state (which is a grounding source)? No problems with the RasPi doing this?


You're limited to about 15mA per pin on the Pi - so really you don't want to have more than 1 LED lit at a time, so having one resistor is a safeguard in a way, as having one on each LED would let you light all the LEDs then they're all sinking into the GPIO pin

edyb wrote:If that is the case, I could theoretically use the GPIO pins themselves to build up my MATRIX because I could connect say 4 GPIO horizontally and 4 GPIO vertically in a matrix to drive a 4x4 LED matrix. Then the default state of the horizontal rows can be OFF or "0" and default state of the vertical columns can be all "1". The LED will be polarized only to flow from horizontal to vertical with a resistor for each (or I can use only 4 resistors if I am cycling one LED at a time anyways).

Then I can cycle the state of a horizontal to "1" to drive the row of LED, but select which one of the LED in that row is lit by choosing a state of "0" for the GPIO that is acting as the sink in the verticals. This is in effect the same idea as using the transistors, but instead we are choosing to ground.


That's exactly it. Just make sure you stick to the limits - keep just one LED lit at a time.

edyb wrote:Any thoughts about this? That sounds like it should be pretty easy then, and we can drive 16 LED in a 4x4 matrix by cycling on/off just using 8 GPIO (4 driving the horizontals, 4 driving verticals) with nothing more than 4 resistors either placed at the start of each horizontal row or vertical column to limit current based on the LED that is being lit up.

I don't have the parts yet to try this, but planning on picking up some stuff from the electronics store soon (breadboard and a package of resistors). I have an old IDE 40-pin hard-drive ribbon cable which fits the GPIO header pins just fine and I can modify that to link up to the breadboard and have easier access to my GPIO. My 40-pin has all 40 pins accessible (it isn't the one that has a missing or blocked pin to ensure correct connection orientation)... so I can just chop off the extra or have it hanging off the end of the RasPi.


The biggest issue on the Pi is going to be the software - you will need to drive that loop to drive the LEDs constantly - stop the program and the LEDs will stop being displayed.

Additionally, you might find that the LEDs are rather dim - as they're only being turned on for 1/16th of the total time (for 16 LEDs). There are ways to counteract this, and specialist driver chips to help too - you can reduce the value of the limiting resistor slightly to compensate, but you then run the risk of going over the limits for the GPIO pin drivers...

And sometimes it's easier to just use a ready-built module...

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by gordon@drogon.net » Thu Jul 12, 2012 3:19 pm
Just a follow-up on this - A bit longer than I expected due to ther things getting in the way but I've just successfully conected a 4-digit, 7-segment display up to a Pi and driven it...

Picture here:

Image

and a write-up here

https://projects.drogon.net/7-segment-led-display-for-the-raspberry-pi/

includes links to the software and a cheesy video (teenage quality)

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by edyb » Thu Jul 12, 2012 9:35 pm
I am having some trouble with the Python program controlling LEDs... It seems to be working backwards.

My program is supposed to turn on each LED high in a row of 8 LED (each on a different GPIO) and the turn on sequence has a sleep delay of half second between each turn on... So I should she each LED turn on until my whole row is lit up.

Then when all of them are HIGH, I have a loop which shuts them all off with NO delay, so should turn off all almost same time.

What happens is the REVERSE.

It's as if HIGH and LOW are reversed. All my lights are on, then when I am turning them on instead it is turning them off 1 by 1.

Is this something with my wiring? Is GPIO by default 3.3v or 0? Isn't high supposed to be 3.3 and low is 0v so since connected to GND pin 6 should be LED off?

Help!
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by gordon@drogon.net » Thu Jul 12, 2012 9:44 pm
edyb wrote:I am having some trouble with the Python program controlling LEDs... It seems to be working backwards.

My program is supposed to turn on each LED high in a row of 8 LED (each on a different GPIO) and the turn on sequence has a sleep delay of half second between each turn on... So I should she each LED turn on until my whole row is lit up.

Then when all of them are HIGH, I have a loop which shuts them all off with NO delay, so should turn off all almost same time.

What happens is the REVERSE.

It's as if HIGH and LOW are reversed. All my lights are on, then when I am turning them on instead it is turning them off 1 by 1.

Is this something with my wiring? Is GPIO by default 3.3v or 0? Isn't high supposed to be 3.3 and low is 0v so since connected to GND pin 6 should be LED off?

Help!


What is the other end of the LED connected to?

If you connect it to 0V / Ground, then the LED will light when you write 1 to the GPIO pin. If it's connected to +3.3v then the LED will light when you write 0 to the GPIO pin.

Personally, I prefer connecting the GPIO LED circuits to ground so that writing 1 turns them on, but some people will tell you that the GPIO pins are better at sinking current than sourcing it - and they may well be right, but I have to say, for simple stuff like this it doesn't really matter one way or the other... (and trivial to change in sotware anyway)

-Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1530
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by croston » Thu Jul 12, 2012 10:05 pm
If you are using RPi.GPIO 0.3.0a there is a critical bug where high and low are reversed. I suggest you upgrade to 0.3.1a where the problem is fixed.
User avatar
Posts: 449
Joined: Sat Nov 26, 2011 12:33 pm
Location: Blackpool
by edyb » Thu Jul 12, 2012 11:53 pm
Ha! I am using 0.3.0a!!!
I was scratching my head and so thanks, at least I know I am not crazy!

I will upgrade. Maybe a stupid question, how do I upgrade? Download, unzip and untar, then install?

Will it just over-write the old library? Or do I need to remove something first?

Thanks!
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by edyb » Fri Jul 13, 2012 2:11 am
...Just a follow-up...

Perhaps better to wait until the new Debian image with floating point comes out?

As far as I know, there is no way I can really migrate my existing setup easily to the new image. So I assume that I will have to copy my work-files at least (source code files) but everything else will be scrapped, including all installed programs.

With the new Debian OS image, I guess I will have to:

1. reinstall wiringPi
2. reinstall python (hopefully they put it on by default)
3. reinstall any other programs I used with apt-get...
4. copy over my folder with source code (that's the easy part)

So perhaps wait until the new image and just install Rasp GPIO to the new image and get 0.3.1 without the REVERSE high/low major flaw? And get wiringPi on that, and any dependencies?
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by edyb » Fri Jul 13, 2012 4:43 am
I uploaded a video of my setup and code here:

http://youtu.be/D3CiRmh4cE8
Posts: 29
Joined: Thu May 24, 2012 3:11 am
by Neil » Fri Jul 13, 2012 11:26 am
Look up "Charlieplexing". That will do precisely what you want.

Neil
Posts: 89
Joined: Thu Sep 29, 2011 7:10 am
by edyb » Sat Jul 14, 2012 2:23 pm
Thank you, I read up on charlieplexing and multiplexing. I also was thinking of something "in between" the two that keeps wiring more simple.... not sure what you call it.... but here it goes:

We know for multiplexing you can use 2n pins to control n-squared LEDs in a square grid, since it is the number of pins used for the column and row. Or more simply, a+b pins to control a x b LEDs (and when a=b you get 2a=a x a=a-squared). For example, 6 pins (3 row and 3 column) to control 9 LED matrix.

We also know for charlieplexing the rule is n pins for n(n-1) LED, so with 6 pins you can control 30 pins.

IN BETWEEN....

Can we use multiplexing but "double-up" on the LEDs by having a reverse bias LED together with a forward bias LED at each node? That would effectively double-up on the number of multiplexing but keep the wiring simple since it is still a grid, just with 2 LED at each node. So for 6 pins you could control now 18 LED instead of 9.

Multiplexing 6 pins = 9 LED (3x3 grid with 1 LED at each node)
"xxx"plexing 6 pins = 18 LED (3x3 grid with 2 LED, one forward one backward at each node)
Charlieplexing 6 pins = 30 LED (with a more complicated wiring pattern)

Would I just need 3 resistors still, at either the start of each row or column? No matter which LED I light up, the circuit would have to pass through a resistor.

Any thoughts?
Posts: 29
Joined: Thu May 24, 2012 3:11 am