[Tfug] OT: Arduino group?

[Bexley Hall]

Hi Adrian,

> Well, yes PICs are old technology, but they are still evolving.

Of course!  If you had seen their ancestors you would roll
on the ground doubled over:  "How could you possibly write code
on *that*??"

> Without the benefit of having actually sat down and had my hands
> on stuff yet... PICs seem to have several advantages. One, you 
> can get PICs with a multitude of 
> interfaces built in, including USB, CAN, dedicated serial,
> and ethernet. The AVRs only seem to come with USB.

You should be able to get USARTs or UARTs on either.  You will
also see more specialized interfaces for inter- and intra-
*board* communication (e.g., SPI).  These can be a win if you
are talking to other "high integration" peripherals (e.g.,
an audio preamplifier with digital controls).

> Two, It seems like you can get PICs with as 
> little as 512bytes of memory to as much as several
> megabytes. The AVRs all seem to be in the couple of KB range.

You can get AVRs with as much as 256K (assuming you mean
*program* space -- most of these processors resemble
Harvard architecture and *data* space can be considerably
less!)

> Third, as you said, Microchip has a 
> wealth of free tools and comm code for building projects.

This is usually the thing that makes them most appealing.
Easy to buy into their toolchain.

> The wide range of 
> subsets/supersets in programming the PICs (everything from
> 8pin to 40pin) 
> seemed a bit daunting though. AVRs seemed more consistent
> across the board for programming.

For most of these, you can program them "in circuit" using
a simple two or three wire interface (you may need a parallel
port, though, to do this "for free"  :> ).  The cost of adding
support for this to the circuit is usually just a small signal
transistor (2N3904-ish) and a couple of resistors.  Plus a
crude connector to gain access to those signals (in a manufacturing
environment, these things aren't necessary).

> I looked around for a while at different devel boards and
> chips. One thing I 
> want to do here shortly is build a network controlled I/O /
> sensing platform. 
> Something to read voltage, I/O, temprature, etc. and be
> remotely readable by 
> both HTTP and SNMP. Going the AVR route, I can get an
> Arduino for $40 plus a 
> network shield for $50 more... A PIC w/ethernet devel board
> is $45. A PIC 
> chip with built in ethernet MAC (sans mag/jack) was in the
> neighborhood of $7 
> from what I remember searching. A comparable AVR chip was
> something like $4 plus another $5 for an EN82J60...

These will be 10BaseT (which is probably sufficient for
your needs).  But, I caution you to think hard about what
you want to do and how you want to do it!  Your N-GHz PC
is probably 1000 times faster than these boxes!  You're
looking at maybe 1 VAX-MIPS tops from any of these little
guys.

Think about what (OSI) level you want to use when interfacing
to this device.  You might find it considerably easier to
use UDP exclusively. (skip all the TCP overhead and state)
Just doing a checksum on a 500 byte packet will take a
big piece of time for one of these guys!

Knowing absolutely nothing about your application ( :> ),
I'd suggest you look at possibly having the "remote node"
(PIC/AVR/whatever) just sit in a loop reading these process
variables, packaging the data in whatever format you decide
upon, and then blasting them out UDP to "whatever".  I.e.,
make the listener responsible for catching the data instead
of making the PIC/AVR have to listen to incoming packets,
decode messages (rebroadcasts, etc.) and *then* reply.

If you had lots of these things on a network, it would be
a horrible waste of bandwidth.  But, I suspect you would
never notice a dozen of them chirping away continuously!

<shrug>  Just a thought.
 
> So I would really like to hear from someone with build
> experience in both to 
> find out the advantage/disadvantages of each in practice.
> The easy 
> availability of Microchip libraries felt like a big
> advantage to me. But... 
> things that made me wonder. Does having the larger memory
> space really help 
> or does it just tend to get sucked up by a platform's
> less-efficient 

Download Microchips toolchain.  IIRC, it includes a simulator.
You can hack together a sample application (stub in the I/O)
and actually see how big it is and how *fast* it is.

> language? For a networked application being pinged and
> polled several times a 
> minute, does having interrupt processing really help
> responsiveness, or is a 
> continuous polling of the MAC sufficient? Are there big
> pitfalls in one vs 
> the other? I suppose these all kind of come down to, you
> just have to build 
> it and try both. Without practical experience, its hard to
> know where to jump in first.

I suspect neither option will "break you".  It's not like
you *must* meet some stringent processing requirements.
I.e., if you can only get data 10.4 times per minute instead
of 14.6... <shrug>

> > Unless I am missing an overload on the PLC term, a PLC
> > is a different beast entirely.
> 
> Yep... I meant PLCs. I have a couple projects that need
> relay/timer logic. 
> Things like controlling AC compressors and cooling towers
> or power 
> monitor/generator start/stop controls.  The hardest

This gets a bit more involved.  :<  The problem with
*controling* things is you have to plan for the possibility
that your controller will *fail*.  If you are just controlling
outdoor landscape lighting... <shrug>  BFD.

But, if you are controlling something where a controller failure
can result in injury, loss of life or significant financial
loss (e.g., you forget to turn off the pump that tops off your
swimming pool and, in addition to the high water bill, your
neighbor sues you for flooding their yard, etc.) then you have
to take extra precautions.

For example, I design all of my field interfaces so that they
"fail safe" when the system is reset.  (i.e., what happens if the
processor fails to start up?  You want to make damned sure that
something doesn't start happening randomly!)  Then, I design
watchdog circuits that can force the system into this safe state
if the system appears to be misbehaving.  The complexity of
those "sanity monitors" varies depending on what's at stake.

By way of example, a tablet press can produce a few $K of product
PER SECOND.  Furthermore, if it produces "dubious" product,
that will "contaminate" several hundred kilobucks worth of
"good" product (i.e., how can you look through a BARREL full
of tablets and find which ones are "out of spec" without examining
each of them individually?)  So, you design the system to
not allow an "insane" condition to last for more than a fraction of
a second.  And, acknowledging that the system can't physically
shut down that quickly, you also include mechanisms to divert
"dubious" product in this time period away from the "known good"
product produced prior to this incident.

You have to look at your applications and figure out just how
important "reliable control" of your field is to you.  But,
the first time you "flood your neighbor's yard", you'll
understand my admonition!  :>

Remember, most of these sorts of things run continuously.
It's a big deal to have a PC with an uptime of a few hundred days.
Imagine having to have uptimes of *thousands* of days!  :-/

[in all of these cases, I am assuming this is a personal use 
application and not something that you are peddling commercially]

> thing I have found here 
> is the availability of ethernet connections (for monitoring state), 
> everything seems to want to be Modbus or CAN, and price.

Yes.  I think Profibus may also be a player.  I have a friend who
has stacks for these interfaces but he sells them as commercial
products so you're SOL there.

> You can get a PLC 
> with ethernet/SNMP. but it will cost you $3000. Not exactly
> experimentation 
> prices. Im looking at a couple PLCs right now with 20 I/Os
> in ~$150-200 range. Modbus, no ethernet though.

Omron (?) IIRC makes some small PLC's -- the size of your
fist -- with limited I/Os.

> > Field Programmable Gate Arrays are dedicated pieces of "logic"
> > that the user "customizes".  
> 
> Yep again... Like the above, I have a number of projects Id
> love to learn and 
> dig into. Learning to use DSPs to process analog signals or
> encode data. In 
> particular, Id like to build/find a reconfigurable
> general-purpose CPU on a 
> PCI board. And a multi-input multi-monitor processing front
> end (think 
> multi-source input KVM that does PiP/PbP to multiple
> monitors). 

You can probably do that with a (very) high speed FPGA if
you deal with digital video exclusively.  Processing
analog in a KVM requires some quality electronics to
deal with those high bandwidths without distorting signals.

> Sigh.. If only I had time to play.

heh heh heh... if you're lamenting *now*, wait until you
get a bit OLDER!  :-(  :-(