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:
As Clock functions execute in either a Swi or Hwi context, they
are not permitted to call blocking APIs.
Clock requires regular interrupts by an underlying timer peripheral. (If
operating with TickSource_USER, Clock requires regular invocation via
Clock_tick().) If the timer interrupt is inadvertently disabled Clock ticks
will stop incrementing, Clock functions will not execute, and when queried
Clock will report incorrect tick counts, timeouts, and ticks until timeout.
Clock objects are maintained in a queue, and there may be multiple Clock
objects that need to be serviced upon a given timer interrupt. Depending upon
the content of the queue, and the servicing of other objects that have timed
out, there will be some corresponding jitter in timing between the timer
interrupt and the actual invocation of a Clock object's function.
If there is a mismatch in the configured Clock tick period and the resolution
of the underlying timer peripheral, by convention Clock will generate a timeout
early, rather than late. For example, if the desired Clock tick period is 1
millisecond, and the underlying timer is clocked at 32768Hz, the counts
corresponding to 1 millisecond would be 32.678. Since an integer value must
be set in the timer peripheral, a truncated value of 32 counts will be used
per interrupt, resulting in an actual tick period of 0.977 msec.
Clock timing services require timely servicing of the timer peripheral
interrupt by the CPU, as well as timely execution of the Clock work function
(typically executed as a Swi). For the case where Clock runs and sees that
there have been multiple intervening timer interrupts since it was last able to
process its queue, it will walk the queue multiple times to 'catch up' and
resync the timeouts. If this happens the timing of execution of the missed
ticks will be faster than typical. For example, if Clock finds there have been
three intervening timer interrupts since it was last able to run, it will walk
its queue three times rapidly to replay the missed ticks, in sequence, once for
each intervening delayed tick. So if there are Clock objects that timeout on
each tick increment, they will be invoked in order, but the delay between the
invocation of these functions will not be a full Clock tick period; it will be
much quicker, as quickly as Clock is able to repeatedly process its queue to
resync to real time.
Timely execution of the Clock work function is especially important for
TickMode_DYNAMIC, as the timer peripheral needs to be reprogrammed on each
timer peripheral interrupt. The ability of Clock to keep time sync will vary
by the configured Clock tick period, the underlying timer implementation, the
peripheral's count width and resolution, and the rate that the timer
increments. In an extreme case, if the delay from the timer raising the
interrupt to the execution of the Clock work function exceeds the rollover
period of the underlying timer peripheral (e.g. a 16-bit timer running at 32kHz
rolling over every 2 seconds), time sync will be lost, the next interrupt may
be significantly delayed, and there will be gaps of lost Clock ticks versus
real time. Some general guidelines for TickMode_DYNAMIC to maintain continuous
time sync are listed below. Some implementations may be more tolerant to
delays; these are conservative general limits. If these conditions cannot be
met the Clock module should be configured for TickMode_PERIODIC.
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.
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
The timeout of an instance cannot be zero.
When using a very fast Clock tick period it may not always be possible
to start a Clock object with maximum timeout (0xFFFFFFFF). This limit
applies when Clock_start() is called while Clock is in-process of
servicing its timeout queue (called by another ISR, by a higher-priority
Swi, or within a Clock function). In this situation the timeout of the
newly-started object may occur in the near future rather than in the
far future. For one-shot objects there will be a single early timeout;
for periodic objects there will be an early timeout, but the next
timeout will occur correctly offset from the first timeout. This
condition is due to a Clock tick count wrap, and only occurs when there
is a very fast Clock tick period such that there are virtual Clock tick
period increments between the last timer interrupt to the invocation of
Clock_start(). For example, if the Clock tick period is 10 usec, and if
the Clock tick count is 0x10000005 when the interrupt occurs, and if
there are 3 intervening tick periods (30 usec) before the call to
Clock_start(), then the future timeout will be computed as
0x10000005 + 3 + 0xFFFFFFFF = 0x10000007, only 2 ticks in the future.
In this case, the maximum timeout should be limited to 0xFFFFFFFD to
achieve the maximum delay since the last timer interrupt.
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.