how fast, what peripherals STM32 do I need for my project - Page 1
Forum section: electronics / general

author: minion
author_rank: Contributor
timestamp: May 02, 2020, 02:18:17 pm
content: Hello guys,I am working on a project, where I will use STM32 mcu. It will be acquiring data from sensors and write it to the SD card.there will be 4 16 bit accelerometers LIS3DSH, connected via SPI.From all accelerometers, values for x, y and z axes will be read. (probably, maybe only two values, will see)I will also read two analog sensors via ADC.All of this data will be read at400Hzand will be written to SD card via SDIO interface.I was thinking about interrupt-driven data transfer, the accelerometer would trigger an interrupt when data is ready, Interrupt handler would set up a flag and mcu would service it when it has time.The thing is, I don't, know complex this 400hz acquisition of data is for the mcu. Is this a piece of cake for average STM32 or do I need more powerful chip? Would DMA be required in this case? Would I nead each accelerometer on seperate SPI line or not? Would I need 4 bit SDIO or would 1 bit work fine?So far, I created a PCB for accelerometer and connect one to nucleo development board and reading data with the interrupt is working fine. I am now working on the main PCB, and don't know what mcu to pick. It is a "one off" project, so the cost of the mcu is not that important.What do you think?Thank you.

author: Siwastaja
author_rank: Super Contributor
timestamp: May 02, 2020, 05:00:19 pm
content: Piece of cake.DMA highly recommended, but not necessary at such low data rates if any reason preventing DMA use arises.

author: I wanted a rude username
author_rank: Frequent Contributor
timestamp: May 02, 2020, 10:25:03 pm
content: As Siwastaja said, the data rate is easy for an STM32 to handle.Some of the other questions might be more difficult, like:Four identical accelerometers would presumably not all be on the same PCB, so would they be too far away to comfortably use one SPI bus?Which SD card filesystems do you want to support, and how much flash/RAM will those drivers require?Should you use the ubiquitous STM32F103 and benefit from all the publicly available code, or try a larger chip with DMA and quad SPI?Will you use FreeRTOS or similar to make scheduling simpler, or do you want to write your own scheduler?Do you anticipate any future requirements that would necessitate a larger chip?In some ways the real question is: how many new things do you want to learn on one project?

author: Siwastaja
author_rank: Super Contributor
timestamp: May 03, 2020, 09:00:20 am
content: I did 18 IMUs (basically six integrated accelerometers+gyros+compasses, three chip selects per IC) on STM32H7 using three SPI peripherals and six chip select signals, so that one chip select simultaneously selects three devices out of 18, reading the SPIs in parallel. The project was open source so I can share the code:https://github.com/siwastaja/robotboard2-fw/blob/master/imu.cSampling the gyros and accelerometers at 1000Hz, interrupt-driven control with DMA, collecting 4..7 16-bit data packets inside the IMU FIFOs before burst readout, and I think the whole interrupt-based control took maybe some 2-3% CPU time on Cortex M7 @ 400MHz, IIRC.If your STM32 MCU happens to have 4 SPIs and you are sure you won't need them for anything else, I'd just give each IMU their own SPI.Note that the nSS hardware control on the STM32 sucks beyond belief so never count on being able to use it, even in trivial cases. It's best to allocate enough CPU resources to be able to wiggle nCS on software with the timing required, and think about this beforehand. In your case, this shouldn't be a problem, though. If you are very lucky with the particular SPI implementation of the partiular STM32 (they are all different), AND the SPI device you are using, you may be able to configure the SPI&DMA to free-run automatically with zero software intervention after the init, and just read out latest data from memory (a struct {x, y, z}, basically) very nicely. But don't count on this.