Coprocessor code and uarte device driver related issues

[Ethan.Shi]

Hi

I'm working on adding software flow control in coprocessor code，

1.CONFIG_UART_ASYNC_API and UARTE_INTERRUPT_DRIVEN ，What's the difference between the two macro definitions，UARTE_INTERRUPT_DRIVEN macro is used in coprocessor code，I read some other questions, which are recommended CONFIG_UART_ASYNC_API.

2.Through the data manual of 52833 Uarte related chapters，the RXD.MAXCNT register must be set to RXD.MAXCNT > 4,But I found that RXD.MAXCNT is assigned to 1，Through this function nrf_uarte_rx_buffer_set，Is there any reason for this.

3.Through the data manual of 52833 Uart related chapters，The UART receiver chain implements a FIFO capable of storing six incoming RXD bytes before data is overwritten. Will this FIFO still work in uarte and can it be configured.

There have been some introductions in this issue, but I want to know more clearly

I'm not very good at English. I hope I can speak it clearly.

thank

[ovrebekk]

Hi 

By software flow control, do you mean you want to use the LPUART driver?

This is a UART implementation using a software flow control scheme to allow the UART peripheral to be disabled when idle, to reduce the sleep current consumption. 

In order for this driver to work you need to implement it on both sides of the link. 

2.Through the data manual of 52833 Uarte related chapters，the RXD.MAXCNT register must be set to RXD.MAXCNT > 4,But I found that RXD.MAXCNT is assigned to 1，Through this function nrf_uarte_rx_buffer_set，Is there any reason for this.

Where did you find this information?

According to the register definition here you should be able to use any value between 0 and 0xFFFF for these registers, but it needs to be > 0 in order for you to send or receive anything. 

3.Through the data manual of 52833 Uart related chapters，The UART receiver chain implements a FIFO capable of storing six incoming RXD bytes before data is overwritten. Will this FIFO still work in uarte and can it be configured.

There is no FIFO in the UARTE peripheral, since it is able to send data directly to RAM through the EasyDMA controller. Instead you provide a pointer to a RAM buffer, and set the size of the buffer through the RXD.MAXCNT register. 

Best regards
Torbjørn

[Ethan.Shi]

Hi

I used the 52833 as a coprocessor, connected to the host side via a serial port for OpenThread functionality.

At present, the hardware flow control cannot be used, but the data of 52833 May be lost due to the large amount of data sent by the host, so we decide to use the software flow control. "XON""XOFF" characters are sent through 52833 to control the host end to start and stop sending data.

Where did you find this information?

If there is no RX FIFO in the UARTE, does it cause data loss

Thank you very much

[ovrebekk]

Hi 

The paragraph you point to is only relevant if you issue the STOPRX task, in order to abort the UART receiver before the buffer has filled up. If you only have 1 byte configured in the receive buffer there should be no need to do this. 

When using the UART driver you should be able to decide how large the RX buffers are, depending on the buffer you provide in the uart_rx_buf_rsp(.. ) function, as seen here. Using only 1 byte buffers is not recommended if you are expecting to receive a lot of data. 

Ethan.Shi said:

If there is no RX FIFO in the UARTE, does it cause data loss

The RXD.PTR register is double buffered, which means you can prepare a second RX buffer after you have configured the first. This allows the UARTE peripheral to seamlessly change from one buffer to the next, without having to wait for the application to provide a second buffer. 

In Async mode the UART driver will utilize this functionality to make sure that you can receive data without packet loss, as long as you scale the UART RX buffers based on the max length of interrupts in the application. 

As an example, if you know that the CPU could be busy in a high priority for up to a millisecond, you should ensure that the UART RX buffers are large enough to receive data for a millisecond without needing to be reconfigured. 

Best regards
Torbjørn

[Ethan.Shi]

Hi

Thank you very much for your answer, which is very helpful to me. I would like to know more about it

Currently, we are based on the openthread Coprocessor example and use the UARTE_INTERRUPT_DRIVEN mode by default,Is it possible to use double buffers in this mode?

Can I understand it this way.If I don't know how much data is going to be on the host side per unit of time, setting the random size of the RX buffer can cause data loss, even with dual buffers

Also, how does HW flow control RTS work in UARTE without RX FIFO?

ethan

[ovrebekk]

Hi Ethan

In order to utilize double buffering you need to use the ASYNC API, instead of the INTERRUPT_DRIVEN API. 

Ethan.Shi said:

Can I understand it this way.If I don't know how much data is going to be on the host side per unit of time, setting the random size of the RX buffer can cause data loss, even with dual buffers

If you don't use flow control then you can have data loss yes, if you don't update the RX buffers fast enough once they fill up. Whether or not you have data loss depends on how long interrupts you could have in your application, and how long the RX buffers are. 

If you use flow control then this is not a problem, and the communication would be delayed until the high priority interrupt is over and you can update the buffers. 

Ethan.Shi said:

Also, how does HW flow control RTS work in UARTE without RX FIFO?

After reading the documentation again I realize that the UARTE peripheral still has an RX FIFO, so my earlier statement that there is no FIFO is not correct. Sorry for the confusion. 

In other words RTS works essentially the same way. 

Best regards
Torbjørn

[Ethan.Shi]

Hi

Are the size of RX FIFO and the working mode of trigger flow control configurable？

If it cannot be configured, it is impossible to control the transmission and stop of the host by software flow control

Thank you for your answer

Ethan

[ovrebekk]

Hi Ethan

No, the size of the RX FIFO is fixed. The hardware flow control method is not really configurable (other than being able to turn it on and off), but it is possible to implement different kinds of flow control in software, or as a combination of hardware and software using the PPI, timers, GPIOTE etc. 

Whether or not a particular flow control scheme can be implemented depends on the requirements. Reception is not really a problem if you size the RX buffers correctly, since the nRF should be able to receive continuously when utilizing double buffering, but the question is how the host should tell the nRF device to stop transmitting if the host is unable to receive any more data. 

If you have a particular scheme in mind maybe you can share the details, and I will try to think of some way this can be done using the UARTE peripheral. 

Best regards
Torbjørn

[Ethan.Shi]

Hi

The host side is the arm cortex A53 core CPU, which runs the Linux system and has a fast processing speed. I don't think it will cause data loss.

Thank

Ethan

[Ethan.Shi]

Hi

I found that there is a GPIO between 52833 and the host. I can configure GPIO as RTS to start flow control.That should solve my problem.

Is there a way to configure GPIO into an RTS via software.

Thank 

Ethan

[Ethan.Shi]

Hi

I have successfully configured the RTS through the device tree.It meets my current job needs

Thank you for your answer

Ethan