Which controller to use?
in [Embedded]
|
From: Fevric J. Glandules on 5 May 2010 16:04 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.
From: Fevric J. Glandules on 5 May 2010 16:16 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.
From: D Yuniskis on 5 May 2010 16:38 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! :> )
From: D Yuniskis on 5 May 2010 16:56 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.
From: Tim Wescott on 5 May 2010 16:56
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 |