The Hex File
One thing you learn pretty quickly when dealing with device programmers is that they tend to like their input in a very specific format — and ELF is generally not it. If you try to use one, either your programmer will complain, or the chip won’t run. So how do we fix that?
By doing this:
$ avr-objcopy -j .text -j .data -O ihex main.elf tiny13demo.hex
This command takes the elf file and turns it into an Intel Hex file that most programmers are able to read. The -j .text and -j .data options tell it to only copy code and data (the code segment is called .text by gcc). The -O ihex option makes it output in Intel Hex (Motorola S-Record is also supported, along with raw binary). Then the source file, and finally the target file.
The Statistics
Now you have the hex file you need for programming, but will it fit in your chosen chip? There’s a simple way to find out:
$ avr-size --format=avr --mcu=attiny13a main.elf
This will give you output similar to the following:
AVR Memory Usage ---------------- Device: attiny13a Program: 68 bytes (6.6% Full) (.text + .data + .bootloader) Data: 0 bytes (0.0% Full) (.data + .bss + .noinit)
USEFUL TIP: Make sure you use the ELF binary as input to this command! Pointing at the HEX file will result in bizarre, erroneous behavior. It doesn’t understand those files!
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!