# Am I able to burn a bootloader and program with an AVR ISP?

I have considered purchasing some ATMega chips as to create simple realizations of projects without sacrificing a dev board (i.e. Arduino)

Now I understand the bootloader is required to read from a usb-to-serial device. The AVR ISP (or equivalent) burns the bootloader, then people often either use a usb-to-serial or the Arduino itself to program the chip.

What on earth does the AVR ISP actually do? If it can burn a bootloader (is it stored within, a generic one for all the AVRs it supports?) why can it not also program the device (as people seem to never instruct, even if that makes it simple)

Why does the ISP also allow you to connect to a computer via USB, for power? for custom boot loaders? Can it even "program" a compiled program in to flash via something such as avr-gcc (assuming the arduino IDE does things that required the bootloader)

I just cannot wrap heads or tails around what is required. I am aiming for a "program the new chip, plug it in to socket, and go" kind of approach without multiple burns or programming.

You can fully program an ATMega with the AVR ISP.

I build a MIDIpal at the beginning of this year. The supplied ATMega chip hadn't been pre-programmed. So after soldering up the board (much easier than I expected. SMT is nothing to fear), I plugged in my TinyISP and downloaded the binary code to it. Now my MIDIpal works as advertised.

I'm not familiar with the bootloader portion, but imagine that it must have been included in the firmware provided by Mutable.

• That is not bad at all then, thank you. I wonder why on earth people suggest rigging usb-to-serial for one time projects. It appears I compile a .hex file (will feel neat!) with avrdude? or something. Then use the a program with the adapter to install the binary. – Tommy Jan 27 '12 at 6:00
• I think the USB to Serial cable is the cheapest solution. But you can get or build an ISP for under $20, so I just went that route. – ObscureRobot Jan 27 '12 at 7:16 What on earth does the AVR ISP actually do? It allows read/writes to all the memory areas of the AVR chips (flash, eeprom and fuses). The "IS" in ISP means "In-system": you do not need to remove the chip from the circuit to program it (in the old days there were "outboard" programmers, you had to pull the chip from your circuit, insert it in the programmer, then insert it back in your circuit... tedious!) why can it not also program the device (as people seem to never instruct, even if that makes it simple) It can! You can absolutely and safely go without any bootloader on the chip. Just make sure that the chip is configured to boot from address 0 instead of booting from the bootloader area. On AVRs, this is configured by fuses. avr-gcc is the compiler, which turns C/C++ program into machine code (ultimately stored as a .hex file). avrdude is a "program loader", responsible for reading/writing data to the chip through a programming interface (such as various flavours of ISP programmers). Here is the avrdude command for writing FIRMWARE.hex to an atmega328P chip through an AVR ISP mkII programmer hooked to the computer by USB : avrdude -V -p m328p -P usb -c avrispmkII -U flash:w:FIRMWARE.hex:i Why does the ISP also allow you to connect to a computer via USB, for power? for custom boot loaders? Can it even "program" a compiled program in to flash via something such as avr-gcc (assuming the arduino IDE does things that required the bootloader) If you need to flash a chip, you need the data to go from the computer to the chip, right? Not surprising then that the ISP programmer is connected to both the chip and the computer. I suggest you to read some non Arduino-related tutorials about AVR programming. Get back to basics. Keep in mind that the way things are done in Arduino land (send the program through a USB->serial chip to a custom bootloader running on the chip) are not the norm. The Arduino stuff is a solution to a specific problem (how can you get people to send programs to a chip without a programmer?), but for your project and your own sanity, you do not have to replicate it. Just buy a$25 programmer, put an ISP socket on your board, and forget for a while about USB, FTDI chips, bootloaders, etc...

As for bootloaders, they will be required only when you want your system to be field-upgradeable through another means than the ISP programmer. There are serial bootloaders (like the Arduino's), SD-card bootloaders, MIDI bootloaders, USB mass storage device bootloaders, etc.

What on earth does the AVR ISP actually do?

The document AVR910: In-System Programming from Atmel is probably a good start to get a better understanding. It describes the required and expected behaviour for the ISP related pins and also documents the programming protocol used by the programmer, giving examples of command and responses for commands like Programming Enable and Read Device Code.

Field programming is important in this market. Having multiple choices helps. Some products both from Atmel and from others, have a bootloader we cannot reprogram that using strap pins allows you to pick usb or serial or other. Some just try to detect what you want to do, and others you only get one choice, jtag for example, or serial.

I like the AVR solution in that the processor is held in reset, so if you (me) do something stupid (yep, been there done that) and hang the processor (say you enable clocks from the pll without correctly configuring the pll), or you reconfigure the wrong gpio pins to find those were the pins you needed for the programming interface. Well you may end up with a bricked board or chip. Holding the processor in reset at least protects us from our self.

The programming interface is well documented. The xmegas or the one I played with uses a completely different interface than the tinys and such. The smaller ones it is just SPI and you can take your time, put the thing in reset, could use toggle switches and flip them by hand if you wanted. The xmega the timing is critical, you wait to long and the chip goes out of programming mode. (it is not spi) Either case it is well documented.

You can use the off the shelf solutions and use avrdude or whatever, but these interfaces are simple, and you can use anything you can generate spi with (other microcontrollers, a raspberry pi, any ftdi part/board with mpsse instructions and the pins exposed, whatever). And developing your own is not a difficult task. Educational, and perhaps in your production line you may or may not want to use avrdude, or maybe you cant for some reason.

Yes, this AVR ISP interface can be used to program a bootloader or any application you want. You do not have to do one thing with one interface then the other with a different interface.

Why use another bootloader then? Well a serial bootloader could use as little as one pin or two, or three if you want a strap or in the case of arduino they use a third one to reset the chip then send something before the bootloader hands off to the application.

So sometimes you want to use serial in your design for field programming, reduce the pins or that is just your preferred thing. You may want jtag, you may want usb or in this case use the AVR ISP all the time. Some chips allow you to erase/write flash blocks while running on a flash block, meaning you can write your own bootloader using whatever protocol you want. Which is what the Arduino folks did, they claim to support some protocol, but look at their bootloader code to see the truth.

Whether you use off the shelf hardware and software or do your own, this AVR ISP interface is probably the way to go for put it in a fixture and program then plug in a socket and go, one burn and done. Esp, if you do end up with a bug in the software you can go back to the programmer and reprogram. Erased and not erased flashes are equally supported.

So the bottom line is about freedom to choose. Program in a fixture then move the part, program in place, RE-program in place, speed of programming, pins required, software requirements, programming fixture hardware/software/cost requirements. There is not one solution that makes everyone happy. So the vendor provides one or two or three solutions, then you can sometimes add your own on top of that.

BUT, you should have read the documentation from the chip vendor for the product you were interested in, they all provide programming information, without that documentation that product is a failure because nobody would be able to use it in a production line. Not our job to read the docs for you.