UARTSerial enhancement request: flow control

[RobMeades]

Description

• Type: Enhancement
• Priority: Minor

Enhancement

#4119 introduced UARTSerial, which provides a very neat interface to buffered serial operations. One thing it is missing, though, is flow control. If UARTSerial receives data faster than it can get rid of it, characters are lost without notice. This is a particular issue when using the recv() method of the equally new ATCmdParser with the serial stream, since the sscanf()ing involved can take quite some time and could cause data loss, especially if there are out of band thingies to capture.

All that is required is for UARTSerial to expose the set_flow_control() bit of SerialBase, I think.

[0xc0170]

cc @hasnainvirk @kjbracey-arm

[hasnainvirk]

@RobMeades Yes this work item is on the to-do list. We are even thinking a step further:

• HW/HW flow control
• HW/SW flow control
• SW flow control (XON/XOFF)

@kjbracey-arm will be the architectural planner. Thank you for highlighting this.
You can keep this open for traction.

[kjbracey]

Looking through the targets, it seems almost every target does implement the set_flow_control() API via hardware assist, so maybe we don't need to worry about software-controlled version in the first pass.

However, XON/XOFF could be useful for the cases where RTS and CTS aren't connected - which is actually quite common.

So maybe we just don't bother with the middle case (RTS and CTS handled as GPIO).

Step 1 is then pass through the set_flow_control, and modify the RX data pump to not read data when the buffer is full, so the RX HW flow control works.

[RobMeades]

Sounds good to me.

[RobMeades]

It would be good to get this flow control cooking, it might help with my attempts to run the modem interface at higher data rates.

[RobMeades]

@kjbracey-arm: is it possible to get some idea when HW flow control might be available in a PR? I've some work that needs higher data rates that I can only realistically schedule with this in place.

[kjbracey]

Not sure we've got the resource available to work on testing this at our end in the next couple of weeks. Seems like it should be basically making the Rx IRQ handling more similar to the Tx IRQ handling - IRQ handler can disable it, and foreground read routine re-enables it.

If I knock out a quick patch proposal can you test it?

[RobMeades]

Yup, absolutely.

[kjbracey]

Try this. Untested apart from compilation.

https://github.com/kjbracey-arm/mbed-os/tree/uartserial_flow

[RobMeades]

Testing now, will continue via e-mail shortly.

[kjbracey]

It occurred to me that it might get a bit stuck without the same basic "do it in the foreground" logic as TX. Extra tweak added to branch.