I’d like to make an attempt at implementing a FFT pitch shift effect (as opposed to the SOLA implementation used in the current DaisySP library).
I came across this FFT pitch shifter implementation from Zynaptiq that I think could work on Daisy if I could use more the more efficient FFT functions available via arm_math.h (i.e. arm_cfft_radix4_f32()) to adapt it.
Is there any ETA on when the CMSIS libarary will be implemented for Daisy? It seems like the idea has been reviewed to some extent - as the current iteration of the pitchshifter in DaisySP includes arm_math.h, but doesn’t seem to compile if I force it to use arm_sin_f32() - I just get the “arm_math.h” is “undefined” error.
It also looks like libdaisy includes CMSIS and arm_math.h in the driver path:
It’s just not part of the current build. Is this something that’s on the roadmap for Daisy in the near future?
But it’s source is already included in libDaisy. They probably haven’t added those files to C_SRC variable, so it doesn’t get built. But you should be able to solve this in your project.
Also, CMSIS based FFT was usable on STM32F4 for running FFT and RFFT on a stereo channel. I’d expect it to manage even 4 channels in Daisy.
Thanks for the reply, antisvin!
I initially thought it would be just as easy as including:
into the Make files for libDaisy and libDaisy core with the #define variable for cortex-m7 MCU (“ARM_MATH_CM7”) - but after a lot of tinkering - it seems that there is something I’m missing.
I can rebuild the libraries without errors and I even get it to stop throwing the “arm_math.h” is “undefined” error…but in it’s place I get “undefined reference to ‘arm_sin_f32’” (or whichever arm_math.h function I use).
Has anyone successfully rebuilt the libraries including the CMSIS DSP headers and gotten something to successfully compile using one of the arm_math.h functions? If so, can you point me to where I may have gone wrong?
It seems that I’ve found a work-around in the meantime.
I stumbled on this stack overflow question and while the poster’s specific issue is about a
stm32f4 device, his issue is the same.
The proposed workaround is to grab the applicable *.c source files from:
and include them in the project directory and the Make file like:
CPP_SOURCES = ex_pitchshifter.cpp
C_SOURCES = arm_sin_f32.c arm_common_tables.c
I am able to get the pitchshifter example to compile this way and it runs on the hardware using using the arm_math.h functions exactly as it runs without them.
I imagine there is a better way to define where all of the CMSIS source files are, so I don’t have to include them one-by-one, but the make file already includes:
# Library Locations
LIBDAISY_DIR ?= ../../../libdaisy
This is not the answer.
So, I’m guessing that:
CMSIS_DIR ?= ../../../libDaisy/Drivers/CMSIS/DSP/Source/
Isn’t the answer (though, I might give this a go now - just to check).
Long term, would love to just be able to use the functions without the workaround - let me know if anyone has a better solution.
Not sure if this is still relevant for anyone, but I think I’ve got it working in my project (trig functions working at least) by adding
C_SOURCES = $(wildcard ../../libDaisy/Drivers/CMSIS/DSP/Source/*/*.c)
to the Makefile. Of course replacing the
../../ with the path to libDaisy.
Then I just
#include "arm_math.h" as usual and everything is working for me
I’ve been trying to get FFTS working as well. Using the additions to the makefile that @fredyeah suggested, it’s linking the .c files. However, it seems one of the files required for arm_rfft_fast_f32 is arm_bitreversal2.S.
Since this is an assembly file, the makefile doesn’t seem to have a rule for passing it to the compiler. I’ve tried several things, but I can’t seem to get it to work. Does anyone know how to set up the makefile to get this to work? This is the first time I’ve ever used makefiles and I’m finding it a bit confusing.
Or if anyone knows of any open source projects using FFTs on the Daisy, that would help immensely. I’ve not been able to find any code using FFTs to use as a model.
Thanks for the help.
Google ‘make implicit rules’.
Makefiles can be confusing, they are super important.