3. Mikrocontroller 3.4 Auswahlkriterien für den Einsatz von Mikrocontrollern (aus der reichhaltigen verfügbaren Palette) Aufgabenstellung Messen Steuern Regeln Überwachen Mensch-Maschine-Schnittstelle Kombination obiger Punkte

3. Mikrocontroller allgemeine Leistungsmerkmale CISC- oder RISC-Architektur Von-Neumann oder Harvard-Architektur Wortbreite (4, 8, 16, 32 Bit) Adressraum

3. Mikrocontroller Architekturmerkmale des Prozessorkerns Welche Befehlsarten stehen zur Verfügung/werden benötigt ? Lade- und Speicher-Operationen logische & arithmetische Operationen Multiplikation & Division Schiebeoperationen, Barrel-Shifter Bit-Testoperationen Gleitkomma-Operationen

3. Mikrocontroller Architekturmerkmale des Prozessorkerns (fortg.) Welche Adressierungsarten sind erforderlich? Unmittelbar Direkt Register Registerindirekt Registerindirekt mit Autoinkrement, Autodekrement Registerindirekt mit Verschiebung Indiziert Indiziert mit Verschiebung Relativ komplexere Adressierungsarten

3. Mikrocontroller Architekturmerkmale des Prozessorkerns (fortg.) Welche Datenformate werden benutzt ? Ganzzahlen (16, 32, 64 Bit) Gleitkommazahlen (32, 64, 80 Bit) Einzelbit-Datentypen Zeichen und Zeichenketten Felder

3. Mikrocontroller Speichermerkmale Wieviel Programm- und Datenspeicher benötigt die Anwendung? Reicht die Größe des internen Daten- und Programmspeichers? Ist ein externer Busanschluss vorhanden? Was ist die max. externe Speichergröße?

3. Mikrocontroller Peripheriemerkmale Anzahl der: parallelen E/A-Kanäle seriellen E/A-Kanäle Interrupt-Eingänge Zähler/Zeitgeber A/D-Wandler D/A-Wandler DMA-Controller Echtzeitkanäle speziellen Peripherie wie CAN, I2C, ...

3. Mikrocontroller Merkmale zur Ereignisbehandlung die Anzahl der Unterbrechungseingänge, eine Prioritäten-Steuerung bei mehrfachen Unterbrechungen, frei wählbare oder starre Prioritäten, das Sperren einzelner Unterbrechungen und die Reaktionszeit auf eine Unterbrechung.

3. Mikrocontroller Weitere technische Merkmale Taktfrequenz Taktzyklen pro Befehl Möglichkeit zum Anschluss langsamer Peripherie Energiebedarf Abwärme Stromspar-Modus

3. Mikrocontroller Ökonomische Merkmale Preis Verfügbarkeit Produktpflege Kundenunterstützung (Support)

3. Mikrocontroller 3.5 Softwareentwicklung In der Regel: Cross-Development

3. Mikrocontroller Da die Entwicklung bis auf den letzen Schritt auf einem leistungsfähigen PC stattfindet => die Entwicklungsumgebung ist zunächst ähnlich zur PC- Programmentwicklung: Versionsverwaltung, Editoren, Übersetzer, Debugger Es gibt jedoch Unterschiede!

3. Mikrocontroller Programmiersprachen Früher Assembler heute meist C, nur zeitkritische Teile in Assembler bei leistungsfähigeren Mikrocontrollern auch C++, erfordert aber mehr Ressourcen und erzeugt mehr Dynamik Java in der Regel zu ressourcen-intensiv Es existieren jedoch einige Forschungsbemühungen in diese Richtung (siehe später)

3. Mikrocontroller Speicherbedarf hier liegt ein wesentlicher Unterschied zur Programmentwicklung auf dem PC bei Mikrocontrollern ist Speicher eine knappe Ressource Übersetzer optimieren meist in Richtung Speicherbedarf (selten Geschwindigkeit) Speichersparende Algorithmen sind gefragt Algorithmen, die vor 10-20 Jahren für den PC entwickelt wurden, können hier interessant werden (zu dieser Zeit hatten PCs etwa den Speicherumfang heutiger Mikrocontroller)

3. Mikrocontroller Adressfestlegung beim Binden bei PCs: dynamische Adressfestlegung zur Laufzeit nur so können mehrere Programme gleichzeitig bearbeitet werden bei Mikrocontrollern: statische Festlegung der Adressen beim Binden (Locator) Die Adressen müssen an das Speicherabbild (Memory Map) des Mikrocontrollers angepasst werden: Programm -> Festwertspeicher Daten -> Schreiblesespeicher Erste Programm-Instruktion, Interrupttabellen, ... , müssen an die richtige Stelle gelegt werden

3. Mikrocontroller Beispiel einer Memory Map

3. Mikrocontroller Laden und Testen Simulator auf dem Entwicklungssystem grober Test, da Zeitverhalten anders und Zielperipherie nicht vorhanden Test auf dem Zielsystem mittels Download und Monitor näher am Zielsystem (Zeitverhalten, Peripherie), immer noch komfortables Testen, Monitor verändert aber Systemverhalten (Initialisierungen, Speichertypen, ...) Test auf dem Zielsystem ohne Monitor endgültige Zielumgebung, Programm im Festwertspeicher (ext. Programmieren oder Flash-Code-Loader), Ladezeiten lang, Test schwierig

3. Mikrocontroller

3. Mikrocontroller 3.6 Forschungstrends 3.6.1 Systems-on-Chip (SoC) SoC sind die konsequente Fortsetzung der grundlegenden Mikrocontroller-Idee: Aufbau eines Systems mit einer minimalen Anzahl externer Komponenten SoC: realisiere das ganze System mit einem einzigen Chip Diese Idee ist Gegenstand vieler verschiedener Forschungsrichtungen!

3. Mikrocontroller Interessante SoC Forschungsrichtungen: Methoden für eine systematische SoC Entwicklung Prozessorkerne als Benutzerbibliotheken Rekonfigurierbare SoCs Integration verschiedener Prozessorkerne 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.1.1 Methoden für eine systematische SoC Entwicklung Notwendige Schritte: Design, Verifikation & Test SoC kombinieren oft digitale und analoge Komponenten Diese Komponenten müssen entwickelt, integriert und getestet werden Heutige Hardware-Beschreibungssprachen (VHDL, Verilog) bewegen sich auf niederer Ebene im Vergleich zu Sprachen der Software-Entwicklung 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Idee: man übertrage die Erfahrungen aus der Software-Entwicklung auf die Hardware- Entwicklung Man definiert “High-Level-Hardware-Beschreibungssprachen”, die folgende aus der Software-Entwicklung bekannte Konzepte einzuführen: Objektorientierung (object orientation) Vererbung (inheritance) Wiederverwendung (resuse) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Beispiele: SystemC: Open systen C Initiative www.systemc.org SuperLog: S2K Superlog Organization www.superlog.org CynApps: Forte Design Systems www.ForteDS.com 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller SystemC ist sehr ähnlich zu C++ Vorteile: Hardware-Komponenten können als Objekte mit Schnittstellen (interfaces) und Funktionalität (functionality) definiert werden ähnliche Sprachen zur Soft- und Hardware-Entwicklung ermöglichen zusätzliche Synergie-Effekte Es können gemeinsame Werkzeuge für Soft- und Hardware verwendet werden Der Datenaustausch wird erleichtert Der Aufwand für das Erlernen durch den Benutzer wird verringert Formale Hochsprachen erlauben eine Verifikation auf hoher Ebene 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller SoC Entwicklung mit einer Hochsprache 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Das Testen kann unterstützt werden durch: eingebettete Teststrukturen Sichtbarmachung interner Hardware-Zustände eingebauten Selbsttests Herausforderung: die Entwicklung effizienter Selbsttests für analoge und digitale Teile eines SoC mit geringen Kosten und geringer zusätzlicher Fläche  Design for Testability. Denke bereits während der Entwicklung an den Test 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.1.2 Prozessorkern-Bibliotheken Grundidee: liefere einen Prozessor nicht als Hardware, sondern als Bibliothek aus. Der Anwender kann den Prozessorkern dann leicht in seine eigene FPGA oder ASIC Entwicklung integrieren Viele Prozessorkerne sind bereits als ASIC-Bibliothek verfügbare, z.B. ARM PowerPC 80251 Kern 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Erstellung eines SoC mit einer Prozessorkern-Bibliothek: 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Gegenwärtige Herausforderungen an die Forschung: Versuche das Gleiche mit FPGAs Für kleine Stückzahlen ist eine FPGA-Entwicklung deutlich preiswerter als eine ASIC-Entwicklung FPGA-Lösungen können “im Haus” erstellt werden Wegen der geringeren Logikdichte von FPGAs sind bisher aber erst kleine Prozessorkerne (z.B. 8051) verfügbar 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.1.3 Rekonfigurierbare SoC Umkehrung der Idee der Prozessorkern-Bibliotheken Ein rekonfigurierbarer SoC besteht aus einem Prozessorkern Speicher einem FPGA Array Während der Prozessorkern und der Speicher unveränderlich sind, kann der FPGA-Anteil rekonfiguriert werden 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Dieser Ansatz ist in doppelter Hinsicht ein guter Kompromiss: Prozessorkern und Speicher können in optimaler Weise realisiert werden Nur der rekonfigurierbare Anteil nutzt die hinsichtlich Geschwindigkeit und Logikdichte weniger optimale FPGA-Technologie Der Anwender kann die Menge an “Spezial-Hardware” für eine gegebene Anwendung selbst bestimmen Der rekonfigurierbare Teil kann so personalisiert werden, dass er eine Aufgabe viel schneller als mittels Software lösen kann 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Es können drei Typen von rekonfigurierbaren SoC unterschieden werden: Statisch Rekonfigurierbar Die Rekonfiguration benötigt längerer Zeit (Sekunden bis Minuten) Das SoC wird einmal statisch für eine Aufgabe konfiguriert Diese Konfiguration ändert sich zur Laufzeit niemals 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Semi-statisch Rekonfigurierbar Kann das FPGA schneller (Millisekunden) rekonfiguriert werden  Das System kann zur Laufzeit rekonfiguriert werden Eine Aufgabe kann dann in Unteraufgaben zerlegt werden Diese Unteraufgaben werden nach dem Pipeline-Prinzip durchgeführt Während eine Unteraufgabe in Software ausgeführt wird, kann das FPGA für die nächste Unteraufgabe rekonfiguriert werden 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Dynamisch Rekonfigurierbar Neue FPGA Arrays ermöglichen eine sehr schnelle Rekonfiguration (Mikrosekunden) Ein andere Möglichkeit ist die “Vorab-Konfiguration” bestimmter Teile des Arrays und das Umschalten durch ein Konfigurations-Register  Das FPGA kann ‘on-the-fly’ rekonfiguriert werden Feinköringe Rekonfiguration Das FPGA kann während der Ausführung einer Prozessorkern-Instruktion rekonfiguriert werden 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Beispiele rekonfigurierbarer SoC FIPSOC (SIDSA coorp. www.sidsa .com) statisch rekonfigurierbar 8051 Prozessorkern FPGA Array mit digitalen und analogen Zellen Analoge Zellen enthalten konfigurierbare Verstärker Vergleicher Signal-Konverter 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller FIPSOC 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller MorphoSys (UCI) dynamisch rekonfigurierbar 32-Bit-TinyRISC-Prozessorkern 64 reconfigurierbare Zellen Jede Zelle enthält Logik ALU Register File Die Rekonfiguration “on the fly” in der Geschwindigkeit des Prozessorkerns geschieht durch Umschalten vorgesetzter Kontext-Wörter Anwendung: Bildbearbeitung 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.1.4 Integration unterschiedlicher Prozessorkerne Kombination von Mikrocontrollern und Signalprozessoren Eine Möglichkeit, die große Anzahl heute verfügbarer Transistoren auf einem Chip zu nutzen Aufgaben des Mikrocontroller-Teils: Ausführung von Steuer- und Regelanwendungen in Echtzeit Signalprozessor-Teils: optimierte Ausführung von Berech- nungen auf Datenströmen mit maximalem Durchsatz 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Beispiele: TriCore, TriCore 2 (Infineon, www.infineon.com) TriCore kombiniert drei Teile: ein RISC Prozessorkern mit Mikrocontroller-Peripherie und einer Hochgeschwindigkeits-Multiplizier-/Addier-Einheit Daher ist TriCore ein erster Schritt Er integriert Teile eines Signalprozessors in einen Mikrocontrollerkern Es gibt immer noch einen einzigen Kern 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Die Integration eines vollständigen Mikrocontrollerkerns mit einem Signalprozessor ist immer noch eine Herausforderung, da: die Programmausführung eines Mikrocontrollers und eines Signalprozessors total unterschiedlich ist ein Mikrocontroller versteckt seine interne Mikrorachitektur durch eine Architektur-Ebene (wie bei Mikroprozessoren) die Parallelität ist unter Kontrolle des Prozessorkerns ein Signalprozessor offenbart dem Anwender seine Mikroarchitektur für maximale Effizienz ist die Parallelität unter Kontrolle des Anwenders 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Sogar einfache Signalprozessoren ermöglichen den direkten Zugang zu ihren internen Komponenten: 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Jeder Teil kann direkt durch das Instruktions-Wort gesteuert werden Ein harmonische Integration beider Konzepte ist eine interessante Aufgabe VLIW oder EPIC könnten einen vielversprechenden Ansatz darstellen 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.2 Energiespar-Techniken Microcontroller werden mehr und mehr in kleinen, mobilen Geräten genutzt (Ubiquitous Computing, Pervasive Computing) Die verfügbare Energie wird durch eine Batterie begrenzt Hauptanforderung: Erzielung einer maximalen Betriebszeit mit der verfügbaren Energie Wärmeabgabe ist ein anderer Grund, den Energieverbrauch zu reduzieren 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Hauptwege zur Reduktion des Enerieverbrauchs: Verringerung der Taktfrequenz Verringerung der Versorgungsspannung Optimierung der Mikroarchitektur 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Reduktion der Taktfrequenz Einfach und effektiv Für CMOS Schaltungen gilt: E ~ f Das bedeutet: Halbierung der Taktrate entspricht einer Halbierung des Energieverbrauchs Problem: die Verarbeitungsgeschwindigkeit wird ebenfalls reduziert 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Reduktion der Versorgungsspannung Nach dem Ohm’schen Gesetz gilt: E ~ V2 Dies bedeutet: 70% Versorgungsspannung bewirken 50% Energieverbrauch Zusätzlich sind Versorgungsspannung und Taktfrequenz nicht unabhängig. Es gilt: f ~ V 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Reduktion der Versorgungsspannung und der Taktfrequenz Bei gleichzeitiger Reduktion von Versorgungsspannung und Taktfrequenz gilt nach den vorigen Zusammenhängen: E ~ f * V 2 ~ f 3 ~ V 3 Kubus-Regel 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Forschungsansätze: Optimierung der Taktfrequenz für die Anwendung z.B. für Echtzeitsysteme: Anpassen der Taktfrequenz und Versorgungsspannung an die Deadlines Ist die Deadline noch weit entfernt, kann die Vearbeitungsgeschwindigkeit und damit der Energiebedarf reduziert werden Ist die Deadline nahe, werden die maximale Taktfrequenz und Versorgungsspannung genutzt Ein geschlossener Regelkreis kann Taktfrequenz und Versorgungsspannung steuern 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Optimierung der Mikroarchitektur Die bisher beschriebenen Ansätze reduzieren auch die Verarbeitungsgeschwindigkeit Ein vielversprechende Idee: Optimierung der Mikroarchitektur zur Reduktion des Energiebedarfs ohne gleichzeitige Reduktion der Verarbeitungsleistung Ansatzpunkte der Optimierung: Reduktion externer Busaktivitäten Statisches Power-Management Dynamisches Power-Managementmanagement Erhöhung der Code-Dichte 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Reduktion der externen Busaktivitäten: RISC Load-/Store Architekturen arbeiten hauptsächlich mit den internen Registern Die Bus-Schnittstelle wird so für viele Operationen nicht benötigt und kann abgeschaltet werden Ein umfangreicher interner Registersatz hilft, externe Buszugriffe zu reduzieren Unterstützung für schmale Datentypen kann dies ebenfalls Während eines 8-Bit Transfers können die oberen 24 Bit einer 32-Bit Busschnittstelle abgeschaltet bleiben 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Statisches Power Management: Spezielle Instruktionen deaktivieren gerade nicht benötigte Komponenten wie Nicht-flüchtigen Speicher Ein-/Ausgabeeinheiten Teile der ALU Flüchtige Speicher können im Schlaf-Modus betrieben werden (z.B. durch Reduktion der Versorgungsspannung auf den zum Aufrechterhalten der Information notwendigen minimalen Level) Schlaf-Modus des Prozessorkerns (z.B. durch statisches Steuerwerk mit 0 Hz minimaler Taktfrequenz) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Dynamisches Power Management: Der Prozessor deaktiviert automatisch nicht benötigte Komponenten Dies kann z.B. in der Pipeline durchgeführt werden Wenn schmale Datentypen unterstützt werden, können Teile der ALU und der internen Datenpfade deaktiviert werden Für einen 8-Bit Datentyp werden z.B. die oberen 24 Bit einer 32 Bit ALU nicht gebraucht und können zur Energieeinsparung deaktiviert werden 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Erhöhung der Code-Dichte: Code-Dichte: Anzahl benötigter Befehle um eine Anwendung zu schreiben Eine hohe Code-Dichte bedeutet, weniger Befehle sind notwendig Dies spart aus zwei Gründen Energie: Weniger Speicher wird gebraucht Weniger Buszyklen zur Ausführung der Anwendung sind nötig Von diesem Standpunkt aus ist CISC besser als RISC 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Weitere Forschungsansätze zur Einsparung von Energie Die vorigen Sektionen haben gezeigt: es besteht ein komplexer Zusammenhang zwischen Architektur, Mikroarchitektur und Energiebedarf  Es wäre günstig, so früh wie möglich während der Entwicklung eines Mikrocontrollers Abschätzungen des Energieverbrauchs vorzunehmen Heute: Energieabschätzung auf Grundlage der Register-Transfer- und Gatter-Ebene Künftig: Energieabschätzungen auf Mikroarchitekturebene 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Idee: man nehme einen taktgenauen Mikroarchitektur-Simulator (zur Abschätzung der Verarbeitungsgeschwindigkeit) Man füge Energiemodelle zur Abschätzung des Energieverbrauchs hinzu Diese Energiemodelle schätzen den Energieverbrauch jeder Mikroarchitektur-Komponente für jeden Taktzyklus und jeden Zustand Ein Standard-Simulator enthält nur Mikroarchitektur-Parameter Energiemodelle beinhalten zusätzlich Technologie-Parameter 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Beispiel: 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3.6.3 Java und Java-Prozessoren für eingebettete Systeme Java bietet viele Vorteile für eingebettete Systeme: Einfache Programmierung Wiederverwendbarkeit Robustheit Reicher Satz von Standard-Klassenbibliotheken Java Bytecode ist portabel klein sicher 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Java Pakete für eingebettete Systems (Sun): Personal Java für einfache Geräte mit GUI und Netzwerk Embedded Java für kleine Systeme mit wenig Speicher und schwacher Verarbeitungsleistung Java Card zur Programmierung von Smart Cards 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Probleme mit eingebetteten Echtzeitsystemen: Die ursprüngliche Java-Sprachdefinition enthält keinerlei Echtzeit-Elemente niedere Verarbeitungsgeschwindigkeit bei interpretierter JVM Schlechtes Best-/Worst-Case Intervall für die Ausführungszeit bei JIT-compiler basierter JVM Leistungsfähige Hardware für Flash-Compiler erforderlich Verlust der Portabilität bei nativem Compiler Garbage Collection wirft zusätzliche Probleme auf 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Lösungen: Hybride Java Systeme Echtzeit-Java Java-Prozessoren 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Hybride Java Systeme: Kombinieren Java mit einem Standard-Echtzeit-OS Java selbst ist nicht echtzeitfähig Die Echtzeit-Anteile einer Anwendung werden in C oder C++ geschrieben Beispiele: JWorks (WindRiver), Java for OS-9 (Microware Systems) oder JavaOS (Integrated Systems) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Echtzeit-Java Systeme: machen Java selbst echtzeitfähig Spracherweiterungen, z.B. zur Definition von Echtzeit- Threads, Synchronisation oder Speicherbereinigung sind erforderlich Derzeit zwei wesentliche Standards: The Real-time Specifications for Java (Sun) Real-time Core extensions for Java (JConsortium) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Wie realisiert man Echtzeit-Java ? 1. Man benutzt eine echtzeitfähige JVM Interpretation von Java Bytecode wie bei Standard Java Garantierte Ausführungszeiten Zusätzliche Funktionen für Echtzeiterweiterungen Beispiel: PERC (NewMonics) Problem: langsame Ausführung im Vergleich zu C wegen Interpretation 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 2. Man benutzt einen nativen Compiler Java wird zu nativem Maschinencode übersetzt Dies erlaubt eine schnelle Ausführung Beispiel: JBed (Oberon Microsystems) Probleme: Verlust der Bytecode-Vorteile wie Portabilität Kein dynamisches Klassenladen 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 3. JIT oder Flash Compiler JIT (Just in Time) Compiler übersetzen den Code, wenn er gebraucht wird Problem: Ausführungszeiten sind schwer abzuschätzen, großes Best-case Worst-case Intervall Flash Compiler übersetzen die ganze Klasse, bevor sie geladen wird Problem: der Compiler muss auf dem Zielsystem laufen => erhöht den Speicherbedarf beträchtlich (auch für JIT) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller 4. Java Prozessoren Führen Java Bytecode direkt in Hardware aus Optimiert für spezielle Java Eigenschaften wie Stack-basierte Bytecode Operationen Garbage Collection Synchronisation => Hohe Verarbeitungsgeschwindigkeit für Bytecodes Beispiele: PicoJava II (Sun), JEM (aJile systems), Delft (TU Delft) , PCS1000(Patriot Coorp.), JSM (Universität Rostock), Komodo (Universitäten Karlsruhe/Augsburg) 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Der Komodo-Mikrocontroller: 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM

3. Mikrocontroller Das Komodo-Projekt ist in fünf Ebenen gegliedert 1./2. being solved by dedicated hardware 3. example: method calls (not classes) 3./4. solved by adapted JVM Der Mikrocontroller ist die niedrigste Ebene