Wednesday, June 27, 2012

The practicing instrumentation engineer's guide to the DFT

Steve has published a series of articles on EDN Magazine about engineering uses of the DFT and FFT. The seires Discusses practical implementation of the Discrete Fourier Transform in instrumentation applications. The series of articles focuses on the often forgotten "Calibration" factors and dispels some myths about DFT's and Windowing data in general.

Links to the articles at EDN Magazine
,

Friday, June 15, 2012

Bit/Bang SPI Speed of PIC18F6722

With all this work on uP's and ATMEL UC3 C Compiler Optimizations, I decided to take a look at one of my old workhorse processors the Microchip PIC16 and 18F families. I program these devices using the CCS PIC-C compiler.

Similar to the last post about UC3 processor timing when running Bit/Bang SPI type of IO quickly threw together some sample code for the PIC18F6722. I set the PIC up to run on a 10 MHz Oscillator with the 4X Internal PLL, giving a program instruction running rate of 10 MHz (the clock in these devices runs at 4 times the actual instruction rate).

The CCS compiler has a series of high level IO commands similar to the ATMEL ASF pin IO commands[1]. This mode is called “FAST_IO” and what it does is allow you to set the direction of the port pin then using a high(er) level command to set any Pin anyway you want it (using the output_bit() function).

I also built a function using direct IO. This is where C really hits the road! In CCS C we are able to directly define any bit or pin in a port using a #bit directive, then just using PIN = 1; or PIN = 0; in my program we can set that pin as requested with just one CPU instruction.

So on to the testing - since the CCS compilers that I use are always optimizing and there are no real optimization switches, we get just one number for comparison - the clock frequency of the Bit/Bang IO function (the code is very similar to the previous post on UC3 IO Optimization[1]).

=======================================================================
Using FAST_IO the SPI clock pin frequency was: 560 kHz

Using direct Pin Banging the SPI clock pin frequency was: 716 kHz
=======================================================================

Not blindingly fast compared to the UC3, but the PIC was using lots less power and is fast enough for many useful applications, in fact we have been using PIC's to successfully control all sorts of things from: Temperature Chambers to Cellphone Monitoring Radios since 1994.

Steve Hageman
www.AnalogHome.com

[1] Previous Post: http://analoghome.blogspot.com/2012/06/atmeluc3-32-bit-processors-and-gcc.html

Thursday, June 14, 2012


ATMEL UC3 32 Bit Processors and GCC Compiler Optimization - Part 2 - Timing

To test the ATMEL GCC Compiler Optimization with respect to loop and IO timing I wrote a simple little SPI type data output routine that simulates bit/bang IO with high level ASF commands. Specifically I wrote a little function that takes a data value, shifts it and actuates a clock pin. The usual thing one does for bit bang IO.


Figure 1 - Here is the code that I used to simulate a Bit/Bang SPI routine, very basic. I used a high level “ioport” command from the ASF framework to set the pins, just to see how fast this ASF method could be.

I set the ATMEL EVK1104 Eval Board to a 66 MHz Internal Clock Frequency and just called the spi_test() routine from a number of places in a simple main.c program, this was to prevent the function from getting inline optimized out. I also made sure that the variable spi_data was not optimized away by making it dynamic in all the calls and by defining it in the main program as volatile.

Now for the results of this test. As can be seen from Figure 2, no optimization is a pretty bad idea for a program such as this as the clock was measured in kHz, not MHz! All the other optimizations had about the same speed increase (within 1% or in the 10's of nSeconds of each other).

Figure 2 - As can be seen in the data, no optimization is a pretty bad idea when doing bit bang IO if you want any speed at all. Using a 66 MHz CPU core clock the SPI clock speed came out a respectable 2.7 MHz when optimized, not blindingly fast, but fast enough - and this was using the high level ASF commands to bang the pins around with.

All the optimizations have some issues: In debugging or in the way the code may or may not actually work, so it is best to study some of the options first before you commit to actual plans.

The code was compiled in AVR Studio 6 that was current on 6Jun12.

Steve Hageman
www.AnalogHome.com


Wednesday, June 6, 2012

ATMEL UC3 32 Bit Processors and GCC Compiler Optimization

We have been working on some 32 bit applications here in the lab using the ATMEL 32 Bit UC3 Processors. The AVR GCC compiler has various optimization levels and there is a lot of information on the web about what the various levels do and what we should be using (or at least opinions as to what we should be using). 

Being an engineer - I like actual data, so I took one of ATMELS rather large DSP applications that has a LCD GUI and I ran it through all the optimization levels just to see what the code size improvement is.



Well, there you have it. For this big application (200k of Flash Used!) the results of the best to no optimization is just under 10% reduction in size, I did not try to measure execution speed as the -O0 code seemed to run the GUI just fine.

The AVR32-SIZE is the actual flash memory usage. Just for comparison I also plotted the raw HEX file size. As can be seen the % decrease in the HEX file tracks the actual reduction in the flash memory usage very well.

All the optimizations have some issues: In debugging or in the way the code may or may not actually work, so it is best to study some of the options first before you commit to actual plans.

The code was compiled in AVR Studio 6 that was current on 6Jun12.

Steve Hageman
www.AnalogHome.com