|
Today I noticed that the Motorola SDK tf16SinPIx() returns unexpected values for the following: tf16SinPIx(0x4000) = 0x8000 // expected 0x7fff tf16SinPIx(0x8000) = 0xc5a8 // expected 0x0000 Any one else have similar results? Also, all other values seem to work fine. Jacob Christ |
|
|
SDK tf16SinPIx
Started by ●October 30, 2002
Reply by ●October 31, 20022002-10-31
|
I could not find the function "tf16SinPIx" in the SDK, the nearest
one I could find is "tfr16SinPIx" in the file "tfr16.c" in the directory "...\src\dsp56807evm\nos\signal\dspfunc" (for the 807 chip), where "..." is the base directory where you installed the SDK. This same directory has the file "basic_op.c", which has many of the common utility functions for 16-bit and 32-bit values (add, subtract, negate, etc.). It is important to note that these utility functions often perform overflow control and saturation on the data supplied to them. The function "tfr16SinPIx" first does a negation if the input data is negative, so that all operations inside the function are performed on positive data. The value 0x8000 (== MIN_16) is trapped by the negate() function in "basic_op.c", which returns MAX_16 (== 0x7FFF) for this value. So, tfr16SinPIx(0x8000) is actually equal to: -(tfr16SinPIx(0x7FFF)) The value 0x8000 as a FRAC16 value is negative one (-1.0), which when negated is 0x7FFF, which is as close as you can get to positive one (== 1.0 - 2^-15). This is described in the DSP56800 Family Manual, in Section 3.3.1 "Interpreting Data", and Section 3.3.2 "Data Formats". This makes tfr16SinPIx(0x8000) equal to: -(tfr16SinPIx(1.0 - 2^-15)) Also using the fact that 0x8000 is -1.0, and 0x4000 is 0.5, this makes tfr16SinPIx(0x4000) equal to: tfr16SinPIx(0.5) The result you get is -1.0 (0x8000). The function header for "tfr16SinPIx" is shown below, which explains the calculations that are performed. /*******************************************************************************\ * * File Name : tfr16.c * * * * Function : Frac16 tfr16SinPIx (Frac16 x) * * * * Description: * * This routine computes sine(pi*x) * * * * Inputs : * * 1) x - input data value * * * * Outputs : * * 1) z - sine(pi*x) * * * * Algorithm : * * if(x > 0.5) * * sin(pi*x) = sin(pi*(1-x)) * * * * * * z = x(SineCoefs(0)+x^2(SineCoefs(1)+x^2(SineCoefs(2)+x^2(SineCoefs(3)+ * * x^2(SineCoefs(4)+x^2(SineCoefs(5)+SineCoefs(6)x^2)))))) * ********************************************************************************\ / The SineCoefs are: const Frac16 SineCoefs[] = { FRAC16(0.39269908169872), FRAC16(-0.64596409750625), FRAC16(0.31877050498467), FRAC16(-0.07446482317004), FRAC16(0.01026823582639), FRAC16(-0.00092130386821), FRAC16(0.00005828785072) }; tfr16SinPIx(0x4000) should equal to: sine(pi/2) which is 1.0, but the closest possible value is 0x7FFF (1.0 - 2^-15), the value you expected to get. Similarly, tfr16SinPIx(0x8000) should equal to: sine(-pi) which is 0.0 (0x0000), again the value you expected to get. I have not used the "tfr16SinPIx" function, but the values you are getting do look to be bad. One thing you could check is the setting of the OMR's Saturation (SA), Rounding (R), and Condition Code (CC) bits, which affect the saturation, limiting, and rounding of the data in the accumulators (A and B). Please see the following Sections in the DSP56800 Family Manual: Section 3.4 "Saturation and Data Limiting" Section 3.4.2 "MAC Output Limiter" Section 3.5 "Rounding" Section 3.6 "Condition Code Generation" Section 5.1.9 "Operating Mode Register" I hope this helps. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com -----Original Message----- From: Jacob Christ [mailto:] Sent: Wednesday, October 30, 2002 1:42 PM To: Subject: [motoroladsp] SDK tf16SinPIx Today I noticed that the Motorola SDK tf16SinPIx() returns unexpected values for the following: tf16SinPIx(0x4000) = 0x8000 // expected 0x7fff tf16SinPIx(0x8000) = 0xc5a8 // expected 0x0000 Any one else have similar results? Also, all other values seem to work fine. Jacob Christ _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●October 31, 20022002-10-31
|
Sorry, tfr16SinPIx is the function I meant. Believe it or not there is
only one computer where I work with internet access, and it's not mine, so I had to jot a note on a piece of paper and dropped the "r" when I composed the message. Thanks for our great response... I stumbled on to not quite the same level of understanding within a couple of hours after finding this problem. I started using the RFFT functions and all of a sudden the tfr16SinPIx function started working. This jarred my memory about other discussions I had seen and I assumed that it must have been a saturation problem. My assumption was not as good as Art's explanation thought. I would have posted my findings as a reply to my own problem, but since this message board is moderated and my message had not yet been posted I figured I would wait until this morning. Thanks again Art, Motorola should give you royalties for every DSP chip they sell (IMHO). Jacob -----Original Message----- From: Art Johnson [mailto:] Sent: Thursday, October 31, 2002 6:25 AM To: Jacob Christ; Subject: RE: [motoroladsp] SDK tf16SinPIx I could not find the function "tf16SinPIx" in the SDK, the nearest one I could find is "tfr16SinPIx" in the file "tfr16.c" in the directory "...\src\dsp56807evm\nos\signal\dspfunc" (for the 807 chip), where "..." is the base directory where you installed the SDK. This same directory has the file "basic_op.c", which has many of the common utility functions for 16-bit and 32-bit values (add, subtract, negate, etc.). It is important to note that these utility functions often perform overflow control and saturation on the data supplied to them. The function "tfr16SinPIx" first does a negation if the input data is negative, so that all operations inside the function are performed on positive data. The value 0x8000 (== MIN_16) is trapped by the negate() function in "basic_op.c", which returns MAX_16 (== 0x7FFF) for this value. So, tfr16SinPIx(0x8000) is actually equal to: -(tfr16SinPIx(0x7FFF)) The value 0x8000 as a FRAC16 value is negative one (-1.0), which when negated is 0x7FFF, which is as close as you can get to positive one (== 1.0 - 2^-15). This is described in the DSP56800 Family Manual, in Section 3.3.1 "Interpreting Data", and Section 3.3.2 "Data Formats". This makes tfr16SinPIx(0x8000) equal to: -(tfr16SinPIx(1.0 - 2^-15)) Also using the fact that 0x8000 is -1.0, and 0x4000 is 0.5, this makes tfr16SinPIx(0x4000) equal to: tfr16SinPIx(0.5) The result you get is -1.0 (0x8000). The function header for "tfr16SinPIx" is shown below, which explains the calculations that are performed. /*************************************************************************** ***** * File Name : tfr16.c * * * * Function : Frac16 tfr16SinPIx (Frac16 x) * * * * Description: * * This routine computes sine(pi*x) * * * * Inputs : * * 1) x - input data value * * * * Outputs : * * 1) z - sine(pi*x) * * * * Algorithm : * * if(x > 0.5) * * sin(pi*x) = sin(pi*(1-x)) * * * * * * z = x(SineCoefs(0)+x^2(SineCoefs(1)+x^2(SineCoefs(2)+x^2(SineCoefs(3)+ * * x^2(SineCoefs(4)+x^2(SineCoefs(5)+SineCoefs(6)x^2)))))) * **************************************************************************** ****/ The SineCoefs are: const Frac16 SineCoefs[] = { FRAC16(0.39269908169872), FRAC16(-0.64596409750625), FRAC16(0.31877050498467), FRAC16(-0.07446482317004), FRAC16(0.01026823582639), FRAC16(-0.00092130386821), FRAC16(0.00005828785072) }; tfr16SinPIx(0x4000) should equal to: sine(pi/2) which is 1.0, but the closest possible value is 0x7FFF (1.0 - 2^-15), the value you expected to get. Similarly, tfr16SinPIx(0x8000) should equal to: sine(-pi) which is 0.0 (0x0000), again the value you expected to get. I have not used the "tfr16SinPIx" function, but the values you are getting do look to be bad. One thing you could check is the setting of the OMR's Saturation (SA), Rounding (R), and Condition Code (CC) bits, which affect the saturation, limiting, and rounding of the data in the accumulators (A and B). Please see the following Sections in the DSP56800 Family Manual: Section 3.4 "Saturation and Data Limiting" Section 3.4.2 "MAC Output Limiter" Section 3.5 "Rounding" Section 3.6 "Condition Code Generation" Section 5.1.9 "Operating Mode Register" I hope this helps. Regards, Art Johnson Senior Systems Analyst PMC Prime Mover Controls Inc. 3600 Gilmore Way Burnaby, B.C., Canada V5G 4R8 Phone: 604 433-4644 FAX: 604 433-5570 Email: http://www.pmc-controls.com -----Original Message----- From: Jacob Christ [mailto:] Sent: Wednesday, October 30, 2002 1:42 PM To: Subject: [motoroladsp] SDK tf16SinPIx Today I noticed that the Motorola SDK tf16SinPIx() returns unexpected values for the following: tf16SinPIx(0x4000) = 0x8000 // expected 0x7fff tf16SinPIx(0x8000) = 0xc5a8 // expected 0x0000 Any one else have similar results? Also, all other values seem to work fine. Jacob Christ _____________________________________ Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. _____________________________________ About this discussion group: To Join: To Post: To Leave: Archives: http://www.yahoogroups.com/group/motoroladsp More Groups: http://www.dsprelated.com/groups.php3 ">http://docs.yahoo.com/info/terms/ |
