[bouLED] Designing the main board

I’m currently designing the main board. First, I had to create a routing table for the STM32H743VIT6 using one Alexis made as a base. We’re only able to have 5 SPIs, a SD card in 1-bit mode and an UART. Programming and debugging will be done over SWD.

The next step is the power supply, using an LT1765-3.3 buck converter. Using the datasheet, I started choosing ratings for its peripheral components, but it’s getting late so I’ll finish that tomorrow. Next step: drawing the schematic.

[bouLED] SPI benchmarking, architecture and component choice

SPI benchmarking

In order to maximize the refresh rate, we’d like the SPIs we control the triangles with to be as parallel as possible, which is done using DMA. For each DMA controller, we can run one SPI in parallel.

I wanted to benchmark this, but I ran into problems using ChibiOS’ HAL on a STM32F7 with 6 SPIs. All my SPIs are used in transmit-only mode, but ChibiOS allocates two DMA streams per SPI: one for transmitting, and one for receiving, which is suboptimal when doing simplex communication. There were stream conflicts: one of the SPIs (SPI1 if I recall correctly) uses the same stream for transmitting as another SPI’s receiver stream. What’s more, ChibiOS’ HAL has no unidirectional SPIs, so I couldn’t fix that easily, but on the other hand ST’s HAL supports simplex mode.

In the end, we chose to ditch ChibiOS for FreeRTOS and ST’s HAL (generated using STM32CubeMX). So far, all SPIs work in blocking mode but it’s not parallel yet (i.e, it doesn’t use DMA). When that’s done, it will give us an idea of the refresh time (and hence of the refresh rate).

Architecture & component choice

We’ve calculated that this project needs a 30A power supply. We obtained this figure by checking one strip’s consumption in the lab and multiplying by 20, and adding 4A as a safety margin. In practice, it should suffice if we avoid making the LEDs too bright. The natural choice is a LiPo battery. A 10Ah 5S (5*3.7V=18.5V) with a 15C (15*10=150A !) maximum current discharge will do, it’d last around 20mn. However, it’s expensive: around 150 euros. The LEDs need 5V and the other components 3.3V, so a regulator is needed.

The 3D printed triangles are annoying: there’s wire everywhere, the precision requirements are very strict and they fall apart without scotch tape. To circumvent this, the triangles should be PCBs, but dumb PCBs: electrically, they shouldn’t be more than a APA102 LED strip and a connector. That’s way cleaner in my humble opinion, but that’s more work.

The main board, inside the icosahedron, will host the main MCU, an ESP32 for WiFi communication, and an AHRS array (Hichem is trying one, we’ll see if it’s good enough). The STM32H743ZI seems perfect for the task at hand: it’s really fast (400MHz), it has more than enough cache, 4 DMA controllers (which means up to 4 parallel SPIs !), a 2MB flash and a 1MB RAM. There’s also a STM32 Nucleo devboard using this MCU. Delivery is due tomorrow !

[LASMO] Started PCB design

This week, I start to draw the design of the PCB.
I start to add the main components of the PCB, and decide the exact references we need :

  • For the STM32F7, all references available on the ST website are suitable, so I choose the one that was already in the Xpedition PCB library, the STM32F767vit6
  • For the ESP32, Luc choose the ESP32-WROOM-32: it has an embedded Wi-Fi antenna, an RMII interface for the ethernet, and an SPI interface to communicate with the STM32F7
  • For the security microcontroller, I choose the STM32F103RE. This MCU has to integrate 5 ADCs, one GPIO and an SPI interface. So, a very small STM32 MCU is enough.
  • For the triple 8bits-DACs, I change the MAX512 to a MAX5105 because the MAX512 don’t integrate three equal DACs. Moreover, the MAX5105 has an asynchronous MUTE input, which is convenient for the stop of the LASERs by the security MCU

Then, I work on the Ethernet connection. I add a LAN8742A and an RJ45 connector to make the physical layer. I never made design PCB, so I spent a lot of time to find and understand the different components to add to the design.

After finishing the Ethernet design, I work on the MAX5105 connections. This part was easy to make, but I’m not sure about the direct connection (cf figure 1) between the DACs’ outputs and the inputs of LASER drivers. I don’t have the LASER documentation yet, so it’s confusing for me to know how correctly connect these two parts.

(figure 1) MAX5105 connections

This is the newest version of our main components implementation :

[LASMO] Main components architecture

The LASER and the scanner were chosen : a LASER RGB of 1W and a scanner with a speed of 30 Kpps. They came from laboutiquelaser.fr, a French website. We are waiting for the technician’s answer for the availability of the LASER and a real documentation of each component. 

The choice of these two components allow us to define the main architecture of the project :

Main components’ architecture

The main controller is a STM32F7 family. On this micro-controller we will :

  • Use two DAC of 12 bits to control the scanner
  • Use two ADC of 12 bits to get a stereo input line ( in order to synchronize the animation with a sound beat )
  • Communicate with a SD card 
  • Communicate with ESP32, STM32F3 and MAX512 with SPI protocol

The network controller is an ESP32. It will allow us to communicate with LASMO over Ethernet or Wi-Fi. It will integrate a HTTP server to provide us a web app in order to control LASMO.

The MAX512 is a triple 8 bits DAC. It will be able to control the LASER with 3 analog inputs (RGB). This information have to be confirmed, we don’t have yet the documentation of the LASER. In case the input is not analog, the MAX512 component will be removed.

The STM32F3 is a micro-controller whose solely role is to comply with security norms : indeed, the LASER can’t be turn on more than 25 ms on the same position. The security controller monitors the return position signal of the galvanometers and force the laser inputs signals to zero if the galvanometers don’t move enough.

[CyL3D] More architecturing

Since last week we’ve mainly done three things : defining formal specifications, upgrading the architecture, and start choosing components.

Formal specifications

We’ve created a spreadsheet that would compute some figures like the maximum power, the maximum bandwidth, the bandwidth per LED driver, etc. We can immediately see parameters effects by varying them.

We’ve chosen to use 1200 LEDs using a 4:3 format. This seems sufficient to get a nice result without creating unnecessary complexity.

We also wanted to check the maximal throughput because we think it’s our main bottleneck. Using 8 bits per color, and 25 revolutions per second we measured a total throughput of around 50 Mb/s. Again this seems reasonable since we can transmit that much data both through WiFi or SDIO.

Finally we needed to check how many drivers and multiplexers we should use. Using 16-LED drivers and 8-columns multiplexers, a block that is at the edge of the panel (thus we the higher update frequency) would have a maximal throughput of around 8 Mb/s. We saw several LED drivers made by TI which have at least 20 Mhz bandwidth (and approximately the same throughput).

With all this, we add our final setup : 40×30 LED pane, decomposed in 8×15 blocks each controlled by a LED driver and a column multiplexer.

Upgrading the architecture

We’ve also been thinking about the fixed part of the project. We needed a way to control the motor and the IR LED used to synchronize the system. We tried to think about the usage flow, and finally came up with this :

  • Push a button to turn the power on. This should power two BLE modules, one fixed and one mobile.
  • When selecting or streaming a file through the WiFi interface, the mobile BLE module would communicate with the fixed part to start IR emission and motor rotation.
  • When paused or stopped, the same process would happen to stop the motor.

It means that we’re going to have to design a (much simpler) circuit in the fixed part to control the motor and LED.

Choosing components

We’ve also started to choose components. In fact this is highly correlated to the architecture since we need to be aware of what’s existing to design the system.


In particular, I’ve been searching for a WiFi module. After some research, I found the ESP8266 and its ESP32 family successors. These are particularly know, and adpated for our usage, because:

  • The processor is dual-core, one core being dedicated to the IP stack, and the other being available for the user
  • The processing power is sufficient for most usage. We are not going to do much work apart from forwarding data to the FPGA.
  • It has 500 Ko of SDRAM and up to 16 Mo of external flash memory. This is clearly enough for our program and data.
  • It is SPI and SDIO capable.
  • It is cheap.
  • It supports WiFi with an UDP throughput of 30 Mo/s
  • It supports BLE
  • It has a huge fan community, lots of tutorials and programming guides.

For all these reasons, we are going to use two ESP32 module. One will be used in the mobile part to handle the WiFi interface. It will also communicate through BLE with the second module on the fixed part. This is the module that will drive both the IR LED and the motor.

Moreover, the ESP32 is supported by, and mostly used with FreeRTOS. This is a sufficient reason for choosing FreeRTOS as our main OS.


I’ve been digging into TI website to compare their LED panel drivers. I noticed that two of their drivers are suited for “large high frequency multiplexed panels”. Furthermore, TI even wrote a document aimed at explaining the whole process of using those two drivers to build a panel. Since this is pretty much what we’re doing, it looked like a good idea to use those.

Ambroise checked the differences with other drivers that were available and noticed that, although the bandwidth is lower, they provide lower rising/fall time and most importantly have buffers to store the whole frame.

As a result, we are going to use the TI TLC59582.