How to use CMSIS-DSP now that there are no precompiled libs in the firmware packs

[theRat]

I am using STM32CubeIDE 1.13.0 with the latest firmware packs targeting a STM32H563 and need to include the CMSIS-DSP library.
All of the forum posts/youtube videos/howto's etc say to copy a precompiled library file from the firmware repository to your project and then reference it.  The problem is that the current firmware repositories no longer contain pre-compiled libraries, only source code.  So can someone provide an updated set of instructions describing how to use the DSP code.

Cheers
Simon

[Robmar]

I seem to have the same issue, nothing links yet the CMSIS includes are in the settings:
Settings/Includes
../Middlewares/Third_Party/ARM_CMSIS/CMSIS/DSP/Include/
Error:
../Middlewares/Third_Party/ARM_CMSIS/CMSIS/DSP/Source/TransformFunctions/TransformFunctionsF16.c:29:10: fatal error: arm_cfft_f16.c: No such file or directory
29 | #include "arm_cfft_f16.c"

[Tesla DeLorean]

Back in the day we'd just use batch files, and the tools, and simply make the libraries we wanted..

One of the benefits of the library being you could throw the kitchen sink in there and let the linker resolve the pieces it did and didn't want to take, and do the dead-code elimination. I suppose the current issue is there are now so many MCU and build options that aligning the library with the project so the ABI bind properly is going to result in two dozen precompiled libraries.

Perhaps you can drop enough of the library source files into a sub-fork of the project until you get closure?

#57Varieties 

[Robmar]

Isn't that like telling someone with a problem in the car's ECU (electronic ignition) that it was easier back in the day when we had carburettors? 

The whole point of technology is increasing leverage, we use C++ over C because it allows more structured and faster development, we use CubeIDE MX rather than coding each MCU´s varied internal registers by hand... the idea is to automate to be more productive, not to be able to boast that we're a "hard metal" programmer who knows the bits in every damned MCU´s DMA or UART register.
The objective here is to increase productivity, create ever more sophisticated machines, not go back to the horse.
I designed my first chip in 1982, assisted Motorola in getting their MC1378 video processor working, Intel their 82786 GPU working... their teams could build those chips, but no single engineer had a clear view how all the chip worked.
Focus, discipline and a lot of long hours, but today staff have gone soft IMHO, and I think that STM will underperform unless they get focused.  Lets face in, the IDE is a sloppy app, lots of hacks and bugs, someone needs to call it IMO.

[theRat]

After a bit more investigation it actually just looks like ST have forgotten to include the libraries is the relatively new H5 firmware (the first revision was March 2023). Hopefully they fix it soon as I desperately need to use the DSP in a project I am working on.

[Foued_KH]

Hello @theRat , 

Thank you for bringing this to our attention.

Internal ticket number: 158545(This is an internal tracking number and is not accessible or usable by customers). 

Foued

[Simon_63893]

@Foued_KH thanks so much for the response. In trying to get someone at ST's attention I also created a github issue against the firmware.
https://github.com/STMicroelectronics/STM32CubeH5/issues/2
Just letting you know to help avoid any duplicate effort.

Cheers
Simon

[Foued_KH]

Hello all,
I will get back to you as soon as the request is analyzed.

Foued

[diego-z.esse-ti]

Hi all,

   any advances on this topic?

Diego

[CKugl.1]

I've gone through this process a few times before and it's always a huge hassle. Here's how I got it done today:

1. mkdir CMSIS-DSP
2. cd CMSIS-DSP
3. git clone [e-mail]:ARM-software/CMSIS-DSP.git
4. git clone [e-mail]:ARM-software/CMSIS_6.git
5. Create a CMakeLists.txt like the following:

 

cmake_minimum_required(VERSION 3.16)
set(CMAKE_TOOLCHAIN_FILE ${CMAKE_CURRENT_SOURCE_DIR}/toolchain.cmake)

set(HOME $ENV{HOME})
set(CMSISDSP ${CMAKE_CURRENT_SOURCE_DIR}/CMSIS-DSP)
set(CMSISCORE ${CMAKE_CURRENT_SOURCE_DIR}/CMSIS_6/CMSIS/Core)

add_compile_options(
 -mcpu=cortex-m4
 -std=gnu11
 -ffunction-sections
 -fdata-sections
 #--specs=nano.specs
 -mfpu=fpv4-sp-d16
 -mfloat-abi=hard
 -mthumb
 
 -Wsign-compare
 -Wdouble-promotion
 -Ofast -ffast-math
 -DNDEBUG
 -Wall -Wextra -Werror
 -fshort-enums 
 #-fshort-wchar
 )
add_link_options(
 -mfloat-abi=hard 
 -mcpu=cortex-m4
 -Wl,--gc-sections
 -static
 -mfpu=fpv4-sp-d16
 -mthumb
 )
## Define the project
project (cmsis-dsp)

add_subdirectory(${CMSISDSP}/Source bin_dsp)

 

(You will probably have to adjust some options for your particular STM32 chip. Look in your project's Properties / C/C++ Build Settings / MCU GCC Compiler / All options and MCU G++ Linker / All options to see what STM32CubeIDE is using.)

• Create a toolchain.cmake file like the following:

 

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_CROSSCOMPILING 1)
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)
set(CMAKE_ASM_COMPILER arm-none-eabi-gcc)
set(CMAKE_OBJCOPY arm-none-eabi-objcopy)
set(CMAKE_SIZE_UTIL arm-none-eabi-size)
set(CMAKE_C_GDB arm-none-eabi-gdb-py)
set(CMAKE_AR arm-none-eabi-gcc-ar)
set(CMAKE_RANLIB arm-none-eabi-gcc-ranlib)

set(CMAKE_EXE_LINKER_FLAGS "--specs=nosys.specs" CACHE INTERNAL "")

# This should be safe to set for a bare-metal cross-compiler
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

 

• mkdir build
• cd build
• cmake ..
• make -j4

This should produce a libCMSISDSP.a file in CMSIS-DSP/build/bin_dsp.

Now, in STM32CubeIDE, you can

1. Go to your project's Properties / C/C++ Build Settings / MCU G++ Linker / Libraries
2. Under Libraries (-l), add CMSISDSP
3. Under Library Search Path (-L), add the full path to the directory containing libCMSISDSP.a
4. Go to your project's Properties / C/C++ Build Settings / MCU GCC Compiler / Include paths and add the full path to CMSIS-DSP/CMSIS-DSP/Include/

 

[DiegoSF]

Thanks a lot CKugl.1 . Your answer made my day :)

 

I provide below my feedback on this matter, in case it can help any one out there in a similar situation:

 

I come from the STM32F4 family and have been using CMSIS-DSP precompiled libraries for STM32F4 family for a while now.

 

Recently I upgraded to the new STM32H5 family, for which no precompiled CMSIS-DSP libraries are availalble. After some (or rather a lot of) search online and following the official instructions of CMSIS-DSP github I managed to add the source files to the project and compile the libraries from source within STM32CubeIDE. I followed my own steps, but they were rather similar to the ones detailed in this ST post by the ST team .

 

However, after testing the libraries for a while I observed a really strange behaviour in some of the functions of the library, mostly some functions related to FFT transformations, when compiling the project  with the Optimization option for speed , as this was the recommended option instructed in CMSIS-DSP github:

 

-Ofast

 

Indeed, with this option I had a gain in computation speed of approximately 60%, but the results of FFT operations , multiplications of complex vectors, etc. were just not right!!

I was then trying to find a way to precompile the CMSIS-DSP libraries externally and ended up in your reply CKugl.1 .

 

For me this is definately the way to go and should be the recommended method for integrating this libraries into the STM32 MCUs. Now I can have the CMSIS-DSP libraries compiled for speed optimization externally and leave the project with Optimization option "None". So now the code is working accurate as a clock and I am also saving processing time. So thanks a lot for this!

 

Cheers,

Diego