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?
> 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. The 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
>
If you go with a 32 bit AVR like the AT32UC3A0xxx,
you will have a USB OTG.
There is WiFi support from H & D Wireless - http://www.hd-wireless.se/
There are several 8 bit AVRs with USB - AT90USB1287.
Best Regards
Ulf Samuelsson
> ROM / RAM / CPU requirements are going to be modest by today's
> standards. We'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?
Reply by 1 Lucky Texan●May 7, 20102010-05-07
On May 6, 3:52=A0pm, "Mark Moulding"
<m...@markesystems.no.damn.spam.com> wrote:
> "Fevric J. Glandules" <f...@invalid.invalid> wrote in messagenews:hrrb2r$=
> use the boxed products)
> 2) Price was quite competitive
> 3) Support was awful - bad enough to turn me off from ever using them aga=
in.
>
> Just my experience - maybe I hit them on a bad day (couple of months,
> actually). =A0Also, this was several years ago - they may have gotten
> better...
>
> Also, have you considered ZigBee as a wireless protocol? On the down side=
,
> you'll need a hardware interface of some sort on your PC (as opposed to
> BlueTooth, which is so often built in now). =A0However, development is re=
ally
> easy, the cost is low, and the range is a bit better than BlueTooth.
> --
> Mark Moulding
There is (was?) a pantech phone with zigbee and there are some
handheld remotes (maybe AMX?)
Perhaps an infra-red interface could work?
Reply by Mark Moulding●May 6, 20102010-05-06
"Fevric J. Glandules" <fjg@invalid.invalid> wrote in message
news:hrrb2r$eob$1@news.eternal-september.org...
<..>
Just a quick data point: I've used the Tern products, and found that:
1) The quality was average, at least for the board-level devices (we didn't
use the boxed products)
2) Price was quite competitive
3) Support was awful - bad enough to turn me off from ever using them again.
Just my experience - maybe I hit them on a bad day (couple of months,
actually). Also, this was several years ago - they may have gotten
better...
Also, have you considered ZigBee as a wireless protocol? On the down side,
you'll need a hardware interface of some sort on your PC (as opposed to
BlueTooth, which is so often built in now). However, development is really
easy, the cost is low, and the range is a bit better than BlueTooth.
--
Mark Moulding
Reply by Meindert Sprang●May 6, 20102010-05-06
"D Yuniskis" <not.going.to.be@seen.com> wrote in message
news:hrtjja$a81$1@speranza.aioe.org...
> The biggest issue is the BT stack. You can either purchase one,
> develop one or use an "open source" solution.
For a low volume/high cost device, I'd suggest the use of BT modules like
the ones form Ezurio. They support the Serial Port Profile and are as easy
to use as a modem through AT commands. BT stack is in the module, no
development cost and, even more important: no approval cost/issues since
these modules are sold and appoved as an End Product. You only need to stick
the supplied labels that come with each module on next to your own type
sticker on your device are you meet all the RF requirements in almost every
country.
Meindert
Reply by D Yuniskis●May 6, 20102010-05-06
Hi Fevric,
Fevric J. Glandules wrote:
> 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.
You might strongly hint at the possibility of users failing to
understand this (and any consequences it might have for you
or it)
>> 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.
Yup. Any holes in a case are problem areas -- buttons, connectors,
indicators, etc.
>> 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...
The biggest issue is the BT stack. You can either purchase one,
develop one or use an "open source" solution.
You can also go other wireless routes -- e.g., 900MHz "modem".
There are also some devices suitable for low frequency short
hops -- like the distance between a laptop user and your device.
You have to look at the application and its market and decide
which "fits right".
>> 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.
Good luck!
--don
Reply by -jg●May 5, 20102010-05-05
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
Reply by D Yuniskis●May 5, 20102010-05-05
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*!)
Reply by Fevric J. Glandules●May 5, 20102010-05-05
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.
Reply by Fevric J. Glandules●May 5, 20102010-05-05
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"?