Interpreting RFFT32 results

The 128 pt RFFT should treat the input as 64 pt complex data and run a 64-CFFT on it resulting in complex output, which, if plotted will show some negative values.

I believe there is a bug in the structure intialization macros which initialize the fft size to N instead of N/2. You also have to perform some additional post-processing steps to get back the correct output which has NOT been implemented in this library as yet.....it will be in the next revision which will be soon

please see section 2 of this wiki: http://processors.wiki.ti.com/index.php/Efficient_FFT_Computation_of_Real_Input#Computing_a_Length_N.2F2_Complex_FFT_from_a_Length_N_Real_Input_Sequence

I would recommend using the CFFT and computing the magnitude for your code. As far as 0th value goes it is the DC value and it basically is a sum of your 128 samples/128. if your square wave has an offset this will be a non-zero values.

So, if I am to use CFFT32, what's the ipcbsrc input supposed to be?

I'm currently sampling data from ADC at 40kHz and stored the data as follows:

ipcbsrc[conversionCount & 0xFF] = (long) AdcResult.ADCRESULT0;

That being said, I want to do 128-points FFT, could you verify that my code initialization are correct?

#define N 128

long ipcbsrc[2*N];

long ipcb[2*N];

CFFT32 fft = CFFT32_128P_DEFAULTS;

CFFT32_brev(ipcbsrc, ipcb, N);

CFFT32_brev(&ipcbsrc[1], &ipcb[1], N);

fft.ipcbptr = ipcb;

fft.magptr = ipcbsrc;

fft.winptr = (long*) win;

fft.init(&fft);

fft.calc(&fft);

fft.mag(&fft);

So I'd expect the magnitude to be stored in ipcb at index 0, 2, 4, and so on?

you're initialization is correct: if your input data is real be sure to pad in alternate zeros for the imaginary parts though and then point ipcbsrc at this padded input matrix. The magnitude is real valued and contiguous in ipcb @ index 0,1,2,3..N

So let me check if my understanding is correct...

ipcbsrc[0, 2, 4, 6, ... 254] <- data from ADC

ipcbsrc[1, 3, 5, 7, ... 255] <- fill with zeros

ipcb[0 ... 127] -> magnitude

ipcb[128 ... 255] -> unusable data

Thanks

That means, during the FFT computation, the ADC should not be allowed to change the contents of ipcbsrc, correct?

Interestingly, after fft.mag(&fft), the ipcbsrc[0..127] are all zeros... fft.peakmag = 0, fft.peakfrq = 0

This is how ipcbsrc gets populated:

interrupt void adc_isr() {

Here's my code that's related to FFT computation:

#define fftSize 128

long ipcbsrc[2 * fftSize];

That now makes much more sense!

Thanks very much, Vishal!

Quick question. There is this following code in F28035.cmd:

   ramfuncs            : LOAD = FLASHD,
                         RUN = RAML0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0

Does the CFFT32 copied from FLASH to RAML0 during runtime?

Thanks

EDIT: I do not find any #pragma that does so, but I just want to double check.

Hi Gloria,

Usually the buffers are in RAM but the code fro the FFT can run out of flash. A good example for FLASH implementation is : controlSUITE\development_kits\F28069 controlSTICK\FPU - SineFIRFFT32---The same code can be adapted to the 2833x with a few changes to the .cmd file

The function InitFlash() is in the section ramfuncs and needs to be copied over to RAM first and then executed to setup the FLASH but other than that the implementation is no different from the RAM version