Hardwareunterstützte, zeittransparente Behandlung von Unterbrechungen in einem Echtzeitbetriebssystem auf dem TriCore TC1796

Größe: px
Ab Seite anzeigen:

Download "Hardwareunterstützte, zeittransparente Behandlung von Unterbrechungen in einem Echtzeitbetriebssystem auf dem TriCore TC1796"

Transkript

1 Hardwareunterstützte, zeittransparente Behandlung von Unterbrechungen in einem Echtzeitbetriebssystem auf dem TriCore TC1796 Diplomarbeit im Fach Informatik vorgelegt von Rudi Pfister geb in Bamberg angefertigt am Department Informatik Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Betreuer: Prof. Dr. Wolfgang Schröder-Preikschat Dipl.-Inf. Fabian Scheler Dipl.-Inf. Daniel Lohmann Dipl.-Inf. Wanja Hofer Beginn der Arbeit: Abgabe der Arbeit:

2 2 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Erlangen, den,

3 Kurzfassung In vielen Echtzeitbetriebssystemen findet eine Zweiteilung des Prioritätenraums statt. Zum einen gibt es die Prioritäten der Programmfäden, die von der Software verwaltet werden. Zum anderen gibt es die Unterbrechungen, die von der Hardware verwaltet werden und deren Prioritäten grundsätzlich höher sind als die der Programmfäden. Das kann dazu führen, dass Programmfäden von Unterbrechungsbehandlungen verdrängt werden, deren zugeordnetes Ereignis eine niedrigere Priorität hat als der Programmfaden. Dieses Phänomen ist als Rate Monotonic Priority Inversion bekannt. Die Antwortzeit des Fadens verlängert sich und es kann passieren, dass der Faden seinen Termin nicht einhalten kann. In dieser Arbeit wird nun eine Art der Unterbrechungsbehandlung vorgestellt und evaluiert, die das Phänomen der Rate Monotonic Priority Inversion verhindert. Dies wird dadurch erreicht, dass die eintreffenden Unterbrechungen von einem Coprozessor entgegengenommen werden und somit die CPU nicht mehr unterbrochen wird. Der Coprozessor aktiviert den Faden der Ereignisbehandlung, der dann vom Ablaufplaner entsprechend seiner Priorität eingeplant und zur Ausführung gebracht wird. Abstract In many real-time operating systems priority space is separated. On one hand there are the priorities of the threads, which are scheduled by software. On the other hand there are interrupts which are managed by hardware and basically have a higher priority than threads. This may cause that threads could be displaced by interrupt handlings which are assigned to events with lower priority than the thread. This phenomenon is known as Rate Monotonic Priority Inversion. The response time of the thread is elongated and this may cause that the thread could not keep its deadline. This work presents and evaluates a way of handling interrupts which prevents Rate Monotonic Priority Inversion. To achieve this, incoming interrupts are handled by a coprocessor and therefore the CPU will no longer be interrupted. The coprocessor activates the thread for event handling. Then this thread will be scheduled and executed according its priority.

4 4

5 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Übersicht Problemanalyse Klassische Unterbrechungsbehandlung Verzögerte Ereignisbehandlung Zeittransparente Ereignisbehandlung Zusammenfassung Anforderungen Definition Zusammenfassung TriCore TC Allgemeines Speichermodell Unterbrechungsbehandlung Service Request Nodes Service Provider Peripheral Control Processor Allgemein Unterbrechungsbehandlung des PCP Instruktionssatz PCP-Programme Zusammenfassung CiAO Überblick Aufbau Konfiguration AUTOSAR-Implementierung Programmfäden und Ablaufplanung Unterbrechungsbehandlung Asynchronous System Trap (AST) Zusammenfassung

6 6 INHALTSVERZEICHNIS 6 Entwurf Erzeugen von Unterbrechungen Behandlung der Unterbrechungen Channel Restart und Channel Resume Unterbrechung von PCP-Programmen Ereignisbehandlung Fadenzustand Adressierung der Verwaltungsdatenstrukturen Aufbau der Verwaltungsdatenstrukturen Synchronisation Systemzustand Signalisierung Zusammenfassung Implementierung Einschränkungen Prinzip der losen Kopplung Datentypen Symbole Speicherzugriffe des PCP Aspekte und Templates Umsetzung Erzeugen von Unterbrechungen Behandlung der Unterbrechungen Ereignisbehandlung Fadenzustand Systemzustand Signalisierung Zusammenfassung Evaluation Testumgebung Erzeugen von Unterbrechungen Faden- und Funktionsaktivierungen Laufzeiten Test 1: Generelles Laufzeitverhalten Testszenario Ergebnisse Test 2: Antwortzeit und Jitter Testszenario Ergebnisse Test 3: Latenz Testszenario Ergebnisse Test 4: Geschachtelte Unterbrechungen Testszenario Ergebnisse Test 5: Überlast

7 INHALTSVERZEICHNIS Testszenario Ergebnisse Bewertung Zusammenfassung Zusammenfassung 75

8 8 INHALTSVERZEICHNIS

9 Kapitel 1 Einleitung 1.1 Motivation In ereignisgesteuerten Systemen wird das Zusammenspiel der einzelnen Komponenten durch Ereignisse gesteuert. Ereignisse können sowohl von außen kommen als auch vom System selbst ausgelöst werden. Das Eintreffen von Ereignissen wird z.b. durch Unterbrechungen signalisiert. Die eintreffenden Ereignisse stoßen eine Ereignisbehandlung an. Die Behandlung der Ereignisse erfolgt in der Regel durch Programmfäden oder Unterbrechungsbehandlungsroutinen. In ereignisgesteuerten Systemen mit statischen Prioritäten wird jeder Ereignisbehandlung eine feste Priorität zugeordnet. In vielen Echtzeitbetriebssystemen gibt es aber eine Zweiteilung des Prioritätenraums. Zum einen die Prioritäten der Fäden, die von der Anwendung gesetzt werden, sie werden vom Betriebssystem verwaltet und der Ablaufplaner entscheidet darüber, welcher Faden als nächstes zur Ausführung gebracht wird. Zum anderen die Prioritäten der Unterbrechungen. Die Unterbrechungen werden von der Hardware verwaltet und haben grundsätzlich eine höhere Priorität als alle Fäden. Ziel der Trennung des Prioritätenraumes ist es, eine möglichst geringe Unterbrechungslatenz zu erreichen. Diese Trennung führt jedoch dazu, dass beim Eintreffen einer Unterbrechung der laufende Faden immer verdrängt wird, was in Echtzeitsystemen zu Problemen führen kann. So kann es vorkommen, dass eine Unterbrechungsbehandlung, die eigentlich einem niederprioren Ereignis zugeordnet ist, einen Faden verzögert, der eine hochpriore Aufgabe bearbeitet. Dieses Phänomen wird als Rate Monotonic Priority Inversion bezeichnet und kann dazu führen, dass zeitkritische Aufgaben ihre Termine nicht mehr einhalten können. Als Beispiel soll hier ein System betrachtet werden, dass einen beliebigen Regelungsprozess abarbeitet. Die Regelungsaufgabe muss von einem Echtzeitfaden erledigt werden, da für die Stellung der Prozessparameter zeitliche Vorgaben einzuhalten sind. Der Begriff Echtzeitfaden bezeichnet einen Faden an den Echtzeitanforderungen gestellt werden, d.h. er hat einen Termin einzuhalten. In diesem System sollen jetzt noch die Prozessgrößen über eine Kommunikationsschnittstelle an eine Leitstelle gemeldet werden. Die Übertragung der Daten hat keine hohe Priorität und ist auch nicht zeitkritisch, deshalb wird dies von weiteren, im System laufenden Fäden erledigt an die keine Echtzeitanforderungen gestellt werden. Die Übertragung der Datenpakete wird mit einer Acknowledge- oder Fehlermeldung quittiert. Das Eintreffen dieser Meldungen wird dem System in Form von Unter-

10 Übersicht brechungen mitgeteilt. Obwohl diese Meldungen selbst nur sehr niederprior sind, haben die Unterbrechungen aufgrund der Zweiteilung des Prioritätenraums eine höhere Priorität als der Echtzeitfaden, der für die Regelung des Prozesses zuständig ist. Der Echtzeitfaden kann unterbrochen und verzögert werden und das Phänomen der Rate Monotonic Priority Inversion tritt auf. 1.2 Zielsetzung In [1] wird eine Möglichkeit vorgestellt, diese Verzögerungen zu minimieren. Dies wird dadurch erreicht, dass beim Eintreffen einer Unterbrechung keine Unterbrechungsbehandlung mehr gestartet wird, sondern nur noch ein Semaphor gesetzt wird, welcher anzeigt, dass eine Unterbrechung eingetroffen ist. Die Behandlung erfolgt erst dann, wenn der hochpriore Faden seine Aufgabe beendet hat. Diese Methode führt jedoch nach wie vor zu kleinen Verzögerungen von höherprioren Fäden (siehe Abschnitt 2.2). In dieser Arbeit wird eine Möglichkeit vorgestellt wie diese Verzögerungen komplett vermieden werden können. Dies wird dadurch erreicht, dass die Unterbrechungen von einem Coprozessor entgegengenommen werden. Der Hauptprozessor soll nur dann unterbrochen werden, wenn die Priorität der Ereignisbehandlung, die der eingetroffenen Unterbrechung zugeordnet ist, höher ist als die des aktuell laufenden Fadens. Ansonsten wird das Ereignis erst nach Beendigung des hochprioren Fadens bearbeitet. 1.3 Übersicht Diese Arbeit beschreibt die Entwicklung und Umsetzung einer Ereignisbehandlung ohne unnötige Unterbrechungen von höherprioren Fäden auf dem TC1796 auf Basis des CiAO- Betriebssystems. Sie gliedert sich in folgende Abschnitte: Kapitel 2 analysiert die Probleme, welche durch die Zweiteilung des Prioritätenraums auftreten können. Nach dieser Problemanalyse wird die Lösung aus [1] vorgestellt und die Grundidee der in dieser Arbeit umgesetzten Lösung dargelegt. Kapitel 3 definiert die an ein System gestellten Anforderungen, in dem eine Behandlung von Ereignissen möglich sein soll, ohne dass der gerade auf der CPU laufende Faden unnötigerweise unterbrochen wird. Kapitel 4 gibt eine Übersicht über die für diese Arbeit relevanten Architektureigenschaften und Hardwarekomponenten des TriCore TC1796. Kapitel 5 stellt das CiAO-Betriebssystem vor und geht besonders auf die in dieser Arbeit verwendete AUTOSAR-Implementierung ein. Kapitel 6 erstellt, basierend auf der Analyse des TC1796 und der Untersuchung von CiAO, einen konzeptionellen Entwurf für die Umsetzung der Behandlung von Ereignissen ohne unnötige Unterbrechungen des laufenden Fadens. Kapitel 7 beschreibt die Implementierung des fertigen Konzepts auf dem TC1796 im Rahmen des CiAO-Betriebssystems.

11 1.3 Übersicht 11 Kapitel 8 evaluiert die implementierte Lösung. Anhand dieser Evaluation werden die klassische Variante der Unterbrechungsbehandlung, die in [1] vorgestellte und die in dieser Arbeit entwickelte Variante miteinander verglichen. Kapitel 9 gibt einen abschließenden Überblick über die in dieser Arbeit durchgeführten Schritte und die gewonnen Ergebnisse.

12 Übersicht

13 Kapitel 2 Problemanalyse Viele Betriebssysteme nutzen das von der Hardware zur Verfügung gestellte Unterbrechungssystem. Unterbrechungen zeigen das Eintreffen von Ereignissen oder die Änderung von Zuständen an. Das Ermöglichen von Unterbrechungen bringt aber auch einige Probleme mit sich. Die Programmfäden können jederzeit unterbrochen werden, deshalb sind Schutz- und Synchronisationsmechanismen nötig. Auch die bereits erwähnte Zweiteilung des Prioritätenraumes sorgt für Probleme. Dieses Kapitel erläutert die Probleme, die in Echtzeitbetriebssystemen durch die Zweiteilung des Prioritätenraums bei der klassischen Unterbrechungsbehandlung auftreten können und stellt die in [1] diskutierte Lösung vor. Anschließend werden die Grundideen der in dieser Arbeit behandelten Lösung dargelegt. 2.1 Klassische Unterbrechungsbehandlung Läuft auf der CPU ein hochpriorer Faden mit Echtzeitanforderungen und trifft eine Unterbrechung ein, die einem niederprioren Ereignis zugeordnet ist, so wird der hochpriore Faden aufgrund der Trennung des Prioritätenraums unterbrochen und von der niederprioren Ereignisbehandlung verdrängt. Diese Rate Monotonic Priority Inversion führt dazu, dass die Ausführung des Echtzeitfadens verzögert wird und sich seine Antwortzeit verlängert. Die Verzögerungen können dazu führen, dass der Echtzeitfaden seine Termine nicht einhalten kann. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.1: Eintreffende Ereignisse unterbrechen den Echtzeitfaden und verzögern diesen

14 Zeittransparente Ereignisbehandlung 2.2 Verzögerte Ereignisbehandlung Eine Möglichkeit die Verzögerungen des hochprioren Fadens zu reduzieren ist die Ereignisbehandlung nicht mehr sofort durchzuführen, sondern sich nur zu merken, dass eine Unterbrechung eingetroffen ist. Die Ereignisbehandlung wird dann erst nach Beendigung des hochprioren Fadens gestartet. Das Merken, dass eine Unterbrechung eingetroffen ist, könnte z.b. durch einen Semaphor geschehen, der gesetzt wird und auf den der Faden der Ereignisbehandlung wartet. Die Priorität der Ereignisbehandlung würde im Prioritätenraum der Anwendung liegen und der Faden würde entsprechend seiner Priorität vom Ablaufplaner zur Ausführung gebracht werden. Der Echtzeitfaden würde nur noch kurz von der Unterbrechungsbehandlungsroutine verdrängt werden, die den Semaphor setzt. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.2: Wenn die Ereignisbehandlung nicht mehr sofort durchgeführt wird, gibt es nur noch kurze Unterbrechungen des Echtzeitfadens 2.3 Zeittransparente Ereignisbehandlung Beim Einsatz von Systemen, welche es ermöglichen Fäden zu aktivieren ohne die CPU zu unterbrechen, lassen sich die Unterbrechungen des Echtzeitfadens komplett vermeiden. Dies wäre zum Beispiel der Fall, wenn das System über einen Coprozessor oder ein ähnliches Gerät verfügt, dass zur Behandlung von Unterbrechungen geeignet ist. In einem System mit einem Coprozessor nimmt dieser die eintreffende Unterbrechung entgegen und aktiviert den Faden der zur Unterbrechung gehörenden Ereignisbehandlung. Hat der gerade auf der CPU ausgeführte Faden eine niedrigere Priorität als die Ereignisbehandlung unterbricht der Coprozessor die CPU und stößt eine Neueinplanung der Fäden auf der CPU an. Echtzeitfaden Ereignisbehandlung Idle Abbildung 2.3: Wenn die Ereignisbehandlung ohne Unterbrechung der CPU aktiviert werden kann, gibt es keine Unterbrechungen des Echtzeitfadens mehr

15 2.4 Zusammenfassung Zusammenfassung In diesem Kapitel wurde festgestellt, dass die klassische Art der Unterbrechungsbehandlung in ereignisgesteuerten Echtzeitbetriebssystemen zu Verzögerungen bei der Ausführung von Programmfäden führen kann. Die Ursachen hierfür wurden erläutert und anschließend wurden zwei Lösungen aufgezeigt. Einerseits eine Möglichkeit welche die Unterbrechungen der Echtzeitfäden zwar nicht verhindern, aber doch deutlich reduzieren kann und andererseits die Möglichkeit, bei der es durch Hardwareunterstützung zu keinen Unterbrechungen des Echtzeitfadens mehr kommt.

16 Zusammenfassung

17 Kapitel 3 Anforderungen Im vorherigen Kapitel wurde gezeigt, dass die klassische Unterbrechungsbehandlung in ereignisgesteuerten Echtzeitsystemen zu Problemen führen kann. Zur Lösung dieser Probleme wurde eine Variante der Unterbrechungsbehandlung vorgestellt, bei der die eintreffenden Ereignisse den gerade laufenden Faden nicht mehr unnötig unterbrechen können. Ihre Umsetzung stellt jedoch gewisse Anforderungen an die Hardware und Software des Systems. In diesem Kapitel werden nun diese Anforderungen definiert und erläutert. 3.1 Definition Die folgenden Anforderungen muss ein System erfüllen, um die vorgestellte Art der Unterbrechungsbehandlung umzusetzen, bei der die auf der CPU laufenden Fäden nicht unnötigerweise unterbrochen werden. (A1) Hardware Das System muss einen Coprozessor oder ein ähnliches Gerät besitzen. (A2) Erzeugen von Unterbrechungen Die Geräte, welche Unterbrechungen erzeugen können, müssen in der Lage sein, die von ihnen generierten Unterbrechungen an den Coprozessor zu leiten. (A3) Behandlung der Unterbrechungen Der Coprozessor muss die eintreffenden Unterbrechungen entgegen nehmen und quittieren können. Dabei ist auch der Fall zu berücksichtigen, dass der Coprozessor verschachtelte Unterbrechungen bearbeiten muss. (A4) Ereignisbehandlung Die Anwendung muss eine Möglichkeit besitzen, einem eintreffenden Ereignis einen Faden zuzuordnen, der dessen Behandlung übernehmen soll. (A5) Fadenzustand Um den Faden der Ereignisbehandlung zu aktivieren, muss der Coprozessor in der Lage sein, die Verwaltungsdatenstrukturen des Fadens und des Ablaufplaners im Betriebssystemkern zu manipulieren. Deswegen ist es nötig, dass (A5a) bekannt ist, wo sich diese Strukturen im Speicher befinden, (A5b) bekannt ist, wie diese aufgebaut sind und (A5c) der Zugriff von CPU und Coprozessor auf diese Verwaltungsdatenstrukturen synchronisiert ist.

18 Zusammenfassung (A6) Systemzustand Der Coprozessor muss entscheiden können, ob der gerade aktivierte Faden sofort eingelastet werden muss. Dazu muss er die Priorität des momentan auf der CPU laufenden Fadens kennen, um diese mit der Priorität des gerade aktivierten Fadens zu vergleichen. So kann er entscheiden, ob eine Neueinplanung der Programmfäden auf der CPU nötig ist. (A7) Signalisierung Für denn Fall, dass der gerade aktivierte Faden sofort eingelastet werden soll muss der Coprozessor eine Möglichkeit besitzen die CPU zu unterbrechen, um eine Neueinplanung der laufbereiten Programmfäden anzustoßen. 3.2 Zusammenfassung In diesem Kapitel wurden die Anforderungen für die Ereignisbehandlung ohne unnötige Unterbrechungen des auf der CPU laufenden Fadens definiert. In den beiden folgenden Kapiteln werden jetzt der TC1796 und CiAO darauf hin untersucht, ob sie geeignet sind diese Anforderungen zu erfüllen.

19 Kapitel 4 TriCore TC1796 Der TC1796 [2] ist ein Derivat des TriCore-Prozessorkerns [4] von Infineon. Bei ihm handelt es sich um einen 32-Bit-RISC-Prozessor, der auch DSP-Funktionalität zur Verfügung stellt. Die Architektur des TriCore ist umfangreich und der TC1796 bietet ein breites Spektrum an Peripheriegeräten. Aus diesem Grund wird in diesem Kapitel nur auf die Architektureigenschaften bzw. Peripheriegeräte eingegangen, die für diese Arbeit relevant sind. Es wird ein allgemeiner Überblick über den TC1796 und seine Unterbrechungsbehandlung gegeben und dann der für diese Arbeit zentrale Peripheral Control Processor (PCP) des TriCore beschrieben. 4.1 Allgemeines Der Registersatz des TriCore besteht aus 32 Allgemeinzweckregistern und einigen Registern mit speziellen Funktionen, zum Beispiel dem Programmzähler und dem Statusregister. Die Breite der Register beträgt 32-Bit. Beim TriCore handelt es sich um eine Load/Store-Architektur, weswegen die meisten Befehle nur mit Registern arbeiten, sowie spezielle Befehle zum Laden und Speichern von Daten bzw. Adressen vorhanden sind. Ein Großteil der Maschinenbefehle arbeitet nur mit speziellen Datentypen von denen die TriCore-Architektur eine Vielzahl unterstützt, z.b. Boolean, Byte, Integer und Fest- und Fließkommazahlen. Der TriCore hat einen extra Datentyp für Adressen, so dass zwischen Adress- und Datenoperationen unterschieden werden muss. Die Maschinenbefehle des TriCore sind 32-Bit lang, es gibt jedoch auch eine Vielzahl von 16-Bit-Befehlen, um die Länge des Programmcodes zu minimieren. 16- und 32-Bit-Befehle können beliebig gemischt werden. Eine weitere Besonderheit der TriCore-Architektur ist die hardwareunterstützte Sicherung des Programmkontextes bei Funktionsaufrufen, sowie bei Unterbrechungs- und Ausnahmebehandlungen, welche zur Implementierung von Programmfäden verwendet werden kann. Dabei wird ein Teil der Register des TriCore automatisch von der Hardware gesichert. Die Sicherung der restlichen Register kann durch einen Maschinenbefehl erfolgen. Die Sicherung der Register geschieht in so genannten Context Save Areas (CSAs). Bei den CSAs handelt es sich 64 Byte große Bereiche im Speicher des TC1796. Sie werden von der

20 Unterbrechungsbehandlung Hardware in Form von verketteten Listen verwaltet. Ihre Initialisierung muss jedoch von der Anwendung beim Systemstart noch vor dem ersten Funktionsaufruf durchgeführt werden. 4.2 Speichermodell Die Architektur des TriCore unterstützt, aufgrund der Adressbreite von 32 Bit, einen Adressraum von bis zu 4 GByte. Der Adressraum ist flach und die Register der Ein- und Ausgabe-Geräte werden in den Speicher eingeblendet. Der interne Speicher des TC1796 ist in Programm- und Datenspeicher unterteilt und besteht sowohl aus SRAM-, wie auch aus Flash-Speichern. Außerdem verfügen Systeme in welchen der TC1796 eingesetzt wird, meist noch über externe Programm- und Datenspeicher, auf welche der TC1796 über die External Bus Unit (EBU) zugreift. So verfügt z.b. das TriBoard von Infineon [8] über 2 MByte externes SRAM. 4.3 Unterbrechungsbehandlung Das Unterbrechungsbehandlungssystem des TriCore gliedert sich in zwei Teile (s. Abbildung 4.1). Zum einen gibt es die Service Request Nodes (SRNs). Sie sind Geräten zugeordnet und können Unterbrechungen erzeugen. Zum anderen die Service Provider, die Unterbrechungen entgegennehmen und behandeln können Service Request Nodes Beim TriCore sind die Prioritäten der von den Geräten erzeugten Unterbrechungen nicht fest vorgegeben, sondern können frei konfiguriert werden. Jedes Gerät, das Unterbrechungen erzeugen kann, besitzt mindestens eine Service Request Node. In ihr wird die Priorität der vom Gerät erzeugten Unterbrechung festgelegt. Auch kann eingestellt werden, an welchen Service Provider die Unterbrechung geleitet wird (A2) Service Provider Service Provider können Unterbrechungen entgegennehmen und diese bearbeiten. Als Service Provider kann die CPU oder der Peripheral Control Processor fungieren. Die Service Provider besitzen jeweils eine Interrupt Control Unit (ICU), die über das Interrupt Control Register (ICR) konfiguriert wird. Ein Flag in diesem Register aktiviert oder deaktiviert die Unterbrechungsbehandlung für diesen Provider. Im ICR ist zusätzlich die höchste Priorität der noch zu bearbeitenden Unterbrechungen und die Prioritätsebene auf der sich der Provider gerade befindet hinterlegt. Es werden nur Unterbrechungen bearbeitet, die eine höhere Priorität als die aktuelle Prioritätsebene des Providers haben. Abbildung 4.2 zeigt den schematischen Ablauf der Unterbrechungsbehandlung des Tri- Core. Die Entscheidung, welche der aufgetretenen Unterbrechungen die höchste Priorität besitzt, trifft die Hardware in der so genannten Arbitrierungsrunde. Diese Arbitrierungsrunde besteht aus mehreren Zyklen. Wie viele Zyklen bei der Arbitrierung durchlaufen

21 4.3 Unterbrechungsbehandlung 21 Abbildung 4.1: Blockdiagramm des Unterbrechungssystems (vgl. [4, Kapitel 5.1]) werden sollen ist konfigurierbar. Eine Reduzierung der Zyklenzahl sorgt für eine schnellere Ermittlung der höchsten anstehenden Unterbrechung, jedoch wird dadurch die Anzahl der Prioritätsebenen eingeschränkt. Die Priorität der höchstprioren Unterbrechung wird im ICR hinterlegt. Wenn deren Priorität höher ist, als die des Providers, beginnt dieser mit der Bearbeitung der Unterbrechung. Hierzu sperrt er Unterbrechungen generell und hebt seine Prioritätsebene auf die der zu bearbeitenden Unterbrechung an. Der vom Provider ausgeführte Programmfaden wird unterbrochen und die Ausführung der Unterbrechungsbehandlungsroutine beginnt im entsprechenden Eintrag der Interrupt Vector Table. Nach der Bearbeitung der Unterbrechung wird die Unterbrechungsbehandlung des Providers wieder aktiviert und die Prioritätsebene wieder auf den vorherigen Wert zurückgesetzt. Die Unterbrechungsbehandlung des Providers kann auch vor Beendigung der gerade laufenden Unterbrechungsbehandlung wieder aktiviert werden, um zu ermöglichen, dass niederpriore Unterbrechungen von höherprioren Unterbrechungen unterbrochen werden können.

22 Peripheral Control Processor Eintreffende Unterbrechungen Arbitrierungsrunde zur Auswahl der höchstprioren Unterbrechung Prüfung der aktuellen Priorität des Providers Weiterleiten der höchstprioren Unterbrechung zum Provider Hardware Unterbrechung des aktuellen Programmfadens Wenn Priorität des Providers kleiner als Priorität der Unterbrechung Fortsetzen des unterbrochenen Programmfadens Auslösen der Unterbrechung: Sperren der Unterbrechungen Anheben des Prioritätslevels Freigeben der Unterbrechungen Rücksetzen des Prioritätslevels Sprung zur Interrupt Vector Table Ausführen der Unterbrechungsbehandlungsroutine Beendigung der Unterbrechungsbehandlung Software Abbildung 4.2: Schematischer Ablauf der Unterbrechungsbehandlung des TriCore 4.4 Peripheral Control Processor Allgemein Der Peripheral Control Processor (PCP) des TriCore (A1) ist für die Behandlung von Unterbrechungen und für das Abwickeln von DMA-Operationen ausgelegt. Er hat einen eigenen Instruktionssatz, eigenen Programm- und Datenspeicher und vollen Zugriff auf die Geräte des Systems. Eine seiner Besonderheiten ist, dass er sich normalerweise im Ruhemodus befindet. Trifft eine Unterbrechung ein, führt er das ihr zugeordnete Programm aus und geht nach dem Beenden seiner Operationen wieder in den Ruhemodus. Er muss nicht wie andere Prozessoren eine Leerlaufschleife ausführen oder per Maschinenbefehl in den Ruhemodus geschickt werden. Abbildung 4.3 zeigt ein Blockdiagramm des PCP. Es stellt den Prozessorkern, den Speicher (s. Abschnitt ) und das Unterbrechungssystem (s. Abschnitt 4.4.2) dar Registersatz Der PCP hat acht 32-Bit Register. Abgesehen von einem können sie alle als Allgemeinzweckregister (GPR) verwendet werden, aber auch die restlichen Register haben für manche Operationen fest vorgegebene Aufgaben (SPR). Tabelle 4.1 zeigt die Register des PCP und ihre besonderen Aufgaben Speicher Der PCP hat einen getrennten Programm- und Datenspeicher.

23 4.4 Peripheral Control Processor 23 Abbildung 4.3: Blockdiagramm des PCP (vgl. [2, Kapitel 11.2]) Register Typ Beschreibung R0 GPR/SPR Ziel für einige arithmetische und logische Operationen R1 GPR - R2 GPR/SPR Rücksprungadresse R3 GPR - R4 GPR/SPR Quelladresse für COPY-Operation R5 GPR/SPR Zieladresse für COPY-Operation R6 GPR/SPR CNT1: Transfer-Zähler für COPY TOS: Type-of-Service SRPN: Unterbrechungspriorität bei EXIT CPPN: Aktuelle Priorität R7 SPR PRAM-Datenzeiger (DPTR) und Statusflags Tabelle 4.1: Register des PCP Programmspeicher Im Programmspeicher (CMEM) des PCP liegen die einzelnen PCP-Programme (s. Abschnitt ). Der PCP adressiert den Programmspeicher halbwortweise, da die meisten Maschinenbefehle des PCP 16-Bit breit sind. Der Zugriff auf den Programmspeicher des PCP über das Flexible Peripheral Interface (FPI), wie er z.b. durch die CPU geschieht, erfolgt hingegen wortweise.

24 Peripheral Control Processor Datenspeicher Der Datenspeicher (PMEM) des PCP dient zum Ablegen der Kontexte (s. Abschnitt ) der einzelnen PCP-Programme und zum Speichern von globalen Daten. Der PCP greift über den 8-Bit Datenzeiger (DPTR) in Register R7 und einen 6-Bit Offset auf den globalen Datenspeicher zu. Sowohl der Zugriff durch den PCP, als auch Zugriffe über den FPI-Bus erfolgen wortweise. Allerdings ist zu beachten, dass die Adressierung über den FPI-Bus byteweise, die Adressierung durch den PCP jedoch wortweise erfolgt. Speicher des Systems Der PCP hat auch Zugriff auf den Speicher des Hauptprozessors und anderer Geräte (A5). Dieser Zugriff erfolgt über den FPI-Bus. Die Adressen, mit denen der PCP auf diese Speicher zugreift, unterscheiden sich im Allgemeinen von denen, die für Zugriffe durch die CPU verwendet werden Unterbrechungsbehandlung des PCP Wie auch das Unterbrechungssystem des TriCore besteht das Unterbrechungssystem des PCP im Wesentlichen aus zwei Teilen. Zum einen aus der Interrupt Control Unit (PI- CU) und zum anderen aus den Service Request Nodes (PSRN). Abbildung 4.4 zeigt die Verschaltung der Interrupt Control Unit und der Service Request Nodes mit dem Prozessorkern und die Busse, die zum Zustellen der Unterbrechungen dienen PCP Interrupt Control Unit Die PICU verwaltet die Unterbrechungen, die an den PCP geschickt wurden. Die PICU wählt in einer so genannten Arbitrierungsrunde die momentan höchstpriore Unterbrechung aus und leitet diese an den PCP weiter. Die Dauer einer Arbitrierungsrunde kann konfiguriert werden, allerdings hat eine kürzere Arbitrierungsrunde zur Folge, dass weniger nutzbare Prioritätsstufen zur Verfügung stehen. Die Unterbrechungsanfrage wird von der Hardware automatisch zurückgesetzt, wenn die Unterbrechungsbehandlung beginnt (A3) Service Request Nodes des PCP Der PCP hat zwölf PSRNs mit denen er Unterbrechungen an die CPU (A7) oder sich selbst schicken kann. Von diesen zwölf PSRNs können zwei ihre Unterbrechungen nur an die CPU leiten und fünf nur an den PCP, bei den restlichen kann der PCP ihr Ziel konfigurieren. Die PSRNs unterliegen der Kontrolle durch den PCP, d.h. sie können, im Gegensatz zu den SRNs anderer Geräte, nicht durch die Anwendung gesteuert werden. Die PCP-Programme können nur beim Ausführen einer Exit-Instruktion eine Unterbrechung erzeugen. Welche Priorität die dabei erzeugte Unterbrechung hat und ob diese für die CPU oder für den PCP bestimmt ist, kann im Register R6 konfiguriert werden.

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme Wilhelm Haas Wilhelm.Haas@informatik.stud.uni-erlangen.de Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl 4

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

LavA OS: Ein Betriebssystem für konfigurierbare MPSoCs

LavA OS: Ein Betriebssystem für konfigurierbare MPSoCs LavA OS: Ein Betriebssystem für konfigurierbare MPSoCs Diplomarbeit Abschlussvortrag Stephan Vogt stephan.vogt@cs.uni-dortmund.de 1 Inhalt Einleitung Wiederverwendung von BS Arbeiten an CiAO Kommunikation

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

Simple Scope. ecos-vertiefung. Florian Franzmann Tobias Klaus Peter Wägemann

Simple Scope. ecos-vertiefung. Florian Franzmann Tobias Klaus Peter Wägemann Simple Scope ecos-vertiefung Florian Franzmann Tobias Klaus Peter Wägemann Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme und Betriebssysteme) http://www4.cs.fau.de

Mehr

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab OSEK-OS Oliver Botschkowski oliver.botschkowski@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung Motivation Ziele Vorteile Einführung in OSEK-OS Architektur Task Management Interrupt

Mehr

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller

Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching. Rainer Müller Slothful Linux: An Efficient Hybrid Real-Time System by Hardware-Based Task Dispatching Rainer Müller 21. November 2013 Spezialisierung von Betriebssystemen Vielzweckbetriebssysteme (General Purpose OS,

Mehr

Architektur Verteilter Systeme Teil 2: Prozesse und Threads

Architektur Verteilter Systeme Teil 2: Prozesse und Threads Architektur Verteilter Systeme Teil 2: Prozesse und Threads 21.10.15 1 Übersicht Prozess Thread Scheduler Time Sharing 2 Begriff Prozess und Thread I Prozess = Sequentiell ablaufendes Programm Thread =

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH ARM Cortex-M Prozessoren Referat von Peter Voser Embedded Development GmbH SoC (System-on-Chip) www.embedded-development.ch 2 Instruction Sets ARM, Thumb, Thumb-2 32-bit ARM - verbesserte Rechenleistung

Mehr

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System

Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Design and Implementation of a Soft-error Resilient OSEK Real-time Operating System Florian Lukas Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich Alexander Universität Erlangen

Mehr

Operating System Kernels

Operating System Kernels Operating System Kernels von Patrick Bitterling 1 Themenübersicht -Eine Einleitung über Kernel -Begriffserklärung, Architekturen -Kernel Subsysteme -Prozess-Scheduling, Speichermanagement,... -Der Networking

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Der Scheduler von Windows Konzepte und Strategien

Der Scheduler von Windows Konzepte und Strategien Gliederung Der Scheduler von Windows Konzepte und Strategien Daniel Lohmann 1 Grundbegriffe 2 Eigenschaften des Schedulers Grundlegende Eigenschaften Prioritätenmodell Dynamische Prioritätenanpassungen

Mehr

b) Gegeben sei folgende Enumeration: enum SPRACHE {Deutsch, Englisch, Russisch};

b) Gegeben sei folgende Enumeration: enum SPRACHE {Deutsch, Englisch, Russisch}; Aufgabe 1: (15 Punkte) Bei den Multiple-Choice-Fragen ist jeweils nur eine richtige Antwort eindeutig anzukreuzen. Auf die richtige Antwort gibt es die angegebene Punktzahl. Wollen Sie eine Multiple-Choice-Antwort

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Domänenmodell: Fadenkommunikation und -synchronisation

Domänenmodell: Fadenkommunikation und -synchronisation Domänenmodell: Fadenkommunikation und -synchronisation Alexander Humphreys, Reinhard Rösch, Fabian Scheler 15. Mai 2003 Inhaltsverzeichnis 1 Domänendefinition 1 2 Domänenlexikon 1 3 Konzeptmodelle 4 4

Mehr

Rechnerarchitektur Atmega 32. 1 Vortrag Atmega 32. Von Urs Müller und Marion Knoth. Urs Müller Seite 1 von 7

Rechnerarchitektur Atmega 32. 1 Vortrag Atmega 32. Von Urs Müller und Marion Knoth. Urs Müller Seite 1 von 7 1 Vortrag Atmega 32 Von Urs Müller und Marion Knoth Urs Müller Seite 1 von 7 Inhaltsverzeichnis 1 Vortrag Atmega 32 1 1.1 Einleitung 3 1.1.1 Hersteller ATMEL 3 1.1.2 AVR - Mikrocontroller Familie 3 2 Übersicht

Mehr

9 Multithreading. 1 Idee des Multithreading

9 Multithreading. 1 Idee des Multithreading 9 Multithreading Jörn Loviscach Versionsstand: 21. Juli 2015, 11:50 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html This work is licensed

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger

mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger mywms Vorlage Seite 1/5 mywms Datenhaltung von Haug Bürger Grundlegendes Oracle9i PostgreSQL Prevayler Memory mywms bietet umfangreiche Konfigurationsmöglichkeiten um die Daten dauerhaft zu speichern.

Mehr

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44

Virtueller Speicher. SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Virtueller Speicher SS 2012 Grundlagen der Rechnerarchitektur Speicher 44 Die Idee Virtuelle Adressen Prozess 1 Speicherblock 0 Speicherblock 1 Speicherblock 2 Speicherblock 3 Speicherblock 4 Speicherblock

Mehr

Funktionskapselung in Steuergeräten

Funktionskapselung in Steuergeräten Funktionskapselung in Steuergeräten Mobilität und Echtzeit Boppard am Rhein, 07.12.2007 Stand: 07.12.2007 1 Funktionskapselung in Steuergeräten Inhalt Ausgangssituation und Motivation Begriff "Kapselung"

Mehr

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161?

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161? Was machen wir heute? Betriebssysteme Tutorium 2 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

Mehr

2. Hintergrundverarbeitung in Android: Services und Notifications

2. Hintergrundverarbeitung in Android: Services und Notifications 2. Hintergrundverarbeitung in Android: Services und Notifications Übersicht 2. Hintergrundverarbeitung in Android: Services und Notifications Übersicht: In Mobis 1: Threads; hier genauerer Blick auf Services

Mehr

Interrupts. Funktionsprinzip. Funktionsprinzip. Beispiel in C

Interrupts. Funktionsprinzip. Funktionsprinzip. Beispiel in C Interrupts Funktionsprinzip Interrupts bei ATmega128 Beispiel in C Funktionsprinzip 1 Was ist ein Interrupt? C muss auf Ereignisse reagieren können, z.b.: - jemand drückt eine Taste - USART hat Daten empfangen

Mehr

Stammdaten- Synchronisierung

Stammdaten- Synchronisierung DESK GmbH Stammdaten- Synchronisierung Zusatzmodul zur Sage Office Line Evolution ab 2011 Benjamin Busch 01.07.2011 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713 Eibelshausen Tel.: +49 (0) 2774/924

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

Die Mikroprogrammebene eines Rechners

Die Mikroprogrammebene eines Rechners Die Mikroprogrammebene eines Rechners Das Abarbeiten eines Arbeitszyklus eines einzelnen Befehls besteht selbst wieder aus verschiedenen Schritten, z.b. Befehl holen Befehl dekodieren Operanden holen etc.

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

13 OOP MIT DELPHI. Records und Klassen Ein Vergleich

13 OOP MIT DELPHI. Records und Klassen Ein Vergleich 13 OOP MIT DELPHI Delphi war früher "Object Pascal". Dieser Name impliziert eine Funktionalität, welche in der Welt der Programmierung nicht mehr wegzudenken ist: die objektorientierte Programmierung,

Mehr

Im Falle der Neueingabe müssen Sie in dem nachfolgendem Formular die Datenquelle auswählen und die Art der Prüfung festlegen.

Im Falle der Neueingabe müssen Sie in dem nachfolgendem Formular die Datenquelle auswählen und die Art der Prüfung festlegen. Ereignismanager Ereignismanager Ereignismanager - Grundsätzliches Allgemeines Mit Hilfe des Ereignismanagers können Sie Feldeingaben (bei Neueingaben oder Änderungen) überprüfen lassen. Sie können für

Mehr

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET Sicherheitskernel ÜBERSICHT SurefireKernel ist ein schlanker skalierbarer nicht preemptiver Echtzeit-Kernel der für den Einsatz auf Kontrollersysteme optimiert ist. Er verfügt über eine Realtime-Überwachung

Mehr

OSEK / OSEKtime - ein Vergleich

OSEK / OSEKtime - ein Vergleich OSEK / OSEKtime - ein Vergleich Hauptseminar WS 07/08 André Puschmann andre.puschmann@stud.tu-ilmenau.de Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Fachgebiet Rechnerarchitektur

Mehr

(Prüfungs-)Aufgaben zum Thema Scheduling

(Prüfungs-)Aufgaben zum Thema Scheduling (Prüfungs-)Aufgaben zum Thema Scheduling 1) Geben Sie die beiden wichtigsten Kriterien bei der Wahl der Größe des Quantums beim Round-Robin-Scheduling an. 2) In welchen Situationen und von welchen (Betriebssystem-)Routinen

Mehr

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Table of Contents... v 1. Einführung... 1 2. Grundlagen...

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Betriebssystembau. 7. Übung. Michael Engel Arbeitsgruppe Eingebettete Systemsoftware. Lehrstuhl für Informatik 12 TU Dortmund

Betriebssystembau. 7. Übung. Michael Engel Arbeitsgruppe Eingebettete Systemsoftware. Lehrstuhl für Informatik 12 TU Dortmund Betriebssystembau 7. Übung Michael Engel Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund michael.engel@tu-dortmund.de http://ess.cs.uni-dortmund.de/~me/ 1 Agenda Coroutinen

Mehr

Java Real-Time Specification

Java Real-Time Specification Ausgewählte Kapitel eingebetteter Systeme Java Real-Time Specification Tobias Distler 05.07.2006 Java und Echtzeit? Problem Nichtdeterministisches Verhalten der Garbage Collection Weitere Nachteile Scheduling

Mehr

Deklarationen in C. Prof. Dr. Margarita Esponda

Deklarationen in C. Prof. Dr. Margarita Esponda Deklarationen in C 1 Deklarationen Deklarationen spielen eine zentrale Rolle in der C-Programmiersprache. Deklarationen Variablen Funktionen Die Deklarationen von Variablen und Funktionen haben viele Gemeinsamkeiten.

Mehr

Ausführungszeiten. Worst-Case Execution-Time. Übung zur Vorlesung EZS. Zeitgeber Oszilloskop Diskussion

Ausführungszeiten. Worst-Case Execution-Time. Übung zur Vorlesung EZS. Zeitgeber Oszilloskop Diskussion 1 Überblick Ausführungszeiten Übung zur Vorlesung EZS Florian Franzmann Martin Hoffmann Tobias Klaus Peter Wägemann Friedrich-Alexander-Universität Erlangen-Nürnberg Lehrstuhl Informatik 4 (Verteilte Systeme

Mehr

VORSTELLUNG DER DIPLOMARBEIT

VORSTELLUNG DER DIPLOMARBEIT 1 VORSTELLUNG DER DIPLOMARBEIT Thomas Werner Inhaltsverzeichnis 2 Thema Aufgabenstellung Anwendungsdebugging Threads Remote Debugging Implementierung Ausblick Quellen 3 Thema Untersuchung von Funktionsabläufen

Mehr

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 4 Prozesse Maren Bennewitz Version 20.11.2013 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Wdhlg.: Attributinformationen in

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

Fresh Minder 3-Server

Fresh Minder 3-Server Fresh Minder 3-Server Installation und Betrieb Fresh Minder-Vertrieb Rieslingweg 25 D - 74354 Besigheim support@freshminder.de www.freshminder.de ÜBERSICHT Die Standardversion (Einzelplatzversion) von

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

Mehr

Technische Informatik 1

Technische Informatik 1 Technische Informatik 1 7 Prozesse und Threads Lothar Thiele Computer Engineering and Networks Laboratory Betriebssystem 7 2 7 3 Betriebssystem Anwendung Anwendung Anwendung Systemaufruf (syscall) Betriebssystem

Mehr

Aspektorientierte Programmierung (aspect-oriented programming, AOP)

Aspektorientierte Programmierung (aspect-oriented programming, AOP) Aspektorientierte Programmierung (aspect-oriented programming, AOP) Abstract Die aspektorientierte Programmierung ist ein neues Programmierparadigma, das die Probleme und Nachteile, die aus der prozeduralen

Mehr

Ticketexpert Ticketsystem der PHSG Informatik

Ticketexpert Ticketsystem der PHSG Informatik Ticketexpert Ticketsystem der PHSG Informatik Ticketexpert Benutzeranleitung 26. April 2010 Pädagogische Hochschule des Kantons St.Gallen Inhaltsverzeichnis 1 Einleitung 3 2 Arbeiten mit dem Ticketexpert

Mehr

Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen

Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen Software-basierter Speicherschutz durch spezialisierte Java-VMs auf Mikrocontrollersystemen Christian Wawersich Lehrstuhl für Informatik 4 Verteilte Systeme und Betriebssysteme Universität Erlangen-Nürnberg

Mehr

5 Speicherverwaltung. bs-5.1 1

5 Speicherverwaltung. bs-5.1 1 5 Speicherverwaltung bs-5.1 1 Pufferspeicher (cache) realer Speicher Primärspeicher/Arbeitsspeicher (memory) Sekundärspeicher/Hintergrundspeicher (backing store) (Tertiärspeicher/Archivspeicher) versus

Mehr

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede

Mehr

VHDL Verhaltensmodellierung

VHDL Verhaltensmodellierung VHDL Verhaltensmodellierung Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2008/2009 VHDL Verhaltensmodellierung 1/26 2008-10-20

Mehr

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden.

Datentechnik. => Das Rechenergebnis ist nur dann sinnvoll, wenn es rechtzeitig vorliegt. Die Zeit muß daher beim Programmdesign berücksichtigt werden. 5. Steuerung technischer Prozesse 5.1 Echtzeit (real time) Im Gegensatz zu Aufgabenstellungen aus der Büroumgebung, wo der Anwender mehr oder weniger geduldig wartet, bis der Computer ein Ergebnis liefert

Mehr

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss Systeme 1 Kapitel 6 Nebenläufigkeit und wechselseitiger Ausschluss Threads Die Adressräume verschiedener Prozesse sind getrennt und geschützt gegen den Zugriff anderer Prozesse. Threads sind leichtgewichtige

Mehr

Internet for Guests. Interfaces. 1.0.0 Deutsch. Interfaces Seite 1/14

Internet for Guests. Interfaces. 1.0.0 Deutsch. Interfaces Seite 1/14 Internet for Guests Interfaces 1.0.0 Deutsch Interfaces Seite 1/14 Inhalt 1. PMS... 3 1.1 Hinweise... 3 1.2 Konfiguration... 4 1.2.1 VIP/Mitgliedschaft: VIP Gast kostenloser Betrieb... 5 1.2.2 VIP/Mitgliedschaft:

Mehr

Übung I Echtzeitbetriebssysteme

Übung I Echtzeitbetriebssysteme Übung I Echtzeitbetriebssysteme a) Von welchen drei Faktoren hängt bei der Echtzeitverarbeitung das korrekte Ergebnis ab? b) Wann ist ein System echtzeitfähig? c) Was versteht man unter Harter und Weicher

Mehr

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7.

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7. Hier finden Sie von der Firma GriCom Wilhelmshaven eine, um ein Backup Ihres Computers / Ihrer Festplatten zu erstellen und dieses Backup bei Bedarf zur Wiederherstellung zu nutzen. Diese Bedienerführung

Mehr

OSEK/OSEKtime OS. Friedrich Alexander Universität Erlangen-Nürnberg. Wilhelm Haas 15. Juli 2006

OSEK/OSEKtime OS. Friedrich Alexander Universität Erlangen-Nürnberg. Wilhelm Haas 15. Juli 2006 OSEK/OSEKtime OS Ausgewählte Kapitel eingebetteter Systeme Friedrich Alexander Universität Erlangen-Nürnberg 1 Einführung Die Abkürzung OSEK steht für ein im Jahre 1993 gegründetes industrielles Standardisierungsgremium,

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Benutzerdokumentation Hosted Backup Services Client

Benutzerdokumentation Hosted Backup Services Client Benutzerdokumentation Hosted Backup Services Client Geschäftshaus Pilatushof Grabenhofstrasse 4 6010 Kriens Version 1.1 28.04.2014 Inhaltsverzeichnis 1 Einleitung 4 2 Voraussetzungen 4 3 Installation 5

Mehr

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs Java TV Seminar Medientechnik 23.06.2003 Übersicht Einleitung Umgebungen Java TV API - Kategorien Service- und Selektions-APIs Definitionen Packages Service Selection API Application Lifecycle APIs (Xlets)

Mehr

B1 Stapelspeicher (stack)

B1 Stapelspeicher (stack) B1 Stapelspeicher (stack) Arbeitsweise des LIFO-Stapelspeichers Im Kapitel "Unterprogramme" wurde schon erwähnt, dass Unterprogramme einen so genannten Stapelspeicher (Kellerspeicher, Stapel, stack) benötigen

Mehr

Form Designer. Leitfaden

Form Designer. Leitfaden Leitfaden Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den Beispielen verwendeten Namen und Daten sind frei erfunden, soweit nichts anderes

Mehr

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition)

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Ein Prozess kann unmittelbar vom Zustand 1. Running in den Zustand Ready 2. Running in den Zustand Blocked 3. Ready in den Zustand Running Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Der Adressraum

Mehr

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse)

Begriff: Scheduling Planung, Schedule Plan. Verplanung der CPU-Zeit an die Threads (bzw. Prozesse) 5 CPU-Scheduling Im folgenden wird von Threads gesprochen. Bei Systemen, die keine Threads unterstützen, ist der einzige "Thread" eines Prozesses gemeint. Früher wurde dieser Thread synonym mit dem Begriff

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

IRF2000, IF1000 Application Note ModbusTCP API

IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Original-Application Note ads-tec GmbH IRF2000, IF1000 Application Note ModbusTCP API Version 2.0 Stand: 28.10.2014 ads-tec GmbH 2014 IRF2000 IF1000 2 Inhaltsverzeichnis 1 Einführung... 3 2

Mehr

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher 729631 745097 736477 745011 741297 Inhalt Schlussbewertung... 3 Bewertung

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Lösungsskizzen zur Abschlussklausur Betriebssysteme

Lösungsskizzen zur Abschlussklausur Betriebssysteme Lösungsskizzen zur Abschlussklausur Betriebssysteme 24. Januar 2013 Name: Vorname: Matrikelnummer: Studiengang: Hinweise: Tragen Sie zuerst auf allen Blättern (einschlieÿlich des Deckblattes) Ihren Namen,

Mehr

Instruktionssatz-Architektur

Instruktionssatz-Architektur Institut für Informatik 3: Rechnerarchitektur Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2005/2006 Übersicht 1 Einleitung 2 Bestandteile der ISA 3 CISC / RISC Übersicht 1 Einleitung 2 Bestandteile

Mehr

Transit/TermStar NXT

Transit/TermStar NXT Transit/TermStar NXT Hardware/Betriebssystem Ihres Rechners ändern 2013-09 Gültig ab Service Pack 7 Stand 2013-09. Dieses Dokument ist gültig ab Transit NXT Service Pack 7. Transit wird kontinuierlich

Mehr

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme.

Universität Koblenz-Landau. Fachbereich 4: Informatik. Prof. Dr. Dieter Zöbel. Seminararbeit OSEK/VDX. Seminar Echtzeitsysteme. Universität Koblenz-Landau Fachbereich 4: Informatik Prof. Dr. Dieter Zöbel Seminararbeit Seminar Echtzeitsysteme Thema 4 Wintersemester 1999/2000 Von Thorsten Schaub (thorsten@schaub-home.de) 17.12.1999

Mehr

Szenario 3: Service mit erweiterter Schnittstelle

Szenario 3: Service mit erweiterter Schnittstelle 2. Hintergrundverarbeitung in Android: Services und Notifications Szenarien für lokale Services Szenario 3: Service mit erweiterter Schnittstelle Ein Service bietet zusätzliche Methoden an, über die sich

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

Domänenanalyse Threadverwaltung/Scheduling

Domänenanalyse Threadverwaltung/Scheduling Domänenanalyse Threadverwaltung/Scheduling Johannes Handl, Marc Rößler, Christian Strengert 15. Mai 2003 Domänenanalyse Threadverwaltung/Scheduling [1] Domänendefinition Die Erzeugung, Verwaltung, Umschaltung/Wechsel,

Mehr

Telefonshop Version 4.5. Die Abrechnung von Telefongebühren in Telefonshops oder kleinen Hotels und Pensionen

Telefonshop Version 4.5. Die Abrechnung von Telefongebühren in Telefonshops oder kleinen Hotels und Pensionen Die Abrechnung von Telefongebühren in s oder kleinen Hotels und Pensionen Das komfortable Werkzeug zur Abrechnung von Telefonkosten. Steht die reine Abrechnung von Telefonkosten im Somit ist tekowin bestens

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort Was machen wir heute? Betriebssysteme Tutorium 12 1 Organisatorisches Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität

Mehr

Microsoft SQL Server 2014 Express & EPLAN Plattform. EPLAN-Product-IT-Support / FOS / 2015 1

Microsoft SQL Server 2014 Express & EPLAN Plattform. EPLAN-Product-IT-Support / FOS / 2015 1 Microsoft SQL Server 2014 Express & EPLAN Plattform 1 Microsoft SQL Server & EPLAN Plattform Übersicht Download - Microsoft SQL Server 2014 Express mit Advances Services Installation - Microsoft SQL Server

Mehr

Wie groß ist die Page Table?

Wie groß ist die Page Table? Wie groß ist die Page Table? Im vorigen (typischen) Beispiel verwenden wir 20 Bits zum indizieren der Page Table. Typischerweise spendiert man 32 Bits pro Tabellen Zeile (im Vorigen Beispiel brauchten

Mehr

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API

mitho -Framework für plenty PHP-Framework zur Anbindung an die plenty API PHP-Framework zur Anbindung an die plenty API Inhaltsverzeichnis 1 Kurzbeschreibung...3 2 Integration...4 3 Möglichkeiten...5 3.1 Artikel...5 3.2 Aufträge...5 3.3 Kunden...5 4 Interne Funktionsweise...7

Mehr

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Betriebssysteme Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Umfaßt z.b. auch Compiler, Interpreter und Dienstprogramme

Mehr

Handbuch zu AS Connect für Outlook

Handbuch zu AS Connect für Outlook Handbuch zu AS Connect für Outlook AS Connect für Outlook ist die schnelle, einfache Kommunikation zwischen Microsoft Outlook und der AS Datenbank LEISTUNG am BAU. AS Connect für Outlook Stand: 02.04.2013

Mehr

Collax E-Mail Archive Howto

Collax E-Mail Archive Howto Collax E-Mail Archive Howto Howto Dieses Howto beschreibt wie ein Collax Server innerhalb weniger Schritte als E-Mail Archive eingerichtet werden kann, um Mitarbeitern Zugriff auf das eigene E-Mail Archiv

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Aufgabe 2 - Erweiterung um PIC und Interrupts

Aufgabe 2 - Erweiterung um PIC und Interrupts Aufgabe 2 - Erweiterung um PIC und Interrupts Rainer Müller Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2014/2015 R. Müller Erweiterung

Mehr

Inhaltsverzeichnis. 1 Grundsätzliche Überlegung. 2 Hinweis zur Installation

Inhaltsverzeichnis. 1 Grundsätzliche Überlegung. 2 Hinweis zur Installation Inhaltsverzeichnis 1 Grundsätzliche Überlegung...1 2 Hinweis zur Installation...1 3 Konfiguration von AutoDocument...2 3.1 Erfassung der Listeneinträge...2 3.2 Hinterlegung von Notizen...3 3.3 Definition

Mehr

J.5 Die Java Virtual Machine

J.5 Die Java Virtual Machine Java Virtual Machine Die Java Virtual Machine 22 Prof. Dr. Rainer Manthey Informatik II Java-Compiler und Java Virtual Machine Quellcode-Datei class C... javac D.java Java-Compiler - Dateien class class

Mehr

A B A S T A R T Kurz-Anleitung

A B A S T A R T Kurz-Anleitung A B A S T A R T Kurz-Anleitung April 2015 / OM Version 2.0 Diese Unterlagen sind urheberrechtlich geschützt. Insbesondere das Recht, die Unterlagen mittels irgendeines Mediums (grafisch, technisch, elektronisch

Mehr

Onlinehilfe für Texteditor + Signaturpad Stand: 20.12.2015 Version 1.0.0.6

Onlinehilfe für Texteditor + Signaturpad Stand: 20.12.2015 Version 1.0.0.6 Onlinehilfe für Texteditor + Signaturpad Stand: 20.12.2015 Version 1.0.0.6 Voraussetzungen Hardware Ein Pad auf dem ein Microsoft Betriebssystem (Minimum ist Windows 7) läuft. Zudem sollte das Display

Mehr