I'm wondering why the Uno still uses a bootloader for the ATMega328. The ATMega16U2 has more than enough available pins to function as a USBasp in addition to a CDC serial device.
Getting rid of the bootloader would:
Free up some flash space.
Simplify debugging initialization problems (i.e. side-effects of the bootloader affecting the sketch code)
Simplify chip replacements (i.e. no need to put a bootloader on a new ATMega328 when you fry your old one)
For power users, it would permit programming the fuses without using an external programmer.
It would also be one less thing that needs to be maintained, and perhaps more work could be done on cleaning up/optimizing the Arduino core</pipe dream>.
In the past few months I've been working on writing an Arduino compatible bootloader in assembly to get it down to 256 bytes (the smallest block supported by the BOOTSZ fuses). Recently I took a step back and asked, "Why am I doing this?", and didn't have a good answer.
The bootloader was great for the Arduino Serial which only had a basic RS232-TTL serial converter on board. Now I think it's time to retire the bootloader.
I haven't encountered any myself that have caused actual errors, however there's another recent thread with someone reporting that his ATmega328 overheats when he uses the bootloader, but doesn't when the sketch is flashed without a bootloader.
From reading the Optiboot code, it does have side effects - I/O registers are not restored to their initial values. So for example code that relies on UCSR0x = 0 after reset (as per the datasheet) could have issues if the chip has Optiboot flashed.
It also appears MCUSR is always zeroed and not restored, so if your code uses watchdog resets for timeouts, or you enable BOD and want to know if you had a power dip, then it won't work with the bootloader.
From reading the Optiboot code, it does have side effects - I/O registers are not restored to their initial values.
Yes they are. The sketch "start" procedure involves causing a WDT reset and then jumping to the user sketch; the only thing not at "reset time" value is the "reset cause" register.
I was wondering the same thing, back when Uno came out. I think there are three major issues:
You still need the USB/Serial function in the 16u2. Having it support both a "programmer" function and a "Serial port" function at the same time might have introduced host-side complexity (for example, I've heard that some versions of MacOS won't support a CDC endpoint that is part of a composite (multi-function) device.
Host-side driver issues for a non-standard "programmer" device. Although AVRDUDE already does most of the work here.
With six interconnections between the 16U2 and the 328 (and the "user" pins) (MOSI, MISO, SSCK, RESET, RxD, TxD) you increase the risk of introducing incompatibilities or frying the programmer chip. It's bad enough that people have problems with D0/D1...
(Yeah, there are probably ways around all of that. Teensy3 apparently uses a chip without a bootloader...)
(I've also attempted the "256byte Bootloader in ASM", and concluded that it wasn't quite possible unless I'm willing to reject the STK500v1 protocol used by the current bootloaders, and write my own simplified protocol. I think I got it down to about 350 bytes before I gave up.)
ralphd:
From reading the Optiboot code, it does have side effects - I/O registers are not restored to their initial values. So for example code that relies on UCSR0x = 0 after reset (as per the datasheet) could have issues if the chip has Optiboot flashed.
Incorrect. The MCUSR register is the only one affected.
CrossRoads:
Making all boards 32U4 based means no more DIP parts for repairing damaged boards. DIP is part of the attraction of beginning Arduino projects.
? I didn't say anything about switching to the 32U4. The Leonardo already does that anyway.
From reading the Optiboot code, it does have side effects - I/O registers are not restored to their initial values.
Yes they are. The sketch "start" procedure involves causing a WDT reset and then jumping to the user sketch; the only thing not at "reset time" value is the "reset cause" register.
I get it now. Since the bootloader timeout is done with a watchdog reset(which sets I/O registers to their defaults), the only thing changed is the MCUSR = 0.
I was wondering the same thing, back when Uno came out. I think there are three major issues:
You still need the USB/Serial function in the 16u2. Having it support both a "programmer" function and a "Serial port" function at the same time might have introduced host-side complexity (for example, I've heard that some versions of MacOS won't support a CDC endpoint that is part of a composite (multi-function) device.
The Leonardo page talks about using it as a HID keyboard/mouse in addition to CDC serial, so I think it would be just as compatible as the Leonardo.
(I've also attempted the "256byte Bootloader in ASM", and concluded that it wasn't quite possible unless I'm willing to reject the STK500v1 protocol used by the current bootloaders, and write my own simplified protocol. I think I got it down to about 350 bytes before I gave up.)
I think it is doable in 256 bytes while maintaining the same level of STK compatibility as optiboot. I load the downloaded data directly to the page buffer instead of SRAM first which cuts down on the code size for the bootloader. However I think what I'll try to do first is finish my transparent SPI version of picoboot, since pin-limited ATtiny devices with reset disabled are what benefit the most from a bootloader. http://code.google.com/p/picoboot/source/browse/trunk/picoboot.S
I've got most of the functionality there and it's still under 128 bytes. My initial idea was to save the original reset vector in the page before the bootloader, but the more I think about it, I like the optiboot technique of using an infrequently used vector. However instead of WDT, I'd probably default to EE_RDY.
CrossRoads:
My thinking behind that - If you dump the bootloader, then users need to have an AVR ISP programmer - or a 32U4 that can do serial downloads.
I said: "The ATMega16U2 has more than enough available pins to function as a USBasp in addition to a CDC serial device."
The UNO has an ATMega16U2 which does the USB-ttl serial translation. That same chip could also function as an AVR ISP programmer (USBasp).
Hmm, I suppose. Would you require a header to header connection, build it into the board, ...? What would be the mechanism to select sketch uploading vs normal serial operations? All workable, got me curious now.
CrossRoads:
Hmm, I suppose. Would you require a header to header connection, build it into the board, ...? What would be the mechanism to select sketch uploading vs normal serial operations? All workable, got me curious now.
The upload uses whatever programmer is selected, so it should be just a matter of a new entry in the boards.txt (or manually selecting USBasp for the programmer).