Selection of a USB microcontroller

ARM

...

While I'm no expert in USB stuff, I have made my fair share of mistakes. My next USB outing will certainly capitalize on what I learned from my mistakes. Here's what I found out:

The host side driver will be your biggest headache, by far. You'll need to consider it carefully. It's usually best to choose a built-in device class supplied by your host computer so you don't have to write, test, and pay for compliance testing. My efforts have only supported Windows computers but I'll bet a whole bunch of problems will surface if you choose others (like Mac or Linux).

The downsides to my suggestion are:

1. Supporting a class driver might mean extra programming on the device side to support the entire class whether you need the full functionality or not.

1. You might have trouble getting a good fit for you needs vs. what the class driver will support.

2. Specifically, if you choose the COM port emulation (usbser.sys), you'll be dogged with always wondering what the COM port is when you plug it in. I hate that problem. Love to know if there's a solution.

The upsides is you could get lucky or even pin your decision to use a specific chip if the chip maker will give you device code to do what you need (for example, Cypress PSOC and USB-UART). Lots of examples and good vendor support are key unless you're the adventurous type. Be wary of vendors that will supply the drivers. They're not always high quality.

Alternative to built-in device classes, you can go the opposite route and design your endpoint interfaces to suit your needs. It's much simpler from the device side but you'll need a driver. I've had my eye on the generic Thesycon driver. Not sure if you need to WHQL test it or not. Certainly, if you write your own driver, it takes a good bit of programming ability, tool investment, and testing requirements.

I'd like to hear other's opinion on the matter. It's all tradeoff (as usual) and how one implements is probably driven by one's talents and resources (as usual, too).

JJs

AVR + ARM

At90USB82 + LM3S301

A well behaved CDC uses a serial number and you allocate a new port for every new serial number you detect. This is not so good in a school environment where you can have a large qty of USB devices and you will eventually have a COM port allocated for each such device.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

The EVAL boards from both SiLabs and Atmel are cheap, so I'd get both, and trial both pathways. SiLabs also have boards and chips that are RS232-USB, which is another option, and can be good if your expected range of Embedded devices is wide. ST have uPSD devices with USB, if you are looking at the higher pin count end.

Above this, there are ARM devices with USB and the new Atmel AT32UC3A0512 is also capable looking silicon - but you are then getting way above

8K Flash.

-jg

"Ulf Samuelsson" schreef in bericht news:f0r6kh$ge0$ snipped-for-privacy@aioe.org...

I am a newbie on the USB front and the host side driver is something that I overlooked a bit. I definitely need Windows and Linux support.

A USB to serial convertor (in my design) might be a very simple solution.

It is not too hard to find the COM port where the device is connected to:

- scan the first 20 ports for availability (open the device)

- provide a handshake method between application and device

- for multiple devices: serial number the device with handshaking I already use this with the serial devices I developed, since I implemented a serial communications protocol.

Frank

I have had good luck with the Silabs CP2103 USB to Serial Bridge components. They provide good utility programs for low level programming of the parts. They seem to work with less problems than other Serial/USB converters.

For my serial communications, I use SerialNG:

It seems to work well with Delphi 4. There is a function that returns a list of all COM ports that have been enumerated by the PC, so you don't need to try opening all possible ports. I send out a test code and detect proper response to determine if a device is connected.

The device I developed is essentially a data collection device, operating at 2400 samples per second to read line frequency waveforms to 10 bit accuracy. My port is set for 57600 Baud. I use a Microchip PIC18F242,

14.7456 MHz clock, which divides exactly to the usual baud rates. I programmed in assembly using a reference application as a starting point. The 18F parts are designed to be used efficiently with C compilers. I have C18, but have not yet used it.

Paul

Could you elaborate on this please? Are AVRs at a given voltage and frequency more susceptible to noise than 8031 variants?

You could do worse than an 8031 variant with an FDTI USB chip.

There's also the option of user-mode drivers which are easier to implement. Libusb works on virtually all platforms, Windows Vista has WinUSB and on OS X has IOKit. There's also some commercial offerings for Windows, eg. Jungo's WinDriver.

-a

In the last year I've built several projects using the SiLabs C8051F320 and C8051F340 series full speed slave USB controllers. The 'F320 runs at 24Mhz, and the 'F340 at 48Mhz. Flash ranges from 16KB to 64KB, RAM from 1KB to

4KB, plus a 1KB USB FIFO. These work very well in small projects, since the chip has an on board oscillator (no crystal needed) and it can be USB bus powered with onboard regulator. The SiLabs website has quite a bit on reference designs and basic software, especially the USB CDC and HID class drivers. I use the SiLabs IDE with the SDCC-51 compiler, no cost and no code limits. Jack Peacock

Using an FTDI serial device will give you three big advantages. On the hardware side, you have no need for USB-specific development in hardware or firmware - you use whatever microcontroller you want, and connect up a serial port. On the PC side, you have drivers and libraries freely available for Windows, Linux, and MacOS in lots of varieties. You can choose to treat the device as a serial port (easy programming) or use the libraries (almost as easy, and giving access to extra features such as serial numbers). A third advantage is that you don't need any code on your microcontroller to get up and running - if your microcontroller can be programmed over a UART, or using a serial bit stream of some kind, then a PC program along with the FTDI chip can program your microcontroller.

"Viktor" schreef in bericht news: snipped-for-privacy@u30g2000hsc.googlegroups.com...

I now have 5 designs with ATmega processors to control high voltage DC and stepper motors. With about 2000 boards produced, we had several problems in the field, like: corruption of Flash (sometimes) and EEPROM (quite often) and flipping of bits in the fuses (5 occasions). Also brand new chips had bad fuses, so that they could not be programmed in the circuit (which could be fixed by applying an external clock oscillator).

Before I used TI's TM370 and ST's ST6 in a similar design (about 5000 produced) without any of these problems. Used about 1000 pieces of Hitachi H8S in industrial equipment where driver chips often burn out just because of earthing problems, but the processor never failed. Years ago I only developed with the 8051 and they were reliable as hell. I used them to remotely monitor and control heating pipes at the railways. Talking about a noisy environment when a train comes by! The 8051 tripped, but a reset always brought them up and running again.

Frank

in

could

I am inclined to think your board design is not EMC proof. I have designed a system with an ATmega162 which is tested according to IEC/EN60945. This also includes several tests where 2kV AC and 1kV DC transients are applied to all terminals of the device and a 6kV or 8kV static discharge is applied to the housing or in the very near vincinity of the device.

No problems were encountered, the device operated normally or recovered immediately (watchdog reset) after the test.

Meindert

"Meindert Sprang" schreef in bericht news:46370f27$0$29000$ snipped-for-privacy@dreader24.news.xs4all.nl...

At first I also thought the design was not EMC proof, but it passed all tests. We have done additional testing in extreme conditions (temperature/humidity/power) with large transients on power supply, terminals, housing and with some sabotage actions like removing shielding and grounding wires. Now there are 5 designs which are used in different pieces of equipment. Weird is that they all show similar problems.

The only thing that I really have found is that the ATmega is very sensitive about the way it is powered up and down. A slow rise and fall of power can cause corruption of the EEPROM. I modified the software to shutdown the application and processor when the power is removed, but it did not solve the problem completely.

Frank

sensitive

modified

You are using the brown-out detection on the ATmegas I assume?

Meindert

"Meindert Sprang" schreef in bericht news:46386902$0$26622$ snipped-for-privacy@dreader12.news.xs4all.nl...

Of course, but that did not make any difference.

Frank