Electronic – What kind of communication protocol is this

variable-length commands

Many people highly prefer fixed-length commands. If you need to have variable-length commands, you need to think about:

• Is it possible for accidental noise (or malicious pranksters) to generate something that will overflow my receive buffer?
• If a little bit of noise flips the high bit of the "length" field of a short packet (making it appear to be a long packet), does my system properly recover?
  • bad: the microcontroller stops everything, waiting for the rest of what it thinks is a "long" packet. Several days later, after many frantic attempts to send it messages saying "deploy the airbags", "lower the control rods", "Open the pod bay doors, HAL", etc., it eventually gets all the bytes it expected, sees that the checksum fails, throws away this "long packet", and starts working normally again.
  • good: after a minute or some other reasonable time, the microcontroller times-out, erases everything in the command buffer (possibly discarding a few "deploy the airbags" messages after the length-corrupted message), and starts working normally again.
  • good: The microcontroller immediately recognizes there is some error in the header (which includes the start byte, the length field, and the header's checksum), and immediately throws away that header and begins searching for the start byte again. The microcontroller immediately starts working normally again, recognizing the first valid command (the header's checksum is good, and also the data's checksum is good) after the corrupted command.
• Does the microcontroller immediately send one ACK after it sees that the (final) checksum of the packet is good, and then execute the command, and finally send back a response to that command? Or is it better to send only the ACK or only the response? Which one makes it easier to debug?

general protocol design tips

There are many more or less simple protocols listed in the "Serial Programming" Wikibook.

If you're lucky, perhaps one of them is already perfect for your application. Or at least close enough that it only requires a little tweaking to fit.

Pretty much everyone who successfully develops a new protocol goes through these phases:

• 1 I may not know much, but reading other people's protocols gives me a headache. It looks like a bunch of unnecessary complexity. Let's dump all that stuff and build a nice, simple protocol.
• 2 It's not working. Maybe if I add [feature 1] then it will work.
• 3 Better, but still not working very well. Perhaps add [feature 2]? ...
• 98 Finally it's working. I better write down who does what in my simple protocol so that if I need to switch to a different microcontroller or want to write a better program on the PC, I'll remember how it goes.
• 99 Funny how my simple protocol takes so many pages to describe.

SPI devices also typically have a chip-select signal (sometimes referred to as a frame sync) that is used to multiplex devices on a single SPI bus. Thus, SPI is often referred to as a 3-wire or 4-wire interface (MISO, MOSI, CS, and CLK; for unidirectional devices, either MISO or MOSI can be omitted). A frame is typically assumed to start at the first bit after the chip-select signal is asserted, but every device has its own protocol. You'll need to adhere to whatever the other side of the link expects.