A timer is a kernel object as defined by the RTOS_TMR data type as shown in the listing below:

typedef struct os_tmr {

INT8U RTOSTmrType; /* Should always be set to RTOS_TMR_TYPE for timers */

RTOS_TMR_CALLBACK RTOSTmrCallback; /* Function to call when timer expires */

void *RTOSTmrCallbackArg; /* Argument to callback function */

void *RTOSTmrNext; /* Double link list pointers */

void *RTOSTmrPrev;

INT32U RTOSTmrMatch; /* Timer expires when RTOSTmrTickCtr = RTOSTmrMatch*/

INT32U RTOSTmrDly; /* Delay time before periodic update starts */

INT32U RTOSTmrPeriod; /* Period to repeat timer */

INT8U *RTOSTmrName; /* Name to give the timer */

INT8U RTOSTmrOpt; /* Options (see RTOS_TMR_OPT_xxx) */

INT8U RTOSTmrState; /* Indicates the state of the timer:*/

/* RTOS_TMR_STATE_UNUSED */

/* RTOS_TMR_STATE_RUNNING */

/* RTOS_TMR_STATE_STOPPED */

} RTOS_TMR;

The structure starts with a RTOSTmrType field, which allows it to be recognized by OS as a timer. Other kernel objects will also have a Type as the first member of the structure. If a function is passed a kernel object, OS is able to confirm that it is passed the proper data type. For example, if passing a message queue to a timer service (for example RTOSTmrStart()) then OS will be able to recognize that an invalid object was passed, and return an error code accordingly.

Each kernel object can be given a name (RTOSTmrName) for easier recognition by debuggers. This member is simply a pointer to an ASCII string which is assumed to be NUL terminated.

The . RTOSTmrCallback member is a pointer to a function that is called when the timer expires. If a timer is created and passed a NULL pointer, a callback would not be called when the timer expires.

If there is a non-NULL . RTOSTmrCallback then the application code could have also specified that the callback be called with an argument when the timer expires. This is the argument that would be passed in this call.

RTOSTmrNext and RTOSTmrPrev are pointers used to link a timer in a doubly linked list. These are described later.

The RTOSTmrDly field contains the one-shot time when the timer is configured (i.e., created) as a one-shot timer and the initial delay when the timer is created as a periodic timer. The value is expressed in multiples of 1/RTOS_CFG_TMR_TASK_RATE_HZ of a second.

The RTOSTmrPeriod field is the timer period when the timer is created to operate in periodic mode. The value is expressed in multiples of 1/RTOS_CFG_TMR_TASK_RATE_HZ of a second.

The RTOSTmrOpt field contains options that are passed to RTOSTmrCreate().

The RTOSTmrState field represents the current state of the timer (see the figure in Timers States).

Even if the internals of the RTOS_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.

RTOS_TmrTask() is a task created by OS (i.e. you) and its priority is configurable by the user. RTOS_TmrTask() is typically set to a medium priority.

RTOS_TmrTask() is a periodic task and uses the same interrupt source used to generate clock ticks. However, timers are generally updated at a slower rate (i.e., typically 10 Hz or so) and thus, the timer tick rate is divided down in software. If the tick rate is 1000 Hz and the desired timer rate is 10 Hz then the timer task will be signaled every 100th tick interrupt as shown in the figure below.

When the timer task executes, it starts by incrementing RTOSTmrTickCtr and goes through the list (linearly) and checks each of the RTOSTmrMatch fields is equal the OSTmtTickCtr. When equal, the timer manager executes the callback function associated with the timer.

When inserting the timer in the link list RTOSTmrMatch field is calculated as OSTmtTickCtr + RTOSTmrDly. If the timer is set to periodic, reloads the RTOSTmrMatch is calculated as OSTmtTickCtr + RTOSTmrPeriod. If the timer is configured as a one-shot timer, the timer is removed from the list upon expiration.

Timer management occurs at the task level. The list must be protected using an internal mutual exclusion semaphore (mutex) or, by locking the scheduler. Its recommend that you use (and thus enable) mutexes because locking the scheduler impacts task responsiveness of other, higher priority tasks in your application.

Your timer management module might need to literally maintain hundreds of timers, so it needs to be implemented such that it does not take too much of CPU time to update the timers. So you may need to design a hash table of link lists to keep the length of the link lists short. You may want to use the value of (OSTmtTickCtr + RTOSTmrDly) % N to calculate the index of the hash table.

RTOSTmrTickCtr is incremented by RTOSTmrTask() every time the tick ISR signal the task.

Timers are inserted in the timer list by calling RTOSTmrSTart().

Please Zip all your files including:

- All source files (*.c and *.h files)

- All Makefiles or project files if any

- A short instruction about the platform that it needs to be compiled on (i.e. Windows/Linux) and how should it be compiled.

OSCfg TmrWheell] [0]0 0 [20 [3 0 0 NextPtr NextPtr [5]0 [6]0 170 [8]0 0- PrevPtr Remain = 1 "Match = 13 OS TMFR PrevPtr Remain = 10 "Match = 22 OS TMFR NbrEntriesMax FirstPtr OSTmrTickCtr= 12 NbrEntries OSCfg TmrWheell] [0]0 0 [20 [3 0 0 NextPtr NextPtr [5]0 [6]0 170 [8]0 0- PrevPtr Remain = 1 "Match = 13 OS TMFR PrevPtr Remain = 10 "Match = 22 OS TMFR NbrEntriesMax FirstPtr OSTmrTickCtr= 12 NbrEntries