Sie sind auf Seite 1von 41

Quickstart

PXROS

Version 1.0
Dieses Werk ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Kein Teil dieses
Werkes darf ohne unsere schriftliche Genehmigung in irgendeiner Form (Fotokopie oder
andere Verfahren) auch nicht zum Zwecke der Unterrichtsgestaltung reproduziert oder
unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet wer-
den. Die Übertragung von Nutzungsrechten obliegt ausschließlich einer entsprechenden
Lizenzvereinbarung.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in die-
sem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass
solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu be-
trachten wären und daher von jedermann benutzt werden dürfen. Sie unterliegen als solche
den gesetzlichen Bestimmungen.
Die in diesem Werk enthaltenen Informationen, Programme, Verfahren, Schaltungen, Bau-
gruppen etc. wurden mit größter Sorgfalt erstellt und getestet. Fehler können trotzdem
nicht ausgeschlossen werden, so dass eine juristische Verantwortung oder irgendeine Haf-
tung für fehlerhafte Angaben und deren Folgen oder Funktionsfähigkeit nicht übernommen
wird. Ferner wird für die Freiheit von Rechten Dritter keine Gewähr übernommen. Wir
behalten uns jegliche Änderungen auch ohne vorherige Mitteilung vor.

Danksagung
Die Firma HighTec EDV-Systeme GmbH bedankt sich bei der Universität Kaiserlautern
Fachbereich Elektrotechnik für die Bereitstellung der Studienarbeit von Denis Eberhard.
Diese Studienarbeit diente als Grundlage für die Erarbeitung dieses Dokumentes, dass
den Einstieg in das Echzeitbetriebssystem PXROS erleichtern soll.

HighTec EDV-Systeme GmbH HighTec EDV-Systeme GmbH


Stammsitz & Entwicklung Niederlassung Leonberg
Feldmannstraße 98 Heidenheimer Straße 14
D-66119 Saarbrücken D-71229 Leonberg
Tel.: 0681/92613-16 Fax: -26 Tel.: 07152/35413-0 Fax: -77
mailto:htc@hightec-rt.com mailto:info@hightec-rt.com

www.hightec-rt.com
Inhaltsverzeichnis
1 Modellierung des Betriebssystems 1
1.1 Grundaufbau des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Objektverwaltung von PXROS 3


2.1 Aufbau der Objektverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Operationen auf Objekt-Pools . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Speicherverwaltung 7
3.1 Speicherklassen mit variabler Blockgröße . . . . . . . . . . . . . . . . . . . 7
3.2 Speicherklassen mit fester Blockgröße . . . . . . . . . . . . . . . . . . . . . 8
3.3 Aufbau der Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Ablauf der Speicherbenutzung . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Befehle der Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Mailboxkommunikation 11
4.1 Sende-und Empfangsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Nachrichtenpools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Anlegen und Freigeben von Mailboxen . . . . . . . . . . . . . . . . . . . . 16
4.4 Spezielle Befehlsvarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5 Mailboxhandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5 Signalisieren von Events 19


5.1 Ablauf der Event-Signalisierung . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Besonderheiten der Kommunikation . . . . . . . . . . . . . . . . . . . . . . 19
5.3 Aufbau des Kommunikationssystems . . . . . . . . . . . . . . . . . . . . . 20

6 Zeitbehandlung in PXROS 23
6.1 Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Periodischer Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Delay Aufträge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4 Aufbau der Zeitverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5 Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Realisierung des IRQ-Anschlusses 31


7.1 Interruptanschluß an einen Prozessoren . . . . . . . . . . . . . . . . . . . . 31

8 Weitere Möglichkeiten der Objektverwaltung 33


8.1 Objektpool-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.2 Beispielablauf der Objektverwaltung . . . . . . . . . . . . . . . . . . . . . 34
8.3 Spezielle Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1 Modellierung des Betriebssystems
Dieses Dokument dient als Einführung in das Echtzeitbetriebssystem PXROS (Portable
eXtendible Real Time Operation System). Es werden die Grundmechanismen von PXROS
und ihr Zusammenspiel behandelt. Für die Darstellung von Abläufen werden Petrie-Netze
verwendet.

• Systemaufbau
• Grundlegende Objektverwaltung
• Speicherverwaltung
• Kommunikationsdienste
• Zeitbehandlung und Scheduling
• IRQ-Anschluss

1.1 Grundaufbau des Systems

Objektpools

Events 1..32 PXROS - Kernel

private Mbx
A R

Stack Task 1 A R

A R
Programm
Code Task n
A R

lokale
Variablen
Handler 1
WS 1
WS n

Systemspeicher Handler m

Abbildung 1.1: Grundaufbau des PXROS Systems


1 Modellierung des Betriebssystems Quickstart V1.0

Den Grundaufbau eines Systems unter Verwendung des Betriebssystems PXROS zeigt
Abbildung 1.1 auf Seite 1.
PXROS ist ein echtzeitfähiges Multitasking-Betriebssystem. Es gibt also mehrere Pro-
grammteile, die unabhängig voneinander abgewickelt werden und sich den Abwickler
im zeitmultiplex teilen. Diese Programmteile werden Tasks genannt. Dazu gibt es noch
Programmteile, die mit höherer Priorität abgewickelt werden und auf externe Ereignis-
se reagieren. Das sind die Hardware-Interrupts, die auf höchster Prioritätsebene abge-
wickelt werden. Dazwischen gibt es noch Software-Interrupts, die bei PXROS Handler
genannt werden. Diese Handler werden vom Betriebssystem angestoßen und führen be-
stimmte Operationen mit Priorität vor allen Tasks, aber niedrigerer Priorität gegenüber
den Hardware-Interrupts aus. Um den normalen Taskbetrieb möglichst wenig zu stören
und möglichst schnell abgearbeitet zu werden, verfügen die Handler über keinen Stack
und nur über einen verringerten Register-Satz. Außerdem sind die Kommunikationsmit-
tel eingeschränkt und es müssen speziell optimierte Funktionen benutzt werden, die an
der Endung _Hnd zu erkennen sind.
Jede Task hat ihr eigenes Working-Set. Dieses beinhaltet eine Liste:

• 32 Events

• Eine eigene Mailbox

• Eigenen Stack

• Lokale Variablen

• Task-Programmcode

Die Hardware-Interrupts können an Software-Handler gekoppelt werden (siehe Kapitel 7


auf Seite 31). Somit stellen die Handler in den meisten Fällen die Hardware-Interrupt-
Programme dar.

2 HighTec EDV-Systeme GmbH


2 Objektverwaltung von PXROS
Die Philosophie von PXROS, eine möglichst portierbarer, von der Hardwareplattform
unabhängiger Programmcode, erfordert eine Abstraktion der Schnittstelle zur Hardware.
Diese darf weder zu abstrakt sein um ein einfaches Verständnis zu gewährleisten, muss
aber im Gegenzug genügend abstrakt sein, um eine Anpassung an die unterschiedlichen
Hardwareplattformen durch das Betriebssystem zu ermöglichen.
Daher benutzt PXROS den Begriff des Objekts. Diese Objekte sind vom Typ:

• Speicherklassen-Objekt
• Mailbox-Objekt
• Objektpool-Objekt
• Delay-Objekt
• Nachrichten-Objekt

Zu Beginn sind alle Objekte noch gleich und nicht unterscheidbar. Daher ist nur ihre
Anzahl zur Boot-Zeit festlegbar, was durch entsprechende Parameter bei der Betriebssys-
teminitialisierung erfolgt. Nach der Initialisierung des Betriebssystems stehen also eine
festgelegte Anzahl von diesen Standard-Objekten zur Verfügung, die alle dem Standard-
System-Objektpool, dem PxOpoolSystemdefault, angehören, wie in Abbildung 2.1 auf Seite 3
dargestellt.

Standard- Objekte in
Objekte 1 PxOpoolSystemdefault

Abbildung 2.1: Diagramm der Objekte zur Boot-Zeit

Hinweis:
Erst bei der Anforderung durch einen Betriebssystem-Dienst erhal-
ten die Standard-Objekte vom Betriebssystem die benötigte Ausprä-
gung, beispielsweise eine Ausprägung als Nachrichten-Objekt oder als
Delay-Objekt.

Alle PXROS-Dienste sind typabhängig, d.h. sie betreffen nur bestimmte Objekttypen.
Die Objekte werden sogenannten Objektpools zugeordnet. Zu Beginn besteht nur ein
Objektpool, der Standard-System-Objektpool. Aus diesem können weitere Objektpools
erzeugt und Objekte zugeordnet werden. Dies wird in Abbildung 2.2 auf Seite 4 veran-
schaulicht.
2 Objektverwaltung von PXROS Quickstart V1.0

1 n Speicherklassen-
Objekt

1 m Mailbox-
Objekt

1 k Nachrichten-
Objektpools
Objekt

1 i Delay-
Objekt

1 j Objektpool-
Objekt

Abbildung 2.2: Struktur der Objekte zur Laufzeit

2.1 Aufbau der Objektverwaltung


Den Aufbau der Objektverwaltung aus Sicht des Programmierers zeigt Abbildung 2.3 auf
Seite 5.
Die Tasks kommunizieren mit dem Betriebssystem-Kernel über Auftrag-Rückmelde Schnitt-
stellen. Der Kernel verwaltet den Arbeitsspeicher, der dem Betriebssytem zugeordnet wur-
de. In dem Arbeitsspeicher sind alle vorhandenen Objekte im Pool PXOpoolSystemdefault
zusammengefasst. Dieser Pool kann in weitere reale oder virtuelle partitioniert bzw. geglie-
dert sein. Der Zugriff auf die einzelnen Objektpools erfolgt ausschließlich über Betriebssystem-
Dienste, daher haben die Tasks selber keinen direkten Zugriff auf die Objektpools.

2.2 Operationen auf Objekt-Pools


Um mit Objekten arbeiten zu können werden auf jeden Fall Dienste zum Anfordern und
zum wieder Freigeben von Objekten benötigt. Bei PXROS haben diese Dienste von Namen
her allgemein den Aufbau:

Px + Objekt + Operation

Zum Bespiel heißt ein PXROS Dienst der eine Nachricht anfordert PxMsgRequest. Einen
neuen Objektpool kann man mit dem Befehl PXOpoolRequest anfordern. Details zur Über-
gabe von Parameter sind im PXROS User’s Guide beschrieben.
Bei der Anforderung wird ein Universalobjekt aus dem angegebenen Systempool entnom-
men und erhält die Eigenschaften eines Objektpools. Dieser neue Pool ist nun noch leer
und muss mit Objekten gefüllt werden.
Mit dem Befehl PXOpoolRelease wird ein Objektpool inklusive aller darin befindlichen
Objekte freigegeben und dem Systempool wieder hinzugefügt. Natürlich geschieht das

4 HighTec EDV-Systeme GmbH


Quickstart V1.0 2.2 Operationen auf Objekt-Pools

PXROS - Kernel
Opool 1

A R
Opool 2
Task 1 A R

Task 2
A R
Opool n

PXOpool
Systemdefault

Systemspeicher Task m

Abbildung 2.3: Aufbau der Objektverwaltung

nur, solange keine Tasks einen wartenden Request auf diesen Objektpool haben. In diesem
Fall meldet der Befehl einen Fehler zurück.
Es gibt noch einige weitere Möglichkeiten und Besonderheiten der Objektverwaltung von
PXROS, auf die in Kapitel 8 auf Seite 33 eingegangen wird. Dies erfolgt später in Abbil-
dung 4.3 auf Seite 15, wo auch ein beispielhafter Ablauf der Objektbenutzung beschrieben
wird.

HighTec EDV-Systeme GmbH 5


2 Objektverwaltung von PXROS Quickstart V1.0

6 HighTec EDV-Systeme GmbH


3 Speicherverwaltung
Das Betriebssystem PXROS unterstützt verschiedene Speicherklassen. Dadurch können
einzelne Bereiche im Speicher geschützt werden, indem verschiedene Teile der Applikati-
on aus unterschiedlichen Speicherklassen versorgt werden. Außerdem ist eine Verkürzung
der Anforderungszeit möglich. Zum Einen, weil eine Speicherklasse fester Blockgröße we-
niger Anforderungszeit braucht, zum Anderen, weil sicherheitskritische (und damit auch
zeitkritische) Teile der Applikation eine eigene Speicherklasse nutzen können, die einen
genügenden Speichervorrat aufweist und dadurch Warten auf einen freien Speicherblock
verhindert.

Nach der Initialisierung des Betriebssystems ist der gesamte verfügbare Speicher der Sys-
temklasse PXMCSystemdefault zugeordnet. Generell unterstützt PXROS Speicherklassen:

• Variabler Blockgröße

• Speicherklassen fester Blockgröße

Die Systemklasse muss von variabler Blockgröße sein.

3.1 Speicherklassen mit variabler Blockgröße


Der Typ der Speicherklassen variabler Blockgröße ist PXMcVarsized.

Bei der Anforderung eines Speicherblocks aus dieser Klasse mit dem Befehl PxMcRequest
wird die gesamte Speicherklasse nach dem ersten, genügend großen Speicherbereich für
die Anforderung durchsucht. Dieser Block wird dann gegebenefalls geteilt und der an-
fordernden Task zur Verfügung gestellt. Bei der Freigabe eines Speicherblocks mit dem
Befehl PxMcRelease überprüft das Betriebssystem, ob angrenzende Speicherblöcke ebenfalls
unbelegt sind und vereint diese, wenn möglich zu einem größtmöglichen Speicherblock.
Daraus folgt, dass sowohl die Anforderung als auch die Freigabe von Speicher mit varia-
bler Blockgröße sehr zeitintensiv ist. Außerdem kann eine Fragmentierung des Speichers
entstehen, so dass zwar in der Summe genügend freier Speicher vorhanden ist, aber dieser
nicht zusammenhängend ist. Eine Speicheranforderung kann dann nicht erfüllt werden.
PXROS bietet keine Funktionen, Speicher zu defragmentieren. Es liegt im Aufgabenbe-
reich des Programmierers, eine Fragmentierung durch geeignete Einstellungen möglichst
zu vermeiden. Werden temporär kleine Speicherblöcke benötigt ist es daher sinnvoll, dies
durch lokale Variablen zu realisieren. Allerdings erhöht die Verwendung von Variablen für
große Speicherblöcke den Datenstack-Bedarf der Task, da dieser beim Task-Wechsel gesi-
chert werden muss. Es ist hier abzuwägen, was für den konkreten Fall sinnvoll erscheint.
Für den Fall, dass man häufig kurzzeitig Speicher benötigt mag es ratsam sein, einen
Speicherblock maximal benötigter Größe anzufordern und diesen ohne zwischenzeitliche
Freigabe weiter zu benutzen.
3 Speicherverwaltung Quickstart V1.0

3.2 Speicherklassen mit fester Blockgröße


Der Typ der Speicherklassen fester Blockgröße ist PXMcFixsized. Bei der Einrichtung ei-
ner Speicherklasse fester Blockgröße wird die gewünschte Blockgröße vom Programmierer
vorgegeben. Limitiert wird diese nur durch die vorhandenen Ressourcen, nicht aber durch
das Betriebssystem.
Da hier die Blockgröße feststeht, muss das Betriebssystem bei Anforderung eines Speicher-
blocks nicht erst nach einem Block passender Größe zu suchen. Ebenso muss bei der Frei-
gabe nicht berprüft werden, ob Speicherblöcke zusammengefasst werden können. Daraus
folgt, dass sowohl die Anforderung als auch die Freigabe von Speicher fester Blockgröße
wesentlich schneller abläuft als die Anforderung und Freigabe von Speicher mit fester
Blockgröße. Da die Systemklasse eine Speicherklasse fester Blockgröße sein muss, ist ein
Geschwindigkeitsgewinn bei der Einrichtung und Benutzung einer Speicherklasse fester
Größe zu erwarten. Ein weiterer Vorteil ist, dass bei fester Blockgröße keine Fragmentie-
rung entstehen kann.

3.3 Aufbau der Speicherverwaltung


Den Aufbau der für die Speicherverwaltung relevanten Teile zeigt Abbildung 3.1 auf Sei-
te 8.

Liste der belegten Liste der


Blöcke Speicherklasse

PXROS - Kernel
Speicherklassel 1

A R
Speicherklasse 2 lokale
Task 1 Speicherliste

A R
Speicherklasse k

lokale
PXMcSystemdefault Task m Speicherliste

Abbildung 3.1: Aufbau der Speicherverwaltung

Die Tasks fordern über eine Auftrag-Rckmelde Schnittstellen zum Betriebssystem Speicher-
blöcke an. Das Betriebssystem hat eine Liste der belegten Speicherblöcke, sowie eine Liste
der vorhandenen Speicherklassen. Wird eine Anforderung einer Task erfüllt, so bekommt
diese den Zeiger auf den Speicherbereich zurück gemeldet. Die Task muss sich die ihr

8 HighTec EDV-Systeme GmbH


Quickstart V1.0 3.4 Ablauf der Speicherbenutzung

zugeteilten Speicherblöcke in einer lokalen Speicherliste merken und kann damit auf den
Systemspeicher zugreifen.
Kommunikation wird realisiert, dass eine Task den Zeiger zu einem Speicherbereich per
Nachrichten-Objekt an eine andere Task übermittelt. Wie dies genau funktioniert wird
später bei den Kommunikationsdiensten beschrieben (siehe Abschnitt 4.1 auf Seite 12).

3.4 Ablauf der Speicherbenutzung


Den Ablauf der Benutzung von Speicher zeigt Abbildung 3.2 auf Seite 10.
Der Ablauf ist unterteilt in drei Bereiche, das Anlegen einer Speicherklasse im ersten
grau hinterlegten Bereich, das Benutzen einer Speicherklasse im zweiten grau hinterlegten
Bereich und das Löschen einer Speicherklasse im dritten grau hinterlegten Bereich.
Zum Anlegen einer Speicherklasse wird zunächst mit dem Befehl PxMcRequest beim Be-
triebssystem eine neue Speicherklasse angelegt. Dies wird durch einen entsprechenden
Parameter beim Aufruf von PxMcRequest festgelegt. Die neue Speicherklasse, hier ’mc’
genannt, ist nach dem erfolgreichen Anlegen noch leer und beinhaltet keinen Speicher.
Der Speicher muss zunächst aus der Systemklasse PXMcSystemdefault mit dem Befehl
PxMcRemoveBlk entnommen werden und mit PxMcInsertBlk in die neue Speicherklasse ein-
gefügt werden. Dieser Entnahme-Hinzufügen-Vorgang wird so lange wiederholt, bis die
Speicherklasse die gewünschte Speichermenge enthält. Wie viel Speicherblöcke in der neu-
en Klasse sind merken wir uns mit einem Mehrmarkenplatz im Petrinetz, wobei jede Marke
einem Speicherblock entspricht. Ist die Speicherklasse fertig initialisiert und mit Speicher
gefüllt, kann dieser Speicher von den Tasks mit dem Befehl PxMcTakeBlk unter Angabe
der Speicherklasse entnommen und benutzt werden. Wird der Speicherblock nicht mehr
benötigt, wird er mit PxMcReturnBlk ebenfalls unter Angabe der Speicherklasse wieder frei-
gegeben. Diese Speicherklasse muss die gleiche sein, aus der der Speicherblock entnommen
wurde.
Soll eine Speicherklasse wieder aufgelöst werden, muss zunächst der gesamte Speicher
entnommen und der Systemklasse (oder einer anderen Speicherklasse) wieder hinzugefügt
werden. Dies geschieht mit dem Befehl PxMcRemoveBlk und anschließendem PxMcInsertBlk
für jeden zuvor hinzugefügten Speicherblock. Ist die Speicherklasse dann komplett ent-
leert, kann sie mit PxMcRelease wieder entfernt werden und das Speicherklassen-Objekt
dem Systempool wieder hinzugefügt werden.

3.5 Befehle der Speicherverwaltung


Die Befehle der Speicherverwaltung mit deren Beschreibungen und Unterschieden sind
wie folgt definiert:

PxMcRequest Anfordern einer Speicherklasse


PxMcRelease Freigeben einer leeren Speicherklasse
PxMcRemoveBlk Endgültiges Entfernen eines Speicherblocks aus einer Speicherklasse,
es sind keine Verwaltungsinformationen mehr dem Block zugeordnet.
Die Anforderung kann einen Block aus einem Größenbereich enthalten.

HighTec EDV-Systeme GmbH 9


3 Speicherverwaltung Quickstart V1.0

PxMcRemoveBlk(mc,minsize,optsize,maxsize,sizefactor,**Blk,*size)

PxMcRequest(mc)

PxMcRemoveBlk(PXMcSystemdefault)

PxMcInsertBlk(mc)

Anlegen der Speicherklasse

PxMcTakeBlk(mc)

Menge der enthaltenen


Blöcke in einer
Speicherklasse

PxMcReturnBlk(mc)

Benutzung der Speicherklasse

PxMcRemoveBlk(mc)

PxMcInsertBlk(PXMcSystemdefault)

PxMcRelease(mc)

Löschen der Speicherklasse

Abbildung 3.2: Aufbau der Speicherbenutzung

10 HighTec EDV-Systeme GmbH


4 Mailboxkommunikation
Grundsätzlich bietet PXROS zwei Möglichkeiten der Kommunikation.

Mailboxen Die Kommunikation über Mailboxen, mit der hauptsächlich Wertekommuni-


kation.

Events Die Kommunikation über Events als Ereigniskommunikation (siehe Kapitel 5 auf
Seite 19).

Hinweis:
Wichtig ist, dass bei der Mailboxkommunikation die Nachrichten im-
mer an eine Mailbox gesendet werden, nicht an eine Task.

Es hat zwar jede Task ihre persönliche Mailbox, aber es können auch weitere systemweite
Mailboxen eingerichtet werden, die von mehreren Tasks ausgelesen werden.
Eine Nachricht besteht immer aus einem Nachrichten-Objekt, dass alle Verwaltungsin-
formationen enthält, sowie aus einem beliebig großen Datenbereich. Es kann entweder
eine komplette Nachricht beim System mit dem Befehl PxMsgRequest angefordert werden,
oder es kann ein schon vorhandener Datenbereich mit einem Nachrichten-Objekt, dem
sog. Envelope versehen und dann verschickt werden. Dieses Mit-einem-Umschlag-Versehen
entspricht einem gemeinsamen Speicher mit Zugriffssteuerung. Da PXROS intern immer
versucht, den Datenbereich der Nachrichten nicht zu kopieren um Ressourcen zu sparen,
sondern wenn möglich einen Zeiger auf den schon vorhandenen Datenbereich versendet,
ist die Speicherbelastung so gering wie möglich. Sollen zwei Tasks beispielsweise sich einen
Speicherbereich teilen, so wird mittels Envelope immer nur der Zeiger auf diesen Datenbe-
reich hin und her geschickt. Nur diejenige Task, die gerade die Nachricht mit dem Zeiger
besitzt, darf auf diesen Speicherbereich zugreifen, ihn auslesen und verändern. Ist sie fer-
tig damit, schickt sie der anderen Task via Envelope das Zugriffsrecht auf den Speicher in
deren Mailbox.
Prinzipiell können Nachrichten beliebig weiterverwendet werden. Selbst wenn sie an einen
ganz anderen Empfänger gehen und einen ganz anderen Inhalt haben ist das kein Problem.
Es wird einfach der Datenbereich und die Verwaltungsinformationen des Nachrichtenob-
jekts angepasst und schon kann die Nachricht weiter verschickt werden. Dadurch spart
man sich das wiederholte Anfordern und wieder Freigeben der Nachrichtenobjekte, was
natürlich auch Rechenzeit kostet.
Die Anzahl und die Größe der Mailboxen ist durch PXROS nicht beschränkt, sondern nur
durch den zur Verfügung stehenden Speicher. Es kann lediglich durch eine ungeschickte
Einstellung und Initialisierung des Betriebssystems beschränkt sein, wenn z.B. zu wenige
Objekte zur Verfügung stehen um genügend viele Nachrichten zu erzeugen.
PXROS unterscheidet zwischen normalen Tasks und den sogenannten Handlern.
4 Mailboxkommunikation Quickstart V1.0

Handler sind Software Interrupt Routinen, die höher priorisiert sind, als alle vorhandenen
Tasks und diese unterbrechen können.

Um eine möglichst schnelle Abwicklung der Handler zu gewährleisten, haben diese keine
eigene Mailbox. Handler können auch keine Nachrichten verschicken oder freigeben. Eine
Möglichkeit ist, einer Mailbox einen sogenannten Mailboxhandler zu zuordnen, der bei
Eintreffen einer Nachricht ausgeführt wird. Mit diesem Mailboxhandler sind noch weitere
sinnvolle Funktionen realisierbar, auf die in Abschnitt 4.5 auf Seite 16 eingegangen wird.

4.1 Sende-und Empfangsablauf


ReceiveMsg

SendMsg

PxMsgReceive

PxMsgRequest

PxMsgGetData
liefert Zeiger
auf Datenbereich

PxMsgGetData
liefert Zeiger
auf Datenbereich

Daten auslesen
und auswerten

Nachrichtendaten
ausfüllen

Datenbereich neu PxMsgRelease


ausfü.llen

PxMsgSend

PxMsgSend

Abbildung 4.1: Ablauf Senden und Empfangen von Nachrichten

Abbildung 4.1 auf Seite 12 zeigt den Ablauf des Versendens und Empfangens einer Nach-
richt. Zum Senden fordert eine Task zuerst eine Nachricht mit dem Befehl PxMsgRequest
beim Betriebssystem an. Nun muss sie mit dem Befehl PxMsgGetData den Zeiger auf den

12 HighTec EDV-Systeme GmbH


Quickstart V1.0 4.1 Sende-und Empfangsablauf

Datenbereich der Nachricht ermitteln um die Daten ausfüllen zu können. Der Empfänger
muss dazu wissen, wie er die Daten zu interpretieren hat. Nachdem der Datenbereich
ausgefüllt ist wird die Nachricht mit dem Befehl PxMsgSend verschickt.
Will eine Task eine Nachricht empfangen, so zeigt sie dieses mittels PxMsgReceive an. Ist
aktuell keine Nachricht vorhanden, so legt sich die Task schlafen, bis eine Nachricht ein-
trifft. Sobald eine Nachricht eingetroffen ist, wird die Task geweckt und ihr die Nachrichten
Id übermittelt. Nun muss sie mit PxMsgGetData den Zeiger auf den Datenbereich ermitteln
und kann dann die Daten auswerten. Die Nachricht hat jetzt ihren Zweck erfüllt. Sie kann
entweder mit PxMsgRelease wieder dem Betriebssystem zurückgegeben werden, oder man
kann die Nachricht weiterverwenden. Dazu wird einfach der Datenbereich neu ausgefüllt
und die Nachricht wieder mit PxMsgSend weiter geschickt.

Daten in lokaler
Variablen speichern

PxMsgEnvelop PxMsgReceive

PxMsgGetData
PxMsgSend liefert Zeiger auf
Datenbereich

Daten auslesen
und auswerten

PxAwaitMsgrel

PxMsgRelease

Task 1 Task 2

Abbildung 4.2: Ablaufen Senden und Empfangen von Nachrichten

Ähnlich ist der Vorgang bei der Verwendung des Envelope-Verfahrens, was in Abbil-
dung 4.2 auf Seite 13 dargestellt ist.
Die Daten, die verschickt werden sollen, sind hier schon in einer lokalen Variablen oder

HighTec EDV-Systeme GmbH 13


4 Mailboxkommunikation Quickstart V1.0

in einem dynamischen Speicherbereich vorhanden. Diese Daten werden mit dem Befehl
PxMsgEnvelop mit einem Nachrichten Objekt versehen und stellen nun eine vollständige
Nachricht dar. Diese Nachricht wird wie gewohnt mit PxMsgSend verschickt. Damit nun
die verschickende Task nicht irrtümlich auf den Datenbereich zugreift, legt sie sich mit
PxAwaitMsgrel schlafen, bis der verschickte Datenbereich wieder von der anderen Task
freigegeben wird.
Die empfangende Task empfängt die Nachricht gegebenfalls nach Warten mit dem Befehl
PxMsgReceive. Für diese Task ist die Nachricht nicht von einer Nachricht, die nicht durch
das Envelope-Verfahren erzeugt und verschickt wurde, zu unterscheiden. Daher ist der
Umgang mit dieser Nachricht auch identisch: Bestimmung des Zeigers auf den Datenbe-
reich mit PxMsgGetData, auswerten des Datenbereichs und anschlißend wird die Nachricht
wieder mit PxMsgRelease freigegeben. Das Betriebssystem aber gibt nicht die kompletten
Ressourcen frei, sondern nur das Nachrichtenobjekt, nicht den Datenbereich. Der Daten-
bereich gehört ja weiterhin der Task, welche Nachricht ursprünglich verschickt hat. Diese
Task wird nun wieder geweckt und kann mit ihren weiteren Aktionen fortfahren.

4.2 Nachrichtenpools
Nachrichtenpools sind eine Besonderheit der Nachrichtenkommunikation. Ihr Vorteil liegt
in der schnelleren Kommunikation, da die Nachrichten vorher schon angelegt wurden und
nicht mehr jedes Mal angefordert und erzeugt werden müssen. Dadurch ist auch eine
Ressourcenbegrenzung möglich, da vorher sichergestellt ist, dass eine bestimmte Anzahl
an Nachrichten vorhanden ist und so Engpässe vermieden werden können.
Damit der Umgang mit Nachrichten aus einem Nachrichtenpool einfach gestaltet bleibt,
wird einer Nachricht einfach eine Release-Mailbox zugewiesen. Wird diese Nachricht nun
mit dem Befehl PxMsgRelease von einer Task wieder freigegeben, so werden die Ressourcen
nicht dem Betriebssystem wieder zugeteilt, sondern die Nachricht wird einfach an diese
Release-Mailbox verschickt. Für die Tasks ist daher der Umgang mit Nachrichten aus
einem Nachrichtenpool identisch mit dem Umgang einer Nachricht, die nicht aus einem
Pool stammt. Diese Release-Mailbox stellt im Prinzip den Nachrichten-Pool dar.
Abbildung 4.3 auf Seite 15 zeigt das Anlegen und das Benutzen eines Nachrichtenpools.
Der obere grau hinterlegte Bereich zeigt das Anlegen eines Nachrichtenpools. Dazu wird
zunächst eine systemweite Mailbox namens MsgPool mit dem Befehl PxMbxRequest ange-
legt. Diese Mailbox, die den Nachrichten-Pool darstellt, wird nun mit Nachrichten gefüllt.
Das geschieht durch Anfordern einer Nachricht mit PxMsgRequest und anschließendem Zu-
weisen von MsgPool als Release-Mailbox dieser Nachricht. Danach kann die Nachricht mit
PxMsgRelease freigegeben werden und wird dadurch an die Mailbox MsgPool verschickt.
Alternativ könnte man hier auch ein PxMsgSend(MsgPool) aufrufen. Dieser Vorgang des
Füllens des Nachrichtenpools wird beliebig oft wiederholt, bis genügend Nachrichten an-
gelegt wurden.
Nun kann der Nachrichtenpool genutzt werden, was im unteren grau hinterlegten Bereich
gezeigt wird. Eine Task entnimmt mit PxMsgReceive eine beliebige Nachricht aus dem
Nachrichten-Pool. Diese Nachricht wird nach Ermittlung des Zeigers auf den Datenbe-
reich mit PxMsgGetData mit ihren Daten versehen und mit PxMsgSend verschickt. Ist die

14 HighTec EDV-Systeme GmbH


Quickstart V1.0 4.2 Nachrichtenpools

Init MsgPool

PxMbxRequest(&MsgPool)

PxMsgRequest(&msg,...)

PsMsgInstallRelmbx(msg,
MsgPool)

PxMsgRelease(&msg)

weiteres Objekt anlegen

Send Msg

PxMsgReceive(&msg,
MsgPool)

PxMsgGetData liefert
Zeiger auf Datenbereich

Nachrichtendaten ausfüllen

PxMsgSend

Abbildung 4.3: Anlegen eines Nachrichtenpools

HighTec EDV-Systeme GmbH 15


4 Mailboxkommunikation Quickstart V1.0

Nachricht dann angekommen und ausgewertet, wird sie durch PxMsgRelease wieder dem
Nachrichten-Pool zugesandt und steht wieder zur Verfügung.

Man könnte auch einen Nachrichten-Pool mit vorgefertigtem Inhalt erzeugen und müsste
dann nicht jedesmal die Nachrichten mit dem entsprechenden Inhalten versehen. Dann
wäre lediglich ein PxMsgReceive vom MsgPool und ein anschließendes PxMsgSend an die
gewünschte Mailbox nötig.

4.3 Anlegen und Freigeben von Mailboxen


Wie in dem Beispiel zum Anlegen eines Nachrichten-Pools zu erkennen, dient der Be-
fehl PxMbxRequest dem Anlegen einer systemweiten Mailbox. Diese kann mit dem Befehl
PxMbxRelease auch wieder freigegeben werden, nachdem alle Nachrichten entnommen wur-
den.

4.4 Spezielle Befehlsvarianten


Es gibt bei allen Befehlen, die ein Warten hervorrufen können (z.B. PxMsgReceive) auf
zwei weitere Varianten. Diese sind PxMsgReceive_NoWait und PxMsgReceive_EvWait. Wird
bei dem standardmäßigen PxMsgReceive so lange gewartet, bis eine Nachricht eintrifft, so
kehrt PxMsgReceive_NoWait sofort ohne Warten ggf. mit einer Fehlermeldung zur Task
zurück. Bei PxMsgReceive_EvWait wartet die Task solange bis entweder eine Nachricht
empfangen, oder bis ein angegebenes Event signalisiert wurde (wie Events signalisiert
werden wird später erklärt). Die Task muss danach erst einmal überprüfen, weswegen sie
geweckt wurde, also ob eine Nachricht angekommen ist, oder ein Event eingetreten ist,
beispielsweise ein Timeout.

4.5 Mailboxhandler
Eine weitere Besonderheit besteht in der Möglichkeit, Nachrichten priorisiert zu verschi-
cken. Normalerweise werden Nachrichten nach dem FIFO-Prinzip in den Mailboxen ver-
waltet.

Wird aber eine priorisierte Nachricht an eine Mailbox verschickt, so wird sie vor alle bisher
vorliegenden Nachrichten eingereiht, auch vor vorher empfangene priorisierte Nachrichten.
Das Versenden von solchen priorisierten Nachrichen erfolgt mit PxMsgSend_Prio und ist
ansonsten identisch mit PxMsgSend.

Wie zuvor schon erwähnt kann einer Mailbox ein Mailboxhandler zugewiesen werden.
Dieser Mailboxhandler kann so installiert werden, dass er entweder durch alle Nachrichten
aktiviert wird, oder nur durch priorisierte oder nur durch unpriorisierte Nachrichten.

Einen beispielhaften Ablauf eines Mailboxhandlers zeigt Abbildung 4.4 auf Seite 17. Ei-
ner mit PxMsgRequest angeforderten Nachricht wird mit PxMbxInstallHnd ein Mailboxhand-
ler zugewiesen. Nun wird eine mit PxMsgRequest angeforderte und mit Daten versehene
Nachricht mit PxMsgSend an diese Mailbox verschickt und sich bis zur Signalisierung eines

16 HighTec EDV-Systeme GmbH


Quickstart V1.0 4.5 Mailboxhandler

PxMbxRequest(mbx)

PxMbxInst allHnd(mbx)

PxMsgRequest

Formular ausfüllen

PxMsgSend(mbx)

PxAwaitEvents PxTaskSignalEvents_Hnd

Task 1 Mailbox- Handler

Abbildung 4.4: Ablauf des Mailboxhandlers

Events schlafen gelegt. Währenddessen wird der Mailboxhandler aktiviert, und signali-
siert der Task ein Event. Die Task wird wieder geweckt und weiß nun, da die Nachricht
in der Mailbox angekommen ist.

HighTec EDV-Systeme GmbH 17


4 Mailboxkommunikation Quickstart V1.0

18 HighTec EDV-Systeme GmbH


5 Signalisieren von Events
Events werden zur Ereigniskommunikation benutzt. Sie werden immer einer Task direkt
signalisiert. Jeder Task können 32 verschiedene Events signalisiert werden. Diese Events
werden in einer Bit-Maske gespeichert. Daher ist eine logische Verknüpfung mittels UND-
und ODER-Operatoren möglich. Das hat zur Folge, das Tasks gleichzeitig auf mehrere
Events reagieren und warten können.
Wenn sich eine Task schlafen legt muss sie angeben, bei welchen signalisierten Events sie
geweckt werden soll. Dies geschieht mit dem Befehl PxAwaitEvents( list ), wobei diese Liste
durch logisches ODER verknüpft ist. Das Signalisieren eines Events kann von einer Task
oder von einem Handler durch den Befehl PxTaskSignalEvents(id, list ) erfolgen, wobei als
Parameter die Task-Id und die zu signalisierende Events-Liste übergeben werden.

Hinweis:
Handlern ist es möglich, Events zu signalisieren, obwohl ihnen sel-
ber keine Events signalisiert werden können. Dazu muss der Befehl
PxTaskSignalEvents_Hnd in einer speziell optimierten Version benutzt
werden.

Durch den Aufruf von PxAwaitEvents wird die betreffende Event-Liste gelöscht und die
Task legt sich schlafen, falls nicht mindestens ein Event bereits signalisiert worden ist.
Das Löschen der Eventliste kann auch mit PxResetEvents erfolgen, der Unterschied ist,
dass sich der Task-Zustand nicht ändert wie bei PxAwaitEvents.
Bei verschiedenen Betriebssystem-Diensten ist paralleles Warten auf Events möglich. In
dem Fall muss der Befehl mit dem Anhang _EvWait aufgerufen werden (siehe Beispiel
PxMsgReceive_EvWait in Abschnitt 4.4 auf Seite 16).

5.1 Ablauf der Event-Signalisierung


Abbildung 5.1 auf Seite 20 zeigt den Ablauf der Signalisierung von Events und des Wartens
auf Events. Task 1 legt sich mit dem Befehl PxAwaitEvents auf das Eintreffen eines Events
schlafen. Eine zweite Task signalisiert Task 1 das entsprechende Event mit dem Befehl
PxTaskSignalEvents. Daraufhin weckt das Betriebssystem Task 1 wieder auf.

Soll von einem Handler aus ein Event signalisiert werden, so muss statt PxTaskSignalEvents
der speziell für Handler optimierte Befehl PxTaskSignalEvents_Hnd benutzt werden (siehe
dazu Beispiel Ablauf Mailbox-Handler in Abschnitt 4.5 auf Seite 16).

5.2 Besonderheiten der Kommunikation


Es ist es möglich, auf mehrere Mailboxen parallel zu warten. Dazu installiert man an einer
zweiten Mailbox einen Mailboxhandler, der einfach nur der Task ein Event signalisiert.
5 Signalisieren von Events Quickstart V1.0

PxAwaitEvents() PxTaskSignalEvents()

Task 1 PXROS- Kernel Task 2

Abbildung 5.1: Ablauf Signalisieren und Warten von / auf Events

Anschließend legt man sich mittels PxMsgReceive_EvWait in der Task schlafen. Kommt
eine Nachricht in der ersten Mailbox an, so wird die Task geweckt und erhält direkt die
Nachricht. Kommt eine Nachricht in der zweiten Mailbox an, so wird der Mailboxhand-
ler aktiviert, der seinerseits der Task ein Event signalisiert, wodurch die Task ebenfalls
geweckt wird. Die Task muss nur nach dem Wecken erst überprfen, weshalb sie geweckt
wurde. Somit ist es möglich, auf beliebig viele Mailboxen zu warten, indem man für jede
weitere Mailbox einen Mailboxhander installiert.
Des Weiteren sieht PXROS die Möglichkeit vor, Funktionen durch Events abbrechen
zu lassen. Dazu muss die Funktion ihre Bereitschaft zum Abbrechen mit dem Befehl
PxExpectAbort zuerst anzeigen. Einsatzgebiet dafür ist beispielsweise ein Not-Aus-Taster,
der eine Motor-Steuer-Task sofort abbrechen lässt, sobald er ausgelöst wird.

5.3 Aufbau des Kommunikationssystems


Abbildung 5.2 auf Seite 21 zeigt alle für den Programmierer relevante Teile des Kommu-
nikationssystems.
Ebenso wie die Handler sind die Tasks per Auftrag-Rückmelde-Schnittstellen an das Be-
triebssystem gekoppelt. Jede Task hat ihre eigene Mailbox und einen eigenen Bereich für

20 HighTec EDV-Systeme GmbH


Quickstart V1.0 5.3 Aufbau des Kommunikationssystems

vorgefertigte Nachrichten. Außerdem gibt es im Speicher noch die systemweiten Mail-


boxen und Nachrichtenpools, auf die alle Tasks und das Betriebssystem Zugriff haben.
Das Betriebssystem verwaltet dazu noch eine Liste der einzelnen Events für die einzelnen
Tasks. Diese können per Auftrag gesetzt, gelöscht oder abgefragt und sich darauf schlafen
gelegt werden.

A
Handler 1
Shared R
Memory
A
Handler m
R

Mbx Task 1
A
Task 1
R PXROS
Vorgef. Msg Kernel

Mbx Task n
A
Task n
R
Vorgef. Msg

Nachrichten-
Pools

Systemweite
Mailboxen
Event-Liste für
einzelne Tasks

Abbildung 5.2: Aufbau der Kommunikationssystems

HighTec EDV-Systeme GmbH 21


5 Signalisieren von Events Quickstart V1.0

22 HighTec EDV-Systeme GmbH


6 Zeitbehandlung in PXROS
Prinzipiell ist PXROS zeitfrei. Es wird keine aktuelle Uhrzeit benötigt und auch kein
Bezug zu irgendeiner Systemzeit. Allerdings gibt es einige Funktionen, die verzögert aus-
geführt werden müssen, oder andere, die in periodischen Abständen ausgeführt werden
sollen. Es gibt auch noch die Notwendigkeit von Timeouts.
Um diese Funktionen realisieren zu können bietet PXROS eine Art flexible Systemzeit.
Die Einheit sind die sogenannten PXROS-Ticks, wobei die Länge dieser Ticks variabel
ist. Das Weiterzählen der PXROS-Ticks geschieht mit dem Befehl PxTickDefine_Hnd. Wie
man an der Endung _Hnd erkennen kann, ist dies eine Funktion für einen Handler. Dieser
Handler kann von jeder periodischen Quelle angestoßen werden (über interne oder externe
Hardware-Interrupts), wie beispielsweise von einem Hardwaretimer. Da jedes Weiterzäh-
len kurz das System unterbricht, sollte man die Schritte der einzelnen Ticks möglichst groß
wählen um möglichst wenig Systembelastung zu erzeugen. Ist beispielsweise die kleinste
benötigte Zeitverzögerung 10 ms, so sollte ein Tick auf 10ms eingestellt werden. Abfragen
kann man den aktuellen Zählerstand mit dem Befehl PxTickGetCount.
Wird PxTickDefine_Hnd aufgerufen, dann überprüft PXROS ob für den aktuellen Zähler-
stand Funktionen ausgeführt werden müssen. Wenn nicht, kehrt der Handler wieder zur
normalen Abwicklung der Applikation zurück. Falls aber etwas auszuführen ist, werden
die entsprechenden auszuführenden Handler gestartet, bevor die Abwicklung der Tasks
fortfahren kann.
Es werden wie schon angedeutet drei verschiedene zeitversetzte Abwicklungen unterstützt:

• Timeouts

• periodische Timeouts

• Delays

6.1 Timeout
Ein Timeout-Auftrag benötigt eine Daten-Struktur vom Typ PxTo_T, in der alle benö-
tigten Verwaltungsinformationen gespeichert werden. Diese Struktur kann entweder lokal
angelegt sein, dynamisch erzeugt werden, oder auf dem Daten-Stack der Task liegen.
Abbildung 6.1 auf Seite 24 zeigt den Ablauf eines Timeout-Auftrages. Zuerst wird der
Timer initialisiert unter der Angabe der Ticks, wie lange das Timeout dauern soll und des
Ereignisses, dass der Task nach Ablauf des Timeouts gemeldet werden soll. Die Initialisie-
rung erfolgt mit dem Befehl PxToInit. Gestartet wird der Auftrag mit dem Befehl PxToStart.
Danach legt sich die Task auf das Timeout-Event mit PxAwaitEvents schlafen. Irgendwann
später wird das Betriebsystem dann nach Ablauf des Timeouts die Task durch Signalisie-
ren des angegebenen Events wieder wecken. Der Timeout-Auftrag kann nun mit PxToClear
6 Zeitbehandlung in PXROS Quickstart V1.0

PxToInit(100,EV_TO)

PxToStart

PxAwaitEvent(EV_TO)A

T=100 Ticks

PXROS- Aktion

PxToClear

Task PXROS- Kernel

Abbildung 6.1: Ablauf eines Timeout Auftrags

gelöscht werden. Alternativ kann man den Auftrag aber auch einfach mit PxToStart wieder
neu starten.
Es gibt fünf Befehle, die einen Timeout steuern.

PxToInit Das Initialisieren erfolgt wie gerade erklärt mit PxToInit.


PxToStart Starten des Auftrages erfolgt durch PxToStart.
PxToStop Der Auftrag kann auch vor Ablauf des Timeouts gestoppt werden mit
dem Befehl PxToStop.
PxToChange Möchte man den Timeout-Auftrag ändern steht einem PxToChange zur
Verfügung.

24 HighTec EDV-Systeme GmbH


Quickstart V1.0 6.2 Periodischer Timeout

PxToClear Das Löschen erfolgt mit PxToClear.

Nach einem PxToClear muss der Auftrag wieder neu eingerichtet werden mit PxToInit,
während er bei Start, Stop und Change nicht wieder neu initialisiert werden muss.

6.2 Periodischer Timeout

PxPeInit(100,EV_PE)

PxPeStart

PxAwaitEvents(EV_PE) Perioden Timer starten

Task wecken

Task Aktionen

weiter Timer abbrechen

PxPeClear

Perioden Auftrag löschen

Task 1 PXROS - Kernel

Abbildung 6.2: Ablauf eines periodischen Timeouts

Prinzipiell ist der periodische Timeout identisch mit dem einfachen Timeout. Es wird hier
eine Daten-Struktur vom Typ PxPe_T benötigt. Die Befehle sind analog zum Timeout

HighTec EDV-Systeme GmbH 25


6 Zeitbehandlung in PXROS Quickstart V1.0

nach dem selben Schema, nur dass bei den Befehlen das ’To’ durch ein ’Pe’ zu ersetzen
ist: PxPeInit, PxPeStart, PxPeStop, PxPeChange und PxPeClear.

Damit ergibt sich der in Abbildung 6.2 auf Seite 25 gezeigte Ablauf. Der Timer wird mit
PxPeInit initialisiert und anschließend mit PxPeStart gestartet. Nun legt sich die Task mit
PxAwaitEvents schlafen. Nach Ablauf der angegebenen Zeit wird die Task wieder geweckt
und wickelt ihren Programmteil ab, bis sie sich wieder schlafen legt oder mit PxPeClear
den periodischen Timeout Auftrag löscht. Alternativ kann mit PxPeStop der periodische
Timeout angehalten werden.

6.3 Delay Aufträge


Der Delay-Auftrag aktiviert nach vorgegebener Zeit eine Funktion auf Handler-Ebene.
Dazu muss man beachten, dass man in der Funktion nur die für Handler optimierten und
zur Verfügung stehenden Befehle nutzen kann.

Abbildung 6.3 auf Seite 27 zeigt den Ablauf eines solchen Delay-Auftrages. Zunächst wird
mit PxDelayRequest ein Delay-Objekt beim Betriebssystem angefordert. Dieses wird dann
mit PxDelaySched eingeplant. Die Task führt nun mit beliebigen anderen Aktionen fort.
Sie ist von dem Delay-Auftrag nicht mehr betroffen. Einzig der Abbruch eines Delay-
Auftrages erfolgt noch auf der Task-Ebene durch erneutes Einplanen mit der Zeit 0 durch
PxDelaySched(0).

Ist der Delay-Auftrag aber erst einmal eingerichtet, startet PXROS nach der angegebenen
Zeit den angegebenen Handler, falls der Auftrag mittlerweile nicht gelöscht wurde. Der
Handler kann dann beispielsweise der Task ein Event signalisieren.

Nach der Abwicklung des Delay-Auftrags kann er mit PxDelayRelease wieder freigegeben
und die Ressourcen dem Betriebssystem zugeteilt werden. Voraussetzung ist, dass der
Delay Auftrag nicht mehr benötigt wird.

6.4 Aufbau der Zeitverwaltung


Der Aufbau der Zeitverwaltung zeigt Abbildung 6.4 auf Seite 28. Das Betriebssystem muss
sich die Liste der eingeplanten Zeitaufträge merken, in der in der zeitlichen Reihenfolge
alle Timeouts, periodische Timeouts und auszuführende Delay-Aufträge vermerkt sind.
Außerdem wird die Events-Liste für die Tasks benötigt um diese nach einem Timeout
wecken zu können. Der aktuelle Zählerstand der Systemuhr muss auch gespeichert werden.
Dieser wird von einem Zeit-Handler weitergezählt. Die anderen Tasks und Handler haben
Zugriff auf den Objekt-Systempool und die einzelnen Delay-Objekte, sowie möglicherweise
dynamisch angelegte Strukturen für die Timeouts.

6.5 Scheduling
Da PXROS ein Multitasking-System ist, können mehrere Tasks im zeitmultiplex ’gleich-
zeitig’ ablaufen. Diese Tasks stellen den größten Teil der Funktionalität der Applikation

26 HighTec EDV-Systeme GmbH


Quickstart V1.0 6.5 Scheduling

PxDelayRequest

PxDelaySched(t=100)

Abbrechen?
Einplanen des
Delayauftrages

Sonstige Aktionen PxDelaySched(0)

Delayauftrag Delayauftrag
löschen starten

PxTaskSignalEvents_Hnd(task1)

PxDelayRelease

Task 1 PXROS Kernel Delay Handler

Abbildung 6.3: Ablauf eines Delay Auftrages

dar. Außer den Tasks gibt es noch die Hardware-Interrupt-Handler, die auf Hardware-
Interrupts reagieren und die Software-Interrupt-Handler, die bei bestimmten Betriebs-
systemdiensten benötigt werden. Welcher Code gerade ausgeführt wird, bestimmt das
Betriebssystem zu jeder Zeit. Dabei wird ein kooperatives, unterbrechendes prioritäts-
gesteuertes Scheduling realisiert. Das bedeutet, das höher priorisierte Teile des Systems
niedriger priorisierte Teile unterbrechen um ihren eigenen Code auszuführen. Niedriger
priorisierte Systemteile können aber höher priorisierte Systemteile nicht unterbrechen und
müssen warten, bis der Abwickler von den höher priorisierten freigegeben wird. Die höchs-

HighTec EDV-Systeme GmbH 27


6 Zeitbehandlung in PXROS Quickstart V1.0

Liste der
geplanter Event-Liste PXROS-Tick
Zeitaufträge der Tasks Count

Delayobjekte
PXROS - Kernel

A R

OpoolSystemdefault Task 1 A R

A R A R
Task n
A R

Timeout
Strukturen Handler 1 Zeit-Handler
PxTickDefine_Hnd

periodische
Timeout
Strutkuren Handler m

Abbildung 6.4: Aufbau der Zeitverwaltung

te Priorität haben Hardware-Interrupt-Handler, die je nach Prozessor auch unterschiedlich


priorisiert sein können. Danach folgt PXROS und die Software-Interrupt-Handler. Unters-
te Priorität haben die Tasks, die aber wiederum genauer abgestuft sind.
Bei den Hardware-Interrupt-Handlern wird sofort die aktuelle Abwicklung unterbrochen
und der entsprechende Handler ausgeführt. Die Latenzzeit zum Umschalten ist abhän-
gig davon, wie der Handler installiert wurde (siehe Kapitel 7 auf Seite 31). Die eige-
nen Prioritätsabstufungen von Prozessoren, falls vorhanden, bleiben erhalten. PXROS
sperrt zu keinem Zeitpunkt Interrupts und verändert auch nichts an der Interruptbe-
handlung des Prozessors. Software-Interrupt-Handler sind vor allem Delay-Handler (siehe
Abschnitt 6.3 auf Seite 26) und Mailboxhandler (siehe Abschnitt 4.5 auf Seite 16). Sie
können von Hardware-Interrupt-Handlern unterbrochen werden, unterbrechen aber ihrer-
seits alle Tasks. Eine Abstufung innerhalb dieser Gruppe erfolgt nicht. Stehen mehrere
Software-Interrupt-Handler zur Ausführung an, so werden diese nacheinander ausgeführt.
Das Task-Scheduling ist prioritätsgesteuert. Alle Tasks werden von Software-Interrupt-
Handlern und Hardware-Interrupt-Handlern unterbrochen. Die Prioritäten der Tasks wer-
den bei deren Erzeugung angegeben und können während der Laufzeit mit dem Befehl
PxTaskSetPrio beliebig verändert werden. Die höchste Prioritätsstufe ist 0. Die niedrigste
Prioritätsstufe ist abhängig vom Prozessor und liegt meist bei 15 oder 31, je nachdem
ob es sich um einen 16 Bit oder einen 32 Bit Prozessor handelt. Wichtig ist die Relation
der Tasks untereinander, nicht die absolute Prioritätsstufe. Es werden nur bereite Tasks
gescheduled, und zwar immer die Task mit der höchsten Priorität. Bei mehreren Tasks

28 HighTec EDV-Systeme GmbH


Quickstart V1.0 6.5 Scheduling

gleich hoher Priorität bekommt diejenige den Abwickler zugeteilt, die am längsten bereit
ist, d. h. die am längsten auf den Abwickler wartet.

Erwartet
Nachricht
Aktiv

Höher priorisierte
Task wird bereit

Bereit Wartend
Wird Task mit
höchster Priorität Nachricht
trifft ein

Abbildung 6.5: Zustände einer Task

Einer Task wird genau einer der vier möglichen Zustände:

• Schlafend

• Bereit

• Aktiv

• Wartend

zugeordnet. Im Zustand schlafend verbraucht die Task keine Ressourcen. Erst mit dem
Befehl PxTaskCreate wird eine Task erzeugt und befindet sich nun im Zustand bereit. Mit
entsprechender Parametrisierung von PxTaskCreate kann die Task zu Beginn auch direkt in
dem Zustand wartend erzeugt werden. Ein Ereignis ist dann nötig um die Task das erste
Mal zu aktivieren. Es ist immer genau eine Task im Zustand aktiv und damit im Besitz
des Abwicklers. Diese Task wird vom Betriebssystem anhand der oben beschriebenen
Prioritäten ermittelt. Es gibt drei Möglichkeiten, wie eine Task die Abwicklerkontrolle
verlieren kann: Sie geht in den Zustand wartend über durch Aufruf eines PXROS-Dienstes,
eine höher priorisierte Task wird durch einen Handler-oder Betriebssystem-Aufruf bereit,
oder die aktive Task verändert ihre Priorität oder die Priorität einer anderen Task. Diese
Prioritäten-Änderung wird wie ein kurzzeitiges Warten und dann wieder Bereit-werden
der Task gehandhabt, so dass schon länger wartende Tasks auf der gleichen Prioritätsebene
vorher abgewickelt werden.
Eine Task kann nur auf eine Weise terminiert werden. Sie muss aktiv sein und selber den
Befehl PxDie() aufrufen. Dazu muss vorher der Die-Server mit dem Befehl PxDiesrvInit
initialisiert worden sein. Der Die-Server läuft nun als Task im System. Aufgrund der
Notwendigkeit des Die-Servers ist eine Terminierung nur sinnvoll, wenn mehrere Tasks
beendet werden sollen, da eine Terminierung eine Ressourcenfreigabe als Hintergedanke
hat und der Die-Server selber Ressourcen belegt.

HighTec EDV-Systeme GmbH 29


6 Zeitbehandlung in PXROS Quickstart V1.0

Das Terminieren einer fremden Task ist bewusst nicht möglich, da sonst nicht gewährleis-
tet werden kann, dass keine Ressourcen verloren gehen. Die vollständige Kenntnis über
die belegten Ressourcen hat nur die zu terminierende Task selber und diese Informationen
wrden bei einer Fremd-Terminierung verloren gehen. Es kann in einem ereignisgesteuer-
ten System, das nicht überlastet ist, immer sichergestellt werden, dass eine Task auch
in den Besitz des Abwickler gelangt und sich selbst terminieren kann. Andernfalls liegt
wahrscheinlich ein Designfehler vor.
Es sei am Rande bemerkt, das es auch spezielle PXROS-Versionen gibt, bei denen neben
den Task-Prioritäten auch ein preemtives Zeitscheibenverfahren (Timeslicing) Anwendung
findet.

30 HighTec EDV-Systeme GmbH


7 Realisierung des IRQ-Anschlusses
Der IRQ-Anschluß ist naturgemäß immer von der verwendeten Hardware abhängig. Den-
noch bietet PXROS einige Dienste, die eine hardwareunabhängige Einrichtung von Inter-
rupts unterstützen. Dazu muss durch den Aufruf von TrapInit diese Schnittstelle initiali-
siert werden. Danach kann mit dem Befehl TrapInstallChandler eine C-Funktion als Handler
installiert werden, die bei Auftreten des Interrupts mit dem angegebenen Argument aus-
geführt wird. Die Funktion TrabInstallChainedChandler ist ähnlich, allerdings bietet sie bei
Auftreten eines bestimmten Interrupts die Möglichkeit, mehrere C-Funktionen hinterein-
ander ausführen zu lassen. Diese Zuordnungen sind auch dynamisch zur Laufzeit verän-
derbar, wodurch sich aber beim Eintreten eines Interrupts die Latenzzeit etwas erhöht.
Oft ist eine dynamische Zuordnung gar nicht notwendig, besonders bei hochfrequenten
Interrupts. Für diesen Fall können die Interrupt-Handler auch statisch mit vorgefertigten
Makros installiert werden.
Die Module für den Trap-Anschluss sind nicht wie die anderen Module in Bibliotheken
vorhanden, sondern in Form von Quelltext, damit man diese an die Hardware anpassen
und parametrisieren kann. Diese Module müssen also editiert, compiliert und zu dem
Projekt hinzu gelinkt werden.
Außerdem besteht die Möglichkeit, Interrupt-Routinen mit z.B. Code in Assembler ein-
zubinden. Dann ist allerdings dafür Sorge zu tragen, dass der von den Routinen benutze
Kontext genauso wiederhergestellt wird und das ggf. noch Platz auf dem Prozessor-Stack
für Funktionsaufrufe zur Verfügung steht.

7.1 Interruptanschluß an einen Prozessoren


Die meisten Prozessoren unterstützen vollkommen die Funktionsweise von TrapInstallChandler
mit der angesprochenen erhöhten Latenzzeit vor und nach dem Ausführen des Interrrupt-
Service Handlers. Liegt die Interrupt-Vektortabelle im Adressbereich des RAM, so sind
keine Einschränkungen nötig. Falls die Interrupt-Vektortabelle im Adreßereich des ROM
liegt, so muss bei allen dynamisch definierten Handlern ein _TrapDispatch für die jeweiligen
Interrupts aufgerufen werden.
Da aber meist die Handler schon bei der Erzeugung der Programme feststehen, können sie
mittels definierter Makros im Quelltext statisch installiert werden. Die Definition dieser
Makros erfolgt in der Header-Datei pxtrap.h. Die Latenzzeiten werden dadurch deutlich
reduziert, und zur Laufzeit ist nur ein PxStrapInit vor dem ersten Interrupt aufzurufen.
Der Interruptanschluss mit Hilfe der PXROS-Dienste ist wie in Abbildung 7.1 auf Seite 32
gezeigt aufgebaut.
Ein Gerät erzeugt einen Interrupt. Der Dispatcher sieht in der Interrupt-Vector-Tabelle
daraufhin nach und springt dann zu der dort angegebenen Stelle, die mit dem Befehl
TrapInstallChandler angegeben wurde. Vor der eigentlichen Ausführung des Handlers muss
noch der Kontext gesichert werden, was zu einer leicht erhöhten Latenzzeit führt. Der
7 Realisierung des IRQ-Anschlusses Quickstart V1.0

Gerät

Port-
Register

Handler

Dispatcher
IR VecTab PXROS- Kernel

A R

Task

Abbildung 7.1: Aufbau des Interrupt-Systems

Handler wird nun abgewickelt. Danach wird von PXROS wieder der Kontext hergestellt.
Für den Dispatcher ist nun der Interrupt beendet und er aktiviert wieder das Betriebs-
system. Dieses prüft, welche Task nun den Abwickler zugeteilt bekommt, da sich auf
Grund des Interrupts ja die Prioritäten oder Taskzustände geändert haben könnten. Die
Abwicklung geht nun ganz normal weiter.

32 HighTec EDV-Systeme GmbH


8 Weitere Möglichkeiten der Objektverwaltung
Über die in Kapitel 2 auf Seite 3 beschriebene Objektverwaltung hinaus gibt es unter
PXROS einige weitere Besonderheiten der Objektverwaltung, auf die nun noch einmal
genauer eingegangen werden soll.

8.1 Objektpool-Typen
PXROS unterscheidet zwischen zwei Typen von Objekt-Pools, den realen und den vir-
tuellen. Während bei den realen Objektpools eine echte Aufteilung der Objekte in ver-
schiedene Pools erfolgt, sind virtuellen Pools keine eigenen Objekte zugeordnet, sondern
ein realer Quellpool. Die Objekte werden von dem virtuellen Pool aus diesem realen Pool
entnommen, sofern der virtuelle Pool noch nicht alle Objekte vergeben hat und sofern im
Quellpool noch Objekte zur Verfügung stehen. Da virtuelle Pools sowohl größer als auch
kleiner als der zugrunde liegende reale Quellpool sein können, ist eine Realisierung von
Zugriffsbegrenzung z.B. zum Abschotten sicherheitsrelevanter System-Bereiche möglich.
Dazu entnehmen beispielsweise die sicherheitskritischen Teile ihre Objekte aus dem rea-
len Objektpool, wärend alle anderen aus einem virtuellen Objektpool bedient werden, der
aber kleiner ist, als der reale Quellpool. So ist immer ein bestimmter Objektüberschuß für
die sicherheitsrelevanten Teile gesichert.
Virtuelle Objekt-Pools dienen daher hauptsächlich zur Begrenzung des Objektverbauchs
ohne eine konkrete Verteilung vorzunehmen. Ein Quellpool kann mehrere virtuelle Pools
bedienen, wobei es sogar möglich ist, dass die Anzahl aller Objekte der virtuellen Pools
größer ist, als die Anzahl der maximal im Quellpool vorhandenen Objekte. Daher ist
eine Benutzung von virtuellen Ports nur bei Anwendungen sinnvoll, bei denen Warten
akzeptabel ist. Denn für den Fall, dass der virtuelle Pool leer ist aber der Quellpool noch
Objekte enthält, muss so lange gewartet werden, bis ein anderes Objekt dem virtuellen
Pool wieder zurckgegeben wird.
Die virtuellen Objekt-Pools sind vom PXROS-Typ PXOpoolVirtual.
Reale Objekt-Pools stellen eine echte Partitionierung der Objekte dar. Für sicherheitsre-
levante Bereiche empfiehlt es sich daher, einen eigenen realen Objekt-Pool anzulegen um
eine ausreichende Versorgung mit Objekten gewährleisten zu können. Die realen Objekt-
Pools sind vom PXROS-Type PxOpoolReal.
Die Struktur der Objektpools zeigt Abbildung 8.1 auf Seite 33.

Standard- 0..n 1 Reale 1 0..n Reale


Objekte Objektpools Objektpools

Abbildung 8.1: ER-Diagramm zur Struktur der Objektpools


8 Weitere Möglichkeiten der Objektverwaltung Quickstart V1.0

8.2 Beispielablauf der Objektverwaltung


Abbildung 8.2 auf Seite 35 zeigt beispielhaft den Ablauf des Anlegens, Benutzens und der
wieder Freigabe eines Objektpools. Mit dem ersten Befehl wird aus einem realen Pool ein
neuer Objektpool angefordert, der fünf Objekte enthalten soll. Danach wird dieser reale
Pool als Quellpool für einen virtuellen Objektpool mit zwei Elementen benutzt. Nach dem
Anlegen des virtuellen Pools sind im Quellpool noch vier Objekte übrig, denn es wurde
ein Objekt als virtuelles Objektpool-Objekt entnommen.
Im zweiten grau hinterlegten Bereich wird die Benutzung des neu angelegten Objektpools
beschrieben. Dazu wird ein beliebiger PXROS-Dienst, beispielsweise die Anforderung ei-
nes Delay-Objekts durch PxDelayRequest_NoWait, benutzt. Es wird nun also aus dem vir-
tuellen Objektpool dreimal hintereinander ein Objekt angefordert. Bei den ersten beiden
Anforderungen sind sowohl der virtuelle Objektpool als auch der Quellpool nicht leer und
die Anforderung gelingt. Bei der dritten Anforderung allerdings ist der virtuelle Objekt-
pool leer, obwohl im Quellpool noch Objekte vorhanden wären. Die Anforderung schlägt
fehl, so dass die Task so lange warten wrde, bis sie ein Objekt zugeteilt bekäme. Es gibt al-
lerdings auch die Möglichkeit der Anforderung ohne Warten durch PxDelayRequest_NoWait.
In diesem Falle wird direkt ein Fehler zurück gemeldet, wovon hier ausgegangen wird um
den weiteren Ablauf des Petrinetzes zu ermöglichen. Der nächste grau hinterlegte Bereich
beschreibt nun die Rückgabe der Objekte an den virtuellen Objektpool durch die Task.
Da der Task nur zwei Objekte zugeteilt wurden, müssen auch nur diese zwei Objekte
zurckgegeben werden. Sind alle Objekte wieder dem Objektpool zurückgegeben, kann der
Objektpool selber gelöscht werden. Alle seine Objekte inklusive des Objekts für den Pool
selber werden dem Betriebssystem-Pool PXOpoolSystemdefault wieder zurückgegeben. Hier
in dem Beispiel wird nur der virtuelle Objektpool wieder gelöscht und der zu Beginn
angelegte reale Objektpool bleibt weiterhin bestehen. Nach dem Löschen des virtuellen
Objektpools enthöht der reale Pool wieder 5 Objekte.
In der Regel werden bei der Initialisierung eines Systems alle benötigten Objektpools
angelegt und erst wieder bei einem Shutdown des Systems gelöscht.

8.3 Spezielle Operationen


Objekten können mit dem Befehl PxObjSetName Namen zugewiesen werden. Diese Namen
identifizieren aber nicht das Objekt, sondern dienen lediglich zum einfacheren Debug-
gen und bieten damit dem Programmierer eine größere Transparenz. Mit dem Befehl
PxObjGetName kann der Name in eine Variable kopiert und auf einer Debug-Schnittstelle
ausgegeben werden. Die Namen Memclass und Syspool werden schon vom Betriebssystem
verwendet.

Hinweis:
Die Vergabe von Namen ist auch für das Analysieren mit pxmon sinn-
voll.

Der Typ eines Objektpools kann mit dem Befehl PxOpoolGetType ermittelt werden. Damit
ist es möglich zu erkennen, ob ein Objektpool virtuell ist und evtl. längeres Warten mit
einkalkuliert werden muss, oder ob es sich um einen realen Objektpool handelt.

34 HighTec EDV-Systeme GmbH


Quickstart V1.0 8.3 Spezielle Operationen

PxOpoolRequest(&realpool,5)

PxOpoolRequest(&virtpool,2)
Anlegen der
Objektpools

PxDelayRequest_NoWait(virtpool)

PxDelayRequest_NoWait(virtpool)

PxDelayRequest_NoWait(virtpool) Anfordern von Objekten


aus dem virtuellen Pool

PxDelayRelease

PxDelayRelease
Freigeben der
Objekte

PxOpoolRelease(virtpool)

Freigeben des
Objektpools

Abbildung 8.2: Ablauf der Objektbenutzung

HighTec EDV-Systeme GmbH 35


8 Weitere Möglichkeiten der Objektverwaltung Quickstart V1.0

Ein weiterer nützlicher Befehl ist PxOpoolGetCurrentCapacity. Mit diesem kann man die
Anzahl der aktuell in einem Objektpool enthaltener Objekte ermitteln.
Diese Objektverwaltung gestattet es, während der Laufzeit weitere Objekte zu erzeu-
gen und einem Objektpool hinzuzufügen. Sinnvoll ist dies z.B. bei der Erweiterung des
Speichers des Systems zur Laufzeit durch beispielsweise Speicherkarten. Mit dem Befehl
PxOpoolInsertNewObj kann man freien Speicher in Standard-Objekte umwandelt, die wie-
derum eine beliebige Ausprägung bei der Anforderung erhalten können. Der Vorrat des
entsprechenden Objektpools kann so also zur Laufzeit erhöht werden. Wie viel Speicher
pro Objekt benötigt wird hängt vom verwendeten Prozessor und der Länge des Objekt-
namens ab. Die Mindestgröße kann mit dem Befehl PxGetObjSize ermittelt werden.

36 HighTec EDV-Systeme GmbH


HighTec EDV-Systeme GmbH HighTec EDV-Systeme GmbH
Stammsitz & Entwicklung Niederlassung Leonberg
Feldmannstraße 98 Heidenheimer Straße 14
D-66119 Saarbrücken D-71229 Leonberg
Tel.: 0681/92613-16 Fax: -26 Tel.: 07152/35413-0 Fax: -77
mailto:htc@hightec-rt.com mailto:info@hightec-rt.com
www.hightec-rt.com