Lowcost DSP for beginner

[glatocha]

Hi,

I am thinking of the multichannel measurement system and would like to have possibility in the future to do some basic signal analysis/statistic etc.
As I am familiar with PIC uC then dsPIC caught my attention. Advantages are the free of charge MPLABX and XC16 compiler and I have the PICKIT3 for programming.
I am wondering what other manufacturers offer this kind of DSP that are so close to standard microcontrollers.

[jahonen]

TI C2000- and Freescale 56F8xx-series comes into mind.

Regards,
Janne

[nctnico]

Just use an ARM controller. I used DSPs in the past but nowadays I always use an ARM (from NXP to be more specific) controller for signal processing applications. Most ARM controllers have interfaces which can talk to a codec directly through an SSI interface.

[TheDirty]

I don't have much experience with DSP's, but the Cortex-M4 ARM's have DSP extensions.  If you want cheap, you can just go with TI's Tiva (used to be Stellaris) launchpad board or the STM32F4 Discovery board.  Both have CM4F cores.

[codeboy2k]

The line is blurring between today's very capable MCUs and what is a true DSP.

Basically, someone says they want a DSP because they are doing lots of "signal processing stuff" but truth is that they often don't need a full-on DSP for basic signal processing.  Only when it gets more advanced then this will they need a real dedicated DSP, and here's why:

a DSP has an accumulator that is designed around multiply-accumulate, because filters are mostly a continuous application of high-order polynomials. The accumulator has guard bits, so that it doesn't lose precision, and the final result can be truncated without much loss of precision.  A DSP operating in real-time is more efficient with a Harvard architecture (but it's not needed for non-realtime signal processing, so MCUs do ok here).  DSP's have fractional number representation internally, and you can operate on fractional numbers directly, and the registers and instruction set understand fractional numbers, -1.0 < Rx < 1.0.  This is because a filter's coefficients are already fractional numbers and the results will also be fractional numbers as it accumulates. DSPs can do parallel fetch while calculating a result.. and DSPs can often do all of this in just a few specialized instructions.

Now, the ARM Cortex-M4 has some DSP extensions, such as a single cycle MAC. This may make it operate faster doing some "DSPish" things, but it may fall short if you want to do DSP in real time on the incoming datastream from your multichannel measurement system.

Finally, a DSP makes programming a filter so easy

the basic FIR filter is



Which is just a series of multiply and accumate, and can often be done in just a few instructions on a DSP, which might take several instructions on a non-DSP.  The DSP can parallel fetch the next x value and the b coefficient while calculating and accumulating y[n]

So.. just some food for thought, to help you decide if you need a real DSP or if a modern MCU with DSP extensions will be good enough for your needs.

[gocemk]

The line is blurring between today's very capable MCUs and what is a true DSP.

Basically, someone says they want a DSP because they are doing lots of "signal processing stuff" but truth is that they often don't need a full-on DSP for basic signal processing.  Only when it gets more advanced then this will they need a real dedicated DSP, and here's why:

a DSP has an accumulator that is designed around multiply-accumulate, because filters are mostly a continuous application of high-order polynomials. The accumulator has guard bits, so that it doesn't lose precision, and the final result can be truncated without much loss of precision.  A DSP operating in real-time is more efficient with a Harvard architecture (but it's not needed for non-realtime signal processing, so MCUs do ok here).  DSP's have fractional number representation internally, and you can operate on fractional numbers directly, and the registers and instruction set understand fractional numbers, -1.0 < Rx < 1.0.  This is because a filter's coefficients are already fractional numbers and the results will also be fractional numbers as it accumulates. DSPs can do parallel fetch while calculating a result.. and DSPs can often do all of this in just a few specialized instructions.

Now, the ARM Cortex-M4 has some DSP extensions, such as a single cycle MAC. This may make it operate faster doing some "DSPish" things, but it may fall short if you want to do DSP in real time on the incoming datastream from your multichannel measurement system.

Finally, a DSP makes programming a filter so easy

the basic FIR filter is



Which is just a series of multiply and accumate, and can often be done in just a few instructions on a DSP, which might take several instructions on a non-DSP.  The DSP can parallel fetch the next x value and the b coefficient while calculating and accumulating y[n]

So.. just some food for thought, to help you decide if you need a real DSP or if a modern MCU with DSP extensions will be good enough for your needs.

Hi,

In your opinion (and experience) how does the 16bit core dsPIC30/33F compare against the PIC32 or ARM Cortex for DSP applications? There are a few interesting findings on the net for this one, some are in favor on dsPICs, others are in favor of the 32bit MCU's.

Thanks.

[NiHaoMike]

Out of the choices you gave, ARM is the way to go for sheer power. The Raspberry Pi is very hard to beat at its price.

[TheDirty]

The line is blurring between today's very capable MCUs and what is a true DSP.

Thanks for that great post.  Too bad there's no Thank button on this forum.

[glatocha]

For some reasons, not sure actually why. I would like to stay as far as possible from ARM if not needed.
Probably will go with dsPIC. As I wrote, the XC is free, the MPLAB X I know already. And I am generally familiar with Microchip way.

[Rasz]

Out of the choices you gave, ARM is the way to go for sheer power. The Raspberry Pi is very hard to beat at its price.

lol no, we are talking DSP here, this is Linear algebra. You need vector coprocessor at the very least

[Harvs]

Then you don't know what you're missing.  The low cost stm32f4 disco board, and I'm sure nxp has something similar, are awesome.

Yes there's a bit of learning to be done, but it won't be a waste of time, and with a gnu tool chain you won't get much cheaper.

[NiHaoMike]

Out of the choices you gave, ARM is the way to go for sheer power. The Raspberry Pi is very hard to beat at its price.

lol no, we are talking DSP here, this is Linear algebra. You need vector coprocessor at the very least

The Raspberry Pi actually does have a video centric DSP. But even without it, 700MHz of ARM will outpace any dsPIC very easily. If you want a proper general purpose DSP, some OMAPs (and probably numerous other SoCs) have it, but they are obviously more expensive than the Pi.

The dsPIC is a great choice where a Pi is overkill. So is the C2000, but in my experience, TI's CCS just isn't as good quality as MPLABX.

[glatocha]

One day 32bit come to me also. But almost surely will be again microchip with PIC32 and the PICKIT dev board.
ARM has so many core types, so many manufacturers. I know it is an advantage, but just can't find the motivation to dig into it.

[nctnico]

For some reasons, not sure actually why. I would like to stay as far as possible from ARM if not needed.
Probably will go with dsPIC. As I wrote, the XC is free, the MPLAB X I know already. And I am generally familiar with Microchip way.

All the ARM tools you need are completely free and there are tons of tutorials out there. Staying away from ARM is like saying you prefer a horse & carriage over a modern car. Just get a board with an ARM from NXP or ST. I don't know about ST but NXP's peripherals are 99.9% identical across their entire range of ARM7 and ARM Cortex devices. So a single investment in time gets you low cost / low power or high performance in a single solution. No need to learn completely different architectures.

[Rasz]

Out of the choices you gave, ARM is the way to go for sheer power. The Raspberry Pi is very hard to beat at its price.

lol no, we are talking DSP here, this is Linear algebra. You need vector coprocessor at the very least

The Raspberry Pi actually does have a video centric DSP.

No it doesnt. It has closed source GFX core (with general computing capabilities inside) you WONT be able to use, EVER. Binary blob, no documentation, NDAs up the ass(if you are as big as Nokia) and Broadcom at the helm.
Afaik Nokia is the only company writing own code for VideoCore line of processors (PureView).

But even without it, 700MHz of ARM will outpace any dsPIC very easily.

dsPIC  is not exactly a DSP processor. Its not hard to outpace 70mips cpu with no hardware FP. My $20 router does that too, but I wouldnt recommend it to anyone interested in DSP.

[rsjsouza]

would like to have possibility in the future to do some basic signal analysis/statistic etc.

Others already mentioned true DSPs, and I would recommend that for the bolded statement above. If your signal analysis will involve operations in the frequency domain, ARM processors won't be as quick as DSPs when FFTs are involved.

Cost of development is pretty low these days irrespective of the platform of choice. I am familiar with the C2000 and you could start really cheap with a Launchpad and a free copy of Code Composer Studio IDE. If you prefer command-line development they have unlimited compilers available for download.

[SolarSunrise]

Low cost STM32F4 (The development board costs 15$ - bargain) can execute multiply & accumulate instruction in a single cycle. Since it has a speed of 164Mhz, It can execute multiply & accumulate instruction 164 million times/second, which is very fast.
However, any microcontroller with DSP will work, STM32F4 is just my personal choice.

[Harvs]

Low cost STM32F4 (The development board costs 15$ - bargain) can execute multiply & accumulate instruction in a single cycle. Since it has a speed of 164Mhz, It can execute multiply & accumulate instruction 164 million times/second, which is very fast.
However, any microcontroller with DSP will work, STM32F4 is just my personal choice.

While I also highly regard this uC.  That's not quite true in practice.

The STM32F3/4 training slides have loads of info on this (lots of bench marking.)  Because of a true DSPs pre-fetch capabilities, in terms of clock cycles it can approach 1 cycle per mul-acc on a FIR filter.  Where as the M4F still needs to spend cycles getting the data out of RAM into the working register set, so their hand optimized assembly was in the order of 6 cycles per mul-acc.

Still far from bad, but it does show how the true DSPs and optimised for this task.

Now the M4F does have truckloads of awesome other features that could make it a better choice where pure DSP capabilities aren't everything.

[westfw]

ARM processors won't be as quick as DSPs when FFTs are involved.

Why not?  What are they missing?  And since the things labeled "DSP" range from that 16bit dsPIC with no floating point to chips that cost $100+ each, perhaps you should qualify "DSP" further as well.

Where as the M4F still needs to spend cycles getting the data out of RAM into the working register set

THAT for instance, is a useful statement!

TI has some low cost DSP eval boards, like this one: http://www.ti.com/tool/tmdx5505ezdsp
But that's a 200MIPS fixed point DSP, so I don't know how it would compare against an RPI or BeagleBone.

[rsjsouza]

Why not?  What are they missing?  And since the things labeled "DSP" range from that 16bit dsPIC with no floating point to chips that cost $100+ each, perhaps you should qualify "DSP" further as well.

Multiply-and-accumulate (MAC) is not the only thing needed for signal processing. True DSPs also have special addressing modes (circular, bit-reversed) that allow algorithms to fetch data in peculiar ways without requiring conditional control code - thus reducing the number of cycles required at each iteration of a typical loop. These addressing modes speed up filters, FFTs and DFTs. Quick google search returns good articles on this subject. Check here and here.

But that's a 200MIPS fixed point DSP, so I don't know how it would compare against an RPI or BeagleBone.

Due to the reasons mentioned above, these processors target different applications. Don't expect a DSP to shine when performing intensive control code (lots of if-then-else or branches); likewise, don't expect a general purpose processor to shine when performing signal processing applications. Both can do anything, but they will be much less efficient on the tasks they are not designed for.

Beware when you are promised processors that will do everything perfectly or, to say a typical marketing jargon, "optimized" - in other words, ARM processors are good for several applications but are not perfectly tailored for everything.

[snoopy]

Here's a good start for you. TMS320F28335 150MHz 32 bit floating point DSP ready to go development board with breakout connectors etc all for $89

http://www.ebay.com/itm/TMS320F28335PGFA-package-176-LQFP-Development-board-TI-DSP-/151032371516?pt=LH_DefaultDomain_0&hash=item232a3b193c

Search for TMS320 on ebay and there are other boards and jtag emulators to suit

Forget about dsPic. It is a toy and you will soon run out of clock cycles if you are doing serious audio processing

regards
david

[nctnico]

IMHO that TMS320F28335 is extremely expensive compared to an LPC4076FBD144 from NXP (according to the prices from Digikey). The LPC4076FBD144 is a 120MHz Cortex M4 controller with FPU and DSP/SIMD extensions (http://www.arm.com/products/processors/technologies/dsp-simd.php). If the 120MHz Cortex isn't enough then NXP also offers a 200MHz dual core (M4 and M0) for less money than the TMS320F28335. I stand by what I already typed before: unless you need really brutal processing power going for an ARM based controller is the best option. The C2000 may be nice but the community support is nowhere near as extensive as it is for ARM. If you need a highly optimised algorithm you stand a better chance finding one for ARM than C2000 unless you want to pay $$$.

[Harvs]

NXP also offers a 200MHz dual core (M4 and M0)

I know this is totally off topic, but has anyone used these?  Any good?

[snoopy]

IMHO that TMS320F28335 is extremely expensive compared to an LPC4076FBD144 from NXP (according to the prices from Digikey). The LPC4076FBD144 is a 120MHz Cortex M4 controller with FPU and DSP/SIMD extensions (http://www.arm.com/products/processors/technologies/dsp-simd.php). If the 120MHz Cortex isn't enough then NXP also offers a 200MHz dual core (M4 and M0) for less money than the TMS320F28335. I stand by what I already typed before: unless you need really brutal processing power going for an ARM based controller is the best option. The C2000 may be nice but the community support is nowhere near as extensive as it is for ARM. If you need a highly optimised algorithm you stand a better chance finding one for ARM than C2000 unless you want to pay $$$.

The trouble is the NXP M4's have configurable IO and are a nightmare to configure just to handle I2S. There was a discussion about this on diyaudio a while ago and it appeared to be very difficult to use

It's one thing having hardware that can do everything but it's another having a decent tool set to back it up

regards

[nctnico]

That is hardly an argument. Nowadays every microcontroller has multifuction I/O pins which need to be setup. You have to invest time to learn how it works but if you read the manual it is pretty simple. In NXP's user manuals each chapter describing a peripheral starts with describing how to setup the clock, power management and I/O pins and provides links to the appropriate registers settings. I've seen far worse.

[snoopy]

That is hardly an argument. Nowadays every microcontroller has multifuction I/O pins which need to be setup. You have to invest time to learn how it works but if you read the manual it is pretty simple. In NXP's user manuals each chapter describing a peripheral starts with describing how to setup the clock, power management and I/O pins and provides links to the appropriate registers settings. I've seen far worse.

I believe the peripherals don't exist unless you configure them in the SGPIO. Whilst it adds more flexibility to the hardware it also adds more complexity

Serial GPIO (SGPIO)
Combining general-purpose I/O with a timer/shift register, our SGPIO can be used to create or
capture multiple real-time serial data streams. There’s no need for code loops that manipulate
GPIO in real time, or CPU-intensive “bit banging”. For added convenience, SGPIO can also be
configured as extra serial interfaces (UART, I2S, I2C, etc.).

[TheDirty]

I believe the peripherals don't exist unless you configure them in the SGPIO. Whilst it adds more flexibility to the hardware it also adds more complexity

Serial GPIO (SGPIO)
Combining general-purpose I/O with a timer/shift register, our SGPIO can be used to create or
capture multiple real-time serial data streams. There’s no need for code loops that manipulate
GPIO in real time, or CPU-intensive “bit banging”. For added convenience, SGPIO can also be
configured as extra serial interfaces (UART, I2S, I2C, etc.).

That's the case with the 4300 series.  They 4000 series has standard already assigned multifunction IO.

The new M800 has the Switch Matrix functionality as well to assign peripherals to pins.  I'm really looking forward to it.  Wish they would get the chips out to retailers.

[Feynman]

The line is blurring between today's very capable MCUs and what is a true DSP.

That's true. But you can devide controllers in three categories: Pure DSPs (e.g. Analog's SHARC), pure Micro Controllers (PIC, Atmel, ...) and "Signal Controllers" that combine both worlds (e.g. dsPIC, TI's C2000, Analog's Blackfin, ...).

[nctnico]

The whole DSP versus microcontroller discussion assumes that a microcontroller isn't suitable for digital signal processing at all. Ofcourse such an assumption is total and utter crap. You can use any microcontroller for signal processing as long as it has enough processing power for the job at hand.

[westfw]

So, from a PROGRAMMING perspective, are the features you get from something like the ARM CM4 DSP extensions (MAC, saturated math, etc) pretty much the same features that you'd get on a "purer" DSP architecture?  (neglecting that the load/store architecture of isn't ideal for dealing with big arrays of data in RAM...)

[nctnico]

The big question is: do you really need those features? Does it pay off to indulge yourself in a proprietary solution with a limited scope?
Besides that the ARM SIMD extensions offer the same features a typical DSP does. When people think about signal processing some immediately jump to the conclusion they need a DSP. Why is that? Is a microcontroller really too slow? Can't a microcontroller multiply or do other calculations? Its like saying 'I need a red car to go to the shopping mall'. It doesn't make any sense. What is wrong with a blue, yellow, white or black car?

[thekhakinator]

I'd avoid the dsPIC, at least the dsPIC33FJ64GP802/804. The sheer number of threads I've read concerning the noise of the DAC and other issues with that chip, all with no solutions... and my own personal experience. It's a shame because it's very easy to work with, C on the dsPIC is really great.

[glatocha]

Can you maybe link to some article about this DAC issue?
Is the DAC the only of your concerns? I am rather focusing on the ADC functionality.

[poorchava]

dsPIC33Fs are actually quite nice, and offer quite a lot of processing power (but less than any given Cortex-M4). Unfortunatelly they suffer from all sorts of "Microchip-nesses" such as shitloads of silicon bugs, shitty compiler and bad libraries. And on top of that they are in the same price range as ARM stuff.

[thekhakinator]

No articles as such but a forum post with links to many others.

http://www.microchip.com/forums/tm.aspx?high=&m=479331&mpage=1#482151

In that thread is a user saying the DAC is usable. Everyone else has just thrown their arms in the air and given up. :/

The ADC, however, has been nice enough in my experience. I initially considered it noisy but that turned out to be the DAC, not ADC.

[poorchava]

Good that dspic33's have better ADC than pic 18... 13LSB of error wasn't that uncommon (as I have found out the painful way) which made it pretty useless...

[glatocha]

what you mean 13lsb error? They have only 12 max I think

I am fighting now with the ADC, measuring battery voltage and having 2.4-2.9V.
Not sure what can be a problem of it. I need to check other voltage sources.

[nuhamind2]

what you mean 13lsb error? They have only 12 max I think

I am fighting now with the ADC, measuring battery voltage and having 2.4-2.9V.
Not sure what can be a problem of it. I need to check other voltage sources.

12 bit ADC mean 4096 count.13 LSB mean your reading might have error by +13 count.
If i understand correctly

[nctnico]

That is right. The error is >0.3%. From the 12 bits you have only 8.3 usefull bits. Microchip really sucks at analog stuff. Their ADCs and DACs are really cheap but the accuracy is far worse than competing devices from Analog or TI/National.

[glatocha]

wish I could have my front-end so good that 0.3% will be an issue for me

[thekhakinator]

wish I could have my front-end so good that 0.3% will be an issue for me

Haha, I hear that mate.

Yeah, in my very limited experience, I am not at all impressed by Microchip's analog parts...

[gregariz]

dsPIC33Fs are actually quite nice, and offer quite a lot of processing power (but less than any given Cortex-M4). Unfortunatelly they suffer from all sorts of "Microchip-nesses" such as shitloads of silicon bugs, shitty compiler and bad libraries. And on top of that they are in the same price range as ARM stuff.

I agree.... we need to remember that the dsPIC is quite fine for lower end applications such as signal conditioning and basic low bandwidth software radio's. Its quite capable for example of taking a 6KBPS sample, demoding it and filtering it using an fft. Of course its a relatively small fft. So thats the kind of app you should be thinking about for them. They are not complete toys and do integrate things like I2S for codec comms which some of the plain vanilla CPU's dont. I generally view them as better than an NXP LPC ARM7.

On the other hand if you want to crunch 50MBPS data you wont get by with a dsPIC, you'll need something like a TMS320C.

You can do similar things on an ARM of course ie ARM9/11 and above. This is what we currently do at my work. The only caveat I would add though is that while general purpose processors can often provide decent CPU performance we've found we need some fairly high current consumptions to get the performance we need because they are working hard (generally clocked alot higher for starters). This will be a real issue in future as customers complain about battery life.

The other alternative of course is to implement an algorithm in a FPGA using VHDL or Verilog. This is something we used to do as well but again, power is an issue. The Xilinx part we used was so hot it was untouchable. (some of the ARMS (OMAPS) we've used were similiar)

With regard to compilers, my personal opinion is that none of the chip makers produce decent compilers. I use a third part compiler for the the dSPIC. MPLAB works but IMO just takes too long to get things up and going, has poor documentation and support. I use CCS for that chip. Similar story with the ARM. Of course for the FPGA's there are no real 3rd party alternatives for development tools so you are kind of stuck (and screwed) with regard to environments. I generally prefer to avoid FPGA's for this reason, plus cost and power concerns. Compilers are one thing I will fairly happily shell out dollars to buy - and often play a part in the final choice of device.

Edit: I'll add one last thing - maybe a plus for an arm. I'm currently working on a radio that will use linux as an OS. As soon as you want something like that (ie connected to the internet, running servers and can be reconfigured) the ARM is the only way to go.

[legacy]

the problem of dsPIC3* is ... you have to deal with "fractional" number
fractional is a sort of fixed point format, i do not like it very much.

[embeddedbob]

IMHO: Theres DSP, then theres implementing DSP algorithms. The former is mathematical manipulation of samples of a signal, the latter is knowing the language and architecture of the hardware. So you can implement DSP algorithms on a PIC16 if it can meet the realtime demands/rates.

dsPIC are marketed as digital signal controllers and are capable of doing a fair amount. Im using one on an automotive project because I cant find a M3 Cortex based processor with extended temperature (-40 to 150) so they have their uses, like most MCUs.

TBH, if you have many channels, Id use a cheap FPGA (spartan 3/6) and make sure theres higher capacity devices in the same config/footprint. This is how most multi-channel measurement systems are implemented. ADC and DACs cost though so the solution will be more expensive than say an ST cortex M4. I havent read the full thread (hence the edit ) but if you know the number of channels and rates, that will normally push you in a direction (E.g. AD-DA + FPGA, AD-DA + CPLD + MCU, Onboard AD-DA MCU).

[legacy]

Anybody using Blackfin BF537 DSP ?

[thekhakinator]

In fairness there is reason why the dsPIC I was complaining about has issues - it's SNR is 61dB for a 16 bit stereo DAC? XD
http://www.grav-corp.com/?p=87

[NiHaoMike]

There are a lot of uses for low definition audio.

[thekhakinator]

There are a lot of uses for low definition audio.

Granted, just amusing they'd use a 16-bit stereo DAC with such high noise.

[nctnico]

There are a lot of uses for low definition audio.

61dB doesn't even cut it for a digital telephone line which has 84dB dynamic range. So what is low definition audio?

[snoopy]

Anybody using Blackfin BF537 DSP ?

I am using a SHARC dsp but have looked at the Blackfin as well. SHARC has floating point DSP capabilities and the Blackfin doesn't. I have a Blackfin BF533 EZlite board and it is a good starting point because you don't need the expensive AD ICE to use it. There are eval boards for the BF537 as well. AD tools and support hardware are expensive but they WORK WELL and worth it in the end !! Also their support community and engineering forum is excellent and even if you have a problem of your own making you can still bounce ideas off them and nut it out.

At the end of the day it's not only the silicon that counts but the support for it that counts just as much !!

regards
dave

[legacy]

do you use fixed point math with blackfin ?

[snoopy]

do you use fixed point math with blackfin ?

Yes I used fixed point arithmetic. You can do floating point arithmetic but it's not very efficient.

regards

[legacy]

what fixedpoint library have you used ?

also 32bit ? 64bit ?

[nctnico]

Why would you need a library? Fixed point is just a matter of choosing a multiplication ratio for shifting the 'point'.

So if you want to multiply by 0.5 and choose the multiplier at 32768 then the calculation is:
a= (a *  16384) / 32768

[legacy]

because in the real word it is not so easy, you need to consider a lot things about fixedpoint math, Microchip has introduced a dedicated hw and library to handle it (dsPIC3* -> fractional engine), also i'd like to have 64 bit of fixed point in order to have a better precision and to avoid precision lost.

[legacy]

I mean, with 32 bit, this is not enough

Code: [Select]

/*
 *  fx2804
 *  ===================
 *  integer    28 bits
 *  fractional  4 bits
 */

#define itofx2804(x)    (fixedpoint_t) (((fixedpoint_t) x) << 4)
#define ftofx2804(x)    (fixedpoint_t) (((float) x) * (16))
#define dtofx2804(x)    (fixedpoint_t) (((double) x) * (16))
#define fx2804toi(x)    (signed long)  ((fixedpoint_t) x) >> 4)
#define fx2804tof(x)    (float)        (((fixedpoint_t) x) / (16))
#define fx2804tod(x)    (double)       (((fixedpoint_t) x) / (16))
#define mulfx2804(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (4))
#define divfx2804(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (4)) / ((fixedpoint_t) y))
#define fx2804_get_n(x) (fixedpoint_t) (((fixedpoint_t) x) >> 4)
#define fx2804_get_d(x) (fixedpoint_t) (( 1 *((fixedpoint_t) x & (0xf) )) >> 4)

/*
 *  fx2408
 *  ===================
 *  integer    24 bits
 *  fractional  8 bits
 */

#define itofx2408(x)    (fixedpoint_t) (((fixedpoint_t) x) << 8)
#define ftofx2408(x)    (fixedpoint_t) (((float) x) * (256))
#define dtofx2408(x)    (fixedpoint_t) (((double) x) * (256))
#define fx2408toi(x)    (signed long)  ((fixedpoint_t) x) >> 8)
#define fx2408tof(x)    (float)        (((fixedpoint_t) x) / (256))
#define fx2408tod(x)    (double)       (((fixedpoint_t) x) / (256))
#define mulfx2408(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (8))
#define divfx2408(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (8)) / ((fixedpoint_t) y))
#define fx2408_get_n(x) (fixedpoint_t) (((fixedpoint_t) x) >> 8)
#define fx2408_get_d(x) (fixedpoint_t) (( 100 *((fixedpoint_t) x & (0xff) )) >> 8)

/*
 *  fx2012
 *  ===================
 *  integer    20 bits
 *  fractional 12 bits
 */

#define itofx2012(x)    (fixedpoint_t) (((fixedpoint_t) x) << 12)
#define ftofx2012(x)    (fixedpoint_t) (((float) x) * (4096))
#define dtofx2012(x)    (fixedpoint_t) (((double) x) * (4096))
#define fx2012toi(x)    (signed long)  ((fixedpoint_t) x) >> 12)
#define fx2012tof(x)    (float)        (((fixedpoint_t) x) / (4096))
#define fx2012tod(x)    (double)       (((fixedpoint_t) x) / (4096))
#define mulfx2012(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (12))
#define divfx2012(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (12)) / ((fixedpoint_t) y))
#define fx2012_get_n(x) (fixedpoint_t) (((fixedpoint_t) x) >> 12)
#define fx2012_get_d(x) (fixedpoint_t) (( 10000 *((fixedpoint_t) x & (0xfff) )) >> 12)

/*
 *  fx1616
 *  ===================
 *  integer    16 bits
 *  fractional 16 bits
 */

#define itofx1616(x)    (fixedpoint_t) (((fixedpoint_t) x) << 16)
#define ftofx1616(x)    (fixedpoint_t) (((float) x) * (65536))
#define dtofx1616(x)    (fixedpoint_t) (((double) x) * (65536))
#define fx1616toi(x)    (signed long)  ((fixedpoint_t) x) >> 16)
#define fx1616tof(x)    (float)        (((fixedpoint_t) x) / (65536))
#define fx1616tod(x)    (double)       (((fixedpoint_t) x) / (65536))
#define mulfx1616(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (16))
#define divfx1616(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (16)) / ((fixedpoint_t) y))
#define fx1616_get_n(x) (fixedpoint_t) (((fixedpoint_t) x) >> 16)
#define fx1616_get_d(x) (fixedpoint_t) (( 1000000 *((fixedpoint_t) x & (0xffff) )) >> 16)

/*
 *  fx1220
 *  ===================
 *  integer    12 bits
 *  fractional 20 bits
 */

#define itofx1220(x)    (fixedpoint_t) (((fixedpoint_t) x) << 20)
#define ftofx1220(x)    (fixedpoint_t) (((float) x) * (1048576))
#define dtofx1220(x)    (fixedpoint_t) (((double) x) * (1048576))
#define fx1220toi(x)    (signed long)  ((fixedpoint_t) x) >> 20)
#define fx1220tof(x)    (float)        (((fixedpoint_t) x) / (1048576))
#define fx1220tod(x)    (double)       (((fixedpoint_t) x) / (1048576))
#define mulfx1220(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (20))
#define divfx1220(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (20)) / ((fixedpoint_t) y))
#define fx1220_get_n(x) (fixedpoint_t) (((fixedpoint_t) x) >> 20)
#define fx1220_get_d(x) (fixedpoint_t) (( 100000000 *((fixedpoint_t) x & (0xfffff) )) >> 20)


[legacy]

Code: [Select]

void eval_pi_float()
{
    fp64_t   sign;
    fp64_t   i, pi;
    uint32_t iteractions;

    iteractions = 20000;
    sign = -1;

    printf("[*] fp64 computing pi with %ld iteractions\n", iteractions);
    pi = 0;
    for (i = 1; i < iteractions; i += 2)
    {
        sign = -1 * sign;
        pi  += 4 * (sign / i);
    }
    printf("pi is equal to ");
    printf("%f ", pi);
    printf("\n");
}


Code: [Select]

void eval_pi_fx1616()
{
    sint32_t     sign;
    fixedpoint_t i, pi;
    uint32_t     iteractions;

    iteractions = 20000;
    sign = -1;

    printf("[*] fixed_point fx16.16 computing pi with %ld iteractions\n", iteractions);
    pi = 0;
    for (i = 1; i < iteractions; i += 2)
    {
        sign = -1 * sign;
        if (sign > 0)
        {
            pi = pi + (4 * divfx1616(1, i));
        }
        else
        {
            pi = pi - (4 * divfx1616(1, i));
        }
    }
    printf("pi is equal to ");
    printffx1616(pi);
    printf("\n");
}


fp64 computing pi with 20000 iteractions
pi is equal to 3.141493

fixed_point fx16.16 computing pi with 20000 iteractions
pi is equal to  3.1411

fixed_point fx24.08 computing pi with 20000 iteractions
pi is equal to  3.10

fixed_point fx12.20 computing pi with 20000 iteractions
pi is equal to  3.1309

math engine	evaluated pi
fp64	3.141493
fx16.16	3.1411
fx24.08	3.10
fx12.20	3.1309

[legacy]

Code: [Select]

void eval_pi_i64()
{
    char     result[100];
    sint32_t sign;
    uint32_t i;
    bigint_t pi;
    bigint_t remainder;
    bigint_t quotient;
    bigint_t dividend;
    bigint_t divisor;
    bigint_t scale;
    bigint_t one;
    uint32_t iteractions;

    iteractions = steps;

    printf("[*] i64 computing pi with %ld iteractions\n", iteractions);
    pi       = i64_atoi("0");
    one      = i64_atoi("1");
    dividend = i64_atoi("4");
    divisor  = i64_atoi("1");
    scale    = i64_atoi("10000000");

    dividend = i64_mul(dividend, scale);

    sign        = -1;

    for (i = 1; i < iteractions; i += 2)
    {
        sign = -1 * sign;
        i64_div(dividend, divisor, &quotient, &remainder);
        if (sign > 0)
        {
            pi = i64_add(pi, quotient);
        }
        else
        {
            pi = i64_sub(pi, quotient);
        }
        i64_itoa(quotient, result, sizeof(result) - 1);
        i64_itoa(pi, result, sizeof(result) - 1);

        divisor = i64_add(divisor, one);
        divisor = i64_add(divisor, one);
    }
    i64_itoa(pi, result, sizeof(result) - 1);
    printf("with a scale of %lu ", scale);
    printf("pi is equal to %s\n", result);
}

i64 computing pi with 20000 iteractions
with a scale of  10000000, pi is equal to 31414944

31414944 / 10000000 = 3.1414944





the difference between float (fp32_t) and double (fp64_t)

float fp32 computing pi with 20000 iteractions
pi is equal to 3.141499

float fp64 computing pi with 20000 iteractions
pi is equal to 3.141493





Final report

math engine	evaluated pi
fp32	3.141499
fp64	3.141493
fx16.16	3.1411
fx24.08	3.10
fx12.20	3.1309
fx.i64	3.1414944

[snoopy]

Why would you need a library? Fixed point is just a matter of choosing a multiplication ratio for shifting the 'point'.

So if you want to multiply by 0.5 and choose the multiplier at 32768 then the calculation is:
a= (a *  16384) / 32768

because fixed fractional numbers are not a standard type in C or C++. They may be supported by the hardware and accessible using assembly language but this doesn't help people writing efficient dsp code in C or C++. Analog devices Visual DSP now supports the fract type in C++

regards

[legacy]

Exactly. Fractional is a particular kind of fixed point, it is Q(1,N-1) and this means it needs a lot of renormalization during calculations, this is done by the special library provided, also C++ is able to "overload" math operators (+,-.*./,%).

To avoid precision lost you need to perform fixedpoint with 64bit at least.

Both of these means: a bit of homeworks you have to write and test by your own if there is no support provided.

[andersm]

Fixed-point math was proposed for C11 as part of TR 18037 (extensions to support embedded processors), but did not make it into this revision of the standard. If your target uses a reasonably modern version of GCC (from ca. 2008 or newer) it can probably generate code for fixed-point math, but library support may be missing.

Quickly testing Microchip's XC32 compiler, it will take advantage of the MIPS DSP extensions if they are enabled. It also appears to have full library support via Dinkumware's libraries.

[snoopy]

Exactly. Fractional is a particular kind of fixed point, it is Q(1,N-1) and this means it needs a lot of renormalization during calculations, this is done by the special library provided, also C++ is able to "overload" math operators (+,-.*./,%).

To avoid precision lost you need to perform fixedpoint with 64bit at least.

Both of these means: a bit of homeworks you have to write and test by your own if there is no support provided.

best to use a micro or dsp that provides native support for fixed point numbers otherwise you will waste a lot of clock cycles emulating it.

regards

[legacy]

the problem is ... what happens if you have not.

[nctnico]

Exactly. Fractional is a particular kind of fixed point, it is Q(1,N-1) and this means it needs a lot of renormalization during calculations, this is done by the special library provided, also C++ is able to "overload" math operators (+,-.*./,%).

To avoid precision lost you need to perform fixedpoint with 64bit at least.

Both of these means: a bit of homeworks you have to write and test by your own if there is no support provided.

best to use a micro or dsp that provides native support for fixed point numbers otherwise you will waste a lot of clock cycles emulating it.

regards

A multiplication or divide by a power of 2 is just a barrel shift. I use fixed point math all the time but never had performance issues.

[snoopy]

the problem is ... what happens if you have not.

then its is not suitable as a dsp.

[nctnico]

the problem is ... what happens if you have not.

then its is not suitable as a dsp.

Thats total crap and you know it!

[snoopy]

the problem is ... what happens if you have not.

then its is not suitable as a dsp.

Thats total crap and you know it!

so how many compares, shifts and adds does it take to multiply a 24 bit fixed point number by another 24 bit fixed point number  ?

and that's only for a single multiply !!

wait till you start implementing a dozen or so biquads at say 96 KHz !! Throw in a 200 tap FIR filter as well !!

you obviously have never done any serious dsp work.

regards

[nctnico]

You obviously have no idea what fixed point is about. Fixed point is no more than a number multiplied by a factor to get an integer. Multiplying integers is dead easy (especially if you have a hardware multiplier). The only thing to watch out for are overflows.

[legacy]

The only thing to watch out for are overflows.

Exactly, you have to care about overflows
and precision lost -> you have to tune your software very accurately.

And THIS is the reason why i need much more than 32bits!!!!
This is the question!

[marshallh]

Hell, fpgas didn't even have floating point DSP units until the new Gen10 series from Altera was revealed weeks ago.
Fixed point is perfectly useful and much simpler/faster to work with in low level hardware. The downside is ex. for 32bits fixedpoint you get a very limited range compared to a 32bit IEEE754 floating point number. The upside is multiplies, adds, substracts can be single cycle.
I've written a MPEG audio decoder on fpga using fixed point multiplies. Takes just nanoseconds, you can clock them faster than you can route nearby logic to them!

[legacy]

Well, as you can see in the previous report i post, i need 64bit or more at least ... so i am really thinking about implementing
- add128bit
- sub128bit
- mul128bit (256bit internal register)
- div128bit (256bit internal register -> also used for modulus)
- shiftL/R 128bit
- cmp128bit
into a spartan3E, also i wandering how good can "cordic" libraries go if implemented with fixedpoint.

[legacy]

multiplies, adds, substracts can be single cycle

with 128bit multiplies should take 4 clocks to complete

[legacy]

More specifically i have to port this code to a dsp

Code: [Select]

void gps_calc()
{
    double a, b, c;

    // Degree
    a  = acos(sin(Lat1 / RADS) * sin(Lat2 / RADS) + cos(Lat1 / RADS) * cos(Lat2 / RADS) * cos((Lon1 - Lon2) / RADS));
    b  = a * Mt_Per_Rad;
    c  = acos((sin(Lat2 / RADS) - sin(Lat1 / RADS) * cos(a)) / (cos(Lat1 / RADS) * sin(a)));
    c *= RADS;

    GPS_dist = (float) b;
    GPS_ang  = (float) c;
}

Please note that the precision requested is satisfied only with floating point 64bit, so ... i need fixedpoint at 128bit at least, and ... cordic implementation of all these trigonometric functions.

Am i right ? Or should i use a "big iron" dsp (magellan, shark, ...) ?

p.s. as "chip" dsp i have got only a blackfin BF537

[nctnico]

I'd start with re-evaluating the precision especially considering the accuracy of GPS data (worst case +/-100meters). The numbers you posted earlier contained less significant numbers than the type could hold and the fixed point wasn't choosen very well. You can use a lookup table for the sine function (0 to pi/2 is sufficient if space is constrained). In think you can use 32 bit integers but you have to choose the point well. The maximum distance around the globe is 40k km which is 40 million meters. In a 32 bit integer this gives you better than 10 centimeters of resolution (integer part shifted by 5 bits / multiplied by 32).

[legacy]

Well ... the problem is related to the error propagation (rounding/truncating) about the primary evaluating values, please not they are double the precision of the final result: double a, b, c. If i use "float a,b,c" instead of "double a,b,c" i got a lot of errors in the final gps distance and angle estimation due to the trigonometic functions involved in formula.

I have also posted how pi has been calculated with fixedpoint at 32bit, what is wrong with it ?

[legacy]

i mean, is this wrong ?

Code: [Select]

/*
 *  fx1220
 *  ===================
 *  integer    12 bits
 *  fractional 20 bits
 */
#define mulfx1220(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (20))
#define divfx1220(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (20)) / ((fixedpoint_t) y))

it should be much more precise than 1616 because it has 20bit for the fractional part of PI instead of 16bit

Code: [Select]

/*
 *  fx1616
 *  ===================
 *  integer    16 bits
 *  fractional 16 bits
 */
#define mulfx1616(x,y)  (fixedpoint_t) ((((fixedpoint_t) x) * ((fixedpoint_t) y)) >> (16))
#define divfx1616(x,y)  (fixedpoint_t) (((fixedpoint_t) x << (16)) / ((fixedpoint_t) y))
/*

but if you look at the report table

fx16.16   pi=3.1411
fx12.20   pi=3.1309

you find that it is not

[jahonen]

Do you need perform millions of these GPS-calculations per second? Or why not just use software double precision floating point if it gets the job done?

Also, your formula may not be in optimal form to squeeze every bit of precision out of underlying numeric representation. It is a bit of an art, see something like Numerical Recipes in C if you haven't already done so. For example, similar "precision problem" occurs when calculating a vector length using trivial formula sqrt(x^2+y^2). It has poor utilization of the value range since it is not possible to calculate the result using double precision floating point if x or y is greater than about 1.4e154 since intermediate results will overflow unless the formula is converted to an another form. So we have wasted quite a bit of our numeric range.

Regards,
Janne

[nctnico]

Its hard to tell what goes wrong with calculating pi without knowing the internals of the library.

There is some interesting reading material here:
http://www.mathworks.nl/help/fixedpoint/examples/calculate-fixed-point-sine-and-cosine.html

[legacy]

Do you need perform millions of these GPS-calculations per second?

it should be use on a flying machine, the GPS calculation is easier than the IMU calculation which needs to be evaluate 50 times a second at least.

Or why not just use software double precision floating point if it gets the job done?

Cause my Blackfin BF537 has no fpu, i can only use softfloat to emulate double/float, also i have to evaluate the IMU &C staff.
I am not sure this  low cost DSP is good for my goal, just doing considerations due to the low cost of a tiny BF537 board sold by SoC Robotics.

Also, your formula may not be in optimal form to squeeze every bit of precision out of underlying numeric representation. It is a bit of an art, see something like Numerical Recipes in C if you haven't already done so.

I have placed a new order on Amazon, thanks for the trips 

[legacy]

Its hard to tell what goes wrong with calculating pi without knowing the internals of the library.

there is no library, i have posted everything you need about fixedpoint 32bit
- add/sub are common addiction and subtract of integer number
- fxmul/fxdiv have been provided as "C macro" (see my previous quote)
- the pi algorithm has been provided, both with the use of fixedpoint32 and float

You are missing the library of fixedpoint64bit: i haven't posted it.

[nctnico]

Do you need perform millions of these GPS-calculations per second?

it should be use on a flying machine, the GPS calculation is easier than the IMU calculation which needs to be evaluate 50 times a second at least.

Sounds like soft float will do just fine. Dunno if a Blackfin has any advantages over an ARM; ARM is more widespread. If its for controlling an airplane you might need a certified compiler and follow certain programming rules.

If I where you I implement the algorithm using (soft) float first and optimise if it is too slow.

A couple of years ago I designed an echo canceller. Since I had no idea how fast it would run on a microcontroller I just started with the (soft) floating point version and measured how long it took to process one sample. Then I measured in which part most of the time was spend. That gave me an idea where I could gain the most from optimisation efforts. It went from 1.5ms per sample to 100us per sample but some part of it is still soft floating point!

[jahonen]

Do you need perform millions of these GPS-calculations per second?

it should be use on a flying machine, the GPS calculation is easier than the IMU calculation which needs to be evaluate 50 times a second at least.

Or why not just use software double precision floating point if it gets the job done?

Cause my Blackfin BF537 has no fpu, i can only use softfloat to emulate double/float, also i have to evaluate the IMU &C staff.
I am not sure this  low cost DSP is good for my goal, just doing considerations due to the low cost of a tiny BF537 board sold by SoC Robotics.

Have you timed how long it takes to calculate using software double precision floating point, then? Using software DP FP sounds feasible if you need just few tens of calculations per second. Depending of course what else you also need to do. You can also possibly save substantial amount of computation time by calculating sin/cos values only once per function call and converting angles to radians only once.

Regards,
Janne

[senso]

Plain atmegas have been running thousands of tri,quad, octo, etc copters just fine, doing waypoint navigation, sensor fusion, inertial calcs, reading the PPM values from the RC transmitters, generating PPM for the ESC's, even data-logging and talking down to a ground station, all that in a 8bit micro running at 16Mhz with crappy Arduino libs that slow everything down.

I understand the need for better and faster, so why not a cortex M4 that has hardware FPU?

[westfw]

gps_calc()

This really needs to re-implemented using integer math SO BADLY.
The real problem is probably due to the relevant range of answers being SO much smaller than the mathematical reality of the situation...  You want better than 1km of accuracy on a circumference of 40k km.

[snoopy]

You obviously have no idea what fixed point is about. Fixed point is no more than a number multiplied by a factor to get an integer. Multiplying integers is dead easy (especially if you have a hardware multiplier). The only thing to watch out for are overflows.

fixed fraction numbers never have numbers greater than one and the multiplier does shift-right and adds instead of shift-left and adds as in an integer multiplier. Try multiplying 0.5 by 0.5 and see the results

If you your micro doesn't  have the hardware to do it quickly then how are you supposed to do it ?

[nctnico]

IMHO fixed fractions from 0..1 have very little practical use.

Anyway I'll show you how its done with integers: Shift 15 bits left (*32768) so 0.5 becomes 16384 -> 16384*16384=268.43 M Now shift the result 15 bits to the right and you get 8192. If you divide 8192 by 32768 you get 0.25 so the result is correct. If you have to add several multiplication results (like in a direct form IIR filter) the right shift can be performed on the final result so you keep maximum resolution and speed.

[Rasz]

btw this might be interesting to people wanting to start developing with DPSs

http://www.limpkin.fr/index.php?post/2013/04/26/The-whistled:-how-to-remake-a-dozen-years-old-project-the-right-way
http://www.limpkin.fr/index.php?post/2013/06/30/The-whistled%3A-from-whistle-to-sound-recognition
https://www.tindie.com/products/limpkin/the-whistled-assembled-pcb/

is based on Freescale KINETIS_K
http://www.freescale.com/webapp/sps/site/overview.jsp?code=KINETIS_K_SERIES

80 FFTs per second at $23 doesnt sound bad
+ its open hardware/software

[legacy]

Interesting, but my actual target board is based on BlackFin BF537, i have to understand if it could satisfy my constraints before opening a fork to an other target platform (e.g. cortex M4)

[snoopy]

IMHO fixed fractions from 0..1 have very little practical use.

Anyway I'll show you how its done with integers: Shift 15 bits left (*32768) so 0.5 becomes 16384 -> 16384*16384=268.43 M Now shift the result 15 bits to the right and you get 8192. If you divide 8192 by 32768 you get 0.25 so the result is correct. If you have to add several multiplication results (like in a direct form IIR filter) the right shift can be performed on the final result so you keep maximum resolution and speed.

If you use any fixed point DSP, fixed fractional arithmetic is what they support in hardware. Also when implementing IIR filters such as a biquad the coefficients are rarely just a power of two.

regards

[legacy]

Comparing Floating-Point and Fixed-Point Implementations on ADI Blackfin Processors with LabVIEW

[legacy]

If you use any fixed point DSP, fixed fractional arithmetic is what they support in hardware. Also when implementing IIR filters such as a biquad the coefficients are rarely just a power of two.

hardware tricks to support fixed fractional arithmetic in hardware: what are they exactly ? and what is the best support around ?
Microchip dsPIC has "fractional engine" in her dsPIC3x series.

[legacy]

You mean something like that implemented in hardware ?

Code: [Select]

/*
 * to add two Q31 values
 * and saturate the result to the maximum or the minimum
 * without the fixed-point arithmetic supports
 */
#define MIN_32    0x80000000
#define MAX_32    0x7fffffff

sint32_t Q31_add_sat1(sint32_t a, sint32_t b)
{
    sint32_t c;

    c = a + b;

    if (((a ^ b) & MIN_32) == 0)
    {
        if ((c ^ a) & MIN_32)
        {
            if (c < 0)
            {
                c = MIN_32;
            }
            else
            {
                c = MAX_32
            }
        }
    }
    return c;
}


[nctnico]

IMHO fixed fractions from 0..1 have very little practical use.

Anyway I'll show you how its done with integers: Shift 15 bits left (*32768) so 0.5 becomes 16384 -> 16384*16384=268.43 M Now shift the result 15 bits to the right and you get 8192. If you divide 8192 by 32768 you get 0.25 so the result is correct. If you have to add several multiplication results (like in a direct form IIR filter) the right shift can be performed on the final result so you keep maximum resolution and speed.

If you use any fixed point DSP, fixed fractional arithmetic is what they support in hardware. Also when implementing IIR filters such as a biquad the coefficients are rarely just a power of two.
regards

That doesn't matter at all. They are constant so multiply them with a factor (like 32768 from my example). Just remember 0.5 (or any fractional number) doesn't exist in the digital domain so no matter how you put it a fractional number is always multiplied by a factor (whether fixed or adjustable) to get a binary representation.

@legacy: saturated instructions are standard on many modern controllers including the ARM Cortex M4. But then again they probably have limited use. If a signal gets saturated then something gets overdriven and you get false results. I always check whether my signal processing algorithms can handle signals with maximum amplitude without clipping.

[andersm]

hardware tricks to support fixed fractional arithmetic in hardware: what are they exactly ? and what is the best support around ?
Microchip dsPIC has "fractional engine" in her dsPIC3x series.

Why not start by studying the CPU you already have.

[legacy]

work in progress 

[Paul Price]

Assuming someone has found or not found the perfect DSP for a beginner, would anyone be so brave to tell what practical application or device they managed to get working using one?

[nctnico]

First you need to define DSP. Usually this is a convoluted CPU with some peripherals to connect codecs (A/D + D/A) aimed to crunch as much numbers as possible in a given time without being easy to program.

The thing is that you don't need a DSP to do signal processing so I wouldn't start with a real DSP to do signal processing unless you need a lot of speed. IIRC my first signal processing project was to convert the analog X-Y output of my oscilloscope into serial data. That project consisted of an 68HC11 (@2MHz) and an A/D converter. Later on I programmed an ADSP2181 in asm for processing audio but that wasn't a pleasant job at all. However since audio is still confined to 20kHz (or 4kHz when it comes to phone lines) and microcontrollers have become 100 times more powerful there is no need to jump through asm hoops any more to get a project going.

[snoopy]

First you need to define DSP. Usually this is a convoluted CPU with some peripherals to connect codecs (A/D + D/A) aimed to crunch as much numbers as possible in a given time without being easy to program.

The thing is that you don't need a DSP to do signal processing so I wouldn't start with a real DSP to do signal processing unless you need a lot of speed. IIRC my first signal processing project was to convert the analog X-Y output of my oscilloscope into serial data. That project consisted of an 68HC11 (@2MHz) and an A/D converter. Later on I programmed an ADSP2181 in asm for processing audio but that wasn't a pleasant job at all. However since audio is still confined to 20kHz (or 4kHz when it comes to phone lines) and microcontrollers have become 100 times more powerful there is no need to jump through asm hoops any more to get a project going.

and DSP's usually have additional hardware to interface directly to ADC's and DAC's with serial interfaces such as I2S, left justified etc. These also have hardware to transfer data to and from the serial interface directly into memory without CPU intervention. A lot of micros such as the ARM have these features as well but these days the converse is true where a lot of DSP's such as the Blackfin have a lot of features you find on embedded micros so it's horses for courses

Yes and you are right. You don't need to use a DSP to do DSP. You could use a Z80 to do DSP as long as the sampling rate is very low

[legacy]

Again, the problem is the math support!

Supposing you can have MAC on a MPU, a low cost dsp is offering you "saturated additions" while MPU is offering you "overflowed addition", a low cost dsp is offering you "fractional engine" while MPU is offering you ... nothing more than an ALU to do dirty pretty & rude fixedpoint with a scaled integers.

[nctnico]

Again, the problem is the math support!

Supposing you can have MAC on a MPU, a low cost dsp is offering you "saturated additions" while MPU is offering you "overflowed addition", a low cost dsp is offering you "fractional engine" while MPU is offering you ... nothing more than an ALU to do dirty pretty & rude fixedpoint with a scaled integers.

You see problems which aren't there at all...

[legacy]

this book is explaining it a bit.

[nctnico]

Ofcourse the author of a book about dsPIC isn't going to write you don't need a DSP 

[legacy]

Ok, and what do you think about this book ? =P