Which controller to use?
in [Embedded]
|
From: Fevric J. Glandules on 5 May 2010 17:43 D Yuniskis wrote: > Hi Fevric, Yo D, > 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. </> > 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. > <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.
From: Fevric J. Glandules on 5 May 2010 17:50 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"?
From: D Yuniskis on 5 May 2010 18:12 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*!)
From: Fevric J. Glandules on 5 May 2010 18:09 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.
From: -jg on 5 May 2010 18:41
On May 6, 9:43 am, "Fevric J. Glandules" <f...(a)invalid.invalid> wrote: > That's an interesting thought. But 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 |