Developing with USB microcontrollers from Atmel

[hlavac]

I have spent this evening playing with ATmega32U4. Here are some notes:

You don't need a hardware programmer with ATmega32U4 and other USB enabled microcontrollers from Atmel.
They come preprogrammed with a DFU bootloader. You just connect the device to the USB and hold pin /HWB low during the release of /RESET to activate the bootloader.
Most of the designs I have seen used two buttons, one for HWB and one for RESET. You had to click RESET button while holding the HWB button. Here is a little single button bootloader activator I have designed (see attachment picture).

Atmel provides a utility called FLIP that will program the device with DFU bootloader. They used to have this integrated with AVR Studio.
Sadly, with Atmel Studio 6, there is no such thing (yet?). So what you have to do is use FLIP command line utility called batchisp.exe and somehow launch it from Atmel Studio.

I thought it will be easy, but found out the pre/postbuild steps are not implemented by Atmel. Also the macro substitutions for build directory etc dont seem to work for external tools, so I had to hardcode the thing But anyway, you can do it like this:

In Tools/External tools, create a new entry. For Command, select the batchisp.exe program from FLIP installation directory:

Code: [Select]

C:\Program Files (x86)\Atmel\Flip 3.4.5\bin\batchisp.exe
For Arguments I have this:

Code: [Select]

-device atmega32u4 -hardware usb -operation ERASE F LOADBUFFER USB01.hex PROGRAM VERIFY START RESET 0

Replace USB01.hex with your filename and atmega32u4 with your device name.

And in the initial directory I had to hardcode the Debug folder containing the .hex file.
Check Close on exit as batchisp will hold with (A)bort, (R)etry, (I)gnore prompt when something is wrong. Haven't seen one of these for a long time!

You use it like this:

1) Do a build to create the .hex file.
2) Press the bootloader activation button while the device is connected to the USB.
3) Activate the external tools menu entry you created from the Tools menu.

You can map this tools entry to a hotkey. I did map it to F5 as there is no point in simulating a chip unsupported by the simulator.
Go to Tools/Customize/Keyboard..., find an entry named "Tools.ExternalCommand1", click in the text field lebeled Press shortcut keys: and press F5, then click Assign.

That's it. Much better than fiddling with the GUI Flip where you have to load the .hex file manually each time it changes

One more catch, if you run the code using the RESET option, it uses watchdog to reset the device, and the watchog remains active after the reset and has to be disabled at the start of your code and it's not as easy as it looks, simple wdt_disable() will not cut it:

Code: [Select]

#include <avr/wdt.h>
     ...

int main(void)
{
uint8_t mcusr_at_start = MCUSR;
MCUSR = 0; // enable WDT disable
wdt_disable();
        ...

Oh well, hope this helps

[poorchava]

I don't like USB in microcontrollers. One time I had to use that on a PIC18F4550 and I hate this stuff since. Protocol is complicated, not likely you will develop library on your own. To do anything serious you need your own custom device driver for windoze (generic HID at about 64k bytes/s doesn't cut it). Plus you need a way to communicate USB driver with your application on PC. Good luck doing that in something like .NET. Simple wrapper I once found somewhere was like 1.5k lines of code.

Good solution: buy any microcontroller and FTDI/Cypress/other usb<->uart bridge

Many people will probably disagree on that .

[hlavac]

There is a nice relatively easy solution for windows drivers - WinUSB. I have created a driver for DFU bootloader enabled AVRs with it before. It's not so bad, but you have to learn about creating Windows .INF files for drivers and code sign the driver.

Granted, it's not like you can do USB and not be a programmer.

Native USB drivers have the advantage that you can find your device without asking user on which COM it is or fiddling with wrong COM ports.
And if you want maximum performance, native USB will remove a level of abstraction/wrapping so it will be faster and have lower latency.
Also you can take advantage of the generic class drivers, not only serial ports.