Software ubiquitärer Systeme: 2. Übung

technische universität
dortmund
Software ubiquitärer Systeme
2. Übung
http://ess.cs.uni-dortmund.de/DE/Teaching/SS2014/SuS
Christoph Borchert
http://ess.cs.tu-dortmund.de/~chb
AG Eingebettete Systemsoftware
Informatik 12, TU Dortmund
technische universität
dortmund
embedded system
software
Überblick
●
C++ Crashkurs (Teil 2)
●
MSP430 Architektur
●
Button-Ansteuerung
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
C++-Konzepte (Crashkurs Teil 2)
●
Übersetzungs- und Bindevorgang
●
Präprozessor
●
Vererbung und Mehrfachvererbung
●
Virtuelle Funktionen
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
C++ - Übersetzungsprozess
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Sourcecode - Präprozessor
●
●
Zwei Dateiendungen:
–
.cc — C++ Source Code
–
.h — „Header Files“ mit Definitionen von Datentypen,
Konstanten, Präprozessor-Makros etc.
Die Endungen sind Konvention, aber nicht zwingend
–
●
oft z.B. auch .cpp, .hpp o.ä.
Header-Files werden mit Hilfe des Präprozessors textuell
in .cc-Files integriert
–
#include – Anweisung:
●
#include <iostream> für System-Headerfiles
●
#include "device.h" für eigene Headerfiles
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Sourcecode - Präprozessor
●
Weitere Präprozessorfunktionen:
–
Makrodefinition, z.B. für Konstanten:
●
ohne Semikolon am Ende!
#define pi 3.1415926
#define LCD_BASE 0x0a00
–
Bedingte Übersetzung:
#ifdef DEBUG
…
#endif
●
#ifndef LCD_BASE
#define LCD_BASE 0x0a000
#endif
Der Präprozessor expandiert Makros im Source Code,
fügt Header-Files ein und erzeugt eine neue Textdatei,
die der Compiler vorgesetzt bekommt
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Sourcecode - Präprozessor
●
Wichtige Anwendung für #define und #ifndef:
–
Verhindern von mehrfacher Inklusion von
Header-Dateien
●
Header-Dateien dürfen wiederum Header-Dateien
inkludieren -> Ringschluss...
#ifndef LCD_H
#define LCD_H
class LCD
{
/* Hier muesst ihr selbst Code vervollstaendigen */
};
#endif
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Sourcecode - Compiler
●
Erzeugt aus vom Präprozessor vorverarbeitetem Source
Code eine Objektdatei (.o)
–
●
●
Diese ist i.a. nicht direkt ausführbar, da noch Referenzen auf
Funktionen oder Variablen in anderen Objektdateien enthalten
sein können
Der Compiler überprüft den Source Code auf
Syntaxfehler und erzeugt ggf.
–
Fehlermeldungen (errors)
–
Warnungen (warnings)
Eine Objektdatei wird nur bei fehlerfreier Übersetzung
erzeugt
–
Warnungen führen nicht zum Abbruch des
Übersetzungsvorgangs!
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Sourcecode - Linker
●
●
Fasst eine Menge an Objektdateien (.o) sowie ggf.
Libraries (.a, .so) zu einem ausführbaren Programm
zusammen:
–
Auflösung von Referenzen
–
Sortierung der einzelnen Teile der Objektdateien im
Speicherabbild der ausführbaren Datei
„Normalerweise“ gibt es zwei Link-Modi:
–
dynamisch: Libraries werden erst zur Zeit der
Ausführung des Programms zum Objektcode geladen
und Referenzen darin aufgelöst
–
statisch: Libraries werden zur Link-Zeit in ein komplett
ausführbares Programm integriert
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Einfache Vererbung
●
Klasse Derived erbt von Klasse Base
●
Vererbungsoperator “:” (entspricht “extends” in Java)
Base
Derived
Base.h:
Derived.h
class Base {
…
};
#include "Base.h"
class Derived : public Base {
public:
Derived();
~Derived();
};
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Mehrfachvererbung
●
Klasse Derived erbt von den
Klassen Base1 und Base2:
Base2
Base1
Derived
Derived.h:
#include "Base1.h"
#include "Base2.h"
class Derived : public Base1, public Base2 {
public:
Derived();
~Derived();
};
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Vererbung: Konstruktoren
●
Abgeleitete Klassen müssen im Konstruktor immer
zuerst die Basisklassenkonstruktoren aufrufen
–
Implizit bei Basisklassenkonstruktoren ohne Parameter
–
Explizit: Initialisierungsliste
●
Wird vor dem eigentlichen Konstruktor ausgeführt
#include "Base1.h"
#include "Base2.h"
class Derived : public Base1, public Base2 {
public:
Derived() : Base1(42), Base2(4711) {}
};
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Virtuelle Funktionen
●
●
Virtuelle Funktionen sind Funktionen einer Basisklasse.
Eine abgeleitete Klasse kann sie überschreiben und
übernimmt damit die Ausführung der Funktion für ihre
Klassenmitglieder.
–
●
●
das funktioniert auch mit nicht virtuellen Klassen...
Das Besondere an virtuellen Funktionen ist, dass das
Objekt selbst weiss, zu welcher abgeleiteten Klasse es
gehört und seine zugehörige Klassenfunktion ruft.
Nicht jede Funktion ist standardmäßig virtuell, es muss
explizit das Schlüsselwort „virtual“ verwendet werden!
(im Gegensatz zu Java)
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Virtuelle Funktionen
#include <iostream>
●
class base {
public:
virtual void display() {
cout << ”Base”;
}
};
Ausgabe:
„Derived“
●
ohne das virtual vor
void base::display():
„Base“
class derived : public base {
public:
void display() {
cout << ”Derived”;
}
};
void main() {
base *ptr = new derived;
ptr->display();
}
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Virtuelle Destruktoren
●
●
Es gibt eine Faustregel, die besagt, dass jede Klasse mit
virtuellen Funktionen auch einen virtuellen Destruktor
haben soll.
Da ein nicht virtueller Destruktor nicht gewährleistet,
dass abgeleitete Klassen ordnungsgemäß abgebaut
werden, kann ein nicht virtueller Destruktor sogar so
interpretiert werden, dass der Autor ein Ableiten seiner
Klasse nicht vorgesehen hat und wohl auch nicht
empfiehlt.
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Überblick
●
C++ Crashkurs (Teil 2)
●
MSP430 Architektur
●
Button-Ansteuerung
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
EZ430-Chronos
●
Entwicklungskit von Texas Instruments
–
Display mit 7-Segment- und Spezialanzeigen
–
5 Bedienknöpfe
–
Sensoren für Luftdruck, 3-Achsen-Beschleunigung, Temperatur
und Batteriespannung
–
„RF“-Funk im 868MHz-Frequenzband (lizenzfrei)
–
TI CC430F6137 System-on-Chip
●
16-Bit-Mikrocontroller (MSP430) und Funkchip (CC1101)
●
27 MHz (max.), bei uns mit 12 MHz
●
32 KiB Flash, 4 KiB RAM
●
Peripherie: A/D, D/A, SPI, I2C, Timer, UART, Watchdog, ...
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
System-on-Chip (hier: msp430f1611)
●
Alle Komponenten
auf einem Stück
Silizium
→ geringe
Produktionskosten
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
CC430F6137 µController
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430 Speicheraufbau
●
Ein Speicherbereich
–
RAM
–
Flash
–
Peripherie
●
z.B. LCD
(0x0a00...)
●
Adressierung in
Bytes (8 Bit) oder
Words (16 Bit)
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430-Architektur (CPU)
●
●
16 Register zu je 16 Bit
–
R0: Program Counter (PC)
–
R1: Stack Pointer (SP)
–
R2: Status Register (SR)
–
R3: Constant Generator (CG2)
–
R4–R15: Allzweckregister
16-Bit ALU
–
●
16-Bit-Adressen
–
●
Zusätzlich: Multiplikatoreinheit
RAM, Flash, Memory-Mapped I/O
MSP430X: 20 Bit Adressen/Register
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430 Instruction Set Architecture
●
27 CPU Instruktionen
–
24 „emulierte“ Instruktionen (Assembler Makros)
●
3 stufige Pipeline (Fetch/Decode/Execute)
●
7 Adressierungsarten
●
–
Bestimmen Instruktionslänge (16, 32, 48 Bit)
–
Bestimmen Taktzyklen (1-6) der Instruktionen
RISC (Reduced Instruction Set Computing)
–
Warum?
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430-Instruktionsformate
●
Jump Instruktionen
●
Single-Operand (Format II) Instruktionen
●
Double-Operand (Format I) Instruktionen
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430-Adressierungsarten
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
MSP430-Betriebsmodi
160 µA/MHz
1.0 µA
2.0 µA
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Überblick
●
C++ Crashkurs (Teil 2)
●
MSP430 Architektur
●
Button-Ansteuerung
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
EZ430-Chronos: Buttons
●
●
Vier frei definierbare Buttons
–
„*“, „#“, „Up“, „Down“
–
An GPIO-Pins angeschlossen
–
Nicht entprellt
Der „Light“-Button startet das
Hauptprogramm bzw. den
Bootloader
–
Darf nicht verändert werden!
Software ubiquitärer Systeme: 2. Übung
technische universität
dortmund
embedded system
software
Pull-Up vs. Pull-Down
Software ubiquitärer Systeme: 2. Übung