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

Timing the Duration of a OSAL Event/Task

Kevin Lockwood
Expert 1035 points

I have made some modification to some code which was based on the SimplePeripheral Project.  I notice that the new code is slightly slower at receiving GATT Server Attribute Update from a BLE Central Device.  I haven't changed any of the Event timer periods so I worry that it may be that I segmented my code too much (too many jumps to functions) that may be slowing down the response of the Code.  Its fairly consistent at ~300msec difference.   To determine if its my code I want to time how long (or how many clock cycles) my Events/Tasks are taking so that I may optimized my code.  I tried using theosal_GetSystemClock(),  but it did not increment between the start and stop of the Event/Task.  Anyone tackle this before?  Thanks

  • 0
    TI__Guru 57865 points

    Hey Kevin,

    Have you changed the connection interval? (Done from Central or requested by Peripheral)

    Data transmission will be buffered until the next connection event so if you have 300 ms connection interval it may take up to 300 ms until the transmission is performed.

    Best Regards

    Joakim

  • 0 in reply to J Lindh
    Expert 1035 points

    The Connection Interval is the same.   The Main Event/Task is called thru an OSAL timer at the same 1second intervals as the previous code.  That's what brought me to thinking it may be a slight hang up in my code.  It's there a low level system clock I can capture at the beginning of a task and break point at the end to see the time span or clock tick duration?  Thanks for your help

  • 0 in reply to Kevin Lockwood
    TI__Mastermind 23440 points

    Hi,

    Timer2 is always running, and you could potentially use one of these functions, defined in ll_timer2.h, used by hal_sleep;

    extern uint32 llGetCurrentTime( void );
    extern uint16 llGetCurrentFineTime( void );
    extern void llGetFullCurrentTime( uint32 *coarse, uint16 *fine );

    Which will return the 24-bit overflow part of Timer2 (625us ticks), the 16-bit part of Timer2 (31.25ns ticks) or both.

    Note that these are internal functions, but _should_ have no adverse effects when used.

    BR,
    Aslak