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.

TMS320F28388D: Buffer index operation cost too much time as expected

Part Number: TMS320F28388D

Tool/software:

Hi,

I am using CLA to monitor the state of 32 input channels. The ClaTask1 will be triggered by the TINT1 and the Timer01 was set as 20usec. In ClaTask1, It will set on the test output pin when the task start, then execute recordStateInBit(), then it will set off the test output pin when the task end. The test output pin status will be the working time of ClaTask1.

The problem I faced is that if I use the “1.” way to read the pin, then the working time of ClaTask1 will be really long, about 50usec. And if I use the “2.” way then the working time of ClaTask1 will be really short, about 8usec. But I don't think that it will cause the working time to be so different. Do you have any idea of this?

The ChPinIdxBuf is put in RAMLS7



Best Regards,

Norman

  • Hi Nai,

    What is the data type being used for the ChPinIdxBuf array?

    I would expect option 2 to take longer because of the following: In option 2, you are passing a #define value into the GPIO_readPin() function, which means the input of the function will be processed at compile time. This minimizes the number of instructions needed by the CPU at runtime. In option 1, the CLA itself needs to execute instructions to grab the i'th element ChPinIdxBuf before passing the value into the function. 

    You can look at the actual assembly code being executed by navigating to View >> Disassembly in your CCS window while debugging your code. This will give some more indication to why the different lines have different execution times. Likely option 1 generates less lines of assembly for the CLA to run. 

    Another note, you usually only want to call inline functions in CLA code to reduce branching instructions done by the CLA (since the CLA has a smaller stack- called the scratchpad, than a normal CPU). I would suggest making recordStateInBit() and inline function. 

    Best Regards,

    Delaney

  • Hi Delaney,

    Really thanks your suggestion, I have checked the disassembly code and I think I have some conclusions:

    There are division and modulus maths in the GPIO_readPin(uint32_t pin) function, and as I know CLA is not really good at division and modulus operation.

    Then I checked the disassembly for Option 1 and Option 2,

     I have found that if I use the Option 1,  the $C$L4 part will repeat lot of times, and the repeat times is equals to the (pin%32U). My MONITOR_CHANNELS is defined as 32, and my TestInputPin is difined as 91. So $C$L4 part will repeat 32*27 times in once ClaTask1. It will really cost tens of microseconds. I am not really familiar with the instructions of CLA, but I think this part is about the modulus operation.

     (Option 1 Diassembly code)

    And I have found if I used Option 2, the disassembly code is only few instructions, I think it is because that Option 2 passed a #define value, so the division and modulus maths in GPIO_readPin() can be operated by the compiler to short lots of time in runtime.

     (Option 2 Diassembly code)

    Is my understanding right?

    Then because in my case, the pin be monitored will not be changed in runtime, so I think I may directly call GPIO_readPin( PIN_MONITOR_x) for 32 times, and which the PIN_MONITOR_1~PIN_MONITOR_32 will be #defined so that I can make compiler do the division and modulus maths to short the operation time of CLA. Although this makes the code looks really long and ugly, but this is the best way I can think, or there are another way?

  • Hi Nai,

    Yes, you are correct. You will get the best performance by using different compiler defines for the input of the GPIO_readPin() as you have stated. CLA code unfortunately requires some uglier code at times since the instruction set is smaller and not as efficient for some operations.

    Best Regards,

    Delaney