• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 474 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.

SYSBIOS on F28335: Clock module

Mathieu TARRIUS
Intellectual 900 points
Other Parts Discussed in Thread: SYSBIOS

Hi,

I am using the RTOS SYSBIOS "bios_6_35_04_50”" on the F28335 target.

In my application, I use the Clock module that allows to have periodic functions that are run in the context of a Swi (software interrupt) thread.

I would like to evaluate in this case what is exactly executed under hardware interrupt. In other words, for this feature, what is the length in CPU cycles of the hardware interrupt.

When I use the TI tool: RTOS Analyse-> Execuition Graph
 I can see:

#Hwi.ti_sysbios_knl_Clock_doTick__I() : 40 us at 60Mhz so around 2400 CPU cycles.

I am surprised of this important number of CPU cycles.

Could you indicate to me if it is normal ? or if I missed something ?

Thanks for your help,

Regards,

Mathieu

  • 0
    TI__Mastermind 20480 points

    Hi Mathiew,

    The System Analyzer execution graph is generated with the help of instrumented Log API function calls. I don't think they are well suited for sort of time measurements you're looking for with the Hwi dispatcher.

    I would refer to the benchmark times in the release notes and the SYS/BIOS User's guide. I think those numbers are much more realistic.

  • 0
    TI__Mastermind 20805 points

    Hi Mathieu --

    Since you are using the Exec Graph, you must have Logging enabled.  The kernel has code that is logging data at the beginning/end of each ISR, as well as a Log call within the Swi_post() call.  This will add some overhead, although the number you see is still bigger than I'd expect.

    The other thing that might be in review the FLASH wait states and the placement of your code.  I think you may need to add some code to your main() function to initialize the FLASH wait states to match your 60MHz CPU speed.

    -Karl-

  • 0 in reply to Karl Wechsler
    Intellectual 900 points

    Hi Karl and Tom,

    Thanks for your answer.

    Sorry for the delay.

    You are right!

    I need to do in my system the double check of the TI Benchmarking to know the latency introduced by SYSBIOS on the handling of the ISR.

    If I am not wrong this latency is equal to (form C28x large model Timing Benchmarks figure, ezdsp28335 platform compiler version 6.2.0B1)):

    * Interrupt Latency: 156 cycles

    * Hwi_dispatcher_prolog: 242 cycles

    Is it OK ?

    To measure this timings at the scope I instrumented the code to measure the time between:

    • the first line of code of the hardware interrupt handling of the SYSBIOS “Dispatcher”
    • the line of code before the line of code calling to the customer ISR

    First   line

    File: bios_6_35_04_50\packages\ti\sysbios\family\c28\Hwi_disp.s28

    Function:  

    _ti_sysbios_family_c28_Hwi_dispatchPie:  ; PIE dispatcher (plugs PIE vectors)

     

    Code do   set to LOW PIN TEST 1 (GPIO51):

     

            push      ACC

            mov     @AL, *(0:0x6fcd)   // 0x6fcd is the address of the register GpioDataRegs.GPBCLE  

            orb     AL, #0x8                   //    bit 3 is GPIO51

            mov     *(0:0x6fcd),@AL

            pop     ACC   

     

    Before   calling user ISR handler

    File: bios_6_35_04_50\packages\ti\sysbios\family\c28\Hwi.c

    Function:   Void Hwi_disptachCore(Int intNum)

     

        /* call the user's isr */

        if   (Hwi_dispatcherAutoNestingSupport) {

            if (Hwi_zeroLatencyIERMask ==   0) {

                /* Propagate self bit which   is auto cleared by hardware */

                  IER |= hwi->ierBitMask;

                oldIER = IER;

     

                Function C to set to high GPIO51

     

                IER &= ~hwi->disableMask;

                  __enable_interrupts();

                (hwi->fxn)(hwi->arg);  /* here is called the user isr */

     

     

     

    This measurement provided the following results, with the following settings:

    • CPU  at 60Mhz
    • all the SYSBIOS code executed from FLASH (with wait states set for 60Mhz )

     

    With   SYSBIOS options disabled (Enable Asserts and Enable logs)

    7us so   around 420 cycles

    With   SYSBIOS options enabled (Enable Asserts and Enable logs)

    18us

     

     

    It looks like that we obtained the same results that the TI benchmark for the setting for which TI SYSBIOS are disabled.

    Do you confirm that my measurement is correct ?

    However it makes me think that enabling the logs have a big impact. I did not expect so big differences. What is the advice from TI regarding the setting of SYSBIO for commercial code?

    In the pannel : SYS/BIOS - Basic Runtime Options

    there are 4 choices for the SYS/BIOS library type

    besides we may enable : Asserts and Logs

     

    Thanks for your help.

    Regards,

    Mathieu