Betriebssysteme Windows Embedded Compact 7 Echtzeit-Tuning

Windows Embedded Compact 7 eignet sich grundsätzlich für Echtzeit ist aber in Bezug auf seinen Einsatz hochflexibel. Welche Anpassungen OEMs vornehmen können, erklärt dieser Beitrag.

Anbieter zum Thema

Data Modul AG

MicroConsult Academy GmbH

PTC

Windows Embedded Compact 7, ein 32-Bit-Betriebssystem bietet umfangreiche Dienste, mit denen OEMs eine Vielzahl verschiedener Geräte entwickeln können - einschließlich Systeme, die Echtzeitbedingungen erfordern, wie beispielsweise zur Signalerfassung.

Windows Embedded Compact 7 ist äußerst flexibel. Um aber ein definiertes Zeitverhalten für bestimmte Anwendungen sicherzustellen, müssen OEMs unter Umständen ihre Systeme anpassen und so die Echtzeitfähigkeit von Windows Embedded Compact optimieren. Dieser Artikel beschreibt die Interrupt Handling Architektur von Windows Embedded Compact und die damit möglicherweise verbundenen Optimierungen.

Windows Embedded Compact 7: von Navigationsgerät bis Industrieroboter

Windows Embedded Compact 7 adressiert den Industrial-Markt. Es ist jedoch ausreichend allgemein gehalten und eignet sich für zahlreiche andere Anwendungen, vom GPS-Navigationsgerät bis zum Industrieroboter. Je nach Einsatzgebiet bestehen unterschiedliche Einschränkungen und Anforderungen an den Funktionsumfang oder die Echtzeitfähigkeit eines Systems.

Grundsätzlich bietet Windows Embedded Compact Echtzeitfähigkeit und arbeitet auf drei verschiedenen Prozessorfamilien (ARM, x86, MIPS) mit unterschiedlicher Interrupt-/Timer-Behandlung und Speicherzugriff. Microsoft bietet deshalb einen generischen Kernel an, der auf eine spezielle Softwareschicht aufbaut, dem so genannten OEM Abstraction Layer (OAL), der je Prozessor und Hardwaredesign spezifisch ist. Dieser Code wird zusammen mit dem Board Support Package (BSP) zur Verfügung gestellt, das für jede Plattform erforderlich ist, um einen Kernel und folglich auch das Runtime Image zu erzeugen.

Videobericht: Was Windows Embedded Compact 7 kann

Da der OAL für die mit dem Runtime Image Design verbundene Hardware spezifisch ist, enthält er den Hardware-Zugang z.B. für die Register der Interrupt Controller, Timer und Real-Time-Clock.

Die Microsoft-Funktionen OEMInterruptInitialize und OEMInterruptDone sorgen dafür, dass der generische Kernel mit der Hardware interagiert. Außer dem erwarteten Verhalten dieser Funktionen gibt Microsoft jedoch keine Tipps mit auf den Weg, wie der Code geschrieben werden sollte. Durch eine logische Funktion namens Interpretation ist jedoch leicht nachvollziehbar, dass ein System leistungsstärker ist, wenn es wenig Zeit für Interrupts aufwenden muss.

Interrupt Management in Windows Embedded Compact

Unter Windows Embedded Compact nutzt das Interrupt-Management den OAL-spezifischen Code und die synchronisierten Objekte und splittet das Interrupt-Management-Verfahren in die Interrupt Service Routine (ISR) und den Interrupt Service Thread (IST) auf.

Wird dem Kernel ein Hardware-Interrupt signalisiert, leitet er die Information zur Identifizierung des System Interrupts (SYSINTR) an die ISR weiter. Nach der Identifizierung „erwacht“ der zugehörige Thread, der in einem Treiber gehostet und dann weiterverarbeitet wird. Die ISR und der IST-Code können also die Reaktionsfähigkeit des Systems auf einen externen Impuls beeinflussen.

Interrupt Service Routine (ISR)

Da der Kernel während der ISR-Ausführung alle Interrupts mit niedrigerer oder gleicher Priorität maskiert, ist es wichtig, dass die Ausführung der ISR bis zur Rückgabe eines SYSINTR-Wertes möglichst wenig Zeit in Anspruch nimmt und der Kernel alle Unterbrechungsanforderungen (IRQs) mit minimaler Verzögerung reaktivieren kann (außer dem gerade ablaufenden Interrupt). Wenn zu viel Zeit für die Abarbeitung von ISRs aufgewendet wird, mindert dies die Systemleistung merklich. Dann werden möglicherweise Interrupts verpasst oder Speicherpuffer laufen über.

Ein weiterer wichtiger Aspekt ist, dass die ISR im Kernel-Modus läuft und keinen Zugang zu den Higher-Level-APIs des Betriebssystems hat. Daher führen die meisten ISRs nur einfache Aufgaben aus, z.B. schnelles Kopieren von Hardwareregister-Daten in die Speicherpuffer. Bei Windows Embedded Compact erfolgt die zeitintensive Interruptbehandlung normalerweise in einem IST.

Wie schon erwähnt, verarbeitet der Interrupt Service Thread (IST) zeitaufwändige Aktionen, z.B. Registerzugriff und Datenmanipulation. Der IST-Code wird in einem Treiber gehostet und während der Interrupt-Initialisierung, die i.d.R. während der Treiberinitialisierung stattfindet, gestartet. Unter Windows Embedded Compact können Threads einen Prioritätswert zwischen 0 und 255 haben, je nach Wichtigkeit der Task, wobei 0 die höchste Priorität bezeichnet.

Installable Interrupt Service Routine (IISR)

Das beschriebene ISR-Verhalten ist eine generische Methode, die sich unter Umständen für bestimmte Geräte gar nicht eignet. Beispielsweise lässt sich ein IRQ mehreren Geräten zuweisen, wenn Shared Interrupts verwendet werden. In diesem Fall muss der Kernel den korrekten SYSINTR-Wert erhalten. Dies ist nicht nur ein Lesezugriff auf ein Prozessor-Register.

(ID:24924510)