embedded architectures am Beispiel AVR - Weblearn

Transcrição

Eingebettete Systeme am Beispiel Atmel
AVR/AVR32
Schriftliche Ausarbeitung
Hochschule Bremen - University of Applied Sciences Bremen
Fachbereich: Elektrotechnik und Informatik
Studiengang Technische Informatik
Fachrichtung: Angewandte Informatik
Rechnerstrukturen Labor
Prof. Dr. Thomas Risse
Wintersemester 2007/2008
Semesterverband: I7I
vorgelegt von:
Florian Haskamp (Matrikelnr. 151199)
Thorsten Katzor (Matrikelnr. 147487)
Bremen, 11. März 2008
Inhaltsverzeichnis
Abbildungsverzeichnis
Inhaltsverzeichnis
1 Einführung
4
1.1
Einsatzgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2 Mikrocontroller
2.1
2.2
2.3
2.4
8
Atmel AVR (8 Bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.1
Kernarchitektur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.2
Befehlssatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.1.3
AVR Mikrocontroller Familie
. . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.2.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.2.2
Eignung für eingebettete Systeme . . . . . . . . . . . . . . . . . . . . .
18
Atmel AVR32 (32 Bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3.1
Befehlssatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.2
Mikroarchitekturen
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.3
Priorisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.4
Java Erweiterung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.5
Pipeline
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.6
MMU / MPU
Atmel ATtiny13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
Atmel AT32AP7000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.4.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.4.2
Eignung für eingebettete Systeme . . . . . . . . . . . . . . . . . . . . .
29
3 Software
32
3.1
Entwicklung
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.2
ISP und JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3
Betriebssysteme
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
AVR Architektur [avr8]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3
ADD (AVR RISC) [avr8is]
Beispiel: 32-Bit-Befehl JMP (AVR RISC) [avr8is]
. . . . . . . . . . . . . . . .
14
4
AVR Mikrocontroller Familie [avr8] . . . . . . . . . . . . . . . . . . . . . . . .
15
5
Architektur ATtiny13 [avr8] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
6
ADD Befehl: kompakt [avr32] . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2
Beispiel: 16-Bit-Befehl
2
. . . . . . . . . . . . . . . .
14
7
ADD Befehl: erweitert [avr32] . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8
Java Erweiterung Software / Hardware [avr32jvm] . . . . . . . . . . . . . . . .
23
9
Java Ausführung [avr32jvm] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
10
AT32AP7000 Pipeline [avr32ap] . . . . . . . . . . . . . . . . . . . . . . . . . .
25
11
AT32AP7000 Übersicht [embnews] . . . . . . . . . . . . . . . . . . . . . . . .
28
12
Umfrage embedded.com [embos]
35
. . . . . . . . . . . . . . . . . . . . . . . . .
3
1 EINFÜHRUNG
1 Einführung
In den letzen Jahrzehnten zeichnete sich ein deutlicher Trend bei der Entwicklung von Rechnersystemen ab, der sich auch in naher Zukunft so fortsetzen wird; der Trend der Miniaturisierung.
In den 80er Jahren arbeitete man noch mit groÿen Mainframe-Rechnern, um Daten elektronisch
zu verarbeiten, während in den 90er Jahren diese Rechner durch den PC (Personal Computer)
abgelöst wurden. Das letzte Jahrzehnt wurde und wird vor allem durch mobile Endgeräte wie
Notebooks, Subnotebooks und PDAs geprägt, man spricht dabei auch von der Post-PC Era.
Teilweise schon heute aber auch in der Zukunft werden kleinere Rechnersysteme entwickelt, die
in gröÿere Produkte integriert werden, Beispiele hierfür sind Mobiltelefone, Digitalkameras uvm.
Dieser Trend wird auch als verschwindende Computer bezeichnet, damit wird ausgedrückt,
dass Rechnersysteme nicht mehr direkt sichtbar, sondern eher im verborgenen - also für den
Nutzer nicht sichtbar - arbeiten. Peter Marwedel beschreibt dazu in seinem Buch Eingebettete
Systeme [esmar] drei Begrie, welche die Schwerpunkte zukünftiger Informationsverarbeitung
charakterisieren:
•
ubiquitous computing
(dtsch.: Rechnerallgegenwart):
Informationen werden überall und jederzeit zur Verfügung gestellt.
•
pervasive computing
(dtsch.: Rechnerdurchdringung):
Durchdringende Vernetzung des Alltags durch den Einsatz von intelligenten Geräten.
•
ambient intelligence (dtsch.: Umgebungsintelligenz):
Kommunikationstechnologie im Wohnbereich, intelligente Gebäudetechnik
Grundlage für diese Charaktereigenschaften sind eingebettete Systeme. Als eingebettetes System versteht man intelligente informationsverarbeitende Systeme, die in eine gröÿere technische
Umgebung integriert (eingebettet) sind, wobei diese Datenverarbeitungen normalerweise nicht
direkt vom Benutzer wahrgenommen werden (vgl.[esmar]). Eingebettete Systeme werden häug
nur für einen bestimmten Zweck entwickelt und arbeiten meistens autonom. Im folgendem Abschnitt soll ein kurzer Überblick über die Einsatzgebiete von eingebetteten Systemen gegeben
werden.
1.1 Einsatzgebiete
Eingebettete Systeme sind heute in sämtlichen Bereichen des alltäglichen Lebens vorhanden.
Die folgende Auistung mit exemplarischen Beispielen (vgl. [esmar] Seite 5) soll einen kurzen
Einblick in die vielen unterschiedlichen Einsatzgebiete dieser Systeme geben:
4
1.1 Einsatzgebiete
•
1 EINFÜHRUNG
Automobilindustrie
Gerade im Bereich der Automobilindustrie zeichnet sich der Trend ab, immer mehr Elektronikkomponenten einzusetzen. 1995 wurden in einem Audi A6 genau sechs eingebettete
Systeme verbaut, heutzutage sind es schon 70 mit steigender Tendenz (vgl. [cz]). Als Beispiele gelten für diesen Bereich: ABS (Antiblockiersystem), adaptives Kurvenlicht, ESP
(Elektronisches Stabilitätsprogramm), elektronisches Einspritzsystem, Navigationssystem,
Infotainment, Tempomat, etc.
•
Bordelektronik im Flugzeug
Auch bei Flugzeugen werden viele intelligente informationsverarbeitende Systeme verwendet, die einen groÿen Anteil am Gesamtwert eines Flugzeugs ausmachen. Beispiele hierfür
sind Autopilot-, Flugkontroll-, Anti-Kollisions- und Piloteninformationssysteme.
•
Eisenbahntechnik
Im Bereich der Eisenbahntechnik nden eingebettete Systeme bei Zügen, Lokomotiven
und stationären Sicherheitssystem Verwendung. Auch hier bildet der Anteil an Elektronik
einen beachtlichen Teil am Gesamtwert.
•
Telekommunikation
Die Herstellung von Mobiltelefonen hat in den letzten Jahren ein enormes Wachstum
erlebt, die Funktionalität nimmt ständig zu, während die Geräte dabei immer kompakter
werden. Multimedia-Applikationen, Büro-Anwendungen, alles gehört bereits heute zum
Funktionsumfang eines Mobiltelefons. Bei dieser Art von Einsatzgebiet spielen vor allem
die schnelle Verarbeitung von Daten, ein geringer Stromverbrauch sowie die Gröÿe der
Systeme eine wichtige Rolle.
•
Medizinische Systeme
In der Medizintechnik verwendet man eingebettete Systeme bspw. für Überwachungssysteme (Monitoring), elektronische Gasdosierung, Glukosetester, Infusionspumpen, Respiratoren, Inkubatoren, EEG (Elektroenzephalograe), EKG (Elektrokardiogramm).
•
Unterhaltungselektronik
Ein Bereich, in dem viele Nutzer gar nicht bemerken, dass sie es mit intelligenten Systemen zu tun haben, ist der Bereich der Unterhaltungselektronik. In diesen Bereich fallen
Digitalkameras, MP3-Player, DVB-T-Receiver, CD/DVD Systeme, etc.
•
weitere Einsatzgebiete lassen sich im Bereich der Automatisierungstechnik, der Robotik,
bei militärischen Anwendungen, in Authentizierungs-Systemen oder intelligenten Gebäuden nden.
5
1.2 Anforderungen
1 EINFÜHRUNG
1.2 Anforderungen
Aus den im vorhergehenden Kapitel genannten Einsatzgebieten wird deutlich, dass eingebettete
Systeme speziellen Anforderungen gerecht werden müssen. Diese Systeme bestehen oft aus Sensoren und Aktoren; Sensoren sammeln Informationen über die Umgebung und Aktoren nehmen
aktiv Einuÿ auf die Umwelt. Da solche Systeme häug direkt mit Ihrer Umgebung verbunden
sind und unmittelbaren Einuÿ auf diese ausüben, müssen sie
verlässlich sein. Beispiele für die-
se Beeinussung nden wir in Transportmitteln wie Autos, Zügen, Flugzeugen usw. Teilweise
müssen eingebettete Systeme auch sicherheitskritischen Anforderungen gerecht werden, wenn
wir uns die Steuerung eines Atomkraftwerkes vor Augen führen (vgl. [esmar] Seite 95)
Verlässlichkeit
Ein eingebettetes System muss
verlässlich sein. Diese Anforderung wird durch
folgende Charaktereigenschaften näher speziziert (vgl. [baswt]):
•
Zuverlässigkeit
Die Zuverlässigkeit beschreibt hierbei, inwieweit das System fähig ist, sein Leistungsniveau
unter festgelegten Bedingungen in einem festen Zeitraum zu bewahren.
Reife
Wie oft versagt das System aufgrund von Fehlern?
Fehlertoleranz
Wie verhält sich das System gegenüber der Nicht-Einhaltung der spezizierten
Schnittstellen?
•
Wartbarkeit/Wiederherstellbarkeit
Wartbarkeit gibt an, wie groÿ der Aufwand ist, in einer bestimmten Zeitspanne das Leistungsniveau nach Versagen wiederherzustellen.
•
Verfügbarkeit
Verfügbarkeit macht Aussagen über die Wahrscheinlichkeit, dass das System bestimmte
Anforderungen in einem festgelegten Zeitintervall erfüllt. Demnach berechnet sich die
Verfügbarkeit etwa nach folgender Formel:
Verfügbarkeit
=
Gesamtzeit−Gesamtausfallzeit
Gesamtzeit
Zuverlässigkeit und Wartbarkeit müssen entsprechend hoch sein, um eine hohe Verfügbarkeit zu erreichen.
6
1.2 Anforderungen
•
1 EINFÜHRUNG
Sicherheit
Sicherheit macht Aussagen über die Wahrscheinlichkeit, dass ein ausfallendes System
Schaden anrichten kann.
•
Integrität
Integrität beschreibt, inwiefern das System die Fähigkeit besitzt, Daten vor Manipulation
zu schützen, vertrauliche Daten geheim zu halten und die Authentizität der Kommunikation zu gewährleisten.
Ezienz
Ein eingebettetes System muss ezient sein, d.h. das Verhältnis zwischen dem
Leistungsniveau und den eingesetzten Mitteln sollte möglichst hoch sein. Dabei sind folgende
fünf Aspekte zu unterscheiden (vgl. [esmar] Seite 158):
1. Energie
Eingebettete Systeme sind oft in tragbare Geräte integriert und beziehen somit Ihre
Energie aus Batterien bzw. Akkumulatoren. Die Kapazitäten dieser Energieträger sind
begrenzt, zudem beanspruchen die zahlreichen Mulitmedia-Anwendungen immer höhere Rechenleistung. Die vorhandene elektrische Energie muss daher ezient eingesetzt
werden, um dem Kunden möglichst lange Betriebsdauern zu gewährleisten.
2. Codegröÿe
Bei eingebetteten Systemen muss der auszuführende Code innerhalb des Systems gespeichert werden können, da es bei solchen Systemen i.A. keine Festplatten gibt. Der Code
muss so klein wie möglich sein, während die Funktionalität erhalten bleiben muss. Will
man beispielsweise auf einem
System On a Chip (SoC), bei dem alle informationsverarbei-
tenden Komponenten auf einem Chip vorhanden sind, einen Befehlsspeicher integrieren,
so muss dieser sehr ezient genutzt werden.
3. Laufzeit-Ezienz
Bei dieser Eigenschaft geht es darum, möglichst ressourcenschonend vorzugehen. Die
Funktionalität und das Einhalten von Zeitbedingungen sollten mit minimalem Einsatz
von Hardware- und Energie-Ressourcen sichergestellt sein. Desweiteren sollten nur Komponenten integriert werden, welche die sog.
worst case execution time
(kurz: WCET)
wirklich verbessern. Dies ist insbesondere bei Echzeitsystemen von Bedeutung, da es
hierbei auf die rechtzeitige Lieferung von korrekten Ergebnissen zu bestimmten Zeitpunkten ankommt. Die WCET der eingesetzten Komponenten darf also nie gröÿer sein, als es
die zeitlichen Vorgaben erlauben.
4. Gewicht
7
2 MIKROCONTROLLER
Eingebettete System sind oft in mobilen Endgeräten integriert. Aus diesem Grund ist es
wichtig, ein möglichst geringes Gewicht zu erzielen, damit der Kaufanreiz erhalten bleibt.
5. Preis
Ebenso wie das Gewicht spielt der Preis eine wichtige Rolle. Um wettbewerbsfähig zu
bleiben, müssen Hard- und Software kostenezient produziert und genutzt werden.
Echtzeitanforderungen
Viele eingebettete Systeme müssen Echzeit-Bedingungen erfüllen,
bei denen Berechnungen innerhalb bestimmter Zeitspannen erfolgt sein müssen. Schon bei geringen Unregelmäÿigkeiten bei der Einhaltung dieser Vorgaben, kann es z.B. bei Audio/VideoAnwendungen zu Qualitätsverlusten kommen. Es kann sogar zu körperlichen Schäden der Benutzer kommen, wenn z.B. Systeme im Auto oder in Zügen nicht korrekt arbeiten/reagieren.
Man unterscheidet hierbei zwei Formen von Zeitbedingungen: Zum Einen harte Zeitbedingungen, deren Nicht-Einhaltung katastrophale Folgen haben kann, und zum Anderen weiche
Zeitbedingungen, die alle anderen Bedingungen umfassen. Während in normalen informationsverarbeitenden Systemen Techniken eingesetzt werden, um die Geschwindigkeit zu erhöhen
(Caches) bzw. die Zuverlässigkeit der Kommunikation zu verbessern (Protokolle mit wiederholten Sendevorgängen) und dabei Verzögerungen in Kauf genommen werden, funktioniert dies
bei Echzeitsystemen nicht. Diese Systeme müssen immer eine vorgegebene Antwortzeit garantieren.
2 Mikrocontroller
Die Herzstücke von eingebetteten Systemen sind sog. Mikrocontroller. Mikrocontroller werden
in der Literatur häug auch als
nur als
µC
micro controller unit (MCU), als µController oder auch einfach
bezeichnet. Sie sind deniert als leistungsfähige, programmierbare Rechnersysteme
auf einem Chip. Dabei gibt es oft den Fall, dass auf diesem Chip zusätzlich alle nötigen Funktionseinheiten wie z.B. Speicher, A/D-Wandler, Timer, I/O-Schnittstellen, etc. integriert sind,
man spricht dann von einem
system on a chip (SoC). Mikrocontroller gibt es in den verschie-
densten Variationen mit mehr oder weniger Speicher, in kleiner oder gröÿerer Form. Auf dem
Markt gibt es zahlreiche Hersteller, von denen die Marktführer hier aufgelistet sind:
•
Atmel
•
ARM
•
Texas Instruments
8
2.1 Atmel AVR (8 Bit)
•
IBM
•
Intel
•
Hitachi
2 MIKROCONTROLLER
Für diese Ausarbeitung wurden zwei Mikrocontroller des Unternehmens Atmel ausgewählt, die
als Beispiel für diese Technologie dienen sollen und im Weiteren näher erläutert werden. Das
Unternehmen wurde 1984 gegründet und ist, wie in der obigen Liste aufgezeigt, eines der
führenden Unternehmen in diesem Bereich weltweit.
Die 8-Bit-Variante der Mikrocontroller wurde ausgewählt, da sie im Hobby-Bereich besonders
1
beliebt und verbreitet sind: Sie sind meist in DIL -Gehäusen verfügbar, können per In-SystemProgramming (dazu später mehr) programmiert werden, und es existieren eine Vielzahl von
kostenlosen Programmen zur Softwareentwicklung (Assembler, Compiler).
Die 32-Bit-Variante als Stellvertreter für leistungsfähigere Mikrocontroller wurde für eine bessere
Vergleichbarkeit aus dem gleichen Hause gewählt.
2.1.1 Kernarchitektur
Atmels AVR Architektur ist eine 8-Bit-Kernarchitektur. Der Kern dieser MikrocontrollerStruktur ndet sich bei allen Mikroprozessoren dieser Architektur-Familie wieder. Die Unterschiede der einzelnen Prozessoren bestehen lediglich in der Gröÿe des Speichers und der Anzahl
an I/O-Modulen.
Der Befehlssatz dieser Architektur wird von Atmel als
Advanced RISC Architektur
bezeichnet -
inwieweit die Bezeichnung RISC als zutreend gilt, wird im Abschnitt 2.1.2 näher erläutert.
Abb. 1 zeigt die AVR Kernarchitektur. Sie deniert folgende Merkmale:
1
•
8-Bit Architektur
•
32 8-Bit Allzweck-Register
Das Dual in-line package (Akronym DIP, auch Dual In-Line, kurz DIL) ist eine längliche Gehäuseform (Package) für elektronische Bauelemente, bei der sich zwei Reihen von Anschlussstiften (Pins) zur Durchsteckmontage an gegenüberliegenden Seiten des Gehäuses benden. [wikipedia]
9
2 MIKROCONTROLLER
•
Harvard-Architektur
•
Abarbeitung eines Befehls pro Taktzyklus (meistens)
Abbildung 1: AVR Architektur [avr8]
Die hohe Anzahl an Allzweck-Registern ist in diesem Segment der Mikroarchitekturen eher
unüblich, daher ist es ein besonderes Merkmal dieser Architektur. Bei der Architektur wurde
das Harvard-Schaltungskonzept verwendet. Dies bedeutet, dass Programm und Datenspeicher
physikalisch getrennt von einander implementiert sind und dabei über getrennte Busse angesteuert werden. Durch diese Form ergeben sich Vorteile: Eine schnellere Befehlsabarbeitung durch
gleichzeitiges Laden von Daten und Befehlen, bei Softwarefehlern kann der Programmcode nicht
überschrieben werden und es sind unterschiedliche Daten- und Befehlswortbreiten möglich. Ein
Nachtteil dieser Bauweise ist allerdings, dass unbenötigter Datenspeicher nicht als zusätzlicher
Befehlsspeicher genutzt werden kann. In Abb. 1 wird diese Architektur durch die getrennten
Blöcke
Flash Program Memory
(Befehlspeicher, 16-Bit Organisation) und
Data SRAM
(Da-
tenspeicher, 8-Bit Organisation) deutlich. Die AVR Architektur verfügt dabei über eine ALU
10
2 MIKROCONTROLLER
für die Verarbeitung arithmetisch-logischer Operationen mit zwei Operanden. Desweiteren ist
diese Bauart mit folgenden Komponenten ausgestattet:
•
Für die Verarbeitung von Unterbrechungen (Interrupts und Exceptions) gibt es eine
terrupt Unit.
•
Zur Steuerung von zeitlichen Abläufen gibt es einen
Watchdog Timer.
In-
Dieser Timer
besitzt einen eigenem Taktgeber. Überschreitet der Timer ein bestimmtes Zeitfenster,
ohne dass er vom laufenden Programm zurückgesetzt worden ist, wird ein Interrupt bzw.
ein System-Neustart ausgelöst.
•
Es gibt einen
Analog Comparator
zum Vergleich von analogen Signalen.
Ein weiteres besonderes Merkmal dieser Kernarchitektur sind drei besondere Register, die als X-,
Y- und Z-Register bezeichnet werden (siehe Abb. 5). Es handelt sich dabei um die sechs letzten
Byteregister der insgesamt 32 8-Bit-Allzweckregister. Diese Register können paarweise als drei
16-Bit indirekt addressierte Zeiger für die Datenspeicher Adressierung verwendet werden, um
eziente Adressberechnungen zu ermöglichen. Einer dieser Adresszeiger kann ebenso als Zeiger
für
Look Up Tables (LUT) im Flash-Programmspeicher genutzt werden.
2.1.2 Befehlssatz
Laut Atmel handelt es sich bei der AVR Mikrocontroller-Familie um eine sog. RISC (
instruction set computing )
reduced
Architektur. Unter einer RISC-Architektur versteht man folgende
Eigenschaften des Befehlssatzes:
•
Weniger komplexe Befehle
Durch weniger komplexe Befehle wird auf der einen Seite das Chipdesign vereinfacht
(weniger Transistoren) und auf der anderen Seite muss weniger Aufwand zum Dekodieren
des Befehls betrieben werden.
•
Befehle bei RISC-Prozessoren sind fest verdrahtet
Alle Operationen werden durch Leiterbahnen auf dem Chip repräsentiert. Es gibt also
keine
•
µProgramm-Steuerung,
wie z.B. bei CISC-Prozessoren.
LOAD/STORE-Architektur
Nur LOAD- und STORE-Befehle greifen auf den Speicher zu.
•
Hohe Anzahl an Allzweck-Registern
11
•
2 MIKROCONTROLLER
Homogener Befehlssatz, d.h. wenige Befehlsformate
Es gibt nur wenige Befehle, die in der Regel gleich breit sind und wenig Befehlsformate
aufweisen.
Nachfolgend sind die tatsächlichen Merkmale des 8-Bit-AVR-Befehlssatzes dargestellt:
Load/Store-Architektur
So
wie
kurz
zuvor
beschrieben
kommt
auch
hier
eine
LOAD/STORE-Architektur zum Einsatz, bei der nur über LOAD/STORE-Befehle auf den Speicher zugegrien wird.
Adressierungsarten
Insgesamt sind bei dieser Architektur 13 verschiedene Arten der Adres-
sierung möglich:
1. Direct Single Register Addressing
Ein Operand bendet sich in einem Register des Registersatzes.
2. Direct Register Addressing
Zwei Operanden benden sich in Registern des Registersatzes.
3. I/O Direct Addressing
Die sechs unteren Bits des Befehls werden zur externen Speicheraddressierung verwendet.
4. Direct Data Addressing (2-Wort-Befehl, 1 Wort = 16 Bits)
Die 16-Bit-Adresse zur Datenadressierung bendet sich in den unteren 16-Bits des 2Wort-Befehls.
5. Data Indirect with Displacement
Die Datenspeicheradresse wird aus der Summe des Y- oder Z-Register mit den unteren
6 Bits des Befehls gebildet.
6. Data Indirect
Die Adresse des Operanden (im Datenspeicher) bendet sich in einem der speziellen X-,
Y- oder Z-Register.
7. Data Indirect Addressing with Pre-decrement
Der Inhalt von dem X-,Y- oder Z-Register wird um 1 verringert. Der veringerte Inhalt
bildet die Adresse des Operanden (im Datenspeicher).
8. Data Indirect Addressing with Post-increment
12
2 MIKROCONTROLLER
Der Inhalt von dem X-, Y- oder Z-Register bildet die Adresse des Operanden (im Datenspeicher). Nach der Operation wird dessen Inhalt um eins erhöht.
9. Program Memory Constant Addressing
Der Inhalt des Z-Registers bildet die konstante Byteadresse. Die oberen 15-Bits des Befehls beschreiben die Wort-Adresse, während das LSB entscheidet, ob die oberen oder
unteren 16 Bits des Programmspeichers angesprochen werden.
10. Programm Memory Addressing with Post-increment
Der Inhalt des Z-Registers bildet die konstante Byteadresse. Die oberen 15-Bits des Befehls beschreiben die Wort-Adresse, während das LSB entscheidet, ob die oberen oder
unteren 16 Bits des Programmspeichers angesprochen werden. Nach der Operation wird
der Inhalt des Registers um eins erhöht.
11. Direct Program Memory Addressing (32-Bit)
Die Programmausführung beginnt ab der Adresse, die sich direkt aus 22-Bits des Befehls
ergeben (6 MSB, 16 LSB).
12. Indirect Program Memory Addressing
Die Programmausführung beginnt ab der Adresse, die aus dem Inhalt des Z-Registers
gebildet wird.
13. Relative Programm Memory Addressing
Die Programmausführung beginnt ab der Adresse, die aus der Summe des aktuellen und
um eins erhöhten Programmzählers und einer 12-Bit-Konstanten (vorzeichenbehaftet)
aus dem Befehl gebildet wird.
Diese hohe Anzahl an Adressierungsarten widerspricht den eigentlichen RISC-Eigenschaften,
siehe auch die Hinweise auf Seite 14.
Befehlsbreite
Durch die implementierte Harvard-Architektur (siehe Abschnitt 2.1.1) ist es
möglich, dass sich die Befehlswortbreite von der Datenwortbreite unterscheidet. Bei diesem
Befehlssatz ist ein Befehlswort 16-Bit breit, für spezielle Befehle zur direkten Daten- oder
Programmadressierung ist ein 2-Wort-Befehl vorgesehen (32-Bit). Beispiele hierfür sind:
1.
Additionsbefehl
(16-Bit-Befehl)
Die Inhalte der Register Rd und Rr werden addiert und in das Register Rd geschrieben.
Danach wird der Programmzähler um eins erhöht.
13
2 MIKROCONTROLLER
Abbildung 2: Beispiel: 16-Bit-Befehl
2.
Sprungbefehl
ADD
(AVR RISC) [avr8is]
(32-Bit-Befehl)
Die Programmausführung beginnt bei der Adresse, die aus der 22-Bit-Konstante gebildet
wird.
Abbildung 3: Beispiel: 32-Bit-Befehl
JMP
(AVR RISC) [avr8is]
In Abb. 2 und 3 ist deutlich zu erkennen, dass eine gewisse Inhomogenität bei den OperationCodes der Befehle existiert; sie haben weder eine feste Breite noch eine einheitliche Anordnung.
Ob es sich bei dieser Implementierung tatsächlich um eine RISC-Architektur handelt, ist fragwürdig. Die hohe Anzahl an Allzweck-Registern und die LOAD/STORE-Architektur sprechen
dafür, die Inhomogenität des Befehlsaufbaus und die hohe Anzahl an unterschiedlichen Adressierungsarten sprechen eher dagegen.
2.1.3 AVR Mikrocontroller Familie
Abb. 4 zeigt den Aufbau der AVR Mikrokontroller - wie bereits erwähnt, ist die Kernarchitektur
in allen AVR Controllern wieder zu nden. Es gibt zwei unterschiedliche Gruppen
TINY
und
MEGA, die sich in Gröÿe und Eigenschaften unterscheiden. TINY ist dabei die Gruppe mit den
Mikroprozessoren für den Low-End-Bereich, sie verfügen über wenig Speicher, sind dafür aber
klein und günstig. MEGA-Controller haben dagegen wesentlich mehr Funktionen durch integrierte I/O-Schnittstellen oder andere Module und verfügen darüberhinaus über einen gröÿeren
Speicher.
14
2 MIKROCONTROLLER
Abbildung 4: AVR Mikrocontroller Familie [avr8]
ATtiny - Eigenschaften im Überblick
ATmega - Eigenschaften im Überblick
•
Speicher: 1-8 KB Flash Speicher
•
Speicher: 4-256 KB Flash Speicher
•
Anzahl I/O-Pins: 6-18
•
Anzahl I/O-Pins: bis zu 100
•
Gröÿe: 7,7mm x 5,13mm
•
Gröÿe: 15,75mm x 15,75mm
(≈1/6 Eurocent)
•
(≈1 Eurocent)
•
Preis: 1,20 Euro (ATTINY 13V-10SU)
Preis: 14,30 Euro (ATMEGA 2561V8AU)
Spezialisierte AVR Mikrocontroller
Atmel hat in seinem Produktportfolio viele Mikrocon-
troller, die für bestimmte Einsatzzwecke entwickelt worden sind. Im Folgenden sind diese mit
ihren Eigenschaften aufgelistet:
•
Automotive AVR
2
Spezielle Controller mit CAN - und LIN
3 -Schnittstellen, speziell für die Autmobilindustrie
daher mit besonderen Qualitätsmerkmalen wie z.B. erlaubten Betriebstemperaturen bis
◦
+150 C.
•
AVR Z-Link
Unterstützung des ZigBee Standards (oener Funkstandard nach IEEE 802.15.4)
CAN Controller Area Network - Asynchrones, serielles Feldbussystem entwickelt zur Verringerung der Kabelbäume in Automobilen
3
LIN Local Interconnect Network - Feldbussystem entwickelt zur kostengünstigen Kommunikation von intelligenten Sensoren und Aktuatoren im KfZ-Bereich
2
15
2.2 Atmel ATtiny13
•
2 MIKROCONTROLLER
CAN AVR
AVR Controller mit CAN-Schnittstelle
•
LCD AVR
Spezielle Schnittstelle zur Ansteuerung von Monochrome-LCDs.
•
LIGHTNING AVR
Spezielle Eigenschaften zur Ansteuerung von Blitzlicht (für Digitalkamera, o.Ä.)
•
Smart Battery AVR
Besonders stromsparend zur Erhaltung einer langen Batterielebensdauer.
2.2 Atmel ATtiny13
Als Beispiel für einen Mikrocontroller, der in eingebetteten Systemen Verwendung ndet, dient
der ATtiny13 der AVR-Familie. Dieser
µController
wurde ausgewählt, da er im Gegensatz zu
dem nachfolgend erwähnten AT32AP7000 eher im Low-End-Bereich angesiedelt ist. Low-End
bezieht sich hierbei zum einen auf die Kosten, denn ein solcher Chip ist im Handel schon
ab ca. 1,20 Euro zu haben, zum anderen bezieht es sich aber auch auf den sehr geringen
Stromverbrauch des Controllers. Die Namensbezeichnung tiny trägt er zurecht, denn seine
Ausmaÿe sind in etwa so groÿ wie
1
6 der 1-Eurocent-Münze. Folgende Eigenschaften zeichnen
diesen Controller aus:
•
6 programmierbare I/O-Lines
•
Bis zu 20 MHz (20 MIPS)
•
Geringer Stromverbrauch
•
1kB programmierbarer Flash Programmspeicher
•
64 Bytes EEPROM
•
64 kB SRAM
Es handelt sich bei diesem Mikrocontroller um ein
System on a Chip, da alle nötigen Komponen-
ten, wie z.B. Speicher und Taktgeber, auf einem Chip vereint sind. Über die sechs programmierbaren I/O-Lines können Signale eingelesen bzw. ausgegeben werden. Sofern in der Befehlsfolge
ausschlieÿlich Befehle vorkommen, die innerhalb eines Taktzyklusses abgearbeitet werden können, schat der Controller bei 20 MHz Taktfrequenz 20 MIPS. Als Befehlspeicher dient der
16
2.2 Atmel ATtiny13
2 MIKROCONTROLLER
1 kB groÿe, programmierbare Flash Speicher, der sowohl über die
von extern, als auch intern von der
µController
debugWIRE 4 -Schnittstelle
Unit, programmiert werden kann. Zusätzlich zu
dem 64 kB groÿen 8-Bit-Datenspeicher verfügt der Mikrocontroller über 64 Bytes EEPROM
Speicher, der als Datenspeicher organisiert ist, in welchem einzelne Bytes gespeichert werden
können.
2.2.1 Architektur
Abbildung 5: Architektur ATtiny13 [avr8]
4
Auf dem Chip bendliches Debug-System, das die Steuerung des Programmusses, die Ausführung von AVRBefehlen und die Programmierung der nicht-üchtigen Speicherbausteine ermöglicht
17
2.2 Atmel ATtiny13
Wie in Abb. 5 ersichtlich, stammt dieser
2 MIKROCONTROLLER
µController
aus der AVR Familie. Im linken Teil der
durch den 8-Bit-Datenbus getrennten Grak, bendet sich hauptsächlich die bereits beschriebene AVR-Kernarchitektur mit den getrennten Befehls- und Datenspeichern, dem 32x8-Bit
Registersatz inkl. der X-,Y- und Z-Register und der ALU zur Durchführung von arithmethischlogischen Operationen. Auf der rechten Seite bendet sich die weitere Peripherie, die diesen
Controller zu einem SoC werden lässt. Zu diesen Komponenten zählen u. A. der eigene Taktgeber, ein separater Timer sowie eine Einheit zu Verarbeitung von internen und externen Interrupts. Im unteren Bereich bendet sich der bi-direktionale Port B mit der Ansteuerung für die
Data Register Port B, das
den aktuellen Status der I/O-Pins wieder gibt und das Data Direction Register Port B, in dem
sechs I/O-Lines. Port B verfügt über zwei bereitgestellte Register
festgelegt werden kann, ob ein PIN zum Lesen oder Schreiben genutzt werden soll ([avr8] Seite
43).
2.2.2 Eignung für eingebettete Systeme
Der ausgewählte Mikrocontroller erfüllt einige der angesprochenen Anforderungen von eingebetteten Systemen in mehreren Hinsichten:
Chipgröÿe
Da der Chip sehr klein ist, kann er gut in eingebetteten Systemen eingesetzt
werden, die selbst wiederum minimalen Platz beanspruchen dürfen.
Kostenezienz
Wie angesprochen ist dieser Chip im Verhältnis zu seiner Funktionalität sehr
günstig und kann damit auch in Systemen eingesetzt werden, die sehr kostenezient sein
müssen.
Stromsparend
Um möglichst stromsparend arbeiten zu können, unterstützt der ATtiny13
drei unterschiedliche Stromsparmodi:
• Idle Mode
In diesem Modus wird nur die CPU abgeschaltet, d.h. die Taktsignale für die CPU und
für den Programmspeicher werden angehalten. Die CPU kann durch externe und interne
Interrupts wieder aktiviert werden.
• ADC Noise Reduction
Im Prinzip verhält sich dieser Modus wie der vorhergehende, mit dem Unterschied, dass
18
2.3 Atmel AVR32 (32 Bit)
2 MIKROCONTROLLER
nicht nur das Taktsignal für die CPU und den Flashspeicher angehalten werden, sondern
darüberhinaus auch das Signal für den I/O-Port.
• Power-down
In diesem Modus werden alle generierten Taktsignale angehalten. Das System kann erst
durch einen externen Interrupt wieder aktiviert werden.
Wiederherstellbarkeit
Die Wiederherstellbarkeit des Systems wird dadurch begünstigt, dass
es wenig Aufwand benötigt, den Programmspeicher neu zu programmieren (zu ashen). Dafür
In System Programming ) entwickelt. Diese Schnittstelle wird
wurde eine sog. ISP-Schnittstelle (
im Laufe dieses Berichts noch näher erläutert.
Codeezienz
Dadurch, dass es im Befehlssatz 1- und 2-Wort-Instruktionen gibt, kann der
Programmspeicher ezienter ausgenutzt werden, als wenn sich der Befehlssatz auf einen dieser
Instruktionstypen beschränken würde.
AVR32 ist eine 32 Bit RISC Architektur und wurde für High-Perfomance Anwendungen bei
gleichzeitig niedrigem Stromverbrauch und hoher Codedichte entworfen. Auÿer dem Namen
hat diese Architektur nicht viel mit der 8-Bit AVR Architektur gemeinsam - sie ist nicht binärkompatibel. Tatsächlich will Atmel mit Mikrocontrollern dieser neuen (erstmalig im Jahre
2006 veröentlichten) Architektur ein Konkurrenzprodukt zu den ARM-Mikrocontrollern etablieren, die häug in PDAs (Palm, Windows Mobile) oder Netzwerkgeräten wie Routern (Linksys
WRT54G oder NSLU2) zu nden sind.
Die AVR32 Architektur deniert
•
15x 32-bit Allzweckregister
•
Pipeline System
•
Interrupt / Ausnahmen mit Prioritäten
•
Optionale Sprungvorhersage
•
Befehlssatz mit Befehlsarten unterschiedlicher Länge
19
2 MIKROCONTROLLER
•
MMU oder MPU Unterstützung
•
Erweiterbarkeit: Java Unterstützung, Coprozessoren ...
•
Mikroarchitekturen: AVR32A / AVR32B (siehe Abschnitt 2.3.2)
2.3.1 Befehlssatz
Der Befehlssatz der AVR32 Architektur wird von Atmel als RISC-Befehlssatz (siehe auch Abschnitt 2.1.2 auf Seite 11) angegeben. Aber bis auf den Speicherzugri über separate
Load/Sto-
re -Befehle ist an diesem Befehlssatz sehr wenig reduced. Beispielsweise gibt es 67 verschiedene
Load/Store -Varianten, Befehle liegen als 16- und 32-Bit Typen vor und das Befehlsformat sieht
fast 60 verschiedene Möglichkeiten des Befehlsaufbaus vor.
Weiterhin gibt es verschiedene spezialisierte Befehle, die dem RISC-Grundsatz widersprechen bspw. Instruktionen für die Ansteuerung eines Coprozessors oder SIMD-Instruktionen um ganze
Datenpakete zu verarbeiten.
Beispiel: ADD
Im folgenden wird anhand der ADD-Anweisung ein Beispiel für die AVR32-
Befehle gezeigt. Diese Anweisung liegt in zwei verschiedenen Varianten vor, als kompakte 16Bit-Anweisung mit zwei Operanden sowie als erweiterte 32-Bit-Anweisung mit drei (bzw. vier)
Operanden. Je nach Anwendungsfall kann der Compiler sich so für eine dieser Instruktionen
entscheiden, um die Codegröÿe gering zu halten.
Abbildung 6: ADD Befehl: kompakt [avr32]
Abbildung 6 zeigt die kompakte ADD-Variante
auf den Inhalt des Registers
Rd
addiert.
20
ADD Rd, Rs.
Der Inhalt des Registers
Rs
wird
2 MIKROCONTROLLER
Abbildung 7: ADD Befehl: erweitert [avr32]
In Abbildung 7 ist dagegen die erweiterte 32-Bit-Variante
ADD Rd, Rx, Ry << sa
Diese ermöglicht das shiften (bitweise Verschieben) des Registers
die darauolgende Addition der Register
(kurz geschrieben:
Rx
und
Ry
Ry
zu sehen.
um 0 bis 3 Stellen und
mit Speicherung des Ergebnisses in
Rd
Rd=Rx+Rysa). Aufgrund seiner Komplexität ist dieser Befehl bereits ein
Beispiel für eine typische CISC-Operation!
2.3.2 Mikroarchitekturen
In der AVR32 Architekturbeschreibung werden sogenannte Mikroarchitekturen beschrieben (siehe Abschnitt 1.3 Microarchitectures in [avr32]), die Teile der Implementation zusammenfassen
und unterschiedliche Stufen von Performance, Chip-Gröÿe oder auch Stromverbrauch erreichen
sollen. Derzeit sind die beiden Mikroarchitekturen AVR32A und AVR32B deniert, die im folgenden beschrieben werden:
AVR32B
Die Mikroarchitektur AVR32B ist für Anwendungen gedacht, bei denen Interrupt-
Latenzzeiten eine wichtige Rolle spielen. Aus diesem Grund verfügt diese Architektur über dedizierte Register für Interrupts und Ausnahmebehandlung, die die Statusregister und RücksprungAdressen enthalten. Es müssen somit keine Stackzugrie erfolgen, was die Latenzzeiten reduziert.
Weiterhin existieren für die Kontexte Interrupt 0 bis Interrupt 3 (also der Zustand des Mikrocontrollers, während eine Interrupt-Routine für einen dieser vier Interrupts abgearbeitet wird)
separate Register. Diese Register sind sogenannte Shadow Register, da sie die normalen Allzweckregister überlagern. Durch Einsatz dieser zusätzlichen Register kann eine Interrupt-Routine
sofort ausgeführt werden, ohne vorher die vorhandenen Allzweckregister auf dem Stack zu sichern.
Ob und in welchem Maÿe ein shadowing, also ein Überlagern, stattndet, hängt von der
jeweiligen Implementation ab. Im Mikrocontroller AT32AP7000 werden beispielsweise nur im
21
2 MIKROCONTROLLER
INT3 Kontext die Hälfte der Register überlagert, weitere Register müssen auch hier über den
Stack gesichert werden (vgl. Abschnitt 2.3 Register le conguration in [avr32tech]).
AVR32A
Diese Mikroarchitektur zielt eher auf Anwendungen, bei denen ein niedriger Preis
und eventuell eine geringere Chipgröÿe eine Rolle spielen. Im Gegensatz zu AVR32B sind hier
keine zusätzlichen Register vorhanden, stattdessen werden die vorhandenen Registerinformationen sowie Rücksprunginformationen auf dem Stack gesichert.
2.3.3 Priorisierung
Um ein deniertes Laufzeitverhalten zu erreichen, deniert die AVR32 Architektur eine Priorisierung von Ereignissen (
events ) und eine Priorisierung von Ausführungsmodi (execution contexts ).
Ein Event ist beispielsweise ein ausgelöster Interrupt oder eine Ausnahme des Coprozessors
etc. Ein Ausführungsmodus ist bspw.
Interrupt0
für den Zustand während der Ausführung der
Service-Routine für den Interrupt 0.
Die Event-Priorisierung deniert das Verhalten bei gleichzeitig auftretenden Ereignissen. Dies
garantiert, dass wichtigere Ereignisse Vorrang vor weniger wichtigen haben.
Die Priorisierung der Ausführungsmodi dagegen legt fest, aus welchem Kontext die Ausführung
unterbrochen werden kann (bspw. kann die Ausführung einer Service Routine des Interrupts 3
nicht von Interrupt 2 unterbrochen werden).
Vgl. Kapitel 7 Event Processing in [avr32].
2.3.4 Java Erweiterung
Die AVR32 Architektur unterstützt optional das direkte Ausführen von Java Bytecode durch
den Einsatz eines Java Erweiterungsmoduls (
Java Extension Module JEM ).
Im direkten Vergleich zwischen den AVR32 RISC Befehlen und den Java Befehlen fällt auf, dass
sich sehr viele der Instruktionen gleichen bzw. ähneln (bspw.
iadd
für Integer-Addition oder
ifeq für einen bedingten Sprung). Die Grundidee ist also, dass eine separate Dekodiereinheit die
Java Befehle auf die vorhandene Hardware umsetzt. Das Umschalten zwischen RISC- und JavaCode wird über ein Flag im Statusregister des Controllers gesteuert. Da die virtuelle JVM keine
Register- sondern eine Stack-Maschine ist, werden die AVR32 Register im Java Modus genutzt,
um einen Stack zu implementieren bzw. zu beschleunigen. Für einen schnellen Zugri werden
22
2 MIKROCONTROLLER
jeweils 8 Elemente des Operanden- und Variablen-Stacks direkt einzelnen Registern zugewiesen
(vgl. Abschnitt 2.3 The RISC Register File and the Java Operand Stack in [avr32jvm]).
Leider können nicht alle Befehle des Java Befehlssatzes 1:1 ohne aufwendige Hardwareerweiterungen umgesetzt werden. Aus diesem Grund werden komplexere Java Instruktionen als normale
RISC Programme im Programmspeicher abgelegt. Der Java Decoder fängt diese Instruktionen ab, schaltet in den normalen RISC Modus zurück und führt das jeweilige Unterprogramm
aus. Für eine Auistung der Java-Instruktionen und ihrer Zuordnung Software/Hardware vgl.
Abschnitt 3.4 Java Bytecode Summary in [avr32jvm].
Abbildung 8: Java Erweiterung Software / Hardware [avr32jvm]
Abbildung 8 zeigt die Unterteilung Software vs. Hardware der virtuellen Java Maschine von
Atmel. Der graue Bereich zeigt den Teil, der komplexe Java-Instruktionen behandelt und in
Software implementiert ist. Das Extension Module auf der rechten Seite enthält die Hardwareanteile zur direkten Umsetzung der Befehle.
23
2 MIKROCONTROLLER
Abbildung 9: Java Ausführung [avr32jvm]
Ein Beispiel für die Ausführung von Java Code zeigt die Abbildung 9.
AVR32-Code (im Bild als C-Syntax dargestellt) wird ausgeführt und dann wird die Java Virtual
Machine (ajvm) wie ein normales Unterprogramm aufgerufen. Diese bereitet zuerst das System
auf das Ausführen von Java Code vor und ruft dann die eigentliche Java Methode auf (im Bild
der innerste Bereich). Diese wird daraufhin vom
Java Extension Module
ausgeführt, wobei für
die komplexen Instruktionen zurück in den normalen RISC Modus gesprungen wird (im Bild als
24
2 MIKROCONTROLLER
Trap routines bezeichnet). Am Ende der Methode setzt die umgebende Virtual Machine einige
Register zurück etc. und kehrt zur Ausführung des normalen Codes zurück. Vgl. Abschnitt 1.3
The AVR32 Java Virtual Machine in [avr32jvm].
2.3.5 Pipeline
Die allgemeine AVR32 Architektur deniert nur das Vorhandensein einer Pipeline. Die exakte
Funktion und die Anzahl der Pipeline-Stufen hängt von der jeweiligen Implementation ab. Im
folgenden wird die Pipeline (siehe Abb. 10) des AT32AP7000 Mikrocontrollers, der in den
späteren Kapiteln vorgestellt wird, kurz erläutert (vgl. Abschnitt 3 Pipeline in [avr32tech]).
Abbildung 10: AT32AP7000 Pipeline [avr32ap]
Prefetch
In der Prefetch Phase werden die Instruktionen aus dem Befehlscache geladen und
an den Befehlsdekoder ID weitergegeben. Zusätzlich werden in dieser Phase Sprungvorhersagen
getroen, wenn es sich bei der gelesenen Instruktion um eine entsprechende Anweisung handelt (dementsprechend muss in dieser Phase bereits eine Befehlsdekodierung stattnden). Falls
möglich, wird sogar die Sprunganweisung direkt gegen die Instruktion im Sprungziel ersetzt.
Als weitere Aufgabe der Prefetch Einheit werden einige Java-Instruktionspaare zu einer zusammengesetzten Instruktion für die Weitergabe an den ID verschmolzen.
Decode
Die Dekodierungseinheit (decode unit) generiert in der ID-Stufe (instruction decode)
für jeden Befehl die entsprechenden Kontrollsignale für die Befehlsausführung und kann eventuell
Exceptions auslösen (bspw. Illegal instruction usw.).
25
2 MIKROCONTROLLER
Auÿerdem wird hier ein Mapping der logischen Registeradressen auf die physikalischen Adressen
vorgenommen, je nach aktuellem Kontext. Siehe hierzu auch die Erläuterung zu shadowed
Registern im Abschnitt 2.3.2 auf Seite 21.
Die IS Stufe (instruction issue) liest Register aus und prüft die Pipeline auf Datenhemmnisse
(data hazards) und kann die Pipeline entsprechend anhalten, um diese Hemmnisse aufzulösen.
Weiterhin kann sie ein Forwarding zwischen den drei Unterpipelines aktivieren, um Daten aus
einer Pipeline in einer anderen frühzeitig bekanntzugeben.
ALU
Die Stufe A1 führt Adressberechnungen sowie Condition Checks aus (also Prüfungen
auf Gleichheit von Registerinhalten etc.) und ist für allgemeine arithmetische sowie logische
Operationen zuständig. Weiterhin wird hier geprüft, ob Sprungvorhersagen aus der Prefetch
Einheit korrekt waren. Falls nein, wird die Prefetch Einheit informiert, die Pipeline zu leeren
und die richtige Instruktion zu holen.
In der Stufe A2 werden die zusätzlichen Aktionen für sogenannte saturate-Befehle ausgeführt.
Bspw. die Anweisung SATADD.W addiert zwei 32 Bit Werte mit der Besonderheit, dass bei
einem Über- bzw. Unterlauf der maximal bzw. minimal mögliche Wert als Ergebniswert gesetzt
wird.
Multiply
Für die Multiply-Unterpipeline stellt die Dokumentation des AP7000 keine exakte
Dokumentation der beiden Stufen bereit. Allgemein werden hier Multiplikationen und Divisionen
durchgeführt und je nach Befehl auch eine dazugehörige Addition des Ergebnisses auf den Wert
eines Zielregisters. Je nach Gröÿe der Operanden sowie Art des Befehls sind u.U. zwei oder
mehr Takte für die Abarbeitung nötig.
Load/Store
Die Adressen für indizierte Zugrie auf den Speicher werden in der Stufe A1
der ALU Unterpipeline berechnet. Alle sonstigen Adressberechnung werden in der DA Stufe der
Load/Store Pipeline durchgeführt. In der D Stufe werden dann die eigentlichen Schreib- oder
Lesezugrie auf den Datencache durchgeführt.
Writeback
Die drei Unterpipelines teilen sich eine Writeback-Stufe mit drei Registern für das
Zurückschreiben von Daten.
26
2.4 Atmel AT32AP7000
2 MIKROCONTROLLER
2.3.6 MMU / MPU
Die AVR32 Architekturbeschreibung sieht den Einsatz einer
oder einer
Memory Management Unit (MMU)
Memory Protection Unit (MPU) für die Verwaltung der Speicherzugrie vor, die im
folgenden kurz erläutert werden (vgl. Abschnitt 4 Memory Management Unit und Abschnitt
5 Memory Protection Unit in [avr32]):
MMU
AVR32 speziziert einen 32-bit-adressierbaren virtuellen Speicher, der mit Hilfe einer
MMU auf 32-bit-adressierbaren physikalischen Speicher abgebildet wird. Virtueller Speicher
vereinfacht die Ausführung von mehreren Prozessen und erlaubt Zugrisbeschränkungen auf
einzelne Speicherbereiche.
MPU
Eine MPU ist eine einfachere Alternative zur MMU, die keine virtuelle Speicherverwal-
tung besitzt. Stattdessen erlaubt die MPU, den Speicher in (vom Benutzer denierbare) Bereiche aufzuteilen, denen jeweils andere Berechtigungsstufen zugewiesen werden können. Diese
Stufen bestehen aus Kombinationen der drei Zugrisarten lesen, schreiben oder ausführen.
2.4.1 Architektur
Als
Beispiel
für
die
AVR32
Architektur
wird
im
folgenden
der
Mikrocontroller
Atmel
AT32AP7000 kurz vorgestellt und in Hinblick auf die Eignung für eingebettete Systeme betrachtet. AP steht für
Application Processor
und soll auf den möglichen Einsatz für High-
digital signal processing ),
Performance Anwendungen hindeuten, wie DSP (
Multimedia und
Wireless-Anwendungen. Dieser Mikrocontroller steht in Bezug auf Leistung und Flexibilität am
oberen Ende von Atmels Produktpalette und stellt ein Konkurrenzprodukt zu den (bspw. in
5
PDAs und Smartphones) weit verbreiteten ARM Prozessoren dar . .
5
Siehe Atmel AVR32 AP Produktvorstellung und Benchmarks unter http://www.atmel.com/products/
avr32/ap7/ap7_3.asp?family_id=682
27
2 MIKROCONTROLLER
Abbildung 11: AT32AP7000 Übersicht [embnews]
Die grobe Übersicht über den Aufbau des AT32AP7000 in Abbildung 11 zeigt die umfangreichen
Möglichkeiten, verschiedenste Arten von Peripherie und Speicher anzuschlieÿen. Eine kurze
Übersicht über einige in der Abbildung verwendete Kürzel:
•
VMU: Video Management Unit
•
OCD: On Chip Debugging (entspricht JTAG)
•
EBI: External Bus Interface
•
TWI: Two-Wire-Interface (entspricht I C)
•
PWM: Pulsweitenmodulation (Pulse-width Modulation)
2
28
•
SPI: Serial Peripheral Interface
•
SSC: Synchronous Serial Controller
•
TC: Timer / Counter
•
MCI: Multimedia Card Interface
2 MIKROCONTROLLER
Um ein paar Funktionen zu nennen, bietet der Chip bspw. die Möglichkeit der EthernetKommunikation über zwei Schnittstellen, einen Anschluss für eine LC-Anzeige oder auch eine
MCI erlaubt die direkte Anbindung von diversen Arten von FlashSpeichern wie bspw. CompactFlash (CF) oder SecureDigital (SD).
USB 2.0 Schnittstelle. Das
Weiterhin ist ein Pixel-Coprozessor onboard, welcher bspw. Unterstützung für bestimmte Berechnungen bei der MPEG4 Dekodierung bietet.
Detaillierte Erläuterungen der vielen Controller und Schnittstellen nden sich in [avr32ap].
2.4.2 Eignung für eingebettete Systeme
Ezienz
Bei der Entwicklung der AVR32 Architektur wurde darauf geachtet, mit möglichst
wenig Taktzyklen möglichst viele Daten zu verarbeiten. Der Prozessor kann also trotz hoher
Performance bei einer vergleichsweise niedrigen Taktfrequenz betrieben werden. Dies verringert
den Stromverbrauch.
6 gibt Atmel ein Szenario an, bei dem der AVR32 AP7000 einen QVGA
Als Praxisbeispiel
(320x240 Pixel) MPEG4 Datenstrom, der über den eingebetteten 100 MBit Ethernet-Controller
empfangen wird, mit 30 Bildern pro Sekunde dekodiert und auf einem angeschlossenen QVGA
TFT LCD ausgibt, während im Hintergrund ein angepasstes Linux System läuft. Der Mikrocontroller begnügt sich hierbei mit einem Systemtakt von 100 MHz und einem Stromverbrauch
von 250mW.
Weiterhin gibt Atmel an, dass für MPEG2 Dekodierung in PAL Auösung weniger als 75 MHz
und für reine MP3 Dekodierung nur 15 MHz Systemtakt ausreichend sind.
Diese Werte sind allerdings kritisch zu betrachten, da der Mikrocontroller mit spezieller Hardware ausgestattet ist (Pixel Coprozessor), die insbesondere für die Bewältigung dieser Aufgaben
ausgelegt ist.
6
http://atmel.com/products/AVR32/ap7/ap7_6.asp
29
2 MIKROCONTROLLER
Der AVR32 AP7000 deniert zusätzlich verschiedene Sleep-Zustände, um den Stromverbrauch
zu senken:
•
Idle : Die CPU ist angehalten, der Rest des Chips arbeitet normal weiter. Die CPU wird
durch jeden Interrupt oder durch ein Signal am WAKE_N Pin wieder aufgeweckt.
•
Frozen: Die CPU und alle Module am HighSpeedBus sind angehalten, aber die sonstige
Peripherie arbeitet normal weiter. Das System wird durch Interrupts vom Peripherie-Bus
oder durch ein Signal am WAKE_N Pin wieder aufgeweckt.
•
Standby : Alle synchronen Taktgeber werden angehalten, aber Oszillatoren und PLLs laufen weiter und erlauben ein schnelles Aufwachen aus dem Standby-Modus. Das Signal für
das Aufwachen wird entweder von der Echtzeituhr, einem externen Interrupt oder durch
den WAKE_N Pin ausgelöst.
•
Stop: Wie Standby, aber weitere (nicht alle) Oszillatoren und PLLs sind deaktiviert.
•
Static : Alle Oszillatoren und Taktgeber sind angehalten. Externe Interrupts oder ein Signal
am WAKE_N Pin können das System wieder aufwecken.
Der Befehlssatz der AVR32 Architektur wurde unter dem Gesichtspunkt einer geringen Codegröÿe bzw. einer hohen Codedichte entworfen. Beispielsweise gibt es für einige Instruktionen
mit Konstanten zwei Maschinenbefehle - eine kompakte und eine erweiterte Form. Die kompakte Form kann für kleine Konstanten genutzt werden und die erweiterte für groÿe Konstanten.
Der Compiler kann bei der Übersetzung immer die optimale Instruktion wählen und so die
Codegröÿe klein halten. Ein weiteres Beispiel sind häug benutzte Befehle (wie ADD), die es
in kompakten Varianten mit zwei sowie erweiterten Varianten mit drei Operanden gibt. Die
erweiterten Instruktionen ermöglichen in einem Zyklus bspw. sowohl eine Addition als auch eine
Daten-Bewegung (also Addition zweier Register und Ergebnis in drittem Register sichern).
Detaillierte Erläuterungen des Befehlssatzes nden sich in [avr32] ab Abschnitt 8.3 Instruction
Set Summary.
Varianten
Die AVR32 Architektur sieht optionale bzw. gegeneinander austauschbare Anteile
vor (bspw. Mikroarchitekturen AVR32A vs. AVR32B; Java Extension etc.). Dadurch kann eine
Variante des Mikroprozessors gewählt werden, die am besten zum geplanten Einsatzgebiet passt
ohne unnützen Ballast mitzuführen. Dies spart Platz und verringert u.U. den Stromverbrauch.
7 des AVR32 (AVR32 AP7000, AP7001 und AP7002)
Praktisch sind derzeit drei Varianten
7
zu Details der versch. Varianten siehe auch Produktübersicht unter http://atmel.com/dyn/products/
param_table.asp?family_id=682&OrderBy=part_no&Direction=ASC
30
2 MIKROCONTROLLER
erhältlich, die sich nur durch die Zahl der I/O Pins und des Ethernet-Anteils unterscheiden.
Der AP7000, der als maximale Ausbaustufe angesehen werden kann, ist aktuell im Handel für
ca. 20,- Euro erhältlich. Eine komplette Referenzimplementation des AP7000 ist als
NGW100 8
für ca. 80,- Euro zu kaufen und wird ausgeliefert mit zwei Ethernet-Schnittstellen, 32 MB
SDRAM, 16 MB Flash, Adapter für SD oder MMC Karten, USB Anschluss, JTAG Schnittstelle
sowie diversen I/O-Pins und LEDs. Vorinstalliert ist ein als Netzwerk-Router angepasstes LinuxSystem.
Eine Variante des AVR32 (AVR32 UC3) mit der Mikroarchitektur AVR32A, die für niedrigere
Anforderungen bei kleinerem Preis gedacht ist, bendet sich derzeit vor der oziellen Auslieferung.
Wartbarkeit / Verfügbarkeit
Die AVR32 Architektur unterstützt (im Gegensatz zu einfa-
cheren Mikrocontrollern) explizit Betriebssysteme, bspw. durch spezielle Instruktionen (normale
Sprünge mit ACALL vs. System-Sprünge mit SCALL, die für den Aufruf von Routinen eines
Betriebssystem verwendet werden können). Mit einer Memory Management Unit (MMU), die in
der Mikroarchitektur AVR32B deniert wird, ist auch die Portierung von komplexeren Systemen
wie Linux möglich.
Durch den Einsatz eines portierten, in der Praxis bewährten Betriebssystems und damit der
Verwendung von vorhandener und entsprechend getesteter Software wird die Stabilität erhöht
und der Aufwand sowie die Kosten für neue Systeme vermindert.
Echtzeitanforderungen
Durch das Priorisierungssystem (siehe Abschnitt 2.3.3 auf Seite 22)
ist das Laufzeitverhalten exakt festgelegt und Systementwickler können die Interruptleitungen
entsprechend den eigenen Anforderungen nutzen und Routinen in hoch priorisierten Kontexten
laufen lassen.
Bezüglich Eignung für Echtzeitanforderungen lässt sich hier weiterhin die Möglichkeit auühren,
9
ein Echtzeit-Betriebssystem (bspw. embOS der Firma Segger Mikrocontroller GmbH ) einzusetzen, welches ein exaktes Zeitverhalten garantiert.
8
9
http://www.avrfreaks.net/wiki/index.php/Category:NGW100
http://www.segger.com/embos.html
31
3 SOFTWARE
3 Software
3.1 Entwicklung
Programme für Mikrocontroller wie die vorgestellten AVR Varianten können auf unterschiedliche
Arten geschrieben werden.
Assembler
Assembler, also die Kodierung des Programms direkt mit dem Befehlssatz des
Zielsystems, erlaubt dem Entwickler die volle Kontrolle darüber, was auf dem Mikrocontroller
abläuft. Diese Art der Entwicklung ist jedoch im Vergleich mit Hochsprachen aufwendiger,
schwieriger zu warten und wird daher nur in kleineren Anwendungen oder aus Ezienzgründen
in Teilbereichen der Software eingesetzt.
Für die AVR 8-Bit Architektur wird von Atmel das sogenannte
AVR-Studio 10 als Entwicklungs-
umgebung (Freeware) für Windows angeboten, das neben dem Assembler auch einen Simulator
enthält.
Für Linux gibt es mehrere freie AVR Assembler wie etwa
lässt sich mit der Software
C
simulavr
avra11 .
Simulation und Debugging
12 in Verbindung mit dem Debugger
gdb13 vornehmen.
Neben Assembler ist C die wohl am häugsten eingesetzte Programmiersprache bei der
Softwareentwicklung für Mikrocontroller. Die Sprache ist hoch genug, um leicht verständlichen und somit wartbaren Code zu erzeugen - bietet aber noch genug Hardwarenähe, um die
Ressourcen des Controllers direkt und ezient zu nutzen.
Für die Entwicklung in C unterstützt die GNU Compiler Collection (
gcc
bzw.
gcc-avr 14 )
so-
wohl die AVR- als auch die AVR32-Architektur. Eine Windows-Variante im Komplettpaket mit
weiteren benötigten Werkzeuge ist als
WinAVR 15 im Internet zu nden.
Für AVR32 hat Atmel ein Paket aus der Eclipse IDE und den GNU Werkzeugen als
Studio
16 mit Unterstützung für Windows und Linux veröentlicht.
10
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2725
http://avra.sourceforge.net/
12
http://www.nongnu.org/simulavr/
13
http://sourceware.org/gdb/
14
http://www.gnu.org/software/gcc/
15
http://winavr.sourceforge.net/
16
http://www.atmel.com/dyn/products/tools.asp?family_id=682
11
32
AVR32
3.2 ISP und JTAG
Weitere Sprachen
3 SOFTWARE
Mikrocontroller können neben C und Assembler auch in weiteren Sprachen
programmiert werden.
In Bezug auf die AVR Architektur muss hier der kommerzielle Basic-Compiler
BASCOM
der
17 Electronics besonders erwähnt werden. Dieser bietet einen sehr einfachen Einstieg
Firma MCS
in die Softwareentwicklung für Mikrocontroller und enthält bereits viele Sprachkonstrukte (bspw.
direkte Unterstützung von I2C-Bussen) für die schnelle Erstellung von Programmen.
Java wurde bereits bei der Vorstellung der AVR32 Java-Erweiterung erwähnt. Dies ist aber nicht
die einzige Zielumgebung für diese Programmiersprache:
NanoVM 18 ist eine JVM Implementierung für Atmels AVR Mega8 und Mega32 Mikrocontroller, die komplett in deren 8 kByte Flash ROM untergebracht wird. Diese wurde entwickelt,
um den mobilen Lehr-Roboter
programmieren.
NanoVM
ASURO 19
des Instituts für Luft- und Raumfahrt einfacher zu
unterstützt nur einen kleinen Teil der Java Spezikation und das
Programmieren mit Java und
NanoVM
ist weniger exibel und auch weniger performant als
mit C oder Assembler. Der Vorteil ist aber darin zu sehen, dass die JVM sämtliche Hardwarespezischen Details vor dem Entwickler verbirgt und dieser plattformunabhängigen Code mit
Zugri auf einfach strukturierte Schnittstellen schreiben und sich so mehr auf das was als auf
das wie konzentrieren kann: gerade zu Lehrzwecken und für den Einstieg in die Entwicklung
ein groÿer Vorteil.
Eine weitere interessante (Nicht-Atmel-)Hardwareumgebung für die Java-Entwicklung ist die Experimentierplattform
Sun SPOT 20 der Firma Sun Microsystems; ein auf einem ARM Prozessor
basierendes, batteriebetriebenes Gerät mit Funktechnologie und verschiedensten Sensoren.
3.2 ISP und JTAG
Für die eigentliche Programmierung eines Mikrocontrollers, also den Vorgang, Software auf
den internen Speicher zu laden, gibt es hauptsächlich zwei verschiedene Möglichkeiten (weitere
Varianten sind Hersteller- oder Schaltungsabhängig):
In-System Programmierung
Für die sogenannte In-System Programmierung (ISP) bietet
der Mikrocontroller eine Schnittstelle an, die es ermöglicht, seinen internen Flash-Speicher
17
http://www.mcselec.com/
http://www.harbaum.org/till/nanovm/index.shtml
19
http://www.dlr.de/rm-neu/desktopdefault.aspx/tabid-3848/6062_read-9032/
20
http://www.sunspotworld.com/
18
33
3.3 Betriebssysteme
3 SOFTWARE
zu beschreiben (je nach Mikrocontroller kann auch die Möglichkeit gegeben sein, den Speicher
auszulesen). Gewöhnlich wird diese Schnittstelle auf der Zielschaltung bspw. über eine Stiftleiste
nach auÿen geführt. Dadurch kann der Mikrocontroller in-System programmiert werden - er
muss also nicht mehr aus der Schaltung entfernt werden, um ihn zu programmieren. Siehe auch
[wikiisp].
ISP Programmiergeräte für AVR Mikrocontroller sind kostengünstig und als reine Adapter für
den Parallelport bereits ab ca. 10,- Euro erhältlich. Programmiergeräte mit USB Schnittstelle
der Firma Atmel sind für ca. 40,- Euro zu beziehen; diese bieten den Vorteil, dass direkt aus
der Software AVR Studio die Programmierung des Mikrocontrollers erfolgen kann.
Die derzeit erhältlichen Mikrocontroller der AVR32 Architektur bieten leider keine ISP Schnittstelle sondern werden entweder über die JTAG Schnittstelle oder über einen vorinstallierten
Bootloader beschrieben.
JTAG Schnittstelle
Die Alternative zur ISP Schnittstelle lautet JTAG (Joint Test Action
Group). JTAG bezieht sich auf den Standard IEEE-Standard 1149.1, der ein Verfahren für
das Testen und Debugging von elektronischer Hardware beschreibt. Im Gegensatz zu ISP ist
hier also nicht das reine Programmieren des angebundenen Speichers möglich, sondern auch
das Testen laufender Anwendungen (On-Chip Debugging OCD) direkt im Zielsystem möglich.
Ähnlich dem Debugging bei PC Software kann Befehl für Befehl nachvollzogen werden, was auf
dem Mikrocontroller ausgeführt wird. Weiterhin können Register und Speicherinhalte geprüft
werden. Dies erleichtert das Testen und die Fehlersuche für den Entwickler - insbesondere,
wenn Eigenschaften der Zielhardware nicht im Simulator dargestellt werden können (bspw.
angeschlossene Peripheriegeräte). Siehe auch [wikijtag].
Geräte für die Anbindung an JTAG Schnittstellen sind technisch aufwendiger zu realisieren als
Programmiergeräte für ISP. Dies schlägt sich auch im Preis nieder - das aktuelle JTAG Entwicklungstool
JTAG ICE MKII
der Firma Atmel ist für knapp 300,- Euro im Handel erhältlich.
3.3 Betriebssysteme
Das Feld der Betriebssysteme für eingebettete Systeme ist sehr groÿ und wird hier nur kurz
angerissen.
34
3.3 Betriebssysteme
3 SOFTWARE
Abbildung 12: Umfrage embedded.com [embos]
Laut einer Umfrage durch
embedded.com
aus dem Jahre 2006 (siehe Abbildung 12) wird in
weniger als 30% der eingebetteten Systeme direkt auf der Hardware entwickelt - über 70% der
befragten Firmen setzen auf ihren Systemen ein Betriebssystem ein. Dementsprechend wichtig
und groÿ ist auch der Markt der Betriebssysteme für eingebettete Systeme, von denen ein Groÿteil als
Realtime OS (Echtzeit-Betriebssystem, welches ein striktes Einhalten von speziziertem
Zeitverhalten aufweist) beworben wird.
Das, laut embedded.com, am häugsten eingesetzte (kommerzielle) OS ist
VxWorks der Firma
Wind River Systems mit einem Anteil von ca. 25%, mit einigem Abstand gefolgt von den beiden
Microsoft Systemen
XP Embedded, Windows CE
35
und diversen Linux Distributionen.
Literaturverzeichnis
[esmar]
Peter Marwedel: Eingebettete Systeme, Springer Verlag Berlin, 2007
[baswt]
A. Spillner, T. Linz: Basiswissen Softwaretest, dpunkt.Verlag Heidelberg, 2007
[wikijtag]
Wikipedia Deutschland: Joint Test Action Group
http://de.wikipedia.org/wiki/Joint_Test_Action_Group
[wikiisp]
Wikipedia Deutschland: In-System-Programmierung, 2007
http://de.wikipedia.org/wiki/In-System-Programmierung
[avr32ap]
Atmel Corporation: AT32AP7000 Preliminary, 2007
http://atmel.com/dyn/resources/prod_documents/doc32003.pdf
[avr8]
Atmel Corporation: ATtiny13, 2007
http://www.atmel.com/dyn/resources/prod_documents/doc2535.pdf
[avr8is]
Atmel Corporation: AVR Instruction Set, 2007
[avr32]
Atmel Corporation: AVR32 Architecture Document, 2007
http://atmel.com/dyn/resources/prod_documents/doc32000.pdf
[avr32jvm]
Atmel Corporation: AVR32 Java Technical Reference, 2007
[avr32tech] Atmel Corporation: AVR32 AP Technical Reference Manual, 2007
[cz]
Urlich Hottelet: Eingebettete Systeme prägen das Auto der Zukunft, Online
Artikel der Computer Zeitung, 28.11.2007
http://computerzeitung.de/loader?path=/articles/2007049/31326048_
ha_CZ.html&art=/articles/2007049/31326048_ha_CZ.html&thes=8002,
9788,9801,9789,9790,9791,9792,9794,9795,9797,9846,9796&pid=
ee54f3c7-0de1-40f5-bb23-2cfdf022aee5&page=1
[embos]
Operating Systems On The Rise, Online Artikel embedded.com, 21.6.2006
36
http://www.embedded.com/columns/surveys/187203732?_requestid=
636383
[embnews]
AP7000 AVR32-based SoCs - Atmel, Online Artikel embedded-systems.net,
29.08.2006
http://embedded-system.net/avr32-based-socs-atmel-ap7000.html
37

embedded architectures am Beispiel AVR - Weblearn

Transcrição

Documentos relacionados

AVR Projekte - der

1. Teil 10/04/08

Karten personalisieren – Welche Technik steckt dahinter

Elektronische Ladenwaage XS 100

Mikrocontroller gesteuerter 3-Kanal-Dimmer

AVR KlimaWärmeService

Robot Kit NIBO burger

HARMAN KARDON® AVR 435/AVR 635

Hochzeitsplaner - ABC

Vertrag (2 fach)

Handbuch IR - Sensor