Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer 1 3. Mikrocontroller 3.4 Auswahlkriterien für den Einsatz

1Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer

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

Versions-Verwaltung

Editor

Übersetzer

Binder

integrierteEntwicklungs-umgebung

Quelldateien

freigegebene Quelldateien

geänderte Quelldateien

Objekt-Dateien

Ausführbare Datei

Entwicklungssystem: PC Zielsystem:Mikrocontroller

Anwendungsprogramm

Download

DebuggerTestSymbole


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 4 KByte Festwertspeicher

3 KByte Schreib-/Lesespeicher

E/A-Adressbereich

unbelegt

unbelegt

0

0FFF

8000

8BFF

FE00

FFFF

Code,Größe 3217 Bytes

Einsprungadresse 0

Daten,Größe 625 Bytes

Stack, Größe 325 Bytes

Peripherie


3. Mikrocontroller

Laden und Testen

– Simulator auf dem Entwicklungssystemgrober 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 Monitorendgültige Zielumgebung, Programm im

Festwertspeicher (ext. Programmieren oder Flash-Code-Loader),

Ladezeiten lang, Test schwierig


3. Mikrocontroller

Download o. Programmieren von int.oder ext. EPROMs, Flash-RAMs, ...

Download,z.B. über serielleSchnittstelle

Contr. Debug-Monitor

HW-Interface

PC-Interface

Test-Hardware

Mikrocontroller

Ziel-Hardware

Mikrocontroller-Testsystem

Mikrocontroller-Zielsystem

Mikrocontroller-Simulator(Software)

Entwicklungs-PC


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


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


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)


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


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


3. Mikrocontroller

SoC Entwicklung mit einer Hochsprache

High Level Design(z.B. in SystemC)

Verifikation

Low Level Design(z.B. in VHDL)

Verifikation

Platzieren und Routen

FPGA, ASIC

Korrekturen

Korrekturen

Test


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


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


3. Mikrocontroller

Erstellung eines SoC mit einer Prozessorkern-Bibliothek:

Prozessorkern-Bibliothek(in VHDL)

Anwendercode

(in VHDL)

Chip(ASIC oder FPGA)

erstellen bzw.programmieren


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


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


3. Mikrocontroller

Prozessor-Kern

SpeicherProgrammierbare Hardware, FPGA

Speicher Ein-/Ausgabe


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


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


3. Mikrocontroller

Semi-statisch Rekonfigurierbar

Kann das FPGA schneller (Millisekunden) rekonfiguriertwerden

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


3. Mikrocontroller

Dynamisch Rekonfigurierbar

Neue FPGA Arrays ermöglichen eine sehr schnelleRekonfiguration (Mikrosekunden)

Ein andere Möglichkeit ist die “Vorab-Konfiguration”bestimmter Teile des Arrays und das Umschalten

durch einKonfigurations-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


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


3. Mikrocontroller

FIPSOC

On ChipMemory

80251Core

CellInterface

AnalogCells

LogicCells

ConfigMemory

To Other FIPSOCsTo External Memory

Dig

ital

I/O

Ana

log

I/O


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


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


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


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


3. Mikrocontroller

Sogar einfache Signalprozessoren ermöglichen den direkten Zugang zu ihren internen Komponenten:


3. Mikrocontroller

Jeder Teil kann direkt durch das Instruktions-Wort gesteuert werden

Program-Control

ALU-Control

Operand-Selection

Multiplier-Control

RAM Addr.-Control

ROM Addr.-Control

Bit 0Bit n

Ein harmonische Integration beider Konzepte ist eine interessante Aufgabe

VLIW oder EPIC könnten einen vielversprechenden Ansatz darstellen


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


3. Mikrocontroller

Hauptwege zur Reduktion des Enerieverbrauchs:

Verringerung der Taktfrequenz

Verringerung der Versorgungsspannung

Optimierung der Mikroarchitektur


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


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


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


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


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


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


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)


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


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


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


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


3. Mikrocontroller

Beispiel:

Taktschritt-orientierter

Mikroarchitektur-simulator

Energiemodelle

Mikroarchitektur-parameter

Schaltkreistechnolgie-parameter

Energiebedarfs-Abschätzung

Verarbeitungs-geschwindigkeits-Abschätzung

Programm


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


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


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


3. Mikrocontroller

Lösungen:

Hybride Java Systeme

Echtzeit-Java

Java-Prozessoren


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)


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)


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


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


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)


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)


3. Mikrocontroller

Der Komodo-Mikrocontroller:

Java

einfacheProgrammierung,

Threads

Echtzeit

Zeitbedingungen,Scheduling

MehrfädigeProzessortechnik

schnellerKontextwechsel

Komodo Mikrocontroller

Java Prozessor,mehrfädige Hardware,

Thread-basierteUnterbrechungsbehandlung,

Middleware


3. Mikrocontroller

Das Komodo-Projekt ist in fünf Ebenen gegliedert

Der Mikrocontroller ist die niedrigste Ebene

Middleware OSA+

Anwendung

Heap

Traps

GarbageCollection Mem.

KlasseEthreads.Klasse

Driver.KlassenStandard Klassen

Signal EinheitPrioritäts-Manager

Multithreading I/O Einheit

Komodo-Mikrocontroller

Documents

Universität Karlsruhe - Prof. Dr. U. Brinkschulte Universität Augsburg - Prof. Dr. Th. Ungerer 1 3. Mikrocontroller 3.4 Auswahlkriterien für den Einsatz