Non-Blocking Serial Data

So here is the thing. I LOVE efficient code.
Further, this project is beginning to push the limits of the MCUs, so having segments of blocking code running on both sides to facilitate serial comms was a heartache.

I knew in my heart of hearts that the most efficient way to send data down to the motion controller was as bytes which could be interpreted as bits.
If I were to send down a WORD (2 bytes) there would be 16 bits of data to play with in a very compact message.
A chunk of the least significant bits could serve as the velocity reference, 9 bits for a signed int -255 to 255, then the remaining 6 bits could be used for things like enable, selecting which motor to set point, or allowing both motors to see the same set point. Heck I could probably afford to include a estop bit in there as well.

In my hubris I decided to just start writing functions without doing much research, the code compiled just fine and would even interpret bytes from the Arduino IDE.
The issues started occurring when I connected the Motion Controlling Arduino Uno to my MCU ESP32.

I was able to validate that the MCU was sending good serial data by reading it with my Oscilloscope, but the arduino wasn’t recognizing the commands.
So this was when I decided to start my research.

I pretty quickly came across the following 2 articles on the Arduino forums which quickly showed me the errors in my code, whilst simultaneously showing me how to solve them.
https://forum.arduino.cc/t/serial-input-basics-updated/382007/2
https://forum.arduino.cc/t/demo-of-pc-arduino-comms-using-python/219184

The issues I was running into was related to the cycle timing of the micro controllers, and having both units boot at different times.
During the boot sequence the Motion controller would boot quickly and then start reading data from the initializing pins of the ESP32.
Once some of the errant data made its way into the stack, all further data communications would be off by a few bits, and then my sanitizing filters would dump the information.

Additionally, because I was writing non-blocking code the number of processor cycles between bits was actually way higher than I expected even at 115200 baud; where over 1300 instructions can be processed between received bytes.
The primary solution here seems to be adding a starting byte and a terminating byte wrapping my WORD to let the Motion controller know when good data is available.

I am now working on implementing and testing this code over the next few days…