• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 561 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.

Speed issues going from BIOS5 to BIOS6

Steve Runion
Intellectual 960 points
Other Parts Discussed in Thread: TMS320F28335

I have taken one of the minimal example projects available in CCS5 for BIOS5 and BIOS6 for use on the EZDSP28335. In each case the "task" example was used. In each case I attempted to minimize the OS overhead by eliminating any unnecessary modules.

I have code that can be summarized as such:

Clear pin GPIO32                     : the led on the EZDSP28335

Set pin GPIO32 1000 times      : I need a period that can be captured on my 200MHz scope.

Clear pin GPIO32                     : Finish the cycle.

These are done linearly with copied and pasted code so that no looping instructions would be required and I could get the purest measurement possible.

Based on measurements with the scope the run time for the identical code is ....

bios 5:   53.9 (uS)
bios 6:   321  (uS)

Certainly the overhead of BIOS6 cant be 6 times the overhead of BIOS5.

I have attached the CCS5 projects below.

0116.speed_test.zip

speed_test.zip
  • 0
    TI__Mastermind 30830 points

    Steve,

    I think the problem is that the b5 example is placing all the code and data into hi speed LO3SARAM & L47SARAM while the b6 example is placing all of the code in FLASH.

    For a more fair comparison, try modifying the TM320F28335.cmd file to place the .text section into LO7SARAM memory:

        .text               : > M01SARAM | L07SARAM PAGE 1

    You can try moving more sections into RAM and see how the performance is effected, but I think you'll notice a HUGE improvement simply by placing the .text section into RAM.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 960 points

    Alan,

       I made that change. My BIOS 6 code almost halves in time from 321uS down to 151uS. This is still a factor of 3 over the BIOS5 code. Any suggestions.

  • 0 in reply to Steve Runion
    TI__Mastermind 30830 points

    Your const pointers to the GPIO registers are being placed in flash.

    Using the same syntax, try moving the .econst, and .switch sections into RAM also.

    Alan

  • 0 in reply to Alan DeMars
    Intellectual 960 points

    Alan,

     Thanks again you are really helping me drill down. Last question. Looking at the time it takes for the signal to toggle 53uS (now the same on bios5 and bios6) and looking at the number of instructions (MOVL, ADDB, OR each 1 cycle I believe and this is linear code with no branches) 8015-8FB7 for 4002 instructions. This calculates to ~13nS per instruction. I am on the TMS320F28335 running 150MHZ which should have a cycle time of ~7nS. So my code is still running twice as long as it should. I can imagine BIOS adding 10, 20, or maybe 30% overhead. I suppose it could be that I am using debug built code. Any further closing advice.

     

    Thanks Much,

    Steve

  • 0 in reply to Steve Runion
    TI__Mastermind 30830 points

    Steve,

    As far as I can tell, the code you're measuring the performance of isn't using ANY BIOS APIs.

    Consequently, I think the performance must be solely defined by the memory the code is running in, the peripherals its accessing, and the compiler options you're building the application with. Beyond that, I don't know how to squeeze more out of the code.

    Certainly using the "Release" build option should improve performance. But when you're comparing BIOS 5 and BIOS 6, I think both version should behave equally given the code you're measuring.

    Alan

  • 0 in reply to Alan DeMars
    TI__Mastermind 30830 points

    I'm not sure if it applies with your hardware, but sometimes you can actually get better performance by lowering the clock speed.

    If the CPU is running so fast that every access to RAM requires a wait-state (or more) to be inserted in the cycle, and if by lowering the speed just a little you can eliminate this wait state, it may pay off big time to run a little slower...

    Alan