Which controller to use?

1 Lucky Texan wrote:

> As others have pointed out, this 'could' be a project with more
> ramifications than are immediately apparent. How 'robust' does it
> REALLY need to be.

<snip>

All good questions, thanks.

Tim Wescott wrote:

> I _do_ think that there's a huge advantage to using standard methods, 
> and bluetooth is pretty darn standard.  Make your gizmo talk bluetooth, 
> then your customers can go read it with an industrial hand-held 
> computer, and you're done.  

I'm in agreement, although they seem reluctant to go that way.

I can understand their thinking.  "All" that is needed is a passive
memory device - a sneakernet - to get information from the office
to the control unit and back again.  (Wifi would be great except
for the range required.  Wimax would probably be great except for
the cost and that the technology doesn't seem stable).  But USB
is *not* designed for the outdoors.

Hi Fevric,

Fevric J. Glandules wrote:
> D Yuniskis wrote:
> 
>> Likewise, use of a conventional "relay" requires some sort
>> of hammer driver *somewhere* (either on the board or in some
>> intermediary circuitry) whereas a solid state relay can more
>> readily be driven from a logic output.
> 
> By "hammer driver" do you just mean what I'd call an electromagnetic
> relay?

A semiconductor device *intended* to drive the coil of an
electromagnetic relay.  This can be something as simple
as a Darlington...

>>> I don't know yet, but "not very big".  A few hundred K at most?
>> There are ~5K characters on a sheet of paper; ~2K on a CRT "screen".
> 
> Sure - my estimates are based number of RFID tags to deal with
> (of the order of a hundred) and bytes per tag (four?) for the
> settings; for reports, perhaps 16 bytes per tag per day.  But
> I don't know.

Understood.  You know your application better than any of
*us*!  :>

>> If that is the case, you might consider just storing raw data
>> on a *smaller* memory device and letting the "elsewhere" device
>> deal with formatting it and printing it.  This can have some
> 
> Oh, absolutely; for an embedded system it never crossed my mind
> not to have a reasonably well-packed format.  Probably not worth
> trying to bit-pack or compress, but you never know.
> 
> [output]
> 
>> Ah, so maybe even just an LED that "winks"...?
> 
> Yup, although IME doing something "simple" like a winking
> LED or a beep buzzer is a whole load more complicated than 
>   LCD_writestr("Calibrating...");
> assuming, of course, that you have a board and library that
> provides this.

Of course you can provide whatever API you think you
need.  And, that will depend on the actual device(s)
that you use for your indicator/display, etc.  E.g.,
if you don't want to have to bother with a timer job
that does:  lamp on - delay - lamp off - delay - repeat
then you can always purchase an LED that blinks by itself.

>> <grin> The point of my questions is to get you to think of
>> options you can present to your client and the tradeoffs
>> they could give you (him).
> 
> <grin> The point of my asking here is to get people like 
> you to ask questions like this. So far I think many of the
> issues raised here simply haven't been considered; the people
> involved are newbs to embedded control systems.  I've got 
> some experience, but by and large I've been handed hardware
> and asked to write code for it.

<frown>  Unfortunately, that happens far too often.
I prefer looking at the entire application and then
making the hardware-software tradeoffs myself.  I.e.,
some things it is silly to "spend (hardware) money on"
(e.g., a low speed UART could be done with bit-banging)
whereas other things are *essential* (when you run
out of RAM, there's not much else you can do!  :> )

Hi Fevric,

Fevric J. Glandules wrote:
> Tim Wescott wrote:
> 
>> I _do_ think that there's a huge advantage to using standard methods, 
>> and bluetooth is pretty darn standard.  Make your gizmo talk bluetooth, 
>> then your customers can go read it with an industrial hand-held 
>> computer, and you're done.  
> 
> I'm in agreement, although they seem reluctant to go that way.
> 
> I can understand their thinking.  "All" that is needed is a passive
> memory device - a sneakernet - to get information from the office
> to the control unit and back again.  (Wifi would be great except

Are you sure that they are thinking *exactly* along these
lines?  I.e., that the USB device is *just* a "transport device"
and *not* a "storage device"?

In other words, your box operates *without* the "thumb drive"
installed and accumulates data *internally*.  The thumb drive
is introduced *just* to copy the data out of your device and
transport it to some other device that "prints it" (likewise,
it transports "settings" from some external device *to* your
box).

[N.B., you might want to *retain* the "old data" within your device
to cover the case where the copy-to-thumb-drive fails -- or the
thumb drive gets lost, etc.  You can always externally track
which data you have printed vs. "new data" -- i.e., let your
external application disregard the "old data" that it sees *again*
in the thumb drive]

In this (transport) case, you can possibly come up with a
weatherproof connector (behind a rubber gasketed door, etc.)
that is "always" protected from the environment *except*
for the minute or two that the thumb drive is present.

OTOH, if the thumb drive *is* your "data storage" device,
then it must be connected at all times -- different problem
to solve.  :<

Returning, again, to the "transport" approach...

You can argue that, instead of carrying a thumb drive
to the box, you can carry some "wireless enabled" device
instead.   E.g., I have a WiFi PDA and a WiFi phone that
I use to talk to wireless devices so that I can make
them "headless", otherwise.

In your case, (depending on budget, sophistication,
market, etc.) you might suggest bluetooth but supporting
a profile that a "typical" cell phone would be able to
pair with -- perhaps even an iPhone?  Depending on your
market, the "wow factor" might be worth something...

Or, a zigbee (or bluetooth) dongle that plugs into a
laptop's USB port, allows the laptop to talk to the
"box" (user interface for all those "settings", etc.)
to fetch history data and deliver configuration data.

In *any* case, you also have to look at the consequences
of folks tampering with the box via the "interface"
(be it USB or wireless).  What happens if someone introduces
bogus configuration data (safety, liability, security, etc.).
And, what happens if someone harvests data from your
device -- is there anything exposed there that *shouldn't*
be?
> for the range required.  Wimax would probably be great except for
> the cost and that the technology doesn't seem stable).  But USB
> is *not* designed for the outdoors.

Fevric J. Glandules wrote:
> Tim Wescott wrote:
> 
>> If you want success, you MUST make sure that the hardware you specify 
>> can do everything you ask of it.  This is not a trivial task if you 
>> don't want to way overdesign the processor.  
> 
> Something I really really should have said: "low-volume, high-margin".
> Not too fussed if we overspec the control module to the tune of 
> a hundred dollars.

For $150 in small quantities you can get a PC-104 processor board with 
an ARM, running Linux.  That'll have a USB stack, and Bluetooth as well, 
if you want.

It has the potential to save you loads of development time, and you can 
play video games on it as well, as long as you don't mind building them 
from source.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

D Yuniskis wrote:

> Hi Fevric,

Yo D,

> Fevric J. Glandules wrote:
>> 
>> By "hammer driver" do you just mean what I'd call an electromagnetic
>> relay?
>
> A semiconductor device *intended* to drive the coil of an
> electromagnetic relay.  This can be something as simple
> as a Darlington...

<cowers>
I am but a simple software endjuneer.  I set the bit to one,
it goes on.  Unless it's the other way round.
</>

> Understood.  You know your application better than any of
> *us*!  :>

Hah!  I've abstracted it a bit, but otherwise I am pretty
much in the dark myself.

> that does:  lamp on - delay - lamp off - delay - repeat
> then you can always purchase an LED that blinks by itself.

That's an interesting thought.  But really I think 
"we" want an off the shelf controller module of some
sort.

> <frown>  Unfortunately, that happens far too often.
> I prefer looking at the entire application and then
> making the hardware-software tradeoffs myself.  I.e.,
> some things it is silly to "spend (hardware) money on"
> (e.g., a low speed UART could be done with bit-banging)
> whereas other things are *essential* (when you run
> out of RAM, there's not much else you can do!  :> )

I, too, insist on the "big picture".  The tradeoffs 
are often in the numbers - basically, "how many of
these things do you want?"

Right now, we're talking prototype; in any case I get
the impression that it's low-volume, high-markup, which
means off-the-shelf everything.

Tim Wescott wrote:

> For $150 in small quantities you can get a PC-104 processor board with 
> an ARM, running Linux.  That'll have a USB stack, and Bluetooth as well, 
> if you want.

Power *might* be an issue there.  I know ARMs run at low power, but 
how much does the whole module take "on standby"?

D Yuniskis wrote:

> Fevric J. Glandules wrote:
>> I can understand their thinking.  "All" that is needed is a passive
>> memory device - a sneakernet - to get information from the office
>> to the control unit and back again.  (Wifi would be great except
>
> Are you sure that they are thinking *exactly* along these
> lines?  I.e., that the USB device is *just* a "transport device"
> and *not* a "storage device"?

Pretty sure.

<snip>

> In this (transport) case, you can possibly come up with a
> weatherproof connector (behind a rubber gasketed door, etc.)
> that is "always" protected from the environment *except*
> for the minute or two that the thumb drive is present.

Even *with* a rubber gasket it's bound to end up full of goo.

<snip>

> In your case, (depending on budget, sophistication,
> market, etc.) you might suggest bluetooth but supporting
> a profile that a "typical" cell phone would be able to

Oooh.  Bluetooth smartphone.  I like it.

Development cost, OTOH...

> In *any* case, you also have to look at the consequences
> of folks tampering with the box via the "interface"
> (be it USB or wireless).  What happens if someone introduces
> bogus configuration data (safety, liability, security, etc.).

To give credit to the original spec writer(s), they'd already
flagged this as an issue.

Hi Fevric,

Fevric J. Glandules wrote:
> D Yuniskis wrote:
>> Fevric J. Glandules wrote:
>>> By "hammer driver" do you just mean what I'd call an electromagnetic
>>> relay?
>> A semiconductor device *intended* to drive the coil of an
>> electromagnetic relay.  This can be something as simple
>> as a Darlington...
> 
> <cowers>
> I am but a simple software endjuneer.  I set the bit to one,
> it goes on.  Unless it's the other way round.
> </>

Yes.  My point is in how you go looking for this "board".
I.e., you can get a board with a bunch of CMOS/TTL outputs
routed to a connector; or, some number of those connected
to "transistors" capable of switching bigger loads (like
relays); or, opto-isolators that give you one of the
above two scenarios but with the advantage of isolating
the "load" (relay, etc.) from your logic; or a board with
actual *relays* on it.

The more you put *on* the board, the fewer choices you
have (in terms of COTS solutions).  OTOH, the less you put
on-board, the more interconnects, modules, etc. you will
need.

In any case, to the software, it's "just a bit" (well,
actually, some designs might require you to periodically
stroke that "bit" as a safety factor -- so the motor
or whatever shuts off if the processor looks like it
may have become "distracted")

>> Understood.  You know your application better than any of
>> *us*!  :>
> 
> Hah!  I've abstracted it a bit, but otherwise I am pretty
> much in the dark myself.
> 
>> that does:  lamp on - delay - lamp off - delay - repeat
>> then you can always purchase an LED that blinks by itself.
> 
> That's an interesting thought.  But really I think 
> "we" want an off the shelf controller module of some
> sort.

You can still hook a "flashing LED" to a digital output
(since the LED would presumably be mounted off-board
so it could poke through a window in the enclosure)

>> <frown>  Unfortunately, that happens far too often.
>> I prefer looking at the entire application and then
>> making the hardware-software tradeoffs myself.  I.e.,
>> some things it is silly to "spend (hardware) money on"
>> (e.g., a low speed UART could be done with bit-banging)
>> whereas other things are *essential* (when you run
>> out of RAM, there's not much else you can do!  :> )
> 
> I, too, insist on the "big picture".  The tradeoffs 
> are often in the numbers - basically, "how many of
> these things do you want?"
> 
> Right now, we're talking prototype; in any case I get
> the impression that it's low-volume, high-markup, which
> means off-the-shelf everything.

Present informed opinions to customer/client. Let them
decide on what the actual product needs to be (since they,
ultimately, know the market "best" -- or, *should*!)

On May 6, 9:43=A0am, "Fevric J. Glandules" <f...@invalid.invalid> wrote:

> That's an interesting thought. =A0But really I think
> "we" want an off the shelf controller module of some
> sort.

Such a board is unlikely to have relays in the mix you need - so a
simple daughter/slave board is usually done.

 Be very cautious deploying mechanical relays, if at all possible, use
Power fets, or even solid state relays.
 - lower power, and the arcing contacts in relays, can
have unexpected consequences.

-jg