62
Hochschule für Technik und Wirtschaft Dresden (FH) Fakultät Informatik/Mathematik Diplomarbeit im Studiengang Informatik Thema: Portierung des Betriebssystems Contiki auf die Blackfin-Architektur Eingereicht von: Marcus Dreier Eingereicht am: 28.09.2010 Betreuender Hochschullehrer: Herr Prof. Dr.-Ing. R. Baumgartl

Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Hochschule für Technik undWirtschaft Dresden (FH)

Fakultät Informatik/Mathematik

Diplomarbeitim Studiengang Informatik

Thema:Portierung des Betriebssystems Contiki auf die Blackfin-Architektur

Eingereicht von: Marcus DreierEingereicht am: 28.09.2010Betreuender Hochschullehrer: Herr Prof. Dr.-Ing. R. Baumgartl

Page 2: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart
Page 3: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einführung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Stand der Technik 32.1 Blackfin-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Prozessorkern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Bus- und Speicheraufbau . . . . . . . . . . . . . . . . . . . . . . 52.1.3 Direkter Speicherzugriff . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.4.1 Kerntimer . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4.2 Watchdogtimer . . . . . . . . . . . . . . . . . . . . . . . 92.1.4.3 Echtzeittimer . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4.4 Mehrzwecktimer . . . . . . . . . . . . . . . . . . . . . . 9

2.2 BF-537 STAMP Evaluierungsboard . . . . . . . . . . . . . . . . . . . . . 102.3 Contiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.2 Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2.1 Protothreads als Basis von Prozessen . . . . . . . . . . 132.3.2.2 Multithreading . . . . . . . . . . . . . . . . . . . . . . . 142.3.2.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . 15

2.3.3 Echtzeitaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.3.1 Prozessmodell . . . . . . . . . . . . . . . . . . . . . . . 162.3.3.2 Multithreading . . . . . . . . . . . . . . . . . . . . . . . 172.3.3.3 Taskplaner . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.4 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.5 Speicherverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Konzept 223.1 Portierungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Einbindung des Bootloaders . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Linker-Anpassungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 LED-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

I

Page 4: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Inhaltsverzeichnis

3.5 UART-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.1 Terminal-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.5.2 SLIP-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Netzwerktreiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Implementierung 334.1 Newlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Clock-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.2 Realtime-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.4 Zeitmessung von Codeabschnitten . . . . . . . . . . . . . . . . . . . . . 384.5 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Leistungsbewertung 415.1 Zeitmessung der Erstellung und des Wechsels von Prozessen und Threads 415.2 Vergleich der Netzwerkperformance zwischen Contiki und Linux . . . . . 435.3 Ermittlung des Speicherverbrauchs . . . . . . . . . . . . . . . . . . . . . 44

6 Zusammenfassung und Ausblick 466.1 Thesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Bezugsquellen der Software . . . . . . . . . . . . . . . . . . . . . . . . . 48

Literatur 49

Selbständigkeitserklärung 52

II

Page 5: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Abbildungsverzeichnis

Abbildungsverzeichnis

2.1 Blockschaltbild des BF-537 (entnommen [Adh, S. 1-4]) . . . . . . . . . . 42.2 Contiki-Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Contiki-Prozessbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Speicherregionen zur Programmaufteilung auf dem BF-537 . . . . . . . 253.2 UART-Funktionsdiagramm im Terminal-Modus (Auszug) . . . . . . . . 283.3 MAC-Funktionsdiagramm (Auszug) . . . . . . . . . . . . . . . . . . . . 30

4.1 Multithreading-Funktionsdiagramm (Auszug) . . . . . . . . . . . . . . . 36

III

Page 6: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Tabellenverzeichnis

Tabellenverzeichnis

2.1 Registersatz des BF-537 . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Speicherlayout des BF-537 im Überblick . . . . . . . . . . . . . . . . . . 62.3 Vergleich zwischen Prozessmodell und Multithreading . . . . . . . . . . 15

3.1 Basisaufgaben für die Portierung . . . . . . . . . . . . . . . . . . . . . . 223.2 Contiki Portierungsaufgaben für Blackfin . . . . . . . . . . . . . . . . . 23

5.1 Messung des Thread- und Prozessverhaltens (8000 Messungen) . . . . . 425.2 Vergleich der Netzwerkperformance zwischen Contiki und uClinux . . . 435.3 Speicherverbrauch von Contiki inklusive einer Applikation (in Byte) . . 45

IV

Page 7: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Abkürzungsverzeichnis

Abkürzungsverzeichnis

ALU Arithmetic Logic UnitAPI Application Programming InterfaceBSD Berkeley Software DistributionBSS Block Started by SymbolCAN Controller Area NetworkCCLK Core ClockCD Collision DetectionCFS Contiki File SystemCISC Complex Instruction Set ComputingCPU Central Processing UnitCSMA Carrier Sense Multiple AccessCVS Concurrent Versions SystemDAB DMA Access BusDAG Data Adress GeneratorDMA Direct Memory AccessDSP Digital Signal ProcessorELF Executable and Linking FormatFFT Fast Fourier TransformationI/O Input/OutputICMP Internet Control Message ProtocolIPC Inter Process CommunicationIPv4 Internet Protocol Version 4IPv6 Internet Protocol Version 6ISR Interrupt Service RoutineJTAG Joint Test Action GroupMAC Media Access ControllerMCU Micro Controller UnitMEMB Memory Block ManagementMII Media Independent InterfaceMMEM Managed Memory AllocatorMMR Memory Mapped RegisterMMU Memory Management UnitMPU Memory Protection UnitNFS Network File System

V

Page 8: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Abkürzungsverzeichnis

NMI Non Maskable InterruptOSI Open Systems Interconnection ModelPAB Peripheral Access BusPPI Parallel Peripheral InterfacePPP Point to Point ProtocolPWM Pulse Width ModulationRAB Register Access BusRAM Random Access MemoryRISC Reduced Instruction Set ComputingROM Read Only MemoryRTC Real Time ClockSCLK System ClockSDRAM Synchronous Dynamic Random Access MemorySICS Swedish Institute of Computer ScienceSIMD Single Instruction Multiple DataSLIP Serial Line Internet ProtocolSPI Serial Peripheral Interface BusSRAM Static Random Access MemoryTCP Transmission Control ProtocolTFTP Trivial File Transfer ProtocolTWI Two Wire InterfaceUART Universal Asynchronous Receiver TransmitterUDP User Datagram ProtocolVLAN Virtual Local Area NetworkWLAN Wireless Local Area NetworkWSN Wireless Sensor Network

VI

Page 9: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Danksagung

Danksagung

An dieser Stelle möchte ich allen, die zum Gelingen und erfolgreichen Abschluss dieserDiplomarbeit beigetragen haben, herzlich danken. An erster Stelle danke ich HerrnProf. Dr.-Ing. R. Baumgartl für die Vergabe des Themas, der sehr guten Betreuungund fachlichen Beurteilung der Diplomarbeit. Für die Begutachtung dieser Arbeitund zahlreiche Hinweise bedanke ich mich bei meinen Freunden Philipp Gläßer undDirk Dankhoff. Mein Dank gilt außerdem meiner Freundin Bettina für das aufwendigeKorrekturlesen. Nicht zuletzt möchte ich mich bei meiner Familie für viele aufmunterndeWorte und die ständige Unterstützung während des Studiums bedanken.

VII

Page 10: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

1 Einführung

1 Einführung

1.1 Aufgabenstellung

Die vorliegende Diplomarbeit thematisiert die Portierung des freien BetriebsystemsContiki auf die Analog Devices Blackfin-Architektur. Dabei sollen sowohl die spezifischenEigenschaften von Hard- und Software herausgestellt, als auch die unterschiedlichenAnsätze bei den konzeptionierten Softwaremodulen diskutiert werden. Als Ergebnis sollneben dieser theoretischen Betrachtung das Betriebssystem so erweitert werden, dassdie wichtigsten Hardwarekomponenten auf dem Evaluierungsboard BF-537 STAMPuneingeschränkt mit Contiki nutzbar sind. Weiterhin ist beabsichtigt, die Performancedes neu entstandenen Systems zu ermitteln und mit anderen Betriebssystemen zuvergleichen. Anschließend sollen Rückschlüsse auf mögliche Einsatzbereiche aus derKombination von Blackfin und Contiki gezogen werden.

1.2 Motivation

Digitale Signalprozessoren (DSPs) sind aus unserem Alltag nicht mehr wegzudenken.Sie finden Verwendung in vielen Bereichen der Unterhaltungselektronik, im Mobilfunk-bereich und der Automatisierungstechnik. DSPs lösen dabei häufig Probleme bei derVerarbeitung von Audio- und Videosignalen. Sie unterscheiden sich von Universalpro-zessoren, da sie bestimmte mathematische Operationen besonders effektiv anwendenkönnen. Diese Spezialisierungen zielen besonders auf die Optimierung von diskretenAlgorithmen und Filtern ab.

Der BF-537, ein Modell aus der Blackfin-Prozessorfamilie, ist ein aktueller und leis-tungsfähiger DSP, der sich durch eine Vielzahl an integrierten Peripheriekomponentenauszeichnet.

Bei Contiki handelt es sich um ein speicherplatzsparendes Betriebssystem, das bisherfür eine Reihe von Mikrocontrollern portiert wurde. Es besitzt eine eventgesteuer-te Architektur, einen integrierten TCP/IP-Netzwerkstack sowie eine Reihe weitererHardwaresubsysteme.

1

Page 11: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

1 Einführung

Auf einen DSP wurde Contiki bisher noch nicht portiert. Die vorliegende Arbeit soll nunklären, wie gut sich Contiki für die Arbeit mit DSPs eignet und ob die Anforderungender digitalen Signalverarbeitung erfüllt werden können. Zu diesen Anforderungen zählenEchtzeitfähigkeit, eine kurze Latenzzeit bei eintreffenden Ereignissen sowie ein ressour-censparender Umgang mit der eingesetzten Hardware. Vor allem durch den letzten Punktzeichnet sich Contiki aus, da alle bisher bekannten und nichtkommerziellen Betriebssys-teme, die für Blackfin portiert worden (uClinux, eCos), deutlich mehr Ressourcen fürsich selbst beanspruchen. Ob Contiki in der Lage ist, harten Echtzeitanforderungen zugenügen, wurde bisher noch nicht untersucht und soll ebenfalls Gegenstand dieser Arbeitsein. Contiki soll in Verbindung mit den zu entwickelnden Erweiterungen zu einemeffizienten, einfach benutzbaren und kompakten Betriebssystem für Blackfin zusam-mengesetzt werden. Dieses soll dem Applikationsentwickler größtmögliche Flexibilitätund eine produktive Umgebung unter Bereitstellung aller notwendigen Treiber undFunktionen bieten.

Es ist beabsichtigt, das Gesamtsystem zu Lehr- und Forschungszwecken an der FakultätInformatik/Mathematik im Fachbereich Betriebssysteme der HTW-Dresden einzusetzen.

1.3 Aufbau der Diplomarbeit

Die vorliegende Arbeit ist in sechs Kapitel gegliedert. Sie soll den Portierungsprozess,beginnend mit der Erarbeitung der technischen Grundlagen über den Planungs- undImplementierungsvorgang, bis hin zur Bewertung und Zusammenfassung der Ergebnissedarstellen. Kapitel 2 befasst sich mit den gegebenen Grundlagen von Blackfin undContiki. Dabei wird insbesondere das Contiki-Prozesssystem analysiert, um anschließendRückschlüsse auf die Tauglichkeit im Echtzeitbereich zu ziehen. In Kapitel 3 werdenKonzepte, die für die Softwarelösung entworfen werden, dargestellt und begründet.Konkrete Problemstellungen bei der Implementierung werden anhand einiger Beispielein Kapitel 4 beschrieben. Kapitel 5 beinhaltet die Bewertung und den Vergleich derLeistungsfähigkeit des Systems zu anderen. Schließlich wird die Arbeit im KapitelZusammenfassung abgerundet, und es werden Anregungen für zukünftige Entwicklungengegeben.

2

Page 12: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

2 Stand der Technik

2.1 Blackfin-Architektur

Dieses Kapitel befasst sich mit dem grundlegenden Aufbau der Analog Devices Blackfin-Prozessorreihe, um die notwendigen Kenntnisse von der Architektur für den weiterenPortierungsprozess zu vermitteln. Konkret wird hierbei auf das DSP-Modell BF-537eingegangen. Als Referenz für dieses Kapitel diente hauptsächlich die Blackfin HardwareReferenz (siehe [Adh]).

Bei Blackfin handelt es sich nicht um eine reine DSP-Architektur, vielmehr ist es eineKombination aus Micro Controller Unit (MCU) und DSP. Kennzeichnend dafür istdie Integration zusätzlicher Komponenten (Timer, Universal Asynchronous ReceiverTransmitter (UART), Ethernet, etc.), die im Bereich eingebetteter Systeme häufigbenötigt werden.

Abbildung 2.1 zeigt das Blockschaltbild der Blackfin-Architektur. Neben dem Prozessor-kern, in dem sich die Recheneinheit befindet, werden alle weiteren logischen Bestandteileund deren Busverbindungen schematisiert. Die nachfolgenden Unterkapitel beschreibeneinige Komponenten dieses Schaltbildes näher.

3

Page 13: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Abbildung 2.1: Blockschaltbild des BF-537 (entnommen [Adh, S. 1-4])

2.1.1 Prozessorkern

Der Kern des DSPs ist ähnlich einer Reduced Instruction Set Computing (RISC)-Architektur aufgebaut. Dabei wird auf komplexe Befehle, die viele Taktzyklen beanspru-chen, verzichtet. Es sind allerdings mehr Register vorhanden als bei der gegensätzlichenComplex Instruction Set Computing (CISC)-Architektur, da notwendigerweise mehrZwischenergebnisse bei Berechnungen gespeichert werden müssen.

Die Adressbreite beträgt 32-Bit. Arithmetische und logische Operationen können auf8-, 16- und 32-Bit-Register angewandt werden. Da Operationen mit Fließkommazahlendeutlich komplexer sind, benötigen sie mehr Taktzyklen zur Verarbeitung. Um einebeschleunigte Ausführungsgeschwindigkeit zu erzielen, ist deshalb bei Blackfin nurFestkommaarithmetik möglich.

Die folgenden Merkmale zeichnen den CPU-Kern der Blackfin-Architektur aus:

• Zwei Arithmetic Logic Units ALUs, um parallel arithmetische und logische Opera-tionen mit max. 40-Bit breiten Ergebnissen zu ermöglichen

• Vier 8-Bit-Video ALUs zur Verwendung von Single Instruction Multiple Data(SIMD)-Operationen (eine Rechenoperationen wird parallel auf mehrere Registerangewandt)

4

Page 14: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

• Zwei 16-Bit-Multiplikationsakkumulatoren zur Durchführung von Multiplikationenmit andschließender Additionen oder Subtraktionen während eines Taktzyklus(notwendig unter anderem bei häufig eingesetzten Algorithmen wie der Fast FourierTransformation (FFT))

• Ein Barrel-Shifter, der ein Register um mehrere Stellen in einem Taktzyklusverschiebt

• Zwei Data Adress Generators DAGs zur Berechnung von effektiven Adressen undindizierten Speicherzugriffen

Die in Tabelle 2.1 aufgelisteten Register stehen dem Entwickler zur freien Verfügung.

Tabelle 2.1: Registersatz des BF-537

Register Funktion BemerkungR0 ... R7 Datenregister 32-Bit-Register zur freien Verwendung, möglich ist der

16-Bit-Zugriff über Registerpostfixe .h und .lP0 ... P5 Pointerregister beinhalten die 32-Bit-Adressen von DatenstrukturenSP Stackpointer aktuelle Stackadresse, wächst in negativer RichtungFP Framepointer zeigt auf den Beginn des aktuellen Frames (Kontext)A0, A1 Akkumulatorregister 40-Bit-Datenregister, welche aktuell zu bearbeitende

Daten enthaltenLC0, LC1 Schleifenzählregister Zero-Overhead SchleifenzählerLT0, LT1 Schleifenanfangsregister Anfangsadresse einer Zero-Overhead SchleifeLB0, LB1 Schleifendregister Endadresse einer Zero-Overhead SchleifeB0 ... B3 Basisregister kennzeichnen den Anfang eines RingpuffersI0 ... I3 Indexregister indizierter Zugriff auf zugehörigen RingpufferM0 ... M3 Änderungsregister Berechnung der Offsetadresse des zugehörigen Ring-

pufferL0 ... L3 Längenregister Längenangabe des zugehörigen Ringpuffer

2.1.2 Bus- und Speicheraufbau

Die Aufteilung der Speicherbusse erfolgt bei Blackfin nach dem Prinzip der angepasstenHarvard-Architektur. Wie bei der einfachen Harvard-Architektur werden Daten- undBefehlsspeicher separiert und über getrennte Busse an die CPU angeschlossen. ImUnterschied dazu befinden sich diese unterschiedlichen Inhalte in einem gemeinsamenAdressraum. Da andernfalls der Befehlscode bei seiner Ausführung immer erst in dasCodesegment verschoben werden müsste, ergäbe sich eine größere Komplexität bei

5

Page 15: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Kompilern von höheren Programmiersprachen wie C. Die Harvard-Architektur bietetgegenüber der von-Neumann-Architektur den Vorteil, dass Befehle und Daten parallelgeladen werden können. Nachteilig kann sich bei der modifizierten Variante der gemein-same Adressraum auswirken. Falls ein Programmfehler zu einem Pufferüberlauf führt,kann das Codesegment dabei überschrieben werden. Dadurch wird das Einschleusenvon Schadsoftware ermöglicht. Bei Blackfin hat der gesamte Speicherbereich einenAdressraum von 4 GB. Die wichtigsten Bestandteile dessen sind in Tabelle 2.2 vermerkt.

Tabelle 2.2: Speicherlayout des BF-537 im Überblick

Adressraum Name Beschreibung0xFFE0 0000 -0xFFFF FFFF

Kern-MMR-Register (2 MB)

je 32-Bit lang, dienen der Prozessorsteuerung,angeschlossen an RAB, Takt: CCLK

0xFFC0 0000 -0xFFEF FFFF

System-MMR-Register (2 MB)

je 16-Bit oder 32-Bit lang, werden verwendet,um Peripherieeinheiten zu steuern, angeschlos-sen an PAB, Takt: SCLK

0xFFB0 0000 -0xFFB0 0FFF

Scratchpad-L1-SRAM (4 kB)

kann als Daten-RAM verwendet werden, DMA-Controller kann darauf zugreifen, Takt: CCLK

0xFFA0 0000 -0xFFA1 3FFF(unterbrochen)

Code-L1-SRAM(64 kB)

kann wahlweise als Befehlsspeicher oder 4-Wege-Assoziativcache verwendet werden, Takt:CCLK

0xFF80 0000 -0xFF90 7FFF(unterbrochen)

Daten-L1-SRAM(64 kB)

kann wahlweise als Daten-RAM oder 2-Wege Assoziativcache verwendet werden, Takt:CCLK

0x0000 0000 -0x1FFF FFFF

externer SDRAM(16 MB - 128 MB)

externer SDRAM, frei verwendbar, angeschlos-sen über 16-Bit-Busverbindung, Takt: 133 MHz

Die einzelnen Busse, an denen die DSP-Komponenten angebunden sind (ersichtlich inAbb. 2.1), werden unterschiedlich getaktet. Die Register und das Rechenwerk sind überden Register Access Bus (RAB) miteinander verbunden. Dessen Taktung wird überdie Core Clock (CCLK) bestimmt und beträgt beim BF-537 500 MHz. Der PeripheralAccess Bus (PAB) wird bei der vorliegenden Ausführung mit der langsameren Taktrateder System Clock (SCLK) von 125 MHz betrieben. An diesen Bus sind alle peripherenKomponenten des Prozessors gekoppelt. Damit kann zum einen die Peripherie über dieSystem Memory Mapped Register (MMR)s gesteuert werden (z.B. zum Aktivieren/Deak-tivieren und dem Setzen von Initialisierungsparametern), und zum anderen dient er demTransferieren von Daten aus und in CPU-Register. Einige Komponenten sind zusätzlichüber den DMA Access Bus (DAB) an den Direct Memory Access (DMA)-Controllerangeschlossen. Der lesende oder schreibende Zugriff auf den Speicher erfolgt dabei im

6

Page 16: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Hintergrund der Programmausführung (Näheres siehe Kapitel 2.1.3).

Die Memory Management Unit (MMU) besitzt nur einen eingeschränkten Funktions-umfang. Sie kann als Memory Protection Unit (MPU) definierte Adressbereiche vorunerlaubtem Speicherzugriff schützen. Bei konventionellen CPUs hingegen unterstütztsie das Betriebssystem, um einen eigenen Adressraum für jeden Prozess bereit zu stel-len. Dabei bilden virtuelle Adressen den Adressraum unabhängig vom physischen ab(Näheres siehe [Wik10b]). Dieses Prinzip bietet zwar eine Reihe von Vorteilen, darunterdie Verhinderung der Speicherfragmentierung, ist allerdings komplex in der Umsetzungund verlängert die Zugriffszeiten auf den Speicher. Grund hierfür ist die Verdoppelungder Speicherzugriffe, da einmal auf die Seitentabelle und einmal auf die reale Adressezugegriffen werden muss. Bei Blackfin wird deshalb auf virtuellen Speicher verzichtet.

Der SDRAM ist bei der vorliegenden Konfiguration viermal langsamer als die CPUgetaktet. Deshalb führen Zugriffe darauf zu Geschwindigkeitseinbußen bei der Program-mausführung. Da die Ausführungsgeschwindigkeit ein wichtiges Kriterium für DSPsdarstellt, wurde in Blackfin ein schnellerer Speicher, der L1-SRAM, welcher mit derCCLK-Frequenz betrieben wird, integriert. Dieser ist, wie in Abbildung 2.1 ersichtlich,in Befehls- und Datenspeicher aufgeteilt und lässt sich als Daten-/Befehlscache oder alsherkömmlicher Speicher nutzen (Näheres siehe [Get09a]).

2.1.3 Direkter Speicherzugriff

Eine Funktion, welche die Leistungsfähigkeit der Blackfin-Architektur erheblich ver-bessert, ist DMA. Damit ist es möglich, Daten ohne Umweg über den CPU-Kern zutransferieren. Verbindungswege mit direktem Speicherzugriff können sein:

• Innerhalb internen Speichers (Memory DMA Transfer)

• Zwischen internem und externen Speicher unter Berücksichtigung unterschiedlicherTaktung (Handshaking Memory DMA Transfer)

• Zwischen peripheren Komponenten und internem oder externen Speicher (Peri-pheral DMA Transfer)

Die zuletzt genannte Methode kommt bei dieser Portierung als einzige für den Netz-werktreiber zum Einsatz.

7

Page 17: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Damit DMA-Zugriff möglich ist, werden der UART und der Ethernet Media AccessController (MAC) über jeweils einen dedizierten Lese- und Schreibkanal an den DMA-Controller über den DAB angebunden. Im Unterschied dazu teilen sich die SchnittstellenSPI und PPI einen Kanal für beide Übertragungsrichtungen.

Zur Aktivierung von DMA muss die benötigte Menge Speicherplatz in Regionen festerGröße reserviert werden. Eine DMA-Region bei Blackfin kann entweder eindimensionaloder zweidimensional adressiert werden. Letztere Adressierung ist beispielsweise für dieparallele Übertragung von zweidimensionalen Datenobjekten, wie Grafiken, sinnvoll.Eine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählendie Betriebsart (Eindimensional oder Zweidimensional, Interruptbetrieb, etc.), dieAnfangsadresse der Speicherregion (L1-Daten SRAM oder externer Speicher) undInformationen über die maximale und bereits transferierte Anzahl von Daten dieserRegion.

Die Initialisierung einer DMA-Region kann auf zwei verschiedene Arten geschehen,entweder register- oder deskriptorbasiert. Beim registerbasierten Verfahren werden dieParameter über MMRs gesetzt, wohingegen beim deskriptorbasierten die Parameter inListen- oder Array-Strukturen im Speicher abgelegt sind. Beide Adressierungsverfahrenbesitzen ihre Vor- und Nachteile. Das registerbasierte Verfahren kann prinzipiell schnellerarbeiten als das deskriptorbasierte, da zum Verarbeiten der Konfiguration aufwendigeSpeicherzugriffe entfallen. Es ermöglicht aber nur eine konfigurierte DMA-Region. NachAbschluss eines Transfers wird die Konfiguration der betroffenen Region entwederauf die Anfangswerte zurückgesetzt (Autobuffer Mode), oder sie muss manuell neuinitialisiert werden (Stop Mode). Der zuletzt genannte Modus ist dabei vor allem für diesynchrone Datenübertragung sinnvoll. Dem gegenüber erlaubt das Deskriptorverfahrendie Konfiguration beliebig vieler DMA-Regionen, welche automatisch und zirkulärgewechselt werden, ohne dass der Prozessorkern eingreifen muss.

2.1.4 Timer

Timer spielen eine wichtige Rolle, um Aktionen nach einer definierten Zeitspanneauszuführen. Dabei sind sie eine Art Zähler, die bis zu einem definierten Wert in einemfestgelegten Takt hoch oder runterzählen und beim Erreichen des Wertes ein Ereignisauslösen. Eingesetzt werden sie beispielsweise als Uhren, als Pulse Width Modulation(PWM) Taktgeber oder in Echtzeitanwendungen. Die bei Blackfin eingesetzten Timerkönnen Interrupts auslösen. Sie unterscheiden sich hinsichtlich ihrer Anwendungsbereicheund Auflösungen.

8

Page 18: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

2.1.4.1 Kerntimer

Der Kerntimer zeichnet sich dadurch aus, dass er mit der CCLK-Taktrate betriebenwird. Dadurch erreicht er die maximal mögliche Auflösung des Prozessors und kann beiMessungen, die einer hohen Genauigkeit bedürfen, eingesetzt werden. Dabei kann er füreine einzelne oder periodische Messung aktiviert werden.

2.1.4.2 Watchdogtimer

Dieser Timer ist als ein eigener Schaltkreis innerhalb des DSPs integriert und wirdüblicherweise zur Überwachung der Systemstabilität verwendet. Dabei muss er an be-stimmten Stellen im Programmablauf periodisch auf einen festgelegten Wert gesetztwerden. Wenn der Timer nicht rechtzeitig zurückgesetzt wird, signalisiert dies einenAusnahmezustand (siehe [Adp, S. 4-65]). Infolgedessen wird ein nichtdeaktivierbarerHardwareinterrupt (NMI) ausgelöst, welcher in den meisten Fällen das System zurück-setzt und neu startet. Eine weitere Anwendungsmöglichkeit für den Watchdogtimerstellt das periodische „Wecken“ des Prozessors aus dem Energiesparmodus dar.

2.1.4.3 Echtzeittimer

Die Besonderheit dieses Timers besteht darin, dass er mit einer außerhalb der CPUangebrachten Real Time Clock (RTC) betrieben wird. Diese kann so skaliert werden,dass sie sehr genau die Frequenz von 1 Hz einhält. Dabei stehen für diesen Timer nichtnur ein, sondern vier Register zur Verfügung. Die Sekunden-, Minuten-, Stunden- undTagesregister werden dabei nach der allgemeinen Zeitumrechnung geschaltet. Üblicher-weise wird er deshalb als Uhr eingesetzt. Beim Umschalten eines Registers könnenebenfalls Interruptroutinen ausgelöst werden.

2.1.4.4 Mehrzwecktimer

Hierbei handelt es sich um eine Komponente, die es ermöglicht acht voneinanderunabhängige Timer zu benutzen. Neben dem einfachen und periodischen Betrieb sindsie in der Lage einzelne Ausgänge des DSPs für eine bestimmte Dauer zu aktivieren oderzu deaktivieren. Damit können beliebige Phasen zur PWM erzeugt werden, welche manunter anderem zur Steuerung von Motoren einsetzt. Das Erfassen der Dauer von digitalenSignalen an den Eingängen des Digital Signal Processor (DSP)s kann damit auch

9

Page 19: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

vermessen werden. Somit wird beispielsweise eine automatische Baudratenerkennungfür den UART ermöglicht.

2.2 BF-537 STAMP Evaluierungsboard

Dieses Board entstand als Open Source Hardwareprojekt der uClinux-Arbeitsgruppe.Hierbei dürfen die Schaltpläne und das Boardlayout frei verwendet und angepasst werden.Als CPU kommt der BF-537 zum Einsatz, dessen integrierte Peripheriekomponentenüber das Board mit Anschlüssen versehen sind. So können JTAG, SPI, PPI, Ethernet,UART und andere Komponenten sofort angeschlossen und verwendet werden. Integriertsind weiterhin LEDs und Taster sowie eine Spannungsversorgung. Speicherbausteinebefinden sich ebenso auf dem Board. Damit stehen dem Anwender 64 MB SDRAM und4 MB Flashspeicher zur Verfügung. Insgesamt eignet sich dieses Board sehr gut dafür,die vielfältigen Möglichkeiten der Blackfin-Architektur zu testen.

2.3 Contiki

Bei Contiki handelt es sich um ein ressourcensparendes Betriebssystem mit eventbasier-tem Prozessmodell, das einer BSD-artigen Lizenz unterliegt. Initiiert und weiterentwickeltwird das Projekt maßgeblich von dem Projektleiter und Erfinder Adam Dunkels so-wie einer Reihe weiterer Personen des Swedish Institute of Computer Science (SICS).Es ermöglicht optional Multithreading als Alternative zu Prozessen und bietet nachAussagen der Entwickler den mit 1.8 kB kleinsten voll kompatiblen TCP/IPv4 undIPv6 Netzwerkstack (siehe [Abe08]). Ein weiterer Schwerpunkt stellt die Entwicklungstromsparender Kommunikationsstacks für Funknetzwerke dar, wie beispielsweise Con-tikiRPL und RIME (siehe [Tsi10] und [Dun07b]). Ein wichtiger Anwendungsbereichist daher der Einsatz in Wireless Sensor Networks (WSNs) (Näheres siehe [Wik10c]).Das Contiki-Kernsystem wurde in C implementiert und besitzt weder virtuellen Spei-cher noch Speicherschutzmechanismen. Ausführbar ist das Betriebssystem bereits auf8-Bit-Prozessoren mit mehr als 2 kB RAM (ohne Netzwerkunterstützung). Zu denbereits portierten Architekturen zählen insbesondere Mikrocontroller, darunter derTexas Instruments MSP430 und der Atmel AVR.

Contiki ist entwickelt worden, um die beschriebenen Funktionen mit beschränkten Hard-wareressourcen zu ermöglichen. Dabei bietet es dem Entwickler ein hinreichendes Maß anAbstraktion bei gleichzeitiger Nähe zur Hardware. Hinsichtlich seines Funktionsumfangs

10

Page 20: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

und der Anzahl an verfügbarer Software ist es jedoch nicht mit Universalbetriebssyste-men wie Linux vergleichbar. In diesem Kapitel werden die wichtigsten Konzepte unddie portierungsrelevanten Bestandteile des Betriebssystems näher erläutert.

2.3.1 Architektur

Contiki ist modular aufgebaut, besitzt aber keine Hardwareabstraktionsschicht. Dasheißt, Applikationen und Treiber können direkt auf die Hardware zugreifen. Somit wirdder Kernel kompakt gehalten. Der Aufbau des Betriebssystems kann in einem Schich-tenmodell zusammengefasst werden. In Abbildung 2.2 werden die Kernkomponentendavon illustriert.

Sensoren

LEDELF-Loader

Clock

TimerCFS

Energest

Plattform

integrierte Services

Webserver

FTP

Serial Shell

Telnet IRC

RIME

Process

SLIP

Kern

Threads Routing PPPuIP

Treiber

eigene Services

Applikationsprozesse

...

...

Net

Twitter

Webbrowser

CPU

Editor

Libraries

Protothreads

...

Abbildung 2.2: Contiki-Schichtenmodell

Gerätetreiber liegen in dem Modell auf der untersten Ebene. Sie werden in einen CPU-und einen plattformspezifischen Teil untergliedert. Im „cpu“-Verzeichnis existierenTreiber für integrierte Peripherien (Timer, UART, etc.) und architekturabhängigeImplementierungen einzelner Subsysteme, beispielsweise für Threads. Im „platform“-Verzeichnis liegen dagegen Treiber, für Geräte die mit der CPU gekoppelt sind.

In der darüberliegen Schicht befindet sich der Kern beziehungsweise Kernel. Dieser

11

Page 21: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

beinhaltet keinen architekturabhängigen Code mehr, sondern stellt plattformunabhängigunterschiedliche Module und Bibliotheken bereit, unter anderem für Threads und Timer.Falls diese Module an die Hardware angepasst werden müssen, existieren definierteSchnittstellen, die der jeweilige Treiber implementiert haben muss.

Der ELF-Loader nimmt im Betriebssystemkern eine besondere Stellung ein. BeimExecutable and Linking Format (ELF) handelt es sich um ein standardisiertes Binärfor-mat für ausführbare Dateien, wie es von Contiki und anderen Betriebssystemen (Linux,BSD, etc.) verwendet wird. Der Loader ermöglicht es, zur Laufzeit einzelne Module desSystems zu aktualisieren. Diese Updates sind dabei auf Services und Nutzerprozessebeschränkt. Das Prinzip unterscheidet sich unter anderem von Linux-Kernelmodulen,bei denen neue Programmfragmente zur Laufzeit durch eine Reihe von Tools gegen denKernel gelinkt werden. In Contiki übernimmt diese Aufgabe der Kernel selbst. Nachdem Laden des neuen Programmteils in den ROM oder Flash-Speicher wird versucht,den erforderlichen Speicher für das neue Programmfragment zu allozieren. Gelingtder Vorgang, wird die Initialisierungsfunktion des neuen Prozesses aufgerufen. Dieseaktualisiert im Codesegment, unter Nutzung der ELF-Loader-Bibliothek, die Adressender Schnittstellen.

Über dem Kern liegt die Serviceschicht. Bei Services handelt es sich um Programmteile,die bestimmte High-Level-Funktionen bereitstellen. Da sie keinen Prozess implementie-ren, sind sie nicht eigenständig ausführbar. Stattdessen können sie über eine definierteSchnittstelle in Prozesse integriert werden. Contiki liefert bereits eine Vielzahl vonunterschiedlichen Services mit, die im <contiki>/apps/ Verzeichnis liegen.

Die oberste Schicht stellen die Applikationsprozesse dar. In diese können einzelneServices integriert werden. Sie werden vom Kernel verwaltet und können untereinanderkommunizieren. Applikationsprozesse sind keine eigenständigen Dateien, sondern werdenmit dem Betriebssystem durch statisches Linken verknüpft. In Kapitel 2.3.2 wirddetaillierter auf die Funktionsweise von Prozessen eingegangen.

Zu bemerken ist, dass Contiki dem Anwender völlige Freiheit lässt, welche Teile desBetriebssystems er in seine Applikation aufnehmen möchte. Der einzige unverzichtbareBestandteil ist dabei das Prozesssystem. Die beschriebenen Schichten sind von obennach unten durchlässig. Somit können nicht nur der Kernel, sondern auch Services undProzesse auf die Treiberschicht zugreifen. In umgekehrter Richtung sollten allerdingskeine Zugriffe erfolgen, um eine lose Kopplung der Module beizubehalten. Nähereszum Buildvorgang und der Integration von Prozessen kann der Contiki-Dokumentationentnommen werden (siehe [Dun10]).

12

Page 22: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

2.3.2 Prozessmodell

Bei Contiki ist das Prozessmodell nach dem Prinzip des kooperativen Multitaskings inKombination mit einer eventgesteuerten Architektur umgesetzt. Bei diesem Paradigmahandelt es sich um ein nichtpräemptives Verfahren, bei dem Kernelcode nur dannausgeführt wird, wenn ein aktiver Prozess die Steuerung abgibt. Informationen, die denProgrammablauf kontrollieren, werden mithilfe von Events kommuniziert.

2.3.2.1 Protothreads als Basis von Prozessen

Die konkrete Umsetzung des Prozessmodells erfolgt auf der Basis von Koroutinen mittelsder Protothreads-Bibliothek. Prozesse werden in diesem Zusammenhang auch nur alsThreads bezeichnet. Sie sind in der Lage, die Programmausführung zu unterbrechen(blockieren), den aktuellen Zustand zu speichern und zu einem anderen Prozess überzu-gehen (siehe [Tat08]). Dabei wird die sequentielle Ausführung solange unterbrochen, biseine Zustandsänderung hervorgerufen wird. Der Wiedereintritt in den Prozess erfolgtan der Stelle, wo die Steuerung zuvor abgegeben wurde. Diese Eigenschaft wird alseintrittsinvariant (engl. reentrant) bezeichnet. In dieser Implementierung teilen sich alleThreads gemeinsam einen Stack, wobei pro Thread lediglich ein Overhead von 2 Byteentsteht. Protothreads bestehen im Kern aus einer Menge von C-Präprozessordirektiven.Sie profitieren von der Möglichkeit, auch andere Kontrollanweisungen in switch-caseStatements zu definieren und innerhalb dieser zu springen (siehe [Dun06b]). In der Praxismuss beachtet werden, dass automatische Variablen beim Wechsel in einen anderenProzess gelöscht und bei Reaktivierung neu angelegt werden. Um Daten zu speichern,sollte man daher statische Variablen verwenden.

Ein Prozess besteht in Contiki aus einem Eventhandler (Funktionsrumpf) und einemoptionalen Pollhandler. Der Eventhandler ist ein Protothread und erfüllt meist in Formeiner Hauptschleife eine definierte Aufgabe. Der Pollhandler ist hingegen eine herkömm-liche C-Funktion, die zur periodischen Abfrage von Hardwarezuständen eingesetzt wird.Bedingt durch den hochfrequenten Aufruf sollten Pollhandler möglichst kurz sein. DasProzessmodell von Contiki erweitert zudem die Funktionen von Protothreads zur Ermög-lichung der Kommunikation mittels Events. Ein Event besteht aus einem Eventtyp undeinem Pointer für beliebige Daten. Soll ein anderer Prozess die Steuerung erhalten, kanndies nur über Aussendung eines Events geschehen, das wiederum einen anderen Prozessaktiviert. Die Verarbeitung kann dabei synchron oder asynchron erfolgen. Events sindsomit für das Prozessmodell unverzichtbar und stellen den Contiki-Weg der Inter Process

13

Page 23: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Communication (IPC) dar.

Asynchrone Events werden am häufigsten verwendet und können global (als Broadcast)oder an einen bestimmten Prozess gerichtet, ausgesendet werden. Hierbei löst ein Prozessein Event aus, indem anfangs nur die Information über das Event in einer Datenstrukturgespeichert wird. Gibt der Prozess seine Steuerung an den Kernel ab, prüft dieser fürjeden Prozess, ob ein Event vorliegt. Wenn das der Fall ist, wird die Eventnachricht anden Prozess übergeben und dieser wird ausgeführt. Liegen keine Events vor, durchläuftder Kernel die Prozessliste nach dem Ringpuffer-Prinzip. Die als Pollhandler registriertenProzessbestandteile werden, bevor die Prozessverwaltung die Steuerung an einen anderenProzess abgibt, ausgeführt. Somit werden stets alle Pollhandler vor dem Wechsel ineinen anderen Prozess verarbeitet.

Die neben den asynchronen Events existierenden synchronen Events werden ohne Kernel-unterstützung behandelt. Der Eventtyp wird ebenfalls gespeichert, aber der adressierteProzess wird nun direkt vom momentan ausgeführten aufgerufen. Die Rückgabe zumKernel erfolgt erst, nachdem beide Prozesse ihre Steuerung abgegeben haben.

2.3.2.2 Multithreading

Diese Erweiterung des Contiki-Prozesssystems wird als eine Bibliothek bereitgestellt.Man kann Multithreading optional für eigene Applikationen verwenden, wenn sichdas beschriebene Prozessmodell nicht eignet. Der Begriff Thread hat im Kontext vonMultithreading eine andere Bedeutung. Anstelle eines gemeinsamen Stacks besitzt jederThread nun seinen eigenen. Zusätzlich werden Threads nicht mehr global vom Contiki-Prozesssystem verwaltet, statt dessen muss diese Aufgabe von einem Erzeuger-Prozessübernommen werden. Dieser ist folglich für die Erstellung und den Wechsel zwischen denThreads verantwortlich. Einen eigenen Stack zu verwalten erfordert im Detail, dass alleCPU-Register bei einem Thread-Wechsel auf dem Stack abgelegt werden. Im Anschlussdaran ist es notwendig, den Stackpointer mit der Stackadresse des neuen Threads zuüberschreiben. Damit können die zuvor gesicherten Registerwerte des neuen Threadsvom Stack abgehoben und den CPU-Registern zugewiesen werden. Im Unterschied zumProzessmodell ist der beschriebene Vorgang stark CPU-spezifisch und muss daher fürjede Architektur angepasst werden. Da hierfür der direkte Zugriff auf CPU-Registernotwendig ist, muss die Umsetzung in Assembler erfolgen.

Ein Thread ist somit, bis auf das Scheduling, vergleichbar mit User-Threads in Linux.Da sich Prozesse in einem gemeinsamen Kontext befinden und auch den Stack teilen,

14

Page 24: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Threads hingegen einen eigenen Stack besitzen, ist ihr Verwaltungsaufwand höher als beiContiki-Prozessen. Allerdings besitzen sie den Vorteil, dass sie präemptiv beendet werdenkönnen. Der Einsatz von Threads sollte deshalb nur erfolgen, wenn ein threadeigenerStack zwingend notwendig ist, wie beispielsweise bei rekursiven Algorithmen.

2.3.2.3 Zusammenfassung

Das Contiki-Prozesssystem stellt einen neuartigen, aber überschaubaren Ansatz dar,Prozesse innerhalb eines Kontextes zu verwalten. Dabei sind ein Großteil der Diensteund Treiber, die Contiki anbietet, selbst Prozesse. Die Implementierung eines Systemsmit präemptiven Multitasking, wie es sich bei Mehrzweck-Betriebssystemen durchgesetzthat, würde den Entwicklungsaufwand, die Komplexität und den Verwaltungsaufwandwesentlich erhöhen. Auf präemptives Multithreading kann dennoch optional zurückge-griffen werden, wenn man parallele Ausführungsfäden mit eigenem Stack benötigt oderrekursive Algorithmen benutzen möchte. Durch den präemptiven Charakter findet esAnwendung, wenn die Ausführungsdauer des Tasks sehr lang ist, da mit dem beschrie-benen Prozessmodell während dieser Zeit keine anderen Prozesse verarbeitet werdenkönnen. In Tabelle 2.3 werden die Eigenschaften von Contiki-Prozessen und Threadsnoch einmal zusammengefasst.

Tabelle 2.3: Vergleich zwischen Prozessmodell und Multithreading

Merkmal Contiki-Prozess Contiki-ThreadEigener Stack nein jaPräemption nicht möglich möglichWechsel einfacher Sprung aufwendig da KontextwechselSpeicherverbrauch 2 Byte höher, KontextabhängigRekursion nicht möglich möglichAutomatische Variablen flüchtig beständigVerwaltung Kernel NutzerprozessContiki-System fester Bestandteil optional

In Abbildung 2.3 wird das Prozessmodell anhand eines fiktiven Beispiels veranschaulicht.Dabei werden die unterschiedlichen Anordnungsmöglichkeiten von Eventhandlern, Poll-handlern und Threads gezeigt. Es wird verdeutlicht, dass der Kernel zwar die Prozesseabhängig von den vorliegenden Events aktiviert, die Threads aber völlig eigenständig vonden Prozessen 2 und 3 verwaltet werden. Der Darstellung ist weiterhin zu entnehmen,

15

Page 25: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

dass der Pollhandler von Prozess 1 immer dann ausgeführt wird, sobald der Kernel dieSteuerung erhält. In der Zeit in der keine Events vorliegen, wird nur der Pollhandleraufgerufen.

t

KernelScheduler

Prozess 3

Thread 1

Thread 2

Prozess 2

Thread 1

Prozess 1

T1 T2

T1

T1 T2

Prozess-Eventhandler

Thread

Prozess-Pollhandler

Event

Abbildung 2.3: Contiki-Prozessbeispiel

2.3.3 Echtzeitaspekte

Grundsätzlich wird von Echtzeitsystemen ein möglichst deterministisches Reaktions-verhalten erwartet. Daraus ergeben sich besondere Ansprüche an Hard- und Software.Moderne CPU-Architekturen, wie Blackfin, haben Pipelining- und Caching-Technologienumgesetzt, die eine exakte Vorhersage erschweren. Unter folgenden Aspekten soll je-doch die Software näher betrachtet werden. Dabei wird der Einsatz von Contiki beiechtzeitkritischen Anforderungen und unter Berücksichtigung der unterschiedlichenRealisierungsvarianten diskutiert.

2.3.3.1 Prozessmodell

Betrachtet man das Contiki-Prozesssystem unter Verwendung von asynchronen Pro-zessen, die vom Betriebssystem verwaltet werden, müssen die folgenden Tatsachenüber die Echtzeitfähigkeit festgehalten werden. Mögliche Modelle, die das Echtzeit-scheduling bestimmen, sind das ereignisgesteuerte und das zeitgesteuerte. Der Begriff

16

Page 26: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

„ereignisgesteuert“ kann hierbei zur Verwirrung führen. Contiki selbst besitzt zwar eineereignisgesteuerte Architektur und kommuniziert intern zwischen Prozessen mithilfevon Events. Bezogen auf Echtzeitsysteme sind jedoch externe Zustandsänderungendurch eintreffende Interrupts gemeint, welche den Wechsel des laufenden Prozesses unterBerücksichtigung von Prioritäten herbeiführen können. Prinzipiell ist beim kooperativenMultitasking, wie es in Contiki umgesetzt ist, nur das zeitgesteuerte Scheduling vonTasks möglich. Bei der ereignisgesteuerten Variante muss das Prozesssystem präemptivsein und Priorisierung unterstützen. Beide Punkte sind mit Contiki nicht realisierbar.

Die Einplanung von Tasks kann beim zeitgesteuerten Scheduling unter bestimmtenBedingungen online (zur Programmlaufzeit) oder offline (vor der Programmausführung)erfolgen. Da der Entzug der Prozesssteuerung durch den Kernel nicht möglich ist, mussdie Ausführungsdauer jedes Tasks bekannt sein. Ohne diese Information kann keinZeitplan aufgestellt werden. Der Kernel besitzt die Steuerung nur, um den Prozess-wechsel herbeizuführen. Die Dauer, die der Kernel dafür benötigt, kann exakt ermitteltwerden, da das Verhalten deterministisch ist. Zur Ermittlung der Zeiten für bestimmteAnwendungszenarien müssen der Kernel und die Applikation vermessen werden, um dieerforderlichen Informationen zur Erstellung eines Taskplans zu gewinnen. Tasks, derenAusführung zu lange dauert, könnten beispielsweise über einen Zustandsautomaten inkürzere Teile zerlegt werden. Zur Realisierung des zeitgesteuerten Schedulings ist esweiterhin erforderlich, Interrupts zu deaktivieren, da diese die Ausführungsdauer negativbeeinflussen würden. Dadurch verändert sich die Ressourcenverwaltung, und es müsseneine Reihe von Treibern auf den DMA- oder Polling-Modus umgestellt werden.

Die Umsetzung harter Echtzeitanforderungen ist mit dem Contiki-Prozesssystem möglich,aber nicht leicht. Da der Kernel keinerlei Einfluss auf die Programmausführung nehmenkann, obliegt es dem Entwickler die entsprechende Applikation in den Kontext desBetriebssystems, unter Einhaltung der Zeitschranken, einzubauen. Contiki bietet aktuellkeine Unterstützung, welche die Umsetzung von echtzeitkritischen Applikationen für dasProzessmodell unterstützt. Tools zum Vermessen von Ausführungszeiten könnten hierbeihilfreich sein. Aktuell ist keine praktische Umsetzung harter Echtzeitanforderungenbekannt.

2.3.3.2 Multithreading

Das Multithreading kann, wie bereits geschildert, auch präemptiv verwendet werden.Prinzipiell würde es sich deshalb für das ereignisgesteuerte und zeitgesteuerte Echtzeit-modell eignen. Von einer näheren Analyse wird jedoch abgesehen, da Threads stark

17

Page 27: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

eingeschränkt arbeiten. Die Tatsache, dass sie eine Untermenge eines Prozesses darstel-len und nur unidirektional mit diesen kommunizieren können, verhindert die Nutzungvon Treibern und anderen Contiki-Komponenten. Außerdem muss ein echtzeitfähigesScheduling zuvor als Nutzerprozess implementiert werden. Contiki unterstützt denEntwickler hierbei ebenfalls nicht.

2.3.3.3 Taskplaner

Auf der Basis von Interrupts stellt Contiki unabhängig vom Prozessmodell eine Lösungs-möglichkeit für bestimmte Echtzeitaufgaben bereit. Mit dem sogenannten Realtime-Modul ist man in der Lage, einen Zeitplan für Tasks zu erstellen. Ein oder mehrereTasks können damit beliebig oft zu bestimmten Zeiten eingeplant werden. Bei diesenkann es sich nur um eine Funktion, nicht aber um einen Prozess nach dem Prozessmo-dell handeln. Deshalb muss man unter anderem auf die eventbasierte Kommunikationverzichten. Umgesetzt wird dieses Konzept über die Aktivierung eines Hardware-Timers,der so konfiguriert wird, dass er nach Ablauf einer definierten Zeitspanne einen Interruptauslöst. Geschieht dies, wird der Task in der Interrupt Service Routine (ISR) ausgeführt(siehe [Wik10a]). Wie in jedem ISR-Kontext sind auch hierbei Race-Conditions denkbar,die nur bei atomaren Zugriffen auf globale Variablen, welche von der ISR und demnormalen Programmkontext verwendet werden, verhindert werden können. Weiterhinsollte die Ausführungszeit von ISRs so kurz wie möglich sein, da während dieser Dauerder Kernel auf keine anderen Ereignisse reagieren kann. Blockierende Funktionsaufrufe,Zugriffe auf Treiber sowie das Auslösen und Verarbeiten anderer Interrupts sind währendder Task-Ausführung nicht möglich. Bei mehreren eingeplanten Tasks besteht zudemdie Gefahr, dass der Zeitplan nicht eingehalten werden kann, da zuvor erst der laufendeTask beendet sein muss. Mit dem Realtime-Modul sind Echtzeitprobleme deshalb nursehr eingeschränkt zu bewältigen.

2.3.4 Sensoren

Die Sensorinfrastruktur dient als Teil des Contiki-Kerns dem periodischen Abfragenbeliebiger Peripheriezustände (zu finden unter <contiki>/core/lib/sensors.c). Dafür exis-tiert ein Prozess, welcher wiederkehrend alle registrierten Sensoren abfragt und beiÄnderung eines Zustands ein Event als Broadcast emittiert. Es ist daher erforderlich, fürjeden Sensor eine Konfigurations- und elementare Abfragefunktion zu implementierenund diese mittels einer Präprozessordirektive zu registrieren.

18

Page 28: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Die Infrastruktur stellt eine einfache, aber interessante Implementierung dar, welcheauf der Interaktion von Prozessen mittels Events basiert. Sie kann eingesetzt werden,wenn einfache (ganzzahlige) Rückgabewerte von externen Komponenten abgefragtwerden sollen. Diese Sensorinfrastruktur soll zur Ermittlung der Tasterzustände aufdem Evaluierungsboard verwendet werden.

2.3.5 Speicherverwaltung

Um Speicherplatz innerhalb von Anwendungen bereitzustellen, existieren mehrere Mög-lichkeiten. Für statische Daten kann dies auf dem Daten- und BSS-Segment geschehen.Darin werden initialisierte beziehungsweise uninitialisierte statische und globale Va-riablen abgelegt. Charakteristisch ist ihre konstante Größe, die bereits während derKompilierung feststeht und sich zur Laufzeit nicht ändern kann. An die wechselhaftenAnforderungen von Applikationen während der Ausführung, können sie nicht skaliertwerden. Dazu eignen sich eher dynamische Verfahren, die nachfolgend näher betrachtetwerden. Eine Möglichkeit ist es, Speicher auf dem Stack bereit zu stellen. Das geschiehtstandardmäßig für automatische Variablen. Der Vorteil ist, dass der Speicher für denStack nicht explizit angelegt und freigegeben werden muss. Stattdessen verändert erseinen Füllstand dynamisch während der Ausführungszeit. Da der Inhalt automatischverloren geht, sobald der Block oder die Funktion verlassen wird, entfällt das fehler-anfällige manuelle Freigeben des Speichers. In Contiki erhöht sich diese Flüchtigkeitsogar noch, da bei jedem Prozesswechsel der Kontext gewechselt wird (vergleiche Ka-pitel 2.3.2.1). Daher kann man den Stack in Contiki-Prozessen nur als temporärenSpeicher von Objekten verwenden.

Ein wichtiger Punkt bei eingebetteten Systemen ist, die benötigte Menge des Stackspei-chers zur Kompilierungszeit vorherzusagen. Dies ist nur unter bestimmten Vorausset-zungen möglich. Für den Stack bedeutet das, dass auf Rekursion, Funktionspointer undMultithreading verzichtet wird. Hält man diese Kriterien ein, kann der Speicherverbrauchfür den Stack deterministisch vorausgesagt werden. Für eingebettete Systeme, die häufignur über wenige Kilobyte RAM verfügen, wäre diese Speicherkontrolle wünschenswert.Somit wäre der Kompiler in der Lage, für die jeweilige Architektur abzuschätzen, obder Code in den RAM hinein passt oder nicht.

Die Verwendung des Heapspeichers stellt die flexiblere Möglichkeit dar, Speicher anzufor-dern. Der Entwickler kann hierbei kontrollieren wann und für wie lange er eine gewisseMenge Speicher benötigt. Die Allokation des Speichers kostet jedoch Rechenzeit. Einweitaus größeres Problem stellt eine mögliche Fragmentierung dar, wie sie nach häufiger

19

Page 29: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Allokation und Deallokation von Speicher auftritt (Näheres siehe [Mur]). Außerdemkann der Speicherverbrauch auf dem Heap nicht deterministisch im Voraus ermittelt,sondern lediglich vom Entwickler abgeschätzt werden.

In Contiki werden derzeit drei unterschiedliche Methoden zur Speicherverwaltungbereitgestellt, die nachfolgend kurz charakterisiert werden.

Methode 1 - Malloc

Mit dieser Funktion wird dynamischer Speicher üblicherweise auf dem Heap alloziert.Allerdings bringt dieses Verfahren die bereits genannten Nachteile der Fragmentierungund des nichtdeterministischen Speicherverbrauchs mit sich. Stack- und Heapspeicherwachsen üblicherweise gegenläufig aufeinander zu. Dabei wird die Größe des Heaps durchfestgelegte Konstanten im Linkerskript oder der Startuproutine begrenzt und kann nichtdarüber hinauswachsen. Die Ausdehnung des Stacks hingegen kann von Contiki währendder Laufzeit nicht kontrolliert werden. Es ist deshalb möglich, dass der Stack Teile desHeaps überschreibt. Dabei stürzt die Anwendung nach einer bestimmten Laufzeit in derRegel einfach ab, weshalb die Problemerkennung schwierig ist. Die Funktion malloc()

sollte in eingebetteten Systemen nur für den kurzfristigen Gebrauch und unter strengkontrollierten Umständen verwendet werden. Deshalb sind die folgenden Methoden zuempfehlen.

Methode 2 - Memory Block Management (MEMB)

Hierbei handelt es sich um ein einfaches Verfahren, das einen Mittelweg zwischenstatischem und dynamischen Speicher beschreibt. Um Speicher bereit zu stellen, wirdmithilfe des MEMB-Makros eine ausreichende Menge Speicher in einem Pool, bestehendaus einem globalen Array, reserviert. Dabei muss dem Makro ein Name, die Größeeines Datenobjekts und die maximal benötigte Anzahl der Objekte mitgeteilt werden.Diese Parameter sind zur Programmlaufzeit nicht mehr änderbar. Mittels Zugriffs- undFreigabefunktionen erfolgt die dynamische Verwaltung von Speicherblöcken. DiesesVerfahren ist nicht so flexibel wie malloc(), da nur Blöcke fester Größe vergeben werdenkönnen. Man hat jedoch die Sicherheit, dass nur eine definierte Menge Speicherplatzvom Programm verwendet wird. Fragmentierung kann ebenfalls nicht entstehen, aberes besteht die Gefahr, dass bei fehlerhafter Anwendung des Verfahrens, Speicherplatzungenutzt bleibt.

20

Page 30: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

2 Stand der Technik

Methode 3 - Managed Memory Allocator (MMEM)

Bei dieser etwas komplexeren Herangehensweise soll der Speicher ebenfalls fragmentie-rungsfrei verwaltet werden, ohne Speicherblöcke unbenutzt zu verschwenden. Speicherwird auch hierbei über ein globales Array mit einer festen Größe definiert. Im Unter-schied zum MEMB-Verfahren wird nicht für jede benötigte Datenstruktur ein Arrayangelegt, sondern ein einziges wird für alle Speicheranforderungen aufgeteilt. Dabeiwird bei einer Anforderung nur noch ein Pointer auf eine Struktur, welche die realeSpeicheradresse kennt, zurückgegeben. Jeder Speicherzugriff muss daher mittels MEMPTR-Makro gekapselt sein. Dieses Makro verwaltet die Pointer der einzelnen Speicherblöcke.Wird Speicher alloziert, muss dieser nicht in aufeinanderfolgenden Blöcken vorliegen,wie es durch Fragmentierung verhindert wird. Stattdessen können die Speicherblöckebeliebig im Array verteilt sein. Die einzelnen Blöcke sind dabei über eine verketteteListe miteinander verbunden (Näheres siehe [Aki08]). Diese Flexibilität erkauft man sichmit einem Overhead, der die Zugriffszeit auf diesen Speicher jedoch negativ beeinflusst.

21

Page 31: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

3 Konzept

Dieses Kapitel beginnt mit der Vorstellung der Portierungsaufgaben und des gewähltenallgemeinen Lösungsansatzes. Daran schließt sich Vorstellung des Bootloaders an, derzum Starten Contikis verwendet wird. Es folgt eine Beschreibung der Speicheraufteilungmithilfe des erarbeiteten Linker-Skripts, um flexibel die unterschiedlichen Speicherdes Blackfins zu nutzen. Zusätzlich werden die Entwürfe zur Anpassung der LED-Infrastruktur und der komplexen Treiber für den UART und den Ethernet-MAC erläutertund begründet.

3.1 Portierungsaufgaben

Die Portierung kann von zwei Seiten betrachtet werden. Einerseits soll das Betriebssystemin Form von Treibern möglichst das gesamte Spektrum von Hardwarefeatures undPeripheriekomponenten unterstützen. Andererseits ist es wünschenswert, dass auch alleFunktionen des Betriebssystems durch die Hardware umgesetzt werden. Ziel war es,möglichst viele Features von Hard- und Software mit dem neuen System zu unterstützen.

Bevor Contiki für Blackfin erweitert werden konnte, mussten zuerst die Grundlagen fürdie weitere Arbeit geschaffen werden. Dazu konnte auf existierende Software zurückge-griffen werden (Näheres siehe [Str10] und [son10]). Die Aufgaben werden in Tabelle 3.1aufgeführt.

Tabelle 3.1: Basisaufgaben für die Portierung

Aufgabe Bedeutung StandInstallation der Build-Toolchain aufdem Hostsystem

notwendig umgesetzt

Installation des Bootloaders notwendig umgesetztUpload und Debuggen des Pro-gramms mittels JTAG

notwendig umgesetzt

In Tabelle 3.2 werden die Portierungsaufgaben, die sich aus den Fähigkeiten von

22

Page 32: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

Blackfin und Contiki ergeben, genannt. Die Realisierung jeder Teilaufgabe erfolgtestets nach dem gleichen Muster. Nach der Analyse der Problemstellung konnte mitder Erarbeitung einer Lösung in Contiki begonnen werden. Als Entwurfstechnik wurdedazu das Top-Down-Verfahren gewählt. Die Schnittstellen waren von Contiki für diemeisten Treiber vorgegeben. Die Portierungen anderer Hardwareplattformen auf Contikidienten als hilfreiche Informationsquellen, die zusammen mit den Informationen aus denBlackfin-Handbüchern [Adh] und [Adp] als Basis für das Konzept und die darauffolgendeImplementierung verwendet wurden. Die Reihenfolge der in der Tabelle 3.2 aufgeführtenAufgaben entspricht in etwa der zeitlichen Abfolge ihrer Realisierung.

Tabelle 3.2: Contiki Portierungsaufgaben für Blackfin

Aufgabe/Komponente Contiki-Subsystem StandAnpassen der Verzeichnisstrukturund der Makefiles

nein umgesetzt

Initialisierungsfunktion zum Setzendes Takts und der RAM-Refreshrate

nein umgesetzt

Implementierung der Newlib nein teilweise umgesetztEntwurf eines Linkerskripts zur Nut-zung des SDRAMs

nein umgesetzt

UART ja umgesetzt (Terminal-und SLIP-Modus)

LEDs ja (wurde modifiziert) umgesetztUhrfunktion ja umgesetztTaskplaner ja umgesetztMultithreading ja umgesetztEthernet TCP/IP Stack vorhanden umgesetztTaster ja umgesetztBefehlscache nein Funktionalität wird vom

Bootloader geerbtDatencache nein nicht möglich wegen der

ProgrammaufteilungWatchdog ja aus Zeitgründen vorerst

nicht umgesetztFlashspeicher ja (CFS-Dateisystem) aus Zeitgründen vorerst

nicht umgesetztELF-Loader für Programmupdates ja nicht umgesetzt (nur

sinnvoll in Sensornetz-werken)

Busse: CAN, PPI, SPI, TWI nein nicht umgesetzt

23

Page 33: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

3.2 Einbindung des Bootloaders

Um Blackfin und Contiki im produktiven Einsatz zu verwenden, wurde von vornherein dieVerwendung des Bootloaders U-Boot beabsichtigt. Dieser ermöglicht es bei Systemstartein Betriebssystem aus einer Vielzahl von Quellen (TFTP, NFS, Flash, etc.) auszuwählen.Ein Wechsel zwischen unterschiedlichen Betriebssystemen oder die Aktualisierung dieser,gestaltet sich damit sehr einfach, solange dieses im ELF-Binärformat vorliegt. Bei nähererBetrachtung des Bootloaders stellte sich die Besonderheit heraus, dass der Befehls- undder Daten-Cache standardmäßig bereits aktiviert sind. Dieser Zustand bleibt auchnach dem Laden des Betriebssystems erhalten, solange es die Cache-Behandlung nichtselbst übernimmt. Ursprünglich sollten Caches aus Zeitgründen nicht Gegenstand dieserPortierung sein. Aus der „Vererbung“ des bereits aktivierten Befehls-Caches ergab sichallerdings ein erfreulicher Performancegewinn, ohne dass weitere Schritte notwendigwaren. Daher konnte die Aktivierung des Befehls-Caches nicht aber die des Daten-Cachesbeibehalten werden, da der hierfür verwendete Adressraum (L1-Daten SRAM) bereitsfür andere Datensegmente verwendet wird. Informationen zur Benutzung von U-Bootund Contiki sind in der Anwenderdokumentation beigefügt (siehe Kapitel 6.2).

3.3 Linker-Anpassungen

Der GNU Linker (ld) fügt als Teil der Blackfin-Toolchain alle Module einer Anwendungzu einer eigenständigen Datei, im vorliegendem Fall im ELF-Binärformat, zusammen.Dabei werden die unterschiedlichen Speicherbereiche der Programmmodule in die Spei-cherregionen der Hardware aufgeteilt (Relocation). Dafür ist es unter anderem notwendig,den Linker über das Layout der zur Verfügung stehenden Speicherbereiche zu informieren.In Abbildung 3.1 sind die hierfür verwendbaren Speicherregionen aus dem Adressraumdes Blackfins dargestellt.

24

Page 34: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

externer SD-RAM (48 MB)

externer SD-RAM unbenutzbar (16 MB)

L1 Daten - Bank B (32 kB)

L1 Daten - Bank A (32 kB)

L1 Code (48 kB)

L1 Scratchpad (4 kB)

0x00000000

0xffb00000

0xffa00000

0xff900000

0xff800000

0x03000000

Abbildung 3.1: Speicherregionen zur Programmaufteilung auf dem BF-537

Um die Aufteilung der Programmsegmente optimal zu gestalten, unter anderem zurIntegration von SDRAM, genügt es nicht, das vom GNU Linker vorgegebene Layout zuverwenden. Es ist vielmehr erforderlich, durch die Erstellung eines Skripts die Aufteilungder Speicherregionen selbst vorzunehmen (Näheres zur Skriptsprache siehe [Lev01]). DieImplementierung dazu ist in <contiki>/cpu/bf537/bf537.ld zu finden. Der Grund für dieBegrenzung des SDRAMs auf 48 MB wird in Kapitel 4.5 beschrieben.

Um den hohen Datendurchsatz des L1-Code und L1-Daten SRAMs gegenüber demca. 4 mal langsameren SDRAM vollständig auszunutzen, wurde zuerst versucht, dasCodesegment und die unterschiedlichen Datensegmente in den L1-SRAM aufzuteilen.

Für den Codeabschnitt Text erwies sich die zur Verfügung stehende Speicherkapazitätvon 48 kB bei zunehmender Integration neuer Treiber in das Betriebssystem als unzu-reichend. Die ausführbare Datei überschritt die maximale Größe. Aus diesem Grundwurde der gesamte Code in den SDRAM eingelagert. Mit dem vorliegenden Linkerskriptist man jedoch in der Lage, bestimmte kritische Module in den L1-SRAM zu verlagern.Dazu kann das Befehlssegment im Linkerskript entweder dem SDRAM beziehungsweisedem SRAM zugewiesen werden, oder man versieht die entsprechenden Funktionen imQuellcode mit besonderen Attributen (siehe [Get09b]). Eine Effizienzsteigerung beider Auslagerung in den SRAM würde sich insbesondere in Modulen, in denen vielCode ausgeführt wird, ergeben. Messungen, die diese Aussage belegen, wurden ausZeitgründen bisher nicht unternommen.

Die Datensegmente Data und BSS werden in Bank A und B des L1-SRAMs aufgeteilt.Während das Data-Segment für Konstanten verwendet wird, dient das BSS-Segment inContiki als langfristiger Speicher für statische Variablen, da der Stack in Prozessen nichtbeständig ist. Es wird beispielsweise als Puffer im uIP-Netzwerkstack oder als DMA-

25

Page 35: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

Region im Netzwerktreiber eingesetzt. Gegenüber der Zuweisung dieser Datensegmente inden SDRAM konnten während des Entwicklungsvorgangs deutliche Performancegewinnezugunsten des L1-SRAMs festgestellt werden. Bei Überschreiten der maximalen Größevon je 32 kB erzeugte der Kompiler eine Fehlermeldung. Wird dieses Segment häufigeingesetzt, kommt es schnell zur Überschreitung der zulässigen Größe und es wirdnotwendig, die betroffene Region im Linkerskript in den SDRAM umzuleiten.

Im vorliegenden Entwurf wurden außerdem die notwendigen Symbole für die Verwaltungder dynamischen Speicher Stack und Heap definiert. Dies umfasst die Festlegung vonBeginn und Ende des Heaps (_heap_start, _heap_end) sowie Beginn und maximale Größedes Stacks (_stacksize, _stack_end). Da der Zugriff auf den Stack am häufigsten geschiehtund er für Contiki auf etwa 2 kB angegeben wird, fiel die Wahl auf den für diese Zweckevorgesehenen 4 kB großen L1-SRAM Scratchpad. Da die Kapazität des SRAMs nichtausreichte, wurde der Heapspeicher dem SDRAM zugeordnet. Folgende Symbole wurdendefiniert und wie folgt dimensioniert:

_stacksize = 0x1000 (4 kB)

_stack_end = 0xffb01000 (L1 Scratchpad + _stacksize)

_heap_start = Ende statischer Daten

_heap_end = 0x3000000 (48 MB)

heapsize = _heap_end − _heap_start

Entgegen der gängigen Praxis, den Stack in negativer und den Heap in positiver Richtungaufeinander zuwachsen zu lassen, umgeht dieses Layout wegen der unterschiedlichenLokalität der Speicher diese Konvention.

Das Linkerskript wurde vor allem für einen maximalen Durchsatz beim Netzwerkdaten-transfer optimiert und ist als experimentell zu betrachten.

3.4 LED-Infrastruktur

Im Contiki-Kern ist eine einfache API zur plattformunabhängigen Ansteuerung fürmaximal drei LEDs implementiert. Neben diesen unabhängigen Funktionen sind außer-dem definierte Schnittstellen vorgegeben, die für den Hardwarezugriff der jeweiligenPlattform implementiert werden müssen. Die API umfasst die Funktionen:

• Initialisierung

26

Page 36: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

• Zustandsspeicherung

• Aktivierung/Deaktivierung einzelner LEDs

• Invertierung aller Zustände

• Rückgabe der aktuellen LED-Zustände

Da diese Infrastruktur nicht gänzlich plattformunabhängig ist, können nur drei LEDsangesteuert werden. Dabei muss für den gezielt lesenden und schreibenden Zugriffdie konkrete Farbe der LED (rot, gelb oder grün) angegeben werden. Da das BF-537STAMP Board sechs gelbe LEDs besitzt, ist die Verwendung der API, so wie es inContiki vorgesehen ist, nicht möglich. Für diese Portierung wurde die bestehende In-frastruktur deshalb so umgebaut, dass LEDs unabhängig von ihrer Farbe und Anzahlangesteuert werden können. Dazu wurde ein einfach adressierbares Nummerierungs-schema eingeführt. An den externen Schnittstellen hatte sich nichts geändert. DieImplementierung der blackfin-spezifischen Funktionen erfolgte im Anschluss, wobeilediglich die entsprechenden Port-Register der LEDs gesetzt werden mussten.

3.5 UART-Treiber

Ziel war es, den UART zur seriellen Kommunikation in Contiki zu unterstützen. DerBF-537 besitzt zwei getrennt arbeitende UARTs, nur einer davon ist mit einer typischenSUB-D Buchse auf dem STAMP Board verbunden. Vorkonfiguriert ist deshalb nur dererste (UART0). Der Treiber wurde so entworfen, dass beide UARTs getrennt vonein-ander aktivierbar und konfigurierbar sind. Für jeden UART sind protokollspezifischeEigenschaften, wie die Baudrate und der verwendete Interrupthandler, konfigurierbar.Der Interrupthandler muss austauschbar sein, da er abhängig vom Betriebsmodus ist.Momentan sind die Modi Terminal und SLIP möglich.

3.5.1 Terminal-Modus

Dieser Modus dient der Kommunikation mit herkömmlichen Terminalprogrammen,wie Minicom oder Hyperterminal. Er ist außerdem der voreingestellte Modus, der alsStandardausgabe konfiguriert ist. Das heißt, dass alle Ausgaben von printf(), putchar

(), etc. direkt an die Sendefunktion des Treibers weitergeleitet und von dieser überden UART verschickt werden. Der Ablauf beim Datentransfer ist der Abbildung 3.2 zu

27

Page 37: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

entnehmen. Bei diesem Entwurf geschieht der Datenempfang in einer Interruptroutine.Darin werden eintreffende Daten in einem Ringpuffer zwischengespeichert. Im Anschlussdaran wird per Event der Contiki Prozess für die serielle Datenübertragung aufgerufen,welcher die Daten umkopiert und den Applikationsprozess über den Erhalt von Datenbenachrichtigt. Das Senden erfolgt über einen blockierenden Funktionsaufruf, der zei-chenweise den Sendepuffer überträgt. Eine andere Variante für den Versand größererDatenmengen ist die asynchrone Übertragung, ausgelöst durch einen Interrupt. Dazumuss der Sendepuffer in eine vorher konfigurierte DMA-Region kopiert werden. Durchdas Auslösen eines Interrupts wird der Transfer aktiviert, der im Anschluss nichtblo-ckierend im Hintergrund abläuft. Die Entscheidung fiel auf die erstgenannte Variante,da der UART häufig nur für geringe Bandbreiten und einfache Textausgaben verwendetwird. Außerdem ist für größere Datenmengen die Übertragung mittels Ethernet möglich.

Eine sehr praktische Applikation für den Terminal-Modus ist die in Contiki integrierte„serial-shell“. Innerhalb dieser können weitere Contiki-Applikationen gestartet werden.

Kern

Applikation

Treiber

uartx_init

serial_line_init

process_post

Anwendungsprozess

HauptschleifeInitialisierung

ringbuffer_init process_start Serial_Line_Process

ringpuffer_put

process_poll

Empfangen: Uartx-RX ISR

ringpuffer_get

starte

Daten im Ringpuffer

uartx_push_char

Funktionsaufruf

Event

Daten im Puffer

sende Daten

Abbildung 3.2: UART-Funktionsdiagramm im Terminal-Modus (Auszug)

3.5.2 SLIP-Modus

Beim Serial Line Internet Protocol (SLIP) werden die zu übertragenden Daten in dasTCP-Protokoll gekapselt. Dieses Protokoll ist, verglichen mit dem Point to Point Protocol(PPP), einfacher aufgebaut (siehe [Rom88]). Der Entwurf des SLIP-Modus ähnelt in der

28

Page 38: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

Treiber-Schicht dem des Terminal-Modus. Der Hauptunterschied auf der Empfangsseitebesteht darin, dass der Prozess slip_process() anstelle von serial_line_process() gestartetwird. In diesem werden die Daten des Empfangspuffers verarbeitet und an die SLIP-APIweitergeleitet. Um den Prozess mit Daten zu versorgen, musste die Interruptroutinefür den Datenempfang ausgetauscht werden. Sendeseitig wird der uIP-Stack aktiviertund die slip_send() Funktion als Callback für den ausgehendenden Netzwerkverkehrregistriert. Diese Funktion fügt die Protokoll- und Nutzdaten zusammen und leitet sieanschließend an die Sendefunktion des Treibers, die identisch mit der Sendefunktion imTerminal-Modus ist, weiter. Mithilfe des Contiki-Werkzeugs „tunslip“ kann ein seriell mitdem Board verbundener Linux-Client eine Netzwerkverbindung aufbauen. Dabei wirdein neuer Netzwerkadapter mit IP-Schnittstelle erstellt, der die Netzwerkdaten über dieserielle Schnittstelle leitet. Dieser Adapter kann wie ein herkömmlicher Ethernet-Adapterverwendet werden (siehe [Bur09]). Zum Testen bietet sich der in Contiki integrierteTelnetserver an, der ähnliche Funktionen wie die „serial-shell“ bereitstellt.

3.6 Netzwerktreiber

Der Ethernet-MAC ist ein integrierter Bestandteil des BF-537 Prozessors. Er ermög-licht Vollduplex- und Halbduplex-Übertragungen mit den Datenraten 10/100 Mbit/s.Dabei werden bereits einige Aufgaben in Hardware gelöst. So beherrscht der ControllerAdressfilterung, Kollisionserkennung/-verhinderung (CSMA/CD) und Prüfsummenge-nerierung für Ethernet Frames. Über das Media Independent Interface (MII) ist derMAC mit einem Signalwandler (PHY) verbunden. Dieser übernimmt die Umwandlungder Signale für die Übertragung auf dem physikalischen Medium. Die Ansteuerung desMACs geschieht, wie bei anderen peripheren Komponenten auch, über entsprechendeMMR. Nutzdaten können dabei nur über DMA-Kanäle transferiert werden. Es wurdeein Treiber entwickelt, der den Datenaustausch mit dieser Schnittstelle ermöglicht undin den Contiki uIP-Netzwerkstack integriert ist. Abbildung 3.3 veranschaulicht dasKonzept dafür.

29

Page 39: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

Kern

Applikation

Treiber

uIP - SchreibenuIP - Init. uIP - Lesen

bfin_EMAC_recv process_poll

Netzwerktreiberprozess

mac_output

Funktionsaufruf

Event

DMASchreib-puffer

DMALese-puffer

Netzwerkanwendungsprozess

HauptschleifeInititialisierung

Daten im Puffer

bfin_EMAC_send

bfin_EMAC_init

setup_dma_buffer bfin_miiphy_init

NetzwerkhardwareDatenfluss

pollhandler

Pollrequest

Abbildung 3.3: MAC-Funktionsdiagramm (Auszug)

Bevor die Designentscheidungen erläutert werden, soll kurz auf die abstrahierten uIP-Bestandteile eingegangen werden. Die dargestellten drei Funktionsblöcke stehen hierbeistellvertretend für eine Vielzahl von Initialisierungs- und Transferfunktionen inner-halb des Netzwerkstacks. Welche man davon für seine Applikation verwenden muss,ist abhängig von den Anforderungen und den verwendeten Protokollen. Der Stackübernimmt vollständig die Protokollverwaltung der Netzwerkschichten 2-5 nach demOSI-Referenzmodell. Dazu gehören Ethernet, IPv4, IPv6 und ICMP, TCP und UDPsowie eine Socket-Implementierung. Für die Initialisierung und das Senden von Datenwerden dazu gewöhnliche Funktionsaufrufe in den uIP-Stack durchgeführt (beispielsweisetcp_listen(), tcp_connect(), uip_send(), etc.). Um Daten synchron zu verarbeiten, könnenApplikationen beim Empfangen blockierend auf diese warten. Treffen neue Daten ein,werden vom uIP-Stack, abhängig vom Protokoll, Contiki-Events als Broadcast emittiert.Durch diese Events wird die Blockierung der Applikation aufgehoben und die Netzwerk-daten können weiterverarbeitet werden (Näheres zu uIP siehe [Dun10]). Weiterhin ist esin Contiki möglich, wie bei anderen Treibern auch, den Netzwerkstack zu umgehen unddirekt auf die Treiberschnittstellen zuzugreifen, um beispielsweise eigene Protokolle zuimplementieren.

30

Page 40: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

Wie in der Abbildung des Funktionsdiagramms 3.3 zu sehen ist, sollte der Netzwerktreibernur drei, objektiv notwendige, externe Schnittstellen bereitstellen. Die Initialisierungs-funktion bfin_EMAC_init() setzt dabei die MAC-Adresse und aktiviert das MII. Für dieDatenübertragung ist der Weg über DMA vorgeschrieben (siehe [Adh, S. 8-7]). Dazuwerden zwei unabhängige DMA-Kanäle zum Senden und Empfangen konfiguriert. ImUnterschied zu anderer DMA-fähiger Peripherie ist für den MAC nur die deskriptorba-sierte Methode möglich (vergleiche Kapitel 2.1.3). Über Präprozessordirektiven wird dieAnzahl der DMA-Puffer eingestellt. Jeder Puffer hat dabei die maximale Größe einesEthernet-Pakets von 1556 Byte, zuzüglich 32 Byte für die Deskriptoren. Dabei werdendie Puffer global und statisch definiert, um sie mit dem vorliegendem Linkerskript inden L1-SRAM abzulegen. Dieser Umstand ist wichtig, da die Bandbreite des SDRAMsvon 133 MB/s für den maximalen Durchsatz des MACs ausreichen würde, die Datendanach aber noch umkopiert und im Netzwerkstack weiterverarbeitet werden müssen.Die Verwendung des SDRAMs würde deshalb zu einer verringerten Übertragungsrateführen. Der Puffer für den uIP-Stack uip_data befindet sich ebenfalls im SRAM, damitder Kopiervorgang performant ablaufen kann. Da die Größe dieses Speicherbereichsbegrenzt ist und andere Daten im SRAM liegen, erhält dieser Puffer nur die notwendigen1556 Byte. Das führt dazu, dass segmentierte IP-Pakete (das Protokoll erlaubt bis zu 64kB) nicht verarbeitet werden können. Um den Initialisierungsvorgang abzuschließen, istes weiterhin notwendig, den MAC selbst über das EMAC_OPMODE-Register zu konfigurieren.Aktiviert werden dabei die MAC-Adressfilterung, das automatische Auffüllen zu kurzerEthernet-Frames (Frame Padding) sowie das Empfangsregister. VLAN-Tagging wirdmomentan vom Treiber nicht unterstützt.

Beim Aufruf der Funktion bfin_EMAC_send() wird der Sendevorgang eingeleitet. Dazuwerden der Funktion die zu sendenden Daten übergeben, die anschließend in einenDMA-Puffer kopiert werden. Dieser Puffer wird an einen freien Platz in der Liste derDMA-Deskriptoren eingehängt und als sendebereit markiert. Ist kein Eintrag in der Listefrei, schlägt der Sendevorgang fehl. Im nächsten Schritt erhält das DMA2_NEXT_DESC_PTR-Register die Adresse des aktuellen Deskriptorelements aus der Liste. Die Sendefunktionkehrt bei Erfolg sofort zurück, während der Datentransfer im Hintergrund abläuft. DerDeskriptor wird nach Abschluss des Transfers automatisch als unbelegt markiert. Werdenmehrere Deskriptoren nacheinander in die Liste eingehängt, erfolgt die Versendung derenPuffer selbstständig und seriell durch den MAC. Um den Speicherverbrauch gering zuhalten, wird die Länge der Liste im vorliegenden Entwurf auf einen Deskriptor begrenzt.

Für den Empfangsvorgang wird der Netzwerktreiber in zwei Module aufgeteilt. Zumeinen wurde der Treiberprozess entwickelt, der nach dem Prinzip des Polling-Verfahrens

31

Page 41: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

3 Konzept

arbeitet. Dessen Pollhandler überprüft periodisch die Hardware auf eingetroffene Datenund informiert Applikationen mittels Events über dieses Ereignis. Dieser Prozess istsomit generisch und kann auch für andere Treiberschnittstellen, die das Polling-Verfahrenanwenden, eingesetzt werden. Eine Alternative zum Polling-Verfahren ist die Generierungeines Interrupts beim Datenempfang. Dies hätte den Vorteil, dass keine Rechenzeitvor dem Eintreffen von Daten verbraucht werden würde. Im Gegenzug würde derhäufige Kontextwechsel in die Interruptroutine während des Datenempfangs vermehrtRechenzeit benötigen. Da der Overhead durch das Polling mit Contiki relativ gering ist,fiel die Entscheidung auf diese Variante. Bei dem zweiten Modul handelt es sich umdie Treiberschnittstelle zum Blackfin-MAC bfin_EMAC_recv(). Diese überprüft bei einemAufruf alle Elemente der DMA-Deskriptorliste auf eingetroffene Daten. Sind Datenangekommen, werden diese aus dem DMA-Puffer in den Puffer des Netzwerkstacksuip_data kopiert. Die Verwendung mehrerer Deskriptoren ist dabei vor allem dannsinnvoll, wenn die Daten schneller eintreffen als sie verarbeitet werden können. UmSpeicherplatz zu sparen, wird, wie beim Sendevorgang auch, die Anzahl der Deskriptorenauf eins beschränkt.

32

Page 42: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

4 Implementierung

In diesem Kapitel wird detailliert auf einzelne Problemstellungen bei der Program-mierung eingegangen. Die beschriebenen Teilaufgaben stellten hierbei eine besondereHerausforderung dar (Multithreading) oder sollen zum Verständnis des neuen Systemsbeitragen (Newlib, Timer). Das Kapitel zur Zeitmessung soll verdeutlichen was inKapitel 5.1 vermessen wurde. Damit Aussagen über das Verhalten der Implementierunggetroffen werden können, bildet die Vorstellung der durchgeführten Tests den Abschlussdieses Kapitels.

4.1 Newlib

Die Newlib ist eine frei verfügbare Variante der C-Standardbibliothek, die als leicht-gewichtige Alternative zur GNU C-Bibliothek entwickelt wurde. Hauptsächlich wirdsie deshalb in eingebetteten Systemen eingesetzt. Die Newlib wurde bereits für vieleArchitekturen, darunter auch Blackfin, portiert. Diese Portierung lässt jedoch einigeFunktionen undefiniert.

Für die Implementierung der Low-Level I/O-Funktionen wurden folgende Entscheidun-gen getroffen. Die Funktion write() arbeitet als Standardausgabe und übergibt die Datenan die Treiberschnittstelle uart_push_string(). Von dieser Funktion werden die Datenanschließend zeichenweise an den UART0 gesendet. Eine Standardeingabe existiertnicht, sodass die Funktion read() undefiniert bleibt. Da Contiki keine Dateideskriptorenunterstützt, entfällt die Implementierung der Funktionen open() und close().

Relevant für die dynamische Speicheranforderung mittels der Standardbibliotheksfunk-tion malloc() ist die Funktion sbrk(). Diese verwendet die im Linkerskript definiertenSymbole _heap_start und _heap_end zur Ermittlung der Anfangsadresse des angefordertenSpeicherblocks. Das folgende Listing zeigt diese Implementierung auf.

1 caddr_t2 _sbrk(int incr)3 {4 extern char _heap_start ;5 extern char _heap_end ;6 static char * new_start = & _heap_start ;

33

Page 43: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

7 char * memory ;8

9 if ( new_start + incr > & _heap_end ) {10 errno = ENOMEM ;11 return ( caddr_t ) -1;12 }13 memory = new_start ;14 new_start += incr;15

16 return memory ;17 }

Listing 4.1: Low-Level Speicherallokation

Eine Reihe weiterer Funktionen (_exit(), _abort(), _kill(), _getpid()), deren Aufgabedie Prozesssteuerung ist, lassen sich im Contiki-Prozesssystem nicht sinnvoll anwendenund bleiben deshalb als Dummy-Funktionen undefiniert.

4.2 Timer

4.2.1 Clock-Modul

Das Clock-Modul erfüllt bei Contiki die Funktion einer klassischen Uhr, wobei üblicher-weise die Zeit ab dem Systemstart gemessen wird. Wie für andere Contiki-Subsystemeauch, sind hierfür definierte Schnittstellen vorhanden, welche für die jeweilige Portierungimplementiert werden müssen. Diese umfassen folgende Funktionen:

• Initialisierung der Hardware clock_init()

• Einstellen der Zeit clock_set_seconds()

• Rückgabe der Zeit in Millisekunden clock_time()

• Rückgabe der Zeit in Sekunden clock_seconds()

• Blockierendes Warten für eine definierte Dauer clock_delay()

Das Auslösen eines Timers erfolgt jede Millisekunde. Dazu wird periodisch eine Inter-ruptroutine ausgelöst, in der ein Zähler inkrementiert wird.

34

Page 44: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

Von den vier bereits vorgestellten Timern, welche bei Blackfin zur Verfügung stehen (sieheKapitel 2.1.4), eignen sich der Kerntimer und einer der Mehrzwecktimer. Die Verwendungder RTC schied aus, da die Register der RTC beim Erreichen der nächstgrößerenEinheit (Stunde, Minute, Tag) überlaufen. Contiki kann jedoch nur Sekunden undMillisekunden auswerten und müsste diese Werte aufwendig verarbeiten um darauswieder Sekunden zu erhalten. Die Entscheidung fiel auf den Kerntimer, da dieser diezweckmäßigen Funktionen erfüllt und einfacher zu konfigurieren ist, als die komplexerenMehrzwecktimer.

Die resultierende Frequenz (f) des Kerntimers ergibt sich aus der CCLK, dem Perioden-register (TPERIOD) und dem Skalierungsregister (TSCALE), die in einem linearenVerhältnis zueinander stehen:

f = TSCALE ∗ TPERIOD

CCLK

Um eine Frequenz von 1 kHz bei der CCLK von 500 MHz zu erreichen, wurde dasSkalierungsregister auf 1 und das Periodenregister auf 1000/CCLK gesetzt.

4.2.2 Realtime-Modul

Dieses Modul implementiert einen Timer für den in Kapitel 2.3.3.3 beschriebenenTaskplaner. Es unterscheidet sich vom Clock-Modul folgendermaßen. Anstelle der peri-odischen Ausführung muss der Timer nur für einmaliges Auslösen konfiguriert werden.Außerdem existieren neben einer Initialisierungsfunktion und einer Aktivierungsfunktionkeine weitere Schnittstellen, die implementiert werden müssen. Als Timer kommt nurnoch ein Mehrzwecktimer in Frage. Dieser wird in der Funktion rtimer_arch_schedule() sokonfiguriert, dass er nach einer bestimmten Anzahl von Prozessortakten einen Interruptauslöst. Ein Skalierungsregister ist hierbei nicht vorhanden. Die Periode wird überdas TIMER0_WIDTH-Register eingestellt, wobei als Referenztakt die SCLK von 125 MHzverwendet wird.

4.3 Multithreading

Die Multithreading-Erweiterung liegt in Contiki als eine minimalistisches Implementie-rung für stackeigene Threads vor (vergleiche Kapitel 2.3.2.2). Sie ist in eine plattformun-abhängige und in eine hardwarespezifische Schicht aufgeteilt. Die erstgenannte stellt fürApplikationen die Schnittstellen bereit, mit denen Threads plattformunabhängig erstellt

35

Page 45: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

und verwaltet werden können. Die andere Schicht besteht aus einer Gruppe von Funk-tionsdeklarationen, für die CPU-abhängig der Kontextwechsel implementiert werdenmuss. Dies war auch Bestandteil dieser Implementierung. Abbildung 4.1 veranschaulichtden Aufbau und die Verwendung der Threadbibliothek.

Kern

Applikation

Treiber mtarch_start

mt_yield mt_exec

mtarch_exec

mt_start mt_remove

mtarch_yield mtarch_remove

Threads

...

thread_1

thread_n

Initialisierungsprozess

HauptschleifeInit. Beenden

context_switch context_switch

Abbildung 4.1: Multithreading-Funktionsdiagramm (Auszug)

Threads müssen vor ihrer Verwendung nach der Schnittstellenspezifikation initialisiertwerden. Eine Initialisierungsfunktion muss einen Namen, die Adresse der Threadfunktionund die Adresse eines Parameters für Daten erhalten. Mit diesen Informationen wird fürjeden Thread eine Struktur vorbereitet, die diese Angaben speichert und in einem ArraySpeicherplatz für den Stack reserviert. Der Stack bekommt dabei für jeden Thread einefeste Größe von 256 Byte zugewiesen und wird mit dem Wert Null initialisiert.

Wird der Threadwechsel nach dem Prinzip des kooperativen Multithreadings durchge-führt, muss die mt_exec()-Funktion mit der Threadfunktion als Parameter aufgerufenwerden. Dabei wird der Thread aktiviert und es findet ein Wechsel in den Threadkontextstatt. Der aktivierte Thread übernimmt infolgedessen auch die CPU-Kontrolle. Ihmobliegt es nach seiner Tätigkeit die Kontrolle zurück an den aufrufenden Prozess zuübergeben. Geschieht dies, ändert der Funktionsaufruf mt_yield() den Status des Threadsund wechselt zurück in den Kontext des aufrufenden Prozesses, der nun ebenfalls auchdie Kontrolle erhält.

36

Page 46: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

Präemptives Multithreading ist ebenfalls möglich. Dazu wird der Kontextwechsel nichtvom laufenden Thread selbst, sondern von der Interruptroutine eines vorher program-mierten Timers initiiert.

Der Kontextwechsel speichert alle CPU-Register auf dem Stack des alten Threads,ändert die Adresse des Stackpointers und überschreibt die CPU-Register mit den zuvorgesicherten Werten des neuen Threads. Das folgende Listing verdeutlicht den Vorgangin Blackfin-Assembler.

1 _context_switch :2 /* push all registers */3 [--sp] = fp;4 ...5

6 /* swap stack pointer */7 P2.H = _running ;8 P2.L = _running ;9 P2 = [P2];

10 R0 = [P2+ MTARCH_STACKSIZE *4]; /* get new stack address */11 P2.H = _sptmp ;12 P2.L = _sptmp ;13 [P2] = R0;14 P2.H = _running ;15 P2.L = _running ;16 P2 = [P2];17 R0 = sp18 [P2+ MTARCH_STACKSIZE *4] = R0; /* save old stackpointer */19 P2.H = _sptmp ;20 P2.L = _sptmp ;21 sp = [P2] /* overwrite stackpointer */22

23 /* pop registers from new stack position */24 SEQSTAT = [sp ++];25 ...26

27 rts; /* return to new thread */

Listing 4.2: Kontextwechsel für Multithreading

Die beschriebene Implementierung für Multithreading ist sehr kompakt und erlaubtes den Kontextwechsel mit minimalem Overhead durchzuführen. Problematisch ist dieBegrenzung der Stackgröße, da diese für die einzelnen Threads, wie auch für Contikiinsgesamt, nicht kontrolliert werden kann. Somit steht der Applikationsentwickler inder Verantwortung, den Stack nicht über die maximale Größe hinauswachsen zu lassen,da sonst Speicherbereiche anderer Threads überschrieben werden können.

37

Page 47: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

4.4 Zeitmessung von Codeabschnitten

Die Vermessung bestimmter Codeabschnitten diente im Rahmen dieser Diplomarbeitvor allem zur Ermittlung der Ausführungszeit kritischer Programmbestandteile (sieheKapitel 5.1). Denkbar ist auch dieses Konzept zur Vermessung von Tasks für einezukünftige Echtzeitimplementierungen zu verwenden. Es ist wichtig bei der Vermessungkritischer Codeabschnitte das Ausführungsverhalten des Prozessors möglichst wenigzu beeinflussen, da andernfalls die Ergebnisse nicht aussagekräftig sein werden. Dasvorliegende Konzept wurde vom Autor bereits vor Entstehung dieser Diplomarbeit füruClinux entwickelt. Eine Veröffentlichung lag hierzu noch nicht vor. Um die Imple-mentierung unter Contiki zu verwenden, musste sie unter Beibehaltung der Grundideevereinfacht werden. Diese beruht auf der Speicherung des 64-Bit CYCLE-Registers vor undnach einem kritischen Abschnitt. Das Register wird dabei im Takt der CCLK-Frequenzinkrementiert, woraus im Nachgang Rückschlüsse auf die Dauer des kritischen Ab-schnitts gezogen werden. Beim Aufruf einer Zugriffsfunktion werden die letzten 7 Bytedes Zählregisters, eine ID-Nummer und die Information über den Ein- oder Austritt deskritischen Codeabschnitts in einer 8 Byte großen Union-Datenstruktur gespeichert.

1 set_timestamp (1, TS_ENTRY ); /* ID 1 entry */2 /*3 * Critical code section4 */5 set_timestamp (1, TS_EXIT ); /* ID 1 exit */

Listing 4.3: Vermessung eines kritischen Codeabschnitts

Diese Zeitstempel können mit unterschiedlichen ID-Nummern auch verschachtelt werden.Nach Beendigung einer Messreihe können die aufgezeichneten Zeitstempel, beispiels-weise über den UART, für die Speicherung und Verarbeitung ausgegeben werden. DieAuswertung geschieht mit einer Anwendung auf dem Hostsystem. Dabei wird für jedenAbschnitt die Differenz zwischen dem Austritt und dem Eintritt in den kritischenCodeabschnitt gebildet. Diese Differenzen können anschließend als Liste ausgegebenund als Graph gezeichnet werden. Außerdem können das Minimum, das Maximum unddas arithmetische Mittel einer Messreihe ermittelt werden. Da das Setzen von Zeit-stempeln ebenfalls Rechenzeit verbraucht, wurde dieser Vorgang auch vermessen. Dasresultierende Ergebnis kann von der Auswertungsapplikation für weitere Messergebnisseabgezogen werden, um nur den kritischen Codeabschnitt selbst zu vermessen. Auf dieFunktionsweise dieses Softwarewerkzeugs, das vom Autor ebenfalls im Vorfeld dieserArbeit entwickelt wurde, wird nicht näher eingegangen, da es nicht Gegenstand derPortierung ist.

38

Page 48: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

4.5 Test

Alle Bestandteile dieser Portierung wurden auf ihre Funktionsfähigkeit getestet, einigedavon mit den Beispielapplikationen von Contiki (zu finden unter <contiki>/examples/).Dazu zählen:

• example-shell (ohne CFS-Module)

• telnet-server (ohne CFS-Module)

• webserver

• multi-threading

Außerdem wurde eine Applikation entwickelt, welche die Fähigkeiten der Taster undLEDs erprobt (zu finden in <contiki>/platform/bf537-stamp/apps/buttons-example.c). Fürandere Bereiche wurden die nachfolgenden Testfälle entwickelt (zu finden unter <contiki

>/platform/bf537-stamp/tests/).

Für einen Langzeittest über 2 Wochen wurde eine Uhr unter Verwendung des Taskplanersimplementiert. Parallel dazu erfolgte die Realisierung der gleichen Funktionalität mitdem Contiki-Eventtimer. Hierbei konnten die Funktionsfähigkeit und die Synchronitätdes Clock- und Realtime-Moduls nachgeprüft werden. Außerdem wurde durch dieseLangzeiterprobung festgestellt, welche Stabilität das System aufweist. Während desTests liefen die Uhren synchron und es kam zu keinem Systemfehlverhalten.

Im Rahmen der Prüfung des Linkerskripts wurde versucht, die maximale Kapazität desSDRAMs durch Heap-Allokation auszuschöpfen. Dabei ist die für den Heap verfügbareSpeichermenge abhängig von der Größe der restlichen Speicherbereiche (vergleiche Kapi-tel 3.3). Es wurden für den Test solange 1 MB große Speicherblöcke mit malloc alloziert,bis der Funktionsaufruf fehl schlug und kein weiterer Speicherplatz mehr verfügbarwar. Jeder dieser Blöcke wurde mit definierten Werten beschrieben und anschließendinhaltlich verifiziert. Bei dem Test wurde festgestellt, dass das Beschreiben nur bis zumErreichen der 48 MB Grenze möglich ist. Bei Zugriff jenseits der Adresse 0x03000000löste der DSP eine Hardware-Exception aus. Nach aufwendigem Debuggen des Pro-gramms konnten Fehler weder im Linkerskript noch im Quellcode gefunden werden.Daher lag die Vermutung nahe, dass ein Hardwarefehler vorliegt. In der Hardware-Anomaly Liste (siehe [Ada]), welche eine Reihe von Fehlern im Chipdesign enthält,wurde unter dem Fehlercode 05000263 dieser Verdacht für die vorliegende Prozessor-ausführung (Silicon-Revision 0.2) bestätigt. Da keine Lösung des Problems bekannt ist,

39

Page 49: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

4 Implementierung

musste die Speicherkapazität des SDRAMs durch eine Anpassung des Speicherlayoutsim Linkerskript auf 48 MB begrenzt werden.

Die beschriebenen Testfälle decken in ihrer Summe alle Entwicklungen der vorliegendenPortierung ab. Abschließend konnten alle Tests erfolgreich durchgeführt werden.

40

Page 50: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

5 Leistungsbewertung

5 Leistungsbewertung

Zur Bestimmung der Leistungsparameter wurden unterschiedliche Messungen durch-geführt, um eine Vergleichsgrundlage zu anderen Systemen zu schaffen und die Praxi-stauglichkeit zu ermitteln. Der Quellcode für die einzelnen Messungen befindet sich, wieauch für Tests, im Verzeichnis <contiki>/platform/bf537-stamp/tests/.

5.1 Zeitmessung der Erstellung und des Wechsels vonProzessen und Threads

Neben der theoretischen Analyse des Prozessmodells (vergleiche Kapitel 2.3.2) soll mitden folgenden Messungen gezeigt werden, welche Timingparameter zur Unterscheidungder einzelnen Verfahren beitragen.

Hierbei wurden mit dem entwickelten Messwerkzeug (vergleiche Kapitel 4.4) zwei wesent-liche Charakteristiken von Prozessen und Threads bestimmt. Zum einen wurde die Dauerzwischen dem Aufruf zur Erstellung von Prozessen (process_start()) beziehungsweiseThreads (mt_init(), mt_start(), mt_exec()) bis zum Ausführen der ersten Anweisunginnerhalb der neu erstellten Umgebung ermittelt. Zum anderen war die Verzögerungzwischen dem Wechsel von Prozessen und Threads Bestandteil der Untersuchung. Dabeiwurden der Eintrittzeitstempel unmittelbar vor der Abgabe der Steuerung und derAustrittzeitstempel direkt nach dem Erhalt der Steuerung des neues Prozesses/Threadsgesetzt. Die Dauer des Wechsels ist dabei der entscheidende Parameter, um das Reakti-onsverhalten des Systems bei der Eventkommunikation beurteilen zu können. In Tabelle5.1 werden die Ergebnisse zusammengefasst.

41

Page 51: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

5 Leistungsbewertung

Tabelle 5.1: Messung des Thread- und Prozessverhaltens (8000 Messungen)

Anzahl der Takte Dauer in µsMin. Max. arith. Mittel Min. Max. arith. Mittel

Erzeugen vonProzessen 387 464 387 0,774 0,928 0,774Threads 7315 7395 7316 14,630 14,790 14,632

Wechsel zwischen

synch. Prozessen 127 149 127 0,254 0,298 0,254Threads 474 577 486 0,948 1,154 0,971asynch. Prozessen 2051 2130 2051 4,102 4,260 4,103Xenomai: RT-Tasks 14,014 23,424 15,232(600000 Messungen)

Die Messergebnisse zeigen, dass die Erzeugung von Threads ca. 18 mal länger dauertals die von Prozessen. Ursache hierfür ist die aufwendige Einrichtung des Stacks für denjeweiligen Thread.

Bei der Bestimmung der Wechseldauer wurde zwischen synchronen und asynchronenProzessen aufgrund der unterschiedlichen Behandlung im Prozesssystem unterschieden.Erwartungsgemäß war die Verzögerung beim synchronen Prozesswechsel am geringsten,da der Wechsel innerhalb des aufrufenden Prozesses statt findet. Das Verhalten vonThreads ist ebenfalls synchron. Ihr Wechsel dauerte deutlich länger, da der Stack ausge-tauscht wurde und somit ein vollständiger Kontextwechsel erfolgte. Da bei asynchronenProzessen kein Kontextwechsel durchgeführt wird, war die große Dauer überraschend.Ein Grund dafür könnte die Kommunikation mittels Events durch den Kernel sein, welchefür jeden asynchronen Prozesswechsel zuvor erfolgen muss. Zukünftige Untersuchungenmüssen diese Behauptung belegen.

Als Vergleichswert zu einem anderen Betriebssystem wurde der Wechsel eines Echt-zeittasks unter uClinux mit der Echtzeiterweiterung Xenomai hinzugezogen. Die Mess-ergebnisse wurden [Gya08] entnommen. Festzustellen ist, dass der Taskwechsel dabeideutlich langsamer erfolgt als bei allen Varianten, die Contiki ermöglicht. Da sichuClinux als Mehrzweckbetriebssystem mit deutlich höheren Ressourcenansprüchen undeinem komplexeren präemptiven Prozesssystem sehr von Contiki unterscheidet, wirdauf eine Analyse der Messergebnisse verzichtet.

42

Page 52: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

5 Leistungsbewertung

5.2 Vergleich der Netzwerkperformance zwischen Contiki undLinux

Um die Leistungsfähigkeit des entwickelten Netzwerktreibers beurteilen zu können,wurde der maximale Datendurchsatz zwischen einem herkömmlichen Notebook (Linux2.6.35.2, Core 2 Duo 2.5 GHz, Intel 82566MM Gigabit Ethernet Controller) und dem BF-537 STAMP Board vermessen. Dieser Vorgang erfolgte auf dem Blackfin mit Contiki undzum Vergleich mit dem Betriebssystem uClinux. Die verwendete Testsoftware unterschiedsich zwischen den beiden Plattformen. Während bei der Vermessung zwischen Contikiund Linux jeweils eine Eigenentwicklung eingesetzt wurde, kam bei der Vermessungzwischen den beiden Linux-Betriebssystemen das Bandbreitentestprogramm Netperfzum Einsatz (siehe [Jon09]). Da bei beiden Messungen die Ausführungsdauer derNetzwerkstacks so wenig wie möglich in die Messung einfließen sollte, wurde auf derTransportebene anstelle von TCP-, das verbindungslose und somit schnellere UDP-Protokoll eingesetzt. Eine Sende-/Empfangssequenz bestand aus 100 MByte Daten einesdefinierten Datagrammpuffers mit der Größe von 1500 Byte. Die Eigenentwicklungbasiert bei Contiki auf einem einfachen Prozess, welcher Daten bis zum Erreichen einerfesten Größe sendet oder empfängt. Vor und nach jeder Testsequenz wird zusätzlich einTimer auf Basis der Contiki-Clock gestartet und beendet. Aus dieser Zeitmessung wirdim Anschluss der Durchsatz pro Sekunde abgeleitet. Bei Linux besteht Eigenentwicklungaus einer einfachen Socketapplikation, welche die Daten in umgekehrter Richtung biszum Erreichen einer festgelegten Größe sendet oder empfängt. Tabelle 5.2 zeigt dieermittelten Bandbreitenwerte in beide Richtungen.

Tabelle 5.2: Vergleich der Netzwerkperformance zwischen Contiki und uClinux

Bandbreite in Mbit/sBF-537 mit Contiki BF-537 mit uClinux

PC Linux 2.6.35.2Upload 93,74 94,09Download 82,69 90,31

Während man den Netzwerktreiber von uClinux als Referenzimplementierung, diemaßgeblich von Analog Devices entwickelt wurde, betrachten kann, war der Contiki-Treiber in der Lage, empfangsseitig ähnlich gute Werte vorzuweisen. Sendeseitig konntenicht die gleiche Performance erbracht werden. Die Ursache liegt in dem wenigeroptimierten Netzwerkstack und der geringeren Anzahl von DMA-Puffern. Während

43

Page 53: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

5 Leistungsbewertung

uClinux standardmäßig zehn Puffer einsetzt, wird im Contiki-Treiber, um Speicherplatzim SRAM zu sparen, nur ein Puffer aktiviert. Es ist außerdem davon auszugehen, dassdie Testapplikation Netperf durch die langjährige Entwicklung besser optimiert ist, alsdie beschriebenen Eigenentwicklungen.

5.3 Ermittlung des Speicherverbrauchs

Um Kapazitätsengpässe bei den unterschiedlichen Speichern des Blackfin zu vermeiden,ist es notwendig den Speicherverbrauch abzuschätzen. Probleme mit der Speichergrößekönnen besonders beim Stack- und dem BSS-Segment auftreten, da diese dem relativkleinen SRAM zugewiesen wurden. Die Ermittlung des Codesegments, der Datensegmen-te BSS und Data stellte keine Schwierigkeit dar, weil deren Größe statisch ist und diesebereits vor Programmausführung fest steht. Mit dem Werkzeug der Blackfin-Toolchainbfin-elf-size können diese Größenangaben aus der gelinkten ELF-Programmdatei aus-gelesen werden. Diese Vorhersage funktioniert jedoch nicht bei dynamischen Speichern.Der Heapspeicher wurde nicht untersucht, da Contiki dieses Segment aktuell nichtverwendet.

Die Feststellung des Stackverbrauchs ist besonders in Applikationen, die Funktionspoin-ter und Rekursion einsetzen, schwierig. Der Grund dafür ist, dass die Stackgröße abhängigvon den Laufzeitparametern ist, woraus sich ein nichtdeterministisches Verhalten ergibt.Aktuell ist kein Verfahren bekannt, das den Stackverbrauch vor Programmausführungexakt bestimmen kann. Es wurde daher ein einfaches Verfahren implementiert, welcheszur Programmlaufzeit die maximale Stackausdehnung erkennt. Dabei beschreibt eineInitialisierungsfunktion am Anfang der Programmausführung den noch unbenutztenStack mit einem Schlüsselwort. Eine Funktion, die periodisch mittels des Taskplanersaufgerufen wird, prüft vom Ende des Stacks (in positiver Richtung) bis zu welcherAdresse das Schlüsselwort noch vorhanden ist. Diese Adresse markiert die maximaleAusdehnung des Stacks. Um diese Ausdehnung möglichst exakt zu ermitteln, solltewährend der Durchführung versucht werden, alle Pfade der Applikation zu durchlaufen.Das folgende Listing zeigt die Funktion zur Ermittlung des Stackverbrauchs.

1 void check_stack ( struct rtimer *t, void *ptr)2 {3 extern char _stack_end ; /* defined by linker script */4 extern char _stacksize ; /* defined by linker script */5 char * stack_address ;6

7 stack_address = (char *)(& _stack_end - & _stacksize );

44

Page 54: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

5 Leistungsbewertung

8

9 /* ’X’ is the Keyword */10 while (* stack_address == ’X’ && stack_address < & _stack_end )11 ++ stack_address ;12

13 printf ("stack space used: %lu\r\n", & _stack_end - stack_address );14

15 /* reschedule the task in 5000 ms */16 rtimer_set (t, RTIMER_NOW () + 5000 , 0, check_stack , ptr);17 }

Listing 5.1: Kontextwechsel für Multithreading

In Tabelle 5.3 wird der Speicherverbrauch von vier getesteten Applikationen zusammen-gefasst.

Tabelle 5.3: Speicherverbrauch von Contiki inklusive einer Applikation (in Byte)

Hello-World Example-Shell Webserver TelnetData 2264 4080 2540 3112BSS 4496 14900 7880 10756Max. Stackverbrauch 2484 2640 2524 2648Gesamt Datenspeicher 9224 (9 kB) 21620 (21 kB) 12944 (13 kB) 16516 (16 kB)Text 58000 131512 86620 97516Gesamt 67224 (66 kB) 153132 (150 kB) 99564 (97 kB) 114032 (111 kB)

Die „Hello-World“-Applikation stellt unter den erfassten Applikationen eine Besonder-heit dar, da hierbei der Netzwerkstack gezielt deaktiviert wurde. Bei allen anderenApplikationen beansprucht der uIP-Netzwerkstack bereits 4 kB des BSS-Segments fürsich. Erwähnenswert ist, dass Contiki für 8-Bit-Architekturen entworfen wurde. Folglichist der Speicherverbrauch aufgrund der 32-Bit-Adress- und Befehlslänge deutlich größerals auf 8-Bit-Systemen. Bewertet man den Speicherverbrauch von Contiki stellt manfest, dass dieser sich dennoch auf einem sehr niedrigem Niveau befindet.

45

Page 55: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

6 Zusammenfassung und Ausblick

6 Zusammenfassung und Ausblick

Contiki konnte erfolgreich auf die Blackfin-Plattform portiert werden. Damit wurdensicherlich nicht alle Möglichkeiten der Blackfin-Plattform ausgeschöpft. Auch wenn diewichtigsten Hardwarekomponenten von Contiki unterstützt werden, sind die Leistungs-reserven der Recheneinheit des Blackfins nicht angetastet worden. Vielmehr wurde mitdieser Portierung die Grundlage geschaffen, eine Betriebsystemumgebung bereitzustellen,die diese Leistungsreserven für die digitale Signalverarbeitung optimal ausnutzen kann.Es wurde gezeigt, was Contiki leistet und wie minimal der Ressourcenverbrauch dabeiist. Dieser Umstand ist umso bedeutender, da die Regel gilt: Je weniger Ressourcen dasBetriebssystem benötigt, umso mehr stehen den Applikationen, die darauf laufen, zurVerfügung.

Obwohl die Anforderungen an diese Portierung insgesamt alle erfüllt werden konnten,bietet dieses Projekt noch viel Raum für Weiterenwicklungen, die bisher aus Zeitgründennicht alle realisiert wurden. Wünschenswert wäre die Aktivierung des Flash-Speichersunter Nutzung des Contiki-Dateisystems CFS. Weiterhin würde die native Unterstützungdes Befehlscaches das Betriebssystem unabhängig vom Bootloader U-Boot machen. DieOptimierung des Netzwerktreibers und die Ermöglichung von IP-Segmentierung sindweitere Punkte, die diese Portierung komplettieren würden. Ebenfalls erstrebenswertwäre es, nach der theoretischen Betrachtung des Echtzeitthemengebiets praktischeErfahrungen mit Contiki zu sammeln.

Leider ist mit dem BF-537 STAMP Board keine Funkübertragung möglich. Entwicklun-gen in diesem Bereich werden in Contiki aktuell am stärksten voran getrieben. Dabeigeht es vorrangig um Technologien für WSNs. Hierbei wäre der Einsatz von leistungsfä-higen Sensorknoten ein Bereich, in dem aktuell kaum geforscht wird, da man sich eherauf leistungsschwächere und stromsparende Hardware-Technologien konzentriert. DerEinsatz von Blackfin in Verbindung mit ZigBee, WLAN oder anderen aktuellen Funk-technologien, unter Verwendung von Contiki, wäre ein neuartiger und vielversprechenderAnsatz, um komplexe Probleme innerhalb WSNs lösen zu können.

Das Projekt hat dem Autor während seiner Umsetzung viel Spaß bereitet und dazubeigetragen, seine Kenntnisse auf diesem Themengebiet umfangreich zu erweitern. Erbeabsichtigt auch nach Abschluss der Diplomarbeit an diesem Projekt weiterzuarbeiten.

46

Page 56: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

6 Zusammenfassung und Ausblick

6.1 Thesen

1. Bei Blackfin handelt es sich um eine leistungsfähige DSP-Architektur. Der RISC-Prozessorkern und die Integration einer Vielzahl von peripheren Komponenteneröffnen ein breites Einsatzspektrum im Bereich eingebetteter Systeme.

2. Contiki ist ein äußerst ressourcenschonendes Betriebssystem, in dem eine Viel-zahl von Bibliotheken und Subsystemen integriert ist. Es bietet dem Entwicklerdarüber hinaus viele Freiheiten, wie zum Beispiel den direkten Hardwarezugriff.Andererseits exisistert kein Speicherschutz, kein Schutz vor Stack-Overflows sowiekeine ausgeprägte Fehlerbehandlung in Bibliotheken. Mit Contiki ist somit einesehr flexible Entwicklung möglich, die gleichzeitig vom Entwickler eine hohes Maßan Verantwortung fordert.

3. Das Contiki-Prozesssystem ist eine minimalistische Umsetzung einer eventgesteuer-ten Architektur. Prozesse werden nach dem Prinzip des kooperativen Multitaskingseingeplant. Der Kernel hat hierbei keinen Einfluss auf Prozesse, da sie nach demStarten autonom sind. Dies führt dazu, dass Contiki sehr gut an unterschiedlichleistungsfähige Hardwareplattformen skaliert. Ergänzt wird das Prozesssystemdurch präemptives Multithreading.

4. Das Prozesssystem eignet sich prinzipiell für das zeitgesteuerte Echtzeitscheduling,unterstützt den Entwickler aber dabei nicht. Hierfür müssen die Echtzeittasksund das Betriebssystem sorgsam auf der jeweiligen Architektur vermessen werdenund zu einer Echtzeitapplikation zusammengesetzt werden. Eine eingeschränkteEchtzeitlösung bietet der Taskplaner.

5. Contiki kann erfolgreich auf Blackfin portiert werden. Dazu gehören sowohl dasKernsystem, als auch die Treiber für den MAC, UART, Timer, Taster und LEDs.Architekturspezifische Anpassungen für Contiki können ebenso wirksam vorge-nommen werden. Diese umfassen das Ausnutzen des L1-SRAMs und das Multi-threading.

6. Die Kombination aus Blackfin und Contiki liefert vergleichsweise gute Leistungsda-ten. Zu diesen gehört eine hohe Netzwerkperformance, die nahe an das Maximumdes möglichen Datendurchsatzes heranreicht. Weiterhin verdeutlicht das Timingver-halten von Prozessen und der geringe Speicherverbrauch den minimalen Overheaddes Betriebssystems.

47

Page 57: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

6 Zusammenfassung und Ausblick

6.2 Bezugsquellen der Software

Die entwickelte Software kann momentan von zwei verschiedenen Quellen bezogen werden.Als Paket ist sie zusammen mit einem Snapshot aus dem Contiki-CVS über Sourceforge[Dre10a] oder über das uClinux-Projekt [Dre10b] abrufbar. Der Quellcode, der im Rah-men dieser Diplomarbeit entstand, ist auch separat über das Versionkontrollsystem git un-ter git://contiki-bf537.git.sourceforge.net/gitroot/contiki-bf537/contiki-bf537

abrufbar.

Eine Anleitung zum Kompilieren und Ausführen von Contiki-Applikationen in Ver-bindung mit dem Bootloader U-Boot liegt dem Projekt unter <contiki>/platform/bf537-

stamp/README bei.

48

Page 58: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Literatur

Literatur

[Abe08] Julien Abeille. Contiki uIPv6 / 6lowpan Stack FAQ. 29. Sep. 2008. url:http://www.sics.se/contiki/contiki-6lowpan-uipv6-faq.html (besuchtam 29. 06. 2010).

[Ada] Silicon Anomaly List. C. Analog Devices. Feb. 2008.

[Adh] ADSP-BF537 Blackfin® Processor Hardware Reference. 3.2. Analog Devices.März 2009.

[Adp] Blackfin® Processor Programming Reference. 1.3. Analog Devices. Sep. 2008.

[Aki08] Akiba. DevJournal - Finished the switch to dynamic allocation and ma-naged memory. 25. Okt. 2008. url: http://freaklabs.org/index.php/

Blog/FreakZ/DevJournal- Finished- the- switch- to- dynamic- allocation-

and-managed-memory.html (besucht am 11. 07. 2010).

[Bur09] Burindes. Contiki Application Examples. 23. Juli 2009. url: http : / /

senstools.gforge.inria.fr/doku.php?id=contiki:examples (besucht am22. 09. 2010).

[Bur10] Burindes. Contiki. 24. Feb. 2010. url: http://senstools.gforge.inria.fr/

doku.php?id=os:contiki (besucht am 01. 08. 2010).

[Cor10] Surveyor Corporation. Surveyor SRV-1 Blackfin Robot. 27. Apr. 2010. url:http://www.surveyor.com/SRV_info.html (besucht am 04. 06. 2010).

[Dan06] Clarence Dang. „Optimising L4 on Blackfin 533/537“. Bachelor Thesis. TheUniversity of New South Wales, 2006.

[Des08] Hiren Desai. ADSP-BF533 Blackfin® Booting Process. Techn. Ber. E240.Analog Devices, Sep. 2008.

[Dre10a] Marcus Dreier. Contiki for the BF-537 STAMP. 28. Aug. 2010. url:http://sourceforge.net/projects/contiki- bf537/develop (besucht am02. 09. 2010).

[Dre10b] Marcus Dreier. Contiki for the BF-537 STAMP board. 28. Aug. 2010. url:http://blackfin.uclinux.org/gf/project/contiki- bf537 (besucht am02. 09. 2010).

49

Page 59: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Literatur

[Dun06a] Adam Dunkels. Memory Block Management in Contiki. 18. Dez. 2006. url:http://www.sics.se/contiki/developers/memory-block-management-in-

contiki.html (besucht am 08. 06. 2010).

[Dun06b] Adam Dunkels. Protothreads - Lightweight, Stackless Threads in C. 2. Okt.2006. url: http://www.sics.se/~adam/pt/ (besucht am 01. 07. 2010).

[Dun07a] Adam Dunkels. „Programming Memory-Constrained Networked EmbeddedSystems“. Diss. SICS, 2007.

[Dun07b] Adam Dunkels. Rime - A Lightweight Layered Communication Stack forSensor Networks. Techn. Ber. Swedish Institute of Computer Science, Jan.2007.

[Dun10] Adam Dunkels. The Contiki Operating System. Doxygen Dokumentation.Version Contiki 2.4. 16. Feb. 2010. url: http://www.sics.se/~adam/contiki/

docs/ (besucht am 08. 07. 2010).

[For09] Johan Forrer. Building Free-Standing GCC-based Applications for the P1.3. Feb. 2009. url: http://www.johanforrer.net/BLACKFIN/index.html (be-sucht am 22. 05. 2010).

[Fry08] Mike Frysinger. Blackfin U-Boot Memory Layout. 28. Juli 2008. url: http:

//docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:memory-

layout (besucht am 02. 06. 2010).

[Fry10] Mike Frysinger. Application Binary Interface. 9. Apr. 2010. url: http://

docs.blackfin.uclinux.org/doku.php?id=toolchain:application_binary_

interface (besucht am 29. 07. 2010).

[Get09a] Robin Getz. Cache Management. 10. Sep. 2009. url: http://docs.blackfin.

uclinux.org/doku.php?id=bfin:cache (besucht am 28. 08. 2010).

[Get09b] Robin Getz. Using On-Chip SRAM Memory. 13. Juli 2009. url: http:

//docs.blackfin.uclinux.org/doku.php?id=linux-kernel:on-chip_sram

(besucht am 11. 08. 2010).

[Gya08] Gyang. Xenomai/Adeos porting for Blackfin. 3. Juni 2008. url: http://

docs.blackfin.uclinux.org/doku.php?id=linux-kernel:adeos (besucht am29. 06. 2010).

[Hav98] Frank Haverkamp. Was sind DSPs? 6. Feb. 1998. url: http://www.ibr.cs.

tu-bs.de/courses/ws9798/seminar/haverkamp/seminar.html (besucht am04. 06. 2010).

[Jon09] Rick Jones. Netperf. 11. Juni 2009. url: http://www.netperf.org/netperf/

(besucht am 26. 08. 2010).

50

Page 60: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Literatur

[Lev01] John Levine. Linkers and Loaders. 1. Mai 2001. url: http://www.iecc.com/

linker/ (besucht am 05. 08. 2010).

[Lie06] André Liesk. „Porting eCos to the Analog Devices BLACKfin DSP“. Di-plomarbeit. Chemnitz University of Technology, 2006.

[Mur] Niall Murphy. How to Allocate Dynamic Memory Safely. url: http://

www.netrino.com/Embedded-Systems/How-To/Malloc-Free-Dynamic-Memory-

Allocation (besucht am 09. 07. 2010).

[Rom88] J. Romkey. A NONSTANDARD FOR TRANSMISSION OF IP DATA-GRAMS OVER SERIAL LINES: SLIP. 1. Juni 1988. url: http://tools.

ietf.org/html/rfc1055 (besucht am 20. 07. 2010).

[son10] sonicz. Das U-Boot Bootloader. 2. Aug. 2010. url: http://docs.blackfin.

uclinux.org/doku.php?id=bootloaders:u-boot (besucht am 27. 09. 2010).

[Str10] Martin Strubel. ICEbear User Manual. 1.4.1. März 2010.

[Tat08] Simon Tatham. Coroutines in C. 27. März 2008. url: http://www.chiark.

greenend.org.uk/~sgtatham/coroutines.html (besucht am 03. 07. 2010).

[Tsi09] Nicolas Tsiftes. Coffee: Contiki’s Flash File System. 27. Jan. 2009. url:http://www.sics.se/contiki/developers/coffee-contikis-flash-file-

system.html (besucht am 24. 05. 2010).

[Tsi10] Nicolas Tsiftes. ContikiRPL: the new Default Contiki IPv6/6lowpan Rou-ting Protocol. 5. Mai 2010. url: http://www.sics.se/contiki/tutorials/

contikirpl- the- new- default- contiki- ipv6/6lowpan- routing- protocol.

html (besucht am 30. 06. 2010).

[Wik10a] Wikipedia. Race condition. 1. Apr. 2010. url: http://de.wikipedia.org/

wiki/Interrupthandler (besucht am 14. 09. 2010).

[Wik10b] Wikipedia. Virtuelle Speicherverwaltung. 9. Juni 2010. url: http://de.

wikipedia.org/w/index.php?title=Virtuelle_Speicherverwaltung&oldid=

75357691 (besucht am 16. 06. 2010).

[Wik10c] Wikipedia. Wireless sensor network. 30. Juni 2010. url: http : / / en .

wikipedia.org/wiki/Wireless_sensor_network (besucht am 01. 07. 2010).

51

Page 61: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart

Selbständigkeitserklärung

Selbständigkeitserklärung

Ich versichere, dass ich die Diplomarbeit selbständig verfasst und keine anderen als dieangegebenen Quellen und Hilfsmittel benutzt habe.

52

Page 62: Hochschule für Technik und Wirtschaft Dresden (FH)robge/arbeiten/2010/da-marcus-dreier.pdfEine DMA-Konfiguration muss bestimmte Parameter beinhalten. Zu diesen zählen die Betriebsart