For reminder, as the main intelligence in a Phyllo is main_pcb which will be rotating, we cannot tolerate to only have a shell over USB. Thus we have decided to have connect to a shell using WiFi.
I have been implementing this those past few days. Surprisingly, I actually encountered a few friction points.
First, let me describe more precisely the situation we have. The shell is controlling the STM32 and the WiFi is run by an ESP32. We thus have two layers of data transmission. The first one with WiFi between the user and the ESP32 and another one via a data bus between the ESP32 and the STM32. Also, the ESP32 only has a relay role. It is an interface between WiFi and the data bus and does not process any data.
In the beginning, I planned to use a SPI bus as the data bus. However, the user may have long pauses between two commands and I did not want the ESP32 to be the master on the SPI bus. Thus this solution was not appropriate as the clock would have to be transmitted for nothing most of the time. Also, the amount of data transmitted being negligible, it was a waste of resources to use SPI.
Therefore, I naturally chose the UART bus instead. However, when testing my code, I realized that using UART0 on the ESP32 as we did in the PCB was not appropriate as it is used to flash the ESP32.
Then, when it comes to the actual code, I had a few unexpected problems as well. The most annoying one was the watchdog. Indeed, most of the time, the ESP32 is waiting for commands from the user. In the code, it corresponds, to having a blocking call to the receive function in the socket. However, as a human being is not very reactive, the watchdog soon complains that is was left alone for too long. What is tricky in this situation is that there is no parameters in the receive function to set a timeout. Instead, you have to set it directly on the socket file descriptor itself. But then, it is not possible to distinguish between a failure of the receive function because of a timeout or any other reason. So I had to also provide a “keep-alive” function for the client to prevent the socket from having timeouts.
In the end, the operation of the connection through WiFi is as such. First, the client sends an UDP packet broadcasting the name of the Phyllo it wishes to connect to. The Phyllo echoes to the client which provides the client with the IP address of the Phyllo. Then, a TCP connection is established. This connection is kept alive by the client and is either terminated actively by the client or by a timeout of the ESP32.