Measuring time in an RTOS

I spend a lot of my time talking about, writing about and thinking about real time operating systems – including our Nucleus RTOS product. This technology is key to so many modern embedded systems, but I still get the question from time to time: What is an RTOS actually for? This can easily be responded to with a vague description: a scalable software platform on which to build an embedded software application. This is accurate, but unhelpful. It might be better to talk about support for a multi-tasking programming model. However, ultimately an RTOS is there to enable the developer to have control of time …

A real time application is not one that is [necessarily] fast; it is deterministic – it is predictable. This means, in practical terms, that it must be designed to respond to events in a timely fashion; the response must be fast [and/or slow] enough to meet the requirements of the application. An RTOS helps the developer achieve this goal in broadly two ways:

1. The scheduler controls how CPU time is allocated between tasks; the developer has complete control.
2. The OS provides a number of time oriented services that assist with the measurement of time and constraining events in the time domain.

It is (2) that I wanted to discuss further today. I was working on a piece of writing [actually part of an upcoming book] where I was considering RTOS time facilities, so I thought that a heads-up on the topic may be useful here.

Of course, different RTOS products offer different capabilities, but a typical set of facilities are those provided by Nucleus RTOS:

• System Time – Most RTOSes support a “tick clock”. This is simply a timer interrupt, that occurs at a specific frequency, resulting in an increment of the system time value. Service calls enable this value to be retrieved or reset. Knowing the timer frequency enables the developer to calculate time values in seconds.
• Sleep – Service calls are available that enable a task to put itself to sleep, or put another task to sleep, for a specified period, which is generally measured in ticks.
• Application Timers – RTOS timer objects are generally available that enable a task to perform an activity after a defined interval or at a specific frequency. Such a timer is set up with a initial count value and may be configured to just stop when it is finished or restart automatically. Commonly a timer may be configured to run a specific function when it completes.
• API Timeouts – In most RTOSes there are a variety of services, calls to which have the possibility of failure because of some resource not being available. These can be used in blocking and non-blocking modes. In non-blocking mode, the call simply returns with an error code, if the resource is not available. In blocking mode, the task is suspended, if the resource is unavailable, until it is freed up by another task. A blocking call is generally indefinite, but this can be problematic, if a resource may never become available, so a timeout facility is commonly provided.

In different RTOS products, there are many variations on these themes, but this a broad summary of the capabilities available.