Patch for solving communications errors when using serial monitor

[Ayoub-Farah]

The following pull request will :

• Detect if there is any overrun errors in the communication
• Reinitialize the DMA an error is detected

All of this is done in the uninterrupted task.
This is related to #16 and is a short term patch to be able to use RS485 simultaneously with the serial monitor.

[jalinei]

My only concern is the time taken by this restart procedure. I understand the occurrence of the overrun is not frequent at all, but I would love to know what time it takes as an extra overhead for the control task in case it goes through this non frequent edge case.

Also, a second concern is : what happens to the data when overrun flag appears ? Is there garbage data circulating once, prior to the circular buffer flushing ? Or the data is missed once, and then the DMA restart fixes it ?

Last question : Is it okay to miss one data frame times to times ? How do we document that ? At the moment we do not inform the user one data frame is missed, we only silently restart the DMA to avoid losing the data stream.

I would at least add a LOG message for these cases, with a relatively high log level (higher than DEBUG)

[Ayoub-Farah]

My only concern is the time taken by this restart procedure. I understand the occurrence of the overrun is not frequent at all, but I would love to know what time it takes as an extra overhead for the control task in case it goes through this non frequent edge case.

The reinitialize_rx_dma_if_overrun function takes approximately 820 ns to execute when it is invoked.

Also, a second concern is : what happens to the data when overrun flag appears ? Is there garbage data circulating once, prior to the circular buffer flushing ? Or the data is missed once, and then the DMA restart fixes it ?

When the overrun flag appears, the RX callback is not executed and the new values cannot be retrieved.
Therefore, the system continues using the previous values received over RS485 until the DMA is restarted.

Last question : Is it okay to miss one data frame times to times ? How do we document that ? At the moment we do not inform the user one data frame is missed, we only silently restart the DMA to avoid losing the data stream.

I would at least add a LOG message for these cases, with a relatively high log level (higher than DEBUG)

The consequence of missing a value depends on the application, for an application with a low sampling frequency (e.g. MMC working at 50 Hz) it's negligeable but for a high sampling application (several hundred of hertz) missing a value can result in noise in the control.

The latest commit adds a log warning when a value is missed due to an overrun.

[Ayoub-Farah]

Until now, we were using low-level drivers to configure the DMA. There was a suspicion that the DMA channel might also be used by the OS for another task, and since we were not using the OS driver, zephyr had no way to detect that the channel was already allocated.

For this reason, we replaced the low-level implementation with the Zephyr DMA driver. However, the overrun error still occurred.

After testing with the Zero Latency Interrupt (ZLI) mode disabled, the errors stopped occurring. This suggests that the root cause of the problem is likely related to ZLI.