Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Timer States

The figures below show the state diagrams for One-Shot and Periodic timers.

Tasks can call OSTmrStateGet() to find out the state of a timer. Also, at any time during the countdown process, the application code can call OSTmrRemainGet() to find out how much time remains before the timer reaches zero (0). The value returned is expressed in “timer ticks.” If timers are decremented at a rate of 10 Hz then a count of 50 corresponds to 5 seconds. If the timer is in the stop state, the time remaining will correspond to either the initial delay (one shot or periodic with initial delay), or the period if the timer is configured for periodic without initial delay.

One-Shot Timers

Periodic Timers

 

OS_TMR

A timer is a kernel object as defined by the OS_TMR data type (see os.h) as shown in the listing below:

The services provided by µC/OS-III to manage timers are implemented in the file os_tmr.c. Timer services are enabled at compile time by setting the configuration constant OS_CFG_TMR_EN to DEF_ENABLED in os_cfg.h.

Even if the internals of the OS_TMR data type are understood, the application code should never access any of the fields in this data structure directly. Instead, you should always use the Application Programming Interfaces (APIs) provided with µC/OS-III.

Timer Task

OS_TmrTask() is a task created by µC/OS-III (assumes setting OS_CFG_TMR_EN to DEF_ENABLED in os_cfg.h) and its priority is configurable by the user through µC/OS-III’s configuration file os_cfg_app.h (see OS_CFG_TMR_TASK_PRIO). OS_TmrTask() is typically set to a medium priority.

As of V3.07, OS_TmrTask() no longer runs periodically. It now supports dynamic timer management, which is to say it only runs when it needs to process a change to the timer list. During normal operation, the task determines which timer will timeout next and performs a delay for that length of time. This approach helps reduce power consumption and is better suited to low-power applications, where a periodic wake-up is often undesirable.

 

The figure below shows timing diagram associated with the timer management task.

There are a few interesting things to notice:

  • Execution of the callback functions is performed within the context of the timer task. This means that the application code will need to make sure there is sufficient stack space for the timer task to handle these callbacks.
  • The callback functions are executed one after the other based on the order they are found in the timer list.
  • The execution time of the timer task greatly depends on how many timers expire and how long each of the callback functions takes to execute. Since the callbacks are provided by the application code they have a large influence on the execution time of the timer task.
  • The timer callback functions must never wait on events because this would delay the timer task for excessive amounts of time, if not forever.
  • Callbacks should execute as quickly as possible.

Timer List

µC/OS-III applications may require many timers. The timer manager implements a delta list where each timer is linked in a doubly linked list as shown in the figure below.

Timers are inserted in the timer list by calling OSTmrStart() and, a timer must be created before it can be used. Timer locations in the list are determined by the order in which they expire, as shown below.

Since this is the first timer inserted in the timer list, the .NextPtr and .PrevPtr both point to NULL.

The code below shows creating and starting another timer. This is performed “before” the timer task is signaled.

The “second timer” is inserted at the tail of the list as shown in the figure below, because it expires after the first. The delta property is maintained with respect to .Remain: the remaining time of the second timer is the sum of its .Remain value and that of all of the previous timers.



  • No labels