PIC / PICAXE-controlled LED Beat flasher

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 :P

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:

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:

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 :P"

:-? 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 :P)

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.