The previous slides described how an application can create a number of clock instances that each fire off at different rates to call their assigned function. A clock instance is characterized by two time periods. The first is called the timeout and defines the amount of time between when the instance is started and when the function is fired off for the first time. What actually starts the clock instance in the first place can be an explicit call to Clock_start() from the application, or if the instance was created with startFlag set to true, it will simply start immediately after being created. The second period that characterizes the clock instance is the period, which defines how much time elapses between the first function call and all the calls after that. For a one-shot clock, only the timeout value is defined, and the period will simply be set to zero. Keep in mind that the functions being called by each of the clock instances are being invoked in the context of the clock’s software interrupt. What this means is that any calls to Clock_start() and Clock_stop() must be called from that same context and not from any other independent thread that happens to be executing. Other API calls include Clock_tickStart() and Clock_tickStop() to allow control of the underlying timer that is driving the clock module, and Clock_setPeriod(), Clock_setTimeout(), Clock_setfunc() to modify a clock instance’s parameters. There is also an API called Clock_tickReconfig, which allows the clock parameters to be reconfigured if the CPU frequency changes because of any frequency scaling.