UART being overloaded with too many requests fix

[JensOgorek]

We had a problem with a robot, it crashed with a lot of checksum mismatch outputs.
The traceback pointed towards the UART.

It seems the UART was overloaded with too many requests that flooded in while it was still sending.

I recreated the issue with two esps. The expander esp had 21 input modules to create a higher load on the connection.
After both were running, I could trigger the issue with spamming a command like p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.info();p0.version()

After spamming it for multiple seconds, it resulted in the same behavior the robot displayed.

The fix is to wait for the TX to be done sending within the echo method.

[SeaTechRC]

Hello,

As you pointed out in the original post, the issue arises, when too much data is sent over UART.
One thing to note is that in the usual use case (for example in the FieldFriend) messages from p0 to core are always smaller than messages from core to the Jetson. Thus, the limiting factor will be the TX speed from core to the Jetson and the RX Fifo in core for data from p0 will be overfilled. (That could also explain the 1-3 missing characters in #136 as the prefix added by core "p0: " could add such a delay?)
Important to note is of course that the ESP IDF uart driver blocks when the TX buffer is full.

There would be 3 options I could think of:

• Allow core/p0 to ignore lines from UART if overloaded (bad idea, since there might be important commands for motors, etc.)
• Allow core/p0 to send a "empty" response when overloaded, so it can send faster than it receives, thus removing wait time on TX. (Could be problematic if the data core/p0 was supposed to send is time critical and a second request would take too long)
• Allow for transactional messaging (perhaps with some allowed overlap, so multiple transactions could run in parallel to reduce waiting times), so the sender has to wait for a response (to some degree) and spamming could be ignored (not following protocol)

Kind regards

PS: There might be internal discussion about this issue, that I might not know about. I appoligize if me commenting on this issue is unproductive.

[JensOgorek]

Yes, we had internal discussions about that issue, but we appreciate all feedback. I'm currently doing other important tasks, but when these are done I will go back to this.
I was experimenting a few weeks ago with better parallelization of all communication in Lizard. Since everything is just handled by the main thread at this time.