Initializing arm_dsp fft on SD ram

DSP
1

Hello!

I’ve been trying to set up an arm_rfft_fast_instance on the SD ram of a Daisy Seed, as so: arm_rfft_fast_instance_f32 DSY_SDRAM_BSS fft; which unfortunately does not seem to make any difference, as the initialize call arm_rfft_fast_init_1024_f32(&fft); still seems to put these objects on flash. This does work fine, by the way, but I’d love to utilize the SD ram so that I can use higher fft sizes than 1024! Anything higher than 1024 overflows flash memory in my program.

I was wondering if anyone else here got this working, or has any ideas/suggestions on how to make this work on SD ram! Any help is appreciated.

Thanks!

2

Looks like this is a struct which has a pointer element. The struct is being placed in DSY_SDRAM_BSS, but the data referenced by the pointer is not.

3

That’s right - the arm_rfft_fast_init call will set the data for the FFT.

The inner workings of how the library sets up all these FFT objects are a bit complex, but regardless, I’m guessing there’s not an easy way to have this library use SD ram instead. Bar from rewriting parts of that library?

Thanks for your help!

4

Hi! I’ve done a fair bit of work with CMSIS FFT’s on Daisy. There’s a few things that I can offer that might help:

  1. The flash/program size increase for larger FFT sizes is is due to the fairly large FFT factor lookup tables required by the FFT functions in the CMSIS DSP library. These are compile-time constant data and thus end up as part of the program .data section stored in flash which contributes to the overall binary size.
  2. You probably don’t want to use SDRAM for any of the inner FFT calculations - these need to be fast, and SDRAM is significantly slower than AXI SRAM or DTCMRAM. Best to keep all the working memory for the FFT’s in faster RAM.

Because of the first point, there’s unfortunately nothing you can do to reduce the flash usage - those lookup tables have to be part of the .data section in memory which contributes to flash/program size.

Your best bet is probably switching to the Daisy Bootloader (if you aren’t already using it) so your application size can increase, and also make sure you’re only defining the CMSIS preprocessor flags for your desired FFT size and not all of them at once (sounds like you’re already doing this). I’ve been able to use real-valued FFT’s up to 4096 samples long on Daisy in a BOOT_SRAM app.

1 Like
5

Hello!
Great! Thanks for your reply. Good point on SDRAM speeds! I wasn’t aware of the Daisy Bootloader (libDaisy: Getting Started - Daisy Bootloader for those like me) which looks like a good solution for me. So thanks again!