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.
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
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
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
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