MicroC Overview : Time Model and Related Time Operators

Time Model and Related Time Operators

MicroC has three model constructs that have a notion of time:

Keep in mind that the concept of a Timer might not be supported on all targets. For example, in the mainloop_sc OSI supplied with MicroC there is no direct support for a Timer.

The tool assumes the existence of a primary single Software Counter. It is determined within the compilation profile whether this defaults to SYS_TIMER and possibly Timer(s). Applications might use numerous software counters and timers.

Timeout and delay operators, referring to “Software Counter”(s):

 
Related to the Software Counter specified by the counter_id

Delay() expires delay_time after entering the state connected to the transition with the delay trigger/reaction.

Timeout() expires delay_time after an_event occurs, while the application is staying in the current state waiting for the timeout.

Related to the Software Counter specified by the counter_id

Note: When the 3rd argument is omitted in timeout(), the primary “Software Counter” is used.

Delay is actually tm(en(S), d-time) where S is the state name. Delays and Timeouts are “Soft” and “Passive.” This means that they are relatively cheap to implement internally, using 1 or less Timeout Variable Type variables and 1 or less bits of memory (i.e. RAM).

The actual delay might be greater than or equal to (i.e. >=) the specified delay, depends on the cycle used to schedule the task where the timeout is specified. It is conceivable that this might never occur. The actual implementation of the software counters is defined in the OSI.

The Schedule Operator refers to a hardware timer, Timer:

schedule(an_event, sc_time [, sc_cycle]) (sc)
schedule(an_action, sc_time [, sc_cycle]) (sc)
schedule(an_expression, sc_time [, sc_cycle]) (sc)

Note the optional cycle expressed as the 3 rd parameter to sc!(exp, delay, cycle). The timer might be defined in the data dictionary of the scheduled operand (e.g. event or action), or automatically by the tool. Note that this type of timer is potentially more expensive than the delay operator. Actual invocation time accuracy and cost depends upon the Timer implementation. Hardware timers are very accurate and Active, however they are typically a scarce and expensive resource.

The actual implementation of the timers is defined in the OSI.