Question about using the rfftN and ifftN calls with an EZ-Lite Sharc 21489, and CCES.
I tried them on test data and stepped over all the results and verified that I’m using them correctly, (such as no nyquist from the rfft - and need to generate the negative frequencies for the inverse, etc). I can get a forward and reverse just fine.
I finally reduced some code in development to just performing rfft2048 (larger than I verified) and ifft2048 in the code I was transforming, The output is distorted and the MIPS are 125. (That’s “” because I’m adjusting for other overhead and it’s actually around 289 for two channels).
Is there something I should know about those functions for the 489? I do not think I’m making a mistake. I just spent enough time trying to fix it to reach that conclusion. I can verify none of our code has a non-Sharc problem. Also if I don’t do the transform then the rest of the code works. All of the memory is getting allocated. I’m factoring that the input buffers get trashed. The exact same code works with different FFT code without any problem on the PC I used to develop it.
The only things I can think of:
- I’m calling them via function pointers. I can’t see how that could matter, and haven't had problems with that in other parts of the code.
- Maybe they allocate scratch memory and are running out of internal memory? I am using a lot of the internal memory in this prototype version of the function.
- There’s just bugs in the rfftN and ifftN for this device. That’s mostly what I’m hoping I can get an answer about. I’m planning to try the variable sized transforms but these didn’t require twiddle tables, and claim to use SIMD.