Changing timer period at runtime in FreeRTOS - Time & Space Complexity

Time Complexity: Changing timer period at runtime

O(n)

Understanding Time Complexity

When we change a timer's period while a FreeRTOS timer is running, we want to know how the work needed grows as the timer settings change.

We ask: How much time does it take to update the timer period during runtime?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// Change timer period at runtime
void updateTimerPeriod(TimerHandle_t xTimer, TickType_t newPeriod) {
    if (xTimerChangePeriod(xTimer, newPeriod, 0) != pdPASS) {
        // Handle error
    }
}
    

This code changes the period of a running FreeRTOS timer to a new value.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The function call to change the timer period internally updates timer lists and possibly reschedules timers.
• How many times: This update happens once per call; no explicit loops in user code, but internal timer list traversal may occur.

How Execution Grows With Input

Changing the timer period involves updating internal timer structures, which depends on the number of active timers.

Input Size (n)	Approx. Operations
10 timers	About 10 steps to find and update the timer
100 timers	About 100 steps
1000 timers	About 1000 steps

Pattern observation: The work grows roughly in direct proportion to the number of active timers.

Final Time Complexity

Time Complexity: O(n)

This means the time to change the timer period grows linearly with the number of active timers.

Common Mistake

[X] Wrong: "Changing a timer period is always a quick, constant-time operation regardless of system state."

[OK] Correct: Internally, FreeRTOS must update timer lists, which takes longer if many timers are active.

Interview Connect

Understanding how timer updates scale helps you reason about real-time system responsiveness and resource use, a key skill in embedded programming.

Self-Check

What if we changed the timer period for multiple timers at once? How would the time complexity change?

Practice

1.

What function is used in FreeRTOS to change the period of a timer while it is running?

easy

A. xTimerStop()

B. xTimerStart()

C. xTimerReset()

D. xTimerChangePeriod()

Solution

1. Step 1: Understand timer period change in FreeRTOS

   FreeRTOS allows changing a timer's period without stopping it.

2. Step 2: Identify the correct API function

   The function xTimerChangePeriod() is designed to change the timer period at runtime.

3. Final Answer:

   xTimerChangePeriod() -> Option D

4. Quick Check:

   Change timer period = xTimerChangePeriod() [OK]

Hint: Use xTimerChangePeriod() to update timer period on the fly [OK]

Common Mistakes:

• Confusing xTimerStart() with changing period
• Trying to stop and restart timer instead
• Using xTimerReset() which resets but doesn't change period

2.

Which of the following is the correct syntax to change a FreeRTOS timer period to 100 ticks?

?

easy

A. xTimerChangePeriod(timerHandle, 0, 100);

B. xTimerChangePeriod(100, timerHandle, 0);

C. xTimerChangePeriod(timerHandle, 100, 0);

D. xTimerChangePeriod(0, 100, timerHandle);

Solution

1. Step 1: Recall function parameter order

   The function xTimerChangePeriod() takes parameters as (TimerHandle_t xTimer, TickType_t xNewPeriod, TickType_t xTicksToWait).

2. Step 2: Match parameters to example

   To set period to 100 ticks, pass timerHandle, 100, and 0 for no wait.

3. Final Answer:

   xTimerChangePeriod(timerHandle, 100, 0); -> Option C

4. Quick Check:

   Correct parameter order = xTimerChangePeriod(timerHandle, 100, 0); [OK]

Hint: Remember: timer handle first, then new period, then wait ticks [OK]

Common Mistakes:

• Swapping timer handle and period parameters
• Passing wait time before period
• Using wrong parameter types or order

3.

Given the code snippet below, what will be the output if the timer callback prints the timer period each time it runs?

TimerHandle_t timer = xTimerCreate("MyTimer", pdMS_TO_TICKS(500), pdTRUE, NULL, TimerCallback);
xTimerStart(timer, 0);
xTimerChangePeriod(timer, pdMS_TO_TICKS(1000), 0);
// TimerCallback prints current period in ms

medium

A. The callback prints 500 ms once, then 1000 ms repeatedly

B. The callback prints 1000 ms repeatedly from start

C. The callback prints 500 ms repeatedly without change

D. The callback never runs due to period change

Solution

1. Step 1: Analyze timer creation and start

   The timer is created with 500 ms period and started, scheduling first callback in 500 ms.

2. Step 2: Effect of period change

   xTimerChangePeriod() removes the pending expiration, updates the period to 1000 ms, and schedules the next callback in 1000 ms from the change time. Thus, all callbacks print 1000 ms repeatedly.

3. Final Answer:

   The callback prints 1000 ms repeatedly from start -> Option B

4. Quick Check:

   Period change cancels pending expiry = prints 1000 ms repeatedly [OK]

Hint: xTimerChangePeriod cancels pending expiry and starts new full period [OK]

Common Mistakes:

• Thinking first callback uses old 500 ms period
• Assuming period change preserves pending expiration time
• Believing the timer prints 500 ms first then switches

4.

Identify the error in the following code that attempts to change a timer period at runtime:

TimerHandle_t timer = xTimerCreate("Timer", pdMS_TO_TICKS(200), pdTRUE, NULL, TimerCallback);
xTimerChangePeriod(200, timer, 0);

medium

A. Parameters to xTimerChangePeriod are in wrong order

B. Timer was not started before changing period

C. Timer callback function is missing

D. pdMS_TO_TICKS() cannot be used in timer period

Solution

1. Step 1: Check function parameter order

   xTimerChangePeriod() expects (TimerHandle_t, TickType_t, TickType_t), but code passes (TickType_t, TimerHandle_t, TickType_t).

2. Step 2: Confirm other code parts

   Timer is created correctly and callback is provided; pdMS_TO_TICKS() is valid for period conversion.

3. Final Answer:

   Parameters to xTimerChangePeriod are in wrong order -> Option A

4. Quick Check:

   Correct parameter order is timer handle first [OK]

Hint: Timer handle always comes first in xTimerChangePeriod() [OK]

Common Mistakes:

• Swapping timer handle and period parameters
• Not starting timer before changing period (not required)
• Misunderstanding pdMS_TO_TICKS usage

5.

You have a FreeRTOS timer running with a 200 ms period. You want to double the period each time the timer callback runs, up to a maximum of 1600 ms. Which code snippet correctly changes the timer period at runtime inside the callback?

void TimerCallback(TimerHandle_t xTimer) {
    TickType_t currentPeriod = xTimerGetPeriod(xTimer);
    TickType_t newPeriod = currentPeriod * 2;
    if (newPeriod <= pdMS_TO_TICKS(1600)) {
        ?
    }
}

hard

A. xTimerChangePeriod(xTimer, newPeriod, 0);

B. xTimerStart(xTimer, 0);

C. xTimerStop(xTimer, 0); xTimerChangePeriod(xTimer, newPeriod, 0);

D. xTimerReset(xTimer, 0); xTimerChangePeriod(xTimer, newPeriod, 0);

Solution

1. Step 1: Understand timer period update inside callback

   Inside the callback, you can call xTimerChangePeriod() to update the timer period dynamically.

2. Step 2: Choose correct function usage

   Calling xTimerChangePeriod(xTimer, newPeriod, 0); changes the period without stopping or restarting the timer.

3. Final Answer:

   xTimerChangePeriod(xTimer, newPeriod, 0); -> Option A

4. Quick Check:

   Change period directly inside callback = xTimerChangePeriod(xTimer, newPeriod, 0); [OK]

Hint: Use xTimerChangePeriod inside callback to update period safely [OK]

Common Mistakes:

• Stopping timer before changing period unnecessarily
• Starting timer again inside callback
• Resetting timer which restarts count instead of changing period