Advice on STM32 MCU and Baremetal/FreeRTOS selection

[KhangRtR]

Dear Forum,

I am preparing a hardware prototype for a visual inertial odometry project that highly requires realtime-ness.

The planned system would comprise an MCU for gathering data (with some pre-processing such as FFT, Kalman Filter, ...) from various sensors such as IMU, barometer, magnetometer, .. then transferring to a Linux based platform (Raspberry Pi 4/5 for  example) running ROS2. And it looks like that this would be more or less similar to certain open-source flight controllers (for drones, rockets, ...) making use of STM32F4 or STM32F7/H7 families and I would opt for the H7.

In terms of firmware for the MCU side, I would use the microros middleware for timestamp synchronization and data publishing via ROS2 topics.

However, handling multiple tasks such as data acquisition from various sensors and micro-ros communication with host ROS2 platform but still guaranteeing the realtime-ness (low latency in terms of data timestamping) would be a challenge in this project. Therefore, I am in a dilemma of selecting btw an RTOS (FreeRTOS for being precise) or making use of an MCU having multicore (the STM32H745/STM32H755) with some sort of  inter-processor communication techniques presented in the AN5617. 

Could you help to share your opinion/advice, please ?

Thanks in advance and best regards,

Khang.

[Ozone]

> I am preparing a hardware prototype for a visual inertial odometry project that highly requires realtime-ness.

Perhaps two more details you could add.
First, the power supply. Would it run from a battery, and current consumption be an issue ?

Second, specifics about "realtime". What sampling frequencies for the named sensors ?
For 1kHz or below, you would most probably don't need a F7/H7. I used F3 and F4 controllers (F303 and F407, to be exact) for realtime FFT (float) of audio signals with 44.1kHz and a blocksize of 2048, and had sufficent time left for other operations (data transfer or graphics).

And since most sensor values are integer anyway, you don't really need float data. Integer algorithms are faster in this regard. You can do the "heavy processing" on the host side, in double precision.

[KhangRtR]

Hi @Ozone,

Thanks for your prompt feedback.

---

First, the power supply. Would it run from a battery, and current consumption be an issue ?

We would use the battery but this would not be a problem as we also use a Linux board that consumes more power and we still have enough autonomy.

---

Second, specifics about "realtime". What sampling frequencies for the named sensors ?

The fastest sampling frequency would be the case of the IMU (400Hz), barometer and magnetometer could be lower (200Hz). The IMU would also trigger the cameras at its frequency / 10 (i.e. 40Hz) via some GPIOs.

---

For 1kHz or below, you would most probably don't need a F7/H7. I used F3 and F4 controllers (F303 and F407, to be exact) for realtime FFT (float) of audio signals with 44.1kHz and a blocksize of 2048, and had sufficent time left for other operations (data transfer or graphics).
And since most sensor values are integer anyway, you don't really need float data. Integer algorithms are faster in this regard. You can do the "heavy processing" on the host side, in double precision.

---

As I am novice to DSP, I will follow your advice based on the sampling frequencies of the sensors. Also, we could off-load the heavy-processing to the Linux host side. And IMU data is in float format (from its library).

One more thing, we would need Ethernet interface for the UDP transport layer of micro-ros which is reported better latency than the serial over (CDC) USB here : https://docs.vulcanexus.org/en/iron/rst/microros_documentation/benchmarking/benchmarking.html#latency.

I also though that an F4 would be sufficient. However, I am hesitating btw baremetal+multicores vs FreeRTOS for the firmware organization.

Best Regards,

Khang

[Ozone]

> I also though that an F4 would be sufficient. However, I am hesitating btw baremetal+multicores vs FreeRTOS for the firmware organization.

I don't remember all exact details, but a F4 discovery (STM32F407) did a complex float FFT of size 2048 in about 5ms, using ARMs "DSP package" code (supplied by ST) and optimisation for speed.
For smaller block sizes, you get well below 1000us. And unless you want to look at certain specific spectral components, you could go relaitvely coarse for a small display.
The only important point, you need to take "lazy stacking" into account. Task- and interrupt-safe float code increases the stack frame.

I think there should not be a problem with FreeRTOS in general. Professionally I'm working with ECUs using FreeRTOS, SafeRTOS and OSEK/VDX, a 10ms base cycle, and sequential tasks. In your case, you could probably use longer base cycles. You probably gather most of the sensor data per DMA or interrupt in larger buffers, and want to read/process those buffers at least once each cycle. Which is were memory (buffer) sizes come into play.