chore(cpn): stop building STM32F2 simulators

[pfeerick]

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.

[3djc]

Don't we need profiles to import F2 radio models to (hopefully) a newer radio ?

[pfeerick]

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.

[raphaelcoeffic]

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?

[elecpower]

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.

[3djc]

You raise good points

[raphaelcoeffic]

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?

[elecpower]

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.