search

xmos / xcore_iot

Other
30 stars 40 forks source link

UART Updates #457

Closed ed-xmos closed 2 years ago

ed-xmos commented 2 years ago

Submodule containing RTOS driver - https://github.com/xmos/fwk_rtos/pull/27 UART HIL moved to fwk_io and mildly refreshed - https://github.com/xmos/fwk_rtos/pull/27

ed-xmos commented 2 years ago

@xmos-jmccarthy, re:

  • [x] OPTIONAL In rtos_uart_rx.c A streambuffer is an interesting way to interact with an io peripheral. Could you add a function rtos_uart_rx_reset_buffer(), which just empties the streambuffer? In the case of an app that may only care about uart data at specific times, or that is trying to reset post error detected, this would be helpful, otherwise they would have to manually drain the streambuffer.

By 'interesting' would it be better to put a layer on top to hide the streambuffer APIs? It seemed like a good mechanism and would already be familiar to a FreeRTOS user. However saying that I'm happy to modify this to go with convention. Regarding reset, why wouldn't a user just call https://www.freertos.org/xStreamBufferReset.html? (This may be a moot point if I add an abstraction layer)..

xmos-jmccarthy commented 2 years ago

@xmos-jmccarthy, re:

  • [x] OPTIONAL In rtos_uart_rx.c A streambuffer is an interesting way to interact with an io peripheral. Could you add a function rtos_uart_rx_reset_buffer(), which just empties the streambuffer? In the case of an app that may only care about uart data at specific times, or that is trying to reset post error detected, this would be helpful, otherwise they would have to manually drain the streambuffer.

By 'interesting' would it be better to put a layer on top to hide the streambuffer APIs? It seemed like a good mechanism and would already be familiar to a FreeRTOS user. However saying that I'm happy to modify this to go with convention. Regarding reset, why wouldn't a user just call https://www.freertos.org/xStreamBufferReset.html? (This may be a moot point if I add an abstraction layer)..

The main reason for rtos_uart_rx_reset_buffer() and rtos_uart_rx() is for ease of maintainability, with a side benefit of making the software drivers appear more similar to hardware peripherals at the application level. By having all of the driver related calls via a driver named symbol we get the flexibility to support changes in the driver without breaking existing applications. Since streambuffers are FreeRTOS specific, we may one day need to add another rtos port layer, and with this additional thin driver layer, we can accommodate for some degree of application code staying unchanged. Alternatively, we may find that streambuffers aren't what we want, and could replace the guts with a queue, or message buffer, etc. thus providing the ability to make functional changes without breaking the RTOS driver level API.