Finally, after a few posts, and a lot of work, our testing device (ie our dev board and our ESP) can be a complete sender. As a reminder at first our device will receive images from our server but we also wanted it to be able to send data to another device. Since my last post here are the issue I faced and the solutions I found.
The first issue was to send the data to the other device once we got its topic. To ensure we send the correct amount of byte, I wrote a python script that played the role of our second device.… Read more
On Tuesday, I realize that I need to make two tasks for the sensors. One that will enable the good sensor on the multiplexer, and another that will enable the sensor once the first one is finished. I would like to implement a semaphore, but the FreeRTOS manual suggest that I use a task notification instead of a semaphore. They use less RAM, but I still do not understand well how it works after a day at looking and testing it. I’ll sleep on it and hope that I will understand better how it works.
I also configure an ESP32 as an I2C slave device in order to have an ACK when I communicate with the STM because I have no other device that can do this job.
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, Sibille and I ran the final tests for the led-driving PCBs software using Vlaya’s SPI generation code. We wanted to make sure that if the main board sends an entire SPI frame (24 LED configuration instructions and a “TOP” command), the CPU managed to configure all the LEDs and turn them on. It does 🙂
On the nucleo devboard, we can observe 20 out of 24 timers. Have a look at the outputs we measured with the logic analyser :
Today, Xavier and I continued to work on the software for the LED-driving processors. We have obtained fairly satisfying results 🙂
First, we managed to fix the bug explained here for TIM1.
We had just forgot to set one bit (MOE bit) in the configuration : TIM1 is an “advanced timer” and this bit is mandatory to enable the outputs. As for TIM9, it is actually not available on the dev board we use. But it is a “general purpose timer”, so we won’t hopefully have any trouble with it.
Then, with the help of Vlaya, we use her SPI generation code to test our SPI reception.… Read more
This morning, Vlaya, Xavier and I carefully made a paper template for where to bore holes in the PCV disc to attach the Phyllo shell. Vlaya had previously finished placing threaded inserts on a 3D-printed sculpture. We then went to the school mechanic, Mr Croullebois, to bore the holes and attach the sculpture.
The threaded inserts we used have a screw thread diameter of 3.5, which it turns out is not standard in France. Thankfully, the school go-to guy for electronics, Karim Ben-Kalaia, who by luck was visiting Mr Croullebois at that time, offered to take a look in his own workshop and promptly returned with a handful of suitable screws 🙂
Without further ado, here’s what it look like :
Just a quick note : the motor currently in the fixed base has been damaged during our tests and makes a pretty annoying creaking noise while turning.… Read more
Since yesterday, Sibille and I have worked on reducing the voltage threshold for motor acceleration we’ve mentioned here.
After a meeting with Alexis yesterday and with the school mechanic this morning, we have two main leads.
Reflashing BLHeli ESC
The first lead is to take a look and the programmable parameters of the ESC. We previously hadn’t given this much thought, but ESCs usually allow for the tweaking of several parameters in how they control the motor. Usually there’s a way to access these settings by playing with the PWM throttle input and using the feedback bips to identify various menus.… Read more
Yesterday, Xavier and I went through the STM32F207 documentation to finish preparing the code for the LED-driving processors. As we explained on Thursday, we would like to go bare-metal on this one.
Reminder of the SPI protocol
As Vlaya already explained, the LED configurations are 16-bits frames (8 address bits and 8 data bits) send by the main board on a SPI bus. By looking at the firsts bits of the frame, the processor determines whether the following 8 bits configuration concerns it (configuration for one of its LEDs or “TOP” to turn on the LEDs) or not.
If so, it retrieves the following 8 bits on the SPI bus and uses it to configure one of its LEDs or start the flash.
So far, the ESP32 was able to receive images from the server through MQTT and transmit them to the STM32. It also could transmit animations but only if the animation was directly hardcoded. So what we wanted to do was to be able to transmit animations through MQTT just like images and also to find a way to chose if we want to receive an animation or an image.
First things first : the server side
The first step we did to go in this direction was to find a way to transmit animations. We chose that, at least for now, the server will publish periodically on two topics.… Read more
Today with Marc we made some diagrams to plan the software architecture of the main board and bottom PCB:
We also started writing all the .h prototypes so that anyone in our group can start working on a new module and know exactly which functions to code, and which functions they can use from other modules.