Should programmers be platform-specific? #9373
Labels
Type: Improvement
This proposal is considered to be especially beneficial
Comments
per1234
added
the
Type: Improvement
matthijskooijman
added a commit
to matthijskooijman/Arduino
that referenced
this issue
Mar 22, 2020
Previously, the programmers menu always showed *all* programmers of *all* platforms. This made it hard to find the programmer you need. When selecting a programmer from another platform, it would typically not work, since the tool definitions rely on specific variables to be defined by the board, or files available in the variant directory, which are typically platform-dependent. Also, some programmers might be defined in multiple platforms, but there is currently no way to tell which one is for the current platform an will work, and which is for another platform and will break. This commit changes the programmer menu to only show programmers from the platforms that define the board and the core used. The latter is only used when boar definition refers a core in another platform, in which case the core and variant already have a strong coupling (the variant must offer the right variables for the core to work), so that would also apply to the programmer, so programmers from the referenced core's platform can be expected to work. When a board is selected, the menu of available programmers is refreshed, but the currently selected programmer preference is untouched. This might mean that a programmer is selected that is invalid for the current board and will not actually work. This could be fixed by clearing the current programmer when it becomes invalid, but that would mean that changing to another platform and back would always require reselecting the programmer to use, which seems counter-productive. An alternative fix would be to check the programmer against the board and throw an error, but that would require duplicating some code, which did not seem worthwile (ideally, all this code will be moved to arduino-cli anyway in the future). This fixes arduino#9373.
|
I just submitted a PR to fix this, #9900. I ended up only showing programmers from the board platform and the referenced core platform, not any platform with the same architecture, since those would be too likely to break (and contain duplicate entries too). It seems that there are quite some alternative cores for various archs (e.g. ESP and STM32), which are developed either completely separately (and thus incompatible) or forks (and thus have duplicate programmers). |
cmaglie
pushed a commit
that referenced
this issue
Mar 23, 2020
Previously, the programmers menu always showed *all* programmers of *all* platforms. This made it hard to find the programmer you need. When selecting a programmer from another platform, it would typically not work, since the tool definitions rely on specific variables to be defined by the board, or files available in the variant directory, which are typically platform-dependent. Also, some programmers might be defined in multiple platforms, but there is currently no way to tell which one is for the current platform an will work, and which is for another platform and will break. This commit changes the programmer menu to only show programmers from the platforms that define the board and the core used. The latter is only used when boar definition refers a core in another platform, in which case the core and variant already have a strong coupling (the variant must offer the right variables for the core to work), so that would also apply to the programmer, so programmers from the referenced core's platform can be expected to work. When a board is selected, the menu of available programmers is refreshed, but the currently selected programmer preference is untouched. This might mean that a programmer is selected that is invalid for the current board and will not actually work. This could be fixed by clearing the current programmer when it becomes invalid, but that would mean that changing to another platform and back would always require reselecting the programmer to use, which seems counter-productive. An alternative fix would be to check the programmer against the board and throw an error, but that would require duplicating some code, which did not seem worthwile (ideally, all this code will be moved to arduino-cli anyway in the future). This fixes #9373.
matthijskooijman
added a commit
to matthijskooijman/Arduino
that referenced
this issue
Mar 24, 2020
When there are no programmers available for the current board, the programmers menu would remain empty, which would prevent it from unfolding and could make users think there was something wrong with the menu. Now, a disabled item with a message is added if no programmers are available, which should make it more clear what is going on. This is a followup for arduino#9373.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, it seems programmers (e.g. ISP programmers from
programmers.txt) all live in a single global, shared space. In particular, when I use a non-AVR board (such as SAMD, ESP or STM32), I still see all AVR-specific ISP programmers in the Programmer menu. In practice, non of these will work, since they call avrdude that only supports AVR, and theboards.txtfor these other platforms probably do not actually provide the build variables that these programmers use.This makes me wonder: Should programmers not be confined to the platform (or at least the architecture) they are defined in? Usually, the tools are very architecture-specific (e.g. avrdude). Some tools can be used for multiple architectures (e.g. openocd), but in practice, the "interface" offered by these programmer definitions (i.e. the variables that must be set by the board to make the upload work) are very different for each architecture even if the tool is the same.
I think that the only programmers that are relevant are:
programmers.txtin the platform the current board is defined.programmers.txtin the platform the current core is from (e.g. for board-only platforms that reference another platform for the actual code).A slightly broader definition would be to use all
programmers.txtfrom all platforms with the same architecture name (e.g.avrorsamd). That would also allow adding more programmers for an architecture by adding a programmer-only platform, which could be nice. This does mean there is a bit less freedom for a platform to use its own interface betweenboards.txtandprogrammers.txt(all platforms on the same architecture should use the same interface), but I guess that should not be a problem in practice.The text was updated successfully, but these errors were encountered: