[WIP] split drivers/rc_input per protocol

[dagar]

WORK IN PROGRESS opening for discussion, testing, and resolving edge cases

Currently in PX4 main for boards that do RC decoding FMU side (ie no px4io) we have a single monolithic RC driver (drivers/rc_input) that includes all protocols and scans input latching once it has a successful decode. Historically this has been mildly convenient for users because typically things have "just worked", but I am now of the opinion that we'd be much better off with explicit configuration and keeping things separate.

Advantages

• no false positives scanning (eg GHST and CRSF are the same baudrate, checksum, and packet size, but still not compatible)
• more flexibility to have any RC receiver on any serial port (there are still special cases like PPM or DSM bind)
• we'll actually know what the system is supposed to have because it was explicitly configured (eg SBUS receiver missing, arming denied)
• modularity
  • lower risk adding new RC protocols (eg SRXL2 support stalled because it heavily modified the shared driver, a standalone srxl2 driver would have been much lower risk)
  • telemetry and bidirectional support is becoming more common, this gives us more space to expand properly
  • uncommon (arguably legacy) protocols can exist harmlessly off to the side, being entirely removed from builds as needed
• likely makes it easier to support multiple RC inputs simultaneously (possibly not a real use case, although people have asked)

Disadvantages

• more code, more flash
• no more automatic FMU side RC selection

TODO

• [ ] make RC_SERIAL_PORT a board configurable serial port everywhere
• [ ] review and enforce special cases
  • [ ] PPM support limited to boards with appropriate hardware
  • [ ] DSM binding only on boards and ports with support
  • [ ] pre stm32f7/stm32h7 SBUS needs to be limited to boards with hardware support
  • [ ] for things like CRSF telemetry do we need to be careful to not allow you to enable telemetry on ports that are RX only or is it harmless
  • [ ] oddities on px4_fmu-v5 to test/verify

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-community-q-a-may-03-2023/31965/1

[MaEtUgR]

If I understood correctly this pr is superseded by the incremental steps: https://github.com/PX4/PX4-Autopilot/pull/23420 https://github.com/PX4/PX4-Autopilot/pull/23428

[dagar]

If I understood correctly this pr is superseded by the incremental steps: #23420 #23428

After those we'll still need to create standalone drivers for PPM, ST24, and SUMD. At that point we can consider purging the monolithic drivers/rc_input, but we need to figure out how to handle the transition from something that used to automatically "just work" (most of the time) to something that now must be manually configured. In addition there's also a fair amount of confusion due to the "RC" port on some boards being connected to the px4io.

If anyone could test https://github.com/PX4/PX4-Autopilot/pull/23428 on their board of choice it would really help move things along.

[hamishwillee]

but we need to figure out how to handle the transition from something that used to automatically "just work" (most of the time) to something that now must be manually configured.

FWIW the setup of RC is already pretty complicated to the point that this won't make it much worse, if at all.