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.

Question:C6416 EMIFB for float data communication

Hi

   I have a question about the C6416 application and hope to get your support.

 

   1. EMIFB (bus band--16bit, USB interface), the DSP board (slave USB device), the data type (float, 32bit), CCS version (2.2), (relative csl6400e.lib and the rts6400e.lib);

 

   2. Data communication:

(1). the process (USB hostàUSB device, i.e. from USB host to DSP board via EMIFB) is OK. I transform my float data twice (16 bits for one time);

(2). C6416 is designed for the fix point, while I run my float data computing smoothly, by the standard C language and rts6400e.lib in my application;

(3). the issue exists in the process (USB device à USB host, i.e. from DSP board to USB host via EMIFB). I also transform my float data twice (16 bits for one time) and get some different data (some data is OK) at this time;

(4). detailed information for (3):

e.g.

original data:

float data[128;]

for(i=0;i<128;i++)

{

data[i]=i+0.1;

}

 

data I get from the process (USB device à USB host, i.e. from DSP board to USB host via EMIFB)

0.100000  1.100000  2.100000  3.100000  4.100000  5.100000  6.100000  7.100000  8.100000  9.100000  10.100000  11.100000  12.100000  13.100000  14.100000  15.100000  16.100000  17.100000  18.100000  19.100000  20.100000  21.100000  22.100000  23.100000  24.100000  25.100000  26.100000  27.100000  28.100000  29.100000  30.100000  31.100000  32.099998  33.099998  34.099998  35.099998  36.099998  37.099998  38.099998  39.099998  40.099998  41.099998  42.099998  43.099998  44.099998  45.099998  46.099998  47.099998  48.099998  49.099998  50.099998  51.099998  52.099998  53.099998  54.099998  55.099998  56.099998  57.099998  58.099998  59.099998  60.099998  61.099998  62.099998  63.099998  64.099998  65.099998  66.099998  67.099998  68.099998  69.099998  70.099998  71.099998  72.099998  73.099998  74.099998  75.099998  76.099998  77.099998  78.099998  79.099998  80.099998  81.099998  82.099998  83.099998  84.099998  85.099998  86.099998  87.099998  88.099998  89.099998  90.099998  91.099998  92.099998  93.099998  94.099998  95.099998  96.099998  97.099998  98.099998  99.099998  100.099998  101.099998  102.099998  103.099998  104.099998  105.099998  106.099998  107.099998  108.099998  109.099998  110.099998  111.099998  112.099998  113.099998  114.099998  115.099998  116.099998  117.099998  118.099998  119.099998  120.099998  121.099998  122.099998  123.099998  124.099998  125.099998  126.099998  127.099998

3, what do you think my way for float data communication via EMIFB? By the way, I do not use the latest CCS 3.3 since the board is designed by SEED Company and the CCS 3.3 version can not connected the target board and I need upgrade my hardware (from XD510 to higher level).

 

Thanks for your attention

Best Regards

 

 

 

 

  • wqyhandsome said:

    (1). the process (USB hostàUSB device, i.e. from USB host to DSP board via EMIFB) is OK. I transform my float data twice (16 bits for one time);

    This is not clear to me what you mean that you are doing. I will assume that you are splitting a 32-bit float into two 16-bit words to be transferred over the USB connection.

    wqyhandsome said:

     

    (3). the issue exists in the process (USB device à USB host, i.e. from DSP board to USB host via EMIFB). I also transform my float data twice (16 bits for one time) and get some different data (some data is OK) at this time;
    0.100000  1.100000  2.100000  3.100000  4.100000  5.100000  6.100000  7.100000  8.100000  9.100000  10.100000  11.100000  12.100000  13.100000  14.100000  15.100000  16.100000  17.100000  118.099998  119.099998  120.099998  121.099998  122.099998  123.099998  124.099998  125.099998  126.099998  127.099998

    Again, it is not completely clear what the issue is. I will guess that you do not like the fractional part being .099998 instead of .100000. But if this is floating point, do you have the accuracy that you expected? Are you expecting more accuracy than a 32-bit float will provide?

     

    wqyhandsome said:

     

    3, what do you think my way for float data communication via EMIFB?

     

    I think your way is okay. To prove out that the USB communication process is correct, examine the binary representations on the DSP and on the host and compare them. If they are identical, then you have a perfect USB communication process implemented. And I think you probably do.

    You may want to refer to the C6000 C Compiler user's Guide, spru187. My version is spru187o and page 156 section 7.2.1.2 shows the storage format for the 32-bit data types, including float which includes a 23-bit mantissa. Is that the issue?

  • RandyP,

       Thanks for your kindly support, and you get my key point.

    1.       Process: data stream (USB hostàUSB device (DSP board)) is OK, and the DSP can compute my float data correctly. No problem here. I done it as you mentioned (split a 32-bit float into two 16-bit words to be transferred over the USB connection via EMIFB).

    2.       When transferring the data that computed in DSP into USB host, I can not get the same data as them show in the CCS (as you know, I can see the computed result via watch window in CCS environment). This is my issue. E.g. the result data in CCS watch window is 118.100000 while it changed into 118.099998 when I transfer it to USB host. 118.100000 is different from the 118.099998, I personally think.

    3.       Since my application involves DSP, SDRAM, and the USB 2.0 chipset, the issue maybe located in other aspect expect DSP side. I will have a try in other sides.

     

    Best Regards

  • Does the 32-bit binary value match on both sides, DSP and Host? Not the displayed float value but the binary value stored in memory.

    The binaries may match, in which case the issue would be that the two processors round the display value differently at the Least Significant Bit.

  • RandyP,

    Thanks for your information.

    Regards