Allow Burn bootloader with selected programmer

[MiBiMiFlo]

I noticed that Burn Bootloader works possibly with the same upload mechanism as Upload, but not with the new "selected programmer" feature.

I'm not sure if this makes sense at all, but it would be great if either Burn Bootloader uses the selected programmer or if an additional action "Burn Bootloader with selected programmer" could be added.

Btw. this is awesome! Burn bootloader was the last reason for me to keep an original Adruino IDE installed.

[jantje]

Seems I missed this issue. Sorry for the delay.
Can you give an example of the "actual behaviour" versus the "wanted behaviour"?

There are still 2 good reasons to keep arduino IDE around

1. installation/update of drivers
   2)see whether it is a sloeber issue or a platform issue

[jantje]

After waiting for 25 days I close the issue.
Feel free to reopen when answering the questions in the previus post

[MiBiMiFlo]

Sorry I did not find the time to respond more early.

In my setup I have a different tool selected for programming (not the default), additionally I always only use Upload with Programmer, not the normal upload. The current behavior does not honor the selected programmer when using "Burn the Bootloader", but always refers to the board's default bootloader tool. (as far as I understand).

I did some more deep dives in the internals of sloeber and found a workaround that explains my request quite well.

When I create a makefile.defs file in my project root with the following definition:
bootloader.tool=${program.tool}
This fixes my issue and is more aligned with the way how Arduino IDE honors the selected programmer for burning bootloader.

I'm still not sure if the actual behavior is really wanted, as you always need a programmer to burn the bootloader. As far as I understand the normal upload process requires a bootloader to be installed already.

Hope this clarifies my request.

[jantje]

Thanks for the update.
It looks like abug like you describe it.
I havn't use the burn bootloader much but I did do dome burning to test, so there probably are bugs in the code but we need to be very carefully making changes as testing is pretty hard (due to difficulties to test for instance due to lack of hardware).

Anyway I tried here using

When I tried 'burn bootloader" the command obvious failed (as I do not have the bootloader connected)

Then I created the makefile.defs as you explained and ran again

As far as I can see the command that was executed is exactly the same.
So I do not see a issue.
Can you provide the same information from your system?

[MiBiMiFlo]

Hi,

to reproduce this, you need to select a programmer that either does not use avrdude or at least requires different parameter set.
I'm using megaTinyCore from SpenceKonde and selected the SerialUPDI programmer:

When I run burn Bootloader the following is executed:

After I created the makefile.defs and added bootloader.tool=${program.tool} I get the following:

I guess the bootloader tool is taken from atxy4.bootloader.tool=avrdude in boards.txt, but there is no way to change this. Arduino IDE honors the selected programmer and the serialupdi.bootloader.tool=serialupdi from programmers.txt in this case.

[jantje]

Can you provide the json url you used to install this platform?

It looks to me that the problem is as follows:
Sloeber first gets the environment variables from platform .txt then from programmers.txt then from boards.txt

arduino-eclipse-plugin/io.sloeber.core/src/io/sloeber/core/api/BoardDescription.java

Line 807 in 15767ce

allVars.putAll(referencedPlatfromFile.getAllEnvironVars());

arduino-eclipse-plugin/io.sloeber.core/src/io/sloeber/core/api/BoardDescription.java

Line 823 in 15767ce

allVars.putAll(curProgrammer.getAllEnvironVars(programmerID));

arduino-eclipse-plugin/io.sloeber.core/src/io/sloeber/core/api/BoardDescription.java

Line 828 in 15767ce

allVars.putAll(myBoardTxtFile.getBoardEnvironVars(getBoardID()));

This means that boards.txt environment variables will overwrite the platform.txt variables
This complies with your perception

I guess the bootloader tool is taken from atxy4.bootloader.tool=avrdude in boards.txt

From the point of view of programming and bootloading; processing programmers.txt last seems a good idea.
From the ppoint of view of uploading and building; processing the boards.txt last seems most natural.
As in Sloeber the build, programming and burning bootloader all start from the same makefile; changing the order of txt processing is a all or nothing situation.

Though I do not really see risk in processing programmers.txt after boards.txt it does mean: "lots of testing"

FYI If you can build sloeber you can change the order and test your scenario.

[MiBiMiFlo]

I used the following json to install megaTinyCore in version 2.5.4:

http://drazzy.com/package_drazzy.com_index.json

Yes I understand your point and it explains the observed behavior. If I will find some time I will try to change the order and do a test.

As I said I have a working workaround and it's not urgent for me, still it differs from the way how Arduino handles the files and might confuse others as well, when the feature is released.
I see two possible options here:

1. Change the order of config file processing to match Arduino (possibly with a Global Option to select one way or the other?)
2. Add an Option in Project Settings next to programmer Selection where bootloader programmer can be selected per Project

Anyway I'm totally happy that I can use Sloeber, so thanks a lot for this great tool!

[MiBiMiFlo]

I just noticed this option:

Not sure what it does, but it sounds like it should align to Arduino IDE and therefore would possibly make sense to also align this more with the Arduino style when enabled?

[jantje]

That setting has to do with the selection of the version of the build toolchain. The version is selected based on the json file (if unchecked) or the more fussy like arduino (old?) way if unchecked.
As more and more platforms explicitly reference the toolchain in the json this option remains only useful for old json files that assume installed Arduino toolchains. I recently considered to remove this option and always go for the arduino way.
Currently for 99,9% of the platforms the behaviour will be the same.

[jantje]

This one should be fixed now.