My original prototypes were developed on an Atmel ATmega168, with the PC comms going via a USB-Serial converter. This week I’ve been migrating to a microcontroller with native USB support, the Atmel ATmega32U4. For this first round of USB development, I’m using an Adafruit breakout board.
I’ve chosen to use the CDC-ADM USB device class, which makes the device appear as a virtual serial port. Strictly speaking this class is meant for USB modems, but is a very common choice for embedded projects, as it’s supported out of the box on multiple OS’s.
Note that Windows will require an INF file with matching VID/PID to load the USB serial driver, while Linux may need some udev rules to set permissions, and to prevent ModemManager probing the ports when they appear (this will get annoying quite quickly when the bootloader times out before you can get access to the port).
There’s a handful of choices for a USB library to use with the 8-bit AVR micro’s. I suspect it’s fair to say the most popular library for open source projects is the MIT licensed LUFA library by Dean Camera.
Having said that, my initial implementation used the usb_serial demo routines from the PJRC teensy board demo (simply because they were lightweight, with only a couple of files to add to the project to get up & running). This first iteration used the virtual serial port for the comms with Golden Cheetah, and retained the onboard serial for debug messages.
However, the LUFA library supports multiple USB endpoints, which prompted me to adopt it for further development. This has allowed me to present two virtual serial ports over the USB connection, using the first for the GC communication, and the second for debug data.
It is a bit more of a pain to integrate the LUFA library into an Eclipse managed build, as there are a number of symbols and options that need to be migrated from the library makefiles before it will build (it’s also quite a large library, with many features, and supporting multiple platforms). But, once all set up & building correctly, it’s very easy to get started with the supplied demo’s and examples.
Next week, I’ll be adding support for automatically trimming the resistance setting based on the real-time power data. With luck this will overcome any deficiencies in the power/speed/resistance map, and allow closer tracking of the target load.