Which controller to use?
in [Embedded]
|
From: Fevric J. Glandules on 5 May 2010 10:43 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.
From: 1 Lucky Texan on 5 May 2010 11:29 On May 5, 9:43 am, "Fevric J. Glandules" <f...(a)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?
From: Tim Wescott on 5 May 2010 13:28 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
From: D Yuniskis on 5 May 2010 14:10 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
From: Fevric J. Glandules on 5 May 2010 16:03
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. |