This is a 64-point Fast Fourier Transform sampling at ~9.8 kS/s using 16-bit mathsss.
The brain is an Atmel ATMega88 running at 8Mhz.
Display is an OLED 0.96" 128 x 64 SSD1308 (similar to SSD1306) using SPI (Bit-Banged).
FTT takes 2.39ms to run, uses ~11% code space & ~25% data space.
To make use of the FFT's output takes considerably more time and space.
Audio input is through a Condenser Mic with a Butterworth filter (-3db ~7khz).
This is my "version 3" FFT code. (All code in assembly language).
The first version was derived from a hybrid of code examples from the books NR(1) & DSP(2). This needed 32bit mathsss so I assumed it was beyond the 8bit ATmega and wrote it for ARM Cortex M3 instead, After many hours and a few total rewrites I had some running code, though my FFT was generating the same results as C coded version running on my PC I soon realized the huge mistake I had made.
The C code examples from the books were naturally Floating-point so I did what I normally do and just converted all mathsss to fixed point (32bit=N16.Q16), manipulating the output (Complex Numbers) in this format was going to need 64bit mathss, just became too messy.
This is when I recalled seeing an example (3) of Fix-point FFT and it all became clear why it exists.
With the second version a mixture of the first version and the fix-point example using 16bit mathsss, I deduced while simulating with C that I would only need 8bit variables upto an 128-point FFT, so good for an 8bit brain.
As a rule I'm only interested in what I can do with the ATmega's internal oscillator speed (8Mhz) or less, they can be pushed to over 20Mhz with external clock but that's boring.
I started coding for a 128-Point FFT but soon realized wit was just going to be too slow and RAM hungry to work so switched to 64-Point, So again after much time and many rewrites I had a working FFT.
"Version 2" FFT 64-point takes 3.5ms @8Mhz, 8% code space.
Unfortunately this version was a little too slow, was dropping ~10% of ADC samples.
For "version 3" I had noticed a techniques in the DSP(2) book called 'Odd/Even Frequency Decomposition', It suggested up to a 40% speed could be achieved. So I gave it a try and it worked great! I got ~31% increase in speed with only a small increase in code size.
The final demo code with the OLED display (Audio Spectrum Analyzer) uses 27% Code and 64% RAM.
(1) Numerical Recipes, The Art of Scientific Computing. Teukolsky
(2) Digital Signal Processing, A Practical Guide for Engineers & Scientists. Smith
www.dspguide.com/
(3) code.google.co...
Audio Samples:
White Noise
Sine Sweep
Bin Aligned Tones
Modem Dialup
Leisure Suit Larry theme
Kevin MacLeod - Gaslamp Funworks
Nigel Kennedy - The Four Seasons (Winter)
BIOS - Der Computer Nr3
Hocus Pocus - Here's Johnny!
Source Code:
bit.ly/1jAgf2g
As requested, some schematics:
bit.ly/1fLiXR5
For those interested, Source Code for my older Ver 2 FFT. A more conventional FFT (no Odd/Even Frequency Decomposition stuff) but a bit slow for my project (Dropping ~10% of ADC samples waiting for it).
bit.ly/1mvYnaB
IXIBA
28 сен 2024
