PIC / PICAXE-controlled LED Beat flasher

Hi everyone,

I want to build a gadget to flash 3 different groups of ten LEDs - to
be controlled by a microcontroller. I want these flashes to be
determined by the level of an audio signal (peak 5v.) So, in short, I
am looking for an easy-to-program microcontroller device with a built
on A/D converter that will accept a max 5v AC signal.

Any suggestions?
Thanks.

 

PIC and AVR both have A/D converters, and there are free programming tools
for both. My preference is for AVR because there is a free C compiler -- I
hate working in BASIC !!

Even the smallest versions of these processors have more than adequate I/O,
and most have internal oscilators so you dont have to mess with crystals.
Speed is limited without the xtal -- usually 1mhz -- but these are RISC
chips, so 1 million instructions per second -- which is more than adequate
for A/D stuff and and integer version of the FFT to detect the bass beats..
if it turns out you need a little more UMPH !! -- add the crystal and take
it up to 8mhz or better depending on the specific chip. All have on board
timers which makes clocking the A/D sample rate easy, and while most all
have PWM outputs, there are some with THREE pwm outputs, which would be
interesting if you wanted to modulate the intensity of the LEDs rather than
just flashing them.

Pretty much all these features and variations are available either the PIC
or AVR, so its really more a question of what languages you are comfortable
with, and what development tools are available, as both chips are about
equally easy to program for.

No matter which you choose, I strongly suggest getting the hardware
developers kit for the one you choose -- saves you the trouble of having to
debug both hardware and software at the same time.

 

Great! I am familiar with C so I'll check out the AVRs.

Seeing as I am planning on having three banks of colours, with 10 LEDs
for each colour, that makes up a total of 30 LEDs which I need the
controller to be able to switch on or off. Any ideas on what hardware
would be suitable for an application like this?

Perhaps something like the following: Microcontroller >----
(serial output, perhaps)------>Serial to bit decoder-->LED Drivers

Thanks very much for your involvement,
John.

 

Keep the serial port free for printing debug information.. there is more
than enough digital I/O pins to control the LED banks (enough to do a dozen
or more LED banks of on/off control if you want to get crazy with this) ...
the cpu will directly drive the base/gate of an NPN darlington or N channel
mosfet, connecting or disconnecting the ground from the LEDs as needed..
pick your darlington or fet based on the total current for the bank of
LEDS.... (if the current is low enough, an NPN transistor would be plenty,
but I've done a few stepper and servo motor controllers and am used to
working with high currents)

For simple on/off control, just flip the right I/O bit.. for intensity
control, drive the transistor/fet from one of the PWM outputs -- the longer
the duty cycle of the PWM output, the brighter the LEDs will shine.

Since you seem to like the AVR -- there is a site called AVRFreaks that has
LOTS of sample source code including PWM LED drivers and other LED related
code. Just download the code and go to town -- lotsa nice folks there that
can help out if you need some help solving programming issues !!

 

Thanks again, although I need to be able to independently control 30
different LEDs. Either I didn't explain this clearly .. or.. do AVRs
really support 30 seperate outputs? (By bank I simply mean a group of
partiular coloured LEDs, I did not mean for this to cause confusion

Cheers
John

 

If you use one of the 40 pin AVRs, you could most certainly get 30
individual outputs (the chips have 4 ports of 8 bits each), but for a 3 bank
application, you are better off using one bit to drive one mosfet (I
recommend the International Rectifier HEXFET) for each bank.. if you have a
12v supply voltage available, run your LEDs for each bank in series with a
current limiting resistor between the LED chain and the power supply.. hook
the other end of the chain to the HEXFET, which will connect the LEDs to
ground when commanded to do so by the microcontroller.

If you dont have 12v available, or if you are using LEDs with a high forward
voltage drop, run them in parallel with a limit resistor for each LED.

The LEDs that we used for the light bar had a drop of about 1.7v and we had
6 per bank... needed about 10 volts.. so we ran them in series with a limit
resistor off the unregulated 12v car voltage and it kept the wiring simple
(limit resistor was computed for a 14v power supply to make sure any
spikes from the car didnt blow the LEDs, at the cost of a little brightness
when the voltage was lower)

 

Total driving power would be a problem. You can probably drive a few
high power LED directly from each AVR. You can do as we do:

Running an ARM master micro, which can crunch FFT like peanuts
(perhaps 20 to 30 per second). Using Jtag to control slave AVRs.

In this setup: http://linnix.com/boards.jpg

4 I/O pins from the ARM (lower left) jtag control 20 pins of the AVR
(upper right, showing back side only). The plan is to have
additional chains and additional AVR per chain. Namely

ARM -> AVR -> AVR -> AVR
\> AVR -> AVR -> AVR

By the way, the AVRs are unprogrammed, just jtag enabled.
The ARM is programmed with USB Jtag.

 

Even the smallest micro should be able to handle this by using external
shift registers (like the 74hc595 for example). You clock the bits out
serially (only takes a few pins (1 for clock, 1 for data, 1 for latching).
By chaining the shift-registers together, you could drive scores of LEDs
like this and update them many, many times per second (like thousands ;-).
If you use a micro that has built in SPI, you can really go fast.

This should be helpful:
http://www.windmeadow.com/node/20

 

If you are going to use the ARM as the math work-horse, there is no reason
not to use to to drive the fets for the LEDs -- no need for multiple
processors -- just extra hassle -- I havent looked at the latest stuff from
Atmel, but they are supposed to have chips with on-board DSP, floating
point, etc -- just depends on what you need

Besides -- Johnno wants a beat detector -- if he does a 256hz analog low
pass on the inbound audio before sampling, he'll only need 512 samples per
second, broken up into 8 segments of 64 samples to feed to the FFT.. that
would give him something around 4hz resolution on the FFT output and a small
enough dataset to keep the computations reasonably fast with an integer
FFT... dont really need the full accuracy of a floating point FFT for this
task. That would give him the ability to detect up to 8 beats per second,
and some discrimination ability to decide which beat to trigger on by
keeping a rolling event list to see what repetitive events have occured..
that would let the code automatically adjust to changes in the music. And
with a little extra work, respond to transient musical events

And if thats a little too much for the AVR -- there is still plenty of room
to back down the filter and sample rate to reduce the FFT load on the
processor while still covering most of the frequencies produced by the
drummer

 

But the problem isnt controlling lots of LEDs -- he only has 3 banks (10
leds each) .. so he only needs one output per bank -- besides --- using a 3
to 8 decoder and 8 bit latches will get you 64 bits of output using only 12
bits of microcontroller I/O.. or you could use I2C i/o chips (256 per I2C
bus, 8 bits per chip) and get 2048 bits of control.. either solution is much
simpler to deal with than shift registers, and the shift register setup
would have the pattern shifting across the banks as you moved the bits along
to their proper position .. or were you going to add a blanking circuit to
keep the LEDs turned off while you shifted the data ??

The problem is detecting the beats so the lights sync to the music..... Once
you got that under control, controlling LEDs is a no-brainer (even with
neet little tricks like PWM brightness control and such that would make this
really cool)

 

I must be dense, but I could swear that the OP keeps telling you that he
needs 30 separate outputs.

"Thanks again, although I need to be able to independently control 30
different LEDs. Either I didn't explain this clearly .. or.. do AVRs really
support 30 seperate outputs? (By bank I simply mean a group of partiular
coloured LEDs, I did not mean for this to cause confusion "

:-? He hasn't really mentioned that part yet. I don't mean to be rude but,
for all we know so far, he is making a linear 30 LED audio level detector
using 10 green, 10 yellow and 10 red leds. AFAIK, he hasn't mentioned
anything about frequency detection yet. I could be wrong, but I think he
just wants independant control of 30 LEDs. Hopefully the OP will tell us
more.

 

OK -- I admit it -- I'm brain dead -- I'm on the tail end of an all-nighter
that I just had to pull for work

So -- to answer the question.. yes -- using any of the 40 pin AVR chips, you
can easily drive 30 individual LEDs with no external circuitry except for
current limiting resistors... the I/O ports on the AVR can sink enough
current for a single LED easily.

and if all he wants is level detection, thats a breeze too -- somehow I got
the impression he was trying to do a "color organ" from the initial
description.. not a level meter.

 

BTDT, no fun.

He really hasn't told us what he's building exactly, maybe it's a secret.
;-)

 

Haha hey guys.. this topic has turned into something larger than I
originally anticipated! How wonderful!
Anyway.. back to the task at hand. My intention is to have a red bank
with 10 LEDs.. which act as a level meter, connected to an audio
source which (like was mentioned before) will have any frequencies
above around 150-250 Hz cut off. Once the level reaches a certain
amount (say, to drive the 6th, 7th, or 8th Red LED) the
microcontroller switches to the next colour bank of LEDs.. so that it
is a level meter with 10 level divisions, that changes colour on the
beat (in theory )

I must admit that I have zero experience with microcontrollers, and I
expect the building time of this project to be long, with small pieces
completed at a time. Although, I have patience on my side, and with
the resources and helpful communities available to me on the net I am
confident about getting help.

If the AVR could directly drive 30 LEDs (Keeping in mind that it only
has power up to 10 at any one time) , is there an appropriate AVR that
could drive 10x25mA LEDs? (250mA, hmm.. perhaps?)

 

Ok, got that.

Ah, that'll make John and linnix happy, but I'd probably make an active low
pass filter using two op-amp sections. It's not hard to pass say 120Hz
fine, yet be down >30dB/octave above that. I can give you a schematic if
you want, just pin down the cut-off frequency.

Hmm, I hate to say this, but you can probably do all this without a micro
and without too much trouble.

Ahh, well good then, you want to use a micro. You'll get no qualms from me
on that.

I think you should still use shift registers. A 74HC595 should supply all
the current you need to drive 8 LEDs. Since you can clock them at up to
100MHz, it should be fast enough for you. ;-) Just try reload it at least
60 - 70 times second. Don't let anyone tell you that 20 or 30Hz PWM update
rate is fast enough, it's flicker city. I don't use AVRs myself (no reason,
just started with PICs first), but any PIC with an ADC can easily take a
reading thousands of times per second.

Though you see numbers like that allot around the net, 25mA is an awful lot
of current for most LEDs. Are you using some that really require that kind
of current. I have a bunch of blue LEDs that will hurt your eyes at only a
couple of mA. I have a "super bright" green one that seems to violate the
known laws of thermodynamics, no trouble seeing that one outside on a bright
sunny day. ;-)

You didn't really explain how you want the other 20 LEDs to behave exactly.
Do they act as two groups that behave like first, but only respond to higher
audio levels?

Sorry I can't help you too much on the AVR front, but if you want to use a
PIC and do it in assembler, I'll give you a hand.

 

If you were to bank them, use an NPN or NPN Darlington transistor externally
to switch the ground connection, so as not to stress a single pin of the AVR
too heavily... One LED per pin is no problem, in fact, thats what the
STK-500 developers board provides for its visual output -- 8 LEDs with
current limiting resistors tied directly to the port pins.

For your application -- you will want an 8515 or any of the other 40 pin
AVRs. There is a comprehensive index of the available AVR chips on
AVRFreaks, along with links to the datasheets -- take a peek -- you'll see
what I mean about plenty of port pins available... all except a very few
pins for power and the serial port (which you will want for debugging) are
fully functional I/O pins .. even the reset pin can be used as an I/O. It
may look like the pins are taken up by other functions, but thats only if
you enable those functions, which you wont need to do

You could get tricky and do it with a smaller AVR and 13 I/O pins -- use 3
pins with a PNP transistor each to switch the positive voltage to the
correct color bank, then tie the ground pins of the LEDs in sets of 3 (one
LED of each color) to an I/O pin of the AVR -- that would simplify the
wiring dramatically and make it easier to test the code in a modular
fashion -- you could get the level meter function working with just 10 LEDs
before worrying about the color switching.

hehehe and if you went with the multiplexed idea and if you get one of the
chips with 3 pwm timers, you can modulate the PNP transistors to control the
LED intensity on top of everything else !!

Anyway -- thats about as far as I go on this one unless you need help with
schematics or code to make it fly !! (EaglePCB and the GNU AVR C compiler
are your friends -- get to know them well !!)

Good Luck !!

 

30hz ?? why so slow ?? I run PWM at 10-100khz or better for my servo motor
controller -- no flicker here !! (hardware PWM generator -- not software !!)

And why add shift registers when you can direct drive or multiplex and save
the chips and the code needed to drive them ?? (direct drive needs no
external components except limit resistors, and multiplex takes 3
transistors.. one for each color bank... too simple !!)

Your eyes are incredibly more sensitive to green than they are to blue and
red -- found that out when I was researching color balancing for RGB laser
show systems.

all 3 banks act identically as a 0-10 level meter when a given bank is
enabled.. when a sufficiently strong pulse of sound is detected, then the
meter function switches to the next color bank -- this makes the multiplex
idea especially attractive since it seperates color selection from level
meter code, and enables the level meter code to work correctly no matter
what color is currently selected. the level meter code will not have to be
aware at all of the current color selection. (with the direct drive, the
level meter code would have to use a different set of I/O pins for each
color.. with shift registers -- well thats just getting overly complicated
for something like this)

hehehe the same algorhithms will work on a PIC or an AVR... I program both
so it doesnt matter to me except that I prefer the AVR for its features, and
the free C compiler !! I got burned out on assembly programming YEARS ago
doing 8047 and 8051 microcontrollers, with a dash of Z80 and 80186 on the
side (and to think.. the PC had only been around a coupla years at that
point !!)

 

That's why I told him NOT to use a rate that low. ;-) I don't think
hardware PWM would be a big help here, but maybe I'm missing something.
When using these things, it seems like one always has to keep thinking
outside the box, that's what I love about them.

To learn how to use them, and to save on pin count. My way only needs three
I/O pins.

True, if you have a ton of spare pins.

That's true, but I think that 14,000mcd plays a part too. ;-)

I'll have to take your word for it, he was a bit vague on this for my
comfort level.

And using FFT and a DSP isn't overly complicating the problem? As I see it,
the "level meter code" has one purpose in life, and that is to return the
level of the signal (I assume by using an R/C low pass operation to average
the incoming signal and then using an ADC to read the average level). It
should have no idea what happens to the information after that, much less a
notion of banks of LEDs.

The main level code that called the "level meter code" should make the
determination of which bank to select based upon the returned value. I
would then have seperate code that had no purpose in life other than to turn
on the LEDs that it was commanded to do so. I would use an 8 pin PIC, some
op-amps to process the audio, and four shift registers to drive the LEDs for
about $5 not counting the LEDs. But that's me and the way I see it.

Not written in assembler they won't. And translating would not be a piece
of cake. I only do assembler on the PIC, no C. I have done C on 8051 and
it's alright, but most things I tinker with don't require tons of code so
assembler is ok. It would be nice to have readily available math routines
sometimes though. I've been thinking about tinkering with some of the
neato ARM thingys available now, I would likely use C on those.

My first "personal computer" was a COSMAC ELF I built in 78, and it still
works believe it or not, all 256 bytes of it. ;-) The first PC I saw was
when I was a youngster in the military, I saw IBM PCs running CPM from
external 8" floppy drives. Seems that M$ was late delivering DOS 1.0 and
IBM couldn't let the hardware sit, so they delivered them without an OS.
Some enterprising individuals figured out how to make use of them until DOS
came out. You should have seen the documentation that came with each
machine, amazing. Back then I even saw the original idea that apple later
ripped off to make the MAC, the XEROX Star. Multiplexing is OK, but as soon
as the OP changes his mind about only one bank being on, it's all over. Use
the shift registers. ;-)

 

even the smallest AVR and PIC have 13 I/O pins (unless you get one of the 8
pin parts -- does PIC still have one of those in production ??)

13 pins isnt a lot on an 18 pin device -- nicely utilizes the available
resources

sounds like the super whites we used for the light bar -- I think they were
like 100kmcd
(I didnt handle the LEDs -- just the code)

You are right, the FFT/DSP was overkill -- a result of Johnno saying he
wanted to "detect a beat" which says to me something like the sound
activated DMX systems that can be configured to make state changes on the
sound of bass drum, cymbals, snare, etc

and algorithm is an algorithm -- essentially platform independent -- how you
interface it to the hardware, THATS another story

BROTHER !!! The elf was my first also -- though I didnt build mine -- bought
it used from a neighbor.

If he changes his mind, thats not my problem, I tailored the solution to his
specifications, changes mean contract addendums and MORE MONEY

Gonna go eat -- catch y'all later !!

 

The 12F683 is a cool 8-pin part. Don't be fooled by the 12F it's really a
16F core, but Microchip has funny schemes about numbering. I recently
posted some code and schematics in ABSE using one. Believe the chip is far
more capable than I demonstrated.

LOL It sure does, hope you didn't want to do anything else. ;-)

I know nothing about doing that, I would like to learn to use CPLDs or FPGAs
whichever is the best thing right now, seems like it might be CPLDs.

Of course, but you know what I mean.

Later, me too.