Forums

Conversion distortion

Started by Richard Hendeberg March 26, 2004
Hi,

I'm implementing a IIR-filter on a Motorola DSP56367 processor. When I
convert the sampled audio to float and back again it gets distorted.
First I assumed that it was my filter that was written incorrectly but
just converting the data corrupts it. I use the cast function in
g563c.

int rx_data, tx_data;
float temp;

temp = (float) rx_data;
tx_data = (int)temp;

I loaded rx_data with 0x000fff. 
temp got the value 0x00200b 7ff800.
tx_data gets the value 0x000080.

Is this a known problem? Is there a algorithm I can use instead of
cast?
I'm thankful for any hints.

/Richard Hendeberg
Richard Hendeberg wrote:

> Hi, > > I'm implementing a IIR-filter on a Motorola DSP56367 processor. When I > convert the sampled audio to float and back again it gets distorted. > First I assumed that it was my filter that was written incorrectly but > just converting the data corrupts it. I use the cast function in > g563c. > > int rx_data, tx_data; > float temp; > > temp = (float) rx_data; > tx_data = (int)temp; > > I loaded rx_data with 0x000fff. > temp got the value 0x00200b 7ff800. > tx_data gets the value 0x000080. > > Is this a known problem? Is there a algorithm I can use instead of > cast? > I'm thankful for any hints. > > /Richard Hendeberg
Some round-off error is to be expected, but starting with $FFF (4095) and ending with $80 (128) is beyond anything permissible. Are your word sizes compatible? Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
On 26 Mar 2004 05:33:23 -0800, Richard Hendeberg wrote:
> I'm implementing a IIR-filter on a Motorola DSP56367 processor. When I > convert the sampled audio to float and back again it gets distorted. > First I assumed that it was my filter that was written incorrectly but > just converting the data corrupts it. I use the cast function in > g563c.
Any particular reason to implement your filter in floating point? That processor is naturally fixed-point. (And easy to use in that form, but not from C.)
> int rx_data, tx_data; > float temp; > > temp = (float) rx_data; > tx_data = (int)temp; > > I loaded rx_data with 0x000fff. > temp got the value 0x00200b 7ff800. > tx_data gets the value 0x000080. > > Is this a known problem? Is there a algorithm I can use instead of > cast?
I'd be surprised if anyone here can help directly: I've never heard of anyone doing anything serious with that C compiler (It's very, very old: based on GCC 1.8-something, probably not maintained in the last ten years). Certianly not in floating point on that DSP. However, that said, the answer that you have is obviously wrong. Since the type conversions in both directions are (necessarily) software, the opportunity exists to attempt to debug them. Can you make sure that the code that you are running has actually been linked against the necessary libraries? Can you try tracing the execution at the assembly-instruction level, down through the conversion routines? That could give you a hint as to where things are going awry. Are you using the simulator or the debugger? I think that the usual debugger can interpret the C compiler's float format. That should show you if the problem is confined to the int->float cast or the float->int cast, or is in both. Cheers, -- Andrew
Andrew Reilly <andrew@gurney.reilly.home> wrote in message news:<slrnc69i6j.2mmp.andrew@gurney.reilly.home>...
> On 26 Mar 2004 05:33:23 -0800, Richard Hendeberg wrote: > > I'm implementing a IIR-filter on a Motorola DSP56367 processor. When I > > convert the sampled audio to float and back again it gets distorted. > > First I assumed that it was my filter that was written incorrectly but > > just converting the data corrupts it. I use the cast function in > > g563c. > > Any particular reason to implement your filter in floating > point? That processor is naturally fixed-point. (And easy to > use in that form, but not from C.) >
No, not really. I'm afraid I'd just assumed I had too. I'm however unfortunately forced to work in C and with this particular compiler as well. This is part of a degree project so there is a demand on using C. Then again since it's just a degree project there aren't funds available to buy the compiler from Taskings. That said, is it preferable to write the filter as an assembler functions and call it from the C main program then to write conversion functions (if necessary)and only work in C. /Richard
Andrew Reilly <andrew@gurney.reilly.home> wrote in message news:<slrnc69i6j.2mmp.andrew@gurney.reilly.home>...
> On 26 Mar 2004 05:33:23 -0800, Richard Hendeberg wrote: > > I'm implementing a IIR-filter on a Motorola DSP56367 processor. When I > > convert the sampled audio to float and back again it gets distorted. > > First I assumed that it was my filter that was written incorrectly but > > just converting the data corrupts it. I use the cast function in > > g563c. > > Any particular reason to implement your filter in floating > point? That processor is naturally fixed-point. (And easy to > use in that form, but not from C.) >
No, not really. I'm afraid I'd just assumed I had too. I'm however unfortunately forced to work in C and with this particular compiler as well. This is part of a degree project so there is a demand on using C. Then again since it's just a degree project there aren't funds available to buy the compiler from Taskings. That said, is it preferable to write the filter as an assembler functions and call it from the C main program then to write conversion functions (if necessary)and only work in C. /Richard
> int rx_data, tx_data; > float temp;
ints may be a problem here. rxdata & txdata are not really ints, but fixed point fractions (-1.0..+0.9999999) on a 56K. Does the compiler provide a suitable data type? Do you have compiler docs to tell you what the binary (hex) FP format should look like for known numbers? e.g. 0.99999999, 0.5, 0.1 etc. Make soure the values you give are not those of a NAN (not-a-number) like infinity.
> temp = (float) rx_data; // <<<<<<<<<<<<<<<<<<<<<<< > tx_data = (int)temp;
Also, I once had a problem where the (float) cast was (a) unnecessary and (b) a source of problems. The compiler already new that rxdata was an int, and that it had to be converted to a float, and the cast caused an EXTRA int2flt() conversion to be done on the 1st conversion result. Check the assembler listing from the compiler to see if something like this is happening. If you are lucky, you will find a call to a named s/r label rather than in-line code, which is harder to follow. Jim Adamthwaite.