As I wrote in my previous posts, the ESP, the STM and the server were working together to receive images or animations depending of what the user wants. Now it’s time for the STM to become the sender.
We want the devices to be able to received images from the server but we also want to establish a connection between Touchs to send images from one to the other. On top of that at the end we want to have a communication between both devices in both ways. But as you may know chi va piano va sano. So first things firts, we implemented the emitting part for the first device.… 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
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
Last friday I mainly worked on getting the new marbles (the ones that hadn’t undergone any heating process) to the desired magnetic field values. Remember, on this post I had already manage to have the marbles we already heated at the desired value. It needed a heating time around 5 min, so I instinctively thought that for marbles that had undergone no heating, it would need a longer time. I was wrong. And not slightly wrong, but more like completely wrong.
So I started heating at 300°C for 6 mins, it was too much and the magnetic field almost completely disappeared (barely noticeable).… 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 the last two days, I mostly spent time making the code clearer. Some big functions got divided to make them easier to read and to modify once we will get the test PCB.
The second thing was to add semaphores to protect the variable shared between our threads on both the ESP and the STM. I also create a new thread that will be used to display the image or the animation we receive from the ESP. So far it only prints on the console the value of each bytes but having it already created allowed me to add the semaphores on the image so that when we will be trying to display images with the coils we will simply have to deal with the coils.… Read more
Since Friday, I’ve been working on DShot generation with Xavier. As explained in his last post , we wanted to use only an ESP32 on the bottom PCB.
First try of DShot with an ESP32
So last Friday we tried generating DShot with an ESP32 DevkitC and starting our motor with it.
After familiarising ourselves with the ESP API reference, we managed to generate a DShot signal on the SPI bus of the ESP32 using DMA. The idea is to send a DShot bit as an 8-bit SPI frame with the first 3 bits high to send a 0 and the 6 first bits high to send a 1, as explained in this post.… Read more
To do so we had to make a choice: at which point will we encode the data in regard of the communication protocol between ESP and STM. As a remainder, to be able to differentiate data from commands, the bytes that will contain data will always start with a 1 and then code the state of 7 marbles.… 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
Recently Alexis took the design decision to drop the IrDA idea (see this post) and to instead use an additional ESP32 to communicate between the rotating main board and the bottom PCB (which is in charge of controlling the motor).
So now the bottom PCB has an ESP32 for the purpose of receiving speed instructions from the main board over Wifi.
Yesterday, I wondered whether we could actually drop the STM32 processor on the bottom PCB and let the ESP32’s CPUs handle everything. We decided that the question was worth investigating, as there really isn’t that much to do on the bottom PCB.… Read more