arm_math.h and the FFT audio blocks

[DerekR]

I am currently writing/adding blocks to the audio library for DSP functions in communications work. Many of them use FFTs, and I note from the Keil website that the arm.h function used (arm_cfft_radix4_q15()) is now deprecated, and carries the warning: "Do not use this function. It has been superseded by arm_cfft_q15 and will be removed".

The new function arm_cfft_q15 is not in the arm_math.h in the Teensy distribution. A couple of questions:
1) Are there any plans to upgrade to the latest version? I note that the installed version is dated 2012.
2) Is there a problem if I download and install the latest version (except that i would have a non-standard development environment and my code would not be transferable)?

What's a boy to do?

Derek

ps - If it would be helpful, I'd be happy to install the latest and benchmark any performance change on the existing functions.

[WMXZ]

I am currently writing/adding blocks to the audio library for DSP functions in communications work. Many of them use FFTs, and I note from the Keil website that the arm.h function used (arm_cfft_radix4_q15()) is now deprecated, and carries the warning: "Do not use this function. It has been superseded by arm_cfft_q15 and will be removed".

The new function arm_cfft_q15 is not in the arm_math.h in the Teensy distribution. A couple of questions:
1) Are there any plans to upgrade to the latest version? I note that the installed version is dated 2012.
2) Is there a problem if I download and install the latest version (except that i would have a non-standard development environment and my code would not be transferable)?

What's a boy to do?

Derek

ps - If it would be helpful, I'd be happy to install the latest and benchmark any performance change on the existing functions.

It will continue to work.
Downloading the new CMSIS code will require some work as they provide a version that blows up the data space (all possible FFTs are prepared) and even Teensy 3.2 is space limited.
IMO, as long there is no bug in old CMSIS code (and I'm not aware of one) there is no need to replace a functioning piece of SW.
Also the new version is not executing faster (core components are the same)

[PaulStoffregen]

1) Are there any plans to upgrade to the latest version?

No, definitely not going to update to the latest arm math lib!

Well, not until there's a fix for the huge increase in memory usage. They added support for larger FFT sizes. But they didn't create separate lookup tables for the smaller FFTs. Using any FFT results in massive increase in program size.

Some time ago, I did initial work on porting the library to our toolchain and a makefile for rebuilding.

https://github.com/PaulStoffregen/arm_math

Eventually this may lead to updating the arm math library we use with Teensy, using customizations for things like the FFT lookup tables and build setting more closely matching how we compile the rest of the code. But it's still very experimental at this point, and my attention is currently on the K66 beta test. Updating the arm math stuff is pretty much at the very bottom of my priority list, which realistically means it may never happen.

[DerekR]

Thanks Paul, that is exactly where your efforts should be! I can't wait for the K66 release, as I need as much processing speed/power as I can grab, and I'll be one of the first to order/pre-order as soon as it is announced!

Yep, the latest is not always the greatest and bloat is common in the software industry. I can certainly work with the existing FFT code; I just wanted to make sure that I wouldn't have a major rewrite in the near future.

[chipaudette]

I just ran into the problem where I wanted N_FFT = 128, but the legacy CMSIS FFT routines only do 64 or 256 (or 1024). Dang it! The newer CMSIS will allow N=128, but the new CMSIS isn't supported by the Teensy Audio Library. Basically, the same problem as described in this tread.

There's another thread where they've made some progress on this issue by hacking a few things. Apparently, they've gotten the new CMSIS calls to work without exploding the program size. I haven't tried it myself, but I figured that I'd link it here, in case someone else stumbles upon this thread.

Making new CMSIS FFT work: https://forum.pjrc.com/threads/38325...l=1#post119797

And if you want to use the floating-point capabillities of the Teensy 3.5/3.6, you should see this refinement: https://forum.pjrc.com/threads/38325...l=1#post120177

Chip

[PaulStoffregen]

but the legacy CMSIS FFT routines only do 64 or 256 (or 1024). Dang it!

That's only true with the radix4 functions. The radix2 ones offer 16, 32, 64, 128, 256, 512, 1024, 2048 sizes. On Cortex-M4 for Q15, the raxid4 versions is slightly faster, which is the reason it was used with the audio library.

[chipaudette]

Ooh! N128 for F32 using radix2? Fingers-crossed!

(Not having to re-plumb for the new CMSIS library would really be nice!)

[DerekR]

Hi Everybody,
I've had to give up all things Teensy for the past few months while battling extreme fatigue post treatment for a serious illness. The good news is that we have found that most of the problem was actually an allergy to one of the drugs that was meant to help fatigue!!! Anyway, I hope now to be much more active on the forum again. I had many projects underway when I was forced to stop, and one of them was a complete Teensy FFT library with int16, int32 , and float, inverse and forward, complex and real, and standalone and audio board versions. It would also have complete radix-2 (32, 64, 128, 256, 512, 1024 (and longer if there is any interest) lengths. In addition the routines all have minimum length "twiddle" tables to keep the memory size to a minimum.
The code is derived from "cherry picking" the newer arm_math source code, and is based on a mixed-radix (4 and 2) approach with output bit-reversal. For the non radix-4 lengths I wrote code to perform the column zero operation before defaulting to the arm_math radix-4 approach for subsequent columns.
Where does the project stand? I have written and verified the complex, int16, forward FFT, standalone, length 32, 64, 128, 256, and 512 functions on both the Teensy 3.2 and 3.6. I have written MATLAB code to automatically generate the twiddle and bit-reversal tables, so extension to other lengths is easy. The routines are fast - I'll try to post the timing information later today. My next focus will on the matching int_16 IFFT routines (making sure IFFT(FFT(x)) = x).

From there I'm open to suggestions - perhaps audio board library forward and inverse complex functions with the missing lengths, particularly 128 (since I want this for some other projects (SDR related))... I don't yet have a 3.6 wired to an audio board, so I'll have to start with a 3.2.

If anybody is interested in working on this project with me, please let me know! You will need some experience with FFT algorithms. I'm going to have to take things fairly easy to start with.

[adamski]

Hi Everybody,
I've had to give up all things Teensy for the past few months while battling extreme fatigue post treatment for a serious illness. The good news is that we have found that most of the problem was actually an allergy to one of the drugs that was meant to help fatigue!!! Anyway, I hope now to be much more active on the forum again. I had many projects underway when I was forced to stop, and one of them was a complete Teensy FFT library with int16, int32 , and float, inverse and forward, complex and real, and standalone and audio board versions. It would also have complete radix-2 (32, 64, 128, 256, 512, 1024 (and longer if there is any interest) lengths. In addition the routines all have minimum length "twiddle" tables to keep the memory size to a minimum.
The code is derived from "cherry picking" the newer arm_math source code, and is based on a mixed-radix (4 and 2) approach with output bit-reversal. For the non radix-4 lengths I wrote code to perform the column zero operation before defaulting to the arm_math radix-4 approach for subsequent columns.
Where does the project stand? I have written and verified the complex, int16, forward FFT, standalone, length 32, 64, 128, 256, and 512 functions on both the Teensy 3.2 and 3.6. I have written MATLAB code to automatically generate the twiddle and bit-reversal tables, so extension to other lengths is easy. The routines are fast - I'll try to post the timing information later today. My next focus will on the matching int_16 IFFT routines (making sure IFFT(FFT(x)) = x).

From there I'm open to suggestions - perhaps audio board library forward and inverse complex functions with the missing lengths, particularly 128 (since I want this for some other projects (SDR related))... I don't yet have a 3.6 wired to an audio board, so I'll have to start with a 3.2.

If anybody is interested in working on this project with me, please let me know! You will need some experience with FFT algorithms. I'm going to have to take things fairly easy to start with.

Sounds great. Looking forward to trying it out when it's ready. I'm looking for a flexible FFT library for standalone use, ideally with support for floating point numbers for use on the 3.5/6.