Which controller to use?

USB in any embedded device is a bit nuts, but I digress.

You are not going to find USB master on a poor 8/16-bit micro.

Only 32 bit devices have USB master.

So, if you think your doing to get it cheap........

Everything else is doable with any micro-controller ( or two ).

Google for WinAVR, free tool chain and Atmel AVR family is very robust.

I have done two products with these tools.

hamilton

You mean like a Cortex-M3 for south of $2, or a Cortex-M0 for south of $1?

Not with usb host. With host functions, pins and costs go up, not that they are correlated.

I'm sure 32 bits is fine.

Sure. What I'm looking for is a module / single-board computer / whatever you want to call it that will provide as much out of the box as possible. Even some sort of "hobbyist" kit would be fine if it provided 12V relays for controlling motors, debounced buttons, a small LCD output, etc.

E.g.

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.

Am 04.05.2010 22:01, schrieb FJG:

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.

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)

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 ?

-jg

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.

I assume you mean you'll use an RFID reader that "talks EIA232" to your "board"? I.e., all you need is a UART (?)

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.?

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?)

What sort of display -- 7 segment, full graphic, color, etc.?

What happens over the WiFi interface? Can you use other wireless protocols? Range? Data rate?

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.)

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"?

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")

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.

Yes, this seems like a major issue to me.

Can you find a "contactless memory stick"?

Yup. I really want a drop-in box or board:

Thanks for your other tips.

Good points Paul.

Whatever is easiest!

I don't know yet, but "not very big". A few hundred K at most?

Yes.

Cheap! We may even use a buzzer to provide the necessary user feedback instead.

Unique ID.

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.

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?

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.

"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.

There are ~5K characters on a sheet of paper; ~2K on a CRT "screen".

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.

Ah, so maybe even just an LED that "winks"...?

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

By "hammer driver" do you just mean what I'd call an electromagnetic relay?

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.

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.

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.

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.