how to control LED array?

--
Do you want to control only one LED at a time or any number of LEDs up
to and including all 64?
Reply to
John Fields
Loading thread data ...

Hi - I'm working on a project to make an 8x8 LED array. The idea is that the anodes in each row are tied together, and the cathodes in each column are attached together, giving me 16 pins which I can control 64 LEDs with. But now the only problem is making sure they get the right current/voltage? My plan is to only have one column turned on at any given time, but then any number of the 8 LEDs in that column could be on at that time, so things get a little difficult. I could apply 0 and 5V then just have a current limiting resistor on each LED, but that would be cumbersome and awkward. My end goal is to be able to drive this with 16 pins from a microcontroller. Hopefully I'm being somewhat clear about what I'm asking. Does anybody have any suggestions as to how I could do this? Thanks so much,

Michael J. Noone

Reply to
Michael Noone

John Fields wrote in news: snipped-for-privacy@4ax.com:

Hi Mr. Fields - I'd like to control as many at a time as possible. My plan was to control one column at a time, and cycle through each column about

100 times per second. Does this seem like a good path to take, or is there a better way to accomplish this? I thought that this method would allow the board to be fairly simple (anode traces on the top of the board, cathode traces on the bottom), and would be fairly easy to control (just 16 control lines). Thanks,

-Michael. J Noone

Reply to
Michael Noone

the

control

As you cycle through each column, only one LED per row is on at any given time. You would put your limit resistors in the row line after an appropriate driver. You are multiplexing the array. I suggest you use a 1 of 8 demux chip such as the

74138. The chip is fed by a binary counter. You clock the counter with 1 bit from your port. This saves IO lines. You can create a clock on the Data Strobe* pin 1 of the parallel port. Any clock rate over 16 or so pulses per second is no necessary as the eye will blend the image. Faster is not better as it gives you a shorter time slot in which to write the active LEDs. You can read the counter overflow on one of the input bits such as paper empty.

There are also specialty chips for doing this very thing to sets of such displays. Maxim comes to mind, I think their chip, in no decode mode, will handle 128 lamp columns. That is 16) 8x8 arrays.

Reply to
Lord Garth

current/voltage?

things

My

have

You have the right idea. With the 8 cathodes connected to the 8 column lines, you have the micro make one column at a time go low, the one being lit. All the others are high. Sequencing through the columns at 100 times per second is fine. It should be fast enough that you can't see flicker. Now, the anodes, row lines can be driven so that only one led is on at a time which means that only one of 64 led's is lit at a time but this makes a dim display. A better solution is to turn on all of the rows for all of the anodes needed in any given column at once and leave them on for the duration of that column. To turn on the anodes make them high and off low, the opposite of the column drives which are on low and off high. In this way up to 8 LED's may be on at a time in one column and the LED's are on for 1/8 of the total time. Since only one column is on at a time, only 8 current limiting resistors are required and they are placed on the row drivers for the anodes. As you sequence through the columns, you set up the required row pattern to light the LED's of each column in turn. There are many ways that this can be set up but one way is to mirror the matrix in memory. This would take 8 bytes with the bit patterns representing the rows. As the columns are sequenced through, the bytes are transferred one at a time, in turn, to the row port. Bob

Reply to
Bob Eldred

The problems I see with doing it

--
John Fields
Professional Circuit Designer
Reply to
John Fields

--
If we set up a 4X4 array for the sake of simplicity, then using your
row-column scheme with common anode rows would yield this:
 Click to see the full signature
Reply to
John Fields

"Lord Garth" wrote in news:lKWae.354$ snipped-for-privacy@newssvr30.news.prodigy.com:

I can't believe I never realized that. Now it seems so simple and obvious - but before I was struggling trying to figure out how to limit current.

Correct me if I'm wrong though, but wouldn't that require an extra two chips? I had been thinking that if I wanted to decrease control lines I could use an 8b shift register with parallel output to drive them.

I should mention that I don't plan on using a computer to drive this array - my plan was for it to be entirely microcontroller driven.

Do you have any idea of a part number for such a chip? I looked through their LED display driver chip section, but most all of them looked more like they were designed for controlling digits, not arrays. Also - any idea if any would be able to do PWM? Does this chip perhaps look right?

formatting link

Thanks,

-Michael Noone

Reply to
Michael Noone

John Fields wrote in news: snipped-for-privacy@4ax.com:

I don't entirely follow your calculations here. If you had the current limiting resistors on the row drivers, wouldn't you then want to turn on column by column so the current limiting resistor would only be limiting current for 1 LED? (as mr Garth suggested) That way you wouldn't have to worry about not all 8 LEDs being on. Also, I'm not entirely sure how you're getting the voltage that you'd need to dissipate? I was thinking that you'd subtract (2 * Vcesat + Vled) from the supply voltage (5V). So wouldn't that be 5 - 2 * 0.4 - 2.0 = 2.2V?

Again - why would you use a resistor on the set of 8 LEDs being driven, instead of one per driven LED? I expect you do have a reason for this - I just am having trouble figuring out what it is.

I believe most AVRs (the type of uC that I'm currently using) can sync about 30ma on each I/O line. Certainly 3ma would not present even the slightest problem.

Mr. Fields - thanks for all your help. You have helped me in the past as well, and your help is always very much appreciated.

Best regards,

-Michael

Reply to
Michael Noone

I disagree on the refresh rate. Having just experimented with PWM on some RGB LEDs, I can attest to the fact that 40Hz refresh is easily visible as flicker at very low duty cycles. You _will_ see the annoying flickering. I suggest using at least 80Hz for completely flicker free operation. Before you get all upset, I know it seems awfully high compared to what's acceptible for TV and movies, but I assure you that the flicker is much more visible on the LEDs. There is plenty of advice on the net about using refresh rates around 100Hz for this very reason. Just commenting for the benefit of the OP.

Of course if the OP doesn't need low intensity levels, then a slower refresh may be fine.

Reply to
Anthony Fremont

V+ 2N4403 | +--------+--------+--------+-[13R]-C E-------+ A| A| A| A| B | [LED] [LED] [LED] [LED] | | _ 1,1| 1,2| 1,3| 1,4| +----[R]--|---> 400Hz. Duck soup. However, it also means that since each LED will

--
Yes, of course, and they _are_ on the row drivers, although they were
shown in the wrong place. I showed them on the emitters of the 2N4403s
 Click to see the full signature
Reply to
John Fields

I was just thinking that a column multiplexing scheme as opposed to a row multiplexing scheme would be more likely to show strobing as one drove by. Is this indeed the case? (not that this is at all a concern to the OP and his 8x8 array)

Reply to
Lord Garth

way to

somewhat

since

on

annoying

free

that

advice

reason.

I don't know if that would make any difference. My experiments were with only one LED and flickering was clearly visible at >40Hz refresh combined with low duty cycles. [I was using a software based 8 bit PWM routine (~25mS period with ~100uS resolution)] When I upped the clock speed to 8Mhz so that the period was ~12.5mS with ~50uS resolution the flicker was not visible to me even with a 1/256 duty cycle. I was also surprised by the brightness of the LED at 1/256 duty cycle, it was clearly visible.

Disclaimer: I know that a linear duty cycle is not the most appropriate method of PWM driving an LED, but it was easy to implement. With the ISR running every 50uS, you don't have allot of time to jack around. ;-)

Using an 8Mhz internally clocked 16F88, I was able to achieve my goal of imperceptibly varying the colors of an RGB LED, in a rainbow like fashion, without generating shades of grey, or taking a week to cycle thru all 16 million combinations. No biggy, but it looks allot better than those cheesy things with the built in color sequencer. ;-) My 10 month old daughter really likes the effect and IMO it's going to look really good on my scooter as full-color, adjustable accent lighting.

8-)
Reply to
Anthony Fremont

Remember that certain color lights are illegal on personal vehicles...regulations vary however.

Reply to
Lord Garth

goal of

cycle

better

10

look

Yep, but that's only when in motion on the road. And certain colors are only illegal from certain directions. AIUI, the law (here in TX) is such that the lights need to be directly visible to be considered illegal, hence the lights are carefully mounted so that only the reflection is visible (accent style). Of course that doesn't hurt the looks of things either. ;-)

Since I want adjustable colors, I should be able to pick a nice color like yellow/green or amber (no real limit on those lights) for maximum visibility when riding and then a nice magenta, cyan, deep blue or the ever popular rainbow effect for parking. :-)

I also made a little doo-dad to replace the factory turn-signal module. It maintains full backward compatibility, has smarter self canceling, and converts the rear turns to running lights using PWM. The blink rate is insensitive to the bulb load (like God intended ;-) and the bulb drivers are short-circuit proof. It also has a nifty strobe mode for maximum attention grab _and_ 4-way flashing.

FWICT, the DOT regs (fed and state) don't care if I strobe the turns instead of flashing them at a regular interval. They seem to only care about the number of flashes per minute, not their regularity. I guess that's why there's a ton of non-emergency vehicles on the road with strobing turn signals.

If a stupid, chickensh*t, p*ssy hobbyist can build stuff like this with a PIC, just think what someone with half a brain could do.

;-D

Reply to
Anthony Fremont

Why the heck don't you post your circuits and source code...there have been questions regarding rainbow effects in the past. Besides, I'd like to see how you protect the PIC from the crappy power in a car.

Reply to
Lord Garth

"Lord Garth" wrote

like

TVSP's are probably the best things that I know of, but a nice choke, some series resistance, a Zener or two followed by a 5V regulator and some more filtering mixed with plenty of bypass caps should do it for you with a PIC. Commonly available high side drivers are responsible for the output magic. Resistance, bypass caps and Zeners on input lines to feed 12V signals into 5V inputs. May be kinda sloppy, but it works well enough. The so-called nano-watt series PICs can be very unforgiving of power supply issues.

While I've given up some good code for public usage in the past, the stuff for my turn-signal doo-dad is not for free. Too much effort combined with real commercial value. I posted a version of my rainbow LED code to A.B.S.E.

Reply to
Anthony Fremont

I got the post thanks....

For me, I don't plug things in until the car is running. Once, my cap dried up and exploded. That car smelled for quite a while.

Reply to
Lord Garth

Maxim 7219?

formatting link

Dave

current/voltage?

things

My

have

Reply to
Yoda

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.