Should programmers be platform-specific?

[matthijskooijman]

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 the boards.txt for 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:

• The ones from the programmers.txt in the platform the current board is defined.
• The ones from the programmers.txt in 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.txt from all platforms with the same architecture name (e.g. avr or samd). 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 between boards.txt and programmers.txt (all platforms on the same architecture should use the same interface), but I guess that should not be a problem in practice.

[matthijskooijman]

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).