UARTSerial: add flow control and format APIs #5088
Conversation
Add passthrough APIs to enable the flow control and format methods from SerialBase to be accessed. Modify the RX data pump so it stops reading data and disables the IRQ when the buffer is full, to allow UART automatic flow control to work. In principle it would also be possible as a future enhancement to provide XON/XOFF flow control, or manual RTS/CTS control using GPIO, but this commit at least restores the functionality present in Serial, SerialBase and RawSerial that was missing in UARTSerial.
|
@TeemuKultala FYI |
|
@sg- Could you take a look at this API change? |
|
I dont like the mixture of DEVICE_XXX in our APIs and suggest we should be using inheritance for this. |
|
Don't really follow - the HAL API is conditioned that way, and this is just passing through to the HAL, same as the other serial classes. Might be better to make it so the call is always available but returns an error code if it can't do it because the HAL doesn't support it? Might make sense as it could in principle support non-hardware-assisted flow control without help from the HAL - wiggle the RTS and CTS as GPIO based on software buffer level. |
|
@kjbracey-arm, @sg-: is there any way that we can move this change along? I have a thing that really doesn't work without HW flow control. |
That is correct, this is how it is now. We could change this to not wrap entire function definiton but only the implementation. The question is then as many of our API do not have return value, how to report an error. @kjbracey-arm suggestions? |
|
For this one I'd be happy to have an integer error return value on the function being added. Whether that fits with wider style views, I don't know. |
@sg- What do you think? |
|
bump |
|
I dont understand where the error code fits but isn't really my problem. The mixture of serial capabilities in developer APIs is a bad path to go down IMO. While this pattern exists I think we'd all agree its not the best way to present capabilities. That said, this patch is starting to define failure modes but we dont have a way to signal that to the application. As with other failure modes, I'd suggest for at least a debug build we were asserting the failure case given the problems are very hard to diagnose. I think @c1728p9 had a patch at one point to add RX OVERRUN in the HAL so I wonder how much of this just needs to be expedited as a review for completeness versus just poking at it more. |
|
There's nothing here about returning error conditions like overrun - this is just letting apps specify flow control mode, which is dependent on target support. If the app requests flow control but the target lacks it - do we want a compile time error, a run-time (I'm kind of inclined towards the last, but not that strongly, as in principle different ports may have different capabilities. Not that the serial HAL currently allows error returns to indicate that) At the minute, Serial, RawSerial and SerialBase all provide If you don't want UARTSerial to just work the same as the existing ones, then we need a concrete proposal for what you actually do want. You said "inheritance" - are you envisaging a |
|
Can I ask that we separate making architectural changes from simply exposing an interface that has always been there and is fundamental to serial port operation? This change is required if we are to use the Cellular API at a rate faster than 115200 which, if we consider only 3G on-air rates, is boringly normal. I'm not really following what approach might be adopted to present "set baud rate" in a more architecturally sympathetic way but I need to get on and re-architecting is taking too long. |
|
In that case I'd suggest we drop the part that disables the RX handler and only add support for the missing flow control and format. |
|
The RX handler change is a necessary part of the flow control change:
The existing version's RX data pump always reads bytes from the data register, and throws it away if the software buffer is full. That defeats any hardware flow control if active, as the hardware buffer never fills. The replacement code here stops reading the data register if the software buffer is full, allowing the hardware buffer to fill to cause the UART to signal "full". |
|
Thanks @kjbracey-arm . Looks fine to me as it is now. |
|
/morph build |
|
/morph build |
Build : SUCCESSBuild number : 399 Triggering tests/morph test |
Test : SUCCESSBuild number : 194 |
Add passthrough APIs to enable the flow control and format methods from
SerialBase to be accessed.
Modify the RX data pump so it stops reading data and disables the IRQ
when the buffer is full, to allow UART automatic flow control to work.
In principle it would also be possible as a future enhancement to
provide XON/XOFF flow control, or manual RTS/CTS control using GPIO, but
this commit at least restores the functionality present in Serial,
SerialBase and RawSerial that was missing in UARTSerial.
Implements #4428