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.

TMS320F28379S: Tformat Migration

Part Number: TMS320F28379S

Hi, Champs,

My customer is using F28379S to implement Tamagawa encoder and there's a question on getting the data correctly.

As you know, below codes used to read position are placed in while(1), while in real application, customer hopes to read it in the current loop interrupt which is 16kHz@62.5us.

Problem is that, when those codes are moved to current loop where has higher interrupt priority, the SPI interrupt used to receive data will be not serviced correctly due to lower interrupt priority. Do we have a solution to support getting position feedback in a faster way?

With this background, we thought about several approaches:

a. Add a condition to run below codes as a function like below:

    if(tformatData.dataReady == 1)
    {

        CLB_Get_TamagawaAbsEncoder(); // This function contains below codes

    }

 But it takes more than 70us to execute, which is not acceptable in customer system.

Can we verify if the 70us is resulted by the SPI ISR or the "    while (tformatData.dataReady != 1) {}" statement?

b. We can try CLA to run to SPI interrupt and tformat library based on CLB, and we know CLA can support SPI but can it support running CLB?

c. We can also use DMA to transfer data from SPI to a RAM buffer with FIFO support, but we still need to do CRC check and CLB logic, where can we find a flag to do that polling?

    retval2 = PM_tformat_setupCommand(DATAID3, 0, 0, 0);
    PM_tformat_startOperation();
    while (tformatData.dataReady != 1) {}
    retval2 = PM_tformat_receiveData(DATAID3);

    crcResult = PM_tformat_getCRC(0, 80, 8, (uint16_t *)&tformatData.rxPkts, tformatCRCtable, 10);
    crcResult = crcResult ^ (0xFF);
     if(!CheckCRC(crcResult,tformatData.crc))
     {
             ESTOP0;
     }

     //Invert the received bit sequence for position and turns for actual data
     position = ((__flip32((uint32_t) tformatData.dataField0) >> 24 ) & 0xFF)|
                ((__flip32((uint32_t) tformatData.dataField1) >> 16 ) & 0xFF00)|
                ((__flip32((uint32_t) tformatData.dataField2) >> 8 )  & 0xFF0000);

     turns = ((__flip32((uint32_t) tformatData.dataField4) >> 24 ) & 0xFF)|
                ((__flip32((uint32_t) tformatData.dataField5) >> 16 ) & 0xFF00)|
                ((__flip32((uint32_t) tformatData.dataField6) >> 8 )  & 0xFF0000);

Best Regards,

Ricky Zhang

  • Ricky,

    a. In customer code, there is no need to wait "while (tformatData.dataReady != 1) {}" - this is an example code and customer can do some other operation in parallel and address the SPI interrupt when data is ready. So, there is no need to wait in this loop.

    b. As a device feature CLB can also be accessed by CLA but the library we released only works with CPU. Hence for now you will not be able to use CLA for tformat library example.

    c. Flag indicating the the data is received is "tformatData.dataReady". This is set inside the SPI ISR in tformat.c. The CRC check still need to be executed from the CPU after the data is received.
  • Bharathi,

    Thanks for your response.

    Subrahmanya said:

     
    a. In customer code, there is no need to wait "while (tformatData.dataReady != 1) {}" - this is an example code and customer can do some other operation in parallel and address the SPI interrupt when data is ready. So, there is no need to wait in this loop.

    Do we have to use a SPI ISR to receive data? Can we read SPI data by polling something in current loop?

    Should we use DMA to transfer SPI data, and then handle the received data in a DMA ISR to save time?

    Subrahmanya said:

     
    c. Flag indicating the the data is received is "tformatData.dataReady". This is set inside the SPI ISR in tformat.c. The CRC check still need to be executed from the CPU after the data is received.

    My customer tried this way below.

    By checking tformatData.spi->SPIFFRX.bit.RXFFST in current loop, he can get position information correctly, while the execution time ~17us is still too long for his application and he prefers to optimize it to 5~6us, do you have any suggestions for below codes?

    Uint16 i = 0;

        if(tformatData.spi->SPIFFRX.bit.RXFFST >= 4)
        {
            for (i=0;i<=tformatData.fifo_level;i++){tformatData.rdata[i]= tformatData.spi->SPIRXBUF;}
            tformatData.dataReady=1;
        }

        if(tformatData.dataReady == 1)
        {
            retval2 = PM_tformat_setupCommand (DATAID3, 0, 0, 0);
            PM_tformat_startOperation();

            if(tformatData.spi->SPIFFRX.bit.RXFFST >= 4)
            {
                for (i=0;i<=tformatData.fifo_level;i++){tformatData.rdata[i]= tformatData.spi->SPIRXBUF;}
                tformatData.dataReady=1;
            }

            retval2 = PM_tformat_receiveData(DATAID3);

            crcResult = PM_tformat_getCRC(0, 80, 8, (uint16_t *)&tformatData.rxPkts, tformatCRCtable, 10);
            crcResult = crcResult ^ (0xFF);

             if (!CheckCRC(crcResult,tformatData.crc))
             {
                 CRC_ErrorCnt ++;
                 gstr_GlobalVar.CLB_Tamagawa_Abs_Ready = 0;
        //         PostErrMsg(ENFBCHKERR);
                 PositionErr = position;
             }
             else
             {
                 //Invert the received bit sequence for position and turns for actual data
                 position = ((__flip32((uint32_t) tformatData.dataField0) >> 24 ) & 0xFF)|
                            ((__flip32((uint32_t) tformatData.dataField1) >> 16 ) & 0xFF00)|
                            ((__flip32((uint32_t) tformatData.dataField2) >> 8 )  & 0xFF0000);

                 gCLB_Tamagawa_AbsPos = position;
                 gstr_GlobalVar.CLB_Tamagawa_Abs_Ready = 1;

                 turns = ((__flip32((uint32_t) tformatData.dataField4) >> 24 ) & 0xFF)|
                            ((__flip32((uint32_t) tformatData.dataField5) >> 16 ) & 0xFF00)|
                            ((__flip32((uint32_t) tformatData.dataField6) >> 8 )  & 0xFF0000);
             }
        }

    Subrahmanya said:

     
    b. As a device feature CLB can also be accessed by CLA but the library we released only works with CPU. Hence for now you will not be able to use CLA for tformat library example.
     

    Thanks for your confirmation.

    Best Regards,

    Ricky Zhang

  • Hi,

    Ricky Zhang said:
    Do we have to use a SPI ISR to receive data? Can we read SPI data by polling something in current loop?

    Yes - you could use the flag, interrupt is generated based on the receive FIFO status. You could pose the same.

    Ricky Zhang said:
    Should we use DMA to transfer SPI data, and then handle the received data in a DMA ISR to save time?

    To transfer the SPI data, you need to use the PM lib function, as the data is adjusted (start/stop and extra buffer bits) as needed by the implementation using CLB.

    When you say the time taken is ~17us is it the time for the actual transaction on the physical layer?
    This time is more or less fixed, depending on the command (DataID) and number of bits in the transaction * bit duration.

  • Hi, Subrahmanya

    the time taken is ~17us is it not the time for the actual transaction on the physical layer ,After measurement, There is Three functions take up too much time. 

    This function " retval2 = PM_tformat_receiveData(DATAID3);    "takes 12us,

    This function " retval2 = PM_tformat_setupCommand (DATAID3, 0, 0, 0);  and  This function  " PM_tformat_startOperation();  "  takes 3.9us,

    Can the execution time of the above three functions be reduced by some optimization? The current execution time is unacceptable.

  • Does these numbers match or come close to the numbers specified in the library guide? These numbers seem higher than anticipated.

  • Hi Zhang,
    Did you get a chance to compare with the cycle count numbers provided in library user guide? Numbers look higher than anticipated.
  • Zhang,

    Can you close this now?
  • Hi, Do you have any update? can we close this thread now?