A Simple Firmware Test and Control Protocol

This article describes a protocol that runs on top of our basic packet we designed in the last article; we can use this protocol to test our embedded code that interfaces with the world over a communications medium such as UDP, BLE, or UART serial-line.

Now that we've designed the basic packet that will carry our higher-layer protocols, let's design a simple protocol that we can use to test the embedded software or firmware that we're developing. Say we're developing motor control firmware; we want a protocol to command our firmware to drive the motors and vary their speed. The protocol must enable us to address specific devices (e.g. motor-1 or motor-2), issue a command, and get a response indicating whether or not the command was accepted. To accomplish this, our protocol will have a device "address" (destination) field, a field to convey whether the packet is a request or a response and, if a response, whether the response is positive or negative, and a command field.

Here is our test protocol format (remember that this format is the payload of our basic packet):

We should keep in mind that we are designing an architecture for how our applications communicate with one another. That is, we expect this format to be useful and hopefully sufficient moving forward. Further, we expect our workplace peers who need to solve similar problems to use this format, or have a solid justification for why not.

Calling it an architecture reinforces the idea that the communications between applications at our workplace use well-known patterns that provide robustness and reliability. In the same way that we have software architectures, we need messaging, or network architectures. With the proper messaging architecture in place, even entry level software engineers can hit the ground running when developing networking applications.

Destination Field

The Destination Field indicates to which device the packet is destined. Architecturally it is important to separate the notions of destination (this field) and the command (described below). It can be tempting to use the command field to imply the destination, which

Request/Response Header

The Request/Response Header indicates whether the packet is a request or a response, and if a response, whether it is positive or negative.

Command Field

The Command Field pertains to the destination, and because it is a byte, there can be 256 commands for a particular destination. The command scheme should be well-planned to avoid overriding command syntax and semantics; again a protocol is part of an architecture that should be predictable and easy to use.