Lowcost DSP for beginner - Page 1
Forum section: electronics / general

author: glatocha
author_rank: Regular Contributor
timestamp: May 13, 2013, 06:02:05 am
content: 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.

author: jahonen
author_rank: Super Contributor
timestamp: May 13, 2013, 06:25:59 am
content: TI C2000- and Freescale 56F8xx-series comes into mind.Regards,Janne

author: nctnico
author_rank: Super Contributor
timestamp: May 13, 2013, 07:36:35 am
content: 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.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 13, 2013, 04:25:59 pm
content: 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.

author: codeboy2k
author_rank: Super Contributor
timestamp: May 13, 2013, 06:11:39 pm
content: 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 easythe basic FIR filter isWhich 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 ySo.. 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.

author: gocemk
author_rank: Regular Contributor
timestamp: May 13, 2013, 06:52:01 pm
content: Quote from: codeboy2k on May 13, 2013, 06:11:39 pmHi,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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 14, 2013, 01:03:54 am
content: 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.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 14, 2013, 01:52:17 am
content: Quote from: codeboy2k on May 13, 2013, 06:11:39 pmThanks for that great post. Too bad there's no Thank button on this forum.

author: glatocha
author_rank: Regular Contributor
timestamp: May 14, 2013, 02:03:23 am
content: 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.

author: Rasz
author_rank: Super Contributor
timestamp: May 14, 2013, 02:32:47 am
content: Quote from: NiHaoMike on May 14, 2013, 01:03:54 amlol no, we are talking DSP here, this is Linear algebra. You need vector coprocessor at the very least

author: Harvs
author_rank: Super Contributor
timestamp: May 14, 2013, 03:29:42 am
content: 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 14, 2013, 04:59:33 am
content: Quote from: Rasz on May 14, 2013, 02:32:47 amThe 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.

author: glatocha
author_rank: Regular Contributor
timestamp: May 14, 2013, 05:01:21 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 14, 2013, 08:47:20 am
content: Quote from: glatocha on May 14, 2013, 02:03:23 amAll 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.

author: Rasz
author_rank: Super Contributor
timestamp: May 14, 2013, 02:28:16 pm
content: Quote from: NiHaoMike on May 14, 2013, 04:59:33 amNo 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).Quote from: NiHaoMike on May 14, 2013, 04:59:33 amdsPIC 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.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 14, 2013, 04:04:55 pm
content: Quote from: glatocha on May 13, 2013, 06:02:05 amOthers 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 aLaunchpadand a free copy ofCode Composer Studio IDE. If you prefer command-line development they have unlimited compilers available for download.

author: SolarSunrise
author_rank: Regular Contributor
timestamp: May 14, 2013, 07:12:49 pm
content: 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.

author: Harvs
author_rank: Super Contributor
timestamp: May 15, 2013, 01:24:42 am
content: Quote from: SolarSunrise on May 14, 2013, 07:12:49 pmWhile 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.

author: westfw
author_rank: Super Contributor
timestamp: May 15, 2013, 06:32:34 am
content: QuoteWhy 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.QuoteTHAT for instance, is a useful statement!TI has some low cost DSP eval boards, like this one:http://www.ti.com/tool/tmdx5505ezdspBut that's a 200MIPS fixed point DSP, so I don't know how it would compare against an RPI or BeagleBone.

author: rsjsouza
author_rank: Super Contributor
timestamp: May 15, 2013, 12:18:09 pm
content: Quote from: westfw on May 15, 2013, 06:32:34 amMultiply-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. Checkhereandhere.Quote from: westfw on May 15, 2013, 06:32:34 amDue 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: May 17, 2013, 05:43:23 am
content: 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 $89http://www.ebay.com/itm/TMS320F28335PGFA-package-176-LQFP-Development-board-TI-DSP-/151032371516?pt=LH_DefaultDomain_0&hash=item232a3b193cSearch for TMS320 on ebay and there are other boards and jtag emulators to suitForget about dsPic. It is a toy and you will soon run out of clock cycles if you are doing serious audio processingregardsdavid

author: nctnico
author_rank: Super Contributor
timestamp: May 17, 2013, 12:03:18 pm
content: 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 $$$.

author: Harvs
author_rank: Super Contributor
timestamp: May 17, 2013, 02:07:35 pm
content: Quote from: nctnico on May 17, 2013, 12:03:18 pmI know this is totally off topic, but has anyone used these? Any good?

author: snoopy
author_rank: Frequent Contributor
timestamp: May 18, 2013, 10:00:13 am
content: Quote from: nctnico on May 17, 2013, 12:03:18 pmThe 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 useIt's one thing having hardware that can do everything but it's another having a decent tool set to back it upregards

author: nctnico
author_rank: Super Contributor
timestamp: May 18, 2013, 10:42:29 am
content: 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: May 19, 2013, 02:47:58 am
content: Quote from: nctnico on May 18, 2013, 10:42:29 amI 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 complexityQuote

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 19, 2013, 03:03:34 am
content: Quote from: snoopy on May 19, 2013, 02:47:58 amThat'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.

author: Feynman
author_rank: Regular Contributor
timestamp: May 19, 2013, 09:48:31 pm
content: Quote from: codeboy2k on May 13, 2013, 06:11:39 pmThat'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, ...).

author: nctnico
author_rank: Super Contributor
timestamp: May 19, 2013, 10:38:10 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: May 19, 2013, 11:35:02 pm
content: 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...)

author: nctnico
author_rank: Super Contributor
timestamp: May 20, 2013, 01:09:04 am
content: 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?

author: thekhakinator
author_rank: Contributor
timestamp: May 20, 2013, 05:13:20 am
content: 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.

author: glatocha
author_rank: Regular Contributor
timestamp: May 20, 2013, 06:33:35 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: May 20, 2013, 09:17:36 am
content: 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.

author: thekhakinator
author_rank: Contributor
timestamp: May 21, 2013, 04:04:07 am
content: 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#482151In 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.

author: poorchava
author_rank: Super Contributor
timestamp: May 21, 2013, 06:47:45 am
content: 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...

author: glatocha
author_rank: Regular Contributor
timestamp: May 21, 2013, 06:53:15 am
content: what you mean 13lsb error? They have only 12 max I thinkI 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.

author: nuhamind2
author_rank: Regular Contributor
timestamp: May 21, 2013, 11:42:41 am
content: Quote from: glatocha on May 21, 2013, 06:53:15 am12 bit ADC mean 4096 count.13 LSB mean your reading might have error by+13 count.If i understand correctly

author: nctnico
author_rank: Super Contributor
timestamp: May 21, 2013, 12:28:21 pm
content: 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.

author: glatocha
author_rank: Regular Contributor
timestamp: May 21, 2013, 01:15:47 pm
content: wish I could have my front-end so good that 0.3% will be an issue for me

author: thekhakinator
author_rank: Contributor
timestamp: May 22, 2013, 06:12:40 am
content: Quote from: glatocha on May 21, 2013, 01:15:47 pmHaha, I hear that mate.Yeah, in my very limited experience, I am not at all impressed by Microchip's analog parts...

author: gregariz
author_rank: Frequent Contributor
timestamp: June 04, 2013, 08:17:05 pm
content: Quote from: poorchava on May 20, 2013, 09:17:36 amI 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.

author: legacy
author_rank: Super Contributor
timestamp: June 04, 2013, 11:52:15 pm
content: the problem of dsPIC3* is ... you have to deal with "fractional" numberfractional is a sort of fixed point format, i do not like it very much.

author: embeddedbob
author_rank: Contributor
timestamp: June 05, 2013, 08:39:16 am
content: 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).

author: legacy
author_rank: Super Contributor
timestamp: June 07, 2013, 08:13:17 am
content: Anybody using Blackfin BF537 DSP ?

author: thekhakinator
author_rank: Contributor
timestamp: June 09, 2013, 03:07:31 am
content: 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? XDhttp://www.grav-corp.com/?p=87

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 11, 2013, 12:52:46 am
content: There are a lot of uses for low definition audio.

author: thekhakinator
author_rank: Contributor
timestamp: June 15, 2013, 05:27:46 am
content: Quote from: NiHaoMike on June 11, 2013, 12:52:46 amGranted, just amusing they'd use a 16-bit stereo DAC with such high noise.

author: nctnico
author_rank: Super Contributor
timestamp: June 15, 2013, 02:40:41 pm
content: Quote from: NiHaoMike on June 11, 2013, 12:52:46 am61dB doesn't even cut it for a digital telephone line which has 84dB dynamic range. So what is low definition audio?

author: snoopy
author_rank: Frequent Contributor
timestamp: June 16, 2013, 01:51:15 am
content: Quote from: legacy on June 07, 2013, 08:13:17 amI 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 !!regardsdave

author: legacy
author_rank: Super Contributor
timestamp: June 17, 2013, 12:05:01 am
content: do you use fixed point math with blackfin ?

author: snoopy
author_rank: Frequent Contributor
timestamp: June 22, 2013, 12:17:12 pm
content: Quote from: legacy on June 17, 2013, 12:05:01 amYes I used fixed point arithmetic. You can do floating point arithmetic but it's not very efficient.regards

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 12:05:40 am
content: what fixedpoint library have you used ?also 32bit ? 64bit ?

author: nctnico
author_rank: Super Contributor
timestamp: June 23, 2013, 12:42:42 am
content: 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

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 09:01:13 am
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 09:03:55 am
content: I mean, with 32 bit, this is not enoughCode:/** 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)

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 09:21:07 am
content: Code: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: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 iteractionspi is equal to 3.141493fixed_point fx16.16 computing pi with 20000 iteractionspi is equal to 3.1411fixed_point fx24.08 computing pi with 20000 iteractionspi is equal to 3.10fixed_point fx12.20 computing pi with 20000 iteractionspi is equal to 3.1309math engineevaluated pifp643.141493fx16.163.1411fx24.083.10fx12.203.1309

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 09:34:03 am
content: Code:void eval_pi_i64(){char result;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 iteractionswith a scale of 10000000, pi is equal to 3141494431414944 / 10000000 = 3.1414944the difference between float (fp32_t) and double (fp64_t)float fp32 computing pi with 20000 iteractionspi is equal to 3.141499float fp64 computing pi with 20000 iteractionspi is equal to 3.141493Final reportmath engineevaluated pifp323.141499fp643.141493fx16.163.1411fx24.083.10fx12.203.1309fx.i643.1414944

author: snoopy
author_rank: Frequent Contributor
timestamp: June 23, 2013, 01:38:31 pm
content: Quote from: nctnico on June 23, 2013, 12:42:42 ambecause 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

author: legacy
author_rank: Super Contributor
timestamp: June 23, 2013, 02:56:35 pm
content: 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.

author: andersm
author_rank: Super Contributor
timestamp: June 23, 2013, 06:30:27 pm
content: Fixed-point math was proposed for C11 as part ofTR 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: June 24, 2013, 03:33:45 am
content: Quote from: legacy on June 23, 2013, 02:56:35 pmbest 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

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 08:20:33 am
content: the problem is ... what happens if you have not.

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 09:35:46 am
content: Quote from: snoopy on June 24, 2013, 03:33:45 amA 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: June 24, 2013, 12:33:48 pm
content: Quote from: legacy on June 24, 2013, 08:20:33 amthen its is not suitable as a dsp.

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 12:51:32 pm
content: Quote from: snoopy on June 24, 2013, 12:33:48 pmThats total crap and you know it!

author: snoopy
author_rank: Frequent Contributor
timestamp: June 24, 2013, 02:32:51 pm
content: Quote from: nctnico on June 24, 2013, 12:51:32 pmso 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

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 04:00:21 pm
content: 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.

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 04:19:26 pm
content: Quote from: nctnico on June 24, 2013, 04:00:21 pmExactly, you have to care about overflowsand precision lost -> you have to tune your software very accurately.AndTHISis the reason why i need much more than 32bits!!!!This is the question!

author: marshallh
author_rank: Unknown
timestamp: June 24, 2013, 04:19:40 pm
content: 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!

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 04:24:22 pm
content: 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- cmp128bitinto a spartan3E, also i wandering how good can "cordic" libraries go if implemented with fixedpoint.

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 04:28:19 pm
content: Quote from: marshallh on June 24, 2013, 04:19:40 pmwith 128bit multiplies should take 4 clocks to complete

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 04:41:58 pm
content: More specifically i have to port this code to a dspCode:void gps_calc(){double a, b, c;// Degreea = 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

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 04:54:28 pm
content: 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).

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 05:42:45 pm
content: 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 ?

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 05:51:38 pm
content: i mean, is this wrong ?Code:/** 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 16bitCode:/** 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 tablefx16.16 pi=3.1411fx12.20 pi=3.1309you find that it is not

author: jahonen
author_rank: Super Contributor
timestamp: June 24, 2013, 06:46:35 pm
content: 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

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 06:55:20 pm
content: 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

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 07:03:44 pm
content: Quote from: jahonen on June 24, 2013, 06:46:35 pmit 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.Quote from: jahonen on June 24, 2013, 06:46:35 pmCause 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.Quote from: jahonen on June 24, 2013, 06:46:35 pmI have placed a new order on Amazon, thanks for the trips

author: legacy
author_rank: Super Contributor
timestamp: June 24, 2013, 07:14:18 pm
content: Quote from: nctnico on June 24, 2013, 06:55:20 pmthere 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 floatYou are missing the library of fixedpoint64bit: i haven't posted it.

author: nctnico
author_rank: Super Contributor
timestamp: June 24, 2013, 07:33:28 pm
content: Quote from: legacy on June 24, 2013, 07:03:44 pmSounds 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!

author: jahonen
author_rank: Super Contributor
timestamp: June 24, 2013, 07:41:46 pm
content: Quote from: legacy on June 24, 2013, 07:03:44 pmHave 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

author: senso
author_rank: Frequent Contributor
timestamp: June 24, 2013, 09:22:17 pm
content: 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?

author: westfw
author_rank: Super Contributor
timestamp: June 24, 2013, 10:02:13 pm
content: QuoteThis 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: June 25, 2013, 03:02:52 am
content: Quote from: nctnico on June 24, 2013, 04:00:21 pmfixed 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 resultsIf you your micro doesn't have the hardware to do it quickly then how are you supposed to do it ?

author: nctnico
author_rank: Super Contributor
timestamp: June 25, 2013, 10:23:43 am
content: 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.

author: Rasz
author_rank: Super Contributor
timestamp: June 25, 2013, 11:04:53 am
content: btw this might be interesting to people wanting to start developing with DPSshttp://www.limpkin.fr/index.php?post/2013/04/26/The-whistled:-how-to-remake-a-dozen-years-old-project-the-right-wayhttp://www.limpkin.fr/index.php?post/2013/06/30/The-whistled%3A-from-whistle-to-sound-recognitionhttps://www.tindie.com/products/limpkin/the-whistled-assembled-pcb/is based on Freescale KINETIS_Khttp://www.freescale.com/webapp/sps/site/overview.jsp?code=KINETIS_K_SERIES80 FFTs per second at $23 doesnt sound bad+ its open hardware/software

author: legacy
author_rank: Super Contributor
timestamp: June 25, 2013, 11:47:03 am
content: 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)

author: snoopy
author_rank: Frequent Contributor
timestamp: June 25, 2013, 12:58:14 pm
content: Quote from: nctnico on June 25, 2013, 10:23:43 amIf 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

author: legacy
author_rank: Super Contributor
timestamp: June 25, 2013, 01:36:12 pm
content: Comparing Floating-Point and Fixed-Point Implementations on ADI Blackfin Processors with LabVIEW

author: legacy
author_rank: Super Contributor
timestamp: June 25, 2013, 01:56:21 pm
content: Quote from: snoopy on June 25, 2013, 12:58:14 pmhardware 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.

author: legacy
author_rank: Super Contributor
timestamp: June 25, 2013, 02:23:44 pm
content: You mean something like that implemented in hardware ?Code:/** 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 0x7fffffffsint32_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;}

author: nctnico
author_rank: Super Contributor
timestamp: June 25, 2013, 03:00:31 pm
content: Quote from: snoopy on June 25, 2013, 12:58:14 pmThat 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.

author: andersm
author_rank: Super Contributor
timestamp: June 25, 2013, 03:41:38 pm
content: Quote from: legacy on June 25, 2013, 01:56:21 pmWhy not start by studyingthe CPU you already have.

author: legacy
author_rank: Super Contributor
timestamp: June 25, 2013, 06:00:50 pm
content: work in progress

author: Paul Price
author_rank: Super Contributor
timestamp: June 25, 2013, 10:04:04 pm
content: Assuming someone has found or not found the perfect DSP for abeginner,would anyone be so brave to tell what practical application or device they managed to get working using one?

author: nctnico
author_rank: Super Contributor
timestamp: June 25, 2013, 11:37:46 pm
content: 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.

author: snoopy
author_rank: Frequent Contributor
timestamp: June 28, 2013, 03:04:35 am
content: Quote from: nctnico on June 25, 2013, 11:37:46 pmand 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 coursesYes 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

author: legacy
author_rank: Super Contributor
timestamp: June 28, 2013, 08:55:23 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: June 28, 2013, 12:15:16 pm
content: Quote from: legacy on June 28, 2013, 08:55:23 amYou see problems which aren't there at all...

author: legacy
author_rank: Super Contributor
timestamp: June 28, 2013, 02:25:17 pm
content: this bookis explaining it a bit.

author: nctnico
author_rank: Super Contributor
timestamp: June 28, 2013, 06:24:44 pm
content: Ofcourse the author of a book about dsPIC isn't going to write you don't need a DSP

author: legacy
author_rank: Super Contributor
timestamp: June 28, 2013, 11:50:38 pm
content: Ok, and what do you think aboutthis book? =P