If you extract the .hex file from another device, you will only have one .hex file - sometimes there's a second, smaller file in the hex format, but with the .eep extension instead (can you guess what this contains?)
The IDE allows you to export compiled binary. In some cases, this will result in two files, one with the bootloader, and one without it:
- If the board is normally programmed by ICSP, you're not using a bootloader to upload, and the first upload you perform over ICSP erases the bootloader. So there's not much point to using it.
- If the board is normally programmed through a bootloader, but this time you are using ICSP, then you should use the with bootloader, otherwise the bootloader will be gone after you upload the sketch.
- If the board currently has a bootloader, and you're using that to upload the hex file, not an ICSP programmer, do not use the "with bootloader" hex file
- If your target part does not have hardware bootloader support (all classic tinies, with a very small number of very obscure exceptions, lack hardware bootloader support), the "with bootloader" hex file will not work correctly (if due to permissions, ; on those sort of parts, if you need to "xerox" the contents of a part's program space, you read the whole flash out with ICSP. This will get you a single hex file containging everything that was on the target (the workflow thus is use icsp to bootload the part being used as a "template", then upload the sketch through the bootloader, not via ICSP, and then switch back to ICSP to dump the contents of the flash to the hex file (you can diff it against the "with botloader" export that is generated, and see that a couple of bytes are different. These are very important bytes.
- note: If you are planning to deploy this to virgin chips, you also need to set the fuses. I don't think any classic AVR programming tools will know how to stash the fuses in the hex file, or to get fuses stashed in some not-otherwise-used portion of the address space. If you aren't comfortable composing AVRdude commands, the fastest way is to enable verbose output during upload, connect a programmer (doesn't need to have anything to program connected to the programmer), "burn bootloader" and scroll to the very top of the console, where you will see an avrdude command. That's the command that writes the fuses (which you will see passed as parameters on the command line, and the .hex file. You could then change that command to use extracted "xeroxed" hex file. You can take that, and just replace the bootloader hex with the "xeroxed" contents of the flash.
- The method they use to generate the .hex with bootloader - at least last time I was poking at it would only work on classic AVRs with hardware bootloader support, and only if the fuses were set - either previously, or because you are doing both the she same avrdude invocation. Otherwise, the resulting sketch+bootloader hex file would fail to ever enter the bootloader, because the bootloader on parts without true hardware bootloader support needs to modify 4 bytes of the sketch code, but that does not happen when the the IDE tooling combines the sketch, and without doing that, the bootloader is unreachable. Originally my first core, ATTinyCore was generating the two hex, and I couldn't find a way to tell it not to, so ATTC actually still exports both, but then immediately deletes the one with the bootloader (since we know that there is no way it will work).
I think the feature's intended use was so people with official boards could get a .hex file that they could upload with some tool more suited towards semi-automation than the IDE. and still have a board with the bootloader on it when they're done
Depending on the part and core you are using, additional files with non .hex extensions and different text-based formats may also be generated when you do export compiled binary, and the named of the file may contain additional information about settings at the time of compilation (my modern AVR cores encode every tools menu setting which alters the code in any in a postfix to the sketch name, so you can easily, say, export the same sketch with several sets of options selected or for several different parts, and they won't overwrite each other),
In addition, when asked to export the binary, megaTinyCore and DxCore output the memory map (.map) and the assembly listing (.lst). The AVR binutils could stand to be better about this on several grounds. somewhere in either avr_research or avr-guidance I have a python script to make the formatting the memory maps less terrible by normalizing the delimiters (The most informative format that nm offers has a mix of spaces and columns defined based on width a tab, or a different delimiter character) but nothing is lined up and the whole thing is impossible to read as generated, because any variable that, when you give the full type of every argument and the full name of the functions etc etc, exceeds like 30 characters, will push over the rest of the columns in that row. Since most functions exceed that limit, you end up with something that is nigh unreadable. But even I was able to throw together a python script that truncated symbol names and normalized the delimiters so I could import it into excel and plot it over time.
I'd like to do a similar processing tool specifically to clean up pathological annotations in the .lst (Like when, after an address, it formats it as a base address and offset - but chooses a base address that has a numeric value close to the address from the other address space. It's as useless as a GPS thats you telling where nearby stops and attractions are, assuming you're located at the latitude and longitude you are picking up, except assuming that you're on mars, and that's martian latitude and longitude, so it warns you about driving too fast (mars is significantly smaller than earth, so it would think you were moving faster than you were) and pointing out landmarks that you could probably clearly see if you were on mars...
with I think 3 passes over the file ("remove junk compiler added comments, then add tags next to instructions that are often a sign of problems in a sketch, if you know any. Instead of saying I'm at EEPROM_LENGTH+74, you want something that would say + 0x04) but that's a problem for another month.