• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 746 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.

One line code change causes code to execute 6.7 times slower

Teddy13640
Prodigy 200 points

Other Parts Discussed in Thread: TMS320F28335

Hello,

I have the following section of code that I am running on a TMS320F28335 using the experimenter kit.
I'm using Code Composer Studio 3.3.81.28 and am compiling for release. I am most interested in the
amount of time that it will take to execute this section of code. To measure the time for the code to execute
I monitor the GPIO32 pin which set as the code begins, and is cleared when the code ends. This
takes about 94 nanoseconds with the processor running at 150MHz.

At the one line indicated with a comment, if it is changed to GpioDataRegs.GPBCLEAR.bit.GPIO33 = 1;
then the code takes 630ns to execute.

Does anyone know why this is so, and is there some better way to toggle I/O bits?

 

Thanks,

Chris

 

 

 

      GpioDataRegs.GPBSET.bit.GPIO32 = 1;
      //========================================
       count=0;
       evensample=*adc_ptr++;
       count += abs(evensample-oddsample);
       oddsample=*adc_ptr++;
       count += abs(evensample-oddsample);
       evensample=*adc_ptr++;
       count += abs(evensample-oddsample);
       oddsample=*adc_ptr++;
       count += abs(evensample-oddsample);

       evensample=*adc_ptr++;
       count += abs(evensample-oddsample);
       oddsample=*adc_ptr++;
       count += abs(evensample-oddsample);
       evensample=*adc_ptr++;
       count += abs(evensample-oddsample);
       oddsample=*adc_ptr++;
       count += abs(evensample-oddsample);
       if (count > 1900)
       {
          GpioDataRegs.GPBSET.bit.GPIO33 = 1;  // <<<<<<<  Slows if you change this with GPBCLEAR
       }
       else
       {
          GpioDataRegs.GPBSET.bit.GPIO33 = 1;
       }
       GpioDataRegs.GPBCLEAR.bit.GPIO32 = 1;
      //========================================

  • 0
    Prodigy 200 points

    Further information:

    This is how the GPIOs are set up

       EALLOW;
       GpioCtrlRegs.GPBMUX1.bit.GPIO33 = 0;    // GPIO pin
       GpioCtrlRegs.GPBDIR.bit.GPIO33 = 1;     // Output pin
       GpioDataRegs.GPBCLEAR.bit.GPIO33 = 1;

       GpioCtrlRegs.GPBMUX1.bit.GPIO32 = 0;    // GPIO pin
       GpioCtrlRegs.GPBDIR.bit.GPIO32 = 1;     // Output pin
       GpioDataRegs.GPBCLEAR.bit.GPIO32 = 1;
       EDIS;

  • 0 in reply to Teddy13640
    Mastermind 7585 points

    Chris,

    I am pretty sure that there is something wrong with your 90 ns - measurement result. A F28335 at 150 MHz takes 6.67 ns per machine code instruction. Your code snippet consists of approximately 20 C-lines, including mulitple calls of the abs-function, pointer increments, etc.  The C - compiler will need definitely more than 1 machine instruction per C-code line! So I guess 640 ns is more appropriate to execute this code block. When you inspect the resluting *.asm - file of you code (or mixed mode in CCS) , you can count the number of assembly instructions.

    Btw, are your sure that your F28335 runs actually at 150 MHz? My F28335ControlCard here driven by at 20MHz external clock, the maximum PLL (according to the data sheet) is 10/2, which gives a 100 MHz CPU - frequency.  

    Regards

     

      

     

     

  • 0 in reply to Frank Bormann
    Prodigy 200 points

    Frank,

    I had a feeling that it was too good to be true. I revised the code to repeat the snippet in a loop and I'm looking at more like 810ns. I will have to rewrite this in assembly to get a slightly better time than what the compiler provides.

    Looking over the TI information, it looks like there may be some contention between the GPIO writing and the ADC taking place at the same time, so I was not sure if delays might occur on the GPIO instructions.

    With regard to the 150MHz, there is an E2E post somewhere that describes the Rev 1.1 in the board and how to work around the 20MHz crystal to run at 150MHz. It involves setting a register to what is currently an undefined value in the TI documentation. This change is in DSP2833x_Examples.h  where you set DSP28_PLLCR  to 15.

    Thanks Frank, this gets me back on track.

    Chris

  • 0 in reply to Teddy13640
    Mastermind 7585 points

    Chris,

    I would be careful with the PLLCR, regardless of the discussions here in this group. If you design a real world product, you have to rely on the data sheet, which say's PLL - multiply by 10 is maximum. Unless TI does not change the data sheet to allow PLL factors above 10, you can save your good nights sleep by staying with PLL = 10. If you need the 150 MHz so badly, it is much easier to replace the external clock by a 30MHz part.

    Btw, I have heard that a future revision of the TI F28335ControlCard will have a 30MHz extermal clock...

    Regards

     

     

  • 0 in reply to Frank Bormann
    TI__Guru** 119680 points

    Our prototype TMX silicon supported a 15/2 PLL, which would give 150 MHz on the controlCARD with the 20 MHz crystal.

    For TMS we had to reduce the datasheet spec to 10/2, so with the current controlCARD you would only run at 100 MHz.

    The TMS silicon will run fine in a development environment at 15/2 PLL, so you can test out 150 MHz operation on your controlCARD.

    The CURRENT F28335 controlCARD that you can purchase online has a 30 MHz crystal, so with 10/2 it supports 150 MHz.

    -Chris