Tiva C Series Launchpad

Hello Scott,

Yes, it is possible to do so with the CMSIS DSP library. The following application note would be useful for porting CMSIS-DSP to TM4C12x devices.

www.ti.com/.../spma041g.pdf

Also in the last 2 weeks there has been a post on CFFT on the TM4C forum. That would be a useful resource as well.

Regards
Amit

Scott Dobbins said:

I wanted to ask if there was a better mcu for performing this type of FFT algorithm? I know this mcu can do it, because I have seen example projects online. 

Wrong question, practically any micro can perform an FFT.

You haven't stated the kind of performance you need. How large an array are you transforming?  How quickly do you need the result? What kind of precision and accuracy?

FFT of video in real-time is a lot different prospect from off-line analysis of a 128 sample buffer.

Robert

Sorry about the lack of information! I am still new to E2E.

As far as performance goes, I would like to be able to take a 2048 point FFT.

This micro controller will need to sample, process, and update the output faster than 1ms (MCU output will be sampled from external DAQ at a max of 1kHz) So that is my "real time" constraint. 

As far as precision and accuracy go, I am looking for the highest performance/most robust MCU to accomplish this algorithm. 

Scott Dobbins said:

I know this mcu can do it, because I have seen example projects online. 

And so many here have also, "Seen claims & examples - online!"    Unfortunately - "online - by itself" - may not serve as full & highly creditable evidence.

Poster Robert identifies key/critical performance metrics - so often absent, "online."  

It is one thing to have an, "MCU do it" - it may prove far more challenging to, "Do it with acceptable speed and accuracy..."    (and that most necessary "detail" rarely resides, "online.")

As far as performance goes, I would like to be able to take a 2048 point FFT.

This micro controller will need to sample, process, and update the output faster than 1ms (MCU output will be sampled from external DAQ at a max of 1kHz) So that is my "real time" constraint.

There is kinda contradiction in your requirements. With a 1kHz sample rate, it takes about 2 seconds to fill the buffer, before you can do a FFT. That gives you spectral information about the last 2 seconds, with this 2 seconds (sampling time) latency. I can't see how this information could be immediately useful in a 1 ms cycle-by-cycle control.

I made some experiments with FFT performance on TM4C (and others) about 2 years ago, achieving about 4ms for a 2048 point CFFT on a 80 MHz core, using the CMSIS DSPLib floating point routines (i.e. 32 Bit, single precision, with FPU). And I got about 2.4ms on a competitor's core, running at 168 MHz. Just to give you some figures about what to expect.

Thank you for your reply f.m. I am still new to MCUs, so I appreciate any help you can give!

I suppose the 2048 point FFT is negotiable. I will know where all the frequencies of interest are located. So lets say the signal has 20 different frequencies embedded in it(and I know the location of all of them). I just need to know the energy associated with 1 specific frequency, and use that to modulate a PWM so I can track it. If I lowered the FFT point (1024?) thus increasing the frequency bin spacing, could I possibly meet the 1ms "output refresh rate" requirement? So long as the 20 different frequencies fall into separate frequency bins of course.

Also the MCU I was looking at purchasing was the TM4C1294 Connected LaunchPad. Since it has 256k of RAM and is 120MHz, seems like it would be good for the job.

I also planned on using the CMSIS DSPLib as well.

Hello Scott,

You would need to see how to keep data acquisition and data analysis in real time as much decoupled. Since the analysis start point is ADC, one method would be to use a Timer to trigger ADC and DMA to offload the data to SRAM. Once done it goes for the next set of acquisition while CPU performs FFT. To ensure that the requirements are met, do the FFT calculation on a known set of data without any other CPU load.

Regards
Amit

I still see a problem with your approach - the latency.

To perform a FFT, you need a certain time to gather all the data. For 1kHz sample rate, it takes 2048 ms to capture all data to perform a (2048 point) transformation. Just assume another 2ms for the FFT (to get a round number), you have spectral information 2050 ms later. In other words, you get new spectral data each 2050ms, not every millisecond. And reducing the number of points does not really alleviate the problem. You could probably increase the DAQ rate to 10kHz to shorten this time, but need to consider how that affects your spectral resolution.

Not sure if there are "FIFO"-like FT algorithms, but not in the CMSIS DSP lib. But there exist algorithms to evaluate single spectral points (i.e. frequencies), which might be of interest in your case. Just can't remember the name at the moment ...

In the not too distant past I pointed to a DSP reference. Ah, here we go

e2e.ti.com/.../1658537

You want to read the filter sections.  That's what you are trying to implement, a filter.

Robert

Amit, I understand your idea. Ideally that is what I would like to accomplish with the general processing algorithm, the ADC samples the signal, then passes that data on to be processed, then immediately begins to sample again, essentially an "assembly line"/pipelined style (if that makes sense).

f.m I now see your point. Maybe if I describe the application a little better in detail and explain my thought process behind doing a FFT (Robert, I had initially thought about using filters, but I thought they would not be fast enough to meet the 1kHz output rate that is required) things will become a little more clear.

The signal that will be sampled will be the linear combination of sine waves at various frequencies and amplitudes. I can choose which frequencies will be present in the signal.

What I need to do is essentially measure the magnitude of each frequency present in the signal. Out of all those frequencies there will be a "desired frequency" I then need to sum all the magnitudes of the "undesired frequencies" then subtract that number from the magnitude of the desired frequency (due to the nature of the system/circuit the desired frequency will always have the largest amplitude). That number will then be set to vary the duty cycle on a PWM output.

My first thought was "I can just implement a bunch of band pass filters (approx 20 -> 1 filter/frequency) and take their magnitudes and then process them" but I thought this approach would be too slow. So i then had the idea of doing the FFT and just grabbing the magnitudes of certain frequency bands (space out the signal frequencies so they are all in a different bin) and that should produce approximately the same result.

Since I have control over the frequencies that will be present in the signal, could I just increase the 20 frequencies into the 30kHz-60kHz (approximately) range, sample them at around 120kHz, and then perform a 1024 (or even less) FFT to acquire their magnitudes?

There is an analog version of this project I am trying to make and it implements the bandpass filter method, however I thought it would be clever to take advantage of processing it digitally to do a "graphical" (FFT) based processing instead of a bunch of filters.

I'm still not sure at which rate you want/need a spectre, i.e. at which rate you want to control your PWM settings. But instead of doing a "full" FFT, have a look at the Goertzel algorithm. This method evaluates only individual frequency terms, which might be appropriate for you, if you know the frequencies involved.

Not sure if an increase in sample rate, i.e. 120kHz instead of 1kHz, will solve your problem. A FFT still takes some time (I guess about 3ms for 2048 points at 120MHz), and with this sample rate, frequent interrupt routines (directly or for DMA "end of transfer") will start to eat significant amounts of cycles away. The Cortex M controllers have DSP-like instructions, but are not DSPs -  if you require peak performance in short (interrupt) cycles, consider a real DSP.

No matter if you use an FFT or a real time filter you are going to need to sample more than twice as fast as the highest frequency you are interested in. An you will need to limit the frequency coming to the A/D to less than half your sampling frequency. For an FFT you will also need to retain enough samples to encompass your lowest frequency of interest and distinguish between all of your frequencies of interest.

The analog solution has the advantage of working with a continuous range of values in both the time and amplitude regimes, the digital solution will be discrete in both.

Filters will still be digital but more flexible than their analog equivalents.

I would suggest testing on your PC with sample data before attempting to implement on the micro. You can easily mock up implementations of FFT and filters to test and compare. That may show a solid advantage for one or the other.

I'm not sure I'd expect a FFT based filter to be faster than a discrete multi-tap FIR or IIR. It would depend on how many poles/how large the FFT.

Robert

f.m.,

I have never heard of the Goertzel algorithm, it looks to be very applicable to this project! Do you have any examples of this algorithm being used on a TI micro controller?

As far as the "rate you want/need a spectre" question goes, I must have a "black box" that will output 1000 times per second. So sample the incoming signal, process, and update the output in less than 1ms. I have no problem increasing the frequencies in the incoming signal, so that the MCU can sample at a higher frequency. Like I said earlier, as long as the frequencies embedded in the signal are sufficiently spaced, why couldnt I sample the system at 120kHz (or as fast as the MCU allows). then implement a 256 point FFT (decrease the number of FFT points, to decrease the processing time) and as long as those 20 frequencies fall into separate frequency bins I could increase the speed of the total process?

Robert,

Would a Matlab simulation be applicable? I have extensive experience programming in Matlab and Simulink. I have designed digital filters before using Matlab's FDA tool. I suppose I could also simulate the Goertzel algorithm as well to see how they all stack up to one another.

Update:

I was doing research on TI products that can do a FFT very quickly, I found this paper that references this product. It looks like it can operate at 100MHz and perform a 1024 point FFT in 73us!

What do you guys think about this?

www.ti.com/.../sprabb6b.pdf

www.ti.com/.../tmdx5505ezdsp

What do you guys think about this?

That links refer to DSP's, which are actually a very different kind of animal. This kind of processors usually have multiple execution blocks, separate RAM blocks (with separate internal bus interfaces) and other nice features to allow for executing 5 ... 10 instructions in parallel, in one cycle. With tailoring and optimising, you might get down to about 1ms with a Cortex M4, but hardly to 73us for a 1024 pt. FFT.

However, I don't think the FFT calculation time is you greatest issue, rather the sampling time before, and the thus introduced lag (i.e. latency). And to be honest, I never investigated the Goertzel algorithm myself - don't know what latency it would have. But if you alter the PWM settings in each cycle, I guess you need to recalculate the spectral information also at that rate. Not sure what is the best way to solve this conflict...

Robert's suggestion to use digital filters would avoid this latencies. And CMSIS comes with several implementations.

I have not used Matlab and Simulink myself. Many physical simulation environments (which I think these started as) do their processing in floating point so a big key to your simulation will be to make sure anything that is integer based (such as the A/D) is properly simulated as a discrete value. This discrete nature of the inputs, outputs and time is potentially a significant factor in the digital versions performance compared to the analog version.

Other than that any language should work for initial simulation of the algorithms to determine fitness.

Robert

This also strikes me as a very good place to be using Test Driven Development.

Robert