А у него точно long длиной в 32 бита? Может быть для уверенности лучше написать uint32_t, как в примере? А то по идее у него уже обычный int должен быть длиной в 32 бита.
А пример у вас в описании библиотеки приведен:
Код
#define N 64 /*Number of points*/
uint32_t x[N],y[N]; /* input and output arrays */
uint16_t real[N], imag[N]; /* real and imaginary arrays */
/* Fill the input array */
for(i=0; i<N; i++)
x[i] = (((uint16_t)(real[i])) | ((uint32_t)(imag[i]<<16)));
cr4_fft_64_stm32(y, x, N); /*computes the FFT of the x[N] samples*/
Это означает, что действительная часть хранится в младших 16-ти битах 32-битного числа, а мнимая - в его старших 16-битах.
И хотя там явно о том не сказано, но, по-видимому, и в результате преобразования тоже будет та же самая система.
Поэтому, на мой взгляд, было бы проще объявить входные и выходные данные не как массив из 32-битных целых, а как массив структур из 16-битных real и image полей:
Код
struct complex
{ uint16_t real;
uint16_t imag;
} BUFOUT[NPT], BUFIN[NPT];
for(i=0;i<NPT;i++) { BUFIN[i].real=500+500*sin(PI2*i/NPT); BUFIN[i].imag=0; }
cr4_fft_64_stm32(BUFOUT, BUFIN, NPT);
// cos-амплитуды выбираем из BUFOUT[i].real, а sin-амплитуды из BUFOUT[i].imag
Тогда и упаковывать/распаковывать ничего не придется.
Библиотека DSP для STM32F1xx от STM, не понятны результаты FFT
Oct 11 2012, 12:15
тут нужны знаковые массивы, т.к. в них же функция пишет коэффициенты синусов и косинусов после БПФ. но идея понятна.
Надо будет подставить другую функцию извлечения квадратного корня.
