Shell in the air

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.

3 Replies to “Shell in the air”

  1. What you describe in your last paragraph is a DNS-like system, but without a DNS server. That’s exactly what mDNS is, and the ESP32 SDK has a built-in mDNS implementation that’s trivial to use. Did you intend to use it ?

    1. Hello, thank you for commenting ! I may be mistaken about how a DNS is working but I feel that what is needed in my situation is a bit different. Indeed, I do not know any IP address in advance, even between Phyllos. If a DNS server existed, I would not know its IP address either.

      Also, I have changed the way things work. Now, the Phyllos regularly actively advertise their IP address and each Phyllo maintains a sort of switching table where each address has a limit of validity date.

      1. Yes, you’re correct with respect to how DNS works. mDNS is different though: a mDNS request is sent using multicast (you can see that as a kind of broadcast). Every connected Phyllo listens for requests and, for instance, when Phyllo 01 sees a request for “phyllo01.local”, it replies. You can also use more elaborate queries such as “hey, i’m looking for all phyllos” and all phyllos will reply. In mDNS, there is no such thing as a central DNS server with a known IP.

Leave a Reply

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