The HWAFFT interface provided by the code accompanying SPRABB6B looks like this:
Uint16 hwafft_8pts(
Int32 *data,
Int32 *scratch,
Uint16 fft_flag,
Uint16 scale_flag
);
As the documentation points out, the format of the data is real/imaginary interleaved 16-bit signed integers. Each 32-bit unit corresponds to a single complex value.
However, for the purposes of further signal processing, it would be very convenient to simply keep an interleaved Uint16 array, rather than have to mask and shift values into, and out of, 32-bit values in the FFT data arrays.
I can't just pass Uint16 pointers to the functions as declared in the header files, because that would be undefined behaviour in C, and I don't see anything in the compiler manual to say I can do that. But I don't know enough about the ROM implementation/TI calling conventions to know if I can change the header file declarations to take Uint16 pointers. Will doing that affect how the hwafft implementation in ROM behaves? Is it a dangerous thing to do, that might work now but might break unpredictably later?
