Update

So it's been a pretty long time since I updated this blog, and while this one doesn't really provide any cool new pictures, I anticipate posting some within the next week or so.

The two main things that have been occupying my time are:

• Converting the FFT algorithm from floating-point to fixed-point arithmetic. 

My PC and laptop have no trouble performing floating-point calculations with their FPUs, but doing them on an embedded microprocessor without one is just a touch too slow. When I initially wrote the fixed-point version, I basically decided to rewrite the entire program from scratch, all in one hit. Big mistake. I ended up with simple, decently written code that did not work as I had intended. I decided, after a lot of faffing about, to cut my losses and start the conversion again, but taking it slowly and checking the results step by step. I converted the code for generating the sample reordering array and twiddle factors to pre-generated look-up tables to cut calculation time.
One thing I've noticed is that the sample bit width appears to generate noise in the FFT output if it is too large, but this only affects the fixed-point code. I believe it may be causing overflows with the complex arithmetic functions, but I'm not 100% on this. Solutions involve possible scaling and/or leaving the ADC samples unscaled (12-bit instead of 16-bit data).

• Playing around with the STM32 hardware.

I had never coded for an ARM based 32-bit processor, so it's been a bit off a learning experience. I had no idea of the little extra hardware modules that you seem to get as default on a 32-bit microcontroller. I don't think I'd bothered to read a list, but some things I really wasn't expecting to find include an internal thermometer and real-time clock. Many parts to play around with.
I've written up libraries for the USART for serial communication and debugging, ADC for sampling an audio signal, and DMA for automatically storing the ADC's results in memory. I also wrote some software to get basic communications going with an old Sure Electronics 64x32 bit RG LED array I had sitting in my cupboard. I'll use this for the spectrum output.

More to come.

Command terminal spectrum analyser

So I was testing my FFT algorithm after porting it to C++ from my Matlab code, and I wanted a way to visualise the results (numbers just aren't as cool).

I decided to write a few lines of code to display the results, and this was the result.

Seems to work, since the test waveform consists of sine waves of various magnitudes at 100Hz, 2kHz, 12kHz, 15kHz and 20kHz.

FTDI, Library Troubles, and an Incorrect Crystal Frequency

After a lot of stuffing about, I've finally got my USART transmitting characters at the correct baud rate.

Since my last post, I've create a little FTDI serial to USB interface board that fits inside my Primer 2. It's fairly dodgy since it was rushed and made at home using the Kinsten etching method, but it works and brings USB serial, along with SPI, I2C and CAN pins, to the outside of the device.

The hardware worked flawlessly the first time (althought I think I should be driving the LEDs from VCC2V8 (2.8V) rather than VCC (5V from the USB port), but the software was an issue. The baud rate was being doubled for some strange reason, and after looking through the libraries without much explanation, I discovered that the 'stm32f10x_conf.h' sets the STM32's clock source to 8MHz which I believed was correct, but the crystal on the Primer 2 is actually 12MHz. If only I'd checked the schematic.

After this was changed, the 115200 baud rate correctly transmitted the single ASCII characters I was testing with.

Changing libraries took a bit of time to get used to since the newer ones handle a few things differently, but I think I'm fairly well sorted now.

Hopefully I can get some basic USART and complex number libraries working tomorrow. If work and Portal 2 don't interfere that is. :)

EDIT: After making a slight modification (cutting two tracks and adding two extra wires to disconnect the LEDs from VCC and reconnect them to VCC2V8) the LEDs now stay completely off when no data is transmitting.