Which controller to use?
in [Embedded]
|
From: Tim Wescott on 4 May 2010 17:56 FJG 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. 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 > > 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? 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. Find out everything that the thing needs to do, budget the RAM/ROM/bandwidth for it, determine if it has to be done simultaneously with everything else, and work from there. Asking the thing to be a USB host -- as pointed out -- will drive the cost up. _If_ you can find a USB host stack (check with Micrium) that will run on an 8/16 bit processor, it'll require more processor resources (maybe someone will chime in, with experience?). Talking to SD cards has a _much_ lighter footprint, although you still have the connectors outdoors issue. 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. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Frank-Christian Krügel on 4 May 2010 18:22 Am 04.05.2010 22:01, schrieb FJG: > 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 You really should try to replace the USB memory stick by a MMC/SD card. USB is a rather complicated interface, and for using USB sticks you'd need to implement an USB host, which is even two magnitudes more complex than an USB device. Just say no! Don't do it. MMC cards are rather simple to talk to. SD cards are basically MMC cards plus copy protection mechanisms, so just use them as MMC cards. > 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? The processor core doesn't matter much. Choose your controller by the built-in peripherials needed. The really cheap segmented bare LCD glasses found in clocks and calculators need a special peripherial, but there are enough controllers that have that already built-in. If you compare prices you'll notice that there is little difference between bigger 8 bit controllers and the smaller 32 bit controllers, which are much faster. Families to look at: AVR (very C friendly architecture which good community support) PIC12/14/16/18 (very ancient C unfriedly architecture, but cheap, broad choice of built-in peripherials, compilers are buyware) PIC24 (very C friendly, has nothing to do with the 8 bit PICs, DSPIC familiy with extended DSP capabilities) PIC32 (powerful MIPS core plus PIC24 peripherials) ARM Cortex M1/M3 (core made by various manufacturers so it's easier to change to a different mfg, widespread support, good free compilers+debuggers; many many enhancements to the older ARM7 architecture) TI MSP430 (well-known for energy efficiency, less peripherials than AVR or PIC) 8051 (ancient architecture, but still widespread, different mfgs) -- Mit freundlichen Gr��en Frank-Christian Kr�gel
From: -jg on 4 May 2010 20:14 On May 5, 8:01 am, FJG <f...(a)invalid.invalid> wrote: > - USB memory stick to upload new settings, download reports > weatherproofed - will operate outdoors, off 12V DC Those two are in conflict. Might be smarter to find a RF link to a USBkey+Netbook, or similar so you can extract the data in a cordless way. Something like this ? https://www.silabs.com/products/wireless/wirelessmcu/Pages/Si1000SynapseWirelessModule.aspx -jg
From: Paul Keinanen on 5 May 2010 01:22 On Tue, 4 May 2010 20:01:36 +0000 (UTC), FJG <fjg(a)invalid.invalid> wrote: >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 What is the environment temperature range ? You may have to select the components based on the temperature range. LCDs will not work well in a hot environment. You may have to derate the controller power consumption e.g. by running it well below maximum frequency or reduce the output currents for digital outputs etc. Weatherproofing will also make it harder to get rid off the dissipated heat, thus the box inside temperature can be much higher than the environment temperature.
From: D Yuniskis on 5 May 2010 02:44
FJG wrote: > 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 I assume you mean you'll use an RFID reader that "talks EIA232" to your "board"? I.e., all you need is a UART (?) > output - solenoids / relays to turn a motor on 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.? > I/O - USB memory stick to upload new settings, download reports 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.e., how will they be *read* "elsewhere"? Could you put a small application elsewhere to interpret raw data and pretty-print it?) > control panel - three buttons and possibly a cheap LCD display What sort of display -- 7 segment, full graphic, color, etc.? > optional - WiFi interface What happens over the WiFi interface? Can you use other wireless protocols? Range? Data rate? > weatherproofed - will operate outdoors, off 12V DC Usually, weatherproofing happens in the *enclosure* choice. However, if you have other environmental extremes that will pertain to the board as a consequence of this, you will need to identify/quantify them (e.g., what sort of ambient temperature range *inside* the enclosure -- taking into account power dissipated by the board, power supply, etc.) > 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. How big is the tag data? Can you just store a hash of that or do you need to store the actual tag itself? I.e., are you concerned with a "foreign" tag being interpreted as one of your 200 "bonafide" tags? 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"? > 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? Depends on power requirements (range), etc. From what little you've said, I'd look at something like ZigBee as your data rates are probably low and power consumption would be a bigger issue. Depending on what you plan on "talking to" over the wireless, you could also conceivably remote the user interface, data store, etc. on the other end of the wireless link (e.g., build a "black box" that only has relays, RFID reader and wireless as it's "I/O's" -- let everything else be injected or displayed "remotely") <shrug. Hard to be more specific without specifics. |