• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 489 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.

CC2538: osal_GetSystemClock not counting correctly

akshay b
Expert 1400 points
Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK

Hello,

I am using osal_GetSystemClock() function for a blocking timer in a while loop below is my code

osalTimeUpdate();
start_time = osal_GetSystemClock();

while(20000 >= stop_time )
{
osalTimeUpdate();
stop_time = osal_GetSystemClock();
stop_time -= start_time;
}

Here i want to achieve a blocking time of 20 seconds but actually i am getting 12 seconds time when i run a stopwatch using debug points before and after this code.

what can be the issue?

Regards,

Akshay

  • 0
    Guru 735685 points

    It’s not good to use while-loop to block everything out for 20 seconds in Z-Stack. I suggest you to use osal_start_timerEx to create a timer event for such long delay.

  • 0
    TI__Mastermind 35070 points

    Hi,

    I agree with YK, you should not block other tasks from running for such an extended period of time.

    Please refer to how SAMPLELIGHT_LEVEL_CTRL_EVT uses osal timer in the SampleLight example.

    Feel free to elaborate on the use case of blocking for 20 seconds.

    Regards,
    Toby

  • 0 in reply to Toby
    Expert 1400 points

    Hi Toby,

    The use case is for calibration purpose i need a delay for 20 seconds after sending a command.

    Thank you,

    Regards,
    Akshay

  • 0 in reply to akshay b
    TI__Mastermind 35070 points

    If you only need to block one task from running, then using osal_timer + events should be sufficient.

    Your method of updating the time is likely calling osalTimeUpdate too often (thus "speeding up" time). This could affect other time critical radio operations, so I wouldn't recommend it.