Hardware Reference
In-Depth Information
OSEK/VDX systems also support non-preemptive scheduling and Preemption Thresh-
olds (see Section 8.3) to limit the overall stack usage. The main idea is that limiting
the preemption between tasks reduces the number of tasks allocated on the system
stack at the same time, further reducing the overall amount of required RAM. Note
that reducing preemptions may degrade the schedulability of the tasks set; hence the
degree of preemption must be traded with the system schedulability and the overall
RAM memory used in the system.
Another requirement for operating systems designed for small microcontrollers is
scalability , which implies the possibility of supporting reduced versions of the API for
smaller footprint implementations. In mass production systems, in fact, the memory
footprint has a significant impact on the overall system cost. In this context, scala-
bility is provided through the concept of Conformance Classes , which define specific
subsets of the operating system API. Conformance classes are also accompanied by
an upgrade path between them, with the final objective of supporting partial imple-
mentation of the standard with reduced footprint. The conformance classes supported
by the OSEK/VDX standard are as follows:
BCC1 :
This is the smallest conformance class, supporting a minimum of eight
tasks with different priority and a single shared resource.
BCC2 :
Compared to BCC1, this conformance class adds the possibility of hav-
ing more tasks at the same priority. Each task can have pending activa-
tions; that is, the operating system records the number of instances that
have been activated but not yet executed.
ECC1 :
Compared to BCC1, this conformance class adds the possibility of hav-
ing extended tasks that can wait for an event to occur.
ECC2 :
This conformance class adds both multiple activations and extended
tasks.
Anther interesting feature of OSEK/VDX systems is that the system provides an API
for controlling interrupts. This is a major difference when compared to POSIX-like
systems, where the interrupts are the exclusive domain of the operating system and
are not exported to the operating system API. The rationale for this is that on small
microcontrollers users often want to directly control interrupt priorities; hence it is
important to provide a standard way of dealing with interrupt disabling/enabling.
Search WWH ::




Custom Search