Support for additional radio receiver protocols (Crossfire, etc.)

[Cyberslug]

Hi! I've been working with PlainFlight and really appreciate the work you've put into this project.
I'm interested in adding support for additional radio receiver protocols beyond SBUS. Currently, SBUS is deeply embedded throughout the codebase, which makes it challenging to add alternatives like Crossfire, SRXL2, or other protocols.

Proposed approach:
I'd like to suggest refactoring the receiver handling to use an abstract base class that defines the interface for radio receivers. This would allow different protocol implementations to be swapped in cleanly without touching the core flight logic.

What I can contribute:
I have a Crossfire implementation with the same structure as the existing SBus implementation ready to test
I'm happy to create the abstract base class and refactor the existing SBUS code to use it
I can implement the integration so other protocols can be added easily in the future

Important caveat:
I'm contributing this in my spare time and can't commit to specific deadlines, but I'm motivated to see this through.
Would you be open to this kind of refactoring? If so, I'm happy to discuss the design approach before I start work to make sure it aligns with your vision for the project. If you have preferences on how the abstraction should be structured or any concerns about the change, I'd love to hear them.
Thanks for considering this!

[plainFlight]

Hi, I am open to contributions and your suggestion sounds good and a sensible way forward.

I ask that you ensure coding style/format is maintained with same use of camel, snake and pascal case etc and that sufficient header and code comments are added for me and others to understand.

Not a problem with time scales I too do this in my own time for a bit of fun. I am able to test crossfire but none of the other protocols. Interested to see if you can achieve 1ms loop rate with crossfire.

Raise a pull request when you are ready.

Paul.

[Cyberslug]

I now have a working version of both crossfire and SBus protocol with a base class. However as SBus constants are involved in scaling in a number of other classes and in many places the changes are quite extensive. I think that if I raise a PR on such a massive change then it definitely won't meet your coding standard and will be too much to consider and respond to in a single effort. I am therefore thinking about how to package these changes as a number of discrete steps that would ultimately lead to the end goal. My thoughts at the moment are to raise PRs to do the following steps

1. Replace Wire with SoftWire. This provides an immediate reduction of loop time by up to 1/3 and is a simple plug in replacement for Wire.
2. Create a RxScaling class that will handle the normalization for all Rx sub classes. The intent would be to normalize as a signed 11 bit number. This is desired because it is possible to capture the resolution of all common serial protocols and it is efficient in that the division required for scaling can be accomplished with a low cost shift instead of integer division. Using this class all (SBus) scaling and normalization constants in DemandProcessor, ModelType, FlightControl and SBus (possibly more) would be replaced with reference to this class/namespace. This is by far the biggest step and removes dependence on SBus for the rest of the codebase. It will also result in a slight reduction in loop time through more efficient scaling.
3. Introduce an RxBase class and a new dependent SBus class. This would maintain functionality while supporting new radio protocol support.
4. Add CRSF support.
5. Add other protocol support as required. At this point these an now relatively trivial to add.

While taking this approach will involve a lot of work in unpicking and repackaging my implementation I think that it is the best way forward as it will allow me to review and hopefully meet your coding standard. Each PR would leave the code base fully functional and with more capability with the exception of step 3 that simply replaces the current SBus class.

Please let me know what you think. If you are happy with this approach then I will start feeding you the various PRs.

[plainFlight]

Apologies for delayed reply... your approach sounds logical and well thought out.
Happy for you to continue but it will take me some time to review the pull requests. Thanks for your interest and efforts. Paul.