The System Clock Manager is responsible for all timing services in
SYS/BIOS.
It generates the periodic system tick. The tick period is configurable.
The timeout and period for all Clock Instances and timeout values in
other SYS/BIOS modules are specified in terms of Clock ticks.
The Clock Manager supports two tick "modes": a periodic mode with an
interrupt on each tick (TickMode_PERIODIC), and a tick suppression
mode (TickMode_DYNAMIC), which reduces the number of timer interrupts to
the minimum required to support the scheduled timeouts. For devices that
support it (e.g., CC13xx/CC26xx devices), TickMode_DYNAMIC may be the default
mode if one is not specified in the application configuration; otherwise,
the default mode will be TickMode_PERIODIC. The following example shows
how the tick mode can be specified in the application configuration:
Clock objects contain functions that can be scheduled to run after a
certain number of Clock ticks.
Clock objects are either one-shot or periodic. Instances are started
when created or they are started later using the Clock_start() function.
Instances can be stopped using the Clock_stop() function. All Clock
Instances are executed when they expire in the context of a software
interrupt.
Clock objects are placed in the Clock object service list when
created/constructed and remain there until deleted/destructed.
To minimize processing overhead, unused or expired Clock objects
should be deleted or destructed.
The getTicks() function returns number of clock ticks since startup.
If you want to use a custom configured timer for the Clock module's
tick source, use the following example configuration as a guide:
In your 'C' code, add your timer interrupt handler and have it
call Clock_tick(), which will perform all of the Clock module
tick duties:
enum Clock_TickMode |
|
Clock Tick Mode
typedef enum Clock_TickMode {
Clock_TickMode_PERIODIC,
// Timer will interrupt every period
Clock_TickMode_DYNAMIC
// Unnecessary timer ticks will be suppressed
} Clock_TickMode;
enum Clock_TickSource |
|
Clock tick source
typedef enum Clock_TickSource {
Clock_TickSource_TIMER,
// Internally configure a Timer to periodically call Clock_tick()
Clock_TickSource_USER,
// Application code calls Clock_tick()
Clock_TickSource_NULL
// The Clock module is disabled
} Clock_TickSource;
VALUES
TickSource_TIMER
The Clock module automatically configures a
a Timer instance (see TimerProxy) to drive the Clock tick.
The specific timer and its period can be controlled via
timerId and tickPeriod.
TickSource_USER
The Application is responsible for calling
Clock_tick() periodically. Make sure Clock.tickPeriod is set to the period that Clock_tick() is called.
Like most other module configuration parameters, the Clock.tickPeriod
config parameter value is accessible in runtime C code as
"Clock_tickPeriod".
TickSource_NULL
The Clock module is disabled.
In this case, it is an error for the application to ever call
Clock_tick().
SEE
typedef Clock_FuncPtr |
|
Instance function prototype
typedef Void (*Clock_FuncPtr)(UArg);
config Clock_A_badThreadType // module-wide |
|
Asserted in Clock_create and Clock_delete
extern const Assert_Id Clock_A_badThreadType;
config Clock_A_clockDisabled // module-wide |
|
Asserted in Clock_create()
extern const Assert_Id Clock_A_clockDisabled;
config Clock_LM_begin // module-wide |
|
Logged just prior to calling each Clock function
config Clock_LM_tick // module-wide |
|
Logged in every Clock tick interrupt
config Clock_LW_delayed // module-wide |
|
Logged if Clock Swi delayed by >= 1 tick
config Clock_tickMode // module-wide |
|
Timer tick mode
DETAILS
This parameter specifies the tick mode to be used by the underlying
Timer.
With TickMode_PERIODIC the timer will interrupt the CPU at
a fixed rate, defined by the tickPeriod.
With TickMode_DYNAMIC the timer can be dynamically reprogrammed by
Clock, to interrupt the CPU when the next tick is actually needed for
a scheduled timeout. TickMode_DYNAMIC is not supported on all devices,
and may have some application constraints.
config Clock_tickPeriod // module-wide |
|
Tick period specified in microseconds
extern const UInt32 Clock_tickPeriod;
DETAILS
Default value is family dependent. For example, Linux systems often
only support a minimum period of 10000 us and multiples of 10000 us.
TI platforms have a default of 1000 us.
Like most other module configuration parameters, the Clock.tickPeriod
config parameter value is accessible in runtime C code as
"Clock_tickPeriod".
config Clock_tickSource // module-wide |
|
Source of clock ticks
DETAILS
If this parameter is not set to TickSource_TIMER,
Clock_tickStart(),
Clock_tickStop(), and
Clock_tickReconfig(), have no effect.
The default is TickSource_TIMER.
config Clock_timerId // module-wide |
|
Timer Id used to create a Timer instance
extern const UInt Clock_timerId;
DETAILS
If
Clock.tickSource is set to TickSource_TIMER,
the Clock module internally creates a
static Timer instance (see
TimerProxy) that automatically calls
Clock_doTick() on a periodic basis (as specified by
tickPeriod and
periodType.)
This configuration parameter allows you to control which timer is
used to drive the Clock module.
The default value is
Timer.ANY (~0)
and the maximum timerId possible is family and device specific.
Clock_getTicks() // module-wide |
|
Time in Clock ticks
RETURNS
time in clock ticks
DETAILS
The value returned will wrap back to zero after it reaches the max
value that can be stored in 32 bits.
Clock_tick() // module-wide |
|
Advance Clock time by one tick
DETAILS
After incrementing a global tick counter, this function posts a Swi
that processes the clock instances.
This function is automatically called by a timer ISR when
tickSource is set to
TickSource_TIMER.
When
tickSource is set to
TickSource_USER, Clock_tick() must be called by the
application. Usually, this is done within a user defined
Hwi,
Swi, or
Task.
Note that this function is not re-entrant. The application is
responsible for ensuring that invocations of this function are
serialized: either only one thread in the system ever calls this
function or all calls are "wrapped" by an appropriate mutex.
SEE
Clock_tickReconfig() // module-wide |
|
Reconfigure clock for new cpu frequency
Bool Clock_tickReconfig();
RETURNS
true if successful
DETAILS
This function uses the new cpu frequency to reconfigure the timer used
for generation of clock ticks such that tick period is
accurate. This function is used along with Clock_tickStop() and
Clock_tickStart() to allow reconfiguration of timer at runtime.
Reconfiguration may not be supported for some types of timers, and is
not supported for Clock.TickMode_DYNAMIC; in these cases, this
this function call will have no effect, and will return false.
When calling Clock_tickReconfig outside of main(), you must also call
Clock_tickStop and Clock_tickStart to stop and restart the timer.
Use the following call sequence:
// disable interrupts if an interrupt could lead to
// another call to Clock_tickReconfig or if interrupt
// processing relies on having a running timer
Hwi_disable() or Swi_disable();
BIOS_setCpuFreq(&freq);
Clock_tickStop();
Clock_tickReconfig();
Clock_tickStart();
Hwi_restore() or Swi_enable()
When calling Clock_tickReconfig from main(), the timer has not yet
been started because the timer is started as part of BIOS_start().
As a result, you can use the following simplified call sequence
in main():
BIOS_setCpuFrequency(Types.FreqHz *freq);
Clock_tickReconfig(Void);
The return value is false if the timer cannot support the new
frequency
CONSTRAINTS
This function is non-reentrant and appropriate locks must be used to
protect against re-entrancy.
Clock_tickStart() // module-wide |
|
Start clock after reconfiguration
DETAILS
This function starts the timer used for generation of clock ticks
It is used along with Clock_tickStop() and Clock_tickReconfig() to
allow reconfiguration of timer at runtime. The new timer configuration
reflects changes caused by a call to reconfig().
Reconfiguration and restart of a timer may not be supported for some
types of timers, and is not supported for Clock.TickMode_DYNAMIC; in
these cases, this function call will have no effect.
CONSTRAINTS
This function is non-reentrant and appropriate locks must be used to
protect against re-entrancy.
Clock_tickStop() // module-wide |
|
Stop clock for reconfiguration
DETAILS
This function is used to stop the timer used for generation of
clock ticks. It is used along with Clock_tickStart() and
Clock_tickReconfig() to allow reconfiguration of timer at runtime.
Stopping the timer may not be supported for some types of timers, and
is not supported for Clock.TickMode_DYNAMIC; in these cases, this
this function call will have no effect.
CONSTRAINTS
This function is non-reentrant and appropriate locks must be used to
protect against re-entrancy.
Module-Wide Built-Ins |
|
// Get this module's unique id
Bool Clock_Module_startupDone();
// Test if this module has completed startup
// The heap from which this module allocates memory
Bool Clock_Module_hasMask();
// Test whether this module has a diagnostics mask
Bits16 Clock_Module_getMask();
// Returns the diagnostics mask for this module
Void Clock_Module_setMask(Bits16 mask);
// Set the diagnostics mask for this module
Instance Object Types |
|
typedef struct Clock_Object Clock_Object;
// Opaque internal representation of an instance object
// Client reference to an instance object
typedef struct Clock_Struct Clock_Struct;
// Opaque client structure large enough to hold an instance object
// Convert this instance structure pointer into an instance handle
// Convert this instance handle into an instance structure pointer
Instance Config Parameters |
|
typedef struct Clock_Params {
// Instance config-params structure
// Common per-instance configs
UArg arg;
// Uninterpreted argument passed to instance function
UInt32 period;
// Period of this instance (in clock ticks)
Bool startFlag;
// Start immediately after instance is created
} Clock_Params;
// Initialize this config-params structure with supplier-specified defaults before instance creation
config Clock_Params.arg // instance |
|
Uninterpreted argument passed to instance function
DETAILS
The default is null.
config Clock_Params.period // instance |
|
Period of this instance (in clock ticks)
DETAILS
This parameter is used to set the subsequent timeout interval (in
Clock ticks) for periodic instances.
The default value of this parameter is 0, which indicates this is
a one-shot Clock object.
A non zero value for this parameter specifies that the Clock
object is to be called periodically, and also specifies the
rate (in Clock ticks) that the Clock function will be called
AFTER the initial 'timeout' argument period.
For one-shot Clock instances, this parameter must be set to zero.
config Clock_Params.startFlag // instance |
|
Start immediately after instance is created
DETAILS
When this flag is set to false, the user will have to call
Clock_start() to start the instance.
When set to true, both statically created Clock objects and Clock
objects created in main() are started at the end of main() when the
user calls BIOS_start(). Dynamically created Clock objects created
after main() (ie within a task) will be started immediately.
The default setting for this parameter is false.
The configured Clock function will be called initially after an
interval equal to the 'timeout' argument for both one-shot and
periodic Clock objects.
Periodic Clock objects will subsequently be called at the rate
specified by the
period parameter.
Runtime Instance Creation |
|
// Allocate and initialize a new instance object and return its handle
// Initialize a new instance object inside the provided structure
ARGUMENTS
clockFxn
Function that runs upon timeout
timeout
One-shot timeout or initial start delay (in clock
ticks)
params
per-instance config params, or NULL to select default values (target-domain only)
eb
active error-handling block, or NULL to select default policy (target-domain only)
DETAILS
The first argument is the function that gets called when the timeout
expires.
The 'timeout' argument is used to specify the startup timeout for
both one-shot and periodic Clock instances (in Clock ticks). This
timeout is applied when the Clock instance is started. For periodic
instances, the configured Clock function will be called initially
after an interval equal to the timeout, and will be subsequently
called at the rate specified by the
period parameter. For
one-shot instances (where the
period parameter is 0), once
the Clock instance is started (with
Clock_start() or
automatically if
startFlag is true) the configured Clock
function will be called once after an interval equal to the timeout.
When instances are created they are placed upon a linked list managed
by the Clock module. For this reason, instances cannot be created
from either Hwi or Swi context.
By default, all Clock functions run in the context of a Swi.
That is, the Clock module automatically creates a Swi for
its use and runs the Clock functions within that Swi.
The priority of the Swi used by Clock can be changed
by configuring
Clock.swiPriority.
If Swis are disabled in an application
(ie
BIOS.swiEnabled = false),
then all Clock functions are executed within the context of
a Timer Hwi.
CONSTRAINT
- As Clock functions execute in either a Swi or Hwi context, they
are not permitted to call blocking APIs.
Instance Deletion |
|
// Finalize and free this previously allocated instance object, setting the referenced handle to NULL
// Finalize the instance object inside the provided structure
Clock_getPeriod() // instance |
|
Get period of instance
ARGUMENTS
handle
handle of a previously-created Clock instance object
RETURNS
returns periodic interval in Clock ticks
DETAILS
Returns the period of an instance.
Clock_getTimeout() // instance |
|
Get timeout of instance
ARGUMENTS
handle
handle of a previously-created Clock instance object
RETURNS
returns timeout in clock ticks
DETAILS
Returns the remaining time if the instance is active; if the instance
is not active, returns zero.
There are certain edge cases to consider when calling this function
for a periodic Clock instance. Let the Clock instance's current
timeout tick refer to the Clock system tick value when the Clock
instance's function should be run. For a one-shot Clock, the
current timeout tick is the number of Clock system ticks at the time
the Clock instance was started, plus the Clock instance's timeout
value. This is also the current timeout tick for a periodic Clock on
its initial timeout. A periodic Clock's current timeout tick is
advanced by the period ticks, each time the periodic function is
run.
The remaining number of ticks for the Clock's timeout or period to
expire is computed by subtracting the current Clock system tick
value from the Clock instance's current timeout tick. Normally,
this value should be less than or equal to the Clock instance's
timeout (for a one-shot Clock or periodic clock on its initial
timeout), or less than or equal to the Clock instance's period (for
a periodic Clock that has already run its initial timeout).
However, if the Clock module Swi is held off long enough for the system
tick count to advance beyond the Clock instance's current timeout
tick, this subtraction will result in a very large number (close to
0xFFFFFFFF). Clock_getTimeout() takes this into consideration.
If the resulting value of the subtraction is greater than the Clock
instance's period (always true for a one-shot clock) and greater than
the Clock instance's timeout, it is assumed that the Clock system
ticks has surpassed the Clock instance's current timeout tick, and
0 is returned. This calculation of the remaining timeout ticks always
works for one-shot clocks. The calculation may fail if the all of
the following conditions are met:
- The Clock instance is periodic
- Clock_getTimeout() is called at a moment in time where
the system Clock ticks has surpassed the Clock instance's
current timeout (due to the Clock Swi being held off),
resulting in a very large value for
remaining ticks = Clock instance's current timeout tick -
system Clock tick count
remaining ticks > Clock instance's timeout, or
remaining ticks > Clock instance's period
This condition can only happen if the Clock instance's timeout
or period is close to 0xFFFFFFFF.
An example of a failure case is the following:
- A Clock instance has an initial timeout of 0xFFFFFFFF and
period of 100. Clock_getTimeout() is called after the initial
timeout has expired and the Clock is now running periodically.
In additiion, when Clock_getTimeout() is called, the system
tick count has surpassed the Clock instance's current timeout
by 2. The remaining ticks will be 0xFFFFFFFE, which is still
less than the timeout of 0xFFFFFFFF, so 0xFFFFFFFE is returned
when actually 0 should be returned. Calling Clock_setTimeout()
after the initial timeout expires, passing a small value for
the new timeout (which will not be used since the Clock instance
is now using the period value), will prevent this case from
occurring. An analogous failure can occur if the period is
close to 0xFFFFFFFF and Clock_getTimeout() is called when the
initial timeout has just expired and the Clock system tick
count has surpassed the Clock's current timeout.
Clock_isActive() // instance |
|
Determine if Clock object is currently active (ie running)
ARGUMENTS
handle
handle of a previously-created Clock instance object
RETURNS
returns active state
DETAILS
Returns TRUE if Clock object is currently active
Clock_setFunc() // instance |
|
Overwrite Clock function and arg
ARGUMENTS
handle
handle of a previously-created Clock instance object
clockFxn
function of type FuncPtr
arg
argument to clockFxn
DETAILS
Replaces a Clock object's clockFxn function originally
provided in
create.
CONSTRAINTS
Cannot change function and arg of Clock object that has been started.
Clock_setPeriod() // instance |
|
Set periodic interval
ARGUMENTS
handle
handle of a previously-created Clock instance object
period
periodic interval in Clock ticks
CONSTRAINTS
Cannot change period of instance that has been started.
Clock_setTimeout() // instance |
|
Set the initial timeout
ARGUMENTS
handle
handle of a previously-created Clock instance object
timeout
initial timeout in Clock ticks
CONSTRAINTS
Cannot change the initial timeout of instance that has been started.
Clock_start() // instance |
|
Start instance
ARGUMENTS
handle
handle of a previously-created Clock instance object
DETAILS
The
timeout and
period values set during create()
or by calling Clock_setTimeout() and Clock_setPeriod() are used and
the expiry is recomputed.
Note that for periodic instances, the first expiry is
computed using the timeout specified. All subsequent expiries use the
period value.
CONSTRAINTS
Timeout of instance cannot be zero
Clock_stop() // instance |
|
Stop instance
ARGUMENTS
handle
handle of a previously-created Clock instance object
Instance Built-Ins |
|
Int Clock_Object_count();
// The number of statically-created instance objects
// The handle of the i-th statically-created instance object (array == NULL)
// The handle of the first dynamically-created instance object, or NULL
// The handle of the next dynamically-created instance object, or NULL
// The heap used to allocate dynamically-created instance objects
// The label associated with this instance object
// The name of this instance object
proxy Clock.TimerProxy |
|
target/device-specific Timer implementation
Clock.
TimerProxy =
ITimer.Module null
// some delegate module inheriting the
ITimer interface
Clock.
TimerProxy.delegate$ =
ITimer.Module null
// explicit access to the currently bound delegate module
Clock.TimerProxy.abstractInstances$ = false
// use indirect runtime function calls if true
DETAILS
The Timer module used by the Clock module to
create a Timer instance when Clock.tickSource_TIMER is configured.
By default, a target specific Timer module is internally selected
for this purpose. If the user wishes to use a different Timer module
then the following configuration script will serve as an example for
achieving that:
var Clock = xdc.useModule('ti.sysbios.knl.Clock');
// Use a dmtimer Timer instance
Clock.TimerProxy = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
enum Clock.TickMode |
|
Clock Tick Mode
values of type Clock.TickMode
const Clock.TickMode_PERIODIC;
// Timer will interrupt every period
const Clock.TickMode_DYNAMIC;
// Unnecessary timer ticks will be suppressed
C SYNOPSIS
enum Clock.TickSource |
|
Clock tick source
values of type Clock.TickSource
const Clock.TickSource_TIMER;
// Internally configure a Timer to periodically call Clock_tick()
const Clock.TickSource_USER;
// Application code calls Clock_tick()
const Clock.TickSource_NULL;
// The Clock module is disabled
VALUES
TickSource_TIMER
The Clock module automatically configures a
a Timer instance (see TimerProxy) to drive the Clock tick.
The specific timer and its period can be controlled via
timerId and tickPeriod.
TickSource_USER
The Application is responsible for calling
Clock_tick() periodically. Make sure Clock.tickPeriod is set to the period that Clock_tick() is called.
Like most other module configuration parameters, the Clock.tickPeriod
config parameter value is accessible in runtime C code as
"Clock_tickPeriod".
TickSource_NULL
The Clock module is disabled.
In this case, it is an error for the application to ever call
Clock_tick().
SEE
C SYNOPSIS
config Clock.A_badThreadType // module-wide |
|
Asserted in Clock_create and Clock_delete
msg: "A_badThreadType: Cannot create/delete a Clock from Hwi or Swi thread."
};
C SYNOPSIS
config Clock.A_clockDisabled // module-wide |
|
Asserted in Clock_create()
msg: "A_clockDisabled: Cannot create a clock instance when BIOS.clockEnabled is false."
};
C SYNOPSIS
config Clock.LM_begin // module-wide |
|
Logged just prior to calling each Clock function
msg: "LM_begin: clk: 0x%x, func: 0x%x"
};
C SYNOPSIS
config Clock.LM_tick // module-wide |
|
Logged in every Clock tick interrupt
msg: "LM_tick: tick: %d"
};
C SYNOPSIS
config Clock.LW_delayed // module-wide |
|
Logged if Clock Swi delayed by >= 1 tick
msg: "LW_delayed: delay: %d"
};
C SYNOPSIS
config Clock.tickMode // module-wide |
|
Timer tick mode
DETAILS
This parameter specifies the tick mode to be used by the underlying
Timer.
With TickMode_PERIODIC the timer will interrupt the CPU at
a fixed rate, defined by the tickPeriod.
With TickMode_DYNAMIC the timer can be dynamically reprogrammed by
Clock, to interrupt the CPU when the next tick is actually needed for
a scheduled timeout. TickMode_DYNAMIC is not supported on all devices,
and may have some application constraints.
C SYNOPSIS
config Clock.tickPeriod // module-wide |
|
Tick period specified in microseconds
Clock.tickPeriod = UInt32 undefined;
DETAILS
Default value is family dependent. For example, Linux systems often
only support a minimum period of 10000 us and multiples of 10000 us.
TI platforms have a default of 1000 us.
Like most other module configuration parameters, the Clock.tickPeriod
config parameter value is accessible in runtime C code as
"Clock_tickPeriod".
C SYNOPSIS
config Clock.tickSource // module-wide |
|
Source of clock ticks
DETAILS
If this parameter is not set to TickSource_TIMER,
Clock_tickStart(),
Clock_tickStop(), and
Clock_tickReconfig(), have no effect.
The default is TickSource_TIMER.
C SYNOPSIS
config Clock.timerId // module-wide |
|
Timer Id used to create a Timer instance
DETAILS
If
Clock.tickSource is set to TickSource_TIMER,
the Clock module internally creates a
static Timer instance (see
TimerProxy) that automatically calls
Clock_doTick() on a periodic basis (as specified by
tickPeriod and
periodType.)
This configuration parameter allows you to control which timer is
used to drive the Clock module.
The default value is
Timer.ANY (~0)
and the maximum timerId possible is family and device specific.
C SYNOPSIS
metaonly config Clock.common$ // module-wide |
|
Common module configuration parameters
DETAILS
All modules have this configuration parameter. Its name contains the '$'
character to ensure it does not conflict with configuration parameters
declared by the module. This allows new configuration parameters to be
added in the future without any chance of breaking existing modules.
metaonly config Clock.rovViewInfo // module-wide |
|
metaonly config Clock.swiPriority // module-wide |
|
The priority of Swi used by Clock to process its instances
Clock.swiPriority = UInt undefined;
DETAILS
All Clock instances are executed in the context of a single
Swi. This parameter allows you to control the priority of
that Swi.
The default value of this parameter is Swi.numPriorities - 1; i.e.,
the maximum Swi priority.
SEE
Instance Config Parameters |
|
var params = new Clock.Params;
// Instance config-params object
params.arg = UArg null;
// Uninterpreted argument passed to instance function
params.period = UInt32 0;
// Period of this instance (in clock ticks)
params.startFlag = Bool false;
// Start immediately after instance is created
config Clock.Params.arg // instance |
|
Uninterpreted argument passed to instance function
var params = new Clock.Params;
...
params.arg = UArg null;
DETAILS
The default is null.
C SYNOPSIS
config Clock.Params.period // instance |
|
Period of this instance (in clock ticks)
var params = new Clock.Params;
...
params.period = UInt32 0;
DETAILS
This parameter is used to set the subsequent timeout interval (in
Clock ticks) for periodic instances.
The default value of this parameter is 0, which indicates this is
a one-shot Clock object.
A non zero value for this parameter specifies that the Clock
object is to be called periodically, and also specifies the
rate (in Clock ticks) that the Clock function will be called
AFTER the initial 'timeout' argument period.
For one-shot Clock instances, this parameter must be set to zero.
C SYNOPSIS
config Clock.Params.startFlag // instance |
|
Start immediately after instance is created
var params = new Clock.Params;
...
params.startFlag = Bool false;
DETAILS
When this flag is set to false, the user will have to call
Clock_start() to start the instance.
When set to true, both statically created Clock objects and Clock
objects created in main() are started at the end of main() when the
user calls BIOS_start(). Dynamically created Clock objects created
after main() (ie within a task) will be started immediately.
The default setting for this parameter is false.
The configured Clock function will be called initially after an
interval equal to the 'timeout' argument for both one-shot and
periodic Clock objects.
Periodic Clock objects will subsequently be called at the rate
specified by the
period parameter.
C SYNOPSIS
Static Instance Creation |
|
var params =
new Clock.
Params;
// Allocate instance config-params
params.config = ...
// Assign individual configs
var inst = Clock.create(Void(*)(UArg) clockFxn, UInt timeout, params);
// Create an instance-object
ARGUMENTS
clockFxn
Function that runs upon timeout
timeout
One-shot timeout or initial start delay (in clock
ticks)
params
per-instance config params, or NULL to select default values (target-domain only)
eb
active error-handling block, or NULL to select default policy (target-domain only)
DETAILS
The first argument is the function that gets called when the timeout
expires.
The 'timeout' argument is used to specify the startup timeout for
both one-shot and periodic Clock instances (in Clock ticks). This
timeout is applied when the Clock instance is started. For periodic
instances, the configured Clock function will be called initially
after an interval equal to the timeout, and will be subsequently
called at the rate specified by the
period parameter. For
one-shot instances (where the
period parameter is 0), once
the Clock instance is started (with
Clock_start() or
automatically if
startFlag is true) the configured Clock
function will be called once after an interval equal to the timeout.
When instances are created they are placed upon a linked list managed
by the Clock module. For this reason, instances cannot be created
from either Hwi or Swi context.
By default, all Clock functions run in the context of a Swi.
That is, the Clock module automatically creates a Swi for
its use and runs the Clock functions within that Swi.
The priority of the Swi used by Clock can be changed
by configuring
Clock.swiPriority.
If Swis are disabled in an application
(ie
BIOS.swiEnabled = false),
then all Clock functions are executed within the context of
a Timer Hwi.
CONSTRAINT
- As Clock functions execute in either a Swi or Hwi context, they
are not permitted to call blocking APIs.