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