I uploaded both files using the serial interface and the ISP.
A) Upload using USB/FTDI.
Of course, the chip must have the boot loader installed.
Both files 1) and 2) can be uploaded normally and seem to work exactly the same (at least with this simple sketch).
B) Upload using ISP programmer (I use an Arduino as ISP).
File 1) overwrites the boot loader. The chip cannot be reprogrammed again using method A).
File 2) uploads both the sketch AND the boot loader. The chip can be reprogrammed again with same or another sketch using method A).
So, the real utility of file 2) is that it allows to burn both the sketch and the boot loader in a single operation. This may be handy if a number of boards must be setup from scratch.
That's my understanding also, though I've never tried it. I did a quick skim of the other thread but I don't understand why it wasn't working. Yes, you need the fuses set for the bootloader, but the fuses on an Arduino should already be set correctly. Even when you do Upload Using Programmer it still leaves the fuses the same as they were set when you do a Burn Bootloader.
Uploading via USB/Serial uses the bootloader, it does not erase the bootloader in the process.
Uploading via ISP will always erase the bootloader - the only way an ISP programmer can erase the flash is do do a chip erase operation, which erases the entire flash (and the EEPROM unless EESAVE fuse is programmed). So, if you want to continue being able to program via serial when you do an upload via ISP, you must use the version of the .hex with the bootloader included.
OK. I was hoping I found an easy way to change the bootloader
There is an easy way to use a bootloader, connect an ISP programmer and use that to put the preferred bootloader on it.
The bootloader (which is what is used when you do a serial/usb upload) will not overwrite itself, and this is good, because otherwise you could upload something that hosed the bootloader; as it is, there is nothing you can upload over the serial port that will damage the bootloader
Hey guys - this topic is a few months old - but I’m confused about what the ‘bootloader’ is exactly in the case of, for example, the ATTiny chips.
I’m using the ATTinyCore, and my understanding is that when I write the ‘bootloader’ to, in this case an ATTiny44A, all I’m really doing is writing fuse settings, which seems to be confirmed by looking at the avrdude verbose output because I can really only see it writing and confirming the efuse, hfuse and lfuse.
However, after uploading my sketch to the ATTiny44 with the programmer (after setting the fuses by writing the ‘bootloader’), if I go into the folder where it dumped my HEX files, I still see a regular .hex file and then still an additional .with_bootloader.hex file sitting there. I understand the purpose of the .with_bootloader.hex file in the case of an Arduino because it allows serial reprogramming, but what’s the purpose of the ‘bootloader’ here? Does the .with_bootloader.hex contain the fuse settings somehow? And if so, why is it the .with_bootloader.hex file 104 bytes larger than the normal .hex file, when it would really only need to be 3 bytes larger?
Basically, if I’m going to send one of these .hex files to Digikey for automatic programming of my chips, which one of these .hex files should I send them? Digikey wants my fuse settings documented separately, so even if the .with_bootloader.hex file contains them, I feel like I should be good with the standard .hex file, but I just want to be sure before I drop a $50 first article setup fee.
The with bootloader hex is bogus. If you use my core, except for the chips where we can produce a bootloader-included image that works (ie, ones that use a bootloader and have hardware bootloader support - most dont and use virtual boot if you use the optional serial bootloadet, which rewrites 2 of the vectors when writing the sketch, so the with bootloader hex wouldn't work), it deletes this non-usable hex immediately.
@DrAzzy thanks for the response . . . I figured the hex with bootloader was pointless, but I didn't know it wouldn't work.
I do use your core. Thanks for all your work on it! I might have an old version of it . . . I'm not sure how to tell which version I have from looking at the readme.md file - it says it's for Arduino version 1.6.x, so a bit at least. Did you add the feature of deleting the non-usable hex later?
That functionality was added in ATTinyCore 1.1.3; release notes for 1.2.2 indicate that at that time an issue relating to export compiled binary on linux and mac OS was fixed as well, I forget the details.