Which controller to use?

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.

> Talking to SD cards has a _much_ lighter footprint, although you still 
> have the connectors outdoors issue.

Yes, this seems like a major issue to me.

> You can buy Bluetooth modules; if you can find one that doesn't put too 
> much strain on the processor this may be way less expensive than USB, 
> and is contactless.

Can you find a "contactless memory stick"?

Frank-Christian Kr�gel wrote:

> The processor core doesn't matter much. Choose your controller by the 
> built-in peripherials needed.

Yup.  I really want a drop-in box or board:
http://tibbo.com/products/controllers/ds10xx/ds1004.html?gclid=CKCMtJTLuqECFdGX2AoddHvpBg
http://www.tern.com/portal/content.asp?contentid=701

Thanks for your other tips.

Paul Keinanen wrote:

> You may have to derate the controller power consumption e.g. by
> running it well below maximum frequency or reduce the output currents
> for digital outputs etc. 
>
> Weatherproofing will also make it harder to get rid off  the
> dissipated heat, thus the box inside temperature can be much higher
> than the environment temperature.

Good points Paul.

D Yuniskis wrote:

> Do you need these on the board?  Or, hammer drivers?  Or,
> just a bunch of "digital outputs" that you will ultimately
> interface to some OPTO-22's, etc.?

Whatever is easiest!

>  From your description of the role of the tags, I assume your
> settings only require a few KB, at most (e.g., 10 bytes per tag).
> How big are these reports?  Do they have to be created in ASCII

I don't know yet, but "not very big".  A few hundred K at most?

> (i.e., how will they be *read* "elsewhere"?  Could you put
> a small application elsewhere to interpret raw data and
> pretty-print it?)

Yes.

> What sort of display -- 7 segment, full graphic, color, etc.?

Cheap!  We may even use a buzzer to provide the necessary user 
feedback instead.

> Can the tag itself contain the "amount of time to turn the relay
> on for", etc.?  Or, is it just a R/O tag that you treat as a
> "unique identifier" used in an associative array paired with
> the "on time data"?

Unique ID.

> shrug.  Hard to be more specific without specifics.

Indeed.  As I said it's still a bit wooly but thanks to you and 
others here I have some pertinent questions for the client.

If I've not answered some of your questions it's probably because
at this time we simply don't know.

On May 4, 3:01=A0pm, FJG <f...@invalid.invalid> wrote:
> As a coder I've usually had custom hardware to work with and
> the choice of architecture etc has been cost-driven and set
> in stone long before I start trying to debug the board...
> but I digress.
>
> I have a potential project coming up, where I may have
> some influence on the hardware. =A0The spec is of necessity
> still slightly woolly, so my apologies for that in advance.
>
> The basics are
> input - RFID tags, info probably read over RS-232
> output - solenoids / relays to turn a motor on
> I/O - USB memory stick to upload new settings, download reports
> control panel - three buttons and possibly a cheap LCD display
> optional - WiFi interface
> weatherproofed - will operate outdoors, off 12V DC
>
> ROM / RAM / CPU requirements are going to be modest by today's
> standards. =A0We're talking about, say, 200 RFID tags to recognise,
> each of which has an individual setting for the amount of time
> to turn the relay / solenoid on for.
>
> So any suggestions for a single board microcontroller that'd
> provide the above at reasonable cost, with the minimum of hassle,
> with a (preferably free) C toolchain?
>
> Personally I think the idea of a USB port on an outdoor piece
> of equipment is a bit nuts, so any suggested alternatives?
> Bluetooth?

Though some of their boards are likely overkill, winsystems.com DOES
have Zigbee on a board or 2(with usb, 422/485 and 232 of course).
Plus, they have had a customer place their equipment in railyards to
read rfid off of boxcars and other equipment run 'tolltags' on
roadways. Do you have your own enclosure?

1 Lucky Texan wrote:

> Though some of their boards are likely overkill, winsystems.com DOES
> have Zigbee on a board or 2(with usb, 422/485 and 232 of course).
> Plus, they have had a customer place their equipment in railyards to
> read rfid off of boxcars and other equipment run 'tolltags' on
> roadways. Do you have your own enclosure?

Not yet.

On May 5, 9:43=A0am, "Fevric J. Glandules" <f...@invalid.invalid> wrote:
> 1 Lucky Texan wrote:
> > Though some of their boards are likely overkill, winsystems.com DOES
> > have Zigbee on a board or 2(with usb, 422/485 and 232 of course).
> > Plus, they have had a customer place their equipment in railyards to
> > read rfid off of boxcars and other equipment run 'tolltags' on
> > roadways. Do you have your own enclosure?
>
> Not yet.

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. If a unit takes a lightnng strike, is run over by a
vehicle or it's watchdog is rebooting after a power fluctuation, will
a 'missed read' put property at risk? or endanger people? You might
need a lwayer to draw up a seriously boilerplated contract. Will the
client handle theri own servicing? what skill level persons will be in
charge of that? Will they need to keep 'turn key' replacements/spares
on hand(probably best for remote/outdoor installations) or will they
do board level repairs. Will you handle RMAs/repairs? What warranty
will they expect. How 'dirty'/stable is the availble power? Will there
be multiple languages involved in use or training?

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.
> 
>> Talking to SD cards has a _much_ lighter footprint, although you still 
>> have the connectors outdoors issue.
> 
> Yes, this seems like a major issue to me.
> 
>> You can buy Bluetooth modules; if you can find one that doesn't put too 
>> much strain on the processor this may be way less expensive than USB, 
>> and is contactless.
> 
> Can you find a "contactless memory stick"?

Not here in my office, but that doesn't mean much -- I'm mostly an 
algorithm guy who understands the wider issues.  So I don't keep tabs on 
all the latest gizmos and gadgets.

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.  Make your gizmo with Fred's Fly-by-night 
Wireless Memory Technology and when he goes out of business because all 
your competitors are using bluetooth, you're out of luck.

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

Hi Fevric,

Fevric J. Glandules wrote:
> D Yuniskis wrote:
> 
>> Do you need these on the board?  Or, hammer drivers?  Or,
>> just a bunch of "digital outputs" that you will ultimately
>> interface to some OPTO-22's, etc.?
> 
> Whatever is easiest!

"Easy" can have different consequences.

E.g., if you want the relays on-board, you'll need those relays
sized to handle that load.  This can limit your choices (depending
on the characteristics of your load).  If you move the relays
off-board, then you have more flexibility in picking the board
(*and* more flexibility in picking the relays!).

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.

And, the character of the load (as well as how you want to switch it)
has consequences on the "relay" (or SSR) chosen.

>>  From your description of the role of the tags, I assume your
>> settings only require a few KB, at most (e.g., 10 bytes per tag).
>> How big are these reports?  Do they have to be created in ASCII
> 
> 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".

>> (i.e., how will they be *read* "elsewhere"?  Could you put
>> a small application elsewhere to interpret raw data and
>> pretty-print it?)
> 
> Yes.

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
advantages as you can change *that* software (PC based?)
presumably a lot easier than changing the firmware inside your
device.

>> What sort of display -- 7 segment, full graphic, color, etc.?
> 
> Cheap!  We may even use a buzzer to provide the necessary user 
> feedback instead.

Ah, so maybe even just an LED that "winks"...?

>> Can the tag itself contain the "amount of time to turn the relay
>> on for", etc.?  Or, is it just a R/O tag that you treat as a
>> "unique identifier" used in an associative array paired with
>> the "on time data"?
> 
> Unique ID.
> 
>> shrug.  Hard to be more specific without specifics.
> 
> Indeed.  As I said it's still a bit wooly but thanks to you and 
> others here I have some pertinent questions for the client.
> 
> If I've not answered some of your questions it's probably because
> at this time we simply don't know.

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

HTH

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?

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

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

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