Let’s push it !

So far, the ESP32 was able to receive images from the server through MQTT and transmit them to the STM32. It also could transmit animations but only if the animation was directly hardcoded. So what we wanted to do was to be able to transmit animations through MQTT just like images and also to find a way to chose if we want to receive an animation or an image.

First things first : the server side

The first step we did to go in this direction was to find a way to transmit animations.
We chose that, at least for now, the server will publish periodically on two topics. There will be one topic for the images and one for the animations. That way, all devices connected will be able to chose what topic they want to consider.
An issue we faced was to deal with the size of the animations. We don’t want all animations to have the same number of images so we had to find a way to get this information. To do so we chose to modify the format we used to store the data (images or animations) on the server. So far it was a file filled of 0 and 1 separated with comma, each number representing a marble. For instance here is the file of the image we used in the previous tests:

1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,

To store the size of an animation, we decided that the first line of each file will be the number of images it contains. So for instance here is the same image as above but with this change:

1
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,

And here is this animation we used as an example:

3
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,1,
1,0,1,0,1,1,1,1,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,0,
0,1,0,1,0,0,0,0,1,

With this format of file, the back-end can directly know how many images the animation has. It will transmit this information through MQTT to the ESP.

Let’s receive and transmit

On the ESP side at first we had little changes to do, it simply had to subscribe to both topics and once it received on either of them it transmited the data to the STM just like before.

What about the display ?

On the STM side we simply had to receive the data from the ESP and display them as we already could.

So is that it ?

Well not yet because at this point, the STM is displaying images and animations in the same time. What we want is a mechanism to chose between displaying an animation or an image. On the final device it will be done through a capacitive button on the side of the box, so the best solution was to use the button on the IoT-node board.
When the button is pushed we want the STM to switch between images and animations. Yet, if we simply do that, the UART bus still transmit both images and animations. In the case where the animation is big and we don’t want to display it, it is a big waste.
A better solution, and the one we chose, was that when we want to switch between image and animation, the ESP unsubscribe to the previous topic and then subscribe to the other one. This way, when we want to display animation, the ESP only receive animations and transmit them to the STM and so on if we want images.
Yet, to do this, we had to transmit the information that the button was pushed between the STM and the ESP. We added two new commands on our protocol, the first one, sent by the STM to inform of the switch and the second one from the ESP to confirm this switch.

On top of that we also had to modify how we dealt with the messages we received in both the ESP and the STM.
On the ESP part, so far we were only looking at the first byte of each transmission as they were one byte long. Yet know the ESP can receive the byte to state the end of the transmission in the same time as the byte to change the topic. This would happen every time the button is pushed during a transmission.
On the STM side, so far we were receiving the messages in an interrupt routine and then doing all the treatment (checking that the exchange is valid, storing the image when needed and sending the answer) in this same routine. I realized it was a very bad idea. To replace this, now the interrupt copy the message into a variable and raise a flag to warn of the new message. Then a regular thread will just wait for this flag to be raised and when it is it will just do the treatment itself. That way the interrupt routine last less time.


Leave a Reply

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