• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 217 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320C6748 floating point problem ?

Doug Kim
Intellectual 300 points

Hi,

I'm trying to do realtime autio processing environment using L138/TMS320C6748.

This is sample base processing and I need floating point calculation, that's why

I just test for int32_t to float and float to int32_t, but it doesn't work well.

int32_t dat;

double dTmp,sum;

 const double  dTmp2 = (1<<24);

float fDat;

 

..... initialize

while (!CHKBIT(MCASP->SRCTL12, RRDY)) {}                                    

           dat = MCASP->XBUF12;   

           dTmp = (double) dat;

           dTmp = dTmp / dTmp2;                 

       sum = (double) fcoef01[0] * dTmp;       

      sum = sum + (double) fcoef01[1] * (double) memL[0];         // fcoef01[5] is float coefficient, and mem[4] also.

      sum = sum + (double) fcoef01[2] * (double) memL[1]; 

      sum = sum + (double) fcoef01[3] * (double) memL[2];     // it have problem, if this line comment out realtime audio not work.

// i was worry about dyname range overflow, that's why i did cast double precision.

// i did similar program in Visual studio, at that time it just float but work very well.

 

while (!CHKBIT(MCASP->SRCTL11, XRDY)) {}           

            MCASP->XBUF11 = dat;      

Code Composer Version : 5.4

Thanks in advance

  • 0
    TI__Guru* 84110 points

    Doug Kim,

    Doug Kim said:

          sum = sum + (double) fcoef01[3] * (double) memL[2];     // it have problem, if this line comment out realtime audio not work.

    This is an unusual situation. It is more common to find that adding more code would cause realtime audio to fail, and that commenting out a line would cause it to work. But you have said the opposite, that removing the line of code makes it not work right. Do I understand this correctly?

    Both RRDY and XRDY will become TRUE at about the same time since they both use the same Frame Sync. This means that you will have a race condition when you wait for one (and do some processing) and then wait for the other (and do some processing). Depending on what is happening in the loop above the code that is shown above, this is the most common situation to cause the application to miss a realtime deadline to either transmit or receive data. As I said above, this would normally be improved by commenting out a line of code.

    Are you using optimization? This does not look like a lot of code, but the design may require more speed than you are allowing in the program. Turn on optimization, at least with -o1, but -o2 or -o3 (Release Build Configuration) will be much faster than the default Debug Build Configuration.

    It is always best to let the EDMA handle your data traffic. It is best when you can wait for a buffer of input data and then process the whole input buffer, and then let the EDMA send out the output buffer. You may want to go to the TI Wiki Pages and search for "C6000 Workshop" (no quotes) to find our training material for using CCS and the C6000 architecture, including EDMA for audio applications.

    Can your project handle the audio latency of a buffer of data being stored before sending out the results? The latency is usually twice the time it takes to fill the buffer (fill the buffer, process it while the next buffer is being filled, then output it during the next buffer period); this is the ping-pong buffer method.

    Also, please refer to the Technical Reference Manual (TRM) or McASP User Guide to see when the RRDY and XRDY signals are brought active during the transmit and receive sequence. This will help you understand the race conditions, if any do exist.

    Regards,
    RandyP