[Tfug] OT: Arduino group?

[Bexley Hall]

Hi Adrian,

> That's a third from me... Im trying to get time to play with
> AVR/Arduino or PICs and perhaps some PLCs and FPGAs. Someone with
> practical experience that could explain the differences would be 
> great (not the obvious architecture 
> differences, but "real life" needs in hardware for
> accomplishing various tasks).

PICs are *ancient* devices that started off as (jokes?) in
General Instrument's product offerings (i.e., they were very
low end devices when every other manufacturer was coming out
with increasingly more powerful 8 and 16 bit processors.
(GI is no more.  Enter Microchip; same company, different face?)

The big win for Microchip was giving away development tools for
these devices (the devices themselves are rather inexpensive as
well).  Other MCU/MPU vendors would typically require $1K to get 
started with an assembler/linkage editor/compiler/debugger
package (or more!).  Microchip also went further and made
"inexpensive" in system emulation tools available whereas
other MCU/MPU products could run as much as $25K/seat for
a hardware emulator (granted, these typically had far more
bells and whistles than the microchip offerings).

The PICs have really funky architectures.  Lots of things
are clumsy in a PIC (e.g. manipulating the stack frame).
And, other things are severely limited (some PICs have
fixed size stacks -- recursive subroutines become tricky
as you have to limit depth of recursion a priori, etc.)

AVR makes a better (? subjective) type of PIC-class machine
but plays to the same "low end" market.  Note that both vendors
offer a variety of products so not all of them are "crippled".
As such, they can get you to buy in to their product family with
a low end freebie and later migrate to a more powerful
(capable) product.

Unless I am missing an overload on the PLC term, a PLC is a different
beast entirely.  Programmable Logic Controllers are typically
used in process control applications complete with their own
I/O's suitable for interfacing with standard field wiring
(e.g., 4-20mA loops, volt-free contact closures, etc.).  They
can get very expensive (high end Allen Bradley systems).
They are often geared towards deployment by non-CS people.
E.g., Allen Bradley uses "ladder logic" -- sort of like designing
an electromechanical pinball machine (the application and controller
are modeled as relays and contact closures, process variables,
etc.).  Often, these are implemented with custom bit-slice processors
that interpret the ladder logic in real time to run the user's
"program" (i.e., ladder logic diagram).

Field Programmable Gate Arrays are dedicated pieces of "logic"
that the user "customizes".  You can create any logic function
using a sum-of-products (or, alternatively, product-of-sums)
implementation.  Add to that some clocked logic (registers)
and you can build a sequential machine that examines inputs,
applies some logic and drives outputs based on an algorithm
encoded *in* that logic.  (some FPGAs are reprogrammable;
some are dynamically reprogrammable!).

All of these require some sort of interface circuitry to
get to/from the real world.

For example, reading a switch can be as simple as putting a pullup
resistor on an input and letting the switch short that input to
ground.  But, this requires a switch that can handle low voltages
reliably *and* some design accommodation for switch "bounce"
(switches don't close cleanly -- instead, they close... open for
a short time... close for a short time... open again... etc.
until they finally close "permanently".  The whole cycle may take
as little as 10ms -- but, if that switch is controlling a counter,
then that counter may think the switch has been closed, OPENED,
closed again, OPENED again, etc. many times in that 10ms interval!).

Switches can be debounced in hardware (RC delays, cross coupled
devices, etc.) or "software" (i.e., build a state machine that
incorporates time in its state transition map).  You can also buy
"bounce free" switches (silly waste of money as the alternatives
are cheaper)

OTOH, if that "switch input" comes from a hostile source
(e.g., something that might have higher voltages impressed on it
*or* even something as "harmless" as static electricity from
a person walking across the rug on a dry AZ winter day), then
you have to take extra measures to protect the rest of the
circuitry that the switch/input *feeds* -- lest you toast it!

The same sort of issues apply on the output side.  First, the
outputs from logic devices are low voltage (a handful to a dozen
volts) and low current (micro to milliamperes).  Second, the
drive capability of many logic families is assymetrical
(e.g., an output may be able to sink/source more current than
it can source/sink).  You might also want some degree of isolation
between the control circuit and the things it controls (e.g,
if you are trying to control the pump motor in your hot tub!).

But, you also have to protect your control circuit from nasty 
things that can happen on the load side.  E.g., you don't want 
something creeping in and frying your control logic.

To be pedantic, you also have to deal with intentional
hostile acts that you might be exposed to.  E.g., slot machines
are a continuing target for hackers trying to "game the system".
So, your circuit might be exposed to things you'd never
rationally considered.  E.g., someone keying their cell phone
in close proximity to your circuit to try to overload some
sensitive circuitry and thereby cause the system to misbehave
in a way that benefits *them*.

<shrug>  Hard to give an exhaustive explanation of the issues that
differentiate these different things.  If you have specific
questions about a particular type of interface, I'll try to help.

--don