No entry to service Entry to service
T2 entry call T1 protected call
Length of T1 protected call Length of T1 protected call
T1 protected call
TASK PRIORITY TASK PRIORITY
TIME 9 9 6 6 3 3 protected action
T1 executing T1 task execution T2 task execution
barrier evaluation
The time T1 spends inside a protected action depends on other tasks.
Time depends on whether there is an entry call to service.
Figure 16
Under the proxy-service model, T1’s protected operation length depends on the entry calls that need servicing. The execution time reported by ORK for the right example is 9 for T1 and 2 for T2.
89 REVIEW OF GNAT FOR BARE BOARDS FOR REAL-TIME SYSTEMS
wake while the task executes and the bound on the waiting time for a protected object processor lock. While the proxy-service model simplifies under the Ravenscar Profile, it still results in pessimistic WCETs: each protected operation includes the entry call servicing time regardless of whether servicing occurs, compounded as protected procedure calls typically outnumber entry calls. Finally, while GNAT-BB provides the ability to track the execution time of tasks, the Ada executive does not provide execution time timers because the Raven- scar Profile prohibits them (ARM D.13). Consequently, GNAT-BB cannot support execution budgets nor execution time-based execution servers.
When the real-time executive has no task to dispatch, GNAT-BB’s design pre- vents its from using the low power modes offered by microcontrollers: instead ORK enters a busy-wait idle loop until a task becomes available, leading to higher power consumption. Consequently, GNAT-BB lacks suitability for systems with low processor utilisation and a requirement to minimise system power — for example, battery operated systems.
ORK’s inability to use low power modes occurs because the idle loop occurs within the “protected” mode of the kernel, where interrupts are disabled. How- ever, tasks migrate from the alarm queue to the ready queue (and thus are dispatched) when a time source raises an interrupt. Consequently, to exit the idle state and dispatch a woken task, the kernel enables interrupts for a brief window each loop cycle (Figure 17). The interrupt window also allows the servicing of other interrupts while in the idle state.
The opening of the interrupt window conflicts with the ability to use low power modes. Entry into these states occurs unconditional though a machine instruc- tion or a write to a memory register. When any interrupt occurs, the micro- controller wakes and continues running. Thus, if the microcontroller enters a low power mode before enabling interrupts, the processor core will never wake. On the other hand, entry to a low power mode after enabling interrupts can allow the handling of any pending interrupt in between the enablement and the execution of the low power mode command (Figure 17). Handling the interrupt may result in a thread dispatched. When the context returns to the first thread, after the thread wakes and heads the ready queue, the task will enter the low power mode since the thread’s context is still within the busy-wait loop and the processor will not progress until the raising of another interrupt.
Support for Processor Low Power Modes
Figure 17
ORK’s idle loop, possible points for entering a Low Power Mode (LPM) and the problems with these points.
Idle Loop
Enable interrupts (1)
Enter LPM here and processor will not wake (interrupts disabled)
Enter LPM here and the processor will wake when an interrupt is raised after this point. However, an interrupt may be handled between (1) and here, causing a task to become dispatch- able. In this case, another interrupt needs to be raised before ORK can leave the idle loop.
Disable Interrupts Loop while no task to dispatch
Interrupts enabled to allow servicing of inter- rupts and management of queues
GNAT for Bare Boards pairs a Ravenscar Profile subset of the GNAT run-time with a small kernel providing the run-time’s required services. GNAT-BB’s ap- proach rests upon GNAT’s portable, modular and flexible design. The result produces a small real-time executive with low run-time overheads elegantly supporting bare-board Ravenscar Profile applications while maintaining a common code base with the full GNAT run-time. The approach allows GNAT-BB to accrue the benefits from GNAT’s development, maintenance and stability. Deriving a bare-board Ravenscar Profile from GNAT compromises the resulting run-time, as the inherited tasking model relies on threading services inspired by POSIX. Compromises results from GNAT’s need to support a wide range of operating systems using POSIX or POSIX-like threading services —most, if not all, operating systems. Consequently, GNAT services queued entry call using the proxy-service model, one not suited to real-time systems as it complicates the timing analysis of tasks and system schedulability analysis. Furthermore, the proxy-service model forces a more pessimistic WCET bound, reducing processor utilisation. Finally, the execution time reported for a task on GNAT-BB includes the time the task spends servicing the entries of other tasks: creating problems where tasks run longer than expected.
GNAT for Bare Boards’ simple kernel also poses a number of potential problems for real-time users. For some, the lack of support for processor low power modes when idling creates an issue for systems required to conserve energy. A larger problem rests with run-time priority inversion: where the kernel in-
terrupts a running task to move woken lower priority tasks to the ready queue. Moreover, the running task’s execution time includes the time spent moving these tasks. The effective result causes a lower priority task to consume the running task’s resources and potentially cause the task to miss its deadline. A workaround exists if the system’s schedulability analysis and the task’s WCET bound factors in the interruption, but the solution complicates analysis: par- ticularly as WCET determination now includes activities from outside the task. Finally, GNAT for Bare Boards simplicity and compactness derives from sup- porting only the Ravenscar Profile subset of the Ada tasking runtime. While valuable for applications that target the profile, many tasking features outside the Ravenscar Profile are still valuable to real-time users that GNAT-BB is unable to support, for example execution time timers or different task dispatching policies. While some features, like execution time timers, are implementable on top of the current kernel, others require structural changes to ORK to im- plement due to the Ravenscar Profile guiding the kernel’s design. For exam- ple, implementing different task dispatching policies is difficult as the kernel is designed around a particular fixed-priority scheduler implemented in the
System.BB.Threads.Queues package.
Thus, while GNAT for Bare Boards does provide a small and simple real-time executive, its simple nature and a run-time designed to operate on top of a general operating system complicates the timing and schedulability analysis of real-time systems. GNAT-BB’s design also limits its ability to support other Ada tasking features that are outside the Ravenscar Profile, but are useful or desired by some real-time users. The problems encountered raise the question whether a real-time executive using a purpose-built tasking run-time better suits the needs of bare-board real-time users.