Lowcost DSP for beginner

[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...