A recommendation of DSP chip?

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi:

Can anyone please recommend a chip? Not necessarily a DSP, but capable of executing FFT is a must.

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's like saying "could you please recommend a car". Do you want your car to accelerate to 60mph under 6.0s? Do you want it to achieve 70mpg? Do you want to tow a caravan? Do you want it to seat 8 people?

(clearly TI are perhaps the biggest player in the DSP world).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you're new to DSP, do yourself a favor and get a floating point point device.

Greg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wondered if there was a DSP world equivalent of Arduino for getting started easily. Closest I have found so far is $49 for this:

http://www.ti.com/tool/tmdx5505e...

(but regarding what Greg said that is fixed point, not floating).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Floating point libraries are implemented in the gcc avr development environment. But you need memory for that, like a 32k type (e.g. the ATmega328, which is also used in most arduinos).
It is possible, but the maximum frequency might be a problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But you need memory for that

Just over 1K - any 4K or greater AVR should be fine.

But an AVR is not great for DSP tasks (though I guess that depends on how intense the computation is).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Notice that the OP didn't mention any performance expectations:

Quote:
Not necessarily a DSP, but capable of executing FFT is a must

so, if he's after minimal power consumption, even an old wooden abacus would qualify, since the FFT can always be done in "software".

More seriously, many people over here (myself included) have done useable floating point FFTs on an AVR...

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah but... for audio you need one period of the lowest freq of interest.... that's 50ms worth of samples at 40KHz... about 2000 samples at 4 bytes ea.... need lots of ram

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who said "audio"? The OP could as well try to measure the earth's movements in order to predict earth quakes...

The STM32F4 series comes to mind if you really want to do audio, with 192 KB SRAM there's plenty of buffer space to hold your audio samples. DMA, fast 2 channel DACs, lots of audio-related application notes, voila!

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Who said "audio"?

OP did in his other threads.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the max and min freqs encountered in seismographs? (Engineers sure are curious aren't they?)

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm currently using Chan's FFT library on my Atmega128. I'm not even running at full speed, and is meeting my application requirements nicely.

My advice : experiment first, FFT on AVRs is not as processor intensive as people would think.

It's going to be expensive and time consuming to jump platforms for something that can be done with your existing hardware.

By the way, I got my mega running at 8Mhz.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do DFT calculations on the fly, little ram is needed. Smaller code requirement. It takes more time to run each harmonic. We are all guessing the speed requirement. Might do that with AVR.

I have used TI TMS320F280x series. They are very uC like, with easy to use peripherals including multiple timers with pwm, adc, spi ...
Development costs are more, to buy programing dongle and C compiler.

It all starts with a mental vision.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I notice there's a port of GCC to the ADI Blackfin - that could reduce C compiler cost.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ARM Cortex M4.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, that's exactly what i had in mind when i first recommended the STM32F4 series. Being back from the Embedded World, i'm now busily comparing all those free evaluation kits that are mostly ARM-based (with the exception of the Renesas RL78). But the huge amount of RAM in the STM chip goes unparalleled with all the others.

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atollic have changed their free offerings. No longer do you have unlimited code size and chopped down features, but the opposite now. The 32 k limit is next to useless for doing any real work.

On the entry level TI micros, there is a free code composer suite.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you all.
I have got a TMS320VC5505 dZdsp USB Stick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't keep us in the dark - exactly what kind of audio processing were you planning to do?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FFT - he mentioned it in his first post.

I've got one of those ezDSP USB Sticks, as well.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes but to achieve what? I'm just interested because many responders said "AVR can do FFT" (which is technically true) but wonder what the actual processing requirements of the job really were.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That kit is intended for AF, as it has an audio codec, microphone input and headphone output. I doubt if an 8-bit AVR would be suitable.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To clawson and all other people who are interested:

There are two design objectives I want to achieve: A and B, below they will be broken into steps:

A1: using TMS320VC5505 as the platform to develop a demonstration unit, which will be recording audio signals from a portable radio's speaker, time stamp them and store them in on-board memory. By the end of step A1, audio processing should be minimum.
A2: using TMS320VC5505 USB connection, all time stamped audio signals will be downloaded to a PC; I will write a PC based application to display those audio signals in time domain.

In summary, objective A is to enhance the current field trial system, where all time stamps are recorded by human operators. Human operators make mistakes, they may miss a time stamp or get a time stamp wrong. (I will write a detailed post about field trial system and what I want to achieve in detail should anyone is interested.)

B1: In a completely different operating mode, with TMS320VC5505, it will capture and record audio, time stamp them.
B2: In mode B, this device has to be connected to a PC all the time. All captured audio signal will be downloaded in real time to a PC, and with a PC application, they will be displayed in frequency domain. There are two options, I can either do FFT using a DSP chip or do FFT on PC. I have not made the decision yet.

In summary, objective B is to provide a way to present an audio signal in frequency domain. The reason why I want to do this is: in the past, there has been several incidents that when testers/developers attempt to describe an audio signal, they will have to say "a large electronic noise" or "qukkkkkkkkk". What if we can "see" audio signal in frequency domain? There is no need to use "large electronic noise" or "qukkkkkkk" anymore, instead, we can say "there is an unexpected audio tone that consists of xxxxxxxxxx". This detailed information will be more helpful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yuzhang wrote:
... recording audio signals from a portable radio's speaker, time stamp them and store them in on-board memory.
The memory usage could be considerable; will likely need compression. Some open software codecs: Speex, CELT, Opus; quality levels for each are telephone, speech, music (some or a lot of music).
CELT and Opus do frequency domain computation. These codecs run on a lot of 32-bit MCUs, some 16-bit MCUs, and PCs. Frame duration can be a fixed (or variable) time duration so may be able to (or modified to) store absolute time within a frame or use relative time if handle missing frames. These are lossy codecs but the loss may be acceptable.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you gchapman. I will remember your suggestions.