Serial driver requirements and usage scenarios

[rotorman]

Come and join in spawning ideas for PR #1089 (Serial refactor) by discussing requirements and usage scenarios of serial ports in the radios.

Update: text in this post was augmented with discussion input from below posts (until Nov. 21st, 2021).

One goal is to make interacting with a serial port (either physical UART/USART or virtual VCP/CDC over USB) uniform and better interchangeable in order to be able to less tediously integrate future ideas.
The mapping between the port and the application should be user selectable and not hard-coded. E.g. consider the current implementation of GPS and Bluetooth (BT) on TX16S, where both are hard-wired to USART6. This is unnecessary, as both could also be used e.g. on USART3 (AUX1 on TX16S instead of AUX2) as well. In addition, the present implementation does not allow due to this hard-coding GPS and BT to be used simultaneously.

Please feel free to augment and brainstorm!

Ports to consider

• UART/USART
• USB device, Virtual-Serial-Port (VCP)/Communications-Device-Class (CDC)
• USB host with FTDI adapter
• Software serial ports, reception e.g. with EXTI & fixed timer
• Combined hw / software serials, e.g. where sending is done using sw/timer GPIO and receiving via HW UART/USART pin

Configurability

• baud rate (300 to 10M+, default 115.200) or auto-baud, incl. auto-switch (latter for USB device based serial comms, where the host sets the baud rate and changes it on the fly, think e.g. flashing ESP32 chips with esptool.py)
• data word length (8 (default) or 9)
• stop bit count (0.5, 1 (default), 1.5 or 2)
• parity (None (default), Even, Odd)
• flow control: (none (default), hardware CTS/RTS, CTS only, RTS only). Note: current radios on the market presently do not yet offer HW flow due to scarceness of GPIO pins.
• bi-directional (TX and RX) or unidirectional (only TX, only RX)

Possible use cases

• SBUS in/out
• Telemetry in/out
• Comms with internal and external modules (incl. SBUS in/out, Telemetry in/out)
• Mirror a signal on another serial (think e.g. telemetry mirroring, but not limited to it)
• Passthrough mode
• GPS / Compass
• Antenna tracker
• Radio modem (including. Bluetooth)
• FrSky Bluetooth
• MAVLink
• ADS-B receiver
• Flashing devices (receivers, ESCs, RF-modules etc., further MCUs in the radio)
• Reading/writing from/to EEPROM/Flash modules in the radio
• Inter-chip communications (e.g. with another MCU in the radio)
• On-Screen-Display (OSD) output
• access from LUA
• Reading sticks (e.g. FlySky HZCZ) and performing their firmware update
• Debug output
• Command-Line-Interface (CLI)

[gagarinlg]

Maybe at a soft UART for SBUS on radio where the inpit can not be inverted?
But only for pins UART with an attached hardware timer, to keep things simple.

[raphaelcoeffic]

There are some capabilities for soft UART at the moment, as is used for PXX1 modules (internal interface) and MPM on the external interface.

What we really miss is indeed receiving via soft UART. There are a couple ways to do it efficiently, among which EXTI IRQs and CC timers, or a combination of both. Mike Blandford mentioned that using EXTI for detecting start bit as well as a fixed timer for sampling is a good way of doing it as well.

[raphaelcoeffic]

First of all, thanks a lot for putting this together! It’s just splendid!

i have only a couple remarks:

• flow control is, as of now on the current hardware, largely unsupported (could be possibly changed, but it costs pins which are rather scarce these days).
• I think we should mention “combined ports”, like the MPM is using, where sending is done using a timer and receiving on a HW USART.
• The capability of mirroring seems quite important for many applications (basically telemetry mirroring as of now).

[raphaelcoeffic]

@rotorman as you mention it, I don’t think it will be 100% covered in the first PR, which goal is for now to get rid of the mess and dust on the current code. But we need to have goals and designs if this is supposed to be heading anywhere.

[NemesisXB]

How about adding RTT as well, can probably only be used for cli and debug. I had errors when enabling debugging because uart debugging is slow and changed some timings (was when we were testing the touch screen lockup). Will mostly only be useful for devs, but it works really well, is fast so doesn't affect real-time operation, and does not take a lot of code space.

[rotorman]

Do you mean Segger RTT https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/ ?
This uses SWD, so no further serial (software or hardware) pin/port is required.

Plans are afoot to have future hardware support also SWO on SWD header

and possibly even full Cortex ARM trace (19-pin header with ETM trace) to be available on future radio dev. kits:

SWO costs 1 additional pin, ETM 5 pins.

But these debugging header options are not related to serial ports.

[NemesisXB]

Yes Segger RTT. Runs over SWD (or jtag). No extra pins required. You require a Segger device for it to work but it even works on the segger edu and edu mini which are low cost. So like I said, probably only for devs.

[NemesisXB]

The nice thing about RTT is you can leave it "on" and at any time connect the debugger to get the data out. No need to compile special builds with debugging enabled (for the radios that have enough flash available for the strings).

What would be cool would be to have debugging always enabled and if required by someone that does not have a segger debugger available have it routable to an external uart.

[rotorman]

The latter means a hw-solution though.
Further option, although costly, would be to have embedded J-Link on-board https://www.segger.com/products/debug-probes/j-link/models/j-link-ob/

[brainbubblersbest]

1-All should be Model specific and not Set by Hardware Tab.
Maybe someone use Externalaccess on one Model.
But use a esp32 as wireless interface mounted in the Jr bay or at the bottom aux connector on another Model.
Or for mav-link Modem with a third Model.

2-Standard Baudrates should be Marked somehow (with STD Label or else?) to give users a hint what Baudrate they should choose in most cases.

3-Talking over Chip interconnection like writen already above...
Would a "Sensor Interface Hub" with another processor an idea?

4-Configurable uart 4 also would be Nice. Especially for the x12s because it's the only physical connector available without Soldering.
(GPS)
And I think for the Hall Gimbal Conversion, if I remember right? But change the gps for esp32 here would be easy too.
Maybe this can be named Aux Serial 3?

Just my thoughts. 🙂