The Burn
You’ve built your circuit; you’ve written your code; you’ve generated the hex file, and you’ve verified that it’ll fit in your chosen microcontroller. Now it’s time put it there and see if it works. Should be a piece of cake, right?
And really, it is; simply connect your programmer, figure out what serial device it’s on, and do this:
$ avrdude -c buspirate -b 115200 -p attiny13 -P /dev/tty.usbserial-AH00MPIC -U flash:w:tiny13demo.hex
Trust me, it only looks complicated. The -c <programmer> option tells it what programmer to use – the Bus Pirate in my case. The serial line speed (yes, you need it even over USB (sigh)) is set by the -b <speed> option, and the type of microcontroller by the -p <mcu> option*. Then you have the -P <dev> option that specifies the serial device your programmer is connected to.
It’s that last option, -U <operation>, that you need to pay attention to.
The argument to the -U option is split into fields with ‘:’ as the delimiter. There are actually four fields, but the fourth isn’t needed for what we’re doing; it just lets you specify the file format of the target file. See the man page for more information.
The first field in the list is the memory area we wish to operate on. There are a number of options, but don’t concern yourself with those; they have more advanced uses that we haven’t gotten to yet. For now, we just specify flash, which is where the code and data goes.
Option the second is the operation we wish to perform. This can be ‘r’, which will read from the device and write it the file; ‘v’, which will verify the device’s memory against the specified file; and ‘w’, which will write the contents of the file to the device. The latter is obviously what we want for programming.
The final option is the name of the filename you want to operate on (either the output target if the previous field is ‘r’, or the file to use as a programming or verification source otherwise).
When you run the command, you’ll get output like this:
Detecting BusPirate... ** ** Bus Pirate v3b ** Firmware v5.10 (r559) Bootloader v4.4 ** DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5) ** http://dangerousprototypes.com ** BusPirate: using BINARY mode avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.10s avrdude: Device signature = 0x1e9007 avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude: erasing chip avrdude: reading input file "tiny13demo.hex" avrdude: input file tiny13demo.hex auto detected as Intel Hex avrdude: writing flash (68 bytes): Writing | ################################################## | 100% 2.27s avrdude: 68 bytes of flash written avrdude: verifying flash memory against tiny13demo.hex: avrdude: load data flash data from input file tiny13demo.hex: avrdude: input file tiny13demo.hex auto detected as Intel Hex avrdude: input file tiny13demo.hex contains 68 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 2.17s avrdude: verifying ... avrdude: 68 bytes of flash verified avrdude: safemode: Fuses OK avrdude done. Thank you.
And that’s all it takes.
(*)USEFUL TIP: avrdude doesn’t support the ATtiny13A – but the ATtiny13 is fully supported, and works just fine for programming the 13A.
Thanks for this! I’ve been using microchip’s PICs a fair amount, and wanted to start trying AVRs to see if they might be more simple. This will be a nice starting point.
Um. This is a serious cliffhanger – or did Part2 get blown with the wind^Wfuse? Is there still hope?
Thanks anyway for the nice introduction, as a late adopter I appreciate it a lot. Everyone else is using RasPis now, but AVRs are fun for someone who decades ago had to learn and write (mainframe) assembly code!