Integrating CMSIS-DSP libraries in a STM32 project

[JvdV]

I had been using the instructions gleaned from https://github.com/YetAnotherElectronicsChannel/STM32_CMSIS_DSP for how to use prebuilt CMSIS library for STM32F407 Discovery board.

Then I noticed https://community.st.com/t5/stm32-mcus/how-to-integrate-cmsis-dsp-libraries-on-a-stm32-project/tac-p/714554 so I wanted to update my project to use the new way to access CMSIS DSP code, so that my students will not be using an outdated method.

One thing I found onerous about the new method was having to go through every folder of code to remove or comment out <foldername>.c and <foldername>F16.c just to get the code to compile with multiple definitions complaints.

Once everything was compiling, I found that my original code didn't work any more. I had been using a 101 coefficient FIR filter on 1024 samples in each half of a DMA block. When I reduced to an 81 coefficient FIR filter, my project worked fine again. This suggests to me that the prebuilt library code was faster.

Another note: I am working in Debug mode in STM32CubeIDE. When I set the -Ofast flag, nothing about my code worked any more, not even in talk-through mode.

At KDJEM.1's suggestion, I am posting here, with my project attached, in case anyone wants to delve deeper. ADC input expected between PA1 and GND. Output from headphone jack.

[BarryWhit]

Debugging this requires so much upfront prep, I don't think you'll have much luck finding volunteers to help you.

What I can suggest is that you use a disassembler to compare the generated code for your DSP kernel function with the new and old versions. That might give you a hint as to what's going wrong.

If the version migration involves switching from precompiled libs to compiling the actual code (I haven't dug into it, but I got that impression reading the thread), there's obviously the question of compilation flags, optimization level, and which compiler (both flavor and version) was used. AFAIK, ARM has their own version of clang, while the STM32 toolchain is based on GCC. That could account for some differences (or not). 

In general, libraries that see intensive optimization for performance by the vendor can be very sensitive and just-so about how they are compiled.

If you're doing all this in a teaching context, I strongly recommend you reconsider. Having something that works out of the box far outweighs any seeming benefits of using the latest version. Is there any tangible pedagogical benefit to using the newest version of CMSIS-DSP instead of whatever version that ST ships as part of the MCU firmware package for the chip the students will be working with? Is it worth spending so much time (yours and theirs) to put together a dev environment incompatible with any example project or tutorial they'll find online? Your students should be given every opportunity to focus on the concepts and on experimentation through fast-iteration, instead of spinning their wheels fighting compilation errors. And *you* don't want to waste the first month of the semester playing whack-a-mole with strange compilation issues on their BYOD laptops. 

I also have a sharp thing or two to say about the state of your tax returns and your marital communication patterns, but I'll stop here. For now. ;)

[JvdV]

I'm using the version of CMSIS DSP that ships with the firmware. With this version my filters need to be shorter than when I used the arm_cortexM4lf_math library.

I'm not looking for debugging support. Shorter filters are just fine. KDJEM.1's reply made me think sharing my experience might potentially be useful to others with tax and marriage problems.

[BarryWhit · Accepted solution]

:)

I was fooled by

> I had a project working with the CMSIS 5.8.0 but wanted to update it to use CMSIS 5.9.0. 

and

>  I wanted to update my project to use the new way to access CMSIS DSP code

My apologies if I misunderstood, and best of luck with your class.