EmbeddedRelated.com
Forums

Which controller to use?

Started by FJG May 4, 2010
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
"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
"Fevric J. Glandules" <fjg@invalid.invalid> wrote in message
news:hrrb2r$eob$1@news.eternal-september.org...
<..>
> 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
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
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$=
eob$1@news.eternal-september.org...
> <..> > > > Yup. =A0I really want a drop-in box or board: > >http://tibbo.com/products/controllers/ds10xx/ds1004.html?gclid=3DCKCMtJ.=
..
> >http://www.tern.com/portal/content.asp?contentid=3D701 > > 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 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?
FJG skrev:
> 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?
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?
check this rfid 'toy' interface; http://vimeo.com/6698128