Re: PIC / PICAXE-controlled LED Beat flasher


"Anthony Fremont" <spam-not@xxxxxxxxxxx> wrote in message
news:12tpmhu70t9hff0@xxxxxxxxxxxxxxxxxxxxx
John Barrett wrote:
"Anthony Fremont" <spam-not@xxxxxxxxxxx> wrote in message


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.

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 !!)

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.


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

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

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

needs no external components except limit resistors, and multiplex
takes 3 transistors.. one for each color bank... too simple !!)

True, if you have a ton of spare pins.

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


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


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.

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

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 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?

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

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

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)

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

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




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.


hehehe the same algorhithms will work on a PIC or an AVR... I program

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.

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


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 !!)

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

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 !!



.

Relevant Pages

  • Re: PIC / PICAXE-controlled LED Beat flasher
    ... supply all the current you need to drive 8 LEDs. ... To learn how to use them, and to save on pin count. ... selection from level meter code, and enables the level meter code to ... running CPM from external 8" floppy drives. ...
    (sci.electronics.design)
  • Re: PIC / PICAXE-controlled LED Beat flasher
    ... supply all the current you need to drive 8 LEDs. ... all 3 banks act identically as a 0-10 level meter when a given bank is ... selection from level meter code, and enables the level meter code to ... external 8" floppy drives. ...
    (sci.electronics.design)
  • Re: PIC / PICAXE-controlled LED Beat flasher
    ... microcontroller switches to the next colour bank of LEDs.. ... is a level meter with 10 level divisions, ... and enables the level meter code to work correctly no matter ...
    (sci.electronics.design)
  • Re: led dimmer circuit
    ... This current source drives a current through R3 and R4 ... and thereby sets the linearly adjustable voltage to the base of Q2, ... Q2's emitter voltage sets the current through R5 and therefore also ... be used, though, if several LEDs are to be used in series. ...
    (sci.electronics.design)
  • Re: led dimmer circuit
    ... This current source drives a current through R3 and R4 ... and thereby sets the linearly adjustable voltage to the base of Q2, ... Q2's emitter voltage sets the current through R5 and therefore also ... be used, though, if several LEDs are to be used in series. ...
    (sci.electronics.design)