Real-time systems generally need some means to monitor the passage of time and arrange for things to be done at specific moments in time or after specified delays. ECROS provides a timer mechanism to enable this.
ECROS provides three kinds of timers:
All timers can be destroyed, one shot timers before they fire and repeating timers at any time. When a one-shot timer fires, it is automatically destroyed by ECROS and the timer resource becomes available for reuse.
ECROS measures the passage of time in "ticks". The duration of a tick is selectable at run time via an argument to the API function OsStart() (refer to this function's description for details). The default tick for most platforms is 1 ms. Standard alternatives are 0.125, 0.25, 0.5, 2, 4, 8 and 16 ms. Some values may not be available on all platforms. Non-standard values, such as 5, 10, 20 ms, etc. may be implemented by recompiling ECROS. Operating system overhead increases slightly as the tick duration diminishes, so applications should select the largest tick that meets the timing resolution they need.
Time information is passed through the ECROS API using variables of type OsTicksT. This is a 16-bit unsigned integer and therefore cannot represent more than 65,535 ticks, which is a little more than a minute at the default tick size. This is another good reason to use the largest tick that meets your needs. As a result of this limitation, you cannot create timers with a delay or repeat interval greater than 65,535 ticks. To measure out longer periods of time, if you cannot use a longer tick, you will need to create a task that processes events from an ECROS timer, counts out the longer interval and then sends the final event to the target task. The use of 16-bit time values is a tradeoff between convenience and performance.
The global variable TickCount allows a client application to get the number of time ticks that have passed since the ECROS scheduler started. Using it, the application can monitor the progression of time without using ECROS timers. However, it is important to be aware of two limitations of such an approach. First, TickCount is a 16-bit unsigned integer and therefore wraps back to zero upon reaching a count of 65,535 ticks. So, for a tick period of 1 ms, the variable wraps a little less frequently than once per minute. Second, TickCount is updated by software in ECROS and will not change while a task retains control of the CPU. It is therefore not possible to see time progress while in a single invocation of a task function, only between invocations of task functions. These limitations notwithstanding, TickCount has uses such as reporting the progress of an application and seeding random number generators.