Async UART API in Zephyr timeout to slow

Hello all,

We are working on an nRF52832 and use the UART peripheral in the latests Zephyr release. As we have a lot of data to send from the nRF to the linux host we are using the async uart interface (DMA) and this works flawlessly. Sometimes the Linux host needs to send some small packets to the nRF side and thus we use the `uart_rx_enable` function. In our protocol timings are very strict and this is where the problem arises.

The DMA receive buffer is 128B long but many messages coming from the linux host are much smaller. We therefore need to rely on the timeout to get an interrupt before the receive buffer is full. We enable receiving as follows:

uart_rx_enable(uart_dev, rx_bufs[0], RX_BUF_SIZE, USEC_PER_MSEC);

We would thus expect an interrupt every millisecond, as soon as at least one byte was received by the DMA. The problem is that the timeout that we are measuring is much, much longer and we have determined a minimum of about 16ms. 

We suspect it may have something to do with the clock source of the interrupt but we need some pointers on how to fix this. 

Kind regards,
Daan

Parents
  • Thanks a lot for your feedback, Daan! 

    dpape said:
    I think we have quite good understanding of how this API works. In our opinion it doesn't work according to the documentation or the documentation lacks some details about timing. Please elaborate.

    I have two questions here: 

    1. Documentation states that “Inactivity period after receiving at least a byte which triggers uart_event_type::UART_RX_RDY event.” & “If some data was received and timeout occurred uart_event_type::UART_RX_RDY event will be generated. It can happen multiples times for the same buffer. RX timeout is counted from last byte received i.e. if no data was received, there won’t be any timeout event.” Can you confirm that at least one byte was sent in this particular case?
    2. As already mentioned, if you change the timeout to a different value, how long will the offset be then? I asked this because it would be interesting to know if you can see any pattern.

    Regards,

    Markus

Reply
  • Thanks a lot for your feedback, Daan! 

    dpape said:
    I think we have quite good understanding of how this API works. In our opinion it doesn't work according to the documentation or the documentation lacks some details about timing. Please elaborate.

    I have two questions here: 

    1. Documentation states that “Inactivity period after receiving at least a byte which triggers uart_event_type::UART_RX_RDY event.” & “If some data was received and timeout occurred uart_event_type::UART_RX_RDY event will be generated. It can happen multiples times for the same buffer. RX timeout is counted from last byte received i.e. if no data was received, there won’t be any timeout event.” Can you confirm that at least one byte was sent in this particular case?
    2. As already mentioned, if you change the timeout to a different value, how long will the offset be then? I asked this because it would be interesting to know if you can see any pattern.

    Regards,

    Markus

Children
No Data
Related