I would learn how to modify the bootloader

There a little idea that is growing up in my head but I need to understand more things on the bootloader and how to modify it.

I have an Arduino Uno. Why, if I open /arduino/hardware/arduino-00xx/bootloaders/optiboot/optiboot_atmega328.hex, that file is 1.4 KB in size? Shouldn't it be 512 byte? Maybe the bin file carries extra data? What kind of data? Where those data will be write?

How file do I have to change, to modify the bootloader? bootloader.c?
Why is there a file named optiboot_atimega328.lst? What's for?

leo72:
There a little idea that is growing up in my head but I need to understand more things on the bootloader and how to modify it.

I have an Arduino Uno. Why, if I open /arduino/hardware/arduino-00xx/bootloaders/optiboot/optiboot_atmega328.hex, that file is 1.4 KB in size? Shouldn't it be 512 byte? Maybe the bin file carries extra data? What kind of data? Where those data will be write?

How file do I have to change, to modify the bootloader? bootloader.c?
Why is there a file named optiboot_atimega328.lst? What's for?

A .hex file is an ASCII version of the binary code. A hex file is built to a Intel standard format so many application programs can generate or use such files. The size is relative to the binary file but always larger.

To modify the bootloader program you must recompile the bootloader.c program. I'm not sure that can be done from the Arduino IDE, we will have to hear from some of the software gurus around here. Modifying the bootloader may trigger the need to modify other arduino files to utilize your new bootloader, so you need to understand what effect your changes will have on the total Arduino platform.

Lefty

Ah, OK.
So an HEX file isn't a pure binary file. It carries some extra data.

I don't have in mind to use the Atmega with the new bootloader inside an Arduino board. I would program it for a standalone project.

Yes, it as the address so the programmer can put the code in the right place, and it as a lot of lines, and each line as an address, and it also as checksums and some other things, so its in fact 512 bytes of code or less, but there are 1,4K of text in that file.

So an HEX file isn't a pure binary file.

It's not a binary file at all; it's an ascii representation of a binary file.
Each byte of the binary file is stored as two characters (0xFF becomes "FF"), and there is additional grouping, formatting, typing, error checking, and etc:

:10010000214601360121470136007EFE09D2190140
:SSAAAATTdddddddd...dddddddddCC
SS= size
AAAA= address
TT= type
dd...dd= data
CC= checksum

How file do I have to change, to modify the bootloader? bootloader.c?

optiboot/optiboot.c for optiboot, atmega/ATmegaBOOT_168.c for the old bootloader, etc.

Why is there a file named optiboot_atimega328.lst? What's for?

This is an informational "listing" file produced by compilation process, for reference (for one thing, so you can check that the code produced is small enough to fit in the "bootloader section" of the cpu.)

If you can get the proper headers set up in avrstudio, it gives an option for scaling the file down. I dunno how it does it though, as it may very well change variable names and etc. thus making the bootloader useless but it's worth a shot i guess.

I don't use AVRStudio as I'm on Linux.

leo72:
...Linux.

Here's my experience using avr-gcc version 4.3.4, built from source, on my Centos 5.5 Linux workstation. See Footnote.

When I executed "make atmega328" using arduino-0022/arduino/bootloaders/Makefile, the size of the object file was too large (532 bytes)

To get it below the 512 byte limit I did the following:

I changed line 61 of Makefile from the following

override LDFLAGS       = -Wl,$(LDSECTION) -Wl,--relax -nostartfiles

to the following

override LDFLAGS       = -Wl,$(LDSECTION) -Wl,--relax -nostartfiles -nostdlib

Now, with my compiler, that gets the object size down to 490 bytes.

Before going any further, there is a bug in that version of optiboot.c that has been documented elsewhere. I really, really (really) recommend that you do the following, as I did:

I changed line 216 of optiboot.c from the following

  // asm volatile ("clr __zero_reg__");

to the following

  asm volatile ("clr __zero_reg__");

This must be the first executable statement in main().

This statement requires an avr header that was not previously needed, so I inserted the following after line 71 of optiboot.c

#include <avr/interrupt.h>

For me, that brought the object size to 492 bytes.

The code is very tightly written, and you won't have oodles and oodles of room to add any enhancements, but maybe this will give you a chance to start.

There have been other changes in optiboot since the last Arduino release. If you really want to work with the latest, go to the Optiboot Home Page and follow the instructions to check out the latest optiboot source. That code leaves less headroom than the code in arduino-0022, so you may have problems shoe-horning other stuff into it.

Bottom line: If you have a different version of avr-gcc, you may not see the exact same results. Do I have to say it? IWFMYMMV. (It works ror me, your mileage may vary.)

Regards,

Dave

Footnote: Actually, I created a new working subdirectory under the optiboot directory and copied everything there. That way, I could experiment to my little heart's content in the working directory and still have the originals with which to compare.

If you really want to work with the latest, go to the Optiboot Home Page and follow the instructions to check out the latest optiboot source. That code leaves less headroom than the code in arduino-0022, so you may have problems shoe-horning other stuff into it.

Also be sure to check out the "issues" database from google code. There are patches and discussion there that haven't made it into the source yet...

Ok.Thanks for your suggestions :slight_smile: