short to single precision floating point conversion
Started by ●December 31, 2005
Hi,
I am using C6711 to implement the some algorithm which uses floating point numbers. For the Real-time implementation of the my system, the reading of the input audio signal as well as the writing of the output signal is done via serial port 1 of the Multi Channeled Buffered Serial Port (MCBSP). Using the Chip Support Library (CSL) routines, both the right and the left channels can be read or written in a single function call so I am using the functions MCBSP_read and MCBSP_write both of which expect a Uint32 as a parameter. The MCBSP_read routine returns an unsigned integer (Uint32) which is a 32 bit data representation of the stereophonic audio signal read into the system. In addition, each audio channel on the DSK is in a 16-bit signed integer format:the upper 16 bits represent the right channel and the lower 16 bits represent the left channel.
in the algorithm itself i need to convert those two values to a flaoting point number so I am using:
volatile Uint32 mcbsp32BitIn=0;
Int16 rightInput=0;
float x_n=0;
/* Read a 32-bit Unsigned integer data from channel
1 of the McBSP */
mcbsp32BitIn=MCBSP_read(hMcbsp1); /* Shift the upper 16 bits of mcbsp32BitIn down
into the lower 16-bit position (bits 15 - 0), for instance if
mcbsp32BitIn is 0xFF09FF98 then rightInput will be
0xFF09. */
rightInput = mcbsp32BitIn >> 16;
/* Convert right channel to floating point */
x_n = ((float) (rightInput));
/* Scaling */
x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768 (0x8000 in hexadecimal)
Am I correct in doing so or should I be using 32,767 (0x7FFF in hexadecimal) ???
And my second question is: when converting back from float to short int I am using:
x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling factor?
Thanks,
Reply by ●January 1, 20062006-01-01
I believe it would be 32768. When going from float to int, you can round
to
the nearest int for more accuracy.
Robert
> -----Original Message-----
> From: c6x@c6x@... [mailto:c6x@c6x@...] On
> Behalf Of shlomo_kashani
> Sent: Saturday, December 31, 2005 8:15 PM
> To: c6x@c6x@...
> Subject: [c6x] short to single precision floating point conversion > Hi,
>
> I am using C6711 to implement the some algorithm which uses
> floating point numbers. For the Real-time implementation of
> the my system, the reading of the input audio signal as well
> as the writing of the output signal is done via serial port 1
> of the Multi Channeled Buffered Serial Port (MCBSP). Using
> the Chip Support Library (CSL) routines, both the right and
> the left channels can be read or written in a single function
> call so I am using the functions MCBSP_read and MCBSP_write
> both of which expect a Uint32 as a parameter. The MCBSP_read
> routine returns an unsigned integer (Uint32) which is a 32
> bit data representation of the stereophonic audio signal read
> into the system. In addition, each audio channel on the DSK
> is in a 16-bit signed integer format:the upper 16 bits
> represent the right channel and the lower 16 bits represent
> the left channel.
>
> in the algorithm itself i need to convert those two values to
> a flaoting point number so I am using:
>
> volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */ x_n =
> ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is
> SCALE_FACTOR_SHORT_TO_FLOAT2768 (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF
> in hexadecimal) ???
>
> And my second question is: when converting back from float to
> short int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct
> scaling factor?
>
> Thanks, > --
the nearest int for more accuracy.
Robert
> -----Original Message-----
> From: c6x@c6x@... [mailto:c6x@c6x@...] On
> Behalf Of shlomo_kashani
> Sent: Saturday, December 31, 2005 8:15 PM
> To: c6x@c6x@...
> Subject: [c6x] short to single precision floating point conversion > Hi,
>
> I am using C6711 to implement the some algorithm which uses
> floating point numbers. For the Real-time implementation of
> the my system, the reading of the input audio signal as well
> as the writing of the output signal is done via serial port 1
> of the Multi Channeled Buffered Serial Port (MCBSP). Using
> the Chip Support Library (CSL) routines, both the right and
> the left channels can be read or written in a single function
> call so I am using the functions MCBSP_read and MCBSP_write
> both of which expect a Uint32 as a parameter. The MCBSP_read
> routine returns an unsigned integer (Uint32) which is a 32
> bit data representation of the stereophonic audio signal read
> into the system. In addition, each audio channel on the DSK
> is in a 16-bit signed integer format:the upper 16 bits
> represent the right channel and the lower 16 bits represent
> the left channel.
>
> in the algorithm itself i need to convert those two values to
> a flaoting point number so I am using:
>
> volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */ x_n =
> ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is
> SCALE_FACTOR_SHORT_TO_FLOAT2768 (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF
> in hexadecimal) ???
>
> And my second question is: when converting back from float to
> short int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct
> scaling factor?
>
> Thanks, > --
Reply by ●January 2, 20062006-01-02
Hi,
If you think of the signed 16 bit values to/from DAC/ADC as 1b15 (Q.15)
fixed-point numbers, they represent fractions between -1 and
0.999969482421875. So, to convert rightInput to floating point you
divide rightInput by 32768. What you've done to convert rightInput is
absolutely correct. However, you can do this more efficiently by using
ldexp.
x_n = ((float) (rightInput));
x_n = ldexpf (x_n, -15);
When you convert the floating-point sample back to signed 16 to write
to the DAC, you have to convert the floating-point fraction back into
1b15. To do this, you multiply the floating-point fraction by 32768. If
the float number doesn't lie between -1.0 and 0.999969482421875, your
result will overflow. So you have to saturate it as shown below.
Additionally, you may also want to round the number if your algorithm
is sensitive to rounding errors. Also, the intrinsic _spint can be used
to saturate and round a float to an Int32.
x_n = floorf (ldexpf (x_n, 15) + 0.5f);
if (x_n > SIGNED_1b15_MAX)
{
rightInput = SIGNED_1b15_MAX;
}
else if (x_n < SIGNED_1b15_MIN)
{
rightInput = SIGNED_1b15_MIN;
}
else
{
rightInput = (Int16) x_n;
}
Niro.
--- shlomo_kashani <shlomo_kashani@shlo...> wrote:
>
> Hi,
>
> I am using C6711 to implement the some algorithm which uses floating
> point numbers. For the Real-time implementation of the my system,
> the reading of the input audio signal as well as the writing of the
> output signal is done via serial port 1 of the Multi Channeled
> Buffered Serial Port (MCBSP). Using the Chip Support Library (CSL)
> routines, both the right and the left channels can be read or written
> in a single function call so I am using the functions MCBSP_read and
> MCBSP_write both of which expect a Uint32 as a parameter. The
> MCBSP_read routine returns an unsigned integer (Uint32) which is a 32
> bit data representation of the stereophonic audio signal read into
> the system. In addition, each audio channel on the DSK is in a 16-bit
> signed integer format:the upper 16 bits represent the right channel
> and the lower 16 bits represent the left channel.
>
> in the algorithm itself i need to convert those two values to a
> flaoting point number so I am using:
>
> volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be
> 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */
> x_n = ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768
> (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF in
> hexadecimal) ???
>
> And my second question is: when converting back from float to short
> int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling
> factor?
>
> Thanks,
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
If you think of the signed 16 bit values to/from DAC/ADC as 1b15 (Q.15)
fixed-point numbers, they represent fractions between -1 and
0.999969482421875. So, to convert rightInput to floating point you
divide rightInput by 32768. What you've done to convert rightInput is
absolutely correct. However, you can do this more efficiently by using
ldexp.
x_n = ((float) (rightInput));
x_n = ldexpf (x_n, -15);
When you convert the floating-point sample back to signed 16 to write
to the DAC, you have to convert the floating-point fraction back into
1b15. To do this, you multiply the floating-point fraction by 32768. If
the float number doesn't lie between -1.0 and 0.999969482421875, your
result will overflow. So you have to saturate it as shown below.
Additionally, you may also want to round the number if your algorithm
is sensitive to rounding errors. Also, the intrinsic _spint can be used
to saturate and round a float to an Int32.
x_n = floorf (ldexpf (x_n, 15) + 0.5f);
if (x_n > SIGNED_1b15_MAX)
{
rightInput = SIGNED_1b15_MAX;
}
else if (x_n < SIGNED_1b15_MIN)
{
rightInput = SIGNED_1b15_MIN;
}
else
{
rightInput = (Int16) x_n;
}
Niro.
--- shlomo_kashani <shlomo_kashani@shlo...> wrote:
>
> Hi,
>
> I am using C6711 to implement the some algorithm which uses floating
> point numbers. For the Real-time implementation of the my system,
> the reading of the input audio signal as well as the writing of the
> output signal is done via serial port 1 of the Multi Channeled
> Buffered Serial Port (MCBSP). Using the Chip Support Library (CSL)
> routines, both the right and the left channels can be read or written
> in a single function call so I am using the functions MCBSP_read and
> MCBSP_write both of which expect a Uint32 as a parameter. The
> MCBSP_read routine returns an unsigned integer (Uint32) which is a 32
> bit data representation of the stereophonic audio signal read into
> the system. In addition, each audio channel on the DSK is in a 16-bit
> signed integer format:the upper 16 bits represent the right channel
> and the lower 16 bits represent the left channel.
>
> in the algorithm itself i need to convert those two values to a
> flaoting point number so I am using:
>
> volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be
> 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */
> x_n = ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768
> (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF in
> hexadecimal) ???
>
> And my second question is: when converting back from float to short
> int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling
> factor?
>
> Thanks,
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Reply by ●January 2, 20062006-01-02
Hi,
If you think of the signed 16 bit values to/from DAC/ADC as 1b15 (Q.15)
fixed-point numbers, they represent fractions between -1 and
0.999969482421875. So, to convert rightInput to floating point you
divide rightInput by 32768. What you've done to convert rightInput is
absolutely correct. However, you can do this more efficiently by using
ldexp.
x_n = ((float) (rightInput));
x_n = ldexpf (x_n, -15);
When you convert the floating-point sample back to signed 16 to write
to the DAC, you have to convert the floating-point fraction back into
1b15. To do this, you multiply the floating-point fraction by 32768. If
the float number doesn't lie between -1.0 and 0.999969482421875, your
result will overflow. So you have to saturate it as shown below.
Additionally, you may also want to round the number if your algorithm
is sensitive to rounding errors. Also, the intrinsic _spint can be used
to saturate and round a float to an Int32.
x_n = floorf (ldexpf (x_n, 15) + 0.5f);
if (x_n > SIGNED_1b15_MAX)
{
rightInput = SIGNED_1b15_MAX;
}
else if (x_n < SIGNED_1b15_MIN)
{
rightInput = SIGNED_1b15_MIN;
}
else
{
rightInput = (Int16) x_n;
}
Niro.
--- shlomo_kashani <shlomo_kashani@shlo...> wrote:
>
> Hi,
>
> I am using C6711 to implement the some algorithm which uses floating
> point numbers. For the Real-time implementation of the my system,
> the reading of the input audio signal as well as the writing of the
> output signal is done via serial port 1 of the Multi Channeled
> Buffered Serial Port (MCBSP). Using the Chip Support Library (CSL)
> routines, both the right and the left channels can be read or written
> in a single function call so I am using the functions MCBSP_read and
> MCBSP_write both of which expect a Uint32 as a parameter. The
> MCBSP_read routine returns an unsigned integer (Uint32) which is a 32
> bit data representation of the stereophonic audio signal read into
> the system. In addition, each audio channel on the DSK is in a 16-bit
> signed integer format:the upper 16 bits represent the right channel
> and the lower 16 bits represent the left channel.
>
> in the algorithm itself i need to convert those two values to a
> flaoting point number so I am using:
>
> volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be
> 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */
> x_n = ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768
> (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF in
> hexadecimal) ???
>
> And my second question is: when converting back from float to short
> int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling
> factor?
>
> Thanks,
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
Reply by ●January 2, 20062006-01-02
Hi,
Does anyone know whether is it possible to run the on-board audio codec
(AIC23) on 6713 DSK at 96 kHz sampling rate to acquire spectral
contents up to 48 kHz? I'm hoping to use the on-board codec to transmit
and receive data to/from ultrasonic transducers with 40 kHz centre
frequency. According to AIC23 data sheet, the codec can run at 96 kHz
sampling rate and the anti-aliasing/reconstruction filters all have
~Fs/2 cut-off, but Im not sure if there are any other constraints on
the DSK board that would limit the maximum bandwidth/sampling rate. Any
info would be greatly appreciated.
Thanks,
Niro.
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Does anyone know whether is it possible to run the on-board audio codec
(AIC23) on 6713 DSK at 96 kHz sampling rate to acquire spectral
contents up to 48 kHz? I'm hoping to use the on-board codec to transmit
and receive data to/from ultrasonic transducers with 40 kHz centre
frequency. According to AIC23 data sheet, the codec can run at 96 kHz
sampling rate and the anti-aliasing/reconstruction filters all have
~Fs/2 cut-off, but Im not sure if there are any other constraints on
the DSK board that would limit the maximum bandwidth/sampling rate. Any
info would be greatly appreciated.
Thanks,
Niro.
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Reply by ●January 2, 20062006-01-02
Shlomo-
> I am using C6711 to implement the some algorithm which uses floating point
> numbers. For the Real-time implementation of the my system, the reading
> of the input audio signal as well as the writing of the output signal is
> done via serial port 1 of the Multi Channeled Buffered Serial Port (MCBSP).
> Using the Chip Support Library (CSL) routines, both the right and the left
> channels can be read or written in a single function call so I am using the
> functions MCBSP_read and MCBSP_write both of which expect a Uint32 as a
> parameter. The MCBSP_read routine returns an unsigned integer (Uint32)
> which is a 32 bit data representation of the stereophonic audio signal read
> into the system. In addition, each audio channel on the DSK is in a 16-bit
> signed integer format:the upper 16 bits represent the right channel and
> the lower 16 bits represent the left channel.
>
> in the algorithm itself i need to convert those two values to a flaoting
> point number so I am using:
The code below looks Ok -- or at least going in the right direction -- but just want
to point out there is no compelling reason to convert 16-bit A/D values to +/- 1.0 in
floating-point code. You can maintain the values in the range of -32768 to 32767
throughout your algorithm. In the case of time-sensitive real-time processing, it
might make the A/D "entry point" slightly more efficient, such as DMA and interrupt
service routine code.
-Jeff > volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be
> 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */
> x_n = ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768 (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF in hexadecimal) ???
>
> And my second question is: when converting back from float to short int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling factor?
>
> Thanks,
> I am using C6711 to implement the some algorithm which uses floating point
> numbers. For the Real-time implementation of the my system, the reading
> of the input audio signal as well as the writing of the output signal is
> done via serial port 1 of the Multi Channeled Buffered Serial Port (MCBSP).
> Using the Chip Support Library (CSL) routines, both the right and the left
> channels can be read or written in a single function call so I am using the
> functions MCBSP_read and MCBSP_write both of which expect a Uint32 as a
> parameter. The MCBSP_read routine returns an unsigned integer (Uint32)
> which is a 32 bit data representation of the stereophonic audio signal read
> into the system. In addition, each audio channel on the DSK is in a 16-bit
> signed integer format:the upper 16 bits represent the right channel and
> the lower 16 bits represent the left channel.
>
> in the algorithm itself i need to convert those two values to a flaoting
> point number so I am using:
The code below looks Ok -- or at least going in the right direction -- but just want
to point out there is no compelling reason to convert 16-bit A/D values to +/- 1.0 in
floating-point code. You can maintain the values in the range of -32768 to 32767
throughout your algorithm. In the case of time-sensitive real-time processing, it
might make the A/D "entry point" slightly more efficient, such as DMA and interrupt
service routine code.
-Jeff > volatile Uint32 mcbsp32BitIn=0;
>
> Int16 rightInput=0;
>
> float x_n=0;
>
> /* Read a 32-bit Unsigned integer data from channel
> 1 of the McBSP */
>
> mcbsp32BitIn=MCBSP_read(hMcbsp1); > /* Shift the upper 16 bits of mcbsp32BitIn down
> into the lower 16-bit position (bits 15 - 0), for instance if
> mcbsp32BitIn is 0xFF09FF98 then rightInput will be
> 0xFF09. */
> rightInput = mcbsp32BitIn >> 16;
>
> /* Convert right channel to floating point */
> x_n = ((float) (rightInput));
> /* Scaling */
> x_n *= _rcpsp(SCALE_FACTOR_SHORT_TO_FLOAT);
>
> The value I use for the sacling is SCALE_FACTOR_SHORT_TO_FLOAT2768 (0x8000 in hexadecimal)
>
> Am I correct in doing so or should I be using 32,767 (0x7FFF in hexadecimal) ???
>
> And my second question is: when converting back from float to short int I am using:
>
> x_n =x_n*SCALE_FACTOR_FLOAT_TO_SHORT;
>
> where SCALE_FACTOR_FLOAT_TO_SHORT2,767 is this the correct scaling factor?
>
> Thanks,
Reply by ●January 2, 20062006-01-02
Jeff & Nero,
Thanks a lot for both of the replies.
(Jeff)
The algorithm is an adaptive noise cancellation algorithm ( LMS ) which involves multiplication by a what is known as a convergence factor, mu, which is typically in the range of .0001 to .1. That is the reason I was using SP floating point and that is why I converted 16-Bit PCM to float. I gained knowledge by doing so and I am happy i
did so but I am always willing to do it better if that is possible even though I spent a lot of time making it work in floating point. Initially,I tried to represent "mu" as a fraction between two short integers but that didnt go very well but I am sure it can be done
and would be happy for any suggestion in that direction as it would save CPU cycles.
Thanks a lot for both of the replies.
(Jeff)
The algorithm is an adaptive noise cancellation algorithm ( LMS ) which involves multiplication by a what is known as a convergence factor, mu, which is typically in the range of .0001 to .1. That is the reason I was using SP floating point and that is why I converted 16-Bit PCM to float. I gained knowledge by doing so and I am happy i
did so but I am always willing to do it better if that is possible even though I spent a lot of time making it work in floating point. Initially,I tried to represent "mu" as a fraction between two short integers but that didnt go very well but I am sure it can be done
and would be happy for any suggestion in that direction as it would save CPU cycles.
(Nero)
First thank a lot for the long and detailed reply :)
First thank a lot for the long and detailed reply :)
I
followed your suggestion to use x_n = ldexpf (x_n, -15); I am just not
sure that this library routine is faster then multiplication on the C6711. And
another issue is with the compiler. As I understand, adding a function call
inside a l loop disqualifies the loop for software pipelining and in that case
the call to ldexpf would disqualify the loop while the multiplication
would not (please correct me if i am wrong)
regarding the issue of
converting back to Int16 from float:
1-In which header file is SIGNED_1b15_MAX defined?
2-Adding a conditional if statement in my ISR would make it work much slower as conditional statements (branch instructions) costs
6 CPU cycles. Is there an alternative ? Or maybe as Jeff suggested
remove all floating point operations from the code?
1-In which header file is SIGNED_1b15_MAX defined?
2-Adding a conditional if statement in my ISR would make it work much slower as conditional statements (branch instructions) costs
6 CPU cycles. Is there an alternative ? Or maybe as Jeff suggested
remove all floating point operations from the code?
I am attaching the below, any comment would be
appreciated. Naturally not all the code is included.
Shlomo.
Yahoo! Shopping
Find Great Deals on Holiday Gifts at Yahoo! Shopping
Reply by ●January 3, 20062006-01-03
Shlomo-
> (Jeff)
> The algorithm is an adaptive noise cancellation algorithm ( LMS ) which involves
> multiplication by a what is known as a convergence factor, mu, which is typically
> in the range of .0001 to .1. That is the reason I was using SP floating point and
> that is why I converted 16-Bit PCM to float. I gained knowledge by doing so and I
> am happy i
> did so but I am always willing to do it better if that is possible even though I
> spent a lot of time making it work in floating point. Initially,I tried to
> represent "mu" as a fraction between two short integers but that didnt go very
> well but I am sure it can be done
> and would be happy for any suggestion in that direction as it would save CPU
> cycles.
Sounds like an echo can type algorithm, in which case yes I agree -- get it working
in "conventional floating-point format" first, make it match your MATLAB or host C
code, etc.
Once it's working, then worry about optimizing for real-time.
-Jeff
> (Nero)
> First thank a lot for the long and detailed reply :)
> I followed your suggestion to use x_n = ldexpf (x_n, -15); I am ju st not sure that
> this library routine is faster then multiplication on the C6711. And another issue
> is with the compiler. As I understand, adding a function call inside a l loop
> disqualifies the loop for software pipelining and in that case the call to ldexpf
> would disqualify the loop while the multiplication would not (please correct me if
> i am wrong)
> regarding the issue of converting back to Int16 from float:
> 1-In which header file is SIGNED_1b15_MAX defined?
> 2-Adding a conditional if statement in my ISR would make it work much slower as
> conditional statements (branch instructions) costs
> 6 CPU cycles. Is there an alternative ? Or maybe as Jeff suggested
> remove all floating point operations from the code?
>
> I am attaching the below, any comment would be appreciated. Naturally not all the
> code is included.
>
> Shlomo.
> (Jeff)
> The algorithm is an adaptive noise cancellation algorithm ( LMS ) which involves
> multiplication by a what is known as a convergence factor, mu, which is typically
> in the range of .0001 to .1. That is the reason I was using SP floating point and
> that is why I converted 16-Bit PCM to float. I gained knowledge by doing so and I
> am happy i
> did so but I am always willing to do it better if that is possible even though I
> spent a lot of time making it work in floating point. Initially,I tried to
> represent "mu" as a fraction between two short integers but that didnt go very
> well but I am sure it can be done
> and would be happy for any suggestion in that direction as it would save CPU
> cycles.
Sounds like an echo can type algorithm, in which case yes I agree -- get it working
in "conventional floating-point format" first, make it match your MATLAB or host C
code, etc.
Once it's working, then worry about optimizing for real-time.
-Jeff
> (Nero)
> First thank a lot for the long and detailed reply :)
> I followed your suggestion to use x_n = ldexpf (x_n, -15); I am ju st not sure that
> this library routine is faster then multiplication on the C6711. And another issue
> is with the compiler. As I understand, adding a function call inside a l loop
> disqualifies the loop for software pipelining and in that case the call to ldexpf
> would disqualify the loop while the multiplication would not (please correct me if
> i am wrong)
> regarding the issue of converting back to Int16 from float:
> 1-In which header file is SIGNED_1b15_MAX defined?
> 2-Adding a conditional if statement in my ISR would make it work much slower as
> conditional statements (branch instructions) costs
> 6 CPU cycles. Is there an alternative ? Or maybe as Jeff suggested
> remove all floating point operations from the code?
>
> I am attaching the below, any comment would be appreciated. Naturally not all the
> code is included.
>
> Shlomo.
Reply by ●January 6, 20062006-01-06
It's often quite amazing for me of how well the world's been constructed,
except, of course, the Windows OS :)
You've been used a wrong method with "good" data, that's why you never
spotted the error. I might be wrong here and you might quite well know
what's the trick, but just in case look at the Table 85. TMS320C6700
C/C++ Compiler Intrinsics in spru187 :)
The problem is that _rscsp() returns only an 8 bit correct reciprocal
estimate to a number further used in N-R type iterations. The "good"
thing is that the floating point representation of 2**(-15) does not
have non-zero bits in the significand at all :) That's why the 8 bit
good approximation is exact for any number of bit in mantissa.
Regards,
Andrew
P.S. Sorry, last time I kind of "foobar"-ed the subject line...
> Date: Wed, 04 Jan 2006 19:04:03 -0000
> From: "shlomo_kashani" <shlomo_kashani@shlo...>
> Subject: Re: Digest Number 1358
>
> Dear Andrew,
> Thanks for the reply.
>
> Invocation of the _rcpsp(32678) function returns a single precision
> floating point value of normalizedScale=3.0517578125e-5 which is
> later used for the conversion and is the value you have quoted.
> I did not define 3.051758e-05 as a constant ... I used whatever the
> function was returning ... it was the fault of the "watch window"
> which ignored the last 3 bits (125). I DID use the correct value, the
> code comment was just showing the value from the watch window.
> Anyway, thanks for pointing that out.
>
> Shlomo. > --- In c6x@c6x@..., Andrew Nesterov <andrew.nesterov@t...>
> wrote:
>>
>>
>> Happy New Year to all.
>>
>>> Date: Mon, 2 Jan 2006 17:51:16 -0800 (PST)
>>> From: "Shlomo K." <shlomo_kashani@y...>
>>> Subject: Re: short to single precision floating point conversion
>>>
>>> I followed your suggestion to use x_n = ldexpf (x_n, -15); I am
> just not
>>> sure that this library routine is faster then multiplication on
> the C6711.
>>
>> In this very patricular case calling ldepf() is absolutely waste of
> time.
>> Sorry.
>>
>> If you know for sure that there are no floating point exact zeroes
> in your
>> data, you can subtract 15 from the exponent bits of the floating
> point number
>> to be scaled, which takes only 1 cycle of the CPU time.
>>
>> Alternatively, if you are not sure about exact zeroes, modify your
> factor
>>
>>> float normalizedScale=0.0f;
>>> /* Updated in lmsInit to 3.051758e-05 */
>>
>> to be 3.0517578125e-5, which is *exact* 1/32768 in floating point
>> (check the hex masks) and scale by this factor. It takes 4 cycles.
>> The value you've used so far is not an exact reciprocal of 32768,
>> so when you convert back by multiplying by 32768, you've got
>> incorrect results.
>>
>> Rgds,
>>
>> Andrew
>>
>
>
Reply by ●January 6, 20062006-01-06
Andrew,
The build in C67xx library function _rcpsp maps directly
to the assembly instruction rcpsp which is used to approximate 1/X. As you
correctly said, the Newton-Raphson iteration results in a reciprocal accurate
to 8 bits. Actually, I was neither aware of the error I
have done nor have I understood your explanation. What is the
significance of " ... the floating point representation of 2**(-15) does not
have non-zero bits in the significand at all ..."
Thanks,
Shlomo.
Andrew Nesterov <a...@techemail.com> wrote:
Andrew Nesterov <a...@techemail.com> wrote:
It's often quite amazing for me of how well the world's been constructed,
except, of course, the Windows OS :)
You've been used a wrong method with "good" data, that's why you never
spotted the error. I might be wrong here and you might quite well know
what's the trick, but just in case look at the Table 85. TMS320C6700
C/C++ Compiler Intrinsics in spru187 :)
The problem is that _rscsp() returns only an 8 bit correct reciprocal
estimate to a number further used in N-R type iterations. The "good"
thing is that the floating point representation of 2**(-15) does not
have non-zero bits in the significand at all :) That's why the 8 bit
good approximation is exact for any number of bit in mantissa.
Regards,
Andrew
P.S. Sorry, last time I kind of "foobar"-ed the subject line...
> Date: Wed, 04 Jan 2006 19:04:03 -0000
> From: "shlomo_kashani"
> Subject: Re: Digest Number 1358
>
> Dear Andrew,
> Thanks for the reply.
>
> Invocation of the _rcpsp(32678) function returns a single precision
> floating point value of normalizedScale=3.0517578125e-5 which is
> later used for the conversion and is the value you have quoted.
> I did not define 3.051758e-05 as a constant ... I used whatever the
> function was returning ... it was the fault of the "watch window"
> which ignored the last 3 bits (125). I DID use the correct value, the
> code comment was just showing the value from the watch window.
> Anyway, thanks for pointing that out.
>
> Shlomo.> --- In c...@yahoogroups.com, Andrew Nesterov
> wrote:
>>
>>
>> Happy New Year to all.
>>
>>> Date: Mon, 2 Jan 2006 17:51:16 -0800 (PST)
>>> From: "Shlomo K."
>>> Subject: Re: short to single precision floating point conversion
>>>
>>> I followed your suggestion to use x_n = ldexpf (x_n, -15); I am
> just not
>>> sure that this library routine is faster then multiplication on
> the C6711.
>>
>> In this very patricular case calling ldepf() is absolutely waste of
> time.
>> Sorry.
>>
>> If you know for sure that there are no floating point exact zeroes
> in your
>> data, you can subtract 15 from the exponent bits of the floating
> point number
>> to be scaled, which takes only 1 cycle of the CPU time.
>>
>> Alternatively, if you are not sure about exact zeroes, modify your
> factor
>>
>>> float normalizedScale=0.0f;
>>> /* Updated in lmsInit to 3.051758e-05 */
>>
>> to be 3.0517578125e-5, which is *exact* 1/32768 in floating point
>> (check the hex masks) and scale by this factor. It takes 4 cycles.
>> The value you've used so far is not an exact reciprocal of 32768,
>> so when you convert back by multiplying by 32768, you've got
>> incorrect results.
>>
>> Rgds,
>>
>> Andrew
><*> To visit your group on the web, go to:
http://groups.yahoo.com/group/c6x/
<*> To unsubscribe from this group, send an email to:
c...@yahoogroups.com
<*>
Yahoo! Photos
Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
