[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.