In our previous post, Vlaya and I said that when a full rotation completion triggers an interrupt simultaneously with a flash interrupt, the order in which the HAL API IRQ Handler checks and handles each source of the interruption (both share the same IRQ line to the processor, and they set flags that the IRQ Handler must inspect to determine what happened) made it so that the rotation was handled first, delaying the flash handling.
To solve this, we decided to check the flags for the flash directly in the rotation callback, and trigger the flash before handling the rotation completion if they were set.… Read more
On Thursday and Friday, I continue to work on the H-bridge code for the test PCB and finally find a way to implement some timers that should stop the current in the coil.
I also have to go to Télécom to cut another box for testing so that we can even work with the closing of our school. However, we do not have the cable and a battery, so even if our code may work, we cannot make our tests. We hope we could take it at school this week.
Now, I will merge my code with Ilan and Zennedine and I will try to implement a watchdog too that will halt the coil even in debug mode.
Yesterday the latency and jitter of the SPI “FLASH” frames was a little high: around 80µs for the jitter
We had originally planned to solve this by bypassing the interrupts with a DMA request, but sadly this turned out to be unfeasible.
Investigating ways to reduce the interruption jitter revealed two main factors:
The interrupt priority was too low
A scheduled flash and a capture at the same time would cause the flash to be handled after the capture event.
Fixing this reduced the jitter from 80µs to 2.5µs
Yesterday Vlaya and I ended our post with a plan to use a DMA request line (triggered by a comparison match on our Timer channel) to send the “FLASH” SPI frame instead of doing it by software in an interrupt.… Read more
I’ve Come to a Reliable Conclusion upon working on CRC yesterday. Don’t try to understand what’s going on. Many walked this path before me, and yet I couldn’t look away at the promised cognitive pleasure of understanding it. In the end, I was denied this pleasure and here I am, left in frustration.
Well I might be a little bit exaggerating, but I’m sure that I’m miles away from having a grasp solid enough on CRCs to implement my own. For those who would want to do so though, this article from Barr’s group seems to stand as a reference, or at least a reliable entry point on the subject.… Read more
Since our last post on Monday, Vlaya and I have been writing code to trigger flashes when the Phyllo is at precise angular positions.
Flashing via SPI
As mentioned here, to flash the LEDs we need to send a SPI frame “FLASH” from the main board to all the led-driving PCBs signaling them to turn their LEDs on right now and for how long.
Checking the timings
On top of sending a SPI frame, we also set the Timer channel we use to trigger the flashes in output mode “Toggle”. Using a Saleae Logic analyzer to monitor all these outputs allows us to export the precise timings of both the moment the Timer channel is toggled and the moment the SPI frame is sent.… Read more
Today, Sibille and I tested the common reference time sharing between Phyllos. After coding the whole part, it worked pretty well and we managed to communicate with three Phyllos and the main_stm almost on our first try.
What was just a bit more challenging was when we tried to make the current time master (see yesterday’s post) disappear so that a new one could be reelected.
The tests’ main points
We needed to make sure that we could propagate the time tops from the master chosen among the bottom PCBs, through the main PCB and up until the main STM32.… Read more
After spending most of my time finalizing PCBs, I got to work on the embedded software and its communication with the control software. We chose to take advantage of the embedded linux OS and use ssh.
We found the “mkfifo” command that allows a program to read a fifo to which we can write to through ssh using a command such as this : ssh[user]@[machine] ‘echo “[text]” > [path_to_fifo]’.
This puts text in a fifo and it is erased when read. we can therefore send commands from the control app to the embedded software using this method. A thread on the embedded linux reads the fifo and waits for a command to be written.… Read more
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
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