Datenspeicherung unter Echtzeit im Embedded

Datenspeicherung unter Echtzeit im Embedded System einer
Bohrlochsonde
Bachelorarbeit
für die Prüfung zum
Bachelor of Engineering
des Studienganges Informationstechnik
an der
Dualen Hochschule Baden-Württemberg Karlsruhe
von
Daniel Schembri
6. September 2013
Matrikelnummer:
Kurs:
Ausbildungsfirma:
Betreuer:
Zweitbetreuer:
6048889
TiT10
Karlsruher Institut für Technlogie
Dipl. Ing. Stefan Dietze
Dipl. Ing. Bernhard Merkel
Bachelorarbeit
Daniel Schembri
Erklärung
gemäß § 5 (2) der „Studien- und Prüfungsordnung DHBW Technik“ vom
18. Mai 2009.
Ich habe die vorliegende Arbeit selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel verwendet.
Ort, Datum
Unterschrift
B
Abstract
Diese Bachelorarbeit behandelt die Verarbeitung und Speicherung von Messund Bilddaten einer Bohrlochsonde unter Echtzeit. Die Sonde befindet sich dabei
4000m unter der Oberfläche, bei einer Umgebungstemperatur von bis zu 165°C
und 400Bar Druck. Die Bilddaten von Kameras, Messdaten und Statusmeldungen
sollen zur späteren Analyse auf einem Massenspeicher, zeitlich rekonstruierbar,
archiviert werden. Dazu ist es notwendig ein Verfahren zu entwerfen, mit dem
die Daten zuverlässig und bei ausreichender Performance gespeichert werden.
Dabei müssen verschiedene Anwendungsfälle und Szenarien der Messfahrt berücksichtigt werden. Das System wird zum Schluss getestet und bewertet.
Abstract
The duty of this bachelorthesis is to process and record measurment and videodata with realtime treatment in a borehole inspection vehicle. The vehicle is 4000m
down in the waterfiled pipe with temperature of 165°C and under pressure of
400Bar. The videodata, measurementdata and statusmessages has to been saved on a mass storage, mind the correct timestamp. Therefore it is necessary to
develop a performant and reliable method. Besides different usecases has to be
considered. At last the systemparts will be tested and evaluated.
Bachelorarbeit
Daniel Schembri
Inhaltsverzeichnis
Inhaltsverzeichnis
II
Abbildungsverzeichnis
IV
Abkürzungsverzeichnis
VII
1 Einleitung
1
2 Stand der Technik
2
3 Aufgabenstellung und Zielsetzung
6
4 Verbesserung des SD-Karten-Controllers
4.1 Einführung SPI-Bus mit SD-Karten
10
. . . . . . . . . . . . . . . . . 10
4.1.1 SPI-Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 SD-Karten
. . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Der SPI-Memory-Controller-Core von Gaisler™ . . . . . . . . . . . 16
4.2.1 Der Aufbau des Cores . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3 Erweiterung der Statemachine für SDHC-Karten . . . . . . . . . . 23
5 Entwicklung von Softwaretreibern für SD-Karten
29
5.1 SPI-SD Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Das UMSG-Datenformat . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1 Das UMSGV-Bilddatenformat . . . . . . . . . . . . . . . . . 37
5.3 Messdaten-Filesystem . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.1 Messfahrtinformationen im Header . . . . . . . . . . . . . . 38
5.3.2 Recovery der Messdaten . . . . . . . . . . . . . . . . . . . 38
II
Bachelorarbeit
Daniel Schembri
6 Messdatenverarbeitung in der Sonde
39
6.0.3 Der Begriff Echtzeit . . . . . . . . . . . . . . . . . . . . . . 39
6.1 Einführung in das Echzeitbetriebssystem eCos . . . . . . . . . . . 40
6.1.1 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.2 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.2 Implementierung des Zeitstempelverfahrens . . . . . . . . . . . . . 42
6.3 Systemaufbau und Prozesse im HiTES . . . . . . . . . . . . . . . 44
6.4 Tests der gesamten HiTES-Firmware . . . . . . . . . . . . . . . . 44
6.4.1 Geschwindigkeits-Test . . . . . . . . . . . . . . . . . . . . 45
6.4.2 Filesystem-Test . . . . . . . . . . . . . . . . . . . . . . . . 46
6.4.3 Multithreading-Test . . . . . . . . . . . . . . . . . . . . . . 46
7 Fazit und Ausblick
48
8 Literatur- und Quellenverzeichnis
49
9 Anhang
54
III
Bachelorarbeit
Daniel Schembri
Abbildungsverzeichnis
2.1 HiTES verbunden mit dem Bedienstand[internes Plakat abgeändert]
2
2.2 Der Innere Aufbau des FPGAS . . . . . . . . . . . . . . . . . . . .
4
2.3 Die HiTES-Platine. Vorder- und Rückseite[7]
5
. . . . . . . . . . . .
4.1 SPI-Master und Slaves . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 SPI Timing Diagram CHPA = 0 [13 Kap.8.3.2] . . . . . . . . . . . . 12
4.3 SPI Timing Diagram CHPA = 1 [13 Kap.8.3.3] . . . . . . . . . . . . 13
4.4 SD- und mikro-SD-Karte [15] . . . . . . . . . . . . . . . . . . . . . 13
4.5 Aufbau einer SD-Karte [14 Kap.3.7] . . . . . . . . . . . . . . . . . 14
4.6 Blockdiagramm des Spimctrl-Cores von Gaisler[15 Kap.78.1] . . . . 17
4.7 Adress Offset der Spimctrl-Register[16 Kap.78.3] . . . . . . . . . . 17
4.8 Konfigurationsregister des Spimctrl-Cores[16 Kap.78.3] . . . . . . . 17
4.9 Kontrollregister des Spimctrl-Cores[16 Kap.78.3] . . . . . . . . . . 18
4.10 Statusregister des Spimctrl-Cores[16 Kap.78.3] . . . . . . . . . . . 18
4.11 Empfangsregister des Spimctrl-Cores[16 Kap.78.3] . . . . . . . . . 19
4.12 Senderegister des Spimctrl-Cores[16 Kap.78.3] . . . . . . . . . . . 19
4.13 GRMON: Auflistung der SPIM-Befehle . . . . . . . . . . . . . . . . 22
4.14 GRMON: SPIM-Status . . . . . . . . . . . . . . . . . . . . . . . . 23
4.15 Flussdiagramm des Spimctrl-Core . . . . . . . . . . . . . . . . . . 24
4.16 Flussdiagramm des Spimctrl-Core (Fortsetzung) . . . . . . . . . . 26
4.17 Zustandsdiagramm für den Initialisierungsprozess des Spimctrl-Core 27
4.18 GRMON: Ausgabe des CSD-Registers der SD-Karte über SPIM . . 28
5.1 Treiberschichten nach dem OSI-Modell . . . . . . . . . . . . . . . 29
5.2 Single- und Multiple-Blockread . . . . . . . . . . . . . . . . . . . . 30
IV
Bachelorarbeit
Daniel Schembri
5.3 Single- und Multiple-Blockwrite . . . . . . . . . . . . . . . . . . . . 32
5.4 links die UMSG, rechts der Header
. . . . . . . . . . . . . . . . . 35
5.5 Datenbereich bestehend aus einer Allgemeinen Nachricht . . . . . 36
5.6 Datenbereich bestehend aus einer TAB-Info . . . . . . . . . . . . . 36
5.7 Datenbereich bestehend aus CAN-Nachrichten . . . . . . . . . . . 36
5.8 UMSGV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.9 Datenbereich bestehend aus großer Textnachricht oder Frame . . . 37
6.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2 Aufbau des Systems mit SD-Karte (geänderte Abb. von [17 Kap.5.2
Abb.4.1]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Benchmark: Schreiben von 10MByte Testdaten auf die SD-Karte . . 45
6.4 Benchmark: Schreiben eines UMSGFS-Headers mit einem Eintrag
auf die SD-Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.5 Benchmark: Test des Multithreading in eCos
V
. . . . . . . . . . . . 47
Bachelorarbeit
Daniel Schembri
Quellcodeverzeichnis
VI
Bachelorarbeit
Daniel Schembri
Abkürzungsverzeichnis
CAN
Controller Area Network
CPOL
Clock Polarity
CPHA
Clock Phase
CID
Card Identification Register
CSD
Card Specific Data
DSR
Deferred Service Routine
eCos
Embedded Configurable Operating System
FPGA
Field Programmable Gate Array
GRETH
Gaisler Research Ethernet
HC
High Capacity
HiTES
High Temperature Embedded System
I2C
Inter-Integrated Circuit
IP-Core
Intellectual Property Core
ISR
Interrupt Service Routine
JPEG
Joint Photographic Expert Group
LSB
Least Significant Bit
MISO
Master-In-Slave-Out
MMC
Interrupt Service Routine
MOSI
Master-Out-Slave-In
MSB
Most Significant Bit
OCR
Operation Condition Register
RCA
Relative Card Address Register
SCR
SD-Card Configuration Register
SD
Secure Data
SPI
Serial Peripheral Interface
SVGA
Super Video Graphics Array
UDP
User Datagram Protocol
UMSG
Universal Message
UMSGFS
Universal Message File System
UMSGT
Universal Message Trust
VII
Bachelorarbeit
Daniel Schembri
UMSGV
Universal Message Videodata
VHDL
VHSIC Hardware Description Language
W-LAN
Wireless Local Area Network
XC
extended Capacity
VIII
Bachelorarbeit
1
Daniel Schembri
Einleitung
Am 1.Oktober 2009 gab es einen Zusammenschluss zwischen der Universität
Karlsruhe und dem Forschungszentrum Karlsruhe. Daraus entstand das Karlsruher Institut für Technologie, kurz KIT [1]. Im Institut für Angewandte Informatik (IAI)
im Karlsruher Institut für Technologie wird eine Bohrlochsonde für die Geothermie
entwickelt die bis 200°C Umgebungstemperatur eingesetzt werden soll, um bei
Bohrungen bis ca. 4000m Tiefe, Mess- und Videodaten zu übermitteln. Die Daten
werden mit Hilfe eines Embedded Systems verarbeitet und mit UDP/IP-Protokoll
gebündelt durch ein Kabelmodem oder einen Übertrager für Glasfaser übermittelt. Das Hardwareprojekt wurde HiTES (High Temperature Embedded System)
genannt. Die HiTES-Platine befindet sich im gekühlten Bereich und verträgt bis
125°C.
Zwei Kameras liefern ihre Bilddaten seriell und werden hardcodiert von IP-Cores1
umgeformt und komprimiert. Dadurch kann man die volle Rechenleistung des
FPGAs ausnutzen, denn alle zusätzlichen IP-Cores arbeiten eigenständig und unabhängig von dem CPU-IP-Core. Die komprimierten Bilddaten werden anschließend in den RAM übertragen. Da die Bilddaten mit einem Kabelmodem nicht alle
unmittelbar übertragen werden können, sollen Mess- und Bilddaten zur späteren Auswertung auf einem Massenspeicher archiviert werden. Dazu gilt es ein
geeignetes Speichermedium zu finden, einen Treiber zu implementieren und ein
zweckmäßiges Dateisystem einzusetzen. Weiterhin sollen zeitkritische Aufgaben
und Zeitstempelverfahren zuverlässig ausgeführt werden. Hierzu ist ein passendes Betriebssystem notwendig.
1
Ein IP-Core ist ein Intelligent Property Core.
1
Bachelorarbeit
2
Daniel Schembri
Stand der Technik
HiTES soll zur Kommunikation mit der Sonde dienen. Es sollen Daten aufbereitet
und an einen Bedienstand(Host) an der Oberfläche gesendet werden. Folgend
ist das Zusammenspiel der Komponenten von der Sonde bis zum Bedienstand
dargestellt. Im gekühlten Bereich (bis 90Grad Celsius) befindet sich die HiTESPlatine:
Abbildung 2.1: HiTES verbunden mit dem Bedienstand[internes Plakat abgeändert]
Die Platine ist mit mehreren integrierten Schaltkreisen bestückt: einem Spartan6LX75T-FPGA[2, siehe auch 3 Kap.3] mit seriellem Netzlistenflash der Firma
Xilinx, einem 4MByte SRAM, einem Dual-PHY mit Ethernet-Schnittstelle, ADDA-Wandlern und Temperatursensoren. Zusätzlich wird es eine weitere HiTESPlatine geben, die komplett belegt wird durch die Implementierung des Kabelmodems.
2
Bachelorarbeit
Daniel Schembri
Die Sonde ist über ein 4000m langes Kabel mit dem Bedienstand verbunden. Die
besonderen Umgebungsbedingungen (200Grad Celsius, 400Bar Druck) und die
Länge des Kabels verlangen eine hohe Robustheit des Übertragungsmaterials.
Da es durch Marktzwang kaum Alternativen gibt, kommen nur Glasfaser und Koaxialkabel in Betracht.
Auf dem Bedienstand, an der Oberfläche, befindet sich bereits Software, die die
Bild- und Messdaten visualisiert und weiterverarbeitet. Die Anwendung wurde
Geo-GUI[4] genannt. Sie bietet eine Anbindung an eine SQL-Datenbank auf der
die Zeitstempel und zusätzliche Informationen archiviert werden. Durch ein Multithreadingverfahren ist es möglich bei gleichzeitiger Aufnahme von Daten, die
bereits empfangenen Daten erneut abzuspielen. Dadurch ist eine Analyse bereits
während einer laufenden Messfahrt möglich[4 Kap.6]. Die Bilddaten werden zurzeit noch direkt auf dem Dateisystem gespeichert. Bislang gibt es verschiedene
Testprogramme, um ankommende Sondendaten über UDP zu simulieren.
Im Folgenden wird der interne Aufbau des FPGAs, das für die Datenverarbeitung
und Steuerung der Sonde zuständig ist, beschrieben:
3
Bachelorarbeit
Daniel Schembri
Abbildung 2.2: Der Innere Aufbau des FPGAS
Die Sonde besitzt serielle Kameras, die mit einer Frequenz von 144MHz Bilddaten über LVDS überträgt. Die Bilder werden von den IP-Cores[3 Kap.3] umgeformt
und im SRAM gespeichert. Dort ist ein 4MByte großer Adressraum mit 32Bit Datenbreite vorhanden. Die Bilder können durch hinzuschalten eines SVGA-Cores
zu Testzwecken auf einem Monitor ausgegeben werden. Ein JPEG-Core ist so
eingestellt, dass er die Bilddaten der Kamera mindestens um den Faktor 21 komprimiert. Durch weitere Anpassungen, wie die Verringerung der Farbtiefe, Anpassung der Bildqualität, etc. kann der Kompressionsfaktor noch gesteigert werden.
An den internen Hochgeschwindigkeitsbus AHB des AMBA2.0 Bussystems[5]1
können bis zu 16 Komponenten angebunden werden.
Von der HiTES-Platine[6] gibt es mehrere Versionen. Folgend eine Abbildung der
zweiten Version:
1
Näheres siehe [3 Kap.4].
4
Bachelorarbeit
Daniel Schembri
Abbildung 2.3: Die HiTES-Platine. Vorder- und Rückseite[7]
5
Bachelorarbeit
3
Daniel Schembri
Aufgabenstellung und Zielsetzung
In HiTES entstehen Mess- und Steuerkommandos, Statusmeldungen, sowie komprimierte Bilddaten von zwei Kameras. Die eine Kamera blickt axial ins Rohr, während die zweite Kamera, fixiert, durch ein Fenster senkrecht auf die Rohrwand gerichtet ist. Die Sonde lässt sich rotieren und somit kann die ganze Rohrwand inspiziert werden. Ein Teil der Sensoren und Aktoren werden über ein CAN-Bussystem
angebunden, andere mit I2C und manche werden direkt per PWM angesteuert.
Im Moment kann über ein Kabelmodem nur eine schmalbandige Verbindung zur
Oberfläche hergestellt werden. Vorgesehen ist eine Übertragung mit ca. 1MBit/s.
Bei einer Messfahrt, die ca. sechs Stunden dauern kann, sind zwei Stunden für
die Fahrtzeit in 4000m Tiefe eingeplant; vier Stunden fallen für die Beobachtungszeit an. Während der ganzen Zeit muss beobachtet werden. Daher ist es notwendig die Datenpakete mit einem Zeitstempel zu versehen und in einem geeigneten Format auf einem Massenspeicher zu archivieren. Dazu kommen Messdaten,
Statusnachrichten und Kommandos, die aber einen geringes Volumen im Vergleich zu den Bildern besitzen. Daher sind diese in der folgenden Abschätzung
des Datenvolumens zu vernachlässigen.
Die JPEG-Bilder haben momentan eine niedrige Auflösung und sind mindestens
21-fach komprimiert. Damit ergibt sich eine Bildgröße von ca.:
640 ∗ 480 ∗ 24Bit : 21 = 44KByte.
Bei der JPEG-Komprimierung werden die Parameter der Komprimierung nochmals komprimiert. Da viele Bilder in unserem Fall eine geringen Informationsgehalt aufweisen, z.B. weniger Farben besitzen, kann die anzunehmende Datengröße mindestens halbiert werden:
44KByte : 2 = 22KByte
Eine Kamera hat bei 25Bildern/s eine Bandbreite von:
25Bilder/sec ∗ 22KByte/Bild = 0, 550MByte/s
6
Bachelorarbeit
Daniel Schembri
Folglich haben zwei Kameras:
2 ∗ 0, 550MByte/s = 1, 0742MByte/s
Beide Kameras liefern, bei Dauerbetrieb, über sechs Stunden eine Datenmenge
von:
1, 10MByte/s ∗ 6 ∗ 3600sec = 23, 20GByte.
Der Massenspeicher sollte daher eine Mindestgröße von 32GByte aufweisen.
Um zeitkritische Aufgaben und das Zeitstempelverfahren zuverlässig ausführen
zu können wird ein Echtzeitbetriebssystem (siehe Kap. 6) eingesetzt. Die Zeiterfassung wird auf 100 Mikrosekunden genau erfolgen.
Nach Bergung der Sonde sollen die gesammelten Daten auf den Bedienstand zur
weiteren Analyse übertragen werden. Da die Sonde sich in einem Dewargefäß[8]
befindet und somit völlig isoliert ist und möglichst nicht geöffnet werden soll, sollen
die Daten über ein WLAN-Modul übermittelt werden.
Für die Sonde müssen zwei Anwendungsfälle berücksichtigt werden:
Anwendungsfall A: In Situ Messfahrt der Sonde mit Speicherung der Daten auf
dem Massenspeicher
• Szenario 1: Alle anfallenden Mess- und Bilddaten werden auf dem Massenspeicher gespeichert.
• Szenario 2: Es sind Bilder mit hoher Rate für den Bedienstand nötig, daher werden diese mit niedrigerer Qualität erzeugt und versendet. Daraus
entsteht die Notwendigkeit, manuell hochauflösende Schnappschüsse aufzunehmen. In diesem Fall sind die Bilddaten in ausreichend hoher Qualität
und die Schnappschüsse zu speichern.
Anwendungsfall B: Nach Bergung der Sonde werden die in der Sonde gespeicherten Daten per WLAN übertragen und mit den auf dem Bedienstand vorhandenen Daten zusammengeführt.
Um die Aufgabenstellung zu lösen, wurde nach einem geeigneten Speichermedium gesucht. Man hat sich für mikro-SD-Karten (siehe Kap.4.1) entschieden, da
diese, bei geringen Maßen, eine entsprechend große Kapazität aufweisen und
einen ausreichenden Datendurchsatz bieten. Aus Zeitgründen und aufgrund der
von der Firma Gaisler vorhandenen IP-Cores[9] wurde beschlossen die SD-Karte
7
Bachelorarbeit
Daniel Schembri
im SPI-Modus zu betreiben. SPI ist ein gängiges serielles Bussystem in Embedded Systems und bietet ausreichend Datendurchsatz.
Es sind folgende Teilaufgaben zu lösen:
• Implementierung und Test eines SPI-Memory-Controllers mit ausreichender
Bandbreite
• Anpassung des SPIMCTRL-Cores in VHDL[10,11,12] zur Kommunikation
mit SDHC-Karten
• Schreiben von Softwaretreibern, um SD-Karten ansprechen und rudimentäre Schreib-/Leseoperationen ausführen zu können
• Entwurf und Implementierung eines Dateisystem-Treibers, um Dateien im
UMSG-Format(siehe Kap.5.2) archivieren zu können
• Implementierung des Zeitstempelverfahrens unter einem Echtzeitbetriebssystem
• Einsatz von Schedulingmechanismen, um einen reibungslosen Ablauf der
Threads/Interrupts zu garantieren
• Benchmark und Bewertung des Gesamtsystems
Es muss folgende Randbedingung erfüllt werden: Nach einem Stromausfall muss
die Aufzeichnung der Messfahrt nach dem letzten gültigen Datenpaket fortgesetzt
werden; es dürfen keine Daten überschrieben werden.
Der Core von Gaisler ist zu Testen und den Anforderungen entsprechend zu erweitern. Der Treiber ist so umzusetzen, dass dieser bei Verwendung alternativer
Übertragungsverfahren leicht austauschbar bzw. erweiterbar ist, so das z.B. zwei
SD-Karten gleichzeitig betrieben werden können.
Um Konflikte innerhalb des Systems zu vermeiden muss der Ressourcenzugriff
der Threads mit Hilfe von Mutexen bzw. Semaphoren koordiniert werden(siehe
Kap.6.1). Da im System nur vier MByte SRAM verbaut sein werden, ist das Programm effizient umzusetzen.
Es sind verschiedene Benchmarks durchzuführen, um den maximal möglichen
Datendurchsatz des Systems zu ermitteln. Des weiteren ist das Gesamtverhalten
des Systems zu überprüfen und zu bewerten.
Um die Aufgaben umzusetzen, wird die Hardwarebeschreibungssprache VHDL
in der Entwicklungsumgebung ISE Design Suite 14.3 von der Firma Xi-
8
Bachelorarbeit
Daniel Schembri
linx™verwendet. Zum Testen der Hardwareimplementierung wird GRMON, ein
Debuggingtool für Leon3, von der Firma Gaisler™verwendet. Um den Signalverlauf zu überprüfen, wird der Logicanalyzer Chipscope von Xilinx™verwendet.
Simulationen werden mit ISim von Xilinx™durchgeführt. Um die C-Programme
auf dem Leon-Prozessorsystem zu testen wird Eclipse mit CDT und integriertem GRMON verwendet. Als Testsystem fungiert die vom IAI1 eigens entwickelte
HiTES-Platine(siehe Kap.2).
1
Institut für angewandte Informatik
9
Bachelorarbeit
4
Daniel Schembri
Verbesserung des SD-Karten-Controllers
Die im Projekt anfallenden Messdaten sollen zur späteren Analyse archiviert werden. Dazu soll an einem SPI-BUS[13 Kap.8] ein Massenspeicher angebunden
werden.
4.1 Einführung SPI-Bus mit SD-Karten
4.1.1 SPI-Bus
SPI steht für Serial Peripheral Interface und ist eine serielle Kommunikationsschnittstelle der Firma Motorola™. Ein SPI-Bus ist nach dem Master-Slave Prinzip aufgebaut. Es gibt keinen strikten Standard. Der SPI-BUS wird vor allem bei
Mikrocontrollern zur Kommunikation mit Peripheriegeräten eingesetzt, aber auch
bei der Kommunikation innerhalb eines Prozessorsystems findet er Anwendung.
Eine ähnliche Schnittstelle stellt Microwire von der der Firma National Semiconductor™dar.
Folgend der Aufbau eines SPI-Bussystems:
10
Bachelorarbeit
Daniel Schembri
Abbildung 4.1: SPI-Master und Slaves
Der SPI-Master gibt den Takt vor und treibt den SPI-Slave. ’MOSI’ steht für
’Master-Out-Slave-In’ und ist die Sendeleitung des SPI-Masters. ’MISO’ steht für
’Master-In-Slave-Out’ und stellt die Empfangsleitung des SPI-Masters dar. Mit
’Slave Select (SS)’ wird der entsprechende SPI-Slave ausgewählt. Wird nur mit
einem SPI-Slave kommuniziert, so kann die SS-Leitung auf Masse gelegt werden. Eine SPI-Kommunikation kann in vier verschiedenen Modi stattfinden die
folgend aufgeführt sind:
SPI-Modus
CPOL
CPHA
0
0
0
1
0
1
2
1
0
3
1
1
11
Bachelorarbeit
Daniel Schembri
Bei SPI wird das Most-Significant-Bit (MSB) zuerst übertragen. Mit jeder steigenden Taktflanke werden die Daten übernommen. Es werden 8 Bit seriell übertragen. Zwischen jedem Byte kann das SS-Signal für einen Takt auf Low gezogen
werden. ’CPOL’ gibt die Takt-Polarität an. Bei ’CPOL=0’ ist der Idle-Takt low. Bei
’CPOL=1’ ist der Idle-Takt High.
’CHPA’ gibt die Takt-Phase an. Bei ’CHPA=0’ werden die Daten mit der ersten Taktephase übernommen; bei ’CHPA=1’ erst mit der zweiten. Folgend zwei TimingDiagramme mit den verschiedenen Modi:
Abbildung 4.2: SPI Timing Diagram CHPA = 0 [13 Kap.8.3.2]
Abbildung 4.3: SPI Timing Diagram CHPA = 1 [13 Kap.8.3.3]
12
Bachelorarbeit
Daniel Schembri
4.1.2 SD-Karten
Eine SD-MemoryCard[14] ist ein digitales Massenspeichermedium, das auf Flashspeicher basiert. Die SD-Karte wurde 2001 von Sandisk™entwickelt und stellt
eine Erweiterung der Multimedia Card (MMC) dar. Das ’SD’ steht für ’Secure Digital’ und gibt an, dass zusätzliche Funktionen für eine digitale Rechteverwaltung
(’DRM’) auf der Karte verwendbar sind.
SD-Karten werden üblicherweise im SD-Mode betrieben. Dabei werden 4 Bit parallel übertragen. Fast alle SD-Karten unterstützen den seriellen SPI-Mode. Dieser
ist wesentlich einfacher zu implementieren und wird generell unterstützt.
Für eine höhere Datenrate können mehrere SD-Karten parallel betrieben werden.
Mit jeder weiteren Karte würde sich neben der Schreibgeschwindigkeit, die Kapazität erhöhen.
Aufbau und Typen
Abbildung 4.4: SD- und mikro-SD-Karte [15]
Folgend der Aufbau von SD-Karten:
13
Bachelorarbeit
Daniel Schembri
Abbildung 4.5: Aufbau einer SD-Karte [14 Kap.3.7]
Die SD-Karte enthält einen internen Controller, der die internen Operationen ausführt. Der Speicherbereich gliedert sich in zwei Teile: den sechs Registern und
dem Datenbereich. Man kann einen Reset der Karte bewirken, indem man die
Karte einige Zeit vom Strom nimmt.
Für SD-Karten gibt es sechs vordefinierte Register: ’OCR’, ’CID’, ’CSD’, ’RCA’,
’DSR’ und ’SCR’. Diese können nur über die entsprechenden Befehle angesprochen werden.
Das ’Operation Condition Register (OCR)’ enthält Informationen zur Spannungsversorgung der Karte. Außerdem enthält es ein Statusbit, dass gesetzt wird,
wenn die Karte nach dem Anschalten initialisiert wurde.
Im ’Card Identification-Register (CID)’ stehen Herstellerinformationen und die
Seriennummer der Karte.
Das ’Card Specific Data-Register (CSD)’ enthält Information zur Kommunikation
mit der SD-Karte, wie beispielsweise die Version der Karte ,Blocklänge, und die
maximale Transferrate.
Das ’Relative Card Adress-Register (RCA)’ enthält die Adresse die nach der
Kartenidentifikation an den Host im SD-Mode versendet wird.
14
Bachelorarbeit
Daniel Schembri
Das ’Driver Stage-Register (DSR)’ ist ein optionales Register, mit dem die BusPerformance im SD-Mode erhöht werden kann.
Das ’SD-Card Configuration Register (SCR)’ ist eine Erweiterung zum CSDRegister. Es enthält Informationen zu speziellen Eigenschaften der SD-Karte.
Folgend eine Tabelle die die Pins beschreibt:
Pin
Name
Porttyp
Beschreibung
1
DAT2
2
CD/DAT3
In
Slave Select
3
CMD
In
Data In/Master out Slave in
4
Vdd
Support
Stromversorgung
5
CLK
6
Gnd/Vss
Support
Masse
7
DAT0
Out
Data out/Master in Slave out
8
DAT1
Nicht verwendet
Taktleitung
Nicht verwendet
Die erste Generation von SD-Karten mit der Version 1.0 unterstützen bis zu 4
GByte. Die Adressierung der Daten ist byteorientiert. SDHC-Karten entsprechen
der SD-Version 2.0 und sind die zweite Generation. Die Adressierung ist blockorientiert mit einer standardmäßigen Blockgröße von 512 Byte. SDHC-Karten unterstützen Kapazitäten von bis zu 32 GByte. Die dritte Generation mit der SD-Version
3.0 sind SDXC-Karten. Das ’XC’ steht für ’extended Capacity’. Diese Karten sind
ebenfalls blockorientiert adressiert. Die Standardblockgröße beträgt, wie bei den
SDHC-Karten, 512 Byte. Es werden bis zu 2 TByte unterstützt. Bei allen Versionen werden 32-Bit Adressen verwendet.
Unterschied zwischen SPI- und SD-Mode
Der SPI-Mode wird von allen SD-Kartentypen bis mindestens 25 MHz unterstützt.
Der SPI-Mode wird bei Verwendung von SD-Karten mit Mikrocontrollern eingesetzt, da dieser leichter zu implementieren ist und vom Datendurchsatz meist
ausreicht.
Beim SD-Mode werden auf vier Leitungen parallel Daten übertragen. Dadurch
sind Übertragungsgeschwindigkeiten bis zu 10 MByte/s (Class 10) und mehr
möglich. Die Implementierung des SD-Modes ist deutlich aufwändiger. Aus Zeitgründen wurde deshalb davon abgesehen.
15
Bachelorarbeit
Daniel Schembri
Geschwindigkeitsklassen
Sowohl für SDHC- als auch SDXC-Karten gibt es Geschwindigkeitsklassen. Es
gibt die Geschwindigkeitsklassen 2, 4, 6, 8 und 10. Diese legen die Mindestschreibgeschwindigkeit in MByte/s fest. Da der Geschwindigkeitszuwachs durch
internen parallelen Aufbau und bessere Flashtechnik erreicht wird, ist davon auszugehen, dass auch auch die SPI-Schreibgeschwindigkeit steigt.
Bei SDHC- und SDXC-Karten gibt es zudem die Abkürzung UHS-I und UHS-II.
Dies steht für ’Ultra High Speed’. Die Karte SanDisk Extreme Pro SDXC/SDHC
UHS-1 erreicht beispielsweise ein Schreibgeschwindigkeit bis zu 95 MByte/s.
SDHC-Karten können standardmässig im SPI-Modus mit bis zu 25MHz betrieben werden.
Dies ergibt ein Brutto-Datenrate von:
25MHz /(1024*1024*8Bit) = 2,9802322 MByte/sec
4.2 Der SPI-Memory-Controller-Core von Gaisler™
4.2.1 Der Aufbau des Cores
Der SPI-Memory-Controller-Core von Gaisler™, kurz SPIMCTRL[16 Kap.78],
dient zur Anbindung von SD-Karten und Flash-Speichermedien über den SPIBus an das LEON3-System. Der Core wird über Kontrollregister gesteuert, die
in den AMBA-AHB-Adressbereich eingeblendet sind, gesteuert. Sowohl der SPITakt als auch der Initialisierungstakt werden aus dem Systemtakt erzeugt. Der
Systemtakt ist auch der AMBA-Takt. Dieser wird im Spimctrl-Core mindestens
halbiert. Der Core ist über die vier Leitungen ’SCK’, ’MISO’, ’MOSI’ und ’CSN’ mit
dem Speichermedium verbunden. Die Leitungen ’ERRORN’, ’READY’ und ’INITIALIZED’ geben den Zustand des Cores wieder. Zwei Statemachines regeln die
Kommunikation zwischen dem extern angebundenen Speichermedium und dem
Prozessorsystem. Da der Core ein internes 8Bit-Register sowohl zum Senden
als auch Empfangen von Daten verwendet, wird eine Datenübertragung nur im
Halb-Duplex-Modus durchgeführt.
Folgend der Aufbau des Spimctrl-Cores:
16
Bachelorarbeit
Daniel Schembri
Abbildung 4.6: Blockdiagramm des Spimctrl-Cores von Gaisler[15 Kap.78.1]
Zur Steuerung des Cores gibt es verschiedene Register die per Software angesprochen werden können. Diese haben folgenden Offset im AMBA-Adressraum:
Abbildung 4.7: Adress Offset der Spimctrl-Register[16 Kap.78.3]
Folgend der Aufbau des Konfigurationsregisters:
Abbildung 4.8: Konfigurationsregister des Spimctrl-Cores[16 Kap.78.3]
Folgend der Aufbau des Kontrollregisters:
Abbildung 4.9: Kontrollregister des Spimctrl-Cores[16 Kap.78.3]
17
Bachelorarbeit
Daniel Schembri
Wird das User-Control-Bit (USRC) gesetzt ist es möglich einzelne Bytes über
die SPI-Schnittstelle des Cores zu senden. Dazu muss das Byte in das Transmitregister des Cores geschrieben werden. Dieses hat den Adressoffset 0x10. Der
Usercontrolmode wird benötigt, um mit eigens geschriebenen Programmen eine
Kommunikation mit dem Speichermedium realisieren zu können. Der im Projekt
behandelte Softwaretreiber benötigt den User-Control-Mode.
Interrupt Enable (IEN): Ist dieses Bit gesetzt, dann wird nach jedem Transfer im
User-Mode ein Interrupt ausgelöst
Enable Alternate Scaler: Durch Setzen des EAS-Bits wird der (EAS) alternative
Takt als SPI-Takt verwendet
Chip Select (CSN): Die Chipselect-Leitung dient zur Auswahl des Slaves.
Reset Core (RST): Indem dieses Bit gesetzt wird, wird ein Reset des SpimctrlCores durchgeführt. Dies hat den gleichen Effekt wie ein System Reset
Die Bits 5 bis 31 sind reserviert und werden daher nicht weiter beachtet.
Folgend der Aufbau des Statusregisters:
Abbildung 4.10: Statusregister des Spimctrl-Cores[16 Kap.78.3]
Das ’Operation-Done’-Bit (DONE) wird gesetzt, wenn der Core ein Byte im Usermode gesendet hat.
Das Init-Bit (INIT) wird gesetzt, wenn die SD-Karte erfolgreich initialisiert wurde.
Das Error-Bit (ERR) wird gesetzt, wenn der Core sich im Error-Modus befindet.
Das Bit wird im User-Mode nicht automatisch gesetzt.
Das Timeout-Bit (TO) wird automatisch gesetzt, wenn beim Warten auf eine Antwort der SD-Karte ein Timeout des Cores ausgelöst wird. Dies kann beispielsweise bei der Initialiserung auftreten. Bei Verwenden des User-Modes wird dieses Bit
nicht mehr automatisch gesetzt.
Das ’Card-Detect’-Bit (CD) wird nur in Verbindung mit dem SD-Mode des Cores
verwendet. Gesetzt zeigt es an, dass eine SD-Karte an den SD-Slot angeschlos-
18
Bachelorarbeit
Daniel Schembri
sen ist. Durch Überwachen dieses Bits in einem Programm, kann festgestellt werden, ob eine Karte gewechselt, bzw. erneut an das System angeschlossen wurde.
Dementsprechend kann dann ein Core-Reset ausgeführt werden.
Die Bits 6 bis 31 sind reserviert und werden daher nicht weiter beachtet.
Folgend das Empfangsregister
Abbildung 4.11: Empfangsregister des Spimctrl-Cores[16 Kap.78.3]
Im Register ’RDATA’ sind die über SPI empfangenen Daten enthalten. Es werden
jeweils 8Bit empfangen. Ein Anliegen der Daten wird durch ein auf ’0’ zurückgesetztes Busy-Bit angezeigt. Da der SPI-Master den Takt des Slaves treibt, müssen
zum Empfangen von Daten Bytes gesendet werden. Die Bits 8 bis 31 sind reserviert.
Folgend das Senderegister:
Abbildung 4.12: Senderegister des Spimctrl-Cores[16 Kap.78.3]
In die ersten acht Bits, also in das ’TDATA’-Register, müssen die über SPI zu
sendenden Daten geschrieben werden. Es kann immer nur byteweise gesendet
werden. Während dem Senden ist das Busy-Bit gesetzt. Wurde ein Byte gesendet
wird das Busy-Bit auf ’0’ zurückgesetzt und das Done-Bit gesetzt. Dadurch kann
eine Anwendung feststellen, wann das nächste Byte in das TX-Register geschrieben werden kann. Die Bits 8 bis 31 sind reserviert.
4.2.2 Tests
Anfangs wurde eine 1GB SD-Karte (Version 1.0) von Sandisk getestet, da diese sich durch den unveränderten SPI-Memory-Controller von Gaisler ansprechen
lies.
19
Bachelorarbeit
Daniel Schembri
Folgend der Code für das User-Constraint-File:
1
# Enable when SPI−sdcard used , sd
2
NET s p i _ s c k
LOC = L3 | IOSTANDARD = LVCMOS33 ; # LVDS_CLK_P
3
NET spi_miso
LOC = M8 | IOSTANDARD = LVCMOS33 ; # I2C_SCL
4
NET spi_mosi
LOC = F3 | IOSTANDARD = LVCMOS33 ; # LVDS_D_P
5
NET s p i _ s p i s e l LOC = E4 | IOSTANDARD = LVCMOS33 ; # LVDS_D_N
Durch folgenden Eintrag in der Config.vhd werden die Parameter zur Implementation in VHDL gesetzt:
1
−− SPI memory c o n t r o l l e r
2
constant CFG_SPIMCTRL : i n t e g e r : = 1 ;
3
constant CFG_SPIMCTRL_SDCARD : i n t e g e r : = 1 ;
4
constant CFG_SPIMCTRL_READCMD : i n t e g e r : = 16#0#;
5
constant CFG_SPIMCTRL_DUMMYBYTE : i n t e g e r : = 0 ;
6
constant CFG_SPIMCTRL_DUALOUTPUT : i n t e g e r : = 0 ;
7
constant CFG_SPIMCTRL_SCALER : i n t e g e r : = 2 ; −−ca . 25MHz
8
constant CFG_SPIMCTRL_ASCALER : i n t e g e r : = 8 ; −− ca . 300KHz
9
constant CFG_SPIMCTRL_PWRUPCNT : i n t e g e r : = 8 0 ;
Die
ersten
beiden
Konstanten
’CFG_SPIMCTRL’
und
’CFG_SPIMCTRL_SDCARD’ geben an, dass der SPI-Memory-Core zum
Ansprechen von SD-Karten verwendet wird. ’CFG_SPIMCTRL_SCALER’ und
’CFG_SPIMCTRL_ASCALER’ legen den Betriebs- bzw. Initialisierungstakt fest.
Die restlichen Konstanten werden zur Anbindung von Flash-Chips benötigt und
sind daher uninteressant.
Der Spimctrl-Core wird im Leon3-System durch folgenden VDHL-Code implementiert:
1
2
3
spimc : i f CFG_SPICTRL_ENABLE = 0 and CFG_SPIMCTRL = 1 generate
−− SPI Memory C o n t r o l l e r
spimctrl0 : spimctrl
generic map ( hindex => 4 , h i r q => 4 , f a d d r => 16#a00 # ,
fmask => 16# f f 0 # ,
4
i o a d d r => 16#100# , iomask => 16# f f f # ,
5
s p l i t e n => CFG_SPLIT , oepol
6
sdcard => CFG_SPIMCTRL_SDCARD,
7
s c a l e r => CFG_SPIMCTRL_SCALER,
8
a l t s c a l e r => CFG_SPIMCTRL_ASCALER)
9
=> 0 ,
port map ( r s t n , clkm , ahbsi , ahbso ( 4 ) , spmi , spmo ) ;
20
Bachelorarbeit
Daniel Schembri
’hindex’ und ’hirq’ geben den AMBA-AHB-Index und die dazugehörige Interruptleitung an. Mit ’faddr’ wird die Startadresse und mit ’fmask’ der Speicherbereich
festgelegt.
Folgend die Verbindung der PINS mit den internen Signalen:
1
sd_miso_pad : inpad generic map ( t e c h => padtech )
port map ( spi_miso , spmi . miso ) ;
2
3
4
5
6
7
8
mosi_pad : outpad generic map ( t e c h => padtech )
port map ( spi_mosi , spmo . mosi ) ;
sck_pad
: outpad generic map ( t e c h => padtech )
port map ( spi_sck , spmo . sck ) ;
s l v s e l 0 _ p a d : iopad generic map ( t e c h => padtech )
port map ( s p i _ s p i s e l , spmo . csn , spmo . cdcsnoen , spmi . cd ) ;
9
10
nospimc : i f ( ( CFG_SPICTRL_ENABLE = 0 and CFG_SPIMCTRL = 0 ) or
11
( CFG_SPICTRL_ENABLE = 1 and CFG_SPIMCTRL = 1 ) )
12
13
14
15
16
17
generate
mosi_pad : outpad generic map ( t e c h => padtech )
port map ( spi_mosi ,
sck_pad
’0 ’) ;
: outpad generic map ( t e c h => padtech )
port map ( s p i _ c l k ,
’0 ’) ;
end generate ;
Wird der Core nicht verwendet, so werden die Signale auf ’0’ gezogen.
Der SPIMCTRL-Core kann nun in GRMON angesprochen werden. Durch den
Befehl ’spim’ werden die spezifischen Befehle aufgelistet:
21
Bachelorarbeit
Daniel Schembri
Abbildung 4.13: GRMON: Auflistung der SPIM-Befehle
Durch den Befehl ’spim reset’ kann der Core zurückgesetzt werden. Dies entspricht einem System-Reset. Der Core führt anschließend die Initialisierung erneut aus. Mittels ’spim tx’ kann ein Byte über das SPI-Senderegister gesendet
werden.
Der Befehl ’spim status’ gibt den aktuellen Status des Cores wieder. Dazu werden die Control- und Status-Register aufgelistet:
Abbildung 4.14: GRMON: SPIM-Status
Bei einer erfolgreichen Initialisierung sind ’Card Detect’ und ’Initialized’ gesetzt.
Fazit: die ’alten’ SD-Karten funktionieren, deren Kapazität reicht jedoch nicht aus.
22
Bachelorarbeit
Daniel Schembri
Die Lösung, acht SD-Karten zu je 4GB parallel anzubinden ist zu aufwändig. Somit muss der Core zur Unterstützung von SDHC- und SDXC-Karten erweitert
werden.
4.3 Erweiterung der Statemachine für SDHC-Karten
Die Statemachine des SPI-Memory-Controllers initialisiert nur SD-Karten der
Version 1.0. Damit SDHC- und SDXC-Karten ebenfalls verwendet werden können, müssen das Kommando ’CMD8’ und die Checksumme ’0x87’ hinzugefügt
werden. ’CMD8’ überprüft die unterstützte Spannung der SD-Karten. Folgend
eine Auflistung der implementierten SD-Kommandos in VHDL:
1
−−CRCs
and B l o c k l e n g t h
2
constant SD_BLEN : i n t e g e r : = 4 ;
3
constant SD_CRC_BYTE : s t d _ l o g i c _ v e c t o r ( 7 downto 0 ) : = X"95" ;
4
constant SDHC_CRC_BYTE : s t d _ l o g i c _ v e c t o r ( 7 downto 0 ) : = X"87"
;
5
constant SD_BLOCKLEN : s t d _ l o g i c _ v e c t o r (31 downto 0 ) : =
6
c o n v _ s t d _ l o g i c _ v e c t o r (SD_BLEN, 32) ;
7
−− Commands
8
constant SD_CMD0
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "000000" ;
9
constant SD_CMD8
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "001000" ;
10
constant SD_CMD16
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "010000" ;
11
constant SD_CMD17
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "010001" ;
12
constant SD_CMD55
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "110111" ;
13
constant SD_CMD58
: s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "111010" ;
14
constant SD_ACMD41 : s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "101001" ;
15
constant SD_DUMMYCMD : s t d _ l o g i c _ v e c t o r ( 5 downto 0 ) : = "111111" ;
Zudem muss die Initialisierungssequenz erweitert werden. Im folgenden wird die
neue Initialisierungssequenz erläutert:
23
Bachelorarbeit
Daniel Schembri
Abbildung 4.15: Flussdiagramm des Spimctrl-Core
Nach dem Einschalten des Systems sollte die Karte einige Millisekunden unter
Strom stehen. Anschließend müssen 80 Takte bei einer Initialisierungsfrequenz
von 100 bis 400KHz übertragen werden. Die Karte befindet sich nun im Idle-State
des SD-Modes. Da die Kommunikation über den SPI-Bus erfolgen soll, muss die
Karte in den Idle State des SPI-Modes gebracht werden. Dies geschieht durch
Senden des Befehls CMD0. Sobald die Karte im Idle-State ist, liefert sie als
Response eine ’1’ im ersten Bit des Response-Bytes zurück. Andernfalls wird
’CMD0’ erneut gesendet.
24
Bachelorarbeit
Daniel Schembri
Abbildung 4.16: Flussdiagramm des Spimctrl-Core (Fortsetzung)
Bei SDHC-Karten muss nun zusätzlich CMD8 gesendet werden. Dieser Befehl
teilt der SD-Karte die verwendete Versorgungsspannung mit und frägt ab ob diese unterstützt wird. Ältere SD-Karten liefern als Antwort ’Illegal Command’ zurück.
Dies ist nicht problematisch, da das darauf folgende Kommando ohne weiteres
ausgeführt wird. Diese Initialisierungssequenz kann also für alte SD-, als auch
neuere SDHC- und SDXC-Karten verwendet werden. Anschließend wird durch
senden des CMD55 ein spezieller Applicationcommand angekündigt. Durch den
darauf folgenden ACMD41 wird die Host Capacity Information an die SD-Karte
gesendet und der Initialisierungsprozess der gestartet. Nach dem Senden des
Befehls wird ebenfalls auf eine Antwort gewartet. Einigen Karten müssen die beiden Befehl CMD55 und ACMD41 öfter gesendet werden. Ist die Karte initialisiert,
wird durch CMD16 die Blocklänge auf 512 festgelegt. Kommt von der Karte als
Antwort nicht 0x00, dann ist die Initialisierung fehlgeschlagen und die entsprechenden Error-Bits im Status-Register des Cores werden gesetzt. Ansonsten ist
die Karte nun einsatzbereit.
25
Bachelorarbeit
Daniel Schembri
Einige SD-, als auch SDHC-Karten scheinen von der offiziellen Spezifikation etwas abzuweichen und lassen sich nicht initialisieren. Es kommt zu Timeouts des
Spimctrl-Cores. Im Projekt kommt daher eine 8GB bzw. 16GByte micro SDHCKarte der Geschwindigkeitsklasse 4 von Lexar zum Einsatz.
Bei der Erweiterung der Statemachine in VHDL gibt es einige Besonderheiten zu
beachten, die im Folgenden näher erläutert werden:
Abbildung 4.17: Zustandsdiagramm für den Initialisierungsprozess des Spimctrl-Core
26
Bachelorarbeit
Daniel Schembri
Die zwei Zustände ’Send_CMD’ und ’Get_Resp’ folgen nach den meisten Zuständen im Diagramm. Dabei werden im Zustand ’Send_CMD’ die sechs Bytes
eines SD-Kommandos gesendet. Ein Zähler gibt an welches Byte gesendet wird.
Anschließend wird eine ein Byte große Antwort im Zustand ’Get_Response’ empfangen. Ist kein Kommando mehr aktiv wird dies mit dem Signal ’r.go’ auf 0 angezeigt. Bei fallender Taktflanke wird dann in den nächsten State gewechselt.
Bei den SD-Befehlen wird immer ein Offset von 0x40 addiert. Dieser Offset wird
durch Konkatenation im CMD_Send-State dem jeweiligen Register hinzugefügt.
Da an der Schnittstelle des SPIMCTRL nichts geändert wurde, wird der Core wie
oben beschrieben implementiert.
Folgend die Ausgabe des CSD-Registers, bei Verwendung des neuen Cores:
Abbildung 4.18: GRMON: Ausgabe des CSD-Registers der SD-Karte über SPIM
Das CSD-Register der SDHC gibt die SD-Version der Karte an. 0x1 ist als Version
2.0 definiert.
Fazit: Die Lexar-Karte mit 8 und 16GByte funktioniert. Ein Test mit 32GByte steht
noch aus.
27
Bachelorarbeit
5
Daniel Schembri
Entwicklung von Softwaretreibern für SD-Karten
Der SPI-Memory-Controller stellt die unterste Treiberschicht dar. In ihm wird die
Initialisierung des SPI-Modes durchgeführt. Um eine Datenübertragung mit SDKarten durchführen zu können wird eine Treiberschicht in ’C’ entwickelt. Darauf
aufbauend steht ein Dateisystemtreiber, um die anfallenden Bild- Mess- und Steuerdaten im UMSG- bzw. UMSGV-Format([17 Kap.3] und siehe Kapitel 5.2) abzuspeichern. Das Dateisystem wurde ’UMSGFS’ ’Universal User Message File System’ genannt. Eine Anwendung kann diese Treiber zur Kommunikation einbinden.
Folgend eine Abbildung der Treiberschichten, klassifiziert nach dem OSISchichtenmodell[18]:
Abbildung 5.1: Treiberschichten nach dem OSI-Modell
Der SPI-Memory-Controller führt die Initialisierung der SD-Karte durch. Darauf
aufbauend steht die SD-Schicht, über die blockweise Lese- und Schreibzugriffe
mit der SD-Karte durchgeführt werden. Als Transportschicht steht das vom IAI
entwickelte UMSG-Format.
28
Bachelorarbeit
Daniel Schembri
5.1 SPI-SD Schicht
Damit überhaupt SD-Kommandos gesendet werden können, wird vor jedem Kommando vorausgesetzt das der Core korrekt initialisiert wurde und das UsercontrolBit gesetzt ist. Dazu werden im Unterprogramm ’Spim-Init()’ die Register überprüft
und ggf. eine Fehlermeldung ausgegeben.
Folgend das Flußdiagramm für einen Single-Blockread bzw. Mulltiple-Blockread:
Abbildung 5.2: Single- und Multiple-Blockread
Zu Beginn werden sechs Bytes versendet, die das eigentliche SD-Kommando
darstellen. Das erste Byte ist der Befehl CMD17 bzw. CMD18. Die folgenden vier
Bytes sind die zu lesende Blockadresse. Das letzte Byte ist die Checksumme. Da
die CRC-Funktion deaktiviert ist, wird ein Dummybyte gesendet. Nach dem Befehl
29
Bachelorarbeit
Daniel Schembri
wird ein weiteres Dummybyte gesendet, um der Karte einen Zyklus Zeit zu geben
den Befehl auszuwerten. Liefert die SD-Karte 0x00 zurück, dann wurde der Befehl
akzeptiert. Andernfalls liegt ein Fehler vor, der der Tabelle ’R1-Response-Token’
auf Seite 33 entnommen werden kann.
Nun wird auf das Start-Token ’0xFE’ der SD-Karte gewartet. Da der SPI-Master
den Takt und somit den SPI-Slave treibt, müssen in einer Schleife Dummybytes
gesendet werden. Nach einigen Zyklen (in Tests bis zu 128) kann nun mit dem
Auslesen begonnen werden. Nun müssen ebenfalls 512 Dummybytes gesendet
werden. Die Daten werden in einem ’Unsigned-Char-Array’ gespeichert. Der Singleread ist beendet, das Done-Bit wird gesetzt und das Char-Array als Returnwert
zurückgegeben.
Bei einem Multiple-Blockread wird erneut auf das Start-Token für den nächsten
Block gewartet. Wurde die angegebene Anzahl an Blöcken ausgelesen, muss
ein Stop-Tranmission-Befehl gesendet werden. Nun wird ebenfalls das Done-Bit
gesendet und das Char-Array zurückgegeben.
Folgend das Flußdiagramm für einen Single-Blockwrite bzw. Multiple-Blockwrite:
30
Bachelorarbeit
Daniel Schembri
Abbildung 5.3: Single- und Multiple-Blockwrite
Wie bei anderen Kommandos werden zu Beginn sechs Bytes versendet, die das
SD-Kommando darstellen. Das erste Byte ist hier der Befehl CMD24 bzw. CMD25.
Die folgenden vier Bytes sind die zu beschreibende Blockadresse. Das letzte Byte
ist eine optionale Checksumme. Da die Checksummenfunktion deaktiviert ist wird
ein Dummybyte gesendet. Nach dem Befehl wird ein weiteres Dummybyte gesendet, um der Karte einen Zyklus Zeit zu geben den Befehl auszuwerten. Liefert
die SD-Karte 0x00 zurück, dann wurde der Befehl akzeptiert. Andernfalls liegt ein
31
Bachelorarbeit
Daniel Schembri
Fehler vor der der Tabelle ’R1-Response-Token’ auf Seite 33 entnommen werden
kann.
Nun wird das Start-Token ’0xFE’ an die SD-Karte gesendet. Anschließend werden
in einer Schleife die Daten Byte für Byte gesendet. Nach dem ein 512Byte-Block
geschreiben wurde, wird gewartet, bis die SD-Karte die Daten akzeptiert hat. Dies
kann einige Zyklen andauern (bei Tests bis zu 256). Anschließend sendet die
Karte eine Checksumme an den Host. Der Single-Blockwrite ist beendet und das
Done-Bit wird gesetzt.
Bei einem Multiple-Blockwrite wird, nach akzeptieren der Daten, erneut das StartToken gesendet und die obige Prozedur wiederholt. Wurden die angegebenen
Blöcke ausgegeben, muss ein Stop-Transmission-Befehl gesendet werden. Nun
wird ebenfalls das Done-Bit gesetzt.
Folgend eine Tabelle mit den im Treiber SD-Treiber implementierten Befehlen, den
dazugehörige Bitmustern und den Response-Tokens:
Cmd
Bits
Mnemonik
Resp
Beschreibung
CMD12
001100
STOP_TRANS
R1b
Stoppe Übertragung
R1
Lese einen Block Daten aus
R1
Lese mehrere Blöcke aus
R1
Schreibe einen Block Daten
R1
Schreibe mehrere Blöcke aus
MISSION
CMD17
010001
READ_SINGLE
_BLOCK
CMD18
010010
READ_MULTIPLE
_BLOCK
CMD24
011000
WRITE_SINGLE
_BLOCK
CMD25
011001
WRITE_MULTIPLE
_BLOCK
Auf jeden gesendeten Befehl folgt eine Antwort der SD-Karte in Form eines
Response-Tokens. Durch das Auslesen der Response-Tokens wird eine Fehlererkennung und ggf. eine Fehlerbehandlung ermöglicht.
Folgend der Inhalt des ein Byte großen R1 Response-Tokens:
32
Bachelorarbeit
Daniel Schembri
Bit
Status
Beschreibung
0
In idle state
Die Karte befindet sich im Idle-State und
führt den Initialisierungsprozess aus
1
Erase reset
2
Illegal command
Ein nicht zulässiger Befehl wurde erkannt
3
Communication CRC error
Die CRC-Prüfung des Befehls schlug fehl
4
Erase sequence error
Ein Fehler während der Erase-Sequenz
trat auf
5
Addres error
Eine fehlerhafte Adresse
6
Parameter error
Die angegeben Adresse befindet sich
außerhalb des Adressraums
7
MSB
Immer Null
Das R1b Token hat den selben Inhalt wie das R1-Token. Nach dem Token folgen
beliebig viele Nullbytes, die angeben, dass die Karte beschäftigt ist. Sobald ein
Byte ungleich Null empfangen wird, ist die Karte für den nächsten Befehl bereit.
Das Response-Token R2 ist zwei Byte groß. Das erste Byte ist ein R1-Token.
Das zweite Byte enthält die folgend angegebenen Daten:
Bit
Status
Beschreibung
0
Card is locked
Das Bit ist gesetzt, wenn die
Karte durch den Benutzer gesperrt wurde
1
Write protect Erase skip
Das Bit wird gesetzt, wenn versucht
|lock/unlock command failed
wird einen schreibgeschützten Sektor
zu löschen oder
2
Error
Ein allgemeiner oder unbekannter Fehler
trat auf
3
CC error
Interner Fehler des Kartencontrollers
4
Card ECC failed
Der karteninterne ECC wurde verwendet,
konnte die Daten jedoch nicht korrigieren
5
Write protect violation error
Es wurde versucht auf einen schreibgeschützen Block zu schreiben
6
Erase param
Ungültige Auswahl des Sektors für
Erase-Sequenz
7
out of range | csd overwrite
33
Bachelorarbeit
Daniel Schembri
Das R3-Token enthält fünf Bytes. Das erste Byte entspricht dem R1-Token. Die
restlichen vier Bytes entsprechen dem OCR-Register.
Das R7-Token enthält fünf Bytes, die als Antwort auf CMD8 von der Karte versendet werden. (14 Kap.7.3.2)
5.2 Das UMSG-Datenformat
UMSG steht für Universal Message und ist ein vom IAI eigens entwickeltes Datenformat zur Archivierung der Messdaten(Verweis AF oder RH).
Eine UMSG besteht aus einem Header, einer Messagenr und dem Datenbereich.
Eine UMSG hat eine Größe von 40Bytes:
Abbildung 5.4: links die UMSG, rechts der Header
Der Header besteht aus der Magicnr, die als Identifikations-Prefix bei der Übertragung über UDP dient, dem Timestamp, der die Messzeit auf 100 Mikrosekunden
genau angibt und einer ID, die den UMSG-Typ angibt.
Der Datenbereich der UMSG hat eine Größe von 28Byte und kann aus einem
der folgenden Datentypen bestehen:
34
Bachelorarbeit
Daniel Schembri
Abbildung 5.5: Datenbereich bestehend aus einer Allgemeinen Nachricht
Allgemeine Nachrichten können z.B. kurze Statusmeldungen oder Antworten auf
Befehle der Sonde sein.
Abbildung 5.6: Datenbereich bestehend aus einer TAB-Info
In einer TAB-Info können Tabelleninformationen oder eine Referenz auf den Zeitstempel TS0 enthalten sein.(Verweis auf DSPrSem3 Kapitel 6.1)
Abbildung 5.7: Datenbereich bestehend aus CAN-Nachrichten
Es können CAN-Nachrichten gespeichert werden.
35
Bachelorarbeit
Daniel Schembri
5.2.1 Das UMSGV-Bilddatenformat
UMSGV(Verweis DS) ist die Abkürzung für ’Universal User Message Videodata’
und dient zum Archivieren von Bilddaten und größeren Textnachrichten der Sonde. Eine UMSGV besteht aus dem UMSG-Header und einem 1462 Byte großen
Datenbereich. Der Datenbereich ist dabei als Union in ’C’ umgesetzt, d.h. es kann
entweder eine Textnachricht, bestehend aus bis zu 1460 Zeichen, oder eine Teilinformation eines Bildes enthalten sein:
Abbildung 5.8: UMSGV
Folgend der Datenbereich des UMSGV-Paketes:
Abbildung 5.9: Datenbereich bestehend aus großer Textnachricht oder Frame
Das UMSGV-Print besteht aus der Länge des Textes und dem Datenbereich. Das
36
Bachelorarbeit
Daniel Schembri
UMSGV-Frame hat eine ID, eine Partnr, mit der sich ein Bild in mehrere Teilpakete
aufteilen lässt. Eine Size, die die Gesamtgröße des Bildes bis 4GByte angibt und
den Datenbereich.
5.3 Messdaten-Filesystem
5.3.1 Messfahrtinformationen im Header
Der Header des Filesystems verwaltet bis zu 32 Messfahrten. Jeder Eintrag hat
eine Größe von 16Bytes. Dadurch wird genau ein Block der SD-Karte als Header
verwendet.
Folgend der Aufbau des 16Byte großen Eintrages im Header:
Name
Größe
Beschreibung
Measurment_ID
4Byte
ID der Messfahrt. Datum
Measurment_Nr
1Byte
Nummer der Messfahrt
Measurment_Status
1Byte
Status (1: aktiv, 2:abgeschlossen)
Measurment_Startsector
4Byte
Startsektor der Daten auf der SD-Karte
Measurment_Lastumsg_MSB
4Byte
Blocknr der letzten gültige UMSG
Measurment_Lastumsg_LSB
2Byte
Byteadresse innerhalb des Blocks der
letzten gültigen UMSG
Die Messdaten werden als UMSG-Pakete verpackt im Datenbereich nacheinander abgespeichert.
5.3.2 Recovery der Messdaten
Nach den Randbedingungen von Kapitel 3 kann es vorkommen, dass die Sonde
ab und wieder angeschaltet wird. Dabei konnte die Adresse der letzten, gültigen
UMSG nicht gesichert werden. Da die Sonde während dem Schreiben ausgeschaltet wurde, so ist es nötig diese wieder herzustellen. Durch eine binäre Suche wird der Adressbereich der SD-Karte begrenzt. Da die Größe für UMSG- und
UMSGV-Pakete fest vorgegeben ist, arbeitet sich der Algorithmus zum letzten Datum vor und überprüft das Paket auf eine gültige UMSG-ID. Ist dies nicht der Fall,
wird rückwärts die letzte gültige ID ermittelt und die Adresse in den Header geschrieben.
37
Bachelorarbeit
6
Daniel Schembri
Messdatenverarbeitung in der Sonde
6.0.3 Der Begriff Echtzeit
Unter Echtzeit versteht man nach DIN 44300 Deutsche Industrienorm[19]:
.. den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass
die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach
einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.
Der Begriff Echtzeit umfasst dabei zwei Definitionen:
Harte Echtzeit
Bei einem System mit harter Echtzeit muss eine Deadline für die Ausführung bestimmter Operationen erfüllt sein. Ansonsten würde es zu fatalen Systemstörungen bzw. Gefahren kommen. Ein Beispiel wäre die Flugsteuerung in einem Flugzeug.
Weiche Echtzeit
Bei der weichen Echtzeit wird eine gelegentliche Überschreitung der Deadline
toleriert. Bei einem Multimediasystem beispielsweise hat die Überschreitung der
Deadline vergleichsweise geringe Auswirkungen, zum Beispiel Bildflackern.
[20]
Damit die Messungen zuverlässig ausgeführt werden, werden Interrupt-Handling
und Scheduling-Verfahren eingesetzt. Dazu wird ein Echtzeitbetriebssystem eingesetzt. Dadurch soll garantiert werden, dass die Ausführung bestimmter Prozesse bis zu einer bestimmten Deadline abgeschlossen ist. Der Einsatz von eCos
wird in [17 Kap.4.2.2] begründet.
38
Bachelorarbeit
Daniel Schembri
6.1 Einführung in das Echzeitbetriebssystem eCos
eCos [21] steht für ’Embedded Configurable Operating System’ und ist ein quelloffenes Echtzeitbetriebssystem der Firma eCoscentric Limited.
Der große Vorteil an eCos ist seine Skalierbarkeit. Es kann nach Bedarf angepasst werden und unterstützt, unter anderem, die SPARC Architektur des LEON3Prozessors. Hierfür gibt es ein ’Configuration Tool’.
6.1.1 Multithreading
Ein Thread ist ein Teilprozess von mehreren innerhalb eines Programms. Ein
Thread hat in eCos einen eigenen Stack. Multithreading bezeichnet das gleichzeitige Abarbeiten mehrerer Threads in einer Anwendung. Da es nur begrenzte
Ressourcen gibt, muss durch Scheduling der Zugriff auf diese geregelt werden.
Hierfür gibt es verschiedene Möglichkeiten:
Mutex
Ein Mutex (’mutal exclusion’) ist ein Synchronisationsverfahren, durch den ein
gleichzeitiger Zugriff mehrerer Threads auf eine Ressource verhindert wird. Ein
Thread sperrt eine Ressource indem er vor Verwendung derselben die Funktion
Mutex.lock() aufruft. Im Gegensatz zu einer Semaphore, kann nur der aktuelle
Thread die Sperrung wieder aufheben. Ein mögliches Problem ist die sogenannte Prioritätsinversion. Dieser Fall kann auftreten, wenn ein nieder priorer Thread
eine Ressource sperrt und ein höher priorer Thread auf deren Freigabe wartet.
Dann ist es möglich das ein Thread mit mittlerer Priorität den Ablauf unterbricht
und einen Wechsel zum höher prioren Thread verzögert, bzw. verhindert. eCos
bietet als Lösung zwei Verfahren an:
• Die Prioritätsvererbung
• Die Prioritätsgrenze
Semaphore
Eine Semaphore regelt den Zugriff mehrerer Threads auf mehrere Ressourcen.
Sie enthält einen Zähler der die Anzahl freier Ressourcen darstellt. Bei Freiga-
39
Bachelorarbeit
Daniel Schembri
be durch einen Thread wird der Zähler inkrementiert; bei Belegen dekrementiert.
Warten mehrere Threads auf eine Freigabe der Semaphore, dann bekommt der
höchst priore Thread den Zugriff zuerst. Im Gegensatz zum Mutex kann eine Semaphore auch von einem anderen Thread entsperrt werden.
Condition-Variablen
Eine Condition-Variable, zu Deutsch Bedingungsvariable, wird zusammen mit
einem Mutex verwendet, um den Zugriff auf Ressourcen zwischen mehreren
Threads zu steuern. Dabei wird der Mutex gesperrt. Die anderen Threads warten auf Freigabe des Threads. Im Gegensatz zur alleinigen Verwendung von Mutexen kann hierbei entschieden werden, ob ein Thread oder alle Threads ’geweckt’ werden sollen. Bedingungsvariablen eignen sich besonders beim Einsatz
von Erzeuger- und Verbaucher-Threads.
Flags
Ein Flag ist ein Synchronisationsmechanismus der in einem 32-Bit Wort umgesetzt ist. Jedes Bit des Flags repräsentiert eine mögliche Bedingung auf die ein
Thread warten kann. Auch eine Kombination mehrerer dieser Bedingungen ist
möglich. Der Thread selbst legt fest, wann seine Bedingungen erfüllt sind und er
aktiviert wird. Ein anderer Thread setzt oder löscht die Bits des Flags.
Message Boxes
Ecos bietet Message Boxes, auch Mail Boxes genannt an, damit zwei Threads
untereinander kommunizieren können. Im Gegensatz zu anderen Mechanismen
können hier größere Informationen übermittelt werden. Die Nachrichten werden
dabei in einer Warteschlange eingereiht. [21 Kap.6]
6.1.2 Interrupts
Ein Interrupt ist ein asynchrones externes Signal, das während der Programmausführung auftreten und eine Unterbrechung auslösen kann. Dieser wird durch
40
Bachelorarbeit
Daniel Schembri
ein Ereignis ausgelöst: z.B. das Überlaufen eines Timers, das Drücken eines Buttons oder das Empfangen eines Ethernet-Paketes sein. Wird ein Interrupt ausgelöst, dann wird der aktuelle Programmfluss unterbrochen und ein bestimmtes
Unterprogramm, die sogenannte ’Interrupt-Service-Routine (ISR)’ ausgeführt.
Dadurch wird ein gezieltes Abarbeiten von zeitkritischen Aufgaben ermöglicht.
Nach Beendigung des Unterprogramms wird an der letzten Stelle des Programms
fortgesetzt. Der LEON3-Prozessor hat bis zu 16 Interrupt-Leitungen für Hardwarekomponenten, die an den AMBA-Bus des Systems angeschlossen sind. Ein
besonders wichtiger Aspekt ist die Latenz zwischen dem Auslösen des Interrupts
und dem Ausführen der ISR.
Die Abarbeitung von Interrupts in eCos gliedert sich in zwei Teilbereiche: die ISR
und die DSR (Deferred Service Routine). Die ISR soll möglichst schlank gehalten werden, um eine niedrige Latenz zu erzielen. Bei komplexeren Aufgaben
sollte eine DSR verwendet werden, in der zeitintensivere Befehle ausgeführt werden. Dadurch ist es höher prioren Interrupts möglich, die Ausführung der DSR zu
unterbrechen. Zudem können die oben erläuterten Sperrmechanismen verwendet
werden. Man sollte ggf. darauf achten, dass die DSR nicht zu spät abgearbeitet
wird, da das System fehlerhaft arbeiten könnte: Beispielsweise in dem eine Komponente immer wieder Interrupts auslöst, die aber nie verarbeitet werden.
ISRs haben immer eine höhere Priorität als DSRs. DSRs haben immer eine höhere Priorität als Threads.
Die oben beschriebenen Sperrmechanismen sind für ISRs deaktiviert und deshalb nur in DSRs zu verwenden. Die Verwendung in einer ISR kann zu undefiniertem Verhalten führen. [21 Kap.3]
6.2 Implementierung des Zeitstempelverfahrens
Das Zeitstempelverfahren ist eine eigene Funktion in eCos und wurde zusammen
mit einem Hardwaretimer realisiert. Der Timer wurde so eingestellt, dass er mit
1MHz zählt und alle 10ms einen Reload durchführt.
Folgend das Flußdiagramm:
41
Bachelorarbeit
Daniel Schembri
Abbildung 6.1
Zu Beginn wird der Inhalt des Hardware-Timers in die Variable Time_us geladen.
Dabei handelt es sich um einen Zeitwert auf 100 Mikrosekunden genau. Zu beachten ist dabei, dass der Hardware-Timer den Wert dekrementiert.
Anschließend wird die Timebase der Variablen Time_10ms zugewiesen. Nach der
Zuweisung der Time_us gibt es zwei kritische Zeitpunkte, die im Diagramm dargestellt sind. Es kann zu einem Überlauf des Timers und somit zu einem Interrupt
kommen. Dabei wird die Timebase um weitere 10 Millisekunden aktualisiert. Daher muss anschließend überprüft werden, ob es zu diesem Überlauf kam. Ist der
Wert des Hardware-Timers niedriger als der Variablen, so gab es einen Überlauf.
Hat die Timebase zudem den gleichen Wert der Variablen Time_10ms, so muss
Time_10ms dekrementiert werden. Da sich die Timebase nur alle 10 Millisekunden aktualisiert, wird der Thread vor einer weiteren Aktualisierung beendet sein.
Es daher nicht von weiteren Fehlerquellen auszugehen.
42
Bachelorarbeit
Daniel Schembri
6.3 Systemaufbau und Prozesse im HiTES
In der eCos-Anwendung gibt es zwei zentrale Threads und einen 512KByte
großen Speicher, der in zwei 256KByte große Bereiche aufgeteilt ist. Diese Bereich dienen zum Puffern der UMSG- und UMSGV-Pakete. Ein Thread nimmt
Messdaten entgegen und generiert Zeitstempel. Daraus werden UMSG-Pakete
erzeugt, die auf den Speicher gepuffert werden. Nachdem 256KByte Daten geschrieben wurden, sendet der Thread einem anderen Thread ein Startsignal. Dieser schreibt die Daten auf eine SD-Karte. Dabei verwendet er Funktionen des
Filesystem-Treibers. Gleichzeitig wird auf dem zweiten Speicherbereich die Pufferung der Daten fortgeführt. Ist auch der zweite Bereich gefüllt, wird wieder mit
dem ersten fortgefahren. Wichtig ist hierbei, dass die Threads nicht auf den Bereich des anderen zugreifen.
Folgend eine Darstellung des Gesamtsystems:
Abbildung 6.2: Aufbau des Systems mit SD-Karte (geänderte Abb. von [17 Kap.5.2
Abb.4.1])
43
Bachelorarbeit
Daniel Schembri
Zu Beginn wird eine Initialisierung der Variablen und eine Speicherallokation
durchgeführt. Anschließend werden Testdaten generiert und eine UMSG erzeugt.
Der Zugriff auf die beiden Speicherbereiche ist mit Zeigern realisiert.
Durch dieses Puffer-Verfahren wird es möglich die UMSG-Pakete zum Transfer
über W-LAN abzuzweigen. Hierzu muss lediglich ein weiterer Thread implementiert werden, der einen Zeiger auf die entsprechenden Daten besitzt. Ggf. muss
das Scheduling der Threads angepasst werden.
6.4 Tests der gesamten HiTES-Firmware
Die Firmware wurde auf Performance, Multithreading-Funktionalität und korrekte
Implementierung des Filesystem-Treibers getestet.
6.4.1 Geschwindigkeits-Test
Folgend der Benchmark zur Messung der Schreibgeschwindigkeit des Treibers
auf die SD-Karte:
Abbildung 6.3: Benchmark: Schreiben von 10MByte Testdaten auf die SD-Karte
Um die Geschwindigkeit zu Testen wird ein Benchmark ausgeführt das 10MByte
an Testdaten auf 20480 Sektoren der SD-Karte schreibt. Dabei wird ein MultipleBlockwrite ausgeführt. Die SD-Karte benötigte 76677 Taktzyklen, um die Daten
in ihre Flashspeicher zu schreiben. Das Schreiben war erfolgreich und benötigte
9,5145 Sekunden. 2316 Byte des Stacks wurden dabei belegt.
44
Bachelorarbeit
Daniel Schembri
6.4.2 Filesystem-Test
Folgend der Benchmark zum Test des Schreibens eines UMSGFS-Headers:
Abbildung 6.4: Benchmark: Schreiben eines UMSGFS-Headers mit einem Eintrag auf die
SD-Karte
Bei diesem Test wird ein 512Byte großer Block mit UMSGFS-Headerdaten geschrieben. Dabei wird ein Single-Blockwrite ausgeführt. Das Schreiben des Headers dauert 3,416 Millisekunden und auf dem Stack wurden 2308Bytes belegt.
6.4.3 Multithreading-Test
Folgend ein Benchmark zum Test des Multithreadings in eCos:
Abbildung 6.5: Benchmark: Test des Multithreading in eCos
45
Bachelorarbeit
Daniel Schembri
Bei diesem Benchmark gibt es zwei Threads die abwechselnd Text auf der Konsole ausgeben. Dabei zeigen sie die Verzögerung in Taktzyklen bis zu ihrem Aufruf
an.
Fazit: Der Grundaufbau des Systems funktioniert. Es stehen noch Tests zum
Schreiben von Testmessdaten und zum Betrieb unter Volllast aus.
46
Bachelorarbeit
7
Daniel Schembri
Fazit und Ausblick
Das Ziel dieser Bachelorthesis ist der Entwurf und die Implementierung von Messdatenaufzeichnung einer Bohrlochsonde. Kamerabilder und Messdaten werden
dazu mit einem Zeitstempel versehen und auf eine SD-Karte gespeichert. Zu diesem Zwecke wurde der vorgegebene SD-Controller auf Schaltungsebene erweitert und spricht nun SDHC- und SDXC-Karten an. Die entwickelten Treiber bieten
ausreichend Performance, um alle anfallenden Mess- und Bilddaten auf der SDKarte abzuspeichern. Der Dateisystem-Treiber erzeugt einen Header und erlaubt
es weitere Messfahrteinträge, nach einem Systemreset, hinzuzufügen. Durch Implementierung des Zeitstempelverfahrens in dem Echtzeitbetriebssystem eCos
werden die Datenpakete, zeitlich rekonstruierbar, archiviert. Durch das entwickelte Pufferungs-Verfahren ist es möglich, die anfallenden Mess- und Bilddaten der
Sonde abzuzweigen und diese zeitgleich über das Ethernet zu übermitteln. Auf
einen zuverlässigen Ablauf des Multithreading und der Interruptbehandlung wurde Wert gelegt.
Der Grundaufbau des Systems und die Treiberschichten wurde sowohl bezüglich
der Performance, als auch der Zuverlässigkeit getestet. Ein Test unter Volllast des
Systems mit allen angeschlossenen Sensoren steht noch aus.
47
Bachelorarbeit
8
Daniel Schembri
Literatur- und Quellenverzeichnis
[1] Karlsruher Institut für Technologie KIT
http://www.kit.edu/kit/
Auf der Internetseite finden sich u.A. Informationen zu Instituten
und Forschungsprojekten des KIT.
[2] Xilinx Inc.
DS160 Spartan-6 Family Overview [Online]
http://www.xilinx.com/support/documentation/data_sheets/
ds160.pdf
Das Family-Overview gibt eine Übersicht über die einzelnen FPGAS von
Xilinx.
[3] Daniel Schembri
Implementierung von IP-Cores an den AMBA-Bus eines FPGA-Prozessorsystems zur Realisierung von nebenläufiger Bildverarbeitung
Duale Hochschule Baden-Württemberg Karlsruhe, Projektbericht
4.Semester
In diesem Projektbericht wird auf die Entwicklung von eigenen AMBAIP-Cores eingegangen. Diese können an das Leon3-System angebunden
werden und dienen als Vorlage für andere Cores.
Das AMBA-AHB-Protokoll wird näher erläutert.
48
Bachelorarbeit
Daniel Schembri
[4] Daniel Schembri
Entwicklung und Optimierung von Komponenten und Multitasking einer
Mess-und Bilddaten-GUI, Duale Hochschule Baden-Württemberg
Karlsruhe, Projektbericht 3.Semester
Der Projektbericht behandelt die Verarbeitung der Mess- und Bilddaten am
Bedienstand. Es wird auf die Entwicklung verschiedener Verfahren zur
Optimierung der Datenverarbeitung eingegangen. Darunter Multithreading
und ein Zeitstempelverfahren.
[5] ARM Infocenter
AMBA-Spezifikation [online]
http://infocenter.arm.com/help/index.jsp
Die AMBA-Spezifikation beschreibt ausführlich das AMBA-Bussystem.
Dabei wird auf den Hochgeschwindigkeitsbus AHB und den Peripheriebus
APB eingegangen.
[6] KIT - Institut für Angewandte Informatik
Geothermieprojekt ZWERG [online]
http://geothermiewiki.iai.kit.edu/
Auf der Webseite findet man Informationen zum Geothermieprojekt
ZWERG. Es gibt eine Sammlung wissenschaftlicher Arbeiten rund um
die Bohrlochsonde.
[7] Isele, Jörg
Zwischenbericht - Kamerainspektionssystem für tiefe Geothermiebrunnen GeoKam, KIT, 2013
Im Zwischenbericht wird auf die technischen Komponenten der Sonde
eingegangen. Außerdem wird ein Resümee zum aktuellen Stand des
Projektes gezogen.
49
Bachelorarbeit
Daniel Schembri
[8] Antes, Martin
Entwicklung und Konstruktion eines Gehäuses zum Wärmemanagement
einer Inspektionssonde für Geothermiebrunnen, Diplomarbeit, KIT, 2013
Die Diplomarbeit geht näher auf das Dewargefäß in der Sonde ein.
[9] Aeroflex Gaisler AB.
GRLIB IP-Library
Die GRLIB ist eine Sammlung von IP-Cores, die sich an das LEON3System von Gaisler anbinden lassen. Dieses wird z.B. in Satelliten der
ESA eingesetzt.
[10] Reichardt, Jürgen und Schwarz, Bernd
VHDL-Synthese – Entwurf digitaler Schaltungen und Systeme,
München : Oldenbourg-Verlag, 2007
Sehr praxisnahes Buch das von Grund auf die Entwicklung mit VHDL
erläutert.
[11] Sauer, Peter
Hardware-Design mit FPGA – Eine Einführung in den Schaltungsentwurf
mit FPGA-Bausteinen. Aachen : Elektor-Verlag, 2010.
Das Buch bietet eine kompakte Zusammenfassung und Beispiele zu VHDL.
[12] Kesel, Frank und Bartholomä, Ruben
Entwurf von digitalen Schaltungen und Systemen mit HDLs und FPGAs –
Einführung mit VHDL und SystemC. München : Oldenbourg-Verlag, 2009.
Das Buch beschreibt sehr ausführlich die wichtigsten Aspekte über den
Entwurf von digitalen Schaltungen mit VHDL. Dabei wird auch auf
typische Anfängerfehler eingegangen.
50
Bachelorarbeit
Daniel Schembri
[13] Motorola Mobility LLC.
M68HC11 Reference Manual
In Kapitel 8 wird auf das SPI-Protokoll eingegangen.
[14] SD Group
SD Specifications Part 1 Physical Layer Simplified Specification
Version 4.10
https://www.sdcard.org/downloads/pls/simplified_specs/
part1_410.pdf
Das Dokument enthält die wichtigsten Spezifikation zu SD-Karten.
[15] Chlazza
Secure Digital (SD) Card Spec and Info [online], 2010
www.chlazza.net/sdcardinfo.html
Die Webseite erläutert das SPI-Protokoll im Zusammenhang mit SD-Karten.
[16] Aeroflex Gaisler AB.
GRIP
Die GRIP beschreibt den Aufbau der IP-Cores von Gaisler
und geht auch auf die konkrete Implementierung ein.
[17] Frueh, Aaron
Entwicklung eines Echtzeit-Kernel zur Hochgeschwindigkeitsubertragung
für das High-Temperature-Embedded-System einer Bohrlochsonde,
Duale Hochschule Baden-Württemberg Karlsruhe, Bachelorarbeit
Die Bachelorarbeit von Aaron Frueh geht auf die Konzeption eines Echtzeitsystems basierend auf eCos ein.
51
Bachelorarbeit
Daniel Schembri
[18] International Telecommunication Union (ITU)
ITU-T Recommendation X.200
http://www.itu.int/rec/T-REC-X.200-199407-I
Das Dokument spezifiziert das OSI-Schichtenmodell.
[19] Deutsches Institut für Normung
Informationsverarbeitung - Begriffe, DIN43000.
Beuth-Verlag, Berlin, Köln, 1985
[20] Scholz, Peter
Softwareentwicklung Eingebetteter Systeme
Das Buch geht auf Echzeit in eingebettenen System ein
[21] Embedded Software Development wirth eCos
eCos Developer Guide
Das Dokument erläutert Hintergrundinformationen und die Vorgehensweise
zur Anwendungsentwicklung mit eCos
52
Bachelorarbeit
9
Daniel Schembri
Anhang
Die wichtigsten Dokumente und der Quellcode dieser Bachelorarbeit sind auf der
beigelegten CD enthalten.
Darunter:
• Quellen im PDF-Format und ggf. den dazugehörigen Quellcode
• Der Modifizierte SPIM-Ctrl-Core
• Die Treiber und die eCos-Anwendung
• Die Bachelorarbeit als PDF
53