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

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

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

One ESP32 to rule them all

Today, Marc and I started to work on the common time reference shared between Phyllos. 

As you may recall, we need this common time reference to be able to play synchronized animations with several Phyllos. Here is a gif to visualize an example of synchronized animation :

Master election

As explained in this post, we know since a long time that it is possible to transmit precisely enough a time reference with UDP. But we still have to choose one ESP32 to be the master ESP32 and to enforce its time reference to all other ESP32, and by extension all other Phyllos.… Read more

UART, UART, UART (and shell)

As explained in this post, we have decided to use FreeRTOS on our main board. Last week, Sibille and Vlaya have successfully adapted the frame sending code for SPI buses. For The past few days, Sibille and I have wrestled with the UART communication code. 

Here is how the code evolved since my last post.

Shell implementation

At first, when I began coding the UART server, it was closely related to the shell (over WiFi). I also communicated with the ChibiOS shell on the other side of the UART. The next step of my reflexion was to realize that it wasn’t natural to have the shell on the STM32 rather than the ESP32 and I stopped using the ChibiOS shell. … Read more

Timing the flashes

Today Xavier and I worked on a way to flash the LEDs at given absolute angular positions, as discussed in this article

Over the last few days we’ve refined an idea to naturally flash the LEDs at a given absolute angle thanks to the STM32 Timers.

The Idea

To retain awareness of the angular position of the Phyllo, we have a position sensor (either a hall or an optical sensor, both are on the board) that triggers a rising edge once per rotation. We consider the position at which the sensor fires to be the absolute angular position zero. This gives us an absolute reference that we’ll use to keep the flashes from drifting in time.… Read more

A new angle on flash frequency

In a previous post, Vlaya and I showed how the flash frequency can lead to many nice effects.

A question of angles

After a long reflection, we realized that for many reasons the best way to describe the flashes is not by their frequency, but instead by the absolute angular position of the Phyllo when each flash occurs.

Therefore, each image description will contain the colors frames and a pre-computed absolute angle (which may be procedurally computed or included in a stored animation).

These absolute angular positions are not to be confused with the relative angular rotation of the motor between two consecutive flashes.… Read more

Motor control over Wifi

Yesterday, I used Marc’s UART server to connect the ESP32 to the Olimex E407 devboard which we use to test our bottom PCB code. 

After a few adjustments, it works and we are know able to turn on the motor and choose its speed by sending a speed target from a computer to the bottom ESP32, which transmit it to the dev board over UART, which translate it in DShot frames and transmit it to the ESC.

As the majority of the bottom PCB code is written and functional under ChibiOS, we will of course keep this OS for this PCB and use FreeRTOS only on the main board.… Read more

From ChibiOS to FreeRTOS

While Marc and Xavier are stuck in a tedious FH class, Vlaya and I have decided to work on the SD card. Our goal is to upload animations to the SD card (the same animations on each Phyllo). The Phyllos agree thanks to a discussion over Wifi on an animation identifiant and to start the animation at a chosen time (as you may remember, the Phyllos have a common time reference). Then each Phyllo will search the SD card for the desired animation and send it to the LEDs.

We started to read ChibiOS and STM32H7 documentation about SD card and SDC Driver, but soon, we discovered that on the last ChibiOS stable version (19.1.3)… Read more