Async UART API in Zephyr timeout to slow

RE: Async UART API in Zephyr timeout to slow

Albrecht Markus Schellenberger — Mon, 01 Aug 2022 06:13:06 GMT

[quote user="Jonas Dptechnics"]This ticket can be closed. Thank you for your input![/quote]

Thanks a lot for your feedback, Jonas! I will close the ticket then 😊

Cheers,

Markus

RE: Async UART API in Zephyr timeout to slow

Jonas Dptechnics — Thu, 28 Jul 2022 14:56:13 GMT

Hi Markus,

I work for Daan's company.

1) unfortunately I do not have any other nRF devices at present

2) thank you for your help which gave us inspiration to try again in the near future but for now we are using interrupts again and handling the inevitable errors properly so it works quite well on 1mbps now

This ticket can be closed. Thank you for your input!

RE: Async UART API in Zephyr timeout to slow

Albrecht Markus Schellenberger — Wed, 27 Jul 2022 07:32:31 GMT

[quote user="dpape"]

Yes this is the case

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.

Anything below 16ms gets unstable and gives timeouts around 16ms. Above 16ms it works as expected.

[/quote]

Ok thanks, Daan!

Have you tried the API on other nRF devices and if so, do you see any difference in behaviour? Do you have the possibility to share a log demonstrating the issue?

Regards,

Markus

RE: Async UART API in Zephyr timeout to slow

dpape — Tue, 26 Jul 2022 13:50:26 GMT

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?

Yes this is the case

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.

Anything below 16ms gets unstable and gives timeouts around 16ms. Above 16ms it works as expected.

RE: Async UART API in Zephyr timeout to slow

Albrecht Markus Schellenberger — Thu, 21 Jul 2022 06:49:21 GMT

Thanks a lot for your feedback, Daan!

[quote user="dpape"]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.[/quote]

I have two questions here:

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?
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

RE: Async UART API in Zephyr timeout to slow

dpape — Wed, 20 Jul 2022 14:43:52 GMT

Hello,

I understand that the callback is thus purely software and not caused by a hardware interrupt of the DMA controller, therefore you call it a callback function.

I totally understand that the uart_rx_enable function defines the inactivity period. We expect this to call the callback after x amount of time after the last byte was received. We are therefore convinced that we should receive the callback after a timeout of 1ms when we pass `USEC_PER_MSEC` as the timeout parameter. However we see a minimum timeout of 16ms. You suggest to do some modifications, but please let me know what kind of modifications are possible. In my opinion we can only pass the parameter.

[quote userid="100109" url="~/f/nordic-q-a/90203/async-uart-api-in-zephyr-timeout-to-slow/377855"]Otherwise, the uart_event_type gives quite a decent description of how this API is supposed to work. [/quote]

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.

RE: Async UART API in Zephyr timeout to slow

Albrecht Markus Schellenberger — Wed, 20 Jul 2022 12:21:26 GMT

Hello Daan,

[quote user=""]We would thus expect an interrupt every millisecond, as soon as at least one byte was received by the DMA. [/quote]

First of all, I would like to clarify that when using the Asynchronous API, there is no interrupt function. The triggered events are handled by a callback function instead.

[quote user=""]The problem is that the timeout that we are measuring is much, much longer and we have determined a minimum of about 16ms. [/quote]

That being said, the timeout of the uart_rx_enable() function defines an inactivity period. I assume that you might want to do some modifications there.

[quote user=""]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. [/quote]

Otherwise, the uart_event_type gives quite a decent description of how this API is supposed to work.

Cheers,

Markus