General LIBUARTE Questions

[49bwjf8]

Hello, I have recently updated our CLI backend to use LIBUARTE and it seems to be much more reliable. I have a few assumptions I would like to clarify and a few questions as well. This should be helpful to others planning to switch to LIBUARTE.

Assumptions (please correct me if I am wrong):

• LIBUARTE is a replacement to the existing UART and UARTE drivers and interfaces, including app_uart and nrf_serial, and so it is incompatible with them
• This means that  all the default values (including `disabled`) should be used for the UART(E) configuration options in the sdk_config (at least for the nRF52480) to avoid conflicts
• Two new timers will need to be allocated for synchronous and asynchronous implementations (async is required by the CLI backend, and async requires the synchronous implementation, so two timers will be needed if using the CLI backend).
• LIBUARTE requires NRFX_PRS_BOX_4 to be set to disabled for the UARTE0 peripheral since it needs to use its own LIBUARTE UARTE0_UART0_IRQHandler

Questions:

• Is there a way to use one timer for both the nrf_libuarte and nrf_libuarte_async implementations?
• When using nrf_libuarte, is there an internal buffer for receiving data or is the only buffer the one provided by the data parameter in nrf_libuarte_rx_start? What I mean is, does nrf_libuarte_rx_start pull the specified (by 'len') number of bytes from an internal buffer or is 'len' the maximum number of bytes to receive until the buffer overflows?
• What happens when the buffer overflows?
• In the async implementation, how often is the NRF_LIBUARTE_ASYNC_EVT_RX_DATA event triggered? At what point would a stream of incoming data be split into multiple events?
• Is there any issue in modifying the current DTM example implementation to use LIBUARTE instead of app_uart?
• Do I need to make a new implementation of retarget.c to work with LIBUARTE instead of app_uart?

Thanks!

[Krzysztof Chruscinski]

Hi,

I will try to touch on some of topics:

49bwjf8 said:

LIBUARTE is a replacement to the existing UART and UARTE drivers and interfaces, including app_uart and nrf_serial, and so it is incompatible with them

It is not. It is more reliable (ensuring reliable reception without flow control) but it is using more resources (PPI, 2 TIMERS) so it cannot be considered generic enough. In theory HWFC must be used for reliable transfers.

49bwjf8 said:

LIBUARTE requires NRFX_PRS_BOX_4 to be set to disabled for the UARTE0 peripheral since it needs to use its own LIBUARTE UARTE0_UART0_IRQHandler

Unfortunately, yes. As it first started as kind of proof of concept it's not intergrated fully with SDK.

49bwjf8 said:

Is there a way to use one timer for both the nrf_libuarte and nrf_libuarte_async implementations?

No, one timer is used for counting bytes, second timer is used for timeouting. There are work ongoing to allow use of RTC instance for timeouting as on option. It may get to next release.

49bwjf8 said:

When using nrf_libuarte, is there an internal buffer for receiving data or is the only buffer the one provided by the data parameter in nrf_libuarte_rx_start? What I mean is, does nrf_libuarte_rx_start pull the specified (by 'len') number of bytes from an internal buffer or is 'len' the maximum number of bytes to receive until the buffer overflows?

nrf_libuarte only uses external memory provided (for example buffers from nrf_libuarte_async).

49bwjf8 said:

What happens when the buffer overflows?

If new buffer is not set in easydma on time then it will start overwriting current buffer. However, because there is double buffering, time to respond to buffer request equals time to fill single buffer (e.g. 255 bytes buffer @1Mbaud = ~255*10us). 

49bwjf8 said:

In the async implementation, how often is the NRF_LIBUARTE_ASYNC_EVT_RX_DATA event triggered? At what point would a stream of incoming data be split into multiple events?

Event comes on timeout (which may be interpreted as packet boundary) and on buffer getting full (e.g. every 255 bytes). 

49bwjf8 said:

• Is there any issue in modifying the current DTM example implementation to use LIBUARTE instead of app_uart?
• Do I need to make a new implementation of retarget.c to work with LIBUARTE instead of app_uart?

I don't see any issues with using libuarte for those purposes.

[49bwjf8]

Hi Krzysztof,

Thank you for your reply, it was very informative. After experimenting I have a few more questions about the nrf_libuarte specifically:

• When I am waiting for async RX data and issue a dtm_cmd command, I stop getting RX events on the timeout but I continue to get full buffer events. Do you have an idea as to why this is happening?
• When does the NRF_LIBUARTE_EVT_RX_DATA event occur in nrf_libuarte (there is no timeout config option here)? Is it when the buffer is full?
• When does the NRF_LIBUARTE_EVT_RX_BUF_REQ event occur? Is this when the buffer specified in nrf_libuarte_rx_start is full?

• Is nrf_libuarte_rx_buf_rsp used to allocate extra buffer space for when the buffer specified in nrf_libuarte_rx_start is full? If so, then when you run nrf_libuarte_rx_start again will this pull in the data from that extra buffer?

Thanks!