Suggestion: bootloader to be burned before the sketch.

[rtek1000]

Hello,

I would like to suggest that the uC Attiny85 bootloader be automatically burned before the sketch, when the upload is performed using the programmer.

This uC can operate with 1MHz, 4MHz, 8MHz, 16MHz (PLL) but if the user selects the clock, he also has to burn the bootloader, this makes the process more difficult for a beginner because he has to perform an additional procedure that the great part of the tutorials available on the internet does not explain.

Even if "No bootloader" is selected, it is necessary to burn the bootloader again if the uC is programmed for a different clock.

If this is the first time you are using a brand new chip, or if you need to change the clock source or BOD settings, you must do "Burn Bootloader" to set the fuses. If you previously used optiboot, and wish to program with ISP instead, or if you want to install optiboot on the chip, you must do "burn bootloader" first as well.

(Source: https://github.com/SpenceKonde/ATTinyCore/blob/master/Programming.md)

Thank you.

[rtek1000]

This issue tracker is only for bug reports and feature requests related to official Arduino software. ATTinyCore is a 3rd party project, and so feature requests for ATTinyCore are off topic here.

https://github.com/arduino/Arduino/issues/10878

[SpenceKonde]

This is something I have considered, but decided against for ATTinyCore - but it is planned for a future version of DxCore and megaTinyCore.

There are two big arguments against it (but only one is valid for the new parts) - one human and one technical.

The human one: The official Arduino core never sets fuses unless you do "burn bootloader", and following that example, no other cores do either. The fact that this can end up with mismatched clock speeds and so on is unfortunate, but by now, the general expectation is that fuses will not be set except when you choose burn bootloader. That is particularly important because of the technical reason. (as it happens, because of the rarity of using an external clock instead of an external crystal, we don't even support that via burn bootloader; per the documentation, if you want to use external CLOCK, you manually set the fuse with AVRDude, and then upload with the crystal setting for that speed selected; there is only one exception, and that's for the tiny88 micronucleus board, which is widely available for an astonishingly low price, using a 16 MHz external clock, as it doesn't support crystals (note that the datasheet specs maximum clock speed at 12 MHz... but the boards work!)

Technical reason: Setting the fuses incorrectly can brick the chip! What if you have it set on crystal and upload... your board doesn't have a crystal. If that set fuses, you've bricked it - the part now cannot be reprogrammed. You can put a clock signal on XTAL1... assuming there's nothing connected to that pin already that would interfere with that. Like, you know, most things one might connect to a pin... So now you have to desolder things. So that's part of the "deal" of those two commands: Nothing you "upload" can ever brick the chip, but "burn bootloader" with the wrong settings can, and so you are expected to think more carefully before you choose "burn bootloader". With considerably more clever software on the computer side, one could have avrdude read out the fuses, match them against the selected options, and warn the user if they don't match - though that could only go so far (you can tell them that they have PLL selected but the chip is using the internal oscillator, but if they have 8 MHz crystal selected, but the chip has a 16 MHz crystal, you can't tell that from the fuses... but I think that's a fool's errand, and I've got a massive number of tasks that aren't fools errands in my queue

The technical reason is far less of an issue on the new parts though On the AVR Dx-series parts, the clock source isn't set by the fuses (well, you can set it to run at 32KHz in the fuses, though I don't support that in DxCore for obvious reasons) - that gets done in the sketch (it always starts at 4 MHz internal, and init() sets the clock speed and source and specified, so you couldn't brick them that way, and the UPDI pin can't be turned into an I/O pin (at least on the DA and DB series - it looks like it will be able to be on the DD-series which extends all the way down to 14-pin devices; presumably HV-UPDI - which is far easier to do than HVSP on classic AVRs - will be needed to reprogram then - but HV UPDI programmers for hobbyists are becoming available)). With only that one setting that can brick the chip, I could declare that everything except that would be set by upload (well, it would be SYSCFG0, so EEPROM retain would also be burn bootloader only). The tinyAVR 0/1/2-series are in a similar situation to the aforementioned DD-series, where only one fuse can render the chip difficult to reprogram.

But on ATTinyCore, where wrong fuses can easily brick the chip, it's not gonna happen.