Creating a hardware communication protocol

When you’re working with sensors or actuators using a microcontroller unit (MCU), you’ve got some common communication protocols to choose from.
The big players here are Universal Asynchronous Receiver Transmitter (UART), Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI), and even some parallel communication for things like LCD displays.
You’ll often see I2C and SPI in action, as they make data exchange pretty easy and efficient.
While UART, I2C, and SPI are your go-to options for most projects, I2C and SPI share quite a bit of functionality, allowing for simple read or write operations on specific registers without getting bogged down in complicated protocols..

Protocols can get pretty intricate, and they actually change depending on how sensors are set up, like with URSPI or I2C.
To keep everything running smoothly and avoid data mishaps—kind of like what happens with UR—you’ve got to stick to the same protocol for writing, passing, and interpreting values across URSPI and I2C.
Here, we’ll be using Universal Asynchronous Receiver Transmitter (UART) as our go-to standard protocol.
So, in the simplest terms, a protocol is like a handshake agreement that lets the Microcontroller Unit (MCU) chat with sensors, actuators, and other devices.
This back-and-forth is what makes data exchange possible!.

When it comes to data communication, it’s all about setting up an agreement on how to send information between different parties, which is basically what we mean by protocols.
You’ll find that there are a bunch of different protocols to choose from, each tailored for various sensors, actuators, and specific microcontroller units (MCUs).
However, it’s important to note that none of these protocols are perfect.
Some MCUs can really handle high-speed data transfer like a champ, while others might struggle with how much data they can push through at any given time..

When you’re setting up a protocol, it’s super important to make sure it’s tailored to fit your specific environment.
One term that pops up a lot is ‘Start of Text’ or STX, and it’s a big deal because it marks the very first byte that kicks off the protocol.
Depending on company practices, this can be just one byte or maybe two.
Now, as for the ‘End of Text’ or ETX, it’s not always there, and in some cases, STX might even double as the endpoint! Also, don’t forget about the checksum, which is often referred to as CRC—it’s basically a way to verify that the data you send and receive is kept intact and accurate, and it can also come in one or two bytes..

When it comes to designing a protocol, the first thing you’ll need to do is set up your Start of Text (STX) and End of Text (ETX) markers—usually, these are just one byte each and can take on values from 0 to 255.
For instance, I decided to go with the STX represented by AF and the ETX by 7D in hexadecimal after generating a random number.
It’s pretty cool because the order of these elements can actually change from one protocol to another, giving you lots of design flexibility.
After that, you can’t forget about the data length, known as Len, which is really important because it tells you how to structure the data.
And don’t leave out the CMD data elements that come after the length; they’re key for proper referencing!.

When you’re diving into data length, keep in mind that it might go beyond just one byte, and there’s a chance it could take up two or even three bytes, depending on what you prefer.
Now, when we talk about the CMD, the kind of data you’re sending plays a huge role; it can either be a command to tweak an actuator’s speed or something straightforward like just turning it on or off.
You’ll find that there are all sorts of command types out there, so it’s important to have a CMD area that can handle more than 256 types.
This might push you into needing two bytes instead, but to keep things simple for now, let’s just stick with one byte..

Let’s dive into data areas and checksums! First off, it’s important to know that the data area might not always be there.
If there isn’t any data, the following byte just takes its place without leaving a gap.
But when the data is present, you’ll see it labeled as Data 0, Data 1, Data 2, and so on, which affects the length of the data.
When we talk about checksums, there are different methods out there, but we’re going to keep it simple and focus on a one-byte checksum, usually calculated using the XOR operation by including all the preceding data.
Lastly, don’t forget about overflow! Performing addition with a single byte can lead to this issue, creating a bit of a loop, and there are multiple ways to address it..

So, after you do the XOR operation, you can totally subtract from 255 or get creative with other methods to build your protocol.
Keep in mind that there aren’t any perfect protocols, and the order isn’t set in stone.
For example, a command (CMD) can come right after the start of text (STX) or stand alone.
We’ll lay out our protocol with elements like start of text (STX), expectations, attributes, command (CMD), data 0 (D0), data 1 (D1), and it wraps up with a checksum and end of text (ETX).
In our next session, we’ll dive into implementing this protocol using Arduino and learn how to send data based on it..