I have a couple questions about bootloaders for Arduino UNO.
The file that is to be burned to ATmegas is the .hex in hardware/arduino/avr/bootloaders/atmega or atmega8, correct?
If so, now that is a text file right? Can I assume the data payload of each record in the hex are to be converted to binary by either avrdude or uisp?
Once it's in binary. The whole "burning" business is basicaly writing the code to ATmegas programmable Flash memory and data to EEPROM right? That's what avrdude and uisp do right?
If, so .hex no longer contains section names. How does avrdude / uisp respectively know what record goes to what location of what memory?
You can check boards.txt to see which file it uses.
Avrdude knows how to read hex files.
Yes, it's just writing to flash and the "fuses" ( those set basic settings like clock sources. Despite the name, they can be rewritten).The use of the word burn is a source of confusion for some.
The .hex file contains the address to write each line of data to at the start of the line, see Wikipedia entry for "Intel hex format ". The fuse settings to use are taken from boards.txt
Data to EEPROM are not written by the optiboot on UNO. It is possible but for the Arduino UNO is more important for the bootloader to fit into 512B of memory to be as small as possible, so this functionality is not included. Nevertheless, Arduino IDE has no option to write into EEPROM. Avrdude, yes.
The long story: the compiler makes a relocatable object that can be linked with other relocatable objects into a bigger one. Normally these images are named elf files. Once the linker is done putting together the final elf it is passed to avr-objcopy to make the HEX file (e.g. avr-objcopy -j .text -j .data -O ihex blink.elf). Nowadays that hex file is not really needed since avrdude knows how to use the elf object file directly. I am still using hex files, but I can't say why?
Ah boards.txt, got it. I see the optiboot loader has no data.. Thanks!
Well yes avrdude can read .hex, but then again so can notepad.exe. The question is: do the number pairs from .hex become actual bytes in AT microchips flash memory and is avrdude the tool that does that?
(it's somewhat obvious the answer is yes and yes, but I don't like to rely on assumptions if the information is stated somewhere in text)
What is a fuse in respect to Arduino please? Is that a term for single I/O port bit?
The .hex file to binary conversion is done by avrdude. The things actually transmitted to the bootloader are commands (as defined by the STK500v1 communications protocol document from Atmel) and binary data that is written to flash.
The bootloader does not change the fuses.
The bootloader does not write EEPROM or RAM. However, the flash memory will include a COPY of the data memory, which the C startup code will copy from flash to RAM before the actual sketch is started. Putting the copy of the data memory into the flash address space (where the startup code knows to find it) is done by the linker and/or the avr-objcopy; by the time you have the .hex file that arduino gives you, all the locations refer to flash. (not necessarily true in general. In various intermediate spots, RAM is handled as "odd" absolute addresses, since neither the compiler nor linker really understands the idea of multiple address spaces.)
Ok! Ok.. I am pretty happy with what I have learned from answers from all of you guys thank you!
Well ok, maybe one last thing
The SPI unit. What exactly is the difference when I want to use it to programm the flash memory and when I want to use it just for communication with some other device?
Pyjong:
The SPI unit. What exactly is the difference when I want to use it to programm the flash memory and when I want to use it just for communication with some other device?
When the SPI pins are used to flash the chip (using the ArduinoISP or other ISP programmer, like USBAsp), the reset pin is held low, so no user code is running. You put the chip into reset state, and while it's in reset, the programmer talks to it using the SPI pins, and it starts replying on MISO. It's sometimes described as "using the reset pin as CS (chip select)". Also, of course, the atmega chip is the slave when you're programming it, while normally when using SPI devices, the microcontroller on your arduino board acts as the master.
When you try to burn bootloader and get the chip did not answer, that means programmer saw no indication that it was manipulating the MISO line in response to. If the chip is set to use a non-existent clock source, it will start asserting MISO, but it will just keep it low, leading to the signature read as 0x000000.
thank you!