Let’s test all the benches !

Good news today. I completed the testbench connecting the synchronizer and led band controller modules.

This global testbench allowed me to discover and fix new bugs, mainly in the synchonizer module. Everything seems to work as intended now.

The test consists in writing a random frame of data on the led band controller and checking if the simulated driver contains the proper data at the time it should be displayed.

I also tried to change the multiplexing groups, which is an important parameter we will have to set later, and everything still works. I only hope we won’t have too many surprises on the finished product.… Read more

Simulacra and Simulation

I’ve been working for a few days on a global testbench of the system. I am making progress while at the same time integrating the fixes and design changes we decided to make.

This is almost done. Simultaneouly, Romain tests the behaviour of our module on a DE1-SOC dev board, everything is looking good so far.

It’s good to see the synchonization music in action.

Sync me a song

The implementation of the synchronizer is done. The architecture did not change much from this post.

I did unit tests on the submodules of the synchronizer. However a question came to my mind when it comes to testing the global module. How to test such a module without basically reimplementing it in the testbench ?

For the moment I just took a look at the output and checked that it seemed correct. Here is a look at the little music it produces:

Turn timescale
128th of a turn timescale
One multiplexing group writing cycle
One bit for each LED writing cycle

Next, we will have to test if the sync and led band controller modules play nice with each other.

There’s some sync inside you, it’s hard to explain

The synchronizer module

As stated in my previous post as well as Salomé’s post, the synchronization module has to do some heavy lifting.

It must indeed control the timing of data sent on all led band controllers. Basically, we need two state machines: one for the function control, the other for the grayscale data. I started to implement the GS state machine today, but this will need extensive testing.

Furthermore, we need to generate the essential SCLK and GCLK signals (see the led driver description), this is done using two clock dividers. I implemented this module, but the division factors are still to be discussed.… Read more

Let that sync in

After a number of interrocations on the FPGA architecture, we are back to the drawing board.

Indeed, Alexis pointed out that our previous design created a lot of redundancy in the led band controllers. The computation of the current controlled leds, of the current controlled colors and even of the current written bit can be mutualized between each LED band.

That’s why from now on, our synchronization module will have more duties. It will generate :

  • the SCLK and LAT signals (see this post about the LED driver)
  • the current angle
  • the row, color and bit to be sent at any moment

But what does the led band controller do, then?… Read more

Figuring out the right WiFi protocol

Since thursday I’ve looked into how to implement the wifi communication we need between our phyllos (see Ruling the colony of Phyllos ).
We need a way for multiple Phyllos next together to broadcast data between themselves, and a way to communicate with the Phyllos from a smartphone or computer (for instance), and we will be using a ESP32 dev kit C integrated in our Phyllos.

Data exchange between Phyllos

The rate at which the phyllo need to exchange data doesn’t have to be very high at all: we just want to exchange small messages such as “Here is my ID: xxxx” , or “Start animation X at time T”.… Read more

Ruling the colony of Phyllos

Yesterday we mostly worked out the detail of how we’ll be detecting neighbouring Phyllos.

Without further ado, here it is :

Step 1 : Discovery and identifier attribution

The first step for the Phyllos is to establish collectively which other Phyllos are present. Each Phyllo must therefore broadcast its presence and be given an identifier. 

This step must be repeated regularly in case Phyllos are switched on/off. 

As described in this post, we plan to base the protocol on wifi broadcast: a Phyllo regularly broadcasts its IP over wifi to signal that it is still on. The others register this IP address in a local running Phyllos table.… Read more

A first look at the FPGA architecture

In order to synchronize the LEDs and create a persistence of vision image, we use a CycloneV SOC.

Here is a first idea of the architecture we might use :

The ARM processor fills a buffer with the next image to be displayed, that is then swapped with the second buffer. It can pull this image from the SD card, or from another source such as the text printing function we plan on adding.

The full buffer is then accessed by a Direct Memory Access (DMA) IP that then sends the relevant cylinder (32 * 128 pixels) to each LED band controller that is then stored in their memory.… Read more