chores(flysky): separate AFHDS2A and AFHDS3 into 2 different module type

[raphaelcoeffic]

Fixes #836

This should allow to remove some of the hacks added earlier.

[raphaelcoeffic]

@philmoz @richardclli may I outsource separating the AFHDS2A / AFHDS3 options UI to you? I think this is mostly about splitting flysky_settings.{h,cpp} into afhds2a_settings.{h,cpp} and afhds3_settings.{h,cpp}, as this PR introduces 2 separate module types.

@elecpower may I also outsource the Companion changes to you? I believe the focus is probably on the YAML conversion here. The conversion is basically from type=TYPE_FLYSKY & subType=[AFHDS2A | AFHDS3] to type=[TYPE_FLYSKY_AFHDS2A | TYPE_FLYSKY_AFHDS3].

[raphaelcoeffic]

@pfeerick should we add the el18 target to CI as well? I think we should have el18 replace nv14 in the tests, and have final builds for both (second phase).

[elecpower]

@elecpower may I also outsource the Companion changes to you? I believe the focus is probably on the YAML conversion here. The conversion is basically from type=TYPE_FLYSKY & subType=[AFHDS2A | AFHDS3] to type=[TYPE_FLYSKY_AFHDS2A | TYPE_FLYSKY_AFHDS3].

Accepted. After I finish merging pots and sliders config into pots config with all the necessary conversions for old and new settings which I am about half way thru fixing.

[pfeerick]

@pfeerick should we add the el18 target to CI as well? I think we should have el18 replace nv14 in the tests, and have final builds for both (second phase).

Yup, sounds like a good time to do it... want me to add/swap the bits to build_gh and actions? This probably also makes life a bit easier with Companion as then we can start supporting the AFHDS2A and AFHDS3 specific options, which lines up nicely with my "want" for EL18 to get Companion support this cycle :)

[pfeerick]

I think that's all the "generic" bits. I also made a slight change to the order of tests - as I've found the x9dp2019 is the most likely B&W radio to implode if something goes wrong (partly as it probably has the most stuff turned on / hence also the least free space), so moved it to the top so it either passes or fails quicker. TX16S is probably the most representational horizontal LCD, and then the nl14/el18 for portrait LCD... I don't really think we need to do both for the tests post this PR, but probably should do until it's finished, since the tests will break the builds quicker?

[elecpower]

Companion base work done. Will move on to testing NV14 by comparing with its libsim.
Unable to test EL18 libsim yet as has not been added to Companion that I can find.
There appears to be a need for some Companion clean up of AFHDS3 as it appears to be a hack of an old AFHDS2A. eg there is a binary import mapping which how it existed back then I do not know. In this case I'd suggest we just drop the import and any legacy fields in moduledata.h.

[pfeerick]

There is zero support for EL18 in Companion at present, hence my earlier comment. Working on #3247 is on my 2.10 wish-list 😁

Can 100% drop any bin import for EL18 as it is post yml, and I'm 99% sure of the top of my head NV14 is also, so it's probably something from the flysky fork of NV14 which we don't support migrating from anyway, so IMO it can all go bye bye and make life simplier.

[elecpower]

@pfeerick would you like me to start a PR for #3247 in the next few days/week? I'd put all the building blocks in place and leave it to you to refine/fix.
That would be enough for me to run up the libsim to help test this PR.

[pfeerick]

@pfeerick would you like me to start a PR for #3247 in the next few days/week?

Yes, that would be great. With a skeleton in place, I can run through it with the actual hardware and make/suggest/beg for any changes.

[elecpower]

What no grovel 😉

[pfeerick]

beg

It was implied 🤣

[elecpower]

The nv14 libsim crashes in:

• Radio Settings clicking hardware tab
• Model Settings | Setup tab | clicking Int. Module

Does not crash in main branch so will wait for it to be fixed before mirroring the ui in Companion.

[raphaelcoeffic]

@elecpower potentially this was caused by TR_MODULE_PROTOCOLS missing one element, which should be fixed with b091c27.

[elecpower]

@elecpower potentially this was caused by TR_MODULE_PROTOCOLS missing one element, which should be fixed with b091c27.

@raphaelcoeffic that fixed the crash, thanks

[elecpower]

Tested with #3807

[philmoz]

@pfeerick would you like me to start a PR for #3247 in the next few days/week? I'd put all the building blocks in place and leave it to you to refine/fix.
That would be enough for me to run up the libsim to help test this PR.

I started working on the firmware UI changes. NV14 working ok; but I'm a bit stuck without companion support for EL18.

[richardclli]

@philmoz @richardclli may I outsource separating the AFHDS2A / AFHDS3 options UI to you? I think this is mostly about splitting flysky_settings.{h,cpp} into afhds2a_settings.{h,cpp} and afhds3_settings.{h,cpp}, as this PR introduces 2 separate module types.

@elecpower may I also outsource the Companion changes to you? I believe the focus is probably on the YAML conversion here. The conversion is basically from type=TYPE_FLYSKY & subType=[AFHDS2A | AFHDS3] to type=[TYPE_FLYSKY_AFHDS2A | TYPE_FLYSKY_AFHDS3].

Let me take a look first, work on the same branch with you?

[philmoz]

PR #3861 separates the UI settings pages for AFHDS2A and AFHDS3.

[elecpower]

PR #3807 has this PR as its base for the EL18 simulator. So Companion side is done except for fix ups that @pfeerick was going to check when he had a spare minute lol

[philmoz]

PR #3807 has this PR as its base for the EL18 simulator. So Companion side is done except for fix ups that @pfeerick was going to check when he had a spare minute lol

Hmm, I can't see EL18 as a radio type in Companion for setting up to run the simulator.

Ok, so I need 3807 as well?

[pfeerick]

Let me know your thoughts on this one @philmoz :)

[philmoz]

Let me know your thoughts on this one

It seems ok to me. I've used this when building for EL18 and the radio binds and works with the AFHDS3 receiver.

Can't test the NV14 / AFHDS2A side though.

[pfeerick]

Thanks. I'll try the NV14 side out then, and just give the EL18 a look over.

[pfeerick]

NV14 seems to be working both prior to and post this PR with no major issues - receiver still working fine, settings read and wrote fine on radio, and settings also survived Companion sync unscathed. I was going to try the FRM303 with TX16S but it wouldn't cooperate on 2.9.0 (or this PR) so I need to see why the mod to support the module isn't working.