Real-Time Systems: Clocks, Priorities, and Scheduling

Real-Time Systems: Clocks and Scheduling

Core Concepts

• Clocks and Time
• Real-time clocks in Ada95
• Real-time clocks in TinyTimber
• Periodic activities
• Task priorities
• Priority support in TinyTimber
• Priorities and shared resources
• Priority inversion

System Time Modeling

To construct a real-time system, the chosen programming language or the run-time system must support a notion of high-resolution time to model system constraints. Real-time is represented by a system clock, which can be read to report the current time.

The system clock is typically implemented using a free-running timer with the following properties:

• Monotonicity: Time is strictly monotonic and cannot be adjusted backwards.
• Measurement: Time is measured in elapsed units.
• Implementation: Time units are implementation-dependent.

Real-Time Clocks in Ada95

The Real-Time Systems in Ada95 define a data type Time that represents real time with a resolution of 1 ms or better. The current value of the real time can be read by calling the function Clock.

Real-Time Clocks in TinyTimber

TinyTimber defines a data type Time with a resolution of 0.67 μs for the G1 card. Method executions in TinyTimber have a baseline, a timestamp representing the earliest start time for the method execution.

• The baseline of a method is the baseline of its caller, unless a new explicit baseline is provided (using AFTER() or SEND()).
• The baseline of an interrupt-handler method is the time of the interrupt.

The current real time is read by calling CURRENT_OFFSET(), which returns the time measured from the current baseline.

Time Conversion Macros

Macros for converting human-perceived time (s, ms, μs) to internal representations are available in TinyTimber.h within the system source code package.

Periodic Activities

Most embedded real-time applications rely on periodic activities—tasks executing at regular intervals as part of a control loop. Control theory typically dictates the execution interval. To support the reactive programming model, tasks should remain idle when not performing useful work. Therefore, the system must allow delaying task execution until the next activation.

Task Delays in Ada95

To delay a task in Ada95, use the relative delay statement:

delay 0.05; -- wait for 50 milliseconds

• The delay statement guarantees the task will be idle for at least the indicated duration.
• Actual idle time may be longer, as the re-activated task may wait for other tasks to complete, depending on the priority-assignment policy.

Periodic Execution Example

To execute a task periodically every 50 milliseconds, note that this solution may result in a systematic time skew. The code for Action follows.