This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

bit reverse

I was hoping that there would be some psuedo or example code for the CMSIS generated bit reverse look up tables for the FFTs. I would like to try and extend the FFT to 8k in length. So I am looking at these tables, but can not figure out how they are generated, specifically the tables like armBitRevIndexTable128.

Thanks.

Parents
  • Hi dangould,

    First, please clarify that you just want to extend the CMSIS-DSP FFT function to handle 8192 sample length,  you are not writing your own FFT function which will be able to handle this longer number of samples.

    Doing the bit reversal for the new length is not very hard. The difficulty that you have to resolve in extending an existing FFT function for handling longer data is in the twiddle factors. Problems that may arise include:

    • Obstacle in expanding the twiddle factors. You will need twice the memory (compared to the longest, 4096-point, FFT function in CMSIS-DSP library), it should be a contiguous block. If something occupies the memory after the last data in the previous shorter twiddle factor table you have to find a way to "push it aside" to accommodate the twofold increase in twiddle factors. Alternatively, you can get the needed memory somewhere else and modify the pointer that the existing FFT function uses for the twiddle factors.
    • If you will be able to solve or circumvent the first obstacle, the next problem is making the existing FFT function get the correct twiddle factors corresponding to data samples. Perhaps, you have to organize the twiddle factors in unusual arrangement or you can modify the step size through the twiddle factor table. As of this time I don't have a clear idea about the details of implementation of FFT functions in CMSIS-DSP, if you have a comprehensive documentation, better yet, the source code, they are of great help.

    I believe that's the problem that you should plan to solve first. After you have crafted your solution you have to weigh the advantages and disadvantages compared to writing a new function. A factor to consider is if your application will only handle the longer number of samples or will still support the shorter FFT lengths.

    If you have a bright idea, however, please share it with us. Even if you think your idea is not rigid, fellow members may be able to help polish it.

    Regards,

    Goodwin

Reply
  • Hi dangould,

    First, please clarify that you just want to extend the CMSIS-DSP FFT function to handle 8192 sample length,  you are not writing your own FFT function which will be able to handle this longer number of samples.

    Doing the bit reversal for the new length is not very hard. The difficulty that you have to resolve in extending an existing FFT function for handling longer data is in the twiddle factors. Problems that may arise include:

    • Obstacle in expanding the twiddle factors. You will need twice the memory (compared to the longest, 4096-point, FFT function in CMSIS-DSP library), it should be a contiguous block. If something occupies the memory after the last data in the previous shorter twiddle factor table you have to find a way to "push it aside" to accommodate the twofold increase in twiddle factors. Alternatively, you can get the needed memory somewhere else and modify the pointer that the existing FFT function uses for the twiddle factors.
    • If you will be able to solve or circumvent the first obstacle, the next problem is making the existing FFT function get the correct twiddle factors corresponding to data samples. Perhaps, you have to organize the twiddle factors in unusual arrangement or you can modify the step size through the twiddle factor table. As of this time I don't have a clear idea about the details of implementation of FFT functions in CMSIS-DSP, if you have a comprehensive documentation, better yet, the source code, they are of great help.

    I believe that's the problem that you should plan to solve first. After you have crafted your solution you have to weigh the advantages and disadvantages compared to writing a new function. A factor to consider is if your application will only handle the longer number of samples or will still support the shorter FFT lengths.

    If you have a bright idea, however, please share it with us. Even if you think your idea is not rigid, fellow members may be able to help polish it.

    Regards,

    Goodwin

Children
No data