dsPIC and general PIC differences help

[neochrome32]

dsPIC and general PIC

These don't appear to have any significant differences in speeds or memory.

I know the dsPIC is for digital signals
but on a purely mathematics and number crunching basis, would these perform the same??

Its bad form to use floats, I'd rather avoid em, but the project i am working on is badly coded at the moment and is currently using floats.

Does the dsPIC come with its own float co-processor? or am i just wasting money?

I have a pic24HJ128GP502.
I wanted to try the dsPIC33HJ128GP804.

Its audio output isn't really an issue right now,
the answer I'm seeking is CALCULATIONS.

Would these to perform the same on floats/ints and longs?

I just can't seem to get my head clear on this one.

thanks :D

[Ttelmah]

The PIC24, is the lower end of the same part of the PIC family from the 'DsPIC'. The traditional PIC's would be chips like the PIC18's. As such the PIC 24's (depending on the model), have many of the extra features in the DsPIC family. So DMA (faster data movement) etc.. The 'core' is the same between both families.
Depending on the chip versions, the PIC33's often offer faster clock rates. In your case, the PIC24 is only rated for 40MIPS, while there are other chips in the same family rated to 70MIPS. The PIC24EP for example. I don't know a PIC33HJ. Are you sure about the number?. The dsPIC33FJ128GP804 is only a 40MIPS device. None of the PIC's in these families have FP hardware.

Best Wishes

[temtronic]

One option,since the program is 'poorly coded and uses FP', is to start fresh using integer math. It's a LOT faster than FP so you might not need a super fast PIC.At the same time ,by rewriting the code, you may find several areas to improve performance.
I've had projects 'given' to me to 'fix up' and in the end it was easier and quicker to start fresh instead of 'patching/testing/try again'.

hth
jay

[Ttelmah]

Very true indeed.

It's also worth saying that speed depends most, on what is done the most often. In loop that executes 10000 times a second, saving 1uSecond makes a lot of difference, while saving ten times this in something that only updates once a second is far less useful. It is often worth making scaling maths done when calibration factors are entered, or calculated, _more_ complex, so that the values used inside an actual 'sample' loop can be kept simple. I have a system that is based on logarithmic maths, and re-scale everything, after calibration, so that the sample loop works on a normalised range of 0-1, which then allows the maths to be done from a look up table, and interpolation, and then the results scaled. Result no need for FP logs in the speed critical part...

Best Wishes

[neochrome32]

thanks guys, i've made a sort of float to int converter, loaded the values most likely used and just "snap to the nearest"

SO MUCH more speed! thanks for that little tip!!

and the info for the MCU's are just what i needed..

though i think the way forward is the 70mips i do want a NICE 44Khz polyphonic sound... cant really do that with 40mips... its close, but still very grainy with 8bit out

[Ttelmah]

Are you using the standard ADC/DAC?.
It is worth being aware, that this is not really the way to go for audio.
Problem is that audio amplitude response, is non linear. So with a standard DAC/ADC, you waste time and space, storing lots of levels in parts of the waveform where the ear can't really discern them, and lack levels where they matter. This is why audio ADC's and DAC's have non linear responses. With some ingenuity, you can perform conversions on the incoming signal to make it more linear at the ADC, and do the inverse on the data coming out, or use log response ADC's and anti-log DAC's. Have a look at:
<www.thatcorp.com/datashts/Borrowing_Pro_Audio_Tech.pdf>
Which shows a multiplier being used to optimise the range of an ADC, and look at audio DAC's.

Best Wishes