Spectrum Analysis with 8Bit Freescale 9S08 in the 2012

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Spectrum Analysis with 8Bit Freescale 9S08 in the 2012

535 Views
Encoder1
Contributor III

Hi guys.

 

Why this title? A first attempt to use a 8-bit microprocessor from Motorola is described by Richard Lord on “Byte Magazine”, Feb. 1979, pp. 108-119. It was a 6800, grandfather of actual HC/S08 and required some 3 seconds to analyze 256x8bit samples. Not really real time.

 

I am going further to explore feasibility of nowadays small 8bit Freescale uCUs to perform Spectrum Analysis in real time or at least “live”. I already made some assertion based on my previous studies on this matter(see: https://community.freescale.com/message/94668#94668) which I am able to completely confirm. These are the results I obtained from a MC9S08ACxx running at 20MHz busclock, at various resolutions and precision:

 

128 samples, 8bit:          10.6ms

256 samples, 8bit:          24.2ms

256 samples, 16bit:        58.7ms

512 samples, 16bit:      131.3ms

1024 samples, 16bit:    274.3ms

 

As you see there is not the case of 64sps/8bit because of the poor use of this resolution but it is easy to predict from the theory which for each step of 2^N samples assign T(2^N) = 2*N/(N-1) * T(2^N-1), i.e. 4.5ms. You see that all the other results are in line with this function.

 

Above results where obtained with optimized assembler routines either with windowed or unwindowed data and do not include sample time. This latter is obviously dependent only from the sample rate which may be as high as 100kHz+: I did 2 channels 40ksps 8bit sampling in 9.8/13.3us unwindowed/hamming windowed. 10 or 12 bits requires a little more (20-30%). Windowing, when done, is applied during sample time. FFT complex output vectors are geometrically summed to obtain the true modules, not simply added.

 

Main problem for small uCU is internal RAM: data and FFT vectors must reside on it. You need at least the double of data room occupation for processing and some dozens of bytes for variables. ROM occupation is quite small, slightly less than 2kB (2033 bytes) for the 1024/16bit FFT including look-up tables. So you are able to perform 128sps/8bit in 512B, you need ~540B (1kB) for 256sps/8bit, ~1060B (2kB) for 256sps/16bit, ~2080B (3-4kB) for 512sps/16bit, ~4130B (5-8kB) for 1024sps/16bit. I tested the smaller routines in a 9S08AC32 (2k RAM) and simulated the others with a 9S08AC128 (8k RAM), now I am going to use these studies to make some experimental hardware constituting a “real life” test and a challenge for myself:

 

  • In the first HW I am designing a stereo 7 octave + level meter on a 2x20ch LCD alphanumeric display with the smallest usable uCU, a 16pin 9S08SH8 with 512 Bytes RAM. Hardware will be essential: the uCU, 2 x IIIrd order Bessel 20kHz LPF/amplifier with a quad op-amp and little more on a PCB piggy-back mounted on the LCD. FFT will process 2x 128sps/8bit. This is pretty ready, the PCB is designed, the SW is 80% functional
  • The second project is more ambitious and is in development for later. I think to design another simple board with a bigger RAM uCU to make a more powerful Spectrum Analyzer with output in half or third of octave. This could employ 2x256/16bit FFT if mono or 4x128/8bit if stereo. It is still vague

 

Both these projects will be shown on an electronic magazine so I cannot reveal too many details but, if this argument raises some interest I will keep you updated.

 

Your comments and/or experience are welcome.

 

Salvatore

Labels (1)
0 Kudos
0 Replies