Connect with us

PIC / PICAXE-controlled LED Beat flasher

Discussion in 'Electronic Design' started by Johnno, Feb 21, 2007.

Scroll to continue with content
  1. Johnno

    Johnno Guest

    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.
     
  2. John Barrett

    John Barrett Guest

    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.
     
  3. Johnno

    Johnno Guest

    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.
     
  4. John Barrett

    John Barrett Guest

    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 !!
     
  5. Johnno

    Johnno Guest

    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
     
  6. John Barrett

    John Barrett Guest

    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)
     
  7. linnix

    linnix Guest

    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.
     
  8. 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
     
  9. John Barrett

    John Barrett Guest

    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 :)
     
  10. John Barrett

    John Barrett Guest

    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)
     
  11. 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.
     
  12. John Barrett

    John Barrett Guest

    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.
     
  13. BTDT, no fun.
    He really hasn't told us what he's building exactly, maybe it's a secret.
    ;-)
     
  14. Johnno

    Johnno Guest

    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?)
     
  15. 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.
     
  16. John Barrett

    John Barrett Guest

    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 !!
     
  17. John Barrett

    John Barrett Guest

    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 !!)
     
  18. 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. ;-)
     
  19. John Barrett

    John Barrett Guest

    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 !!
     
  20. 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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-