Stellaris LM4F120 LaunchPad Thoughts

I just received my Stellaris LaunchPad in the mail! It shipped on the 25th and arrived at my house today on the 27th. I put in the order within a few minutes of getting TI’s email announcing the pre-order. Looking at TI’s store they are now estimating 2-8 weeks for orders placed before prior to the 25th. I remember it taking them a while to get the MSP430 launchpad shipped when that was first announced, and I would say the LM4F120 is a much better deal for $5. It just goes to show the LaunchPad’s are being shipping.

The demo application on the board shows off the basic hardware on the board. The RGB LED is fades between different colors when left alone and the buttons cycle between the different colors. Holding both buttons down enters hibernation mode.

Not shown in the video the demo application also features serial control over the color, light intensity, and hibernation. The serial drivers do need to be installed for this to work, although I had no issues getting everything up and running on Windows 7 per TI’s included instructions.

Running the demo application draws around 22mA, switching to hibernation reduces this to an average of 850µA. In both cases the LEDs draw the most current. I figured because they included the hibernation feature I might as well test it.

The biggest draw to getting the Stellaris LaunchPad was that it is a Cortex-M4 ARM core which is very capable when it comes to doing DSP. That coupled with the dual on-chip 1MSPS Analog to Digital Converter means that some very interesting mixed signal projects should be possible with this dev board. An interesting feature of the LM4F120’s ADCs are that they can be phase shifted relative to each other (around 20-30°), and they can also be shifted by 180° to get an effective 2MSPS sampling rate. Considering most entry-level MCU’s have ADCs with a 200kSPS or lower sample rate this is fantastic.

Unlike the MSP430 LaunchPad the programmer cannot be separated from the without cutting through and destroying the programming section. The headers are also pre-soldered instead of being included in the box.

An interesting thing to note is that the programmer is exactly the same LM4F120 microcontroller which handles all of the USB serial communications and debugging interface.

I do wish that the board had a more interesting peripheral than an RGB LED, but for 5$ I can’t complain. The LM4F120 MCU has plenty of on-chip features and I am excited to see what people come up with using this development board.

 

LPC1769 Fast Fourier Transform

I recently discovered that NXP has published a DSP library for their ARM Cortex-M3 microcontrollers and I thought it would be fun to write an FFT example using my OpenLPC dev board. It works wonderfully!

I apologize for the video of a computer monitor, the screen capture software didn’t run well when trying to refresh the terminal that quickly.

The example code is actually fairly simple seeing as the heavy lifting is done by the pre-complied library. I turn on and set up the on-chip analog to digital converter and then take 1024 samples storing them in SRAM. There are no imaginary samples so I just store 0 every other sample. The array is then sent as an argument to the Fast Fourier Transform function along with a separate pointer to another location in SRAM on the LPC1769 where the results are stored. The magnitude is then calculated and scaled for printing to the terminal. Because I am using a higher resolution FFT I just print a few of the frequency bins (in the video I print 74) so that it will fit on my screen. My current code doesn’t use interrupts and so the sampling frequency depends on the execution time to store the ADC results in  SRAM along with some logic operations and the 65 clock cycles for the actual conversion. When it is all set and done I repeat the process at 20Hz.

The hardware setup was very simple. An arbitrary signal comes from my function generator centered at 1.5V and fed through an RC low pass filter with a cutoff frequency at ~70KHz for anti-aliasing. This is roughly around the Nyquist frequency of the ADC as I am sampling at around 160KSPS. For practical applications this wouldn’t work well and would allow a lot of signals to alias into the sampled signal, however it takes the edge off of what I was working with.

In all it took a couple hours to get everything set up and running correctly. I will clean up my code and use interrupts in the future to get a more predictable sampling frequency. For now my code is available on my GitHub repository.

https://github.com/willhb/lpc/tree/master/fft_adc.lpc17xx