Can’t you hear my protocol byte so

In our design, we want to use a STM as our main processor bu also an ESP to deal with the network part of our device. This imply a communication between those two.

The low-level protocol

At first we wanted to use the UART protocol. Yet because we will have very strong magnetic fields, we migh need a more reliable protocol. We decided that we will implement both an UART and an SPI interface and test both on the device. As of today we have implemented the UART communication but as we don’t have on our development board (iot-node) any RTS/CTS pin that can be mapped to the arduino connectors we used delays to avoid the overrun we initially had. For the next tests we will probably use an other board.

The upper-level protocol

We want the communication to be possible in both directions. We will also want it to have a re-connection mechanism in case an error is detected by either processor.
Here is a table that list the signals of the current protocol. It will probably evolve later on.

NameSenderMeaning

IMG_TO_STM

ESP

Will send an Image

ANIM

ESP

Will send an Animation

IMG_TO_SRV

STM

Will send an Image that
should be sent to the server

IMG_TO_BOX

STM

Will send an Image that
should be sent to a box

ACK_BEGIN

STM or ESP

Request accepted waiting for data

ACK_END

STM or ESP

Data received.

ASK_RECO

STM or ESP

An error occured

ACK_RECO

STM or ESP

Received that the error occurred.
Restarting the protocol.

The transmission will start by one of the first four signal sent. Then the receiver will send an ACK_BEGIN and the data will be sent. If everything has worked the receiver send an ACK_END. If any error got detected, the receiver send an ASK_RECO that will be followed by a ASK_RECO and we go back to one of the first four signals.
To detect error we have two mechanism. First of all, all those signals’ byte will start with a 0 and all the data’s byte will start with a 1. That way if we are expecting data and we any byte starting with a 0 we detect an error and vice-versa. The second is that both the ESP and the STM know the size of an image. So if they don’t received the correct number of byte they will detect that an error occurred.

We already implemented the transmission of an image from the ESP to the STM using functions that don’t depend of the communication protocol so it will be easy to adapt if we switch to the SPI.

The biggest issue we will be facing will be to deal correctly with the different threads (receiving and sending bytes without data races). On the STM we coded a state machine to send the correct byte regarding what we receive. On the ESP, as we are only sending images, the ESP sends IMG_TO_STM then wait for the ACK_BEGIN and sends the image. If the STM detects an error the reconnect part starts.

Trace of the execution

Here is the log of the STM32. At first the ESP and STM are exchanging data without issue : the ESP says it will send an image, the STM send the ACK_BEGIN and print “waiting for image”. Then the ESP sends the image (here it only is two bytes). When the STM receive the image it print “Image received and the two bytes and then sends the ACK_END to finish the transaction.
At one point, I unplugged one of the wired (data from STM to ESP). The consequence is that the ESP never receive the ACK_BEGIN so it keep sending IMG_TO_STM. On the STM part it receive all datas correctly so after one request it expects the data. As it sees that it keeps receiving commands, it print the error message and begin to attempts a reconnect.
Then I plugged the wire. The ESP receive the ASK_RECO that the STM kept sending and finally respond with ACK_RECO. The STM prints “Reconnexion done” and the exchange goes back to its previous state.


Leave a Reply

Your email address will not be published. Required fields are marked *