Go Down

Topic: Time to dump the bootloader? (Read 7476 times) previous topic - next topic

ralphd

Jan 19, 2014, 05:00 pm Last Edit: Jan 19, 2014, 05:30 pm by ralphd Reason: 1
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.
http://arduino.cc/en/uploads/Main/Arduino_Uno_Rev3-schematic.pdf

Getting rid of the bootloader would:
1) Free up some flash space.
2) Simplify debugging initialization problems (i.e. side-effects of the bootloader affecting the sketch code)
3) Simplify chip replacements (i.e. no need to put a bootloader on a new ATMega328 when you fry your old one)
4) 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<pipe dream>, 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.

robtillaart

+1

Very good question, however...

If I transfer my 328 to a proprietary board with a RS232 interface, I can upload thanks to the bootloader...
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

ralphd


If I transfer my 328 to a proprietary board with a RS232 interface, I can upload thanks to the bootloader...


If the UNO didn't use a bootloader, you could still connect to a blank ATMega328 and use the "burn bootloader" function of the IDE in such a case.

spycatcher2k

Gotta +1 this, in most of my released boards, there is no bootloader, and I have on a few occasions, used the 328 with no memory put aside for the bootloader to get a few extra bytes of program space.
Mrs Drew
-=-
http://www.uk-pcb.co.uk - UK PCB Fab Company
I will design & code for you, but I will also charge you (PM me)
If you don't like my answers, realize : I'm not being cheeky, I'm Just trying to prompt you to use your own brain/google etc.

Coding Badly

2) Simplify debugging initialization problems (i.e. side-effects of the bootloader affecting the sketch code)


Such as?

ralphd


2) Simplify debugging initialization problems (i.e. side-effects of the bootloader affecting the sketch code)


Such as?

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.

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

westfw

Quote
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:
1) 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.
2) Host-side driver issues for a non-standard "programmer" device.  Although AVRDUDE already does most of the work here.
3) 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.)

Coding Badly

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.

ralphd


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.

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

ralphd


Quote
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.

Quote

I was wondering the same thing, back when Uno came out.  I think there are three major issues:
1) 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.
Quote

(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.

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.


I didn't realize the bootloader timeout was based on a watchdog reset, but Bill explained that.

ralphd


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).

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.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Go Up