How to play with Kronos

Today, Sibille and I tested the common reference time sharing between Phyllos. After coding the whole part, it worked pretty well and we managed to communicate with three Phyllos and the main_stm almost on our first try. 

What was just a bit more challenging was when we tried to make the current time master (see yesterday’s post) disappear so that a new one could be reelected. 

The tests’ main points

We needed to make sure that we could propagate the time tops from the master chosen among the bottom PCBs, through the main PCB and up until the main STM32.… Read more

UART, UART, UART (and shell)

As explained in this post, we have decided to use FreeRTOS on our main board. Last week, Sibille and Vlaya have successfully adapted the frame sending code for SPI buses. For The past few days, Sibille and I have wrestled with the UART communication code. 

Here is how the code evolved since my last post.

Shell implementation

At first, when I began coding the UART server, it was closely related to the shell (over WiFi). I also communicated with the ChibiOS shell on the other side of the UART. The next step of my reflexion was to realize that it wasn’t natural to have the shell on the STM32 rather than the ESP32 and I stopped using the ChibiOS shell. … Read more

UART’s breakthrough !

Today, thanks to Xavier’s tips, I finally managed to write a satisfying workflow for the UART server. I used the ChibiOS’ mailbox system on the STM32 and emulated it with queues on the ESP32.

Each applications is in charge of allocating the actual memory space of the data. The server only manages a 256 words long table to store a single pointer for each of the 256 possible ports. This pointer references two mailboxes. One enables the application to provide a buffer and its length to the server while the other enables the server to signal that a given buffer has been filled with a given number of bytes.… Read more

UART flow control

Today, as I was working on implementing the different servers from my last post, I realized a problem occurring on the UART connection between the main_esp and the main_stm. As I previously discussed in that post, I had to tackle the issue of distributing the traffic on the UART data bus.

To this end, I began to write a sort of server on the ESP32. It copies the port system on an internet server. The first byte of each frame encodes the function the following data line must be transferred to. In this approach, two problems must be tackled.… Read more

How to distribute traffic

In one Phyllo, we have two ESP32. Let’s call them main_esp and bottom_esp to match main_pcb and bottom_pcb. As far as WiFi communication is concerned, there are three types of possible data flows:

  • main_esp ↔ client (typically a computer, for shell connection on the main_stm)
  • main_esp ↔ main_esp (to play shared animations)
  • main_esp ↔ bottom_esp (the two ESP32 from the same Phyllo to provide target rotation speed or maybe also turn off main_pcb)

For each flow, there must be a protocol to discover the IP addresses. One solution is to broadcast a request for a specific Phyllo IP address. This solution is especially useful for the shell client.… Read more

Out of the shell

At last the shell is running satisfyingly. Finishing it, I had two last problems. The first one is because Ubuntu finishes its lines with a lone line feed whereas the ChibiOS shell expects a carriage return before it. When it does not get it, it does not reply.

The second problem was that the shell not only returns feedback on the command, it also echoes the command itself. Which is then printed a second time to the user. I did not find another way around this that simply comparing the response to the answer and only print the different part. This may lead to some concurrency issues since the thread receiving the responses is different than the one sending them but even if we sometimes cannot wait to send a new command, at worst we will get the first command printed twice instead of once which is not very important.… Read more

Who am I talking to ?

Today, I came across a problem regarding the information exchange between the STM32 and ESP32 of the main_pcb. What makes the situation a bit special is that not only can the STM32 want to talk to the ESP32, it can also send it information meant for another device. The latter case is about responding to a shell command which must be forwarded through WiFi. Thus the ESP32 here acts a little like a router.

The problem was the following. How can we know if a given byte is meant to be forwarded or not ? As we planned not only an UART connection but also an SPI connection between the STM32 and the STM32, we can use one for each type.… Read more

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.… Read more

Timing with ESP32, conclusion

Today I corrected the test of the ESP32 as I suggested yesterday. I added more ESP32 and I modified the code to emulate a busy CPU situation. I also paid close attention to the regularity of the timing between emission and reception of the UDP packets.
Here is a picture of the setup:

For the question of the stability of the timing between emission and reception, I found out that it is not stable enough. Here we can see that the timing can at least vary between 0,1 and 0,2s which is too much.

However, as shown below, the precision is fairly good for the reception.… Read more

First test on ESP32

Today was day of the test. It was actually quite different from what I planned, in this post especially.

First of all, I did not manage to make an ESP32 receive its own broadcasted packet. Apparently, it is not natural for a device to receive a packet sent by itself. I still have some leads to follow about it so I will maybe continue to look for a solution. In this test, there was simply an ESP32 which did not received packets. It is also possible to accept that. Indeed, we will have 2 ESP32 on each Phyllo. One on the main_pcb and another on the bottom_pcb.… Read more