Projekt Sensor- und Regelungssysteme€¦ · 8.5 Beispielprogramm: Sensordaten via I²C von einem...

Projekt Sensor- und Regelungssysteme

InhaltsverzeichnisVerwendete Betriebssysteme und Softwareversionen:.....................................................................................2 0 Lernziele Projekt Sensor- und Regelungssysteme (PSR..............................................................................3 1 Einleitung...................................................................................................................................................... 3 2 Roboterhardware.......................................................................................................................................... 5 3 Die BeagleBone Grundlagen........................................................................................................................ 5

3.1 Die BB-Hardware.................................................................................................................................. 6 3.2 Grove Cape für den BB......................................................................................................................... 6 3.3 Programmierung des BeagleBone........................................................................................................7

3.3.1 Skriptprogramme:......................................................................................................................... 7 3.3.2 Kompilierte Programme................................................................................................................8

4 Vorbereitung des BeagleBone...................................................................................................................... 8 4.1 Erste Inbetriebnahme............................................................................................................................ 9 4.2 Anschließen des BeagleBone via Ethernet.........................................................................................11

4.2.1 Ermitteln der IP-Adresse des BB................................................................................................11 4.2.2 Anschließen mehrerer BB via Ethernet.......................................................................................11

5 Linuxbetriebssystem auf dem BeagleBone.................................................................................................12 5.1.1 Ermitteln der installierten Linuxdistribution..................................................................................12 5.1.2 Installation einer Linuxdistribution auf dem BB...........................................................................12 5.1.3 Installation von Linuxsoftware auf dem BB.................................................................................12

6 Umgang mit Linux....................................................................................................................................... 13 6.1 Dateimanagement auf dem BB, Übertragen von Dateien zwischen PC und BB.................................13 6.2 Der Bootvorgang................................................................................................................................. 14

7 Die Ein- und Ausgänge des BB...................................................................................................................15 7.1 Der Device Tree (DT): Festlegen der Pinzuordnung beim Booten ohne Capemanager.....................17 7.2 Das Device Tree Overlay (DTO): Festlegen der Pinzuordnung nach dem Booten über dem Capemanager............................................................................................................................................ 18

7.2.1 Anzeigen des aktuell geladenen DTOs.......................................................................................19 7.2.2 Manuelles Laden und Entladen eines DTO aus der Linuxkommandozeile mit Hilfe des Capemanagers..................................................................................................................................... 19 7.2.3 Automatisches Laden eines oder mehrerer DTOs beim Bootvorgang........................................20 7.2.4 Erstellen eines DTO....................................................................................................................21

7.3 Das SysFS.......................................................................................................................................... 21 7.4 Die I²C-Busse..................................................................................................................................... 22 7.5 Hardwarespezifisches......................................................................................................................... 22 7.6 Bei Matlab/Simulink zu beachten........................................................................................................23

8 Einbinden von Sensoren und Aktoren über Pythonskripte..........................................................................23 8.1 Installation notwendiger Phytonbibliotheken.......................................................................................24 8.2 Beispielprogramm: LED blinken lassen..............................................................................................25 8.3 Analogspannung auslesen (ADC).......................................................................................................26 8.4 Beispielprogramm: Analogen Ultraschallsensor HC-SR04 auslesen..................................................26 8.5 Beispielprogramm: Sensordaten via I²C von einem MPU6050 IMU-Sensor „zu Fuß“ auslesen.........27 8.6 Beispielprogramm: Sensordaten via I²C von einem BMP180 Drucksensor mit „Black Box“ Bibliothek auslesen.................................................................................................................................................... 28

9 Vorbereitung der Matlab/Simulink-Umgebung und des Targets BBG..........................................................30 9.1 Simulink-Beispielprogramm beaglebone_gettingstarted.....................................................................31 9.2 Bekannte Probleme:........................................................................................................................... 32

10 Programmieren des BB über Simulink......................................................................................................32 10.1 Wieso macht der Einsatz von Simulink hier Sinn?............................................................................32

Prof. Dr. S. Mack Projekt SensorsystemeBeagleBone Vers. 3, 11.07.16 IP 192.168.7.2 Seite 1 von 65

10.2 Ausführen eines Simulinkmodells auf dem BB.................................................................................35 10.3 Beispielmodell: Externe LED blinken lassen.....................................................................................35 10.4 Beispielmodell: Analogspannung auslesen (ADC)............................................................................35 10.5 Indirekter Zugriff von Simulink auf Sensorwerte über eine Übergabedatei.......................................36 10.6 Beispielmodell: Sensor MPU6050 via I²C auslesen..........................................................................38 10.7 Beispielmodell: Analoger Ultraschallsensor HC-SR04 auslesen.......................................................40 10.8 Kontrolle der Ausführungsgeschwindigkeit des Programms auf dem BB..........................................42 10.9 Bekannte Probleme / Fehler / Ungereimtheiten................................................................................43

11 Verwendung selbst erstellter S-Function Blöcke.......................................................................................43 11.1 Debuggen eines S-Function Builder Blocks......................................................................................44

11.1.1 Verwenden von Log-Dateien.....................................................................................................44 11.1.2 Ausführen des Modells auf dem BB über eine Linuxkonsole....................................................44

11.2 Im Praktikum verfügbare S-Function Builder Blöcke als Ausgangsbasis..........................................45 11.2.1 I²C Bus Lesen........................................................................................................................... 45 11.2.2 I²C Bus Schreiben..................................................................................................................... 46 11.2.3 GPIO Lesen.............................................................................................................................. 46 11.2.4 GPIO Schreiben........................................................................................................................ 46 11.2.5 HCM5883L GMR Magnetfeldsensor auslesen (I²C)..................................................................46 11.2.6 SRF02 Ultraschallsensor auslesen (I²C)...................................................................................47 11.2.7 MPU6050 Beschleunigungs-/Drehratensensor auslesen (I²C)..................................................47

12 Anhang..................................................................................................................................................... 48 12.1 Pinbelegung (Quelle [2])...................................................................................................................48 12.2 Das Grove Cape (Version 1) (Quelle [12])........................................................................................49 12.3 Das Grove Base Cape (Version 2) (Quelle [38])...............................................................................50 12.4 Linux Dateimanagement mit dem Midnight Commander..................................................................51 12.5 IDE Cloud9 für die BB Programmierung und für den Filetransfer zwischen BB und PC...................51 12.6 Fernzugriff auf die grafische Benutzeroberfläche des BB via VNC...................................................53 12.7 Übersicht BB Hardware (Quelle [19])................................................................................................54 12.8 Pinkonfiguration (Quelle [19]), siehe auch [18].................................................................................55 12.9 Nano Cheat Sheet [39].....................................................................................................................57 12.10 Linux Cheat Sheet [40], alternativ [41]............................................................................................59 12.11 Ausgabetext des seriellen Debugschnittstelle während des Bootes bis zum Start des Kernels......60 12.12 Matlabquellcode des Simulink Matlab Function Blocks SensorFromFile........................................61 12.13 Paketmanagement über apt............................................................................................................61 12.14 Glossar........................................................................................................................................... 62 12.15 Verwendete Abkürzungen...............................................................................................................62 12.16 Kommunikationsmöglichkeiten mit dem BB....................................................................................63

Quellenverzeichnis......................................................................................................................................... 64

Verwendete Betriebssysteme und Softwareversionen:

PC: Matlab/Simulink R2015a, R2015aSP1 oder R2015b

PC: Windows 7, 32 oder 64 Bit

BeagleBone Green oder Black: Debian GNU/Linux Version 7.9 (wheezy)


0 Lernziele Projekt Sensor- und Regelungssysteme (PSR• Umgang mit komplexen eingebetteten Systemen am Beispiel eines BeagleBone (BB).

• Erlernen einfacher Grundlagen im Umgang mit Linux als Betriebssystem eines eingebette-ten Systems, insbesondere das Einbinden der Schnittstellen zur Peripherie.

• Erlernen der Kommunikation zwischen einem Linux-basierten eingebetteten System und folgender Arten von Sensoren: Binäre Sensoren, analoge Sensoren, digitale Sensoren mit UART, I²C oder SPI Bus, digitale Sensoren mit Netzwerkschnittstelle.

• Nutzung einfacher Pythonskripte zusammen mit vorhandenen Bibliotheken zum Testen der Sensorfunktion, -kommunikation und der Sensordatenfusion.

• Erlernen verschiedener Konzepte der Sensorkommunikation sowie deren Vor- und Nachtei-le: Vergleich von Skripten wie Python bzw. Javascript mit nativen C-Programmen auf einemeingebetteten Linuxsystem bzw. auf einem Mikrocontroller.

• Erfahren, was Echtzeitdatenverarbeitung für ein eingebettetes System bedeutet, wodurch diese begrenzt wird und wie sie verifiziert wird.

• Erstellen von Programmcode für den BeagleBone über ein Simulinkmodell, das u.a. die Kommunikation mit mehreren Sensoren und Aktoren beinhaltet. Kennenlernen der ver-schiedenen Modi der Programmausführung wie z.B. des „External Mode“ für die Modellopti-mierung oder Fehlersuche.

• Kennenlernen, wie der Programmcode aus dem Simulinkmodell mit getrennten Prozessen verzahnt werden kann, die die Kommunikation mit den Sensoren und Aktoren bearbeiten.

• Erlernen der Systemauslegung, des Programmierens einer Sensordatenfusion, sowie des Aufbaus eines Regelkreises über Simulink mit einem Roboterfahrzeug als Anwendungsbei-spiel.

• Praxiserfahrung im Design, Test und in der Optimierung einer Robotikanwendung.

• Erlernen von Strategien zur Fehlersuche in einem komplexen mechatronischen System.

• Praxis im technischen Dokumentieren von Projektergebnissen und Präsentation derselben in einem Vortrag.

• Erkennen der Vorteile des „Rapid Prototyping“ durch das Verwenden des BeagleBone zu-sammen mit Matlab/Simulink und Python im Vergleich zur Entwicklung mit einer konventio-nellen IDE wie Eclipse.

• Erkennen der Vor- und Nachteile der modellbasierten Entwicklung von Algorithmen und derautomatischen Codeerzeugung mit Simulink. Erkennen des Praxisbezugs hiervon.

• Verstehen, was „Hardware in the Loop“ in diesem Kontext bedeutet: Simulation des Robo-terfahrzeugs unter Einbinden des realen eingebetteten Systems für die Verifikation dessen Softwarefunktion.

1 EinleitungSensoren werden meistens über Mikrocontroller (µC) ausgelesen oder parametriert.Im Automobilbereich werden beispielsweise die Raddrehzahlsensoren vom µC des ABS-Steuerge-räts ausgelesen, welches die Ventile der einzelnen Bremsen steuert. Im Bildungs- und Hobbybe-reich verwendet man oft die Arduino-Plattform mit einem ATmega8 µC, der z.B. via I²C-Bus mit Sensoren kommuniziert. Ein µC wird überwiegend nur für eng begrenzte Aufgaben eingesetzt und besitzt eine limitierte Rechenleistung sowie einen limitieren Speicherplatz. Sein großer Vorteil ist neben den geringen Kosten sein zeitlich deterministisches Verhalten („Echtzeitverhalten“), weshalb


er sich für zeit- und sicherheitskritischen Anwendungen eignet.

Für komplexe Regelungsaufgaben wie z.B. das autonome Fahren reicht die Rechenleistung eines einfachen µC bei weitem nicht mehr aus. Hier verwendet man komplexe eingebettete Systeme, dieaus einem Mikrocomputer inkl. Betriebssystem (meistens Linux) bestehen. Solche Rechner nenntman „Linux Embedded System (LES)“.

Auch ein PC oder ein Laptop wird als Mikrocomputer bezeichnet. Der Rechner ist hier aber körper-lich auf verschiedene Komponenten aufgeteilt, wie der Prozessor, der Grafikchip, der RAM-Spei-cher und etwa die Festplatte. Außerdem wird ein PC anders als ein µC oder LES universell und nicht nur für eine eng eingegrenzte Anwendung verwendet.

Bei den LESs befindet sich ein Großteil der Rechnerhardware auf einem hochintegriertem Chip. Daher spricht man hier auch von einem „System on a Chip (SoC)“.Prominente Vertreter solcher LESs sind der Raspberry Pi, der Arduino Yun sowie der BeagleBone (BB)1.

Diese Systeme beinhalten wie PCs einen leistungsstarken Prozessor mit mehreren Hundert MHz Taktfrequenz, einen mehreren GByte großen Arbeitsspeicher und als Festplattenersatz einen ebenso großen Flashspeicher (z.B. eMMC). Wie bei einem PC-Mainboard gibt es auch Schnittstel-len wie HDMI, USB, Ethernet oder WLAN.

Anders als µC - die eigentlich „wahren“ SoCs2 - sind LESs mit einem Betriebssystem ausgestattet. Dabei handelt es sich im Gegensatz zu PCs meistens um ein Linux-Betriebssystem ohne grafischeBenutzeroberfläche.

Ein für das Sensor- und Regelungssystemeprojekt (SRP) wesentlicher Vorteil von LES gegenüber einem PC sind dessen sogenannte I/Os („Inputs / Outputs“). Diese Ein-/Ausgabepins sind beim Raspberry Pi und BB ähnlich wie beim Arduino auf Buchsenleisten hinausgeführt. Erst dadurch ist das Anschließen von Sensoren und Aktoren einfach möglich.

Eigentlich müsste man LES besser „Linux auf einem eingebetteten System“ nennen: Denn das eingebettete System profitiert von allen allgemeinen Linuxvorteilen, wie von dessen Effizienz, von der riesigen Anzahl hochwertiger Open Source Software, vom exzellenten Open Source Support, von den fehlenden Lizenzkosten und nicht zuletzt von der hohen Stabilität dieses Betriebssystems,das sowohl für Konsumprodukte wie Digitalkameras als auch auf großen Servern Verwendung fin-det.

Da Linux auf vielen verschiedenen SOCs verwendet wird, können fertige Applikationen ohne grö-ßeren Aufwand auch auf andere Plattformen portiert werden, wenn z.B. die Leistungsfähigkeit des ursprünglichen SOCs nicht mehr ausreicht.

Neben den Kosten ist der Hauptnachteil von LES die fehlende (harte) Echtzeitfähigkeit:µC haben den Vorteil, dass deren I/Os zeitlich deterministisch (in „Echtzeit“) bedient werden. Bei einem Mikrocomputer ist das aufgrund dessen Betriebssystems normalerweise nicht der Fall. Manchmal muss der Prozess zur Abfrage eines Sensorausgangs auf einen anderen vorher gestar-teten Prozess warten.

Den BB zeichnet aber noch aus, dass er zusätzlich zu seinem Prozessor zwei „Programmable Real-Time Units (PRU)“ sozusagen als Koprozessoren besitzt, die für die Ein-/Ausgabepins zu-ständig sind:Die PRU des BB sind auf dem µP Chip zusätzlich integrierte µC, die unabhängig von der Prozes-sorauslastung die I/Os bedienen. Ein ähnliches Konzept besitzt übrigens auch der Arduino YUN, welcher aus Kompatibilitätsgründen jedoch nur einen leistungsschwachen ATmega8 µC separat

1 Anfänglich wurde dieser Mikrocomputer als „BeagleBoard“ bezeichnet. Daher tauchen jetzt in der Litera-tur die Begriffe „BeagleBone“ und „BeagleBoard“ mehr oder weniger gleichbedeutend auf.

2 Bei µC sind die Rechnerkomponenten in der Regel komplett in einem Chip integriert. Auf den LESs ist z.B. der Flashspeicher meistens auf einem getrennten Chip untergebracht.


auf der Platine als „PRU“ verwendet.

Im Vergleich zum Raspberry Pi hat der BB wesentlich bessere Schnittstellen zur Peripherie (Sen-soren und Aktoren). Im Vergleich zum Arduino Yun ist er deutlich leistungsfähiger. Insgesamt ist der BB auch die professionellste Plattform unter den Maker-LES.

Ein wesentliches Lernziel des Praktikums ist das Erlernen des „Rapid Prototyping“. Hierfür ist der BB eine ideale Hardwareplattform. Dazu muss aber auch eine „Rapid“ Softwareentwicklung hinzu-kommen, die sich grundsätzlich von der komplexen hardwarenahen C Programmierung unter-

scheiden muss:

Im Praktikum wird daher erstens die Programmiersprache Python verwendet. Zweitens wird über Matlab/Simulink modellbasiertprogrammiert, wobei der letztendliche C-Code automatisch erzeugt, kompiliert und auf den BB übertragen wird.

2 RoboterhardwareAls Roboterplattform wird das „Pirate-4WD“-Fahrzeug von DFRobot verwendet [1]. Es besitzt vier Gleichstromantriebe mit Getriebe. Die beidenRäder auf der linken und rechten Seite werden jeweils gemeinsam angesteuert. Alle Räder kön-nen bei Bedarf mit Drehencodern ausgestattet werden. Der BB steuert mittels PWM-Signale über einen H-Brücken-Motortreiber die Motoren an. Die Energieversorgung geschieht über eine USB-Powerbank.

Achtung: Bei Lastspitzen durch den Motortreiber kann die Versorgungsspannung des BB so stark einbrechen, das dieser einen Reset durchführt. Die hier gezeigte Lösung mit zwei getrennten Po-werbanks für die Stromversorgung ist grundsätzlich aber nicht nötig und sollte vermieden werden.

3 Die BeagleBone GrundlagenAuf dem BB selbst und im Internet finden sich unzählige Informationen, wobei die erste Anlaufstel-le immer die Internetseiten der BeagleBoard.org Foundation sein sollte [2]. Als Fachliteratur wird an erster Stelle auf [3], aber auch auf [4] und [5] verwiesen. Im Internet findet sich unter [6] vom Elektronikhersteller Adafruit umfangreiche Lernmaterialien und Python-Bibliotheken.

Die meisten Internetseiten und Bücher beziehen sich im Schwerpunkt auf die Programmierung desBB über JavaScript oder Python. Nur [3] bzw. [7] behandeln ausreichend die Programmiersprache C und das Anschließen von Peripherie. Speziell die Codegenerierung unter Matlab/Simulink für den BB ist lediglich im Lehrbuch [8] und in der Masterthesis [9] ansatzweise erklärt.

Alle bis hierhin genannte Lehrbücher sind als Printbücher in der Hochschulbibliothek ausleihbar.

Im SRP wird der „BeagleBone Green (BBG)“ verwendet. Der BBG unterscheidet sich vom bekann-teren „BeagleBone Black (BBB)“ nur darin, dass er aus Kostengründen keine HDMI-Schnittstelle aber dafür je eine „Grove“-Steckerbuchse für UART und I²C Peripherie hat, siehe [10].


Vom BBB und gibt es mehrere Varianten („Revisions“), welche sich z.B. in der Flashspeichergrößeunterschieden. Für das SRP sind die Revisions der BBB jedoch unerheblich.

Ein BBG kostet ca. 50 €, und es gibt wie bei allen BBs unterschiedliche Bezugsquellen. Siehe hier-für z.B. [11] oder [12].

3.1 Die BB-HardwareDas Herzstück des BB ist der Texas Instruments Sitara 1 GHz ARM-A8 Cortex Prozessor. Für ihn wird recht konsistent z.B. bei Dateibezeichnungen die Abkürzung „AM335x“ verwendet.Der BBG besitzt u.a. folgende Datenschnittstellen:

65 binäre I/Os (GPIOs), 8 DACs als PWM Ausgänge, 7 ADCs, 2 I²C, 2 SPI, 2 UART, 2 CAN, micro-SD-Karte, USB Host (USB-A), USB Client (Micro-USB), Ethernet (RJ45).

Als Benutzerinterface besitzt er nur 4 LEDs. Von Außen nach Innen („USR0“ bis „USR3“) sind dies Indikatoren für: „Herzschlag “ des Linuxkernels3, Zugriff SD-Karte, Prozessoraktivität, Zugriff eMMC-Speicher. Weiter befindet sich noch ein Power- und einen Reset-Taster auf der Platine.

Im Anhang 12.7 Kapitel findet sich eine detaillierte Übersicht zur BB-Hardware.

3.2 Grove Cape für den BBÄhnlich wie die sogenannten „Shields“ der Arduino-Plattform gibt es für den BeagleBone „Capes“. Die Capes vereinfachen nicht nur das Anschließen der Peripherie sondern schützen auch den BB vor Schäden durch falsches Anschließen. Leider ist der BB gegenüber falsches Anschließen we-sentlich empfindlicher als ein Arduino Uno:

Achtung:Werden an den digitalen Schnittstellen Spannungen größer 3,3 V oder an der Analogschnittstelle größer 1,8 V angelegt, dann führt dies wahrscheinlich zur Zerstörung des BB.

Im SRP wird „Grove Cape“ des Herstellers Seeed [12] verwendet. Zusammen mit den speziell da-für konfektionierten „Grove“-Bauteilen von Seeed ist ein falsches Anschließen nahezu ausge-schlossen.

Auf dem Grove Cape sind die UART-1/2- , I²C-1/2 -Kommunikation sowie für die ADCs AIN 0 bis 4 auf spezielle Stecker herausgeführt. Diese Stecker haben zusätzlich noch einen GND und VCC-Anschluss und sind kompatibel mit der entsprechend vorkonfektionierten Grove-Peripherie. Es können über Adapterkabel aber alle anderen Sensoren mit diesen Schnittstellen angeschlossen werden.

Über den Jumperstecker neben der Ethernetschnittstelle kann (für das gesamte Cape!) die Versor-gungsspannung VCC auf 3,3 V oder 5 V eingestellt werden. Die Beschaltung der o.g. digitalen Schnittstellen und der ADCs ändert sich durch die Stellung der VCC-Jumperstecker jedoch nicht.

Grove-Steckerkontakte jeweils von Oben nach Unten (Beschriftung links und lesbar)

Entsprechende Pins der Buchsenleiste am BB

J1: I2C1 (Cape) P9_17, P9_18, VCC, GND

J5: I2C2/CAN0 (Cape) P9_19, P9_20, VCC, GND

J2: UART1 (Cape) P9_26, P9_24, VCC, GND

J6: UART2 (Cape) P9_22, P9_21, VCC, GND

3 Diese LED blinkt in einem Herzschlagrhythmus, und zeigt damit, dass das Linuxbetriebssystem störungsfrei läuft.


J3: (Cape) P9_39, P9_40, VCC, GND

J7: (Cape) P9_37, P9_38, VCC, GND

Untere Buchse BBG Selbe Belegung wie J5: I2C2/CAN0 (Cape)

Obere Buchse BBG Selbe Belegung wie J6: UART2 (Cape)

Die digitalen Schnittstellen P9_17-22, P9_24 und P9_26 sind durch eine Diodenschaltung auf demGrove Cape gegen Spannungen <0 V und >3,3 V geschützt.

Achtung:Bitte beachten Sie, dass dies ausschließlich nur für diese Pins der Buchsenleisten des BB gilt!

In den analogen Eingängen P9_37-40 (ADCs) ist ein Spannungsteiler integriert, der die Eingangs-spannung von 5 V auf 1,8 V herunter teilt, damit selbst bei einer 5 V Eingangsspannung der ADC nicht zerstört wird.

Egal welche VCC auf dem Cape gewählt ist, sind die oben genannten (physikalischen!) Schnittstel-len des BB vor einer falschen Spannung geschützt. Jedoch ändert sich weder der Pegel der digita-len Ausgänge noch der Fullscale Range des ADCs durch die VCC-Einstellung mittels des Jumper-steckers.

Im Anhang im Abschnitt 12.2 finden sich ein Schaltplan und das Layout des Grove Capes. Beachten Sie bitte, dass der BB viel mehr I/Os als Pins auf dem beiden Buchsenleisten hat.

Daher muss festgelegt werden, welche Funktion auf welchen Pin geführt wird, was man „Pin Mu-xing“ zu Deutsch Pinmultiplexing nennt. Je nach Konfiguration des BB ist diese Zuordnung unter-schiedlich: Ein bestimmter Pin kann z.B. je nach Zuordnung, die man „Device Tree“ (DT) nennt, einmal die Clock des I²C Bus Nr. 1 und einmal GPIO_5 sein.

Es gibt Capes, die über EPROM dem Linuxbetriebssystem ihre Identität mitteilen, woraufhin auto-matisch der passende „Device Tree Overlay“ (DTO) geladen wird. Hierfür sowie für das manuelle Laden wird das Programm „Device Tree Manager“ verwendet.

Näheres hierzu finden Sie im Abschnitt 12.1.

3.3 Programmierung des BeagleBoneDas eingebettete System nennt man im Fachjargon auch „Target“, weil diese Hardware das Ziel des in einer Entwicklungsumgebung (IDE) erstellten Programmcodes ist, wenn man diesen am Ende überträgt.

Auf unterster Ebene gibt zwei verschiedene Arten, wie ein Programm auf dem BB ablaufen kann:

3.3.1 Skriptprogramme:

Es gibt Skriptprogramme wie Python oder JavaScript (beim BB speziell das „BoneScript“), die nichtdirekt auf dem Prozessor sondern auf einer virtuellen Maschine bzw. einem Interpreter ausgeführt werden. Dabei ist die virtuelle Maschine bzw. der Interpreter ein Programm, das direkt auf dem Prozessor läuft. Der Vorteil dieser beiden Skriptprogramme ist deren konsequente Objektorientiert-heit und bei Python die einfache Portierbarkeit auf eine andere Plattform wie z.B. auf einen Raspberry Pi.

BoneScript hat erstens den Vorteil, dass diese Programme direkt über einen Browser ausgeführt werden können, wie in [2] in mehreren Beispielen gezeigt wird. Zweitens ermöglicht diese Skript-sprache einen asynchronen Programmfluss, was im Kontext der Sensoranbindung bedeutet, dass der Programmablauf direkt von einem Sensorsignal beeinflusst werden kann.

Die Skriptsprachen haben aber den Nachteil, dass deren Ausführungsgeschwindigkeit sehr lang-


sam ist. Für ein mechatronisches System wie z.B. die ABS-Regelung beim Auto wären die damit verbundenen Latenzzeiten inakzeptabel.

Im SRP wird Python als Skriptsprache für das Testen der Kommunikation mit der Peripherie ver-wendet. Auch für die Sensorschnittstellen, welche nicht direkt von einem Simulinkblock ausgelesenwerden können, werden die Sensordaten mit Hilfe von Pythonskripten erfasst (siehe Abschnitt10.5).

Eine kurze und gut verständliche Einführung in Python findet sich z.B. in [13].

3.3.2 Kompilierte Programme

Dies Latenzzeiten werden wesentlich kleiner, wenn der Programmcode direkt in der Programmier-sprache C erstellt wird. Dann dabei wird eine speziell für den Prozessor ausführbare sogenannte „native“ Programmdatei „kompiliert“ = erzeugt. Über die C-Programmierung kann auch der PRU di-rekt angesteuert werden, was die Ausführungsgeschwindigkeit nochmals erhöht. Hier sind aber sehr weitgehende Programmierkenntnisse erforderlich.

Einen C-Programmcode kann man textbasiert über eine IDE oder grafikbasiert z.B. mittels Simu-link erstellen. Verwendet man den BB als Target für ein Simulinkmodell, dann wird aus dem Simu-linkmodell ein C-Programmcode erzeugt, dieser auf dem PC für den BB-Prozessor kompiliert und schließlich dort „installiert“ und gestartet.

Das Programmieren via Simulink ist also eine automatische C-Programmcodeerzeugung inkl. IDE, die die zusätzlich nötigen Prozessschritte gleich mit erledigt.

Ganz so „Schwarz-Weiß“ ist die Abgrenzung der Skriptprogramme zu den C-Programmen jedoch nicht: In der Realität werden Skriptprogramme immer mit Bibliotheken kombiniert, die kompilierten Programmcode enthalten. D.h. der Interpreter ruft Unterprogramme auf, die als nativer Code vor-liegen und wahrscheinlich in C programmiert wurden. Außerdem gibt es noch das Konzept der „Just-In-Time“-Kompilierung.

4 Vorbereitung des BeagleBoneNachfolgend wird gezeigt, wie man über das Terminalprogramm Putty, welches auf dem PC läuft eine Verbindung mit dem BB aufbaut. Danach kann man im Putty-Kommandofenster auf dem PCüber Textkommandos in der sogenannten „Kommandozeile4“ (Shell oder Bash genannt) sozusa-gen ferngesteuert auf dem BB arbeiten: Der PC ersetzt hierzu sozusagen die Tastatur und den Bildschirm, der sonst am BB angeschlossen sein müsste.

Darüber hinaus gibt es aber noch zwei andere grundsätzlich verschiedene Fernzugriffsvarianten auf den BB:a) Das Arbeiten über einen Browser auf dem PC, wobei der BB als Webserver fungiert. Hierzu ver-wendet man die Entwicklungsumgebung Cloud9, die auf dem BB schon installiert ist. Näheres siehe Abschnitt 12.5.b) Der BB besitzt eine eigene Benutzeroberfläche. Auf diese kann man auch per Fernzugriff vom PC aus zugreifen. Näheres siehe Abschnitt 12.6.

4 Die Kommandozeile nennt man auch „Shell“. Das Programm auf dem BB, welches die Kommandos verarbeitet wird „Bash“ genannt. Lassen Sie sich nicht irritieren, wenn diese beiden Begriffe oft gleichbedeutend verwendet werden.


4.1 Erste Inbetriebnahme

Grundsätzlich kann der BB über drei verschiedene Schnittstellen mit dem PC verbunden werden:

1. Serielle Schnittstelle (wird im SRP nicht verwendet)

2. USB-Schnittstelle (emuliert eine Ethernetschnittstelle)

3. Ethernetschnittstelle

Die PC-Kommunikation via serieller Schnittstelle wird im SRP nicht verwendet, wohl aber die Kom-munikation von Sensoren bzw. Aktoren über die serielle UART-Schnittstelle.

Bei der ersten Inbetriebnahme verbindet man denBB am besten via USB mit dem PC. Damit ist auch gleichzeitig die Spannungsversorgung ge-währleistet, und man braucht kein separates Netzteil. Bei erstmaligen Anschließen eines BB aneinen PC wird der BB zuerst nur als Massenspei-cher ähnlich einem USB-Stick erkannt.

Die Kommunikation soll später aber nicht über das USB-Protokoll sondern über eine durch die USB-Schnittstelle emulierte Ethernetschnittstelle geschehen. Daher muss noch ein entsprechenderTreiber auf dem PC für diesen „USB-Ethernet-Konverter“ installiert werden:

Auf dem Massenspeicher des BB wird dafür die Datei START.HTML mit dem Browser geöffnet. Auf

dieser Seite befinden sich der je nach PC-Betriebssystem zu installierende Treiber.

Nach der Installation des Treibers befindet sich der BB im Netzwerk des PCs unter der IP-Adresse 192.168.7.2. Diese Adresse muss nun in die Adresszeile des Browsers eingegeben werden, da-mit die beagleboard.org-Seite angezeigt wird. Dabei handelt es sich nicht um eine Seite aus dem Internet, sondern die Seite wird aus lokalen Verzeichnissen des BB aufgerufen.Auf diesen „Internetseiten“ steht alles Weitere, um sich mit dem BB vertraut zu machen, und via BoneScript einzelne Funktionen des BB zu testen.


Abbildung 2: SSH Verbindung mit dem BB für die USB-Schnittstelle mit dem Terminalprogramm Putty.

Abbildung 1: Der BB erscheint nach erstmaligem Anschließen via USB in Windows als Massenspeicher ähnlich einem USB-Stick.

Über die Adresse 192.168.7.2 kann man sich jetzt auch via SSH-Protokoll5 auf dem BB in sein Linux-Betriebssystem einloggen (Benutzername root6, kein Passwort nötig). Dafür verwendet man als Terminalprogramm die Software Putty, welches eine Linuxkonsole öffnet. Einstellungen hierfür siehe Abbildung 2.

Damit man via Putty auf den BB zugrei-fen kann, muss dort ein Dienstprogramm laufen: Ein solches Programm nennt man „Shell“. Im speziellen Fall hier wird die Shell mit dem Namen „Bash“ verwendet. Die nachfolgend dargestellten Linuxbefeh-

le werden in das Kommandofenster von Putty eingegeben.Genauso gut kann man aufeinanderfolgende Befehlszeilen aber auch in einer Textdatei abspei-chern. Dann kann diese Textdatei als Shell- bzw. Bashskript ausgeführt werden: Hier werden die einzelnen Befehle Zeile für Zeile automatisch abgearbeitet.

Achtung:Zum Ausschalten sollte man den BB besser nicht einfach nur von der USB-Schnittstelle (=Span-nungsversorgung) trennen, so wieman es bei einem Arduino Uno macht. Da beim BB ein Betriebs-system mit im Spiel ist, sollte man dieses wie bei einem PC vor dem Trennen herunterfahren. Dies ge-schieht durch kurzes Drücken der „POWER“ Taste am BB (Taster di-rekt neben dem Ethernetan-schluss).

Falls das Ausschalten über die Power-Tastenicht funktioniert, kann man auch im Terminalprogramm den Befehl shutdown -h now verwenden. Durch langes Drücken (>8 s) der POWER-Taste wird der BB „hart“ heruntergefahren.Mit dem Befehl reboot kann der BB neu gestartet werden. Das selbe bewirkt die USER/BOOT-Taste.

Ist der BB „nur“ über USB angeschlossen, dann besitzt er standardmäßig keinen Internetzugang. Dafür kann man ihn z.B. zusätzlich (oder ausschließlich, dann aber mit Netzteil) via Ethernetkabel an einen Switch oder Router anschließen.

5 Das nennt man dann auch „SSH Shell“: Man kommuniziert innerhalb eines PC-Fensters mit dem Linux des BB über Tastaturbefehle.

6 Man kann sich auch als Benutzer debian mit dem Passwort temppwd einloggen. Dann muss man aber bei den meisten nachfolgenden Linuxbefehlen sudo voranstellen, denn der Benutzer debian hat keine Superuser-Rechte wie der Benutzer root. Ist der BB mit dem Internet verbunden, sollte aus Sicherheits-gründen auch für root ein Passwort gesetzt werden.


Abbildung 3: Ermitteln der IP-Adresse des BB über den Befehl ping in der Linuxkonsole.

Abbildung 4: Ermitteln der IP-Adresse des BB über den Be-fehl arp -a in der Linuxkonsole.

Windows-PC BeagleBone

Terminal-programm

„Putty“

Shell„Bash“Textzeichen

Tipp: Die manchmal recht langen Linuxbefehle kann man über Copy & Paste aus einer Internetsei-te oder einer PDF-Datei in die Putty-Linuxkonsole übertragen. Dafür muss man nach dem Kopie-ren in der Putty-Linuxkonsole die rechte Maustaste klicken.

4.2 Anschließen des BeagleBone via EthernetAlternativ (und auch zusätzlich!) zu USB kann der BB auch via Ethernet angeschlossen werden. Dabei handelt es sich dann um eine echte und nicht nur emulierte Ethernetschnittstelle.

Der BB muss zuerst extern mit Spannung versorgt werden, was z.B. über ein USB-Ladegerät inkl. Ladekabel am USB-Anschluss geschehen kann. (Der USB-Anschluss ist in diesem Fall eine reine Stromversorgungsschnittstelle!)

Dann wird der BB mit einem Patchkabel mit einem Switch verbunden, damit sich im selben Netz-werk wie der PC befindet. Wenn nichts anderes am Switch eingestellt ist, erhält der BB von diesemeine freie IP-Adresse zugewiesen (was als „DHCP“ bezeichnet wird).

Der BB kann aber auch die Internetverbindung des PCs mitbenutzen: Dazu ist etwas Konfigurati-onsarbeit nötig, die im Buch von D. Molloy im Kapitel 2 (S. 28) detailliert beschrieben ist [3].

4.2.1 Ermitteln der IP-Adresse des BB

Welche Adresse IP-Adresse der BB erhalten hat, kann man am PC über den Befehl ping beag-lebone erfahren (siehe Abb. 3).Alternativ kann man in der Windows Command Shell (CMD) auch den Befehl arp -a eingeben.

Falls man die MAC-Adresse des BB kennt, kann man dann dessen IP-Adresse ablesen (siehe Abb. 4).Falls keine dieser Methoden funktio-nieren, dann wird der BB sowohl via USB als auch via Ethernet mit dem PC verbunden.

Mit der Software Putty loggt man sich über die USB-emulierte Adresse 192.168.7.2 als root ein und gibt in die Konsole den Befehl ifconfig ein (siehe Abb. 5).

Dann erscheint zusätzlich zur IP-Adresse USB-Ethernetkonverters 192.168.7.2 die vom Switch zu-gewiesene weitere IP-Adresse im Ter-minalfenster.

Statt einer IP-Adresse kann aber bei Putty auch beaglebone eingege-ben werden, wenn sich der BB mit diesem Hostname am Router anmel-det hat.

4.2.2 Anschließen mehrerer BB via Ethernet

Wenn mehrere BB mit dem selben Hostname „beaglebone“ im selben Netz sind, dann muss man seinem eigenem BB aber vorher einen eindeutigen Hostname geben:


Abbildung 5: Ermitteln der IP-Adresse des BB intern vom Linux-Betriebssystem aus über den Befehl ifconfig In der Linuxkonsole.

Dazu loggt man sich als root ein und verwendet den Befehl echo 'xxx' > /etc/hostname mit „xxx“ als neuen Hostname. Danach muss man in der Datei /etc/hosts in der Zeile mit der Hostadresse 127.0.0.1 den nebenstehenden alten Hostname „beaglebone“ noch auf den neuenändern. Dies kann man mit dem Texteditor nano über den Befehl nano /etc/hosts machen.Eine Kurzreferenz, wie der Editor nano zu bedienen ist, findet sich im Anhang dieses Skripts, sie-he Abschnitt 12.9.

Ob der BB Verbindung zum Internet hat, kann über den Linuxbefehl ping www.google.com ge-schehen. Damit überprüft man erstens den DNS-Server und zweitens das Zustandekommen einer Kommunikation mit einer IP-Adresse von Google, von deren ständiger Erreichbarkeit auszugehen ist.

5 Linuxbetriebssystem auf dem BeagleBoneAuf vielen Internetseiten sowie in einigen Fachbüchern ist noch angegeben, dass der BB ab Werk mit einer sogenannten Angström-Linuxdistribution ausgestattet ist. Das stimmt inzwischen nicht mehr, denn aktuell befindet sich auf neuen BBB und BBG eine Debian-Linuxdistribution.

5.1.1 Ermitteln der installierten Linuxdistribution

Welche Distribution sich genau auf dem BB befindet, ermittelt man über den Befehl cat /etc/debian_version oder cat /etc/dogtag oder cat lsb_release -a (siehe Abb. Fehler: Referenz nicht gefunden).

Achtung:Damit später die Codegenerierung über Simulink funktioniert, muss auf dem BB die Debianversion „Wheezy“ (aktuell Debian 7.9) installiert sein. Die andere Debianversion, die mit dem Namen „Jes-sie“ unter [2] zum Download bereit steht, funktioniert nicht unter Simulink!

5.1.2 Installation einer Linuxdistribution auf dem BB

Auf den beagleboard.org Internetseiten befindet sich auch eine detaillierte Anwendung, was zu tun ist, wenn man erst noch die richtige Debianversion installieren muss:Grundsätzlich funktioniert dies über eine sogenannte Image-Datei, die man herunterlädt, entpackt und dann auf eine SD-Karte „aufspielt“. „Aufspielen“ deshalb, da man diese Imagedatei unter Windows nicht einfach auf die SD-Karte

kopieren kann, sondern man muss sie z.B. mit der Software ImageWriter auf die Karte schrei-ben.Beim ersten Booten muss man die USER/BOOT Taste beim Einschalten gedrückt halten, damit der BB von der SD-Karte bootet.Danach muss man auf der SD-Karte über das Terminalprogramm eine Zeile in der Init-Datei /boot/uEnv.txt ändern, damit beim nächsten Einschalten das neue Image auf den eMMC-Speicher übertragen wird, was eine Weile dauert. Details hierzu siehe [2].

5.1.3 Installation von Linuxsoftware auf dem BB

Zu diesem Linuxbetriebssystem wird später Simulink noch ergänzende Pakages installieren, was mehr oder weniger automatisch aus dem Matlab/Simulink-Programm heraus gemacht wird.


Abbildung 6: Ermitteln der auf dem BB installierten Linux-Distribution in der Linuxkonsole.

root@beaglebone:~# cat /etc/dogtagBeagleBoard.org Debian Image 2015-11-12root@beaglebone:~# cat /etc/debian_version7.9root@beaglebone:~# lsb_release -aNo LSB modules are available.Distributor ID: DebianDescription: Debian GNU/Linux 7.9 (wheezy)Release: 7.9Codename: wheezy

Um über Pythonskripte Sensoren und Aktoren testen zu können, müssen ggf. noch Bibliotheken manuell nachinstalliert werden. Dies geschieht über sogenannte Paketinstaller. Dies sind Hilfspro-gramme im Linuxbetriebssystem ähnlich einen Installationsprogramm bei Windows, die bei einer Installation schauen, was schon installiert ist und welche zusätzliche Software noch mit installiert werden muss.Darüber hinaus haben die Paketinstaller aktualisierte Listen, welche Softwarepakete zur Installati-on aus dem Internet verfügbar sind – ähnlich wie „Google Play“ für Android. Nur bei Linux reicht ein Kommandozeilenbefehl für die Installation aus, und es gibt keine Werbung oder sonstigen kommerziellen Interessen, dass ein bestimmtes Programm nun installiert werden sollte ;-)

Mit dem Befehl apt-get update aktualisiert man die Liste der verfügbaren Software, was immervor einer Installation oder einem Upgrade geschehen sollte.Mit dem Befehl apt-get install meinPaket installiert man anschließend die ausgewählte Softwarepaket. Näheres, siehe Abschnitt 12.13.

Achtung: Das Installieren von Software über das Internet funktioniert nur, wenn der BB via Ethernet(egal ob alleine oder zusätzlich zu USB) an einen Switch oder Router angeschlossen ist.Ob eine Verbindung mit dem Internet besteht, testet man z.B. mit dem Linuxbefehl ping www.google.com.

Es ist generell besser, das Linuxbetriebssystem auf der SD-Karte anstatt auf dem eingebauten eMMC-Speicher zu installieren. Denn unglückliche Änderungen an Konfigurationsdateien können dazu führen, dass das Betriebssystem nicht mehr bootet. Im Fall der SD-Karte kann dann der Feh-ler einfach rückgängig gemacht werden, wenn man diese im PC ausliest und bearbeitet. Oder manwechselt sie gegen eine Karte mit neu installiertem Betriebssystem aus und überträgt (vom PC aus) von der alten Karte die persönlichen Daten.

Ob der BB von der SD-Karte oder vom eMMC-Speicher liest/schreibt kann über die USR-LEDs er-kannt werden.

6 Umgang mit LinuxKommt man aus der Welt der Windows/Apple-PCs oder Androidsmartphones, so kann man sich eine Welt ohne grafische Benutzeroberfläche gar nicht mehr vorstellen.

Bei Linux Embedded Systems macht eine solche Benutzeroberfläche jedoch keinen Sinn, da sie nur unnötig Rechenleistung verbraucht, denn sie wird höchstens bei der Parametrierung des ferti-gen Systems gebraucht. Tatsächlich ist der Umgang mit einer sogenannten Konsole, in der man die Befehle in Form von Text statt Mausklicks eingibt, langfristig wesentlich effizienter.

Tipp: Ganz so altmodisch ist der Umgang mit einer Linuxkonsole auch nicht mehr. Eine nützliche Funktion ist das automatische Vervollständigen von Verzeichnis- oder Dateinamen:Bei der Eingabe eines Pfades kann man mit der Tab-Taste die Namen vervollständigen, wenn mandie ersten Buchstaben eingegeben hat.Wie schon erwähnt kann man ein aus einem PDF (wie dieses hier) kopierten Befehl mit einem rechten Mausklick in die Putty-Linuxkonsole einfügen.

Die im Quellenverzeichnis genannten Fachbücher [14], [4] und [5] enthalten jeweils die wichtigen Infos und Befehle zum Thema Linux. In der Praxis sind Cheat Sheets für Linux sehr nützlich, ein Beispiel hierfür finden Sie im Anhang im Abschnitt 12.10.

6.1 Dateimanagement auf dem BB, Übertragen von Dateien zwischen PC und BB

Vom PC aus kommunizieren Sie mittels SSH-Shell über das Programm Putty mit dem Linuxbe-triebssystem auf dem BB. Dies geschieht normalerweise wie oben beschrieben über Tastaturbe-


fehle. Damit können auch z.B. Dateien innerhalb des BBs verschoben werden oder via FTP Datei-en vom BB auf dem PC übertragen werden. Siehe hierfür z.B. Buch von D. Molloy, Kapitel 2, S. 35[3].

Zumindest anfangs ist diese Arbeitsweise für einen Windows-User sehr gewöhnungsbedürftig. Da-her stellt der BB auch alternative Möglichkeiten für den Umgang mit Dateien bereit:

1) Mit dem auf dem BB ausgeführten Dateimanager „Midnight Commander“ können ähnlich wie im Windows Explorer Dateien innerhalb des BBs bearbeitet werden. Details siehe Abschnitt 12.4.

2) Mit der IDE Cloud9, die über den PC-Browser ausgeführt wird, können auch Dateien zwischen PC und BB verschoben werden. Dies ist z.B. sehr nützlich, wenn Sie den Quellcode von Beispiel-programmen aus dem Internet vom PC auf den BB kopieren möchten. Siehe hierzu Abschnitt 12.5.

6.2 Der Bootvorgang

Nach dem Einschalten eines PC führen zuerst dieProzessoren einen Bootvorgang durch, dannstartet das BIOS und in einem letzten Schritt wirddas Betriebssystem gestartet.

Beim BB ist dieser Vorgang ähnlich mehrstufig mitder Ausnahme, dass es kein BIOS gibt, welchesals Schnittstelle zwischen Hardware undBetriebssystem fungiert. Die Information über dieHardwareschnittstellen stecken beim BB zumgrößten Teil im sogenannten Device Tree (DT), derin Abschnitt 7 näher besprochen wird.

Eine grafische Darstellung der ersten drei Stufen


Abbildung 8: Auslesen des Debug UART-Anschlus-ses mit einem FTDI Breakoutboard.

Abbildung 7: Grafische Übersicht des dreistufigen Bootvorgangs beim BB bevor der Kernel (Linuxbetriebssystem) gestartet wird. Quelle: [15].

des BB-Bootvorgangs sind in Abb. 7 dargestellt: Zuerst wird der Code im ROM des ARM-Prozessors ausgeführt, dann wird vorbereitend das nur ca. 400 kByte große „MLO“-Programm ausgeführt und anschließend dann der richtige Bootloader „Das U-Boot“.

Den Löwenanteil der Bootarbeit übernimmt also beim BB der Bootloader „Das U-Boot“. Dessen Bootparameter sind u.a. in der Datei /boot/uEnv.txt zu finden. Näheres siehe Buch von D. Molloy, Seite 60 ff. [3].

Den Bootprozess selbst kann man nur über die serielle Debugschnittstelle, siehe Hinweispunkt Nr. 13 in Abschnitt 12.7 mitschneiden. Dazu verwendet man ein 3,3 V FTDI-Breakout, das man wie in Bild 8 gezeigt direkt aufstecken kann (115200 Baud, Pinreihenfolge Richtung weg vom USB-Anschluss: GND, CTS, VCC, TXD, RXD, DTR. Notwendig ist nur GND, TXD, RXD.).

Achtung:Beim FTDI-Breakout muss unbedingt die Spannung 3,3 V eingestellt sein.

Die Textausgabe der seriellen Debugschnittstelle ist in Abschnitt 12.11 wiedergegeben. Dort sind das Auslesen der Datei uEnv.txt und das Laden des Device Trees hervorgehoben: Es wird also der DT am335x-bonegreen.dtb geladen. Dieser lädt wiederum den DTO BB-BONE-EMMC-2G.

Die Textausgabe endet mit der Information „Starting Kernel ...“. Die nachfolgenden Initialisierungsoperationen werden über den Befehl dmesg | more7 in der Linuxkonsole angezeigt.

Leider ist der tatsächliche Bootvorgang, d.h. welcher Bootparameter aus welcher Datei gelesen wird aufgrund der vielen technischen Änderungen beim BB recht schwer nachvollziehbar. Hinzu kommt, das verschiedene Versionen des BeagleBoards bzw. Genauere Informationen zum Bootvorgang als im Buch von D. Molloy sind in [16] und [17] zu finden.

7 Die Ein- und Ausgänge des BBAchtung:Was das Anschließen von Peripherie wie Sensoren betrifft,ist dieses Kapitel von sehr großer Bedeutung. Denn viele Kompilier- und Laufzeitfehler eines Simulinkmodells beruhen auf Konflikten bei der Pinbelegung.

Grundsätzlich sind auf den bei-den zweireihigen Buchsenleis-ten P9 und P8, den sogenann-ten Cape Expansion Headers“ Versorgungsspannungen (3,3 und 5 V), Masse, Resets, Ana-logeingänge und GPIOs her-ausgeführt.

7 Die Option „more“ ist hier sinnvoll, da es sich um sehr viele Ausgabezeilen handelt. Durch Drücken der Entertaste kann man Zeile für Zeile nacheinander anzeigen lassen. Sonst würden alle Zeilen auf einen Streich in der Linuxkonsole angezeigt. Alternativ kann man auch die Option „less“ verwenden.


Abbildung 9: Beispiel Pinbelegung der beiden Buchsenleisten P8 und P9 bei einem BB ohne geladenem Device Tree Overlay (DTO). Quelle: [18].

Die Abkürzung GPIO bedeutet „General Purpose Input Output“. In der Literatur werden damit aber oft nur die binären I/Os bezeichnet, was streng genommen nicht korrekt ist. Auch in den Abbildungen in Abschnitt 12.1 sind mit „GPIO“ nur diese binären Schnittstellen gemeint.

Die einzelnen Buchsen können über den sogenannten Device Tree (DT) oder Device Tree Overlay(DTO) des BB in gewissen Grenzen entweder als digitale Eingänge, digitale Ausgänge, I²C- Schnittstellen, UART-Schnittstellen, SPI-Schnittstellen oder PWM Ausgänge konfiguriert werden.Dies nennt man „Pin Muxing“, zu Deutsch Anschlussmultiplexing.

Ein BB ohne jegliches DTO besitzt eine Pinbelegung wie in Abb. 9 dargestellt. Der BBB benötigt aber schon einige P8-Pins für die HDMI-Schnittstelle und für die Kommunikation mit dem eMMC-Speicher: Bei ihm werden nach dem Booten zwei entsprechende DTOs geladen, so dass sich an-schließend eine Pinbelegung wie in Abb. 10 dargestellt ergibt. Beim BBG sind die HDMI Pins je-doch frei verfügbar, da auf den HDMI-Anschluss verzichtet wird – hier wird nach dem Booten nur ein DTO geladen.

Mit P9 wird die linke und mit P8 die rechte Steckerleiste bezeichnet, wenn der Ethernetanschluss nach oben zeigt.

In dem Buch von D. Molloy [3] ist dies sehr gut dargestellt. Außerdem findet sich auf seinen Inter-netseiten zu Kapitel 6 des Buchs („Interfacing to BeagleBone Busses“) [19] tabellarische Über-sichten zu den erlaubten und möglichen Pinbelegungen, die auch in Abschnitt 12.8 abgebildet sind.

Im Internet findet sich unter [18] die am besten verständliche Dokumentation zu den Cape Expan-sion Headers. Recht hilfreich sind auch Aufkleber mit den Pinnummern, die man an die beiden Buchsenleisten klebt. Man kann sie als PDF-Datei unter [20] herunterladen.

Achtung:Bestimmte Pins wie z.B. P8_20 bis P8_25, die Schnittstellen zum eMMC (siehe Abb. 10) dürfen nicht umkonfiguriert werden. Nach dem Booten des BB sind normalerweise außer den o.g. systemrelevanten Pins und dem I²C Bus 2 noch keine Pins konfiguriert. Beim Starten eines Pythonskripts oder des Simulinkmodells werden die benötigten Pins automatisch aktiviert.

Startet man ein durch Simulink erstelltes Programm (Dateiendung.erf) manuell über die Linux-Kommandozeile, dann muss vorher die nötige Pinkonfiguration gesetzt werden. Dies kann manuell oder automatisch über den sogenannten „Capemanager“ geschehen.

Normalerweise ist die Pinzuordnung im Betriebssystem =Kernel festgelegt. Aufgrund der vielen verschiedenen ARM-Prozessoren wären folglich viele verschiedene Kernelversionen nötig.Um dies zu umgehen wurde der Device Tree (DT) eingeführt: Hier wird einem einheitlichen Kernel

beim Bootvorgang die gewünschte Pinkonfiguration mitgeteilt.


Abbildung 10: Beispiel Pinbelegung der beiden Buchsenleisten P8 und P9 bei einem BBB. Quelle: [18].

Die Pinzuordnung kann aber auch noch flexibler gestaltet werden: Über das Dienstprogramm Ca-pemanager kann auch nach dem Booten noch die Pinzuordnung geändert werden. Hierfür ver-wendet man Device Tree Overlays (DTO).

7.1 Der Device Tree (DT): Festlegen der Pinzuordnung beim Booten ohne Capemanager

Die Zuordnung der Schnittstellen auf die Pins wird beim BB über den sogenannten Device Tree (DT) organisiert. Normalerweise ist diese Zuordnung fest im Betriebssystem einprogrammiert. Folglich müsste man z.B. für unterschiedliche BB-Capes unterschiedliche Kernels (=Linuxbetriebs-systeme) kompilieren, da die Capes unterschiedliche Pinbelegungen verwenden. Das Selbe würdeauch gelten, wenn man wie in Abschnitt 12.1 dargestellt, auf eine maximale Anzahl bestimmter Schnittstellen zugreifen möchte.

Der DT ist die Lösung dieses Dilemmas:Beim Booten des Kernels wird eine DT-Datei (Endung *dtb, „Device Tree Binary oder Blob“) gela-den, in der die gewünschte Pinkonfiguration angegeben ist. Dadurch stehen diese Schnittstellen anschließend zur Verfügung und können vom Linuxbetriebssystem aus über das SysFS (siehe Ab-schnitt 7.3) ausgelesen und gesteuert werden.

Welche DT-Datei geladen wurde, sieht man in der Textausgabe beim Bootvorgang, siehe Abschnitt6.2.

Beim BBG ist dies standardmäßig die Datei am335x-bonegreen.dtb, was durch den Parameter uname_r im Bootloader u-boot festgelegt ist (siehe \boot\uEnv.txt). Zu dieser Datei gibt es eine lesbare Quelldatei mit dem Namen am335x-bonegreen.dts, welche den Inhalt der beiden Quelldateien am335x-bone-common.dtsi und am33xx.dtsi über eine Include-Anweisung mit einbindet.

Die kompilierten DT-Dateien (Dateiendung *.dtb) finden sich im Verzeichnis /boot/dtbs/3.8.13-bone79.

Die zugehörigen Quellcodedateien (Dateiendung *.dts für „Device Tree Source“) befinden sich meistens nicht auf dem BB. Es gibt jedoch zwei Möglichkeiten, Einsicht in die Quelldateien zu er-halten:

Möglichkeit 1:

Mit dem „Device Tree Compiler“ kann man aus einer .dtb-Datei wieder eine .dts-Datei er-zeugen:

dtc -O dts -o ~/am335x-bonegreen.dts -I dtb /boot/dtbs/3.8.13-bone79/am335x-bone-green.dtb

Mit diesem Befehl zeigt man den DT Quellcode an:

cat am335x-bonegreen.dts | less8

Möglichkeit 2:

Die Quelldateien finden sich im Internet z.B. unter github.com/beagleboard/linux/tree/3.8/arch/arm/boot/dts9.Dort kann man die Dateien im Browser ansehen und herunterladen.

8 Die Option „less“ bewirkt, dass die Ausgabe in der Linuxkonsole nicht auf einen Streich geschieht: Man kann hierbei mit den Cursor- oder Bildtasten die Textausgabe portionieren. Mit der Taste „q“ beendet man übrigens die Ansicht mittels „| less“.

9 Es gibt auch entsprechende Verzeichnisse für andere Linuxkernel wie 4.1, sowie ein spezielles Verzeich-nis für den BBBG. Siehe Auswahl „Branch“ auf dieser Internetseite.


Der aktuell geladene DT wird mit folgendem Linuxbefehl ausgegeben:

dtc -f -I fs /proc/device-tree | less

Dort erscheinen auch die Schnittstellen, die nach dem Booten zusätzlich durch den Capemanager über einen Device Tree Overlay (DTO) geladen wurden.

Welche Pins aufgrund des DT und DTO welche Funktion haben, erfährt man mit einem dieser Be-fehle:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins | less

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

Wenn man für jeden Pin ganz genau wissen will, wie er konfiguriert ist, dann verwendet man:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | less

Bei beiden Ausgaben erscheint nicht die Hardware-Pinnummer P8_n bzw. P9_n, sondern eine fort-laufende Pinnummer. Diese kann über die beiden Tabellen in Abschnitt 12.8 in die entsprechende Hardware-Pinnummer umgewandelt werden.Die Ausgabe des letzteren Befehls gibt für jeden vorhandenen Pin die Konfiguration als Hexadezi-malzahl aus. Auch hier muss man in den beiden Tabellen im Abschnitt 12.8 nachschauen, um die-se Zahlen zu interpretieren.

Nähere Informationen zum DT und DTO finden sich auch in [21].

7.2 Das Device Tree Overlay (DTO): Festlegen der Pinzuordnung nach dem Booten über dem Capemanager

Das Device Tree Overlays (DTO)-Konzept überwindet die Inflexibilität, dass beim Booten schon diePinbelegung über den DT festgelegt sein muss.Der Hintergrund hierzu sind die sogenannten Capes, die man auf den BB aufsteckt. Je nach Funk-tion des Capes müssen die Pins entsprechend konfiguriert werden. Bei einem Cape mit LCD-Dis-play müssen z.B. Pins für die Grafikdaten gesetzt werden.

Die Capes enthalten ein EEPROM, das dem Betriebssystem mitteilt, welcher Capetyp sich auf dem BB befindet. Über dessen „Board Name“ lädt das Hilfsprogramm „Capemanager“ das richtige DTO (Dateiendung .dtbo), welches sich Verzeichnis /lib/firmware befinden muss. Details


[ 0.561233] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,\x1a,BBG115070250'[ 0.561289] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-green[ 0.592516] bone-capemgr bone_capemgr.9: slot #0: No cape found[ 0.629624] bone-capemgr bone_capemgr.9: slot #1: No cape found[ 0.666732] bone-capemgr bone_capemgr.9: slot #2: No cape found[ 0.703841] bone-capemgr bone_capemgr.9: slot #3: No cape found[ 0.710059] bone-capemgr bone_capemgr.9: slot #4: specific override[ 0.710082] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4[ 0.710098] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'[ 0.710401] bone-capemgr bone_capemgr.9: initialized OK.[ 0.713204] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)[ 0.713219] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)[ 0.713234] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)[ 0.713254] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'[ 0.713272] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree[ 0.713466] bone-capemgr bone_capemgr.9: slot #4: #2 overlays[ 0.714101] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.[ 0.714119] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)

hierzu siehe [22].

Nach dem Starten des Kernels wird automatisch der Capemanager gestartet. Er hat die Aufgabe, aufgesteckte Capes anhand deren EEPROMs zu erkennen und das passende DTO autonom nachzuladen. Diese Aktionen erscheinen dann auch innerhalb der Ausgabe des Befehls dmesg, siehe Textfenster oben.

Ein DTO ist also das gleiche wie ein DT, nur dass man hiermit die Pinkonfiguration auch nach dem Booten des Kernels noch parametrieren kann. Diese Aufgabe übernimmt ein Programm mit dem Namen „Capemanager“.Auch ohne ein konkretes Cape kann man ein DTO für eine bestimmte Pinkonfiguration erstellen. Dann spricht man von „virtuellen Capes“.

Soll z.B. der Pin P9_21 als PWM-Ausgang konfiguriert werden, dann wird hierfür ein eigenes DTO erstellt und über den Cape Manager geladen. Beim Starten des Simulinkmodells oder eines Py-thonskripts geschieht dies automatisch, d.h. die nötigen DTOs befinden sich schon auf dem BB. Näheres hierzu siehe [23] und [24].

Wenn man ein ausführbares Programm (das man vorher unter Simulink kompiliert hat) manuell von der Linuxkonsole aus starten möchte, dann muss vorher das DTO für die genutzten Pins ebenfalls manuell mit dem Capemanager geladen werden.

Folgende Dateitypen gibt es im Zusammenhang mit dem DT und DTO:

Dateityp Bedeutung

.dts Quellcodedatei des DT. Wird mit dem Device Tree Compiler in .dtb oder .dtbo Datei kompi-liert. „Device Tree Source“.

.dtsi DT Quellcodedateien ähnlich Include-Dateien, die in eine .dts Datei eingebunden werden.

.dtb Kompilierter DT, der dem Kernel beim Booten mitgegeben wird. Aus ihm kann man mit dem Device Tree Compiler den DT Quellcode wiederherstellen. „Device Tree Binary“.

.dtbo Kompilierter DT, der vom Capemanager als DTO geladen wird.

Nähers siehe auch [25] oder [26]. In [27] ist ein Device Tree Generator für den BB zu finden, ob dieser fehlerfrei funktioniert bleibt aber noch zu testen.

7.2.1 Anzeigen des aktuell geladenen DTOs

Mit folgendem Befehl zeigt der Capemanager die aktuell geladenen DTOs an.

cat /sys/devices/bone_capemgr.*/slots

Die Antwort darauf sieht z.B. so aus:

0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

In diesem Fall befindet sich kein physikalisches Cape auf dem BB. Denn deren DTOs würden an den Stellen („Slots“) 0 bis 3 erscheinen.

Hier wurde lediglich das DTO eines virtuellen Capes für den eMMC geladen.

7.2.2 Manuelles Laden und Entladen eines DTO aus der Linuxkommandozeile mit Hilfe des Capemanagers

Beispielsweise zum Aktivieren des zweiten I²C-Busses muss man das DTO „BB-I2C1“ mit folgen-


den Befehlen laden:

echo BB-I2C1 > /sys/devices/bone_capemgr.*/slots

Die zugehörigen .dtbo Dateien finden sich entweder im Verzeichnis /lib/firmware oder /boot/dtbs/3.8.13-bone79, oder sie sind in anderen .dtbo Dateien enthalten.

Zur Kontrolle kann man sich die geladenen DTOs mit folgendem Befehl anzeigen lassen:

cat /sys/devices/bone_capemgr.*/slots

Möchte man dieses DTO wieder entfernen, so muss man den entsprechenden Slot mit folgendem Befehl leeren (hier am Beispiel von Slot Nr. 5, siehe Ausgabe des Befehls oben):

echo -5 > /sys/devices/bone_capemgr.*/slots

Man kann mehrere DTO nacheinander laden. Sie erscheinen dann unter aufeinander folgenden Slots.Welche kompilierten DTOs als eigenständige .dtbo Dateien auf dem BB verfügbar sind erhält man über folgenden Befehl aus dem /-Verzeichnis:

find -iname "*dtb*"

Darüber hinaus verstecken sich noch weit mehr kompilierte DTO, die geladen werden können.

Pinfunktionalität DTO-Name

I²C-Bus 2, zusätzlicher IC-Bus BB-I2C1

Analoger Eingang BB-ADC

PWM Ausgang (Buchsenleiste x, Pin yz) bone_pwm_Px_yz und am33xx_pwm

UART Schnittstelle (Nr. n=1,2,3,4,5) BB-UARTn

SPI-Schnittstelle (Nr. n=0,1) BB-SPIEEVn ??

Binärer Ein-/Ausgang Wird über SysFS mit „export“ gesetzt

7.2.3 Automatisches Laden eines oder mehrerer DTOs beim Bootvorgang

Es gibt mehrere Möglichkeiten, beim Bootvorgang DTO automatisch zu laden bzw. bestimmte DTs aus am335x-bonegreen.dtb explizit nicht zu laden.Leider gibt es hier bei verschiedenen Linuxversionen immer wieder Unstimmigkeiten in der Doku-mentation, welcher Befehl in welcher Datei dafür nötig ist.

a) Bestimmtes DTO nicht laden:

In der Datei \boot\uEnv.txt) werden die entsprechenden (virtuellen) Capenamen xxx wie folgt angegeben:

cape_disable = capemgr.disable_partno = xxx

b) Bestimmte zusätzliche DTOs laden:

In der Datei \boot\uEnv.txt) werden die entsprechenden (virtuellen) Capnamen xxx wiefolgt angegeben. Die dtbo-Dateien müssen sich dabei unter /lib/firmware/ befinden.

cape_enable = capemgr.enable_partno = xxx

Falls diese Methode nicht funktioniert, dann kann der Campename auch in der Datei /etc/dfault/capemgr eingetragen werden. Dann lädt der Capemanager bei dessen Start dieses DTO automatisch.


7.2.4 Erstellen eines DTO

Hierfür editiert man eine Quelldatei mit der Endung .dts. Aus diesem DTO-Quellcode wird mit dem „Device Tree Compiler“ eine gleichnamige Datei mit der Endung .dtbo erzeugt. Diese muss im Ordner /lib/firmware kopiert werden, damit der Capemanager sie findet.

Das Erstellen solcher DTO Dateien ist sehr schwierig. Es ist einfacher, mehrere vorhandene DTOsfür jedes Pin einzeln nacheinander zu laden.

Will man trotzdem ein gemeinsames DTO für eine Pinkonfiguration erstellen, dann finden sich in[3] , [28] und [19] gute Anleitungen dazu. In Internet finden sich auch DT-Generatoren, die die nöti-gen dts-Dateien fast automatisch erstellen.

Achtung: Bei der Laufzeit des Programms entstehen oft Probleme, weil die Pinkonfigurationen widersprüch-lich sind. Z.B. greifen zwei unterschiedliche DTOs auf den selben Pin zu.

Tipp: Zur Kontrolle, welche Fehlermeldungen hierbei schon beim Bootvorgang auftreten, kann mansich über den Befehl dmesg | tail die möglichen Fehlermeldungen anschauen.

7.3 Das SysFSSind die benötigten I/Os über den DT bzw. DTOs gesetzt, dann kann Linux recht einfach auf diese zugreifen:Jeder Schnittstelle ist ein Verzeichnis in /sys/class/ ein entsprechender Ordner zugeordnet. Indessen Dateien kann man Werte hineinschreiben um z.B. einen binären Ausgang auf High zu set-zen. Genauso kann man eine Datei auslesen, um den Wert des ADCs auszulesen. Das Datei Sys-tem nennt man „SysFS“, es ist eine Besonderheit des Linuxbetriebssytems und ist grundsätzlich unabhängig vom DT-Konzept oder dem Capemanager-Konzept.

Das SysFS ist also ein virtuelles Dateisystem, ober das man als User direkt auf Betriebssystem-funktionen zugreift, um die I/Os zu steuern.

Dieser Umgang mit den I/Os durch das Betriebssystem ist also grundsätzlich bei allen LES gleich. Schreibt man ein C-Programm, dass in dieser Weise die Schnittstellen anspricht, so ist es einfach auf ein anderes LES portierbar.

In den S-Functions von Simulink sprechen die eingebetteten C-Programme die Schnittstellen ebenfalls über dieses SysFS an.

Beispiel 1:

Binärer Eingang P8_11 (GPIO 45, PIN 13, siehe Abschnitt 12.8):

/sys/class/gpio echo 45 > exportecho in > directioncat value

Bemerkung: PIN 13 ist genau genommen GPIO1_13, also Pin 13 des ersten GPIO-Control-lers. Die GPIO 45 ergeben sich aus dem Offset von 32 (jeder Controller hat 32 Pins) plus 13. Die binären I/Os müssen nicht explizit über ein DTO aktiviert werden, wenn sie nicht durch das DTO einer anderen Schnittstelle schon belegt sind. Die Aktivierung und Parametrierungkann wie oben gezeigt auch über das SysFS geschehen.Bestimmte Parameter wie Pull-Ups können jedoch nur über ein DTO eingestellt werden.


Achtung: Bestimmte binäre I/Os können grundsätzlich nicht ohne Weiteres verwendet werden. Diesesind in den Tabellen in Abschnitt 12.8 rot unterlegt.

Beispiel 2: Analoger Eingang AIN0 an P9_39

cat /sys/devices/ocp.*/helper.*/AIN0

Die Ausgabe dieses Befehls ist die Eingangsspannung in mV.

7.4 Die I²C-BusseIn der Linuxdistribution Debian (Wheezy) ist die Software i2c-tool mit enthalten. Mit diesem Toolkann die I²C Kommunikation zu als (Slave angeschlossenen) Peripheriegeräten wie Sensoren überprüft werden.

Mit dem Befehl i2cdetect -y -r 1 wird der I²C-Bus 1 nach angeschlossenen Geräten durch-sucht.

In Abb. 11 Ist die Ausgabe dieses Befehls in der Li-nuxkonsole dargestellt: Es wurde an der Adresse 0x77 ein Gerät gefunden – in diesem Fall ein BMP180 Sensor.

Die Zeichen „UU“ in der Tabelle bedeuten, dass diese Adressen schon im Zugriff eines Treibers

sind und daher nicht ausgelesen werden.

Mit dem Befehl i2cdetect -l (Achtung nicht „-1“ sondern „-l“) werden die verfügbaren Busse aufgelistet. Beim BB sind dies nach dem Booten i2c0 und i2c210.

Achtung: Auf den ebenfalls angezeigten Bus i2c-0 kann der BB nur intern zugreifen. Um eine wei-tere I²C-Busschnittstelle zu erzeugen, muss man den DTO „BB-I2C1“ aktivieren. Dieser erzeugt den Bus i2c-2.

Offensichtlich ist die Nummerierung der I²C-Busse beim BB absolut inkonsistent! Die folgende Ta-belle gibt die verschiedenen Bezeichnungen je nach Kontext an:

Grove Cape SysFS SDA/SCL Pin DT Matlab Simulink Bemerkung

I2C1 i2c-2 P9_20/_19 I2C1 I2C1 2 Muss über DTO aktiviert werden.

I2C2 I2c-1 P9_18/_17 I2C2 I2C2 1 Standardmäßig aktiviert. Hier befinden sich die Adressen der Cape EEPROMs.

Weiter kann man mit diesem Tool alle Register eines angeschlossenen Slaves mit i2cdump -y 1 0x70 z.B. für den BMP180-Sensor ausgelesen werden, um z.B. die Parametrie-rung eines Sensors zu kontrollieren.

Auch kann man direkt per Kommandozeile mit dem Slave kommunizieren.

7.5 HardwarespezifischesDie Analogeingänge haben unter den GPIOs eine Sonderstellung: Sie befinden sich immer an den selben Anschlussbuchsen, die auch nicht durch andere Schnittstellen belegt werden können. Der

10 Achtung: Im Device Tree sind gegenüber dem SysFS die Busse 1 und 2 vertauscht!


Abbildung 11: Verwendung des Tools i2c-tools zum Testen der I²C- Kommunikation.

Grund hierfür ist die nötige Analogelektronik, die nicht einfach über einen Multiplexer weitergeleitet werden kann.Trotzdem müssen die analogen Eingänge aber auch zuerst über einen DTO bzw. DT aktiviert wer-den.

7.6 Bei Matlab/Simulink zu beachtenIm Matlab Befehlsfenster kann die aktuelle Pinbelegung grafisch angezeigt werden:

Zuerst erzeugt man in der Matlab Kommandozeile ein beaglebone_black-Objekt: bbone = beaglebone_black und lässt dann mit dem Befehl showPinMux(bbone, 'P9')das „Pin Muxing“ z.B. der linken Steckerleiste P9 anzeigen.

In Abb. 12 ist ein Beispiel hierfür gezeigt. Intern liest Matlab höchstwahrscheinlich genau so wie in Abschnitt beschrieben über das Linuxbetriebssystem die Datei pingroups aus.

In [24] ist eingehend erklärt, wie man aus der Matlab Kommando-zeile heraus den Device Tree kontrollieren und ändern kann. Anders als bei Simulink muss man dies vor dem Starten des Matlabskripts manuell durchfüh-ren.

Bis auf die hier gezeigte grafi-sche Aufbereitung sind dies aber genau die gleichen Befehle, die man auch direkt in einer Linux-konsole eingibt.

Startet man ein Modell aus Simu-link heraus, dann werden die nö-tigen DTOs automatisch von Si-

mulink über den Capemanager geladen.Welche das sind, kann man in der Linuxkonsole nach dem Start des Modells mit folgendem Befehl nachschauen:

dmesg | tail

Will man das ausführbare Programm des Simulinkmodells manuell aus der Linuxkonsole heraus starten, dann muss man vorher auch die nötigen DTOs manuell laden.

8 Einbinden von Sensoren und Aktoren über PythonskripteFür das Einbinden von Sensoren und Aktoren (Peripherie) ist die Programmiersprache Python grundsätzlich schlecht geeignet, da sie eine Skriptsprache ist und daher eine vergleichbar geringe Ausführungsgeschwindigkeit aufweist, bei der man nur bedingt von Echtzeitfähigkeit sprechen kann.

Ideal würde man C-Programme hierfür verwenden, zumal damit auch die PRU des BB mit einge-bunden werden kann. Siehe hierzu Kapitel 8 in [4].

In [3] (S. 151) wurde für den selben Algorithmus die Programmlaufzeit auf dem BB für verschiede-ne Programmiersprachen verglichen. Wie in der nachfolgenden Tabelle zu sehen ist, liegt Python hierbei weit abgeschlagen.


Abbildung 12: Ergebnis der Abfrage des aktuellen DT über die Matlab-Kom-mandozeile.

Programmiersprache C++ Java Python

Programmlaufzeit (s) 33 39 1063

Python wird mit dem Fokus auf die einfache Erlernbarkeit und einfache/klare Syntax von einer ge-meinnützigen Organisation entwickelt11. Python ist somit sehr viel einfacher als C. Zudem existie-ren sehr viele Bibliotheken und Beispielprogramme für das Einbinden der Peripherie am BB [6]. Bei fast allen LES wird für das Rapid Prototyping daher oft Python eingesetzt. Ein gutes Lehrbuch zu Python ist z.B. [29].

Achtung:Der wohl auffallendste Unterschied zwischen Python und etablierten Programmiersprachen wie Java oder C ist die Tatsache, dass zusammenhängende Codeblöcke nicht über Klammern sondernüber Einrückungen definiert werden. Die Formatierung des Quellcodes bestimmt also dessen In-halt mit. Dabei ist es wichtig, bei den Einrückungen nicht Tabs und Leerzeichen zu mischen!

Python spielt auch beim Raspberry Pi eine wichtige Rolle. Da dessen Hardware I/Os bis auf die fehlenden ADCs recht ähnlich zu denen des BB sind, können Raspberry Pi Pythonskripte einfach auf dem BB portiert werden. Dies betrifft z.B. Beispielprogramme für das Einbinden konkreter Sen-soren, siehe [30].

Im SRP wird Python hauptsächlich verwendet, um die Peripherie vor dem Einsatz von Simulink zu testen. Hierbei überwiegt der Vorteil des einfachen Umgangs.Da die Rechenleistung des BB sehr groß ist, können für das SRP aber auch später in der Applikati-on Pythonskripte verwendet werden, da deren Reaktionszeiten immer noch im Bereich von Millise-kunden liegen. Dies wird z.T. auch gemacht, um einem Simulinkmodell die aktuellen Sensordaten asynchron zuzuführen (siehe Abschnitt 10.5).

8.1 Installation notwendiger PhytonbibliothekenPython ist standardmäßig auf dem BB mit der Linuxdistribution „Wheezy“ installiert.

Die Fa. Adafruit stellt für die Kommunikation über die GPIO-Schnittstellen ADC, PWM, I²C, SPI undUART die fertige Bibliothek Adafruit_BBIO für den BB bereit [6]. Ob diese auch schon mit instal-liert sind, kann man durch folgenden Linuxbefehl abfragen:

python -c "import Adafruit_BBIO.GPIO as GPIO; print GPIO"

Falls die Bibliothek schon installiert ist, dann erscheint eine Rückmeldung wie in Abb. 13.

Falls dies nicht der Fall ist, findet man in [6] eine Anleitung zur Installation der Bibliothek inkl. Bei-spielprogramme.

Achtung:Zum Anschließen der Peripherie muss unbedingt das Grove Cape aufgesteckt werden, da sonst bei falschem Anschließen der BB zerstört wird. Es sind jedoch auch dann nur die vierpoligen Grove-Stecker geschützt! Die beiden Buchsenleistenwerden vom Grove Cape nur durchkontaktiert.

11 Der Name „Python“ wurde der Komikergruppe „Monty Python“ entlehnt – im Sinne der fehlenden Ehrfurcht gegenüber der Programmiersprache C.


Abbildung 13: Rückmeldung des Linuxbetriebssystems in der Linuxkonsole, falls Adafruit BB Python Library schon instal-liert ist.

Der BB muss immer ausgeschaltet sein (nicht ausstecken, sondern über POWER-Taste herunter-fahren!) bevor neue Peripherie angeschlossen wird. Den BB erst dann wieder einschalten, wenn Sie die Verdrahtung überprüft wurde.Außerdem darf an den Anschlüssen des BB keine Spannung anliegen, wenn dieser ausgeschaltet ist.

Zum Öffnen der Beispielprogramme bzw. zum Schreiben eigener Pythonprogramme kann im Putty-Fenster der Linuxeditor Nano verwenden. Da dieser Editor keine grafische Benutzerober-fläche hat, ist ein entsprechendes Cheat Sheet hierfür sehr nützlich (siehe Anhang 12.9).Über eine Browserverbindung zum BB kann auch die auf dem BB vorinstallierte grafikbasierte IDE Cloud9 genutzt werden. Dies funktioniert für Python genau so wie für BoneScript, siehe z.B. [5] oder [2].

8.2 Beispielprogramm: LED blinken lassen.Wie auch bei der Arduinoprgrammierung fängt man beim Physical Computing erst einmal ganz klein an: Man lässt eine LED blinken – d.h. ein GPIO wird ein- und ausgeschaltet.

Das in Abb. 8 Dargestellte Pythonprogramm myBlink.py macht genau das:Der Ausgang P9_14 (linke Steckerleiste wenn Ethernetanschluss oben, 2. Spalte, 7. Zeile) wird miteiner Frequenz von 1 Hz ein- und ausgeschaltet.

Um die Datei myBlink.py zu erstellen, wird in der Linuxkonsole der Befehl nano myBlink.py eingegeben, der den Texteditor Nano öffnet. Darin gibt man den Quellcode ein, siehe Abb. 8.

Anschließend wird die fertige Skriptdatei mit dem Befehl python myBlink.py im Interpreter aus-geführt. Da sich in dem Skript eine Endlos-Whileschleife befindet, muss der Interpreter mit ^C (Strg + C) beendet werden. In der Konsole sieht das Ganze dann so aus wie in Abb. 15.

Die erste Zeile im Python-Quellcode gibt das Verzeichnis des Interpreters an. Wenn man vorher


Abbildung 15: Erstellen und Ausführen des Pro-gramms myBlink.py in der Linuxkonsole.

Abbildung 14: Quellcode des Programms myBlink.py im Editor Nano in der Linuxkonsole.

mit dem Befehl chmod +x myBlink.py der Quelldatei Ausführungsrechte gegeben hat, dann kann man auch nur mit dem Befehl ./myBlink.py das Programm starten.

8.3 Analogspannung auslesen (ADC)An dem Steckplatz J3 des Grove Capes wird ein Potentiometer angeschlossen. Dieses wird mit VCC und GND spannungsversorgt. Sein Ausgang liegt auf Eingang AIN0 (P9_39).

Es wird wieder die Bibliothek Adafruit_BBIO verwendet. Das Skript myADC.py liest die Span-nung am BB Pin P9_39 jede Sekunde aus, bis das Programm mit ^C aus der Linuxkonsole heraus beendet wird.

Der vom AD-Wandler gemessene Wert wird in mV (nicht LSB!) ausgegeben. Bei Ausführen dieses Programms ergeben sich je nach Stellung des Potentiometers Rohwerte zwischen 0 und ca. 1214 mV. Ändert man die Versorgungsspannung VCC des Grove Capes auf 5 V, so wird komplette der Full Scale Range des 12 bit ADCs von 0...1800 mV genutzt.Der reduzierte Aussteuerbereich bei 3,3 V Versorgungsspannung hat seine Ursache in dem festen Spannungsteiler des Capes, der die Eingangsspannung unabhängig von der Jumperschalterpositi-on um 1,8/5 reduziert.

8.4 Beispielprogramm: Analogen Ultraschallsensor HC-SR04 auslesen.Der Ultraschallsensor HC-SR04 benötigt 5 V Versorgungsspannung und gibt die intern gemesseneEcholaufzeit über ein Pulsweitensignal an seinem Echopin aus. Gestartet wird die Ultraschallab-standsmessung über ein Rechtecksignal (mindestens 10 µs GND) am Triggerpin des Sensors.Der Ultraschallsensor kann daher direkt über über einen Steckplatz das Grove Cape (Jumperstellung VCC = 5 V) angeschlossen werden12. In diesem Beispielprogramm myHCSR04.py wird der UART_2 Steckplatz verwendet, wobei der Triggerpin auf den Anschluss TX (P9_21) und der Echo-pin auf den Anschluss RX (P9_22) gelegt werden.

Dieses Programm misst die am Echoausgang als Pulsweite ausgegebene Echolaufzeit, rechnet sie in einen Abstand in Millimeter um und gibt diesen aus. Die Zeitmessung erfolgt über die While-schleife, indem während der Echolaufzeit die Variable stop immer wieder mit der aktuellen Zeit überschrieben wird, bis der Puls am Sensorausgang zu Ende ist.

Beim BB hängt die Verweilzeit in dieser Whileschleife jedoch nicht nur vom Signal am Echopin desSensors ab. Je nach Auslastung des Linuxsystems werden diese Schleife und der vorangehende sleep-Befehl mal langsamer oder schneller ausgeführt. Aus diesem Grund schwanken die Mess-werte recht stark. Außerdem ist die minimal noch messbare Reichweite (= Pulsbreite) von der Pro-zessorlast des BB abhängig.

Bei einem µC wie den ATmega8 (Arduino Uno) wäre dies nicht der Fall: Hier würde man mit einem

12 Man kann aber auch nur die 5 V Versorgungsspannung vom Pin P9_7 des BB abgreifen und die restli-chen Pins des Sensors mit einem Steckplatz des Grove Capes (Jumperstellung VCC = 3,3 V) verbinden.


Quellcode myADC.py für Eingang AIN0 (P9_39):import Adafruit_BBIO.ADC as ADCimport timeADC.setup()

while True:# normierte Werte lesen 0...1.0valueNorm = ADC.read("P9_39")

# Rohwerte lesen 0...2047valueRaw = ADC.read_raw("P9_39")

time.sleep(1)print "Normierter Wert: " + str(valueNorm)print "Rohwert: " + str(valueRaw)

Interrupt die Pulsbreite mit der Genauigkeit der Zählerperiode ausmessen. Denn bei einem µC wird das Programm deterministisch („in Echtzeit“) ausgeführt. Dies ist ein gutes Beispiel dafür, dass für eine Sensoranbindung ein µC oft besser geeignet ist als ein LES wie der BB. Der Königsweg beim BB ist die Zuhilfenahme der PRUs, die quasi als vorgeschaltete µC fungie-ren. Dies ist aber nur mit einem komplexerem C-Programm möglich.

Alternativ kann man natürlich auch einen digitalen Ultraschallsensor wie den SFR02 mit I²C-Schnittstelle einsetzen. Hierzu siehe Abschnitt 11.2.6.

8.5 Beispielprogramm: Sensordaten via I²C von einem MPU6050 IMU-Sensor „zu Fuß“ auslesen.

Dieses Skript myMPU6050.py verwendet für die I²C Kommunikation die Bibliothek Adafruit_BBIO. Eine für den Sensor spezifische Bibliothek wird nicht verwendet. Auf welche Re-gister man hier zugreifen muss, ist dem Datenblatt des MPU6050 zu entnehmen.

Da das Breakoutboard des MPU6050 einen Spannungsregler besitzt, kann es auch bei 5 V Versor-gungsspannung betrieben werden.

Der Sensor wird je nach aktiven Device Tree Overlay (DTO) (sieh Abschnitt 12.1) auf dem Grove Cape an den mit I2C1 oder den mit I2C bezeichneten Stecker angeschlossen.


Quellcode myHCSR04.py (Anschluss UART_2, Trigger auf TX, Echo auf RX):import timeimport Adafruit_BBIO.GPIO as GPIOGPIO_TRIGGER = "P9_21" #UART2_TXD auf dem Grove CapeGPIO_ECHO = "P9_22" #UART2_RXD auf dem Grove Cape

cSound = 340000pauseTime = 0.05delayEchoEdge = 0.0005time.sleep(2)GPIO.setup(GPIO_TRIGGER, GPIO.OUT)GPIO.setup(GPIO_ECHO, GPIO.IN)GPIO.output(GPIO_TRIGGER, False)time.sleep(0.01)

try: #Damit bei Abbruch durch ^C die GPIOs wieder zurueckgesetzt werden while True: GPIO.output(GPIO_TRIGGER, True) time.sleep(0.00001) GPIO.output(GPIO_TRIGGER, False) start = time.time() stop = time.time() time.sleep(delayEchoEdge) while GPIO.input(GPIO_ECHO)==1:

time.sleep(0.00001) stop = time.time() elapsed = stop - start - delayEchoEdge if elapsed<0: distance = 0 else: distance = (elapsed * cSound)/2 print "%d mm" % distance time.sleep(pauseTime) except KeyboardInterrupt: GPIO.cleanup(GPIO_ECHO, GPIO_TRIGGER)

Achtung: Die Nummerierung der I²C-Schnittstellen ist leider inkonsistent, siehe Abschnitt 7.4. Mit dem Tool i2c-tool wird überprüft, ob und unter welcher Adresse der Sensor über den I²C Bus erreichbar ist.Oben ist der Quellcode des Beispielprogramms dargestellt, siehe [31].

8.6 Beispielprogramm: Sensordaten via I²C von einem BMP180 Druck-sensor mit „Black Box“ Bibliothek auslesen.

Das in Abb. 16 dargestellte Programm simpletest_BMP180.py verwendet anders als myM-PU6050.py die Bibliothek ADAFRUIT_PYTHON_BMP, aus deren Beispielverzeichnis es auch

stammt.

Dies ist eine spezifische Bibliothek nur für diesen Sensor, in der die Registeradressen für den BMP180 hinterlegt sind. Für die I²C-Kommunikation sind Teile der Bibliothek ADAFRUIT_PYTHON_GPIO nötig, die automatisch mit installiert wird. Das Installieren dieser Biblio-thek ist in [30] dargestellt.


Abbildung 16: Code des Testprogramms simpletest_BMP180 aus der Adafuit_BMP Bibliothek. Hier wurde die IDE Cloud9 verwendet.

Quellcode myMPU6050.py:from Adafruit_I2C import Adafruit_I2C # i2c Kommunikation auf Adresse 0c68 initialisiereni2c = Adafruit_I2C(0x68)

# Register beschreiben, um Sleepmodus zu beendeni2c.write8(0x6B, 0)

print("Messwert Beschleunigung x-Achse (g): ") # Messwert wird in 2 Bytes ausgegeben# MSB Register 0x3b, LSB Register 0x3c# Register auslesenb = i2c.readS8(0x3b)s = i2c.readU8(0x3c)# Konvertierung der 2 Byte in eine 16 Bit Ganzzahlraw = b * 256 + s# Normierung auf 1 gg = raw / 16384.print (str(g))

Der Sensor wird je nach aktiven Device Tree Overlay (DTO) (sieh Abschnitt 12.1) auf dem Grove Cape an den mit I2C1 oder den mit I2C2 bezeichneten Stecker angeschlossen. Achtung: Die Num-merierung der I²C-Schnittstellen ist leider inkonsistent, siehe Abschnitt 7.4.

Der BMP180 verwendet basiert auf 3,3 V Spannung/Logikpegel. Je nach Typ des Breakoutboards sind nur die Spannungsversorgung oder zusätzlich auch die I/Os jedoch 5V-tolerant. Dies erkennt man über die Anzahl der bestückten Spannungsregler. Beim Anschluss über den Grove-Stecker können beide Typen bei 5 V Einstellung des Capes ver-wendet werden.

In Abb. 16 wurde statt des Texteditors Nano die IDE Cloud9 verwendet, innerhalb der auch das Programm ausgeführt werden kann. Näheres zu dieser IDE finden Sie im Abschnitt 12.5.Das Programm kann aber genau so gut im Texteditor Nano geschrieben und auf der Putty-Linux-konsole ausgeführt werden.

Will man dieses Programm „zu Fuß“ ohne die Bibliothek ADAFRUIT_PYTHON_BBIO schreiben, dann wird die Programmierung sehr aufwändig, da man sehr viele Daten in einzelne Register schreiben und lesen muss (der BMP180 ist sehr komplex). Siehe hierfür z.B. ein entsprechendes Skript für den Raspberry Pi [32].

Übersicht der Beispiel-Pythonprogramme

Für das SRP sind für einige Funktionen/Sensoren/Aktoren schon Beispiel-Pythonprogramme vorhanden. Sie finden Sie als Download auf der Relax-Seite.

Funktion / Sensor / Aktor Programmname Bemerkung

AD-Wandlung myADC.py

LEDs ansteuern myBlink.py

Lidar Lite Sensor Version 1 myLidarLite.py I²C

Digitaler BeschleunigungssensorADXL345

myAdxl345.py

Digitaler Ultraschallsensor SRF02

mySRF02.py I²C, Änderung der I²'C-Adresse noch nicht implementiert

Analoger Ultraschallsensor HC-SR04

myHCSR04.py, myHCSR04Interr.py

Zweite Version mit Pseudointerrupt. Im Buch[7] ist eine Anleitung zu finden, wie man diesen Sensor mittels der PRUs via Python betreibt.

IMU-Sensor MPU6050 myMPU6050.py I²C, nur Ausgabe Beschleunigungswert implementiert

Digitaler Farbsensor TCS34725 myTcs34725.py I²C

Digitaler Lichttaster und Helligkeitssensor VCNL4010

myVCNL4010.py, VCNL40xxLib.py

I²C, Bibliothek muss im selben Verzeichnis sein.

Digitaler TOF-Sensor VL6180X myVL6180X.py, VL6180X_Lib.py

I²C, Bibliothek muss im selben Verzeichnis sein.

Drucksensor BMP180 simpletest_BMP180.py

I²C


9 Vorbereitung der Matlab/Simulink-Umgebung und des Tar-gets BBG

Das Zusammenspiel zwischen Matlab/Simulink und den BB findet auf verschiedenen Ebenen statt und ist daher am Anfang schwer zu verstehen. Grundsätzlich kann die Beziehung zwischen dieser Software und den BB in vier verschiedene Kategorien aufteilen

a) Fernzugriff auf den BB über das Matlab-Kommandofenster:

Hierfür wird die direkte oder über USB emulierte IP-Kommunikation zwischen dem PC und dem BB verwendet. In Matlab wird über den Befehl bbone = beaglebone_black ein BeagleBone-Objekt definiert. Über dieses Objekt kann man dann aus dem Matlab-Kom-mandofenster das Gleiche machen wie aus einer Putty-Linuxkonsole: Man kann Program-me ausführen, stoppen, IP-Adressen abfragen usw. Näheres hierzu siehe [33].

b) Algorithmen als Matlabskripte programmieren und diese in C-Quellcode konvertieren:

Der sogenannte „Matlab Embedded Coder“ konvertiert ein Matlab-Skript in C-Quellcode. Mit diesem wird dann mit Hilfe einer Entwicklungsumgebung wie Eclipse, entsprechenden Compilern, Debuggern usw. ein lauffähiges Programm für den BB erzeugt, dort gestartet und wenn nötig „debugged“. Diese Methode ist recht detailliert inkl. nötiger Toolchain in [8] beschrieben.

c) Algorithmen als Simulinkmodell programmieren, in C-Quellcode konvertieren und auf dem BB ausführen:

Der sogenannte „Simulink Embedded Coder“ erzeugt aus dem grafikbasierten Modell einenC-Quellcode. Dieser kann dann wie in b) über eine andere Entwicklungsumgebung weiter verarbeitet werden. Simulink kann aber auch selbst direkt aus dem Modell ein ausführbaresProgramm für den BB erstellen und dieses dort starten.

d) Algorithmen als Simulinkmodell programmieren, in C-Quellcode konvertieren und im „ex -ternal Mode“ auf dem BB ausführen:

Im Vergleich zu c) kommt hier der „external Mode“ ins Spiel: Das aus dem Modell erzeugte Programm wird ähnlich wie beim „Debuggen“ unter ständiger Kommunikation zwischen dem PC und dem BB kontrolliert auf dem BB ausgeführt. Das besondere hierbei ist, dass man sich live den zeitlichen Verlauf von Signalen anschauen kann oder auch Programmpa-rameter live verändern kann. Damit kann man z.B. unter Beobachtung des Regleraus-gangssignals die Regelparameter während der Laufzeit des Programms optimieren, und muss nicht bei jeder Änderung das Modell ändern und anschließend wieder neu kompilie-ren bzw. hochladen.

Im Praktikum wird primär der „External Mode“ d) verwendet. Nur als Work Around oder zur Fehler -suche wird zusätzlich der Fernzugriff aus a) bzw. der direkte Weg über die Linuxkonsole genutzt.

Die nachfolgende Dokumentation bezieht sich auf den Softwarestand R2015aSP1 von Mat-lab/Simulink in Verbindung mit Windows 7, 64 Bit.

Neben der Matlabgrundinstallation müssen folgende Toolboxen mindestens installiert sein:a) Simulink b) Simulink Coder c) Matlab Coder d) Embedded Coder.

Um einen BB unter Simulink zu programmieren muss sowohl die Matlab/Simulink-Software auf dem PC als auch das Linuxbetriebssystem auf dem BBG angepasst werden. Die dafür nötigen Schritte sind recht gut in der Matlabdokumentation unter [34] beschrieben.

Zuerst muss das sogenannte „Embedded Coder Support Package for BeagleBone Black Hardwa-re“ (der BBB ist ja für die Belange des SRP identisch mit dem BBG) auf dem PC innerhalb Matlab


nachinstalliert werden13. Zwei dafür nötige zusätzliche Support Packages werden in der Regel au-tomatisch mit installiert.Insgesamt werden bei diesem Vorgang also folgende drei Support Packages nachinstalliert:a) Embedded Coder Support Package for BeagleBone Black Hardwareb) Embedded Coder Support Package for ARM Cortex-A Processorsc) MATLAB Support Package for BeagleBone Black Hardware

Dann stellt Matlab/Simulink eine Verbindung zum BBG her und passt dessen Linux-Betriebssysteman („Customize Linux Image“)14.

Beide Anpassungen beanspruchen relative lange Zeit (jeweils ca. 20 Minuten).

Ob eine Verbindung zum BBG möglich ist, prüft man zuerst mit dem Befehl beaglebone_black im Matlab Command Window. Falls ja, wird die IP-Adresse und der Port des BBG ausgegeben.

Beim Build einer S-Function zeigt sich, ob ein geeigneter C-Compiler vorhanden ist. Dies kann vor-her auch im Matlabkommandofenster mit dem Befehl mex -setup überprüft werden. Beim Auftre-ten eine entsprechenden Fehlermeldung muss ein C-Compiler nachinstalliert werden. Welcher C-Compiler für Simulink geeignet ist, hängt von der Matlabversion und vom PC-Betriebssystem ab. Siehe hierzu de.mathworks.com/support/sysreq/previous_releases.html.

Achtung: Auch wenn Ihr BB die Prozedur „Customize Linux Image“ schon vorher auf einem anderen PC bzw. anderer Matlabinstallation durchlaufen hatte, müssen Sie diesen Schritt trotzdem wieder aus-führen! Ansonsten erhalten Sie bei der späteren Kompilierung Fehler, dass Standardbibliotheken nicht gefunden werden.

9.1 Simulink-Beispielprogramm beaglebone_gettingstartedDieses Simulinkmodell lädt man mit dem Befehl beaglebone_gettingstarted im Command Window. Das Modell lässt auf dem BB die äußerste LED nicht mehr in einem Herzschlagrhythmus sondern mit einer Frequenz von 1 Hz blinken.

Wenn man auf den Schalter „Deploy to Hardware“ klickt, passiert was in Abschnitt c) in der Einlei-tung beschrieben ist:Aus dem Simulinkmodell wird ein C-Code erzeugt. Dieser wird auf dem PC für den BB kompiliert („Building“ links unten im Fenster, ca. eine Minute), dann auf den BB hochgeladen15 und schließlichdort gestartet („Ready“ links unten im Fenster). Diese Schritte passieren automatisch. Siehe hierzuauch die entsprechende Hilfeseite von Simulink [35].

Dieses aus dem Simulinkmodell generierte Programm würde nun endlos auf dem BB laufen. Da -her muss man es manuell beenden. Dies geschieht durch die beiden Befehle bbone = beaglebone_black und stopModel(bbone, 'beaglebone_gettingstarted').

Erneutes Starten des Models erreicht man mit dem Befehl runModel(bbone, 'beaglebone_gettingstarted').

Mit dem Befehl isModelRunning(bbone, 'beaglebone_gettingstarted') stellt man fest,ob das Modell noch auf dem BB läuft.

13 Dies kann man auch durch den Befehl supportPackageInstaller aus dem Command Window von Matlab starten.

14 Kann auch aus dem Command Window heraus mit targetupdater gestartet werden.15 Standardmäßig wird die ausführbare Datei mit der Endung .elf im Build Directory /home des Users

root abgelegt (siehe Einstellungen in den „Model Configuration Parameters“).


9.2 Bekannte Probleme:• Matlab/Simulink sollte als Administrator auf dem PC ausgeführt werden. Sonst stürzt die

Vorbereitungsprozedur manchmal ab, wenn das Linuxbetriebssystem angepasst wird.

• Auf dem BB muss Debian 7 „Wheezy“ installiert sein. Die Version „Jessie“ führt zu einer Fehlermeldung bei der Anpassung des Linux-Betriebssystems.

• Die Paketverwaltungsliste auf dem BB muss aktuell sein. Befehl zum Aktualisieren:apt-get update.

• In älteren Internetpublikationen oder Fachbüchern wird für Simulinkmodelle die Dateiendung .mdl gennannt. Inzwischen verwendet Simulink für Modelle die Dateiendung.slx. Es ist sinnvoll importierte Simulinkmodelle immer als .slx-Datei abzuspeichern.

10 Programmieren des BB über SimulinkWie in Abschnitt 8 beschrieben, kann der BB über die Skriptsprache Python programmiert werden. Für die Kommunikation mit der Peripherie und als „Work Around“ wird dies im Praktikum auch an-gewendet.Für Echtzeitanwendungen kommt man jedoch nicht um eine C-Programmierung herum. C Pro-gramme kann man z.B. mit der Entwicklungsumgebung Eclipse und einem für den BB geeigneten Crosscompiler erstellen, was einen sehr hohen Einarbeitungsaufwand erfordert.

Den C Quellcode muss man aber nicht selbst erstellen: Zuerst wird das Programm textbasiert in Matlab als „m-Skript“ erstellt, als unter Verwendung der Matlab-Programmiersprache. Mit dem so-genannten „Matlab Coder“ erstellt Matlab daraus C-Quellcode. Diesen Quellcode wird dann in Eclipse verwendet, um daraus schließlich ein ausführbares Programm zu kompilieren, auf dem BB zu starten und dort zu debuggen.

Es geht aber auch noch einfacher: Die Algorithmen des Programms werden mit Simulink grafisch als Modell in Form eines Blockdiagramms „programmiert“. Der „Matlab Embedded Coder“ erzeugt daraus C-Quellcode und compiliert diesen für den BB. Dann überträgt Simulink dieses ausführbareProgramm auf dem BB und startet es dort.

Im sogenannten „External Mode“ von Simulink wird zusätzlich eine Kommunikation zwischen dem Simulink-PC und dem BB aufgebaut, die zwei Funktionen erfüllt:1) Der zeitliche Verlauf von Signalen des Modells kann am PC beobachtet werden. Damit wird z.B.der Verlauf eines Sensorsignals am Eingang des BB dargestellt.2) Bei dem auf dem BB laufenden Programm können „on the fly“ Parameter geändert werden, um die z.B. einen Regler zu optimieren.

Die verschiedenen Vorgehensweisen, C-Quellcode für den BB zu erstellen sind in [8] vergleichend dargestellt16.

10.1 Wieso macht der Einsatz von Simulink hier Sinn?Hier geht es um das „große Ganze“, sozusagen um den „Wald“, den man anfangs „vor lauter Bäu-men“ gar nicht sieht.

Früher hat man das Programm für ein eingebettetes System (z.B. Automobilsteuergerät) textba-siert in C programmiert. Dieser Quelltext wurde dann kompiliert und auf das eingebettete System übertragen. Diese Vorgehensweise war selten von sofortigem Erfolg gekrönt, da sich im Quellcodeimmer Fehler befanden. Selbst wenn schließlich der Quellcode fehlerfrei war, reagierte das Pro-gramm zur Laufzeit auf dem eingebetteten System anders als erwartet aufgrund von Tests des sel-

16 Jedoch bezieht sich dieses Buch noch auf das alte BeagleBoard-xM und ist fachlich/didaktisch nicht be-sonders gut.


ben Quellcodes auf einem PC

Konkret in der Automobilentwicklung führte dies dazu, dass immer wieder eine neue Software auf das Steuergerät aufgespielt und anschließend eine Testfahrt durchgeführt wurde, bei der man wie-der feststellte, dass etwas nicht stimmte.

Heute müssen Entwicklungszyklen wesentlich kürzer sein, was man nicht zuletzt durch folgende Innovationen in der Embeddedprogrammierung erreicht wurde:

• Simulation

• Modellbasierte (grafische) Programmierung

• Automatische Codegenerierung

Simulation:

Mechatronische Systeme werden komplett oder untergliedert in Subsysteme simuliert. In der Auto-mobilentwicklung erspart man sich dadurch z.B. zeitaufwändige Testfahrten.

Im SRP kann das Fahrverhalten des Roboterfahrzeugs komplett simuliert werden:Im Abhängigkeit von den PWM-Eingangsignalen auf die vier Radantriebe würde die Simulation die Bewegung des Fahrzeugs berechnen. Zusätzlich wird das Sensorsignal des Ultraschallsensors si-muliert, der den Abstand zur ebenfalls simulierten Wand ausgibt, entlang der das Fahrzeug fahren soll.

Mit diesem Modell kann nun in Simulink ein Regler entwickelt werden. Dieser wird innerhalb dieserSimulation optimiert. Ist dies geschehen, dann wird das Reglermodell auf den BB übertragen. Jetztkann man den (Hardware-)Regler auf dem BB testen, in dem man diesen mit dem restlichen Simu-lationsmodell des Fahrzeugs in Echtzeit kommunizieren lässt. Dies nennt man „Hardware in the Loop“, da nun der BB als echte (nicht mehr simulierte) Hardware Teil des Regelkreises geworden ist.Diese Vorgehensweise erspart viele aufwändige Testfahrten mit dem Fahrzeug. Außerdem wird konform mit dem V-Modell, die Funktion des Subsystems „BB als eingebettetes System für die Re-gelung“ verifiziert.

Mittels Simulation lassen sich also Testzyklen am realen System verringern. Subsysteme können in einer Simulation isoliert getestet werden und deren korrekte Funktion kann damit verifiziert wer-den.

Modellbasierte Entwicklung:

In Simulink wird der Algorithmus über Blöcke und deren Signalfluss untereinander „programmiert“. Dadurch muss man sich nicht mehr auf die Syntax einer Programmiersprache konzentrieren. Der Algorithmus wird für Außenstehende auch ohne Programmiererfahrung leicht verständlich. Daher können diese Modelle auch einfach für andere Softwareprojekte wiederverwendet werden.

Automatische Codegenerierung:

Der Algorithmus, d.h. die eigentliche Geistesleistung steckt somit in dem Modell. Aus diesem Mo-dell generiert die Software Simulink textbasiertem C-Code. Dies nennt man „automatische Code-generierung“. Dadurch werden vor allem Syntaxfehler beim Eintippen von Quellcode vermieden.Bei Simulink wird die Codegenerierung „Simulink Coder“ genannt. Gleiches gibt es auch bei Mat-lab: Hier kann mit dem „Matlab Coder“ aus einem Matlab-Programm C-Code erzeugt werden.

Aus diesem automatisch generierten C-Code wird mit einem C-Compiler ein auf dem PC ausführ-bares Programm erzeugt. Im Grunde genommen passiert das Gleiche, wenn man das Simulinkmo-dell bzw. das Matlab-Programm auf dem PC simuliert bzw. ausführt.


Will man nun C-Code für ein eingebettetes System wie den BB erzeugen, dann wird die Sache et-was komplizierter. Denn hier müssen z.B. I/Os bedient werden, und es gibt unter Umständen gar kein Betriebssystem. Trotzdem soll aber das Programm auf dem BB sich genau wie auf dem PC verhalten, was ja auch eine Grundvoraussetzung für das o.g. Einbinden von Simulationen ist.Die Aspekte „Simulation“ und „automatische Codegenerierung“ erfüllt die Software Matlab schon. Durch die Software Simulink kommt noch die Funktionalität der „modellbasierten Entwicklung“ hin-zu.

Insofern überlappen sich Matlab und Simulink. Daher können Simulinkblöcke für den BB z.B. auch Matlabcode beinhalten. Man nennt sie dann „Simulink Matlab Function Block“. Dieser Matlabcode kann wiederum C-Code enthalten. Oder ein Simulinkblock enthält direkt C-Code.

Denn am Ende wird sowieso C-Code generiert und für den BB kompiliert. Ob dieser C-Quellcode nun automatisch aus einem vorgefertigten Simulinkblock heraus, oder automatisch aus einem „Si-mulink Matlab Function Block“ mit eingebundenem Matlabprogramm heraus, oder einfach direkt aus eingebundenem C-Quellcode (entweder in einem Simulinkblock oder in einem Matlabpro-gramm) heraus gewonnen wird, ist für den Compiler des BB weitgehend egal.

In der Grafik in Abb. 17 ist die Codegenerierung und die Verifikation des BB Programms über eine Simulation dargestellt. Eigentlich ist der PC, auf dem die Simulation ausgeführt wird, auch nur ein „Target“: Statt des BB wird ein PC als Mikrocomputer verwendet.

In Abb. 18 ist dargestellt wie aus dem grafischen Simulinkmodell durch die automatische Codege-nerierung am Ende eine auf dem BB ausführbare Datei (=Programm) wird. Simulink macht hierbei nur den ersten Schritt vom Modell zur Quellcode-, Header- und Makedatei. Den Rest erledigt OpenSource Software, die sogenannte „Linaro Toolchain“.


Abbildung 17: Informationsfluss der automatischen Codegenerierung: Auf dem PC als Target wird bei einer Simulinksimulation ebenfalls Code generiert. Das Simulationsergebnis wird mit dem Lauf-zeitverhalten des BB verglichen, um den BB-Code zu verifizieren.

unterschiedlich je nach Target

Simulink Modell(bzw. Matlabcode) C-Quellcode

Compiler fürBeagleBone

AusführbaresProgramm

BeagleBone

„Simulink Coder“ bzw. „Matlab Coder“

„Simulink Embedded Coder“ bzw. „Matlab Embedded Coder“

Simulation auf PC Verhalten auf BB Verifikation FunktionEmbedded Code

10.2 Ausführen eines Simulinkmodells auf dem BBIm SRP werden zwei Arten verwendet, wie ein Simulinkmodell auf dem dem BB ausgeführt wird.

1) Wie in Abschnitt 9.1 beschrieben kann man über den Schalter „Deploy to Hardware“ das Modell auf den BB starten, wo es völlig autark läuft, bis es über den Befehl stopModel() im Komman-dofenster von Matlab wieder beendet wird, falls eine unendliche Ausführungszeit einstellt wurde und es sich nicht selbst stoppt.

2) Klickt man auf den „Run“-Schalter so passiert erst einmal das gleiche wie in 1).Das Modell wird aber jetzt im sogenannten „External Mode“ auf dem BBG gestartet. D.h. während der Laufzeit des Modells gibt es eine ständige Kommunikation zwischen Simulink und dem BBG. So können z.B. Messwerte des BB in einem Scope des Simulinkmodells während der Laufzeit (aber meistens nicht in Echtzeit!) angezeigt werden. Oder es kann umgekehrt über einen Schiebe-regler im Model ein Ausgang am BB gesteuert werden.

10.3 Beispielmodell: Externe LED blinken lassen.Der Ausgang P9_14 (linke Steckerleiste wenn Ethernetanschluss oben, 2. Spalte, 7. Zeile) wird analog wie im gleichen Pythonbeispiel mit einer Frequenz von 1 Hz ein- und ausgeschaltet.

Hierfür wird das Modell beagleboneBlink im normalen Modus („Deploy to Hardware“) gestartet.

10.4 Beispielmodell: Analogspannung auslesen (ADC).Analog wie im entsprechenden Pythonbeispiel wird an dem Steckplatz J3 des Grove Capes ein Potentiometer angeschlossen. Dieses wird mit VCC und GND spannungsversorgt. Sein Ausgang liegt auf Eingang AIN0 (P9_39). Der gemessene Wert soll in einem Scope dargestellt werden.


Abbildung 18: Schnitte des durch Matlab/Simulink automatisierten Prozesses, durch den aus einem grafischen Modell eine auf den BB ausführbare Programmdatei wird.

Simulinkprogramm

Simulink Coder

C-Preprocessor

C-Compiler

Assembler

C-Linker

meinModell.cmeinModell.hmeinModell.mk

meinModell.slx

meinGanzesModell.c

meinGanzesModell.s

meinGanzesModell.o

meinGanzesModell.elf

QuellcodedateiHeaderdateiMakedatei

PlattformunabhängigeAssemblerdatei

PlattformspezifischeObjektcodedatei

Plattformspezifischeausführbare Datei

Kompletter Quellcode in einer Datei

Da der Spannungswert am Potentiometer im Scope des Simulinkmodells angezeigt werden soll, muss dieses Modell im „External Mode“ gestartet werden. Dies geschieht durch Klicken des grünen „Run“-Schalters.

In Abb. 19 ist ein Screenplot dieses Beispielmodells be-agleboneADC dargestellt. Die Eingangspannung wurde durch Drehen des Potentiometers verändert.

In einem weiteren Beispielmodell beagleboneLED wird die Spannung am Potentiometer ausgelesen und dieser Wert als Tastverhältnis für die Versorgungsspannung derLED verwendet. Über den Saturation-Block wird das Tastverhältnis auf Werte von 0...1 beschränkt.

Mit diesem Modell kann man die Helligkeit der LED mit sehr viel Softwareaufwand ;-) über das Po-tentiometer einstellen. Wurde das früher nicht einmal viel einfacher gemacht?

10.5 Indirekter Zugriff von Simulink auf Sensorwerte über eine Überga-bedatei

Bei Sensoren, für die (noch) keine fertigen Simulinkblöcke zur Kommunikation bereitstehen oder falls die Messzeit des Sensors im Vergleich zur Sample Time zu lang ist, muss folgender Work Around verwendet werden.17

Hierzu wird der Sensor zyklisch mit einem Pythonskript ausgelesen und der aktuelle Sensorwert wird in eine speziell für diesen Sensor angelegte Übergabedatei sensorData.txt geschrieben, wobei für sensor eine entsprechende Bezeichnung gewählt wird (z.B. „HCSR04“ für den Ultra-schallsensor). Dieser Prozess der Messdatenerfassung läuft dabei auf dem BB unabhängig als ge-trennter Task zu dem Simulinkmodell.

Das Pythonskript sensorDriver.py muss im Home-Verzeichnis des BB (standardmäßig root) hinterlegt sein.

17 Prinzipiell kann es bei diesem Ansatz zu Konflikten kommen, wenn ein Prozess die Datei liest, während ein anderer Prozess gerade in die selbe Datei schreibt. Bisher sind solche Probleme in der Praxis jedochnoch nicht aufgetreten.


Abbildung 19: Screenshot des Simulinkmodells beagleboneADC. Die Eingangspannung wur-de durch Drehen des Potentiometers verändert.

Abbildung 20: Modell beagleboneLED: Steue-rung LED-Helligkeit über Potentiometer.

Im Simulinkmodell verwendet man für das Erfassen dieser Sensordaten den Simulinkblock Sensor-FromFile. Dieser ist ein sogenannter „Simulink Matlab Function Block“, dem Matlabcode hinterlegt ist, welcher durch Doppelklicken angezeigt wird (nä-here Informationen dazu siehe [36], der Matlabquell-code ist in Anhang 12.12 wiedergegeben). Der Mat-labcode ruft die Funktionen startSensor, stop-Sensor, readData und getData auf. Der C-Quell-code für diese Funktionen befindet sich in der Datei sensorFromFile.c . Dieser C-Quellcode muss sich im Arbeitsverzeichnis des Simulinkmodells be-finden.

Wie in Abb. 22 Dargestellt ist C-Quellcode in einem Matlabprogramm integriert, welches wiederum in ei-nem Simulinkblock integriert ist. Der „Simulink Em-bedded Coder“ (siehe Abb. 17) generiert daraus ein zusammenhängenden C-Quellcode, der beim Star-

ten des Simulinkmodells für den BB kompiliert wird.

Dafür muss die o.g. Quellcodedatei unter Simulation > Model Configuration Parame-ters unter Custom Code angegeben werden (siehe Abb. 21).

Der Simulinkblock SensorFromFile startet das Pythonskript sensorDriver.py , welches die aktuellen Sensorwerte fortlaufend in die Datei sensorData.txt schreibt. Liegt ein Triggersignal am Eingang (Trigger) dieses Blocks an, dann wird der aktuelle Sensorwert aus dieser Datei gele-sen und am Ausgang (Output) des Blocks ausgegeben.

Da sich in dieser Datei immer nur ein Messwert befindet, wird jeweils der aktuelle von Simulink ge-lesen. Beide Prozesse, das Pythonskript und das Simulinkmodell, laufen dann parallel auf dem BB.

Zur Verdeutlichung ist dieser Workflow in Abb. 22 grafisch wiedergegeben.


Abbildung 21: Angabe der C-Quelltextdatei für den Block SensorFromFile in den „Simulink Configu-ration Parameters“.

Abbildung 22: Workflow des Simulink Matlab Function Blocks SensorFromFile, der Matlabcode beinhaltet. Dieser enthält wiederum C-Code u.a. mit den Funktionen startSensor und readData, die er aufruft.

C-Code SensorFromFile.c

Simulink ModellSimulink MatlabFunction Block

SensorFromFile

IntegrierterMatlabcode

SensorFromFile

Funktion startSensor

Funktion readData

Pythonskript sensorDriver.py

Aktuellen Sensor-wert speichern

Aktuellen Sensor-wert auslesenDatei

SensorData.txt

BeagleBone

Beim Beenden des Modells sollte das Pythonskript sensorDriver.py durch den Simulinkblock SensorFromFile automatisch wieder beendet werden, was aber derzeit noch nicht funktioniert.

Achtung:Daher muss (derzeit noch) nach dem Beenden des Modells auf dem BB das Pythonskript sensorDriver.py manuell beendet werden. Dies geschieht über folgende Befehle in der Linuxkonsole:

1) Mit dem Befehl ps -efa | grep sensorDriver.py die Prozess-IDs des Skript anzeigen lassen. Hier für sensorDriver.py den entsprechenden

Skriptnamen einsetzen.

2) Mit dem Befehl kill PID die in 1) angezeigten Prozesse beenden. Hier für PID die in 1) ange-zeigten Porzess-IDs (vierstellige Nummern) einsetzen.

Zusammenfassung:

Für Sensoren, auf deren Schnittstellen nicht über fertige Simulinkblöcke zugegriffen werden kann, wird der Simulinkblock SensorFromFile verwendet:Dieser startet das Pythonskript sensorDriver.py auf dem BB, das mit dem Sensor kommuni-ziert. Die Messdaten werden von diesem Skript in die Übergabedatei sensorData.txt auf dem BB geschrieben. Von dort aus werden Sie durch den Simulinkblock SensorFromFile gelesen, was über Funktionsaufrufe des C-Programms sensorFromFile.c geschieht.Im root-Verzeichnis des BB muss dafür das Pythonskript sensorDriver.py vorhanden sein.Im Matlab-Verzeichnis muss dafür das C-Programm sensorFromFile.c vorhanden sein und über die „Simulink Model Configuration“ angegeben werden.

In den o.g. Namen muss das Wort sensor, wenn es kursiv geschrieben ist, durch den aktuellen Sensortyp ersetzt werden. Denn bei mehreren Sensoren benötigt jeder Sensor einen eigenen Si-mulinkblock SensorFromFile. Im Fall vom Ultraschallsensor heißt z.B. das Pythonskript somit HCSR04Driver.py und das C-Programm HCSR04FromFile.c.

In den Abschnitten 10.6 und 10.7 ist für zwei Sensorarten diese Zugriffsmethode konkret nochmalserklärt.

Bemerkung:Alternativ kann man auch einen sogenannten „S-Function“-Block für diese Aufgabe erstellen: Hier wird C-Code direkt in den Simulinkblock eingebunden. Das Verwenden von „S-Functions“ ist etwaskomplexer im Vergleich zu den oben beschriebenen Verfahren über die „Simulink Matlab Function“Blöcke. Es bietet aber mehr Einstellmöglichkeiten bei den Simulations- und Codegenerierungs-parametern. Ein Beispiel für die Verwendung von „S-Functions“ für den BB findet sich in [9] und in[8].

In Abschnitt 11.2 finden Sie sogenannte „S-Function Builder“ Blöcke für ausgewählte I²C-Senso-ren. Diese Blöcke befinden sich aber noch in einer „Betaversion“, Sie können sie aber als Aus-gangsbasis für eigene S-Function Blöcke verwenden.

10.6 Beispielmodell: Sensor MPU6050 via I²C auslesen.Prinzipiell kann man einen I2C-Sensor (gilt auch für UART und SPI) direkt aus Simulink auslesen. Solche Blöcke für den BB stehen als „Betaversionen“ im Praktikum zur Verfügung und müssen noch je nach Anwendung erweitert werden (siehe Abschnitt 11).


Abbildung 23: Identifikation und Beenden des Prozesses 1689 des Pythonskripts HCSR04Driver.py (Beispiel des Ultraschall-sensor).

In diesem Beispiel wird die Methode einer Übergabedatei verwendet, in die ein Pythonskript den aktuellen Sensorwert schreibt. Näheres siehe Abschnitt 10.5.

Wie in Abschnitt 10.5 beschrieben, ist die einzige Aufgabe des Pythonskripts MPU6050Driver.p-y, in festen Zeitabständen den aktuellen Sensorwert in die Übergabedatei MPU6050Data.txt ab-zuspeichern. Aus dieser Datei liest der Simulinkblock SensorFromFile den Messwert mit Hilfe der Funktionen des C-Programms MPU6050FromFile.c.

Das Pythonskript muss im root-Verzeichnis des BB und das C-Programm muss im Arbeitsverzeich-nis von Matlab sein. Außerdem muss es über die „Simulink Model Configuration“ eingebunden werden.

Im Beispielmodell BB_MPU6050File_Test.slx wird der x-Beschleunigungswert ausgelesen unddamit das Tastverhältnis der Versorgungsspannung einer LED am PWM-Pin 9_14 gesteuert18.

18 Da das C-Programm MPU6050FromFile.c nur Ganzzahlen einliest, gibt das Pythonskript


Quellcode MPU6050FromFile.c:#include <stdlib.h>#include <stdio.h>#include <inttypes.h> FILE *dataFile;const char *filename1 = "MPU6050Data.txt";int Data; void startSensor(){ system("python MPU6050Driver.py &");} void stopSensor(){ system("kill $(pgrep MPU6050Driver)");} int readData(){ int foundNumbers = 0; dataFile = fopen(filename1, "rb"); if (dataFile) { //----- FILE EXISTS ----- foundNumbers = fscanf(dataFile, "%d", &Data); fclose(dataFile); dataFile = NULL; } return foundNumbers;} int getData(){ return Data;}

Quellcode MPU6050Driver.py:import timefrom Adafruit_I2C import Adafruit_I2C

i2c = Adafruit_I2C(0x68)i2c.write8(0x6B, 0)streaming_file = "MPU6050Data.txt"pauseTime = 0.5

while True: b = i2c.readS8(0x3b) s = i2c.readU8(0x3c) raw = b * 256 + s XAcc = 1000 * raw / 16384. Data = open(streaming_file, 'w') Data.write(str(xAcc)) Data.close() time.sleep(pauseTime)

Achtung:Nach dem Beenden des Modells sollte nicht vergessen werden, das Pythonskript auf dem BB ma-nuell zu beenden.

10.7 Beispielmodell: Analoger Ultraschallsensor HC-SR04 auslesen.Der HC-SR04 ist ein Sensor mit einer sogenannten „pulsbreitenanalogen“ Ausgangsschnittstelle. Dies bedeutet, dass der Entfernungsmesswert als Pulsbreite ausgegeben wird, die der Echolauf-zeit entspricht. Wie nachfolgend erklärt wird, kann dieser Sensor ohne größeren Programmierauf-wand nur über die Methode einer Übergabedatei ausgelesen werden.

Ein µC kann eine Pulsbreite mit wenig Programmier- und Rechenaufwand über zwei Interrupt-Befehle (einer bei steigender und einer bei fallender Flanke) ausmessen. Grundsätzlich geht dies auch beim BB über die PRU. Deren Funktion ist aber derzeit weder in Simulink noch in Python im-

plementiert.

Daher bleibt nur die Möglichkeit übrig, diese Puls-breite über ein Polling auszumessen. Dies bedeu-tet, dass der Sensorausgang laufend mit einer ho-hen Frequenz abgetastet wird. Aus dem Abtaster-gebnis wird dann die Pulsbreite bestimmt.

Um über Polling eine Abstandsauflösung von 1 cm zu erreichen, muss der Ausgang des Ultraschall-sensors mit einer Frequenz von ca. 15 kHz abge-tastet werden. Dies ist für die hohe Prozessorleis-tung des BB im Prinzip kein Problem.

Jedoch kann Simulink einen digitalen Eingang des BB nicht mit so eine hohen Rate abtasten. Denn dafür wäre eine Schrittweite (Sampling Time) für das gesamte Modell von ca. 0,00007 s nötig, was

bei einem schon annähernd komplexen Modell die Rechenleistung des BB überfordert.

Das Polling des Ultraschallsensors wird daher über ein parallel laufendes Pythonskript durchge-führt, welches jeweils nur den aktuellen Messwert in die Datei HCSR04Data.txt schreibt, der dann vom Simulinkblock sensorFromFile wieder ausgelesen wird.

Dieses Pythonskript HCSR04Driver.py ist bis auf den Schreibvorgang in die Datei fast identisch mit dem Beispielskript aus Abschnitt 8.4.

MPU6050Driver.py die x-Beschleunigungsmesswerte als Ganzzahlen in der Einheit mg aus.


Abbildung 24: Simulinkmodell BB_MPU6050File_Test.slx: Über die gemessene x-Achsen-Beschleunigung wird die Helligkeit der LED gesteuert.

Abbildung 25: Beispielmodell BB_HCSR04File_Test.slx, das im „External Mode“ den Ultraschallsensor ausliest und dessen Messwerte darstellt.

Im Beispielmodell BB_HCSR04File_Test erscheint als Gegenstück zu dem Pythonskript der Block SensorFromFile, der dann über einen Triggereingang gesteuert den jeweiligen Wert aus


Quellcode hcsr04FromFile.c:#include <stdlib.h>#include <stdio.h>#include <inttypes.h> FILE *dataFile;const char *filename1 = "HCSR04Data.txt";int Data;void startSensor(){ system("python HCSR04Driver.py &");}void stopSensor(){ system("kill $(pgrep HCSR04Driver)");}int readData(){ int foundNumbers = 0; dataFile = fopen(filename1, "rb"); if (dataFile) { //----- FILE EXISTS ----- foundNumbers = fscanf(dataFile, "%d", &Data); fclose(dataFile); dataFile = NULL; } return foundNumbers;}int getData(){ return Data;}

Quellcode HCSR04Driver.py:import timeimport Adafruit_BBIO.GPIO as GPIO

GPIO_TRIGGER = "P9_21" #UART2_TXD auf dem Grove CapeGPIO_ECHO = "P9_22" #UART2_RXD auf dem Grove CapeGPIO.setup(GPIO_TRIGGER, GPIO.OUT)GPIO.setup(GPIO_ECHO, GPIO.IN)

streaming_file = "ultrasData.txt"cSound = 340000pauseTime = 0.05delayEchoEdge = 0.0005

time.sleep(2)GPIO.setup(GPIO_TRIGGER, GPIO.OUT)GPIO.setup(GPIO_ECHO, GPIO.IN)GPIO.output(GPIO_TRIGGER, False)time.sleep(0.01)try: while True: GPIO.output(GPIO_TRIGGER, True) time.sleep(0.00001) GPIO.output(GPIO_TRIGGER, False) start = time.time() stop = time.time() time.sleep(delayEchoEdge) while GPIO.input(GPIO_ECHO)==1: stop = time.time() elapsed = stop - start - delayEchoEdge if elapsed<0: distance = 0 else: distance = (elapsed * cSound)/2 print "%d mm" % distance Data = open(streaming_file, 'w') Data.write(str(int(distance))) Data.close() time.sleep(pauseTime) except KeyboardInterrupt: GPIO.cleanup(GPIO_ECHO, GPIO_TRIGGER)

der Datei liest und diesen an dessen Ausgang (Output) bereitstellt. Dafür bedient sich der Block dem C-Programm HCSR04FromFile.c, das nicht nur im Matlabarbeitsverzeichnis liegen, son-dern auch über die „Simulink Model Configuration“ eingebunden sein muss. Näheres siehe Ab-schnitt 10.5.

Oben sind die Quelltexte des Pythonskripts und des C-Programms dargestellt.

Das Beispielmodell BB_HCSR04File_Test ist in Abb. 25 dargestellt.

Achtung:Nach dem Beenden des Modells sollte nicht vergessen werden, das Pythonskript auf dem BB ma-nuell zu beenden.

Der Ultraschallsensor wird genau so wie in Abschnitt 8.4 an den UART_2 Anschluss des Grove-Capes angeschlossen.

Alternativ kann auch der I²C-Ultraschallsensor SFR02 verwendet werden. Dieser kann aufgrund seiner digitalen Schnittstelle über einen S-Fuction Block ausgelesen werden, siehe Abschnitt11.2.6.

10.8 Kontrolle der Ausführungsgeschwindigkeit des Programms auf dem BB

Das Modell soll auf dem BB mit der vorgegebenen Wiederholrate (Sample Time) ausgeführt wer-den, die global unter „Model Configuration Parameters“ vorgegeben ist.

Falls für die einzelnen Blöcke angegeben ist, dass sie diese Sample Time erben („inherited“), dannwerden sie mit der selben Wiederholrate ausgeführt.

Wenn die Sample Time zu klein gewählt ist (wählen Sie besser keine Sample Time < 10 ms) oder der Quellcode des Modells sehr aufwändig ist, dann reicht die Rechenleistung des BB nicht mehr aus. In diesem Fall wird das Modell nicht mehr in Echtzeit ausgeführt.

Ob dies der Fall ist, kann z.B. über die zwei folgenden Wege herausgefunden werden:

a) Verwenden der „Overrun Detection“ von Simulink:

In den „Model Configuration Parameters“ kann unter eine „Overrun Detection“ aktiviert werden, sie-he [37]. Dann soll eine Meldung im „Diagnostic Viewer“ erscheinen, wenn die Ausführungsge-schwindigkeit des Modells auf dem BB zu langsam ist. Allerdings ist dieses Feature in der Matlab/Simulink-Version 2015b nicht mehr auffindbar. ;-)

b) Toggeln eines GPIOs mit der Wiederholrate:


Wie in Bild 26 am Beispielmodell BB_SFR02_SampleTime.slx gezeigt, kann man über eine ein-fache logische Rückkopplung den GPIO P9_11 des BB im halben Takt der Wiederholrate des gleichzeitig ausgeführten Modells oszillieren lassen. Dieses Rechtecksignal wird mit einem Oszillo-skop ausgemessen und über den Flankenabstand die tatsächliche physikalische „Sample Time“ des Modells bestimmt.

10.9 Bekannte Probleme / Fehler / Ungereimtheiten

• Das Lesen von Gleitkommazahlen aus der Datei sensorData.txt durch Simulink funktio-niert nicht.

• Die Pin-Zuordnung ändert sich nach dem Booten, da die Device Tree Overlay nicht unbe-dingt vom Capemanager automatisch neu geladen werden. Wollen Sie ein mit Simulink er-zeugtes Programm manuell ausführen, dann müssen Sie eventuell die DTOs manuell vor-her laden.Siehe Abschnitt 7.2.3.

• Stellen Sie im Simulinkmodell unter „Configuration Parameters>Solver“ bei „Solver Opti-ons“ unter „Type“ „Fixed-step“ und unter „Solver“ nicht „auto“ sondern auf „discrete“ ein. Verwenden Sie am Anfang unter „Additional options“ eine „fundamental sample time“ von 0.01.Für die einzelnen Blöcke Ihres Modells übernehmen Sie diese globalen Einstellungen über „inherited“ bzw. „-1“.

• Fehlende Typumwandlungen im Modell (z.B. von Integer auf Binär) können dazu führen, dass Programm Schnittstellen nicht mehr funktionieren, da vermutlich deren Speicherberei-che durch die zu großen Variablen überschrieben werden.

11 Verwendung selbst erstellter S-Function BlöckeUm den in Abschnitt dargestellten Work Around mit Pythonskripten zu vermeiden, kann man selbstS-Functions erstellen, die direkt mit der Peripherie kommunizieren.

Dazu gibt es den „S-Function Builder Block“, in dem man die I/Os definiert und C-Quellcode ein-gibt, in dem die Funktion selbst steckt wie z.B. das Lesen auf einem I²C Bus.


Abbildung 26: Modell BB_SFR02_SampleTime.slx, mit dem über den GPIO Pin P_11 ein Rechtecksignal ausgegeben wird. Dessen Frequenz ist gleich der halben Wiederholrate.

Die Ihnen im SRP zur Verfügung gestellten S-Fuction Builder Blöcke können Sie also nach Ihren Bedürfnissen erweitern, um beispielsweise aus einem I²C Read Block einen kompletten Treiber-block für einen Sensor zu erstellen.

Aus einem S-Function Builder Block kann man eine S-Function erstellen und diese „maskieren“. Dies bedeutet, dass der Benutzer dieses Blocks (wie bei den Blöcke aus dem „Embedded Coder Package für BeagleBone Black Hardware“) in einer vereinfachten Benutzeroberfläche nur die ein-stellbaren Parameter sieht. Im Verzeichnis der S-Function „xyz“ müssen dann aber die Dateien xyz.mex, xyz_wrapper.c und xyz.tlc des S-Function Builder Blocks befinden, da sich die S-Function auf diese bezieht.

In [9] finden Sie eine detaillierte Anleitung, wie man S-Functions für den BB erstellt.Vereinfacht dargestellt besteht ein S-Function Builder Block aus folgenden Komponenten:

• Es gibt Eingänge, Parameter und Ausgänge, wobei jedem Wert (der Matlab-typisch ein Vektor darstellt) ein Variablennamen und ein Datentyp zugeordnet wird.

• Durch den C-Quellcode unter „Outputs“ wird aus den aktuellen Eingangswerten entspre-chende Ausgangswerte berechnet.

• Wenn nötig, kann man unter „Discrete Updates“ die Variablen xD[n] einführen, mit denen z.B. gesteuert wird, dass eine C-Quellcodefunktion nur bei dem ersten Sample ausgeführt wird, was z.B. für das Beenden des Sleepmodus beim I²C-Sensor MPU6050 genutzt wird.

11.1 Debuggen eines S-Function Builder BlocksUm einen S-Function Builder Block (SFBB) zu testen, platziert man diesen in ein Testmodell und fügt die nötigen Signalquellen am Eingang und Signalquellen am Ausgang hinzu. Die Beispiel SFBB im SRP sind daher schon in Modellen mit dem Namen „..._Test.slx“ abgespeichert.

Im Quellcode des SFBB verwendet man printf() C-Befehle, um Debugmeldungen auszugeben.Wenn man das Modell auf dem BB startet (egal ob „External Mode“ oder nicht), erscheint diese Textausgabe zur Laufzeit weder im Kommandofenster von Matlab noch in einer zusätzlich geöffne-ten Linuxkonsole des BB.

In diesem Fall findet man die Debugmeldungen aus dem printf() C-Befehle aber nach Been-den des Modells in einer Log-Datei, die sich im selben AB-Verzeichnis wie das ausführbare Pro-gramm befindet.

11.1.1 Verwenden von Log-Dateien

Beim Starten des Modells wird also eine Log-Datei angelegt, in der u.a. die printf() Ausgaben gespeichert werden. Diese Log-Datei kann man sich nach Beenden des Modells auf dem BB im Matlab-Kommandofenster über folgende Befehle anzeigen lassen:

bbone = beaglebone_black und System (bbone, 'cat Modellname.log').

Für Modellname wird der Name des Simulinkmodells eingesetzt.

11.1.2 Ausführen des Modells auf dem BB über eine Linuxkonsole

Will man während der Laufzeit des Modells die Textausgaben der printf() C-Befehle live sehen,so muss man das ausführbare Programm mit der Endung .elf manuell aus einer Linuxkonsole starten:


Dazu wird entweder mit der Software Putty oder über die Web IDE Cloud919 eine Linuxkonsole geöffnet. Bei Putty muss man sich explizit als root einloggen. Aus dem hone-Verzeichnis heraus wird das Modell mitBefehl ./Modellnachbauten gestartet.

Dann erscheinen wie in Abb. 27 darge-stellt die Debugmeldungen aus den printf() C-Befehlen in der Konsole. Mit der Tastenkombination Strg C wird das Modell anschließend wieder beendet.

Hierbei ist jedoch wichtig, dass das ausführbare Modell Modellnachbauten unter Simulink nicht im „External Mode“ sondern über „Deploy to Hard ware“ erzeugt wurde.

Startet man das Modell auf dem BB nicht als root User, dann muss man ihm vorher noch über den Befehl chmod a+x Modellnachbauten die

Berechtigung geben, von allen Usern ausgeführt zu werden.

Diese Dialektvariante ist im Beispielmodell BB_SFR02_SfctnB_wDebug_Test.slx exemplarisch gezeigt.

11.2 Im Praktikum verfügbare S-Function Builder Blöcke als Ausgangs-basis

Die S-Functions für das Lesen/Schreiben der GPIOs und das Ansteuern der User LEDs sind von ihrer Funktion her identisch mit den entsprechenden Blöcken aus der Simulink Model Library für den BB.

Die Blöcke befinden sich jeweils in einem Modell, dessen Namen mit ..._Test endet. Der Ena-ble-Eingang dient dazu, die Ausführung des Blocks während des laufenden Modells ein- und aus-zuschalten.

11.2.1 I²C Bus Lesen

Für eine vorgegebene I²C Adresse wird aus einem vorgegebenen Register dessen Wert in Form von einem Byte ausgelesen.S-Function Builder Block Name: BB_I2C_Read_noD

Eingangsignale Parameter Ausgangssignale

• Enable (Boolean) • I2C-Adresse des Periphe-riegeräts (Dec)

• Gelesener Wert (Hex)

19 Rechter Mausklick auf dem Workspaceordner home (~) und „Open Terminal Here“ auswählen


Abbildung 27: Öffnen einer Linux-Konsole über die Web IDE Cloud9 und Starten des vorher unter Simulink erzeugten ausführbaren Mo-dells BB_SFR02.elf auf dem BB.

• Auszulesende Registeradresse (Dec)

• Nummer des I²C-Busses (Dec)

Modellname: BB_I2C_Read_SfctnB_noDebug_Test.slx

11.2.2 I²C Bus Schreiben

Für eine vorgegebene I²C Adresse wird in ein vorgegebenes Register der am Eingang anliegende Wert (1 Byte) geschrieben.S-Function Builder Block Name: BB_I2C_Write_noD


• Enable (Boolean)• Zu schreibender Wert

(1 Byte)

• I2C-Adresse des Periphe-riegeräts (Dec)

• Auszulesende Registeradresse (Dec)


• Rückgelesener Wert aus dem Register (1 Byte)

Modellname: BB_I2C_Write_SfctnB_noDebug_Test.slx

11.2.3 GPIO Lesen

Für eine vorgegebene GPIO-Nummer wird der an dessen Eingang anliegende Pegel abgefragt und als boolscher Wert ausgegeben.S-Function Builder Block Name: BB_GPIO_Read_noD


• Enable (Boolean) • Nummer des GPIOs (Dec)Die Zuordnung zum physikalischen Pin auf der Buchsenleiste des BB ist abhängig vom aktiven DTO.

• Gelesener Wert des GPI-Os (Boolean)

Modellname: BB_GPIO_Read_SfctnB_noDebug_Test.slx

11.2.4 GPIO Schreiben

Für eine vorgegebene GPIO-Nummer wird der an dessen Eingang anliegende Pegel abgefragt und als boolscher Wert ausgegeben.S-Function Builder Block Name: BB_GPIO_Write_noD


• Enable (Boolean)• Zu schreibender Wert

(Boolean)

• Nummer des GPIOs (Dec)Die Zuordnung zum physikalischen Pin auf der Buchsenleiste des BB ist abhängig vom aktiven DTO.

• Zurück gelesener Wert des GPIOs nach dem Schreiben (Boolean)

Modellname: BB_GPIO_Write_SfctnB_noDebug_Test.slx

11.2.5 HCM5883L GMR Magnetfeldsensor auslesen (I²C)

Auslesen der magnetischen Flussdichten in x, y und z, der gesamten Flussdichte, sowie deren Winkel zur Richtung des magnetischen Nordpols. Nähere Infos siehe [9].S-Function Builder Block Name: BB_HMC5883L_SfctnB_noD



keine • I2C-Adresse des Periphe-riegeräts (Dec)


• Mittelungstiefe, Messrate, Empfindlichkeit usw.

• Magn. Flussdichte X• Magn. Flussdichte Y• Magn. Flussdichte Z• Gesamte magn. Flussd.• Winkel zur Nordrichtung

(jeweils Double)

Modellname: BB_HMC5883L_SFctnB_noD_Test.slx

11.2.6 SRF02 Ultraschallsensor auslesen (I²C)

Einzelne Entfernungsmessung und Ausgabe des Werte in cm.S-Function Builder Block Name: BB_SRF02_ReadDist_noD bzw. BB_SRF02_ReadDist_wD

Achtung:Falls die Messentfernung zu groß ist, gibt der Block einen unsinnigen Entfernungswert zurück, da er nur maximal 50 µs wartet, bis ein Echo angekommen ist.




• Entfernungsmesswert in cm (Dec)

Modellname: BB_SFR02_SfctnB_noDebug_Test.slxVersion mit Debug printf() Anweisungen: B_SFR02_SfctnB_wDebug_Test.slx

11.2.7 MPU6050 Beschleunigungs-/Drehratensensor auslesen (I²C)

Ausgabe der aktuell gemessenen Beschleunigung und Drehrate jeweils als x, y, und z-Komponen-ten. Zusätzlich Ausgabe des sensorinternen Temperaturmesswertes.S-Function Builder Block Name: BB_MPU6050_ReadAccRota_noD




• Beschleunigungswerte in x, y und z (Dec)

• Drehratenwerte in x, y undz (Dec)

• Temperatur (Dec)Alle Werte als 16 Bit Ganzzahlen in willkürlichen Einheiten (siehe Sensordatenblatt)

Modellname: BB_MPU6050_SFctnB_noDebug_Test.slx


12 Anhang

12.1 Pinbelegung (Quelle [2])Hier ist jeweils die Konfiguration angegeben, bei der alle möglichen Pins der jeweiligen Schnittstel-le (zu Lasten der anderen Schnittstellen) aktiviert sind. Lediglich die Pins der analogen Eingänge können nicht durch andere Schnittstellen belegt werden. Die in Rot und Lila dargestellten Pins kön-nen nicht geändert werden. Siehe hierzu auch [18].


12.2 Das Grove Cape (Version 1) (Quelle [12]) Achtung: Die Buchsenleiste J8 entspricht P9 und die Die Buchsenleiste J9 entspricht P8!


12.3 Das Grove Base Cape (Version 2) (Quelle [38]) Dies ist eine Weiterentwicklung der Version 1 des Grove Capes. Es besitzt ein EEPROM, so dass damit automatisch beim Booten ein vordefiniertes DTO geladen wird. Die I²C-Adresse des EEPROMS ist über Dip-Schalter einstellbar. Die analogen Eingänge werden nicht mehr über einen einfachen Spannungsteiler sondern über einen Verstärker geführt. Die digitalen Ein- und Ausgänge laufen nicht mehr über Klemmdioden sondern über Pegelwandler.


12.4 Linux Dateimanagement mit dem Midnight CommanderWem das Hantieren mit Dateien aus der Linuxkonsole wie in Abschnitt 12.10 beschrieben zu kom-pliziert ist, der kann den „Midnight Commander“ verwenden, der dem Windows Explorer schon etwas näher kommt.

Dazu muss über apt-get mc dieser Dateimanager installiert werden. Damit die „Grafik“ des Midnight Commanders richtig dargestellt wird, muss vorher in Putty noch der Zeichensatz „ISO-8859-1:1998 (Latin-1, West Europe) unter Window > Translation eingestellt werden (siehe Abb. 28).

In der Linuxkonsole wird der Midnight Commander mit mc aufgerufen und öffnet sich wie in Abb.29 dargestellt.

12.5 IDE Cloud9 für die BB Programmierung und für den Filetransfer zwischen BB und PC

Normalerweise wird die Cloud9 IDE so verwendet, dass sich der Server mit allen Quellcodedateien und Bibliotheken im In-ternet in einer „Cloud“ befindet. Mit dem Browser auf dem PC ruft man die Internet-adresse der Cloud9 IDE auf.

Damit wird man ein Client dieses Servers, loggt sich ein und kann dort dann Program-me schreiben, so wie man es mit einer lo-kalen IDE (z.B. Arduino IDE) auch macht.

Der Vorteil hierbei liegt u.a. darin, dass manmit allen internetfähigen Geräten immer aufdie aktuellen Quellcodes zugreift, dass


Abbildung 28: Einstellungen bei Putty, damit imMidnight Commander die Grafiken richtig ange-zeigt werden.

Abbildung 29: Screenshot des Dateimanagers Midnight Comman-der.

Abbildung 30: Verwendung der Cloud9 IDE als Dateimanager des BB Dateisystems.

mehrere Programmierer von beliebigen Orten aus an einem gemeinsamen Projekt arbeiten, dass sich der Cloud Service um die Bereitstellung der Bibliotheken kümmert, und dass man den

Quellcode in der Cloud auf verschiedenen Systemen testen kann.

Im Endeffekt benötigen Sie nur noch einen Computer mit Browser, und um den Rest kümmert sich der Cloudser-vice.

Beim BB wird die Cloud9 IDE jedoch ganz anders ge-nutzt:

Hier befindet sich der Cloud9-Server nicht im Internet sondern lokal auf dem BB. Sie rufen diese IDE auch in Ih-rem Browser auf, jedoch mit der Adresse 192.168.7.2:3000/ide.html und landen dann lokal auf dem BB, wo sich dann unter /var/lib/cloud9 die erzeugten Quellcodedateien befinden. Der BB ist also der Server für die IDE.

In der Cloud9 IDE können Sie sich dann unter FAVOURI-TES die Dateien in Ihrem Home-Verzeichnis auf dem BB anzeigen lassen und diese dann z.B. in das FILE SYS-TEM Ihres Workspaces der Cloud9 IDE kopieren, wie in Abb. 30 dargestellt.

In dem in Abb. 30 dargestellten Fall sind die Beispielpro-gramme also zweimal auf dem BB vorhanden.

Jetzt kann mit der rechten Maustaste aus der IDE eine Datei oder ein Verzeichnis auf den PC heruntergeladen

werden (siehe Abb. 31).

Genauso kann man vom PC eine Datei auf den BB hochla-den (siehe Abb. 32).


Abbildung 32: Übertragen einer Datei vom PC auf den BB als Upload.

Abbildung 31: Übertragen einer Datei vom BB auf den PC als Download.

12.6 Fernzugriff auf die grafische Benutzeroberfläche des BB via VNCHierzu muss man zuerst mit folgenden Befehlen in der Linuxkonsole den VNC-Server auf dem BB starten:

Auf dem PC wird die Software VNC-Viewer installiert. Sie kann kostenlos unter realvn.com/down-load/viewer/ heruntergeladen werden.

Nach dem Start dieses Programms (keine In-stallation erforderlich) muss unter „VNC Server“ die IP-Adresse des BB mit Port 1, also 192.168.7.2:1 eingegeben werden. In einem dernächsten Schritte muss noch das beim Starten des VNC-Server gesetzte Passwort eingegebenwerden.

Anschließend erscheint dann auf dem PC-Bildschirm der Desktop des BB:


root@beaglebone:~# vncserver

You will require a password to access your desktops.

Password:Verify:Would you like to enter a view-only password (y/n)? nxauth: file /root/.Xauthority does not exist

New 'X' desktop is beaglebone:1

Creating default startup script /root/.vnc/xstartupStarting applications specified in /root/.vnc/xstartupLog file is /root/.vnc/beaglebone:1.log

Abbildung 33: Nötige Eingabe der IP-Adresse nach dem Start der Software VNC am PC.

Abbildung 34: Auf dem PC übertragener Desktop des BB.

12.7 Übersicht BB Hardware (Quelle [19])


12.8 Pinkonfiguration (Quelle [19]), siehe auch [18].


12.9 Nano Cheat Sheet [39]


The Nano Text Editor

Introduction

Nano is a text editor suited to working in UNIX. It is not as powerful as PC window-based editors, asit does not rely on the mouse, but still has many useful features.

Most nano commands are invoked by holding down the Ctrl key (that is, the control key), andpressing one of the other keys. In this text, the control key is referred to using ^. For example, ^Xmeans ``hold down the CTRL key and press the x key''. Most of the important commands are listed atthe bottom of your screen.

^G nano help

Starting nano

To edit a file called filename, type nano filename.

In nano, you can insert another file:^R read an existing file into nano (inserted at the current cursor position)

^T opens a browser that allows you to select a file name from a list of files and directories

Navigation

The usual mouse-based point-and-click method is not supported by nano. Use the arrow keys tomove around the page in nano.

Other navigation commands:

^A move to beginning of line

^E move to end of line

^Y move down a page

^V move up a page

^_ move to a specific line (^_^V moves to the top of the file, ^_^Y to the bottom)

^C find out what line the cursor is currently on

^W search for some text.

When searching, you will be prompted for the text to search for. It searches from the current cursorposition, wrapping back up to the top if necessary.

Editing

Insert new text at the current cursor position just by typing the text in.


Delete commands:^D delete character currently under the cursor

BackSpace delete character currently in front of the cursor

^K delete entire line

^\ search for (and replace) a strong of characters

Cut and paste

^K does not delete lines permanently; the most recent set of deletions are stored in a buffer. Theselines may be re-inserted at the current cursor location using Û. This may be used to simulate cut andpaste:

Repeatedly use ^K until all of the text you want to move has been deleted.Move to the line that you want to insert the text at, and use Û.

Note that pressing Û more than once will cause multiple copies to be inserted. This is particularlyuseful if you want to copy text:

Repeatedly use ^K until all of the text you want to copy has been deleted.Press Û immediately to put a copy back in its original location.Move to the line that you want to copy the text to, and use Û.

Saving and Exiting

Ô save contents without exiting (you will be prompted for a file to save to)

^X exit nano (you will be prompted to save your file if you haven't)

^Twhen saving a file, opens a browser that allows you to select a file name from a list of files anddirectories

12.10 Linux Cheat Sheet [40], alternativ [41]


Linux Command Line Cheat Sheetby DaveChild

More nano info at:http://www.nano-editor.org/docs.php

Bash Commands

uname -a Show system and kernel

head -n1 /etc/issue Show distribution

mount Show mounted filesystems

date Show system date

uptime Show uptime

whoami Show your username

man command Show manual for command

Bash Shortcuts

CTRL-c Stop current command

CTRL-z Sleep program

CTRL-a Go to start of line

CTRL-e Go to end of line

CTRL-u Cut from start of line

CTRL-k Cut to end of line

CTRL-r Search history

!! Repeat last command

!abc Run last command starting with abc

!abc:p Print last command starting with abc

!$ Last argument of previous command

!* All arguments of previous command

^abc^123 Run previous command, replacing abcwith 123

Bash Variables

env Show environment variables

echo $NAME Output value of $NAMEvariable

exportNAME =value

Set $NAME to value

$PATH Executable search path

$HOME Home directory

$SHELL Current shell

IO Redirection

command < file Read input of command fromfile

command > file Write output of command to file

command >/dev/null

Discard output of command

command >> file Append output to file

command1 |command2

Pipe output of command1 tocommand2

Directory Operations

pwd Show current directory

mkdir dir Make directory dir

cd dir Change directory to dir

cd .. Go up a directory

ls List files

ls Options

-a Show all (including hidden)

-R Recursive list

-r Reverse order

-t Sort by last modified

-S Sort by file size

-l Long listing format

-1 One file per line

-m Comma-separated output

-Q Quoted output

Search Files

grep patternfiles

Search for pattern in files

grep -i Case insensitive search

grep -r Recursive search

grep -v Inverted search

find /dir/ -name name*

Find files starting with name in dir

find /dir/ -username

Find files owned by name in dir

find /dir/ -mmin num

Find files modifed less than numminutes ago in dir

whereiscommand

Find binary / source / manual forcommand

locate file Find file (quick search of systemindex)

File Operations

touch file1 Create file1

cat file1file2

Concatenate files and output

less file1 View and paginate file1

file file1 Get type of file1

cp file1 file2 Copy file1 to file2

mv file1 file2 Move file1 to file2

rm file1 Delete file1

head file1 Show first 10 lines of file1

tail file1 Show last 10 lines of file1

tail -f file1 Output last lines of file1 as itchanges

Process Management

ps Show snapshot of processes

top Show real time processes

kill pid Kill process with id pid

pkillname

Kill process with name name

killallname

Kill all processes with names beginningname

Nano Shortcuts

Files

Ctrl-R Read file

Ctrl-O Save file

Ctrl-X Close fileCut and Paste

ALT-A Start marking text

CTRL-K Cut marked text or line

CTRL-U Paste textNavigate File

ALT-/ End of file

CTRL-A Beginning of line

CTRL-E End of line

CTRL-C Show line number

CTRL-_ Go to line numberSearch File

CTRL-W Find

ALT-W Find next

CTRL-\ Search and replace

Screen Shortcuts

screen Start a screen session.

screen -r Resume a screen session.

screen -list

Show your current screen sessions.

CTRL-A Activate commands for screen.

CTRL-A c Create a new instance of terminal.

CTRL-A n Go to the next instance of terminal.

CTRL-A p Go to the previous instance of terminal.

CTRL-A " Show current instances of terminals.

CTRL-A A Rename the current instance ofterminal.

File Permissions

chmod 775 file Change mode of file to 775

chmod -R 600folder

Recursively chmod folder to 600

chownuser :group file

Change file owner to user andgroup to group

File Permission Numbers

The first digit is the owner permission, the secondthe group and the third for everyone.

Calculate each of the three permission digits byadding the numeric values of the permissions below.

4 read (r)

2 write (w)

1 execute (x)

Ein Programm ausführen, das nicht im über die gesetzte Umgebungsvariable PATH bekannten Pfad befindet: ./meinProgramm(Dabei steht „.“ für das aktuelle Verzeichnis.)

12.11 Ausgabetext des seriellen Debugschnittstelle während des Bootes bis zum Start des Kernels

U-Boot SPL 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19)bad magic

U-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-git hub_Bootloader-Builder-274

Watchdog enabledI2C: readyDRAM: 512 MiBReset Source: Power-on reset has occurred.MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1Using default environment

Net: <ethaddr> not set. Validating first E-fuse MACcpswHit any key to stop autoboot: 0gpio: pin 53 (gpio 53) value is 1Card did not respond to voltage select!Card did not respond to voltage select!gpio: pin 56 (gpio 56) value is 0gpio: pin 55 (gpio 55) value is 0gpio: pin 54 (gpio 54) value is 0switch to partitions #0, OKmmc1(part 0) is current devicegpio: pin 54 (gpio 54) value is 1Checking for: /uEnv.txt ...Checking for: /boot.scr ...Checking for: /boot/boot.scr ...Checking for: /boot/uEnv.txt ...gpio: pin 55 (gpio 55) value is 11798 bytes read in 16 ms (109.4 KiB/s)Loaded environment from /boot/uEnv.txtChecking if uname_r is set in /boot/uEnv.txt...gpio: pin 56 (gpio 56) value is 1Running uname_boot ...loading /boot/vmlinuz-3.8.13-bone79 ...5644336 bytes read in 328 ms (16.4 MiB/s)loading /boot/dtbs/3.8.13-bone79/am335x-bonegreen.dtb ...26118 bytes read in 24 ms (1 MiB/s)loading /boot/initrd.img-3.8.13-bone79 ...2862929 bytes read in 175 ms (15.6 MiB/s)debug: [console=ttyO0,115200n8 root=UUID=d273b6b1-534e-4818-8b38-69ddf0e96000 ro rootfstype=ext4 rootwait coherent_pool=1M quiet init=/lib/systemd/systemd cape_ universal=enable] ...debug: [bootz 0x82000000 0x88080000:2baf51 0x88000000] ...Kernel image @ 0x82000000 [ 0x000000 - 0x562030 ]## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8fd45000, end 8fffff51 ... OK Loading Device Tree to 8fd3b000, end 8fd44605 ... OK

Starting kernel ...


12.12 Matlabquellcode des Simulink Matlab Function Blocks Sen-sorFromFile

12.13 Paketmanagement über aptNachfolgend sind die wichtigsten Befehle für das Paketmanagement via apt aufgeführt. Der Platz-halter MeinPaket steht für eine Softwarepaket wie z.B. nano.

Paket installieren apt-get install MeinPaket

Index Paketmanager aktualisieren apt-get update

Ist MeinPaket installiert? dpkg-query -1 | grep MeinPaket

Ist ein Paket mit MeinPaket verfügbar? apt-cache search MeinPaket

Das Paket MeinPaket entfernen apt-get remove MeinPaket

Alte Pakete im Speicher entfernen apt-get clean


function Output = SensorFromFile(Trigger)%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Funktion zum einlesen eines Ultraschallsensors am BeagleBone oder %% Raspberry Pi mit parallel laufendem Script %% %% Code by Anian Bühler %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% To stop SensorScript on Target use ssh with "ps -efa | grep SCRIPTNAME" to get PID% then use "kill PID (eg. 1234)"

persistent localValue;if isempty(localValue) localValue = -1;end

%Initflag anlegen -> Setupcode soll nur einmal ausgeführt werdenpersistent initflag;if strcmp(coder.target, 'rtw') if isempty(initflag) initflag = 1; %SETUP %****** coder.ceval('startSensor'); % Starte Sensor-Script

%****************************************************************** else %MAIN %******

if Trigger coder.ceval('readData'); localValue = coder.ceval('getData'); end

%***************************************************************** end %SIMULATION%***********else %ToDo in simulationend

Output = localValue;

Hilfe zu apt aufrufen apt-get help

12.14 GlossarToolchain:Hierunter versteht man die „Kette aus Werkzeugen“, die benötigt wird, um ein Programm für ein eingebettetes System zu schreiben, zu kompilieren, auf das System zu übertragen und dort zu de-buggen.

Cross Compiler:Der Compiler erstellt aus einem Quellcode ein ausführbares Programm. Dies geschieht meistens auf einem PC, wobei das ausführbare Programm ebenfalls für eine PC gedacht ist. Im Praktikum wird auf dem Windows-PC der Quellcode erstellt, das ausführbare Programm muss aber nicht für Windows sondern für das Linuxbetriebssystem des BB kompiliert werden.

Target:Das eingebettete System (hier BB), für das mittels Matlab/Simulink ein ausführbares Programm er-zeugt wird.

Host Computer:Der PC, an dem der BB via USB oder Ethernet angeschlossen ist, wie es beispielsweise bei der Programmierung via Simulink der Fall ist.

Client Computer:Ein Computer, der eine Dienstleistung des Host Computers in Anspruch nimmt. Im Fall der IDE Cloud9 ist der Windows-PC über seinen Browser ein Client des Host Computers BB, auf dem ein Webserver läuft.

Pfad:Auch PATH genannt. Eine Liste von Verzeichnissen, in denen das Betriebssystem nach der aus-führbaren Programmdatei sucht, nachdem man deren Namen (ohne „./“) in die Shell eingegeben hat.

Kernel:Damit ist das eigentliche Linuxbetriebssystem gemeint. Der Kernel ist ein C-Programm, das für die entsprechende Plattform wie den BB kompiliert wird und dann als Image auf die Plattform übertra-gen wird. Diese ausführbare Datei findet sich unter /boot.

12.15 Verwendete AbkürzungenSRP Sensor- und Regelungssystemepraktikum

BB BeagleBone

BBB BeagleBone Black

BBG BeagleBone Green

µC Mikrocontroller

LES Linux Embedded System

PRU Programmable Real-Time Unit

CMD Windows Command Shell

SSH Sichere Kommunikation über Ethernet. Wird von Software Putty verwendet, um Linuxkonsole auf PC für BB anzuzeigen.

IDE Entwicklungsumgebung für das Programmieren (z.B. Cloud9, Eclipse, Arduino und im weiteren Sinne auch Matlab/Simulink)


DHCP Dynamic Host Configuration Protocol

APT Advanced Packaging Tool

GPIO General Purpose Input Output, in vielen Publikationen nur auf binäre I/Os bezogen

DTO Device Tree Overlay (zur Laufzeit: Schema der Pin-Zuordnung auf die Schnittstellen)

I/Os Ein-/Ausgabeschnittstellen

DT Device Tree (beim Bootvorgang: Schema der Pin-Zuordnung auf die Schnittstellen)

VNC Virtual Network Computing: Bildschirminhalt des Servers (Linux Benutzeroberfläche des BB) wird auf dem Client (PC) angezeigt.

BASH Bourne Again SHell. Das auf Linuxsystemen am häufigsten verwendete Shellpro-gramm.

12.16 Kommunikationsmöglichkeiten mit dem BBUm den BB zu programmieren oder für die Fehlersuche muss man mit ihm via Tastatur und Bildschirm kommunizieren. Dafür gibt es eine Reihe verschiedener Möglichkeiten, die in der nachfolgenden Tabelle zusammengefasst sind.

An-schlussart

Linux Benut-zeroberfläche

Kommando-zeilenfenster (Shell)

Internetsei-ten auf dem BB

Cloud9 IDE

Internetzu-gang

Bemer-kung

Tastatur und Monitor direkt

USB bzw. HDMI

Direkt Über Linux Benutzeroberfläche

Über Linux-Browser

Über Li-nux-Browser

Ja, wenn Verbindung über Netz-werkbuchse

Geht nur bei BBB

Ethernet über USB

Micro/Mini USB-Buch-se Unter-seite BBG/BBB

Auf dem PC über TCP/IP mit VNC-Soft-ware am PC und VNC-Ser-ver am BB

Auf dem PC über SSH-Pro-tokoll z.B. mit Putty am PC und Bash am BB

Über den PC-Browser

Über den PC-Browser

Ja, wenn Verbindung über Netz-werkbuchseoder mit Trick

Stromver-sorgung über USB

Ethernet Netzwerk-buchse

siehe oben siehe oben siehe oben siehe oben

Ja, wenn Internetgateway im sel-ben Netz-werk

Zusätzlich Stromver-sorgung nö-tig, PC, BB und Inter-netgateway im selben Netzwerk

Seriell Serial De-bug Pins auf Ober-seite

Nein Wie oben aber ohne SSH

Nein Nein Nein Einzige Möglich-keitn um Bootmel-dungen zu empfangen


Quellenverzeichnis1: DFRobot Pirate-4WD-Plattform: dfrobot.com. Letzter Aufruf 06/2016.

2: BeagleBoard.org Foundation: beagleboard.org. Letzter Aufruf 01/2106.

3: Molloy, D.: Exploring Beaglebone. Wiley, Indianapolis, 2015.

4: Yoder, M. A. et al.: BeagleBone Cookbook. O'Reilly, Sebastopol, 2015.

5: Santos, R. et al.: BeagleBone for Dummies. JohnWiley, Hoboken, 2015.

6: Adafruit Inc.: learn.adafruit.com/category/beaglebone. Letzter Aufruf 01/2016.

7: Hamilton, C. A.: BeagleBone Black Cookbook. Packt Publishing, Birmingham, 2015.

8: Dai, X et al.: Rapid BealeBoard Prototyping with MATLAB and Simulink. Packt Publishing, Birmingham, 2013.

9: Kahawita, R. D.: Development of an ARM/Linux Based Testbed for Rapid Control System Prototyping via Matlab/Simulink. Masterthesis, Polytechnique Montreal, 2014.

10: Hersteller Seeed, China: seeedstudio.com/wiki/Beaglebone_green. Letzter Aufruf 02/2016.

11: Distributor EXP GmbH, Saarbrücken: exp-tech.de. Letzter Aufruf 01/2016.

12: Hersteller Seeed, China: seeed.cc. Letzter Aufruf 01/2016.

13: Bartmann, Erik: Die elektronische Welt mit Raspberry Pi entdecken. O'Reilly, Sebastopol, 2016.

14: Bartmann, Erik: Die elektronische Welt mit Arduino entdecken. O'Reilly, Sebastopol, 2014.

15: Beaglebone Black Boot explained by Alexander Holler: ahsoftware.de/Beaglebone_Black_Boot_explained.svg. Letzter Aufruf 06/2016.

16: EBC Exercise 21a Boot Sequence: elinux.org/EBC_Exercise_21a_Boot_Sequence. Letzter Aufruf 06/2016.

17: Booting up a BeagleBone Black: diydrones.com/profiles/blogs/booting-up-a-beaglebone-black. Letzter Aufruf 06/2016.

18: Beagleboard: Cape Expansion Headers: http://elinux.org/Beagleboard:Cape_Expansion_Headers. Letzter Aufruf 06/2016.

19: Exploring Beaglebone: exploringbeaglebone.com. Letzter Aufruf 04/2016.

20: BeagleBone Black Collars: www.doctormonk.com/2014/01/beaglebone-black-collars. Letzter Aufruf 06/2016.

21: BeagleBone and the 3.8 Kernel: elinux.org/BeagleBone_and_the_3.8_Kernel. Letzter Aufruf 06/2016.

22: Capemanager: elinux.org/Capemgr. Letzter Aufruf 04/2016.

23: BeagleBone Device Tree: learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview. Letzter Aufruf 01/2016.

24: Matlab/Simulink Support BB for Device Tree Overlay: de.mathworks.com/help/supportpkg/beaglebone/examples/pin-muxing.html. Letzter Aufruf 02/2016.

25: Using BeagleBone Black GPIOs: www.armhf.com/using-beaglebone-black-gpios. Letzter Aufruf 06/2016.

26: Device Tree Usage: http://elinux.org/Device_Tree_Usage. Letzter Aufruf 06/2016.

27: Beagle Bone Black Device-Tree Overlay Generator: kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator. Letzter Aufruf 06/2016.

28: About The Device Tree: ofitselfso.com/BeagleNotes/AboutTheDeviceTree.pdf. Letzter Aufruf 05/2016.

29: Klein, B.: Einführung in Python 3: Für Ein- und Umsteiger. Hanser Verlag, München, 2014.

30: Adafruit BMP Python Library: learn.adafruit.com/using-the-bmp085-with-raspberry-pi/using-the-adafruit-


bmp085-python-library. Letzter Aufruf 01/2016.

31: MPU6050 Python ohne Bibliothek.: andrewdai.co/beaglecar/sensors-and-interfaces.html. Letzter Aufruf 01/2016.

32: BMP180 Python ohne Bibliothek.: gtkdb.de/index_36_2473.html. Letzter Aufruf 01/2016.

33: Matlab BB Remote Linux Commands: de.mathworks.com/help/supportpkg/beagleboard/examples/remote-execution-of-linux-commands.html. Letzter Aufruf 03/2016.

34: Matlab/Simulink Support BB: mathworks.com/help/supportpkg/beaglebone/ug/install-target-for-beaglebone-black-hardware.html. Letzter Aufruf 01/2016.

35: Beaglebone Getting Started.: de.mathworks.com/help/supportpkg/beaglebone/examples/getting-started-with-beaglebone-black-support-package.html. Letzter Aufruf 01/2016.

36: Matlab Function Block: de.mathworks.com/help/simulink/ug/incorporate-c-code-using-a-matlab-function-block.html. Letzter Aufruf 02/2016.

37: Matlab/Simulink BB Overrun Detection: de.mathworks.com/help/supportpkg/beagleboard/ug/detect-and-fix-overruns-on-beagleboard-hardware.html. Letzter Aufruf 03/2016.

38: Grove Base Cape for BeagleBone v2: www.seeedstudio.com/wiki/Grove_Base_Cape_for_BeagleBone_v2. Letzter Aufruf 07/2016.

39: The Nano Text Editor: mintaka.sdsu.edu/reu/nano.html. Letzter Aufruf 01/2016.

40: Dave Child: Linux Cheat Sheet: cheatography.com/davechild/cheat-sheets/linux-command-line/. Letzter Aufruf 01/2016.

41: GNU/Linux most wanted, summary of most useful commands: free-electrons.com/doc/training/linux-kernel/command_memento.pdf . Letzter Aufruf 06/2016.


Projekt Sensor- und Regelungssysteme€¦ · 8.5 Beispielprogramm: Sensordaten via I²C von einem...

Documents

Transcript of Projekt Sensor- und Regelungssysteme€¦ · 8.5 Beispielprogramm: Sensordaten via I²C von einem...