Romain and I spent the last few days trying to get the WiFi dongle to work with the SOM.
However, several issues had to be overcome in order to succeed in doing this.
Overcurrent detection had to be disabled for USB devices to be detected by the SOM.
WEXT and cfg80211
For the driver to work, wext and cfg80211 drivers have to be enabled in the configuration of Yocto. We found this out because the driver would not work. Fortunately, we stumbled upon this document from Intel.
Compile the correct driver
A confusion between the driver of our dongle (rtl8188eu) and the driver of cyL3D’s defunct dongle (rtl8812au) wasted a good amount of our time.… Read more
Today, Marc and I started to work on the common time reference shared between Phyllos.
As you may recall, we need this common time reference to be able to play synchronized animations with several Phyllos. Here is a gif to visualize an example of synchronized animation :
As explained in this post, we know since a long time that it is possible to transmit precisely enough a time reference with UDP. But we still have to choose one ESP32 to be the master ESP32 and to enforce its time reference to all other ESP32, and by extension all other Phyllos.… Read more
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
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:
client (typically a computer, for shell connection on the main_stm)
main_esp (to play shared animations)
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
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
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
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
I kept preparing the timing test for the ESP32 today. The challenge was to understand how FreeRTOS works, of course, but also to grasp the workflow of the WiFi on the devkitC.
The example I found first was simply about coding a usual UDP server/client pair. However, when I arrived to the actual testing moment, I realized that there was barely any chance of it working as I did not even provide a basic username/password to my program. So I had to discover more about how to setup the actual WiFi connection.
It eventually worked out. However, I am now stuck on a very annoying problem.… Read more
Today, I started to implement the code necessary to test the possibility to use WiFi for time reference between Phyllos as explained in this post. Although we mainly use ChibiOS for our applications, the documentation for ESP32 is in FreeRTOS so the code for this test will also be using FreeRTOS.
The plan for the test is to connect as many devkitC as possible to a main board (here it will be an Olimex E407 programmed with ChibiOS). The main board will be the master over one of the devkitC. When it will start the test, the slave will broadcast an UDP packet.… Read more