[LASMO] First try at FreeRTOS

I didn’t have much time last week to work on the project due to the Athens week. I had a wonderful time in Prague but I wasn’t able to work on the project.

On these last days I’ve been focusing on trying to make FreeRTOS work on a STM32F4xx development card, i. e. making the official demo for this board work. Sadly, the official demo is actually designed to be compiled with the IAR compiler, and we’d rather use GCC for our project instead  of a trial version of some non-free compiler. I’ve found a demo using GCC and a makefile on the Internet, but for some reason, once compiled using GDB will work even if the GDB server isn’t launched, which makes me think the Makefile already opens one (which is not good because it is not launched on our board). I’ll try for the next time to have a  more deeply understanding of how a FreeRTOS program works, and I’ll try to fix that issue.

[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] Git workflow and beginning with FreeRTOS

In 2 days, we defined the architecture of our project and most notably, we establish that we’ll be using 3 microcontrollers: a main controller from the STM32F7 family, a smaller one from the STM32F3xx family, whose main purpose will be to switch off the laser when it doesn’t move to comply with security norms, and an ESP32 for the network.

It seemed then logical to try and begin learning to use FreeRTOS, as we were used to work with ChibiOS in practical courses. That’s why I copied a demo for STM32F4xx cards, which we happen to have used during the practical works. In the next week I’ll try to learn how the kernel works in order to set up a SPI interface and maybe, if I have the time, a code to access an SD card, using the STM32F4xx. The code will be eventually reused on our final STM32F7 if functional.

We chose to use the “GitHub workflow” because it’s simpler. The “Merge Request” feature of GitLab will help us apply this flow well.