On 18/06/2013 23:15, Chuck Guzis wrote:
On 06/18/2013 11:16 AM, Tony Duell wrote:
let me ask you a simple quesiton. You have to
flash an LED at about 1Hz
-- the exact frequency is not important. Nor is the duty cycle (within
reason). You also have a suitable supply line (so no need to consider 3
terminal regualtors, etc)
Now, off the top of my head there are 3 obvious solutions (there are
many
more too, of course ) :
A discrete component multivibrator -- 2 transsitors, 4 resistors, 2
capacitors, LED
A 555 astable --555 Timer IC, 3 resistors, 1 capacitor (2 if you are a
purist and want to decouple 'control voltage), LED
An 8 pin microcotnroller, 1 resistor, LED
Which of those 2 you consider to be the simplest?
I count 3 choices.
None of the above. A UJT, capacitor and resistor with LED would be
simpler than your 2-transistor gizmo. A DIAC (or other suitable
4-layer diode) would be even slightly more simple. Perhaps a nitonol
wire comprising a thermal switch might even be simpler.
Now, let's talk about what's most flexible (i.e. bang for the buck).
The 8 pin MCU can generate *precise* pulses with a *precise* duty cycle.
Heck, you might even be able to get rid of the resistor if you
employed some PWM on the output, such that average maximum ratings on
the LED weren't exceeded.
EDN (ISTR) had a column on this subject last year concerning replacing
a 555 with 8 bit MCUs. It was a lot of "it depends", as I recall--and
no clear winner.
For ONE LED all of these solutions are OK. So soon as you want 20 LEDS
at different frequencies you are into FPGA (or perhaps CPLD) territory.
Depending on total power consumption a typical FPGA will flash as many
LED's as there out-put pins at most any frequency that can be derived
from the master oscillator, typically 50Mhz. I think
the FPGA is a
wonderfull device, and these days you can interface it your PC via
USB
or RS-232...
Actually, the
'friendly votlage levels' could be a minus-point in
that it
is likely a USB interface conenctor is connected directly to some large
and complex IC, while an RS232 port will almost certainly invlove a
simple buffer IC or two. So that if you accidentally connect too high a
voltage to the cable, in the case of USB you have a lot of work to
do, in
the case of RS232 it's one cheap IC that will take a few minutes to
replace (even if soldered in).
Interesting--I've seen more EIA 232 line receivers zapped by ESD than
USB devices, but that could be because 232 has been around longer.
RS232 seems susceptible to getting popped. I think the default
MC1488/MC1489 chips were very easily popped.Also RS232 is good for much
longer line lengths. When I worked at NERC (
www.nerc.ac.uk) we had
several sites in the Thames Valley and the thunderstorms would follow
the river popping the driver chips on the way. There was a map in one of
the Radio Society of Great Britain hand books showing the desnity of
thunder storms. The Thames Valley figured high on that as well....
And the USB
protocol is significantly more complex than RS232 and
that to
me is a major disadvantage _where the extra capabiliities of USB are not
needed__. As an interface to large-ish remveable memory devices it
seems
fine. As am interface to a fairly low-speed ADC system it seems
ridiculous.
But who lives in a world where a single person writes both sides (host
and client) software for a given USB application?
My point is that as a general purpose-common-as-dirt interface, USB is
hard to beat these days, whether you're trying to push 50 bits or 50
megabits per second down the line.
20 years ago, the picture was not the same.
--Chuck
--
Dave Wade G4UGM
Illegitimi Non Carborundum