• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 2306 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is that possible to use the same source and destination address for real FFT computation

Guojin Feng1
Prodigy 180 points

I have been trying to implement FFT on the TIVA launchpad board. As the input data is real-valued data, I have adopted the arm_rfft_fast_f32() method in the CMSIS DSP library. The speed improvement is quite satisfied compared with taking the input as complex data type (uses the arm_cfft_radix2_f32()). The time reduction is over 50% compared with processing the data as complex type.

However, it looks the function arm_rfft_fast_f32() requires the source and destination address should be different while the arm_cfft_radix2_f32() can have the same destination and source address. In this way, these two functions consume the same memory size.

I have noticed a wiki webpage from TI Efficient FFT Computation of Real Input, which says the real-valued FFT can be implemented using the same buffer.

Is there a way to use the same destination and source address for the arm_rfft_fast_f32() function?

Is anyone have a solution for this or suggestion? Thanks.

 

  • 0
    TI__Guru**** 244440 points
    Hello Guoji,

    Apologies for the delayed response. Response from our team.

    In the CMSIS documentation for the arm_rfft_fast_f32() function there is nothing saying that you can or cannot have the src and dst buffers be the same. In the arm_cfft_f32() function, and there is some indication that the output buffer and be the same as the input buffer as it says something about in-place computation. So, we suspect that cfft is OK for in-place, but rfft may not be.

    If you actually look at the code for the arm_rfft_fast_f32() function, it is calling the cfft function and then post-processing to collapse to the rfft result:

    /* Calculation of RFFT of input */
    arm_cfft_f32( Sint, p, ifftFlag, 1);

    /* Real FFT extraction */
    stage_rfft_f32(S, p, pOut);

    So, you can examine the stage_rfft_f32() function (in the arm_rfft_fast_f32.c file) to see if in-place processing will work here. At first glance, it looks like it might work. If it doesn’t work, you can try to modify the stage_rfft_f32() function to make it work.

    Regards
    Amit