16-bit Real-Time FFT Demo on an 8bit AVR (ATMega88 @8Mhz)

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
https://www.dspguide.com/
(3) https://code.google.com/archive/p/arduino-integer-fft/downloads

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:
https://bit.ly/1jAgf2g

As requested, some schematics:
https://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).
https://bit.ly/1mvYnaB

IXIBA

Видео 16-bit Real-Time FFT Demo on an 8bit AVR (ATMega88 @8Mhz) канала DigitalPhage