sleemanj / optiboot

Small and Fast Bootloader for Arduino and other Atmel AVR chips
66 stars 13 forks source link

No programmer other than "DIY ATTiny: USBasp + Upload EEPROM (Not For Burn Bootloader)" is available for ATTiny13a #20

Closed WrichikBasu closed 4 years ago

WrichikBasu commented 4 years ago

Arduino IDE version: 1.8.13

I am interested in programming an ATTiny13a. I was reading the EEPROM auto uploading section in your README file. You have written:

It is important to note that you can not use a + Upload EEPROM programmer selection when you are burning the bootloader, you would get an error, so just switch back to the normal programmer in the menu to burn your bootloaders.

The problem is, in my IDE, the only programmer that I have is DIY ATTiny: USBasp + Upload EEPROM (Not For Burn Bootloader) :

image

Once I select this programmer, it remains selected forever, which means I will not be able to burn any bootloader in the future.

sleemanj commented 4 years ago

Thanks for the report.

It appear that the new IDE version creates this problem, checking with 1.8.9 works as expected, but 1.8.13 has the problem you reported (I didn't test between those).

I expect that it comes from work that @matthijskooijman did in https://github.com/arduino/Arduino/issues/9373

I think I'll have to copy-paste the "standard" avr programmers into out programmers.txt rather than just be able to add an extra :-/

matthijskooijman commented 4 years ago

Yup, seems this is my "fault" indeed. For now, copy-pasting the standard programmers is indeed the only option, though seeing this repo (and it probably also holds for other attiny repos or other AVR repos that want to reuse programmers but not the core from another core), I wonder if maybe an explicit include=arduino (or include=arduino:avr) should be supported by the IDE to explicitly include the programmers from another core...

sleemanj commented 4 years ago

For me it's not actually a problem other than I need to find an hour to repackage and test, but an include statement in programmers.txt does sound like a good idea going forward.

WrichikBasu commented 4 years ago

an include statement in programmers.txt does sound like a good idea going forward.

One question: Won't this make your code dependent on the version of Arduino AVR boards installed in the user's IDE?

Suppose you use the include statement in your programmers.txt file, the IDE successfully imports the programmers from the other core, and you don't find any problem in your tests. However, the user may not be using that same version of Arduino AVR boards that you used for testing. In past or future versions, there might be something that is incompatible with your code, and the result will be a bug. It might take quite some time before someone figures out that the incompatibility of the two cores is creating the problem. Maybe it is better to copy-paste to avoid such compatibility issues.

I am a beginner in Arduino programming, but I have previously made some applications in Java. When I pack the application, I always include the JDK/JRE that I have used for testing. If my code, for example, uses java.time classes, and someone has Java 7 installed on their machines, my application will basically fail on their machine. Packing the JDK with the application itself helps prevent such issues.

matthijskooijman commented 4 years ago

One question: Won't this make your code dependent on the version of Arduino AVR boards installed in the user's IDE?

Yup, this is indeed a problem, and is also one of the reasons I decided to not automatically import programmers from cores sharing the same architecture. The compatibility problem will likely be smaller when you explicitly select another core to import from, but it will still exist. Duplicating the definitions would indeed help in this case.

In the end, it's a balance of duplication and not automatically getting updates, vs the risk of incompatibilities. To really get the best of both, you'd need some way to verbosely express dependencies and version constraints (with proper semver-like version to detect compatibility breakage), but I don't think we'll be able to really properly implement that.

So, maybe just copy-pasting and not implementing the include is a good way in any case. I probably won't find time to implement this anyway, so unless someone else does, that means that the copy-paste solution is going to be the de facto best solution anyway :-p

sleemanj commented 4 years ago

2020.10.10 version of DIY ATTiny includes all the programmers again (NB: the IDE caches json file downloads, so you might not see this release yet).