Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

How to Select a DSP?

Status
Not open for further replies.

DigiTan

New Member
I'm trying to select a cheap DSP and ADC for a radar application.

Basically, I'm trying to use a Discrete Fourier Transform on a K-band radar echo to determine how fast the target(s) travel. The transform needs to deal with the ~1kHz to 20kHz doppler shift with a resolution of 100Hz or finer. I'm the process of requesting more data on this radar, but in case I need to reinvent the wheel, I need help homebrewing the DSP aspect.


I've had luck implimenting the DFT routine below but the recursiveness is too much for my AVRs. My question is: is there a cheap DSP that specializes in 1kHz to 20kHz DFTs? Is the ADC built in? Do I really need floating point? Basically, I'm wanting the simplest DSP that will do the job.
**broken link removed**
 
Last edited:
Have you looked at dsPICs from Microchip? Those are the simplest DSPs I have found...the rest are from TI or Freescale and are 400+ pin BGA packages.
 
Okay, that sounds like what I'm looking for. (Looking at their page just now, I see they come as small as 18 PDIP). Will those require any kind of target board for programming or there a homebrew dsPIC programmer?
 
Make sure the pdip package chips are fast enough for what you want to do.
 
DigiTan said:
Okay, that sounds like what I'm looking for. (Looking at their page just now, I see they come as small as 18 PDIP). Will those require any kind of target board for programming or there a homebrew dsPIC programmer?

What do you mean by a "target board for programming"? You mean an IC socket programmer? Or a development board?

I'll just ignore most of what you said and tell you that you can have board programmers, in-circuit programmers, some homebrew programmers.

There is the Real ICE, the ICD2 which are from Microchip. The Real ICE is an in-circuit emulator/programmer/debugger, while the ICD2 is an in-circuit programmer/debugger. Probably the best official route to go.

You can also find cheaper, less functional 3rd party versions of the ICD2 at www.sparkfun.com.

Mikroelectronika also has their own in-circuit programmer:
**broken link removed**
they also know how to build the programming circuitry right onto the PCB alongside the dsPIC. It's on their development boards but I doubt they will tell you how they did it or the software used.

And of course you can get socket programmers where you pull the IC MCU/DSP out of the board to program and then reinsert it. Microchip also has those, but they don't seem very convenient or nearly as cost effective as the Real ICE or ICD2.
 
Last edited:
Right. dsPIC is a swell line of 16-bit cores. They can do an FFT in 16-bit numbers really fast. The instruction set it just dandy, the math instructions actually support signed/unsigned int/fractional in the instructions themselves. There's a divide instruction. There's 2 40-bit accumulators. I needed an RMS of a set of 16-bit numbers, found I can square them (which makes a 32-bit number) as they're added to the accumulator (and once there's added, I need >32 bits to avoid overflow). Wow, did that in ever so few instructions!

You need an ICD2, Sparkfun.com, $100. Well, there are some other programmers which are dsPIC-capable but you really do need ICD.

I know of nothing in Sparkfun's Olimex ICD2 that is 'less functional" than the Microchip ICD2. AFAIK it is a functionally equivalent clone. The Olimex ICD2 uses the SAME firmware files that are used for the Microchip ICD2.

There's 30F and 33F series. They use the same instruction set and core resources. Here's the differences:

30F:
Has DIP pkgs
5v or 3.3v-capable at lower speeds, but won't run on 3.3v at highest speeds
Slower than the 33F (30MIPs max clock)
Can overheat at highest speed if you drive a lot of pin current and/or use all the peripherals on a small package. Actually needs a heat sink. Probably won't happen with a 40DIP, the 10mmx10mm TQFP could be in trouble if you push it

33F:
No DIP pkgs, you can get a $10 SchmartBoard to mount one
Won't run on 5v, it's 3.3v only
Low pin source/sink current
FASTER than the 30F (40MIPs @ 3.3v)
Much lower power than 33F, won't overheat at highest speed
Has a DMA controller
Maybe it's my opinion, but the 33F is somewhat buggy, mostly peripherals. Much to my dismay, Microchip is not publishing all their known bugs and it's getting to be a problem.
More RAM
No EEPROM
Low ROM write endurance, though neither I nor anyone else seems to have worn one out. Microchip said 1000x I think, but that's a very conservative minimum.

I like the 33F. Faster, lower power, and the DMA controller does some NEAT tricks! 33F128GP706 is a good general-purpose device.
 
Last edited:
What are some bugs in the 33Fs? I've been planning to use them, but still have to finish some cocurrent projects that all use 30Fs.
 
It's looks like I'm definately going with 30F or 33F's then. Maybe 30F for now, just to keep costs at a minimum. Is the Sparkfun ICD2 a definate must-have item or can I build some kind of cheap homebrew programmer. $100 is kind of a large start-up cost for just one DSP project.
 
DO you use other MCU's in your projects right now? If you get an ICD2 you could just start using Microchip PICs and dsPICs for your projects.

I *think* you can program them without the ICD2 and use a PC, but it requires some firmware bootloader or something that I really haven't bothered to look into at all.
 
Believe me, the ICD2 is nice. You need that to program 30F or 33F. It's supported by Microchip and we expect it to work with new products for quite some time. It's important that it is seamlessly integrated into MPLAB. ICD works with a lot of PIC18 products too, to varying degrees. IIRC some PIC16's, even.

It's BITCHIN fast to program with, and the $100 one from Sparkfun works through the USB port so it's generally a bit cleaner on the testbench (as well as being the source of the greater speed).

So, I rate it a "must have".

The 33F don't cost any more than the 30F. In fact they can be cheaper. The only difference this leaves is the $10 Schmartboard to mount it. (Fry's Electronics sells Schmartboards)

For starters, look at the A2 Rev Errata sheet for the 33F line. They do have stuff documented there. I discovered the FRMDLY bit on the Framed SPI module does not work. There is a bug where the SPI is supposed to tristate and "sort of" does but instead drives a fairly high impedance signal out. The CANbus peripheral has a bug where it will jump from a low priority packet to a high priority packet in mid-transmission if a high priority packet is added just then. I recall seeing one other note of a CANbus problem, I think it misidentified its NodeID.

I'm sort of dismayed that these are known, Microchip-confirmed defects, they've been around for months, but Microchip hasn't publicly documented them anywhere. I don't care so much that they happened, but failing to dilligently document them will only cause major problems for users and it's completely unnecessary.

dknguyen, what sort of project do you want to try?
 
I have one sitting around waiting to be used as a reflow toaster oven controller (overkill, but w/e, I want to calculate matrixes while the oven does it's work). Actually I chose it because I plan to use it on a custom PCB to replace the one inside some RC servos, and this was project was going to be a test run. Immediatley, I have a PCB laid out for my current robot but haven't sent it off to be made yet, some GPS, gyros, sensors, motors, stuff like that. These are all for the 30F.

I had planned to use the 33F (or a few of them as coprocessors to each other) on a balancing/vision/earhing/feeling robot which I haven't gotten to yet (2 or 3 other projects between me and it). I just wish the 30Fs had a DMA. I *hate* having to step down these silly 5V gyro analog outputs down to 3.3V to be read by the 33F, or using an SPI controlled ADC.
 
Last edited:
Most analog sensors are ratiometric and work just fine on 3.3v. Are you sure you have this problem?

Most of 33F's digital pins are "5v tolerant". That means they can accept 5v digital inputs without a problem (none of the analog pins however), and as outputs they can be put into open collector mode that can be pulled up to 5v with an external resistor. However, since 33F's pins are only rated to sink 4mA, this does present questions as to how strong you can drive an open collector output. You must choose a large resistor value to get an acceptable "low" voltage level and not exceed the max pin current rating. But a large resistor means the pull-up will be slow, particularly with a high capacitance load.
 
Last edited:
Yes, I am sure. The MEMs IC gyros are 5V absolute, while the Silicon Sensing gyros are 5V ratiometric. Stupid gyros! They have 3.3/5
3-axis accelrometers, but they barely have a 2-axis gyros and all those have the wrong voltage ratings!...Well.. the only 2-axis gyro I have seen DOES have 3.3V, but it has terrible drift compared to the 5V ones out there. There is some other 3-axis gyro/accelrometer/magnetometer in an "IC-like" block but it costs a fortune.

Digital is easy to flip back and forth. Analog is the pain in the ass when you're trying to preserve signal integrity as it is already going down the hole.
 
Last edited:
Actually the trend I'm seeing in accelerometers, pressure sensors, etc is to not only be 3.3v, but 3.3v-only. Some of the latest-and-greatest parts (at a good price, no less) won't do 5v.
 
Hasn't seemed to carry over to gyros yet. Seems to be the case with accelerometers though, but I need gyros more than accels.
 
Well, I will be working this winter break so I guess I can stand paying the $100. So as far as getting the dsPIC to perform the Discrete Fourier, are C or C++ the preferred dsPIC languages or can I also do it in assembly?
 
DigiTan said:
Well, I will be working this winter break so I guess I can stand paying the $100. So as far as getting the dsPIC to perform the Discrete Fourier, are C or C++ the preferred dsPIC languages or can I also do it in assembly?

C++ isn't really relevent to micro-controllers, and I don't think anyone wastes their time selling one?. Presumaby the dsPIC's are optimised to use C?, like the 18F series. I would have thought Fourier Transforms are well documented and easy to do?.

You might try this free book?https://www.mikroe.com/en/books/dspicbook/00.htm although it uses PIC Pascal.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top