EdgeTX
chore(cpn): stop building STM32F2 simulators
Summary of changes:
Following in the vein of #6225, rip out STM32F2 from Companion. This is a crude cull, simply making it so that radio profiles won't be listed, and that simulator plugins won't be generated. i.e. like with firmware, STM32F2 radio support may linger on until it finally gets broken, and can then be cleaned out.
note: not tested locally at all, so will probably break.
Don't we need profiles to import F2 radio models to (hopefully) a newer radio ?
Possibly... but if you don't drop the profiles, you can't drop simulator library builds, without getting numerous runtime errors because the hwdef files aren't present for those targets. Thus companion doesn't get any of the benefits of dropping the stm32f2 builds. But this is a draft for a reason, as this needs to be considered further. ;) As it would be preferable to make it so you can do an import only of those radios, and then copy to another (newer) radio.
Possibly... but if you don't drop the profiles, you can't drop simulator library builds, without getting numerous runtime errors because the hwdef files aren't present for those targets. Thus companion doesn't get any of the benefits of dropping the stm32f2 builds. But this is a draft for a reason, as this needs to be considered further. ;) As it would be preferable to make it so you can do an import only of those radios, and then copy to another (newer) radio.
Maybe we should consider freezing the hwdef files so they do not require any build steps? @elecpower which files do we need exactly to achieve this?
Companion uses the path and filter [build folder]/native/radio/src/*.json from which to load hwdefs into a resource file.
However I do not agree with retaining Companion support for unsupported firmware. Why? Quite simply the age old issue of potentially incompatible hwdef file formats. The files are not version stamped and even if they are then conversion code would need to be introduced and maintained until it can no longer be supported due to divergence. We just go rid of the onerous binary file support so I am not in favour of reintroducing that millstone.
However I do not agree with retaining Companion support for unsupported firmware.
I'm with you, no problem! That means you cannot convert from a radio that is not supported any more in 3.0 to one that is only supported from 3.0 on, right? Or did we kind-of ditch the conversion anyways? Or should we just try to import these files on a "best-effort" basis, telling the user that he will have to manually review all settings to check for potential errors?
With no hwdef then no board thus Companion will parse the yaml and report unsupported radio and go no further.
Also the radio profiles point to a cpn firmware that points to a board.
It might be possible to use the Unknown board type and parse based on the current radio profile which is mostly what happens now.
With no hwdef then no board thus Companion will parse the yaml and report unsupported radio and go no further.
#6437 adds the JSON hardware definitions directly in the repository, so that we don't need to build them anymore. Does that solve the problem?
With no hwdef then no board thus Companion will parse the yaml and report unsupported radio and go no further.
Also the radio profiles point to a cpn firmware that points to a board.
It might be possible to use the Unknown board type and parse based on the current radio profile which is mostly what happens now.
Since IMO the bulk of the concern for end user would be one simply of being able to "bring my models from transmitter X to transmitter Y" perhaps a future "workaround" could be a "simple" controlX to controlY mapping dialog when it is an "unknown" handset. all the radio settings could be set/reset to defaults just the control mapping applied. In other words, throw the task to the user, rather than even attempt to figure it out automatically. That would not be "pretty", since it that would require parsing of all models, to identify all the sources/switches used, and then a list of the valid sources/switches to be mapped to. Just something to think about perhaps, and is well out of scope for this and short term.
https://github.com/EdgeTX/edgetx/pull/6437 adds the JSON hardware definitions directly in the repository, so that we don't need to build them anymore. Does that solve the problem?
Yes, and well, not at all. It will probably resolve the need to build a simulator plugin in order to have a profile listed in Companion. For the conversion issue, we need consider 3.0 to be a migration/conversion step, so that handsets that only exist in 3.0 onwards are migration targets for handsets that are no longer supported in 3.x... with conversion support being dropped for targets that have ended support in 2.11 to be dropped in 4.1+ ... i.e. retain it simply until we branch 3.x off on it's own, and then drop it like the hot potato that it is.
Really? I wasn't going to mention that todo item! 😇 🤭 One of these days...