Timing the flashes, the end for now

A false issue

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

Ready? Steady? Wait…

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.

Timing the flashes, Act 3

TL;DR

  • 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

Unfeasible DMA

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

CRC must stand for Crazy Real Confusion

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

Timing the flashes, Act 2

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

How to play with Kronos

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

Control Freak

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

Driving me crazy

Romain and I spent the last few days trying to get the WiFi dongle to work with the SOM.

The little fella

However, several issues had to be overcome in order to succeed in doing this.

Overcurrent detection

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 we can send

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

Task notify: Hello goodbye

On Wednesday, I spent some times implementing task notify on the sensor task, until implementing it on the h-bridge task. Then, I realize that it creates many memory errors and was not really useful since the thread should not call the function that change the multiplexer until the I2C communication was finished.

I also find the way to put some values in the esp32 that I used for the test as an I2C slave, and realized that it works with only 7 bits adresses whitout a read/write bit at the beginning, so I changed its adress and it correctely acknowledge to my communication.… Read more