how to use async uart api with hardware flow control on zephyr 3.2 with nrf52840?

[Volker]

Hi,

we have got some async uart api application running with zephyr 3.2 on nrf52840.

This worked fairly well until there have been added some file-write operations to the application, which are causing so much delay, that the application is not able to process the uart receivings fast enough anymore. This situation can be detected in software as the uart-dma-isr-event handler can see that the consumer queue for the received data gets more and more filled up.

But what is the proper procedure to tell the async-uart-driver that it should activate the hardware-flow-control (telling the sender to stop transmitting)?

- should it be done by not providing any requested dma-buffers anymore?

- should it be done by using the line-control api?

- is there any other means of doing this?

And what has to be done, when the application has processed all the data and is ready for getting the new receivings? How to tell the driver to deactivate the hardware-flow-control (telling the sender to carry on with further transmitting)?

Regards

Volker

[Amanda Hsieh]

Hi, 

we have got some async uart api application running with zephyr 3.2 on nrf52840.

Are you using vanilla Zephyr or NCS? If NCS, which version? Please be aware that our support is based on NCS. 

The flow control is typically set during the UART initialization and managed by the hardware/driver afterward, so there isn't a direct method to manually activate or deactivate hardware flow control during runtime in the Zephyr UART API.  However, you can control the flow of data by managing the buffers provided to the UART driver. If you stop providing buffers to the driver, it will stop receiving data and generate a UART_RX_DISABLED event. This could effectively tell the sender to stop transmitting. Here's an excerpt from the Zephyr UART API documentation that explains this:

If there was second buffer provided, it will become current buffer and we start again at point 2. If no second buffer was specified receiving is stopped and UART_RX_DISABLED event is generated. After that whole process can be repeated.

Any time during reception UART_RX_STOPPED event can occur. if there is any data received, UART_RX_RDY event will be generated. It will be followed by UART_RX_BUF_RELEASED event for every buffer currently passed to driver and finally by UART_RX_DISABLED event.

If you are using the vanilla Zephyr and the above cannot help, please contact ZEPHYR Discord. 

Regards,
Amanda H.

[Volker]

Hi Amanda,

thank you for your reply. We are currently using zephyr, but are within the decision process to switch over to NCS.

I studied the documentation about the async uart events carefully before, but there is no hint about what happens with the hardware flow control.

Is my understanding correct that stopping the providing of new buffers is the intended way of forcing the driver to use the hardware-flow control lines to tell the transmitter to stop transmitting?

This will then finally lead to a disabling of the uart interface.

As soon as the application thread has processed a reasonable large amount of the queued data, the uart might then be re-enabled again to tell the driver to use the hardware-flow-control lines to tell the transmitter to continue transmitting?

Regards,

Volker

[Amanda Hsieh]

Yes, your understanding is correct.

Volker said:

I studied the documentation about the async uart events carefully before, but there is no hint about what happens with the hardware flow control.

I would suggest contact ZEPHYR Discord for Zephyr UART API with your requirements.