xTimerChangePeriod() return value and reload behaviour for value shorter than currently elapsed

Hi,
I am using software timers and have some questions that I am not clear about after reading the documentation:

  1. When the timer period is changed with xTimerChangePeriod() like in the sample code below, what could be the cause of it failing i.e. “the command not being sent”? In the documentation it says “if it could not be sent to the timer command queue”. What can cause that and how can you prevent that?

  2. Also does xTimerChangePeriod() reset the timer or does it continue count from whichever value it currently is at?

  3. If the latter (i.e. it keeps counting from the value it currently is at) what happens if the new value is lower/shorter than the current value (i.e. the timeout for the new value is already elapsed/passed)?

  4. Finally, is it safe to set the block time to 0? In practical terms, why would you want t0 set the block time to anything other than 0?

    if( xTimerChangePeriod( xTimer, 500 / portTICK_PERIOD_MS, 100 )
    == pdPASS )
    {
    /* The command was successfully sent. /
    }
    else
    {
    /
    The command could not be sent, even after waiting for 100 ticks
    to pass. Take appropriate action here. */
    }

Thank you :slight_smile:

Hi Rik001,

  1. If the timer task’s command queue is full, then xTimerChangePeriod() can (a) simply return with a failure code or (b) it can wait for the queue to have room for the change-period command. If it waits, there’s no guarantee that room will open up in the queue before the blocking time expires. In that case, xTimerChangePeriod() will still return a failure code. To prevent this failure code, make sure the timer task gets enough CPU time to keep up with its duties (eg, configTIMER_TASK_PRIORITY), and make sure the command queue is large enough for any temporary shortage of CPU time (ie, configTIMER_QUEUE_LENGTH).
  2. xTimerChangePeriod() resets the timer.
  3. (see 2)
  4. Setting the block time to zero is common in configurations that set the timer task priority higher than any task that uses the timer API. In other configurations, it might make sense to set the block time to something other than zero or to make the command queue larger.
1 Like

Thank you Jeff for the explanation and details! :slight_smile: