I've been playing around with the hoverboard over serial, and the serial receive DMA can get out of sync with the four-byte command stream, especially on startup. It starts up crazy, and running fast.
This implements a minimalistic solution: adding a preamble and checksum, and ignoring the command if they're not right.
As written, it's compatible with Emanuel Feru's framing, but doesn't depend on the rest of his work.
It's fairly simple to compute the XOR of three numbers, so it should work well enough on basically any client microcontroller. Of course, people who are using UART control will need to adapt their client code. I don't know how many of those there are, or how many have rolled their own framing solutions up to now.
I've been playing around with the hoverboard over serial, and the serial receive DMA can get out of sync with the four-byte command stream, especially on startup. It starts up crazy, and running fast.
This implements a minimalistic solution: adding a preamble and checksum, and ignoring the command if they're not right.
As written, it's compatible with Emanuel Feru's framing, but doesn't depend on the rest of his work.
It's fairly simple to compute the XOR of three numbers, so it should work well enough on basically any client microcontroller. Of course, people who are using UART control will need to adapt their client code. I don't know how many of those there are, or how many have rolled their own framing solutions up to now.
Here's mine. :)
=================== copied the uart framing idea from https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC
to use: send $AAAA to start frame then steer, speed as usual and XOR($AAAA, steer, speed) as checksum
commands that don't match are ignored, and UART DMA is reset hopefully this will set it up to catch the next one re-send frequently.