RE: High Speed 1 MBaud Async UART with Zephyr

Susheel Nuguru — Sun, 17 Nov 2024 18:49:55 GMT

[quote user="MarkusF"]This is unrelated to the actual UART topic but it would be great to find a list of KConfigs settings for each driver in the future.[/quote]

unfortunately we are limited to either search in the menuconfig or if you know exactly which driver is in use then you can look into modules/hal/nordic/drivers/ and its respective driver KConfig. But I understand what you are saying here, my struggle is not just with the driver config but to find their dependencies.

RE: High Speed 1 MBaud Async UART with Zephyr

MarkusF — Fri, 15 Nov 2024 13:20:03 GMT

Thank you for providing some guidance! I will take into account your suggestions.

This is unrelated to the actual UART topic but it would be great to find a list of KConfigs settings for each driver in the future.

RE: High Speed 1 MBaud Async UART with Zephyr

Susheel Nuguru — Mon, 11 Nov 2024 11:24:23 GMT

I normally do not have a good feeling about using that high baudrate on UART where the CPU has other tasks to do.

To answer your questions

Nordic doesn’t have a dedicated guide specifically for pushing the UART Async API to 1 MBaud on the nRF52840. The closest resources are the general UART documentation in Zephyr and Nordic’s guidance around high-throughput UART applications, but these mostly assume lower rates and may not cover high-baud scenarios thoroughly. Achieving reliable UART at 1 MBaud on Nordic devices is possible, though it may require some adjustments for the interrupt handling and DMA settings to handle data at this speed reliably. Developers typically rely on insights shared in forums and DevZone posts, though these tend to vary in accuracy and applicability as SDK versions evolve.

For your second question, I agree that KConfig options for high-speed UART setups on Nordic devices can be frustratingly inconsistent, especially in the context of Zephyr configurations. The KConfig settings most relevant here would include CONFIG_UART_ASYNC_API, CONFIG_UART_0_ASYNC, CONFIG_UART_0_NRF_HW_ASYNC, and potentially CONFIG_UART_0_BAUDRATE for setting 1 MBaud directly. CONFIG_UART_0_NRF_FLOW_CONTROL can also be essential if you’re using hardware flow control. Settings like CONFIG_SERIAL_SUPPORT_INTERRUPT and CONFIG_UART_RX_TIMEOUT play a role in configuring the data-handling responsiveness and flow. That said, DevZone posts do become outdated, and Nordic’s nRF Connect SDK release notes are sometimes the only reliable way to confirm current, valid KConfig options.

On whether to use the Zephyr UART API versus the Nordic nrfx driver at 1 MBaud, I generally leans towards recommending the Zephyr API, especially if you’re working within Zephyr’s async context. The Zephyr UART API aligns better with the broader system, making it more adaptable for projects with expanding features like BLE. However, for specific high-performance needs—particularly when you’re seeing throughput issues with the Async API—using nrfx directly can sometimes give more control over the hardware specifics (like DMA and interrupt prioritization). But, this does come at the cost of some portability and integration simplicity within Zephyr. Nordic generally suggests sticking with Zephyr’s API where possible, especially for maintainability

Few things to keep in mind

With high-speed UART, even small delays in handling incoming data can lead to buffer overruns or missed bytes. When you add BLE later, the BLE and UART interrupts will compete, so you’ll need to carefully prioritize them. For now, ensure UART has high priority in handling interrupts.
At 1 MBaud, it’s best to offload some of the work to the hardware. EasyDMA in Nordic’s chips allows for efficient data transfer without bogging down the CPU. This reduces software overhead by using hardware to manage the byte counting and buffer filling, which is critical at these speeds.
High-speed communication works best with buffers big enough to handle the data burst and a properly set timeout that triggers processing right after data stops flowing. You’re aiming for a balance here—large enough to avoid overflows, but small enough to ensure timely data processing.

The changes to prj.conf can be something like below

CONFIG_UART_ASYNC_API=y               
CONFIG_UART_0_ASYNC=y                 
CONFIG_UART_0_NRF_HW_ASYNC=y          
CONFIG_UART_0_NRF_HW_ASYNC_TIMEOUT=200
CONFIG_UART_0_NRF_HW_ASYNC_RX_BUFFER_SIZE=256 
CONFIG_UART_LINE_CTRL=y               
CONFIG_SERIAL=y                        
CONFIG_SERIAL_SUPPORT_INTERRUPT=y      
CONFIG_UART_RX_TIMEOUT=1               
CONFIG_UART_0_BAUDRATE=1000000        
CONFIG_UART_0_NRF_FLOW_CONTROL=y

You need to make sure that you add hardware flow control to the uart instance, the example below shows adding hardware flow control to uart instance number 0

&uart0 {
    ...
    ...  // other settings you have
    hw-flow-control;
};