Projekt Sensor- und Regelungssysteme...Embedded Coder, MATLAB Coder, Simulink Coder und mit folgenden Add-Ons: Embedded Coder Package for ARM Cortex-A Processors, Embedded Coder Support

Projekt Sensor- und Regelungssysteme

InhaltsverzeichnisVerwendete Betriebssysteme und Softwareversionen:.....................................................................................2 0 Lernziele Projekt Sensor- und Regelungssysteme (SRP)............................................................................3 1 Einleitung..................................................................................................................................................... 4 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 Kommunikation BB und PC................................................................................................................. 9

4.1.1 Kommunikation vía USB............................................................................................................10 4.2 Kommunikation via Ethernet über Switch im selben Netzwerk..........................................................12

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

4.3 Kommunikation via Ethernet über „Cross Over“-Kabel direkt mit dem PC.........................................13 4.3.1 Statische IP-Adresse am BB einstellen......................................................................................13 4.3.2 Statische IP-Adresse für den zweiten Netzwerkadapter am PC einstellen................................14

4.4 Kommunikation via WLAN................................................................................................................. 15 4.4.1 Mit dem BB in ein vorhandenes WLAN einwählen.....................................................................15

4.5 Bekannte Probleme:..........................................................................................................................19 5 Linuxbetriebssystem auf dem BeagleBone................................................................................................19

5.1 Das Betriebssystemimage und die SD-Karte.....................................................................................19 5.1.1 Kopieren, Sichern, Wiederherstellen und Klonen von SD-Karten Images.................................20 5.1.2 SD Karte als Massenspeicher versus eMMC.............................................................................20

5.2 Ermitteln der installierten Linuxdistribution.........................................................................................21 5.2.1 Installation einer Linuxdistribution auf dem BB..........................................................................21 5.2.2 Installation von Linuxsoftware auf dem BB................................................................................21

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

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

7.2.1 Anzeigen des aktuell geladenen DTOs......................................................................................28 7.2.2 Manuelles Laden und Entladen eines DTO aus der Linuxkommandozeile mit Hilfe des Capemanagers..................................................................................................................................... 28 7.2.3 Automatisches Laden eines oder mehrerer DTOs beim Bootvorgang.......................................29 7.2.4 Erstellen eines DTO...................................................................................................................29 7.2.5 Das Standard DTO für die Projektarbeit....................................................................................30

7.3 Das SysFS......................................................................................................................................... 30 7.4 Die I²C-Busse.................................................................................................................................... 31 7.5 Die SPI-Schnittstelle.......................................................................................................................... 32 7.6 Hardwarespezifisches........................................................................................................................ 32 7.7 Bei MATLAB/Simulink zu beachten....................................................................................................33

8 Einbinden von Sensoren und Aktoren über Pythonskripte.........................................................................33 8.1 Installation notwendiger Phytonbibliotheken......................................................................................34 8.2 Beispielprogramm: LED blinken lassen.............................................................................................36 8.3 Analogspannung auslesen (ADC)......................................................................................................36

Prof. Dr. S. Mack Projekt Sensorsysteme BeagleBone Vers. 6, 12.3.18 IP 192.168.7.2 Seite 1 von 74

8.4 Beispielprogramm: Analogen Ultraschallsensor HC-SR04 auslesen.................................................36 8.5 Beispielprogramm: Sensordaten via I²C von einem MPU6050 IMU-Sensor „zu Fuß“ auslesen........37 8.6 Beispielprogramm: Sensordaten via I²C von einem BMP180 Drucksensor mit „Black Box“ Bibliothek auslesen.................................................................................................................................................... 38

9 Einbinden von Sensoren und Aktoren über C-Programme........................................................................40 10 Vorbereitung der MATLAB/Simulink-Umgebung und des Targets BBG...................................................40

10.1 Simulink-Beispielprogramm beaglebone_gettingstarted..................................................................43 10.2 Bekannte Probleme:........................................................................................................................ 43

11 Programmieren des BB über Simulink.....................................................................................................44 11.1 Wieso macht der Einsatz von Simulink hier Sinn?...........................................................................44 11.2 Ausführen eines Simulinkmodells auf dem BB.................................................................................47 11.3 Simulink-Beispielmodelle.................................................................................................................47

11.3.1 Beispielmodell: Externe LED blinken lassen............................................................................47 11.3.2 Beispielmodell: Analogspannung auslesen (ADC)...................................................................47

11.4 Neue Sensoren mit über digitale Schnittstellen ansteuern...............................................................48 11.5 Kontrolle der Ausführungsgeschwindigkeit des Programms auf dem BB.........................................48 11.6 Bekannte Probleme.......................................................................................................................... 49

12 Verwendung selbst erstellter S-Function Blöcke......................................................................................49 12.1 Debuggen eines S-Function Builder Blocks.....................................................................................50 12.2 Im Praktikum verfügbare S-Function Builder Blöcke und Beispielmodelle.......................................51

12.2.1 I²C Bus Lesen..........................................................................................................................51 12.2.2 I²C Bus Schreiben....................................................................................................................51 12.2.3 GPIO Lesen............................................................................................................................. 52 12.2.4 GPIO Schreiben....................................................................................................................... 52 12.2.5 HCM5883L AMR Magnetfeldsensor auslesen (I²C).................................................................52 12.2.6 SRF02 Ultraschallsensor auslesen (I²C)..................................................................................52 12.2.7 MPU6050 Beschleunigungs-/Drehratensensor auslesen (I²C)................................................53 12.2.8 TOF-Sensor VL53L0X auslesen (I²C)......................................................................................53 12.2.9 Farbsensor TCS34725 auslesen (I²C).....................................................................................53 12.2.10 Maussensor AADNS3080 auslesen (SPI)..............................................................................53 12.2.11 Gestensensor APDS-9960 (I²C).............................................................................................54 12.2.12 Besipielmodell Modellbauservo ansteuern (PWM)................................................................54

12.3 Bekannte Probleme.........................................................................................................................54 13 Daten in die Cloud an ThingSpeak senden und dort verarbeiten.............................................................54 14 Anhang..................................................................................................................................................... 56

14.1 Pinbelegung (Quelle [3])..................................................................................................................56 14.2 Das Grove Cape Version 1 (schwarz) (Quelle [12]).........................................................................57 14.3 Das Grove Base Cape Version 2 (grün) (Quelle [42])......................................................................58 14.4 IDE Cloud9 für die BB Programmierung und für den Filetransfer zwischen BB und PC..................59 14.5 Glossar............................................................................................................................................ 60 14.6 Übersicht BB Hardware (Quelle [22])...............................................................................................61 14.7 Pinkonfiguration (Quelle [22]), siehe auch [21]................................................................................62 14.8 Nano Cheat Sheet [43].................................................................................................................... 64 14.9 Linux Cheat Sheet [44], alternativ [45].............................................................................................66 14.10 Ausgabetext des seriellen Debugschnittstelle während des Bootes bis zum Start des Kernels.....67 14.11 Paketmanagement über apt...........................................................................................................67 14.12 Umgang mit Linuximages auf SD-Karten.......................................................................................68

14.12.1 Inhalt des eMMC komplett auf SD-Karte sichern (automatisch nach Booten auf entsprechendpräparierter SD-Karte):......................................................................................................................... 68 14.12.2 Partition auf SD-Karte vergrößern.........................................................................................68

14.13 Linuxdatei /etc/network/interfaces..................................................................................................70 14.14 Verwendete Abkürzungen..............................................................................................................71 14.15 Kommunikationsmöglichkeiten mit dem BB...................................................................................71 14.16 Fachbücher zum BB......................................................................................................................72

Quellenverzeichnis......................................................................................................................................... 73

Verwendete Betriebssysteme und Softwareversionen:

Windows 7, 32 oder 64 Bit mit MATLAB/Simulink R2015a, R2015aSP1 (8.5.1) oder R2015b.Oder Windows 10 mit MATLAB/Simulink R2017a oder 2017b. Jeweils mit Toolboxes Simulink,


Embedded Coder, MATLAB Coder, Simulink Coder und mit folgenden Add-Ons: Embedded Coder Package for ARM Cortex-A Processors, Embedded Coder Support Package for BeagleBone Black Hardware, Support for MinGW-w64 Compiler, MATLAB Support Package for BeagleBone Black Hardware.

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

0 Lernziele Projekt Sensor- und Regelungssysteme (SRP)• 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 konventionellen 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.

• Praxiserfahrung mit IP-Kommunikation.

• Aufbau einer Fernwartung über das Internet indem Daten des Robotersystems in eine Clouddatenbank hochgeladen und dort über einen Webservice analysiert werden.


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 ATmega328 µ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“), weshalber sich für zeit- und sicherheitskritische 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-

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.


teten Prozess warten.

Den BB zeichnet aber noch aus, dass er zusätzlich zu seinem Prozessor zwei „Programmable Re-al-Time Units (PRU)“ sozusagen als 32 bit Koprozessoren mit 200 MHz Taktrate besitzt, die für die Ein-/Ausgabepins zuständig sind:Die PRU des BB sind auf dem SOC Chip zusätzlich integrierte µC, die unabhängig von der Pro-zessorauslastung die I/Os bedienen. Ein ähnliches Konzept besitzt übrigens auch der Arduino YUN, welcher aus Kompatibilitätsgründen jedoch nur einen leistungsschwachen ATmega328 µC separat 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 modellbasiert programmiert, wobei derletztendliche C-Code automatisch erzeugt, kompiliert und aufden BB übertragen wird.

2 RoboterhardwareAls Roboterplattform wird das „Pirate-4WD“-Fahrzeug vonDFRobot verwendet [1]. Es besitzt vier Gleichstromantriebemit Getriebe. Die beiden Räder auf der linken und rechtenSeite werden jeweils gemeinsam angesteuert. Alle Räder kön-nen bei Bedarf mit Drehencodern ausgestattet werden. DerBB steuert mittels PWM-Signale über einen H-Brücken-Motor-treiber die Motoren an. Die Energieversorgung geschieht übereine USB-Powerbank.

Die Ansteuerung der Motortreiber (H-Brücke) ist sehr gut imBuch von D. Molloy [2], Kapitel 9 erklärt. Die Platine kann üb-rigens mit einem Shuntwiderstand bestückt werden, mit dender aktuelle Motorstrom über einen ADC-Eingang des BB er-fasst wird.

Achtung: Bei Lastspitzen durch den Motortreiber kann dieVersorgungsspannung des BB so stark einbrechen, das die-ser einen Reset durchführt. Die hier gezeigte Lösung mit zwei getrennten Powerbanks 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 [3]. Als Fachliteratur wird an erster Stelle auf [2], 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 [2] 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 Kapitel 14.6 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.Verwenden Sie daher als Eingänge ausschließlich die Grove-Stecker!

Im SRP wird das „Grove Cape“ des Herstellers Seeed [12] verwendet. Zusammen mit den speziell dafür konfektionierten „Grove“-Bauteilen von Seeed ist ein falsches Anschließen nahezu ausge-schlossen. Hiervon gib es die Version 1 (schwarz) und die Version 2 (grün). Verwenden Sie wenn möglich die neuere Version 2 (grün).

Auf dem Grove Cape sind die UART-1/2-, I²C-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 Versorgungsspannung VCC auf 3,3 V oder 5 V eingestellt werden.

Für die analogen Eingänge „Analog Input“ ist ein Verstärker nachgeschaltet, der die Eingangs-spannung von 5 V auf 1,8 V reduziert, damit selbst bei einer 5 V Eingangsspannung der ADC nichtzerstört wird. Das heißt aber auch, dass ein 3,3 V Signal auf den ADC diesen nicht voll aussteuert (ca. 1200 mV statt FSR = 1800 mV ADC Messwert).

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

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


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

Entsprechende Pins der Buchsenleiste am BB

Analog Input P9_37-40, VCC, GND

I2C2 (Cape) (Hub für 4 Slaves) P9_19, P9_20, VCC, GND

UART/Digital links (UART1) (Cape) P9_26, P9_24, VCC, GND

UART/Digital rechts (UART2) (Cape) P9_22, P9_21, VCC, GND

GPIO 51 (Cape) im SRP PWM P9_16, NC, VCC, GND

GPIO 50 (Cape) im SRP PWM P9_14, P9_16, VCC, GND

GPIO 117 (Cape) P9_25, P9_14, VCC, GND

GPIO 115 (Cape) P9_27, P9_25, VCC, GND

Untere Buchse BBG Selbe Belegung wie I2C2 (Cape)

Obere Buchse BBG Selbe Belegung wie UART2 (Cape)

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 wie die Version 2 des Grove Capes über ein EPROM dem Linuxbetriebssystem ihre Identität mitteilen können, woraufhin automatisch der passende „Device Tree Overlay“ (DTO) geladen werden kann. Hierfür sowie für das manuelle Laden wird das Programm „Device Tree Ma-nager“ verwendet. Näheres hierzu finden Sie im Abschnitt 14.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 [3] 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.

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


Sehr praktisch ist bei Python der Interpreter: Ähnlich wie bei MATLAB kann man in der Komman-dozeile der „Python Shell“ einzelne Programmbefehle nacheinander eingeben und so testen, bevorman den Quellcode in eine Datei schreibt und dann als Ganzes ausführt.

root@beaglebone:~# pythonPython 2.7.3 (default, Mar 14 2014, 17:55:54) [GCC 4.6.3] on linux2Type "help", "copyright", "credits" or "license" for more information.>>> import Adafruit_BBIO.PWM as PWM>>> PWM.start("P9_14",12,50,0)>>> PWM.set_duty_cycle("P9_14",3)>>>root@beaglebone:~#

Im Beispiel oben wird die Python Shell mit dem Befehl python aufgerufen. Nach dem Import der PWM-Bibliothek wird ein PWM-Signal mit 12 % Duty Cycle und 50 Hz initialisiert, welches in der folgenden Zeile auf 3 % Duty Cycle reduziert wird. Die Python Shell verlässt man mit Strg + q. Hiermit wird z.B. ein Modellbauservo angesteuert.

Achtung: Es gibt leider zwei verschiedene Pythonversionen 2.7 und 3.x, die sozusagen in zwei Paralleluniversen existieren. Auf dem BB wird Python 2.7 verwendet.

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 sie-he Abschnitt 14.4.

4 Die Kommandozeile nennt man auch „Shell“. Das Programm auf dem BB, welches die Kommandos ver-arbeitet wird „Bash“ genannt. Lassen Sie sich nicht irritieren, wenn diese beiden Begriffe oft gleichbedeu-tend verwendet werden. Das hierzu gehörende Protokoll heißt „SSH“.


b) Der BB besitzt eine eigene Benutzeroberfläche. Auf diese kann man auch per Fernzugriff vom PC aus via VNC (Virtual Network Computing) zugreifen. Dafür muss auf dem BB eine VNC-Server gestartet und auf dem PC ein VNC-Viewer installiert werden. Näheres siehe [2].

Egal, für welche Zugriffsvariante man sich entscheidet, zuerst muss eine Kommunikation zwischendem BB und dem PC aufgebaut werden. Dafür gibt es unterschiedliche Wege (siehe Abb. 1).

4.1 Kommunikation BB und PC

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 (entweder im selben Netzwerk wie der PC oder lokal über ein „Coss Over“-Kabel)

4. WLAN-Schnittstelle

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 den BB am besten via USB mit dem PC. Damit ist auch gleichzeitig die Spannungsversorgung gewährleistet, und man braucht kein separates Netz-teil. Bei erstmaligen Anschließen eines BB an einen PC wird der BB zuerst nur als Massenspeicherähnlich einem USB-Stick erkannt, siehe Abb. 2.


Abbildung 1: Übersicht der im Praktikum verwendeten Kommunikationsarten und Stromversorgungen.

Parallel zu USB kann der BB sich auch via Ethernetschnittstelle z.B. in das Hochschulnetzwerk einbuchen. Dann kann man die USB-Verbindung auf die Stromversorgung reduzieren und diese durch eine USB-Powerbank ersetzen.

Hat man keinen Zugriff auf den Router des Netzwerks (wie beim Hochschulnetzwerk), dann kann es schwierig sein, ohne zusätzliche USB-Kommunikation die IP-Adresse des BB herauszufinden.

Nutzt man die USB-Schnittstelle nur zur Stormversorgung über eine Powerbank und hat keinen Routerzugriff, ist es daher besser, eine direkte „Cross Over“-Ethernetverbindung mit dem PC her-zustellen.

Bei einer mobilen Stromversorgung bietet sich auch eine WLAN-Kommunikation an. Jedoch ist diese im Praktikum mit vielen WLAN-Teilnehmern erheblich langsamer und instabiler als eine Ethernetverbindung, was sich besonders im „External Mode“ von Simulink bemerkbar macht.

Tipp:Für die Einarbeitung am BB ist ist die USB-Verbindung die beste Option.

Für den mobilen Einsatz am Roboter ist der USB-Anschluss schon durch die Power Bank belegt. Daher ist hier die „Cross Over“-Ethernetschnitt-stelle optimal.

Eine WLAN-Kommunikation sollte nur verwendet werden, wenn eine drahtgebundene Kommunika-tion nicht möglich ist.

4.1.1 Kommunikation vía USB

Die Kommunikation geschieht hier nicht wie bei einem normalen USB-Gerät sondern über eine durch die USB-Schnittstelle emulierte Ether-netschnittstelle. Daher muss noch ein entspre-chender Treiber 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. Aufdieser Seite befinden sich der je nach PC-Be-triebssystem zu installierende Treiber.

Nach der Installation des Treibers befindet sich der BB im Netzwerk des PCs unter der IP-Adres-se 192.168.7.2.

Eine Internetverbindung besteht jedoch nicht automatisch, da die im PC emulierte Ethernetschnitt-stelle (siehe Bild 4) mit einem separaten Netzwerk 192.168.7 verbunden ist.


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

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

Gibt man nun die Adresse 192.168.7.2 des BB in die Adresszeile des Browsers ein, dann wird diebeagleboard.org-Seite angezeigt.

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 mitdem BB vertraut zu machen, und via BoneScript einzelneFunktionen des BB zu testen.

Über die Adresse 192.168.7.2 kann man sich jetzt auchvia SSH-Protokoll5 auf dem BB in sein Linux-Betriebssys-tem einloggen (Benutzername root6, kein Passwort nötig).Dafür verwendet man als Terminalprogramm die Software Putty, welches eine Linuxkonsole öffnet (Alternativ kann

dies auch in Cloud9 machen.) Einstellungen hierfür siehe Abbildung3.

Damit man via Putty auf den BB zu-greifen kann, muss dort ein Dienstpro-gramm laufen: Ein solches Programm nennt man „Shell“. Im speziellen Fall hier wird die Shell mit dem Namen „Bash“ verwendet. Die nachfolgend dargestellten Linuxbefehle werden in

das Kommandofenster von Putty eingegeben (Abb. 5).

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 wie man es bei einem Arduino Uno macht. Da beim BB ein Be-triebssystem mit im Spiel ist, sollte man dieses wie bei einem PC vor dem Trennen herunterfahren.Dies geschieht durch kurzes Drücken der „POWER“ Taste am BB (Taster direkt neben dem Ether-netanschluss).

Falls das Ausschalten über die Power-Taste nicht funktioniert, kann man auch im Terminalpro-gramm den Befehl shutdown -h now verwenden. Durch langes Drücken (>8 s) der POWER-Tastewird 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.Alternativ kann er auch via USB die Internetverbindung des PCs (z.B. über das Hochschulnetz-werk) mitbenutzen: Dazu ist etwas Konfigurationsarbeit nötig, die im Buch von D. Molloy im Kapitel2 (S. 28) detailliert beschrieben ist [2].

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

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 4: Anzeige der virtuellen Ether-netschnittstelle via USB in "Netzwerkver-bindungen" unter Windows.

Abbildung 5: Kommunikation zwischen dem Programm Putty auf dem PC und der Shell auf dem BB.

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

4.2 Kommunikation via Ethernet über Switch im selben NetzwerkAlternativ (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 emulierteEthernetschnittstelle.

Der BB muss zuerst extern mit Spannung versorgt werden, was z.B. über eine Power Bank oder über ein USB-Ladegerät inkl. La-dekabel am USB-Anschluss ge-schehen kann. (Der USB-An-schluss ist in diesem Fall eine rei-ne Stromversorgungsschnittstel-

le!)

Dann wird der BB mit einem Patchkabel über einen Switch mit dem Hochschulnetzwerk verbunden, damit sich im selben Netzwerk wie der PC befindet. Der BB erhält vom Hochschulnetz anschließend eine freie IP-Adresse zugewiesen (was als „DHCP“ bezeichnet wird).

Achtung:Je nach Einstellungen des Routers (beim Hochschulnetzwerk auf jeden Fall) erhält der BB jedes Mal eine neue IP-Adresse, wenn er sich z.B.nach einem Reboot erneut im Netzwerkeinbucht.

4.2.1 Ermitteln der IP-Adresse des BB

Welche Adresse IP-Adresse der BB erhaltenhat, kann man am PC über den Befehl pingbeaglebone erfahren (siehe Abb. 6).Alternativ kann man in der Windows CommandShell (CMD/Eingabeaufforderung) auch den Be-fehl arp -a eingeben.

Falls man die MAC-Adresse des BB kennt, kannman dann dessen IP-Adresse ablesen (sieheAbb. 7).

Falls keine dieser Methoden funktionieren, dannwird 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. 8).

Dann erscheint zusätzlich zur IP-Adresse des USB-Ethernetkonverters 192.168.7.2 die vom Switch zugewiesene weitere IP-Adresse im Terminalfenster.

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


Abbildung 7: Ermitteln der IP-Adresse des BB über den Be-fehl arp -a im Widows Command Prompt.

Abbildung 6: Ermitteln der IP-Adresse des BB über den Befehl ping in der Windows Eingabeaufforderung.

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 ein-deutigen Hostname geben:

Dazu loggt man sich als root ein undverwendet den Befehl echo 'xxx' >

/ etc/hostname mit „xxx“ als neuen Hostname. Danach muss man in der Datei /etc/hosts in der Zeile mit derHostadresse 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, siehe Ab-schnitt 14.8.

Ob der BB Verbindung zum Internet hat, kann über den Linuxbefehl ping

www.google.com geschehen. 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.

4.3 Kommunikation via Ethernet über „Cross Over“-Kabel direkt mit dem PC

Im einem großen Netzwerk wie dem Hochschulnetzwerk ist es nicht immer einfach, seinen eige-nen BB ausfindig zu machen, dessen IP-Adresse man nicht kennt.

Besteht gleichzeitig eine USB-Kommunikation, dann kann man darüber die IP-Adresse herausfin-den. Wird der BB jedoch über eine USB-Powerbank versorgt wie auf dem Roboterfahrzeug, dann kann dessen IP-Adresse ohne Zugriff auf den Router nur geraten werden ;-)

In diesem Fall ist es besser eine lokale Ethernetverbindung zwischen dem PC und dem BB herzu-stellen. Damit dabei der Zugang des PCs zum Hochschulnetzwerk/Internet bestehen bleibt, wird hierfür eine separate Netzwerkkarte verwendet.

Eine solche direkte Verbindung zwischen zwei Computer ohne Netzwerk/Router nennt man „CrossOver“-Verbindung, da hierfür früher spezielle Patchkabel verwendet werden mussten.

Um eine solche Verbindung zu etablieren, müssen sowohl der BB als auch die Netzwerkkarte des PCs intern feste IP-Adressen erhalten, die bis auf die drei letzten Ziffern übereinstimmen.

4.3.1 Statische IP-Adresse am BB einstellen

Hierfür muss mit dem editor nano die Datei /etc/network/interfaces wie folgt geändert werden:

...# The primary network interface#auto eth0#iface eth0 inet dhcp# Example to keep MAC address between reboots#hwaddress ether DE:AD:BE:EF:CA:FE


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

...# Eintrag für statische IP-Adresse Netzwerkanschlussallow-hotplug eth0iface eth0 inet static address 192.168.5.100 netmask 255.255.255.0 gateway 192.168.5.1

Die DHCT Funktion der Ethernetschnittstelle wird also deaktiviert, und dem BB wird hier als Bei-spiel die statische IP-Adresse 192.168.5.100 zugeweisen.

Nach dem Speichern der Datei interfaces werden diese neuen Einstellung nach einem Reboot ak-tiv.

Ob diese Prozedur für die Schnittstelle eth0 wirklich funktioniert hat, testet man am besten via USB-Verbindung mit dem Befehl ifconfig.

eth0 Link encap:Ethernet HWaddr 78:a5:04:ef:98:58 inet addr:192.168.5.100 Bcast:192.168.5.255 Mask:255.255.255.0

4.3.2 Statische IP-Adresse für den zweiten Netzwerkadapter am PC einstellen

Hierzu müssen die TCP/IP-Einstellungen am PC für die betreffende Netzwerkkarte (Netzwerkad-apter) geändert werden:

1. Unter „Netzwerkverbindungen anzeigen“ erhält man unter Windows eine Liste der Netzwerkadapter.

2. Durch Ein- und Ausstecken des Netzwerkkabels wird die richtige Netzwerkverbindung in der Liste identifiziert, denn z.B. auch die die USB-Schnittstelle des BB taucht als „LAN-Ver-bindung X“ auf. (X wird durchnumeriert)

3. Bei der so identifizierten „LAN-Verbin-dung X“ wird im Kontextmenü deren Ei-genschaften ausgewählt (Adminrechte nötig)

4. Für das Element „Internetprotokoll Versi-on 4 (TCP/IPv4)“ Eigenschaften auswäh-len.

5. Wie in Abb. 9 exemplarisch mit der Adresse 192.168.5.1 gezeigt, die IP-Adresse dieses LAN-Adapters festlegen.

6. Mit OK und Schließen die Änderung be-stätigen.

Wird der BB nun mit einem Patchkabel mit der Netzwerkbuchse des Adapters im PC verbunden, muss man warten bis die LEDs an der BB-Buchse blinken.

Dann ist die Verbindung hergestellt, und in diesem Beispiel ist der BB nun mit Putty unter der IP-Adresse 192.168.5.100 erreichbar.

Diese Verbindung kann ebenfalls parallel zur USB-Verbindung betrieben werden.

Achtung:Unbedingt darauf achten, dass nicht aus Versehen beim falschen Netzwerkadapter oder bei meh-reren Netzwerkadaptern die o.g. statische IP-Adresse eingestellt wird. In der Regel erscheinen un-ter „Netzwerkverbindungen anzeigen“ nicht nur die beiden „realen“ Verbindungen über die Ether-


Abbildung 9: Unter Windows statische IP-Adresse am PC einstellen.

net- und WLAN-Schnittstelle des PCs. Zusätzlich sind auch noch virtuelle Netzverkverbindungen wie die des USB/Ethernet-Schnittstellenwandlers des BB (siehe Abb. 4) oder ein „TAP-Win32 Ad-apter“.

Es ist unbedingt zu vermeiden, dass am Ende zwei Netzwerkverbindungen die selbe statische IP-Adresse zugewiesen bekommen!

4.4 Kommunikation via WLANEs ist am einfachsten, den BB via USB mit dem PC zu verbinden, denn in diesem Fall erfolgt die Stromversorgung via USB und durch den speziellen USB-Treiber kann vom PC aus via Ethernet auf den BB zugegriffen werden. Diese Verbindung ist optimal vom Einbinden der Sensoren bis zu den Plausibilitätsprüfungen des Gesamtmodells mit aufgebocktem Roboterfahrzeug.

Tipp: Verwenden Sie wenn immer es geht die USB-Kommunikation, da diese leistungsstärker und weniger störanfälliger ist als die WLAN-Verbindung.

Um jedoch das Roboterfahrzeug im fahrenden Betrieb zu optimieren, muss eine Drahtlosverbin-dung verwendet werden. Zum Glück ist der BB mit einem Linuxbetriebssystem ausgestattet: Denn für den Umstieg auf WLAN wird daher am BB wie auch am PC nur ein normaler WLAN-Stick bzw. eine WLAN-PCI-Karte benötigt. Man könnte dann den BB als WLAN Accesspoint einrichten, in dessen WLAN sich dann der PC einbucht. In [14] ist die Vorgehensweise am Beispiel eines Raspberry Pi detailliert beschrieben. Diese Art der WLAN-Kommunikation hat sich jedoch als nicht ausreichend stabil erwiesen.

Daher wird im Sensorsystemeprojekt ein einfacher WLAN-Router (ohne Internetanschluss) ver-wendet, in den sich sowohl der PC als auch der BB einbuchen (siehe Abb. 10).

4.4.1 Mit dem BB in ein vorhandenes WLAN einwählen

Die nachfolgend genannte Prozedur wurde mit einem WLAN-Stick von Edimax, Modell EW-7811Un durchgeführt. Dieser sollte vom Debian Wheezy automatisch erkannt und eingebunden werden, da der nötige Treiber (RTL8192CU) dort schon enthalten ist.

Zuerst muss sichergestellt werden, dass das Betriebssystem über den USB-Bus den WLAN-Stick während des Bootens überhaupt erkennt und den obigen Treiber geladen hat.Dazu sollte man den WLAN-Stick erst nach dem Booten einstecken und danach in der Konsole mitdem Befehl dmesg nachschauen, ob folgende Meldung vom Kernel ausgegeben wird - die jetzt in der sehr großen Liste an Zeilen ganz unten steht:

[ 322.809254] usb 1-1: New USB device found, idVendor=7392, idProduct=7811[ 322.809288] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 322.809320] usb 1-1: Product: 802.11n WLAN Adapter[ 322.809349] usb 1-1: Manufacturer: Realtek


Abbildung 10: Kommunikation des BB via WLAN mit einem PC.

PC mit WLAN-Karte: Python: Browser (sonst nichts)Simulink: Matlab/Simulink + C-Toolchain

BeagleBone mit WLAN-Stick:Python: IDE „Cloud 9“ (Webserver)Simulink: Direkt wie über USB

WLAN-Router

[ 322.809467] usb 1-1: SerialNumber: 00e04c000001[ 322.810641] usb 1-1: usb_probe_device[ 322.810686] usb 1-1: configuration #1 chosen from 1 choice[ 322.811763] usb 1-1: adding 1-1:1.0 (config #1, interface 0)[ 322.815764] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002[ 322.815858] hub 1-0:1.0: port 1 enable change, status 00000503[ 322.997777] rtl8192cu 1-1:1.0: usb_probe_interface[ 322.997841] rtl8192cu 1-1:1.0: usb_probe_interface - got id[ 323.130721] usbcore: registered new interface driver rtl8192cu

Zusätzlich kann man auch mit lsusb prüfen, ob er als USB-Gerät angemeldet ist.

root@beaglebone:~# lsusbBus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Mit ifconfig -a wird geprüft, welches „Netzwerk Device“ nun dem WLAN-Stick zugeordnet wur-de. In den Beispiel unten hat er den Namen „wlan0“ erhalten.Achtung:Jeder WLAN-Stick (selbst baugleiche) hat eine andere MAC-Adresse. Wenn man verschiedene WLAN-Sticks mit dem BB verbindet, dann erhält der erste den Namen „wlan0“, der zweite „wlan1“ usw. Daher ist es wichtig den Namen des aktuellen WLAN-Sticks zu kennen - denn man weiß ja nicht unbedingt, wie viele andere WLAN-Sticks schon vorher verbunden waren.

root@beaglebone:~# ifconfig -aeth0 Link encap:Ethernet HWaddr 78:a5:04:ef:98:58 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:40

lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

usb0 Link encap:Ethernet HWaddr 78:a5:04:ef:98:50 inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252 inet6 addr: fe80::7aa5:4ff:feef:9850/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:500 errors:0 dropped:0 overruns:0 frame:0 TX packets:95 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:52200 (50.9 KiB) TX bytes:21536 (21.0 KiB)

wlan0 Link encap:Ethernet HWaddr 74:da:38:05:05:bb BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Im Beispiel oben hat der BB nur über den usb0-Anschluss eine IP-Verbindung (Adresse 192.168.7.2) und dadurch eine IP-Adresse. Der WLAN-Stick ist aber noch nicht mit einer IP-Adres-se versorgt worden, hat also noch keine Verbindung zu einem WLAN-Netzwerk.


Wird der BB zusätzlich über Netzwerkkabel an einem Router angeschlossen, so ändert sich eth0 im Vergleich zu oben: Nun hält die Schnittstelle eth0 ebenfalls eine IP-Verbindung (192.168.178.36), deren Adresse im IPv6-Format angegeben ist.

eth0 Link encap:Ethernet HWaddr 78:a5:04:ef:98:58 inet6 addr: fe80::7aa5:4ff:feef:9858/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:205 errors:0 dropped:27 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:44411 (43.3 KiB) TX bytes:4307 (4.2 KiB) Interrupt:40

Mit dem Befehl iwconfig kann man ähnlich zu ifconfig die Drahtlosverbindungen abfragen:

root@beaglebone:~# iwconfigwlan0 unassociated Nickname:"<WIFI@REALTEK>" Mode:Auto Frequency=2.412 GHz Access Point: Not-Associated Sensitivity:0/0 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/100 Signal level=0 dBm Noise level=0 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0lo no wireless extensions.eth0 no wireless extensions.usb0 no wireless extensions.

Um dem BB mitzuteilen, mit welchem WLAN und unter welchen Randbedingungen er sich verbin-det, muss die zentrale Konfigurationsdatei für die Schnittstellen interfaces auf dem BB geöffnet werden:

nano /etc/network/interfaces

Hier muss unter #WiFi Example die entsprechenden Zeilen auskommentiert und die ssid mit Passwort eintragen werden:

# WiFi Example#auto wlan0allow hotplug wlan0iface wlan0 inet dhcp wpa-ssid "ssid" wpa-psk "Passwort"

(Normalerweise würde man übrigens aus Sicherheitsgründen nie das WLAN-Passwort als Klartext in einer Datei wie hier abspeichern.)

Anschließend muss man neu booten oder den Netzwerkdienst mit folgendem Befehl neu starten:

/etc/init.d/networking restart

Jetzt kann man die WLAN-Verbindung manuell aufbauen mit ifup wlan0 (schließen mit ifdown wlan0). Hat der Verbindungsaufbau funktioniert, dann blinkt die eingebaute blaue LED im WLAN-Stick unregelmäßig.

root@beaglebone:~# ifup wlan0ioctl[SIOCSIWAP]: Operation not permittedioctl[SIOCSIWENCODEEXT]: Invalid argumentioctl[SIOCSIWENCODEEXT]: Invalid argumentInternet Systems Consortium DHCP Client 4.2.2Copyright 2004-2011 Internet Systems Consortium.All rights reserved.For info, please visit https://www.isc.org/software/dhcp/Listening on LPF/wlan0/74:da:38:05:05:bb


Sending on LPF/wlan0/74:da:38:05:05:bbSending on Socket/fallbackDHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14DHCPREQUEST on wlan0 to 255.255.255.255 port 67DHCPOFFER from 192.168.178.1DHCPACK from 192.168.178.1bound to 192.168.178.47 -- renewal in 371195 seconds.

Normalerweise erhält der BB vom Router bei jedem Starten der WLAN-Verbindung eine neue (=andere) IP-Adresse zugewiesen. Es sei denn, man richtet den Router entsprechend anders ein. Die meisten Router vergeben innerhalb 24 h jedoch immer wieder die selbe IP-Adresse an einen bestimmten BB. Man kann auch in der BB-Datei interfaces eine statische Adresse festlegen, siehe dazu [15].

Nun kann man mit ifconfig wlan0 nachschauen, welche IP-Adresse der BB vom Router erhal-ten hat:

root@beaglebone:~# ifconfig wlan0wlan0 Link encap:Ethernet HWaddr 74:da:38:05:05:bb inet addr:192.168.178.47 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::76da:38ff:fe05:5bb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:408 errors:0 dropped:0 overruns:0 frame:0 TX packets:40 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:49488 (48.3 KiB) TX bytes:9668 (9.4 KiB)

Jetzt besitzt der BB in diesem konkreten Beispiel also zusätzlich die IP-Adresse 192.168.178.47, die über WLAN zu erreichen ist. Diese kann nun auch in MATLAB/Simulink, putty oder in Cloud9 statt der USB-IP-Adresse 192.168.7.2 verwendet werden.

Mit dem PC muss man sich nun in das selbe WLAN-Netzwerk einbuchen, damit eine WLAN-Ver-bindung zum BB entsteht. Ob die Verbindung steht, prüft man in diesem Beispiel z.B. von der Win-dowskonsole aus mit dem Kommando ping 192.168.178.47.

Achtung:Wenn Sie den BB später über den Micro-USB Anschluss mit einer Powerbank versorgen möchten,dann muss die WLAN-Verbindung automatisch nach dem Booten hergestellt werden, da ja für die Kommunikation die USB-Schnittstelle schon belegt ist.

Dafür kann man nach einer Anleitung von Adafruit vorgehen [16]. Hier wird ein Service nach dem Booten gestartet, der die WLAN-Verbindung zurücksetzt und dann startet.

Es geht aber auch einfacher:

In die Datei /etc/network/interfaces wird die Zeile auto wlan0 (die für den automatischen WLAN-Start beim Betriebssystemstart sorgen sollte) mit einem # auskommentiert und durch al-low-hotplug wlan0 ersetzt.

Der WLAN-Teil dieser Konfigurationsdatei sieht also schlussendlich so aus:

# WiFi Example#auto wlan0allow-hotplug wlan0iface wlan0 inet dhcp wpa-ssid "Die-ssid" wpa-psk "Das-WLAN-Passwort"

Wenn vor dem Starten der WLAN-Verbindung schon eine Ethernetverbindung aktiv war, dann wird der Internetzuganng über letztere Verbindung laufen. Ansonsten wird der Internetzugang über den WLAN-Router dieser neuen Verbindung hergestellt.Diese Internetverbindung kann man z.B. mit dem „Anpingen“ von google.com testen (danach das Anpingen mit Strg-C abbrechen).


root@beaglebone:~# ping google.comPING google.com (172.217.22.14) 56(84) bytes of data.64 bytes from fra16s14-in-f14.1e100.net (172.217.22.14): icmp_req=1 ttl=57 time=33.2 ms64 bytes from fra16s14-in-f14.1e100.net (172.217.22.14): icmp_req=2 ttl=57 time=35.8 ms^C--- google.com ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1001msrtt min/avg/max/mdev = 33.224/34.529/35.835/1.318 ms

Falls der WLAN-Stick bei längeren Kommunikationspausen die WLAN-Verbindung abbricht, dann kann dies an einer aktivierten Stromsparfunktion des Edimax-Treibers liegen. Die Funktion wird in der Datei /etc/modprobe.d/8192cu.conf durch folgende Zeilen deaktiviert:

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

4.5 Bekannte Probleme:• Der Bootvorgang des BB dauert manchmal ungewöhnlich lange (>10 s), wenn die Ether-

netschnittstelle nicht angeschlossen ist. Dieses Problem lässt sich beheben, indem in der Datei /etc/network/interfaces die Zeile auto eth0 auskommentiert und durch allow-hotplug eth0 ersetzt wird.

auto eth0 bewirkt den Start der Schnittstelle bei Betriebssystemstart, allow-hotplug eth0 aktiviert die Schnittstelle, wenn vom Betriebssystem ein Ereignis eines eingesteckten Neztwerkkabels gemeldet wurde. Für die WLAN-Schnittstelle gilt Entsprechendes.Beim Betriebssystemstart, wird allow-hotplug eth0 übrigens auch ausgeführt. Details siehe debian.org/doc/manuals/debian-reference/ch05.de.html.

• Oft identifizieren Router einen bestimmten BB über dessen MAC-Adresse und weisen ihm immer die selbe IP-Adresse zu. Hat sich der Hostname geändert, dann kann es bei erneu-tem Verbinden mit dem WLAN Router zu Problemen kommen, weil sich die Kombination aus MAC-Adresse und Hostname geändert hat.

• Zusammen mit dem WLAN-Dongle kann der BB kurzzeitig mehr als 1 A Strom benötigen. Dies kann je nach Stromversorgung zu Instabilitäten der WLAN-Verbindung führen. Wenn dies der Fall ist, dann verwenden Sie z.B. den 2 A stat 1 A Ausgang der Powerbank.

Tipp:Manchmal ist es schwierig zu erkennen, ob sich der BB in das WLAN eingebucht hat. Wenn Sie ein Smartphone dabei haben, dann können Sie sich mit diesem ebenfalls in das selbe WLAN ein-buchen und dann mit einer Netzwerk-Scanner App (z.B. Fing) nachschauen, ob Ihr BB im selben Netz ist. Werden hier mehrere BB gelistet, so können Sie Ihren eigenen BB über dessen MAC-Adresse identifizieren und mit ping die Verbindung testen.

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 Das Betriebssystemimage und die SD-KarteIm SRP wird ausschließlich die SD-Karte als Speichermedium im BB verwendet. Ähnlich wie auf der Festplatte Ihres PC befindet sich darauf das Betriebssystem, alle installierten Treiber und Pro-gramme sowie die sonstige wie z.B. persönlich Dateien.Anders als bei einem PC wird das Betriebssystem auf dem BB nicht installiert, sondern es wird ein sogenanntes „Image“ des Betriebssystems auf die SD-Karte des BB bitweise kopiert. Anders als bei PCs, die unterschiedliche Prozessoren, Grafikchips usw. haben ist ein solches Klonen der


„Festplatte“ bei einem festen BB-Modell (hier BBG) möglich, da die Hardware immer identisch ist.

Umgekehrt kann man den Ist-Zustand eines BB als Image (inkl. der zwischenzeitlich zugefügten Programme und Dateien) konservieren und so ein komplettes Back Up herstellen.

Mit dem Begriff „Image“ ist also eine 1:1 Kopie des Speichermediums des BB gemeint.

Das aktuelle Image für das SRP finden Sie als Download unter Relax.

5.1.1 Kopieren, Sichern, Wiederherstellen und Klonen von SD-Karten Images

Kopieren eines vorhandenen Images auf eine SD-Karte für Windows PCs:Nach dem Downlaod wird das Image mit 7-zip entpackt und anschließend mit Win32DiskImager auf die SD-Karte übertragen.

Back up eines SD-Karten Images auf einem Windows PC:Mit der Windows-Software „USB Image Tool“ kann man komplette SD-Karten auf dem PC sichernund danach klonen. Somit können Sie damit den Ist-Zustand Ihres BB Images auf dem PC oder ei-ner zweiten SD-Karte sichern. Das so erstellte Back Up Image (auf dem PC gespeichert) überträgt man im Ernstfall dann mit Win32DiskImager wieder auf eine frische SD-Karte.

Das Programm „USB Image Tool“ kann sowohl Imagedateien aus SD-Karten auf den PC sichern („Backup“) als auch vorhandene Images auf eine SD-Karte kopieren („Restore“). Beide Program-me sind Freeware, müssen nicht auf dem PC installiert werden, erfordern beim Ausführen jedoch Adminrechte.

5.1.2 SD Karte als Massenspeicher versus eMMC

Der BB besitzt sozusagen als SSD-Festplatte einen eMMC (Embedded Multi Media Card). Dieser Speicher ist recht schnell und hat eine Kapazität von 4 GB.

Wenn man auf diesem Speicher jedoch das Betriebssystem „zerschossen“ hat, dann ist es schwie-rig auf dem eMMC befindliche Dateien nachträglich zu sichern.

Stehen schnelle SD-Karten zur Verfügung, so ist es vorteilhaft, diese als SSD-Festplatte zu ver-wenden. In diesem Fall befinden sich die selben Dateien inkl. Dateisystem auf der SD-Karte wie auf dem eMMC. Dieses sogenannte „Betriebssystem-Image“ lässt sich dann einfach via Klonen auf eine weitere SD-Karte sichern.

Wenn man das Betriebssystem auf der SD-Karte zerschossen hat, dann kann man dort befindlicheDateien anders als beim eMMC dadurch retten, indem man die SD-Karte vom BB entfernt und mit einem PC ausliest.

Wenn keine SD-Karte eingesteckt ist, dann bootet der BB vom eMMC aus. Andernfalls bootet er normalerweise von der SD-Karte aus - je nach Booteinstellungen kann man hier aber durch Drü-cken von bestimmten Tastern während des Einschaltens wählen, von welchem Speichermedium aus gebootet wird.

Wichtig ist, dass man nach dem Booten weiß, ob man nun auf der SD-Karte oder auf dem eMMC arbeitet. Am einfachsten ist es, auf der jeweiligen Windowspartition einen Ordner mit dem Namen „Boot_eMMC“ bzw. „Boot_SDKarte“ zu erstellen. Dann kann man kurz im Windows-Explorer nach-schauen, von welchem Speichermedium aus der BB gestartet wurde.

Alternativ kann man auch über das Flackern der USR LEDs herausfinden:

USR3 (erste LED neben der Ethernetbuchse): Booten von eMMC.

USR1 (die übernächste LED): Booten von der SD-Karte.

Sie erhalten für Ihre Projektarbeit das Linuxbetriebssystem als „Image“ auf einer SD-Karte. Die Schritte unter 5.2.1 sind also nicht auszuführen.Den eMMC-Speicher benötigen Sie normalerweise nicht, da Sie auch von dieser Karte aus bootenund dort auch Ihre Software abspeichern. Dies hat den Vorteil, dass im Ernstfall eines zerstörten Betriebssystems einfach eine frische SD-Karte mit Image einstecken und ihre Quelldateien von


der alten noch retten können.

5.2 Ermitteln der installierten Linuxdistribution

Welche Distribution sich genau auf dem BB befin-det, ermittelt man über den Befehl cat /etc/debian_version oder cat /etc/dogtag oder cat lsb_release -a (siehe Abb. 11).

Debianversion und Kernelversion sind etwas ver-schiedenes. Die Kernelversion wird mit dem Be-

fehluname -a angezeigt. Im Praktikum wird die Kernelversion 3.8.13 verwendet. Hier bezeichnet die erste Zahl die eigentliche „Kernelversion“, welche sich nur alle paar Jahre ändert. Die beiden folgenden Zahlen beziehen sich auf die „Major Revision“ und „Minor Revision“ des Kernels.

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 [3] zum Download bereit steht, funktioniert nicht unter Simulink!

Handeln Sie nach der Devise: „Never change a running System“. Verwenden Sie am besten keine andere MATLAB- oder Linuxversion als hier vorgeschlagen oder getestet.

5.2.1 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 Win-dows nicht einfach auf die SD-Karte kopieren kann, sondern man muss sie z.B. mit der Software ImageWriter auf die Karte schreiben. Man muss hier aufpassen, die richtige Image-Datei herunterzu laden, denn es gibt solche, die für ein späteres Booten von der SD-Karte vorgesehen sind und solche, die das Image von direkt auf den eMMC übertragen, so dass anschließend vom eMMC ausgebootet wird.

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.

Wenn man vorher von der SD-Karte gebootet hat und dies nun von dem eMMC-Speicher machen will (für die Projektarbeit nicht zu empfehlen!), wird wie folgt vorgegangen: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-Spei-cher übertragen wird, was eine Weile dauert. Details hierzu siehe [3].

5.2.2 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 11: Ermitteln der auf dem BB installierten Li-nux-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 immer vor einer Installation oder einem Upgrade geschehen sollte.Mit dem Befehl apt-get install meinPaket installiert man anschließend die ausgewählte Soft-warepaket. Näheres, siehe Abschnitt 14.11.

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.

Tipp:Um einfach zu erkennen, ob der BB von der SD-Karte oder vom eMMC bootet, können Sie auf der Windowspartition der SD-Karte z.B. ein Verzeichnis mit dem Namen „dies-ist-die-SDKarte“ anle-gen. Wenn der BB via USB mit dem PC angeschlossen ist, dann sehen Sie im Dateiexplorer des PCs, ob dieses Verzeichnis erscheint oder nicht.Über die LEDs kann wie folgt festgestellt werden, ob der BB auf die SD-Karte oder auf den eMMC zugreift:

USR3 (erste LED neben der Ethernetbuchse): Booten von eMMC.USR1 (die übernächste LED): Booten von der SD-Karte.

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 Funkti-on 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 [17], [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 14.9.

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[2].

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 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 14.4.

2) Es können auch Dateien von einem USB-Stick vom und zum BB kopiert werden. Dazu wird nach dem Einstecken des USB-Sticks mit dem Befehl fdisk -l nachgeprüft, ob dieser als /dev/sda1 erscheint.Nun muss der USB-Stick noch „gemountet“ werden, d.h. es muss ein Verzeichnis angelegt wer-den, über das auf ihn zugegriffen werden kann. Dafür wird z.B. das Verzeichnis /media/usb ange-legt (mkdir /media/usb) und anschließend mit dem Befehl mount /dev/sda1 /media/usb mit dem USB-Stick verbunden.

6.2 Der Bootvorgang selbst

Nach dem Einschalten eines PC führen zuerst die Prozessoren einen Bootvorgang durch, dann startet das BIOS und in einem letzten Schritt wird das Betriebssystem gestartet.

Beim BB ist dieser Vorgang ähnlich mehrstufig mit der Ausnahme, dass es kein BIOS gibt, welchesals Schnittstelle zwischen Hardware und Betriebssystem fungiert. Die Information über die Hard-wareschnittstellen stecken beim BB zum größten Teil im sogenannten Device Tree (DT), der in Ab-schnitt 7 näher besprochen wird.

Eine grafische Darstellung der ersten drei Stufen des BB-Bootvorgangs sind in Abb. 12 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


Abbildung 12: Grafische Übersicht des dreistufigen Bootvorgangs beim BB bevor der Kernel (Linuxbetriebssystem) ge-startet wird. Quelle: [18].

Bootparameter sind u.a. in der Datei /boot/uEnv.txt zu finden. Näheres siehe Buch von D. Mol-loy, Seite 60 ff. [2].

Den Bootprozess selbst kann man nur über die serielle Debugschnittstelle, siehe Abschnitt 14.10 mitschneiden. Dazu verwendet man ein 3,3 V FT-DI-Breakout, das man wie in Bild 13 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 14.10 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 Initialisierungs-operationen 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. Genauere Informationen zum Bootvorgang als im Buch von D. Molloy sind in [19] und [20] 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 BuchsenleistenP9 und P8, den sogenannten „Cape Expansion Headers“ Ver-sorgungsspannungen (3,3 und 5V), Masse, Resets, Analogeing-änge und GPIOs herausgeführt.

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

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 14: Beispiel Pinbelegung der beiden Buchsenleisten P8 und P9 bei einem BB ohne geladenem Device Tree Overlay (DTO). Quelle: [21].

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

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“.

Grundsätzlich ist das nichts an-deres als die Pinzuordnung bei einem µC: Bei dem ATmega328 eines Arduinoboards beispiels-weise können die Analogpins 4 und 5 auch als I²C-Schnittstelle konfiguriert werden. Beim BB gibt es aber ein Betriebssystem, was die Sache schwieriger macht: Man benötigt zusätzlich noch Treiber und eigentlich bräuchte man bei Linux für für unterschiedliche Pinbelegungen unterschiedliche Kernels (=Betriebssystemversionen). Normalerweise ist die Pinzuordnung also im Betriebs-system = 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 Kernelbeim Bootvorgang die gewünschte (nicht einheitliche) Pinkonfiguration mitgeteilt.

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).Dies macht den BB als genau so flexibel wie ein µC!

Ein BB ohne jegliches DTO besitzt eine Pinbelegung wie in Abb. 14 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. 15 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 [2] ist dies sehr gut dargestellt. Außerdem findet sich auf seinen Inter-netseiten zu Kapitel 6 des Buchs („Interfacing to BeagleBone Busses“) [22] tabellarische Übersichten zu den erlaubten und möglichen Pinbelegungen, die auch in Abschnitt 14.7 abgebildetsind.

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

Achtung:Bestimmte Pins wie z.B. P8_20 bis P8_25, die Schnittstellen zum eMMC (siehe Abb.15 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.


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

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 manuelloder automatisch über den sogenannten „Capemanager“ geschehen.

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 für unterschiedliche Pinbelegungen oder BB-Capes (mit unterschiedliche Pinbelegungen) unter-schiedliche Kernels (=Linuxbetriebssysteme) kompilieren. Das Selbe würde auch gelten, wenn man wie in Abschnitt 14.1 dargestellt, auf eine maximale Anzahl bestimmter Schnittstellen zugrei-fen möchte.

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. Damit werden auch entsprechende Kernelmodule bzw. Treiber automatisch mit geladen.

Dadurch stehen diese Schnittstellen anschließend zur Verfügung und können vom Linuxbetriebs-system aus über das SysFS (siehe Abschnitt 7.3) ausgelesen und gesteuert werden.

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

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).Sie wurde (vor dem Bootvorgang) aus einer lesbaren Quelldatei mit dem Namen am335x-bone-green.dts kompiliert, welche wiederum den Inhalt der beiden Quelldateien am335x-bone-com-mon.dtsi und am33xx.dtsi über eine Include-Anweisung einbindet. Die Include-Anweisung ist nötig, da der gesamte DT des BB sehr umfangreich ist.

Die kompilierten DT-Dateien (Dateiendung *.dtb) finden sich im Verzeichnis /boot/dtbs/3.8.13-bone79. Hier steht 3.8.13-bone79 für die Kernelversion.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-bonegreen.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 14.7 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 14.7 nachschauen, um die-se Zahlen zu interpretieren.

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

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 hier-zu siehe [25].

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


[ 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)

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, falls diese Schnittstelle nicht ohnehin schon im Stan-dard DTO des SRP enthalten ist (siehe Abschnitt 7.2.5). Beim Starten des Simulinkmodells oder eines Pythonskripts geschieht dies automatisch, d.h. die nötigen DTOs befinden sich schon auf dem BB. Näheres hierzu siehe [26] und [27].

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. Bei Verwendung des „External Mode“ unter Simulink passiert dies automatisch.

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“. Meistens nicht lokal auf dem BB zu finden.

.dtsi DT Quellcodedateien ähnlich Include-Dateien, die in eine .dts Datei eingebunden werden. Meistens nicht lokal auf dem BB zu finden.

.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“. Zu finden un-ter /boot/dtbs.

.dtbo Kompilierter DTO, der vom Capemanager geladen wird. Zu finden unter /lib/firmware. Die Quellcodedateien der DTOs haben auch die Dateiendungen .dts oder .dtsi. Beispiele siehe [28].

Nähers siehe auch [29] oder [30]. In [31] 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.

In der nachfolgenden Tabelle sind Beispiele der Pinfunktionalität für verschiedenen DTOs aufge-führt.

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-SPIDEVn

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 DTOs 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 wie folgt 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[2] , [32] und [22] 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 man sich über den Befehl dmesg | tail die möglichen Fehlermeldungen anschauen.

7.2.5 Das Standard DTO für die Projektarbeit

Auf dem Linuximage, das Sie beim Start der Projektarbeit erhalten, wird folgendes DTO automa-tisch beim Booten geladen:

4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P8_13 6: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P8_19 7: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P9_14 8: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P9_16 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-PWM110: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART111: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-I2C112: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV113: ff:P-O-L Override Board Name,00A0,Override Manuf,cape-bone-iio

Verwenden Sie möglichst diese Pinbelegung während der gesamten Projektarbeit sowohl fürdie Pythonprogramme als auch für die Simulinkmodelle. Damit haben Sie schon eine Hauptfehler-quelle beseitigt!

Pin P9 Funktion Pin P9 Funktion

P9-28 BB-SPIDEV: SPI1_CS0 P9_12 Chip Select (Slave Select) 0

P9-29 BB-SPIDEV: SPI1_D0 (MISO) P9_3,4 3,3 V Spannungsversorgung

P9-30 BB-SPIDEV: SPI1_D1 (MOSI) P9_5,6 Beim BBG keine Funktion, da keine 5 V Buchse

P9-31 BB-SPIDEV: SPI1_SCLK P9_7,8 5 V Spannungsversorgung

P9_14 PWM P9_33 Analoge Eingänge

P9_16 PWM P9_35 Analoge Eingänge

bis

P9_24 BB-UART1: TX1 P9_40

P9_26 BB-UART1: RX1

P9_19 BB-UART1: RTS

P9_20 BB-UART1: CTS

Pin P8 Funktion

P9_17 BB-I2C: SCL P8_13 PWM

P9-18 BB-I2C: SDA P8_19 PWM

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. In dessen 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, über 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. Daher unterscheidet sich der C- oder Pythonquellcode für einen BB nicht wesentlich von dem für einen Raspberry Pi abgesehen von einigen hardwarespezifischenBibliotheken.

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 14.7):

/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 Pa-rametrierung kann 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 14.7 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 Tool kann die I²C Kommunikation zu angeschlossenen Peripheriegeräten (Slaves) wie Sensoren über-prüft werden.

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

In Abb. 16 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 auf-gelistet. Beim BB sind dies nach dem Booten i2c0 und i2c210.

10 Achtung: Die Nummerierung der Busse im Device Tree kann von der im SysFS abweichen!


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

Achtung: Auf den ebenfalls angezeigten Bus i2c-0 kann der BB nur intern zugreifen. Um eine weitere I²C-Busschnittstelle zu erzeugen, muss man den DTO „BB-I2C1“ aktivieren. Dieser erzeugt den Bus i2c-2, der jedoch nur bei der Version 1 (schwarz) des Grove Capes als Stecker herausgeführt wird.

Die Nummerierung der I²C-Buss und der SPI-Schnittstelln im Linuxbetriebssystem (und Simulink) stimmt nicht unbedingt mit der des Capes oder der von MATLAB überein! Im SysFS Dateisystem wrid die Nummer vermutlich nach der Reihenfolge des Anmeldens der Busse im DT vergeben. Die folgende Tabelle 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 be-finden 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 Die SPI-SchnittstelleIm DTO für das SRP ist nur eine der beiden SPI-Schnittstellen des BB aktiviert. In der Tabelle der Pinzuordnung sind die Pins für MISO, MOSI, SCLK und CS nachzulesen. Hier wird die Schnittstel-le als SPI1 bezeichnet. Im SysFS Dateisystem erscheint diese als spidev1.0 und spidev1.1. Da-bei handelt es sich um die selben Kommunikations- und Clockleitungen, jedoch steht die letzte Zif-fer für die beiden verschiedenen CS-Pins, die jeweils aktiviert werden.

Sowohl in den Python- als auch in den C-Programmen wird diese Schnittstelle mit den beiden Zah-len 1, 0 bzw. 1,1 angesprochen. Der CS_1 Pin ist im aktuellen DTO noch nicht aktiviert.

Für die SPI-Schnittstelle gibt es auch ein Testprogramm mit dem Namen spidev_test, Näheres siehe [2]. Da die SPI-Schnittstelle wesentlich lockerer spezifiziert ist als die I²C-Schnittstelle, muss man vorher genau das Sensordatenblatt lesen, denn verschiedene Peripheriebauteile benötigen unterschiedliche SPI-Modi und Timings.

7.6 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 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.

Achtung:

Wenn Sie die 5 V Spannung an P9_5 bis P9_8 oder über das Grove Cape verwenden, beachten Sie bitte, dass diese Spannung sehr unsauber ist, d.h. mit vielen Störspannungen überlagert ist. Wenn Sie z.B. Sensoren damit versorgen, dann müssen Sie diese Spannung mit einem Konden-sator erst glätten. Die 3,3 V Spannung am BB enthält erheblich weniger Störanteile.

Allerdings sollten Sie Verbraucher mit hohem Störpotential wie z.B.die Motortreiber besser nicht mit 3,3 V betreiben, da sonst wiederum der BB dadurch gestört wird. Zudem ist die 5 V Span-nungsversorgung wegen des fehlenden Spannungsreglers leistungsfähiger.


7.7 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. 17 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 [27] ist eingehend erklärt, wie man aus der MATLAB Kommandozeile heraus den DT kontrollier-en und ändern kann. Anders als bei Simulink muss man dies vor dem Starten des MATLAB-Skripts

manuell durchführen.

Bis auf die hier gezeigte grafi-sche Aufbereitung sind dies aber genau die gleichen Befeh-le, die man auch direkt in einer Linuxkonsole eingibt.

Startet man ein Modell aus Si-mulink heraus, dann werden dienötigen DTOs automatisch von Simulink über den Capemana-ger geladen.Welche das sind, kann man in der Linuxkonsole nach dem Start des Modells mit folgen-dem Befehl nachschauen:

dmesg | tailWill man das ausführbare Pro-

gramm des Simulinkmodells manuell aus der Linuxkonsole heraus starten, dann muss man vorher auch die nötigen DTOs manuell laden.

Achtung:Achten Sie beim Umgang mit MATLAB und Simulink darauf, dass Sie nur einen Pfad lokal auf dem Rechner verwenden, in dem Ihre eigenen MATLAB-Skripte und Simulink-Blöcke von MAT-LAB gesucht werden. Hierfür bietet sich der Ordner C:\Users\IhrName\Documents\MATLAB an. Kopieren Sie immer nur den Code in dieses Verzeichnis, an dem Sie gerade arbeiten und löschen Sie alle Dateien, wenn Sie mit neuem Code anfangen.

Wenn MATLAB in vielen Verzeichnissen nach Code sucht und Sie dort nicht „ordentlich aufge-räumt“ haben, dann ist vor allem bei gleichen Dateinamen nur schwer nachvollziehbar, welche Da-teien für die Codeerzeugung tatsächlich verwendet werden.

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 eingebunden werden kann. Siehe hierzu Kapitel 8 in [4].

In [2] (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.

Programmiersprache C++ Java Python


Abbildung 17: Ergebnis der Abfrage des aktuellen DT über die MATLAB-Kommandozeile.

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. [33].

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 [34].

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.

Cloud9 ist optimal als IDE für die Pythonprogrammierung geeignet: Man kann darin Pyhoncode sehr gut editieren, abschnittsweise in einer Python-Shell testen und ausführen.

Achtung:Cloud9 verwendet standardmäßig die alte Pythonversion 2.7, in der auch die folgenden Beispiel-programme verfasst sind. Python 3.x kann auf dem BB ebenfalls verwendet werden. In diesem Fallmüssen aber folgende Inkompatibilitäten berücksichtigt werden: Ganzzahlmultiplikation, Verwen-dung von Umlauten, print-Anweisung. Näheres siehe [35].

8.1 Installation notwendiger PhytonbibliothekenPython Version 2.7 (!) 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 universelle Bibliothek Adafruit_BBIO für den BB bereit [6]. Ob diese auch schon mit in-stalliert 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. 18.

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

Statt der Adafruit_BBIO können auch die jeweiligen Originalbibliotheken wie spidev oder smbus

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


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

(für I²C) verwendet werden. Pythonbibliotheken werden mit dem Programm pip installiert.

Beispiel: pip install smbus.

Wenn die automatische Installation via pip ausnahmsweise nicht funktioniert wie bei spidev, dannwird die betreffende Bibliothek wie folgt installiert:

apt-get install python-devmkdir python-spicd python-spiwget https://github.com/JoBergs/RaspiContent/raw/master/spidev/setup.pywget https://github.com/JoBergs/RaspiContent/raw/master/spidev/spidev_module.cpython setup.py install

Mit dem Befehl python in der Linux-Shell startet man die Python-Shell. Darin kann man dann mit dem Befehl import spidev testen, ob die Bibliothek installiert ist. Denn in diesem Fall gibt der In-terpreter keine Fehlermeldung aus.

Alternativ kann die Bibliothek „python-smbus“ und „py-spidev“ für die I²C bzw SPI-Kommunikation verwendet werden.

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.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 Put-ty-Fenster der Linuxeditor Nano verwenden. Da dieser Editor keine grafische Benutzeroberfläche hat, ist ein entsprechendes Cheat Sheet hierfür sehr nützlich (siehe Anhang 14.8).Es ist aber einfacher über den Browser die IDE Cloud9 zu nutzen. Dies funktioniert für Python genau so wie für BoneScript, siehe z.B. [5] oder [3].


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

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.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.

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

Die erste Zeile im Python-Quellcode gibt das Verzeichnis des Interpreters an, man nenn sie „Shebang“. Wenn man vorher 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 „Analog Input“ des Grove Capes wird ein Potentiometer angeschlossen. Dieseswird 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 Spannung am BB Pin P9_39 jede Sekunde aus, bis das Programm mit Strg + C aus der Linuxkonsole her-aus 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.

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 (Jumperstel-lung 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-

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.


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

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)

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 ATmega328 (Arduino Uno) wäre dies nicht der Fall: Hier würde man mit ei-nem 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 12.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 Register man hier zu-greifen 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 14.1) auf dem Grove Cape an den mit I2C1 oder den mit I2C bezeichneten Stecker


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)

angeschlossen.

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 [36].

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

Das in Abb. 21 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-


Abbildung 21: 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))

thek ist in [34] dargestellt.Der Sensor wird je nach aktiven Device Tree Overlay (DTO) (sieh Abschnitt 14.1) auf dem Grove Cape an den mit I2C2 bezeichneten Stecker angeschlossen. Achtung: Die Nummerierung 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. 21 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 14.4.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_BMP schreiben, dann wird die Programmierung sehr aufwändig, da man sehr viele Daten in einzelne Register schreiben und le-sen muss (der BMP180 ist sehr komplex). Siehe hierfür z.B. ein entsprechendes Skript für den Raspberry Pi [37].

Übersicht der Beispiel-Pythonprogramme

Für das SRP sind für einige Funktionen/Sensoren/Aktoren schon Beispiel-Pythonprogramme vor-handen. 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 Beschleunigungssen-sor ADXL345

myAdxl345.py

Digitaler Ultraschallsensor SRF02

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

Analoger Ultraschallsensor HC-SR04

myHCSR04.py, myHCS-R04Interr.py

Zweite Version mit Pseudointerrupt. Im Buch[7] ist eine Anleitung zu finden, wie man die-sen Sensor mittels der PRUs via Python be-treibt.

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

Digitaler Farbsensor TCS34725

myTcs34725.py I²C

Digitaler Lichttaster und Hellig-keitssensor VCNL4010

myVCNL4010.py, VCN-L40xxLib.py

I²C, Bibliothek muss im selben Verzeichnis sein.

Digitaler TOF-Sensor VL6180X(180 mm Reichweite)

myVL6180X.py, VL6180X_Lib.py,myVL6180Xmini.py

I²C, Bibliothek muss im selben Verzeichnis sein. Die „mini“-Version läuft ohne Bibliothekund beinhaltet nur absolut nötigen Code.

Digitaler TOF-Sensor VL53L0X(2000 mm Reichweite)

myVL53L0X.py,myVL53L0Xmini.py

Die „mini“-Version läuft ohne Bibliothek und beinhaltet nur absolut nötigen Code.

Drucksensor BMP180 simpletest_BMP180.py I²C

Modellbauservo myServo.py Die Werte MINDUTYC und MAXDUTYC va-riieren je nach Servo.

Maussensor ADNS3080 myADNS3080mini.py Objektiv muss fokussiert sein, Oberfläche muss gut ausgeleuchtet sein. Rückgabe


Messwerte nur bei Bewegung.

Gestensensor APDS-9960 myAPDS9960Ge.pymyAPDS9960Co.pymyAPDS9960Pr.py

myAPDSPrMini.pymyAPDSColMini.pymyAPDSGeMini.pymyAPDSInterrGeMini.py

Gesten L/R, Up/Down und Near/FarFarb- und HelligkeitswerteAbstandswerte, Bibliotheksordner: apds9960_LibMiniversionen funktionieren ohne Bibliothek. Bei Gestensensor hier nur Rohmessdaten.Bei Interruptversion Gestensensorrohdaten erst ab Abstandsschwelle

9 Einbinden von Sensoren und Aktoren über C-ProgrammeWie später gezeigt wird, benötigt man C-Programme um für neue Sensoren in Simulink entspre-chende S-Functions zu erstellen. Im SRP beschränkt sich die C-Programmierung der Einfachheit halber auf normales C, C++ wird nicht verwendet.

Daher ist es manchmal sinnvoll vorher ein C-Programm zu erstellen, und dieses auf dem BB zu kompilieren und dort zu testen.

Funktion / Sensor / Aktor Programmname Bemerkung

Maussensor ADNS3080 ADNS3080_mini.c Minimalprogramm für Delta_X und Delta_Y

Maussensor ADNS3080 ADNS3080_full.c Programm mit Zugriff auf viele Funktionen

AMR-Sensor HMC5883L HMC58832_mini.c Flussdichte (µT) in x, y und z Betrag sowie horizontale Ausrichtung Sensor bezüglich N

Farbsensor TCS34725 TCS34725_mini.c Rot-, Grün-, Blau- und Helligkeitswert

Gestensensor APDS-9960 APDSCol_mini.cAPDSGest_mini.cAPDSProx_mini.c

Col = Farb-/HeligkeitssensorGest = Rohdaten GestensensorProx = Abstandssensor

In der Tabelle sind Beispielprogramme aufgeführt. Sie werden mit folgender Befehlsfolge kompiliertund ausgeführt (siehe auch [2]):

gcc ADNS3080_mini.c -lm -o ADNS3080_mini./DNS3080_mini

Am einfachsten ist das Editieren, Kompilieren und Testen des C-Quellcodes mittels Cloud9.

Für die C-Programmierung können folgende Bibliotheken verwendet werden, um auf die I/Os des BB zuzugreifen:

Name Bibliothek Bemerkung

libsoc Zugriff auf GPIOs statt über das SysFS, andere Schnittstellen und Pythonversion der-zeit in Arbeit.

ioctl Zugriff auf Geräte unter Verwendung des SysFS

spidev SPI Kommunikation, auch indirekt über Python

i2c I²C-Kommunikation

i2c-dev I²C-Kommunikation

10 Vorbereitung der MATLAB/Simulink-Umgebung und des Targets BBG

Das Zusammenspiel zwischen MATLAB/Simulink und den BB findet auf verschiedenen Ebenen statt und ist daher am Anfang schwer zu verstehen. Abb. 22 und Abb. 23 illustrieren die nachfol-


genden Sachverhalte.

Grundsätzlich kann man die Beziehung zwischen dieser Software und den BB in vier verschiedeneKategorien 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 [38].Die Fa. Mathworks (Hersteller MATLAB und Simulink) verkauft diese Funktionalität als „MATLAB Support Package for BeagleBone Hardware“.

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

Der sogenannte „MATLAB Coder“ konvertiert ein MATLAB-Code in C-Code. Anschließend erzeugt der „Embedded Coder“ daraus speziell für den BB angepassten C-Code. Mit die-sem wird dann mit Hilfe einer Entwicklungsumgebung wie Eclipse, entsprechenden (Cross-)Compilern, Debuggern usw. ein lauffähiges Programm für den BB erzeugt, dort ge-startet und wenn nötig „debugged“. Diese Methode ist recht detailliert inkl. nötiger Toolchainin [8] beschrieben.

c) Algorithmen als Simulinkmodell programmieren, in C-Quellcode konvertieren und auf dem BB ausführen: („Deploy to Hardware“)

Der sogenannte „Simulink Coder“ erzeugt zusammen mit dem „Embedded Coder“ aus demgrafikbasierten Modell einen C-Code. Dieser kann dann wie in b) über eine andere Entwick-lungsumgebung weiter verarbeitet werden. Simulink kann aber auch selbst direkt aus dem Modell ein ausführbares Programm für den BB erstellen, dort hin übertragen und 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. Das ist insbesondere praktisch für ein Roboterauto in Aktion, welches via WLAN mit einem PC verbunden ist.

Im Praktikum wird primär der „External Mode“ d) verwendet. Zur Fehler suche wird zusätzlich der Fernzugriff aus a) bzw. der direkte Weg über die Linuxkonsole genutzt.

Die Methode c) „Deploy to Hardware“ wird verwendet, wenn das Modell fertig ist bzw. wenn auf dem BB die bestmögliche Ausführungsgeschwindigkeit benötigt wird. Denn beim „External Mode“ d) wird sehr viel Rechenleistung des BB für die Debugkommunikation benötigt.

Achtung:Daher kann ein Modell mit Timingproblemen im „External Mode“ funktionieren, im Modus c) aber Laufzeitfehler zeigen.

Neben der MATLAB-Grundinstallation 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 MATLAB-Dokumentation unter [39] beschrieben.

Zuerst muss das sogenannte „Embedded Coder Support Package for BeagleBone Black Hard-ware“ (der BBB ist ja für die Belange des SRP identisch mit dem BBG) auf dem PC innerhalb MAT-LAB nachinstalliert werden13. Zwei dafür nötige zusätzliche „Hardware Support Packages“ (auch „Add-Ons“ genannt) werden in der Regel automatisch mit installiert.

Insgesamt werden bei diesem Vorgang also folgende drei Add-Ons nachinstalliert:

a) Embedded Coder Support Package for BeagleBone Black Hardware („Generate Code optimized for BeagleBone Black“)

b) Embedded Coder Support Package for ARM Cortex-A Processors

c) MATLAB Support Package for BeagleBone Black Hardware („Interact with BeagleBone Black from MATLAB“)

Bei einer neuen MATLAB-Installation muss dann zusätzlich noch das Add-On „Support for MinGW-w64 Compiler“ installiert werden.

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


Abbildung 22: Struktur der verschiedenen Mathworks-Produkte und Packages.

MATLAB(Code)

Simulink(Modell)

C++ Codefür PC

„MATLAB Support Package for BeagleBone Hardware ®“: MATLAB auf PC verwendet I/Os BeagleBone

C++ Codefür PC

„MATLAB Coder, Simulink Coder ®“:C++ Code aus MATLAB-code / Simulinkmodell

„Embedded Coder Support Package ...... for BeagleBone Black Hardware... for ARM Cortex-A Processors ®“Berücksichtigung I/Os, begrenzte Resourcen, spezielle Bibliotheken BeagleBone

C++ Code fürEmbedded

„MATLAB, Simulink ®“:Textbasierte / grafikbasierte Programmiersprache z.B. für Simulation


C++-Code kann Teil MATLAB-Programm seinMATLAB-Code, C++-Code kann Teil Simulinkmodell sein

Abbildung 23: Struktur der Simulinkprogrammierung eines BB über einen PC.

PC

MATLAB

Simulink


Crosscompilerfür BeagleBone

BeagleBone (Target)

AusführbaresProgramm

nur „External Mode“

„External Mode“„Deploy to Hardware“

Dann stellt MATLAB/Simulink eine Verbindung zum BBG her und passt dessen Linux-Betriebssys-tem an („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 MATLAB Command Window mit dem Befehl mex -setup überprüft werden. Beim Auf-treten eine entsprechenden Fehlermeldung muss ein C-Compiler nachinstalliert werden. Welcher C-Compiler für Simulink geeignet ist, hängt von der MATLAB-Version 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 MATLAB-Installation durchlaufen hatte, müssen Sie diesen Schritt trotzdem wieder ausführen! Ansonsten erhalten Sie bei der späteren Kompilierung Fehler, dass Standardbibliothek-en nicht gefunden werden. Vermutlich werden währen der Prozedur auch Änderungen am PC und nicht nur am Target vorgenommen!

10.1 Simulink-Beispielprogramm beaglebone_gettingstartedDieses Simulinkmodell lädt man mit dem Befehl beaglebone_gettingstarted im Command Win-dow. 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 [40].

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.

10.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

14 Kann auch aus dem MATLAB 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“).


.slx. Es ist sinnvoll importierte Simulinkmodelle immer als .slx-Datei abzuspeichern.

• Die Installation des „Hardware Support Package“ für den BB sollte mit Administra-torrechten ausgeführt werden.

• Bei der hier u.a. verwendeten MATLAB-Version R2015a SP1 und R2017a tauchen während der Installation sehr oft folgende Probleme auf:1) Der Download des für das SRP nicht nötigen Simulators QEMU funktioniert nicht, da der Server im Internet zu langsam ist.2) Die Installation von 7-zip funktioniert nicht, da sich eine defekte Archivdatei (7za920.zip) im Verzeichnis C:\MATLAB\SupportPackages\R2015aSP1 befindet.3) Auch wenn der BB schon das richtige Image hat, muss trotzdem der MATLAB-Befehl targetupdater ausgeführt werden, da er vermutlich auch am PC und nicht nur am Target BB etwas ändert.

11 Programmieren des BB über SimulinkDie Skriptsprache Python ist wegen der langsamen Ausführungsgeschwindigkeit grundsätzlich nicht geeignet, um das Roboterfahrzeug zu steuern. Im SRP wird Python verwendet, um die Sensoren zu testen. Im nächsten Schritt werden die Sensoren dann über C-Programme getestet, welche mit Cloud9 editiert und anschließend auf dem BB kompiliert (siehe Kapitel 9).Für komplexe C-Programme wie die Robotersteuerung als Echtzeitanwendung kann man dies aber nicht mehr so machen, sondern man arbeitet auf einem (leistungsstarken) PC mit einer Entwicklungsumgebung wie Eclipse mit einem Crosscompiler.

Den C-Quellcode muss man grundsätzlich nicht selbst in Textform erstellen: Die Algorithmen des Programms werden mit Simulink grafisch als Modell in Form eines Blockdiagramms „programmiert“. Der „MATLAB Embedded Coder“ erzeugt daraus C-Quellcode und kompiliert diesen für den BB. Dann überträgt Simulink dieses ausführbare Programm auf dem BB und startet es dort. D.h. MATLAB und Simulink nimmt einem nicht nur das C-Coden sondern auch das Kompilieren ab.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.

Alternativ kann man auch ein textbasiertes MATLAB-Programm erstellen, welches über den „MATLAB-Coder“ in C-Code gewandelt wird und dann in Eclipse kompiliert und debugged wird. Dieverschiedenen Vorgehensweisen, C-Quellcode für den BB zu erstellen sind in [8] vergleichend dargestellt16.

11.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-ben Quellcodes auf einem PC.

Konkret in der Automobilentwicklung führte dies dazu, dass immer wieder eine neue Software auf

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


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.


Abbildung 24: 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. Zusätzlich kann das Simulinkmo-dell MATLAB-Code („MATLAB Function Block“) enthalten. Dann baut der Simulink Coder auf den MATLAB Coder auf.

unterschiedlich je nach Target

Simulink Modell(bzw. MATLAB-Code) C-Quellcode Compiler für

BeagleBone

AusführbaresProgramm

BeagleBone

„Simulink Coder“ bzw. „MATLAB Coder“

Erweiterung: „Simulink Embedded Coder“ bzw. „MATLAB Embedded Coder“

Simulation auf PC Verhalten auf BB Verifikation FunktionEmbedded Code

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 Syntaxfehler beim Eintippen von Quellcode vermieden, der Code entspricht besser einzuhaltenden Standards und ist auch sonst weniger fehlerträchtig.Bei Simulink wird die Codegenerierung „Simulink Coder“ genannt. Gleiches gibt es auch bei MAT-LAB: Hier kann mit dem „MATLAB Coder“ aus einem einfacher zu erstellendem 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 etwas komplizierter. Denn hier müssen z.B. I/Os bedient werden, und es gibt unter Umständen gar kein Betriebssystem. Trotzdemsoll 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 MATLAB-Code beinhalten. Man nennt sie dann „Simulink MATLAB Function Block“. Dieser MATLAB-Code kann wiederum C-Code enthalten. Oder ein Simulinkblock enthält direkt C-Code, was als „S-Function Block“ bezeichnet wird.

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 MATLAB-Programm heraus, oder einfach di-rekt aus eingebundenem C-Quellcode (entweder in einem Simulinkblock oder in einem MATLAB-Programm) heraus gewonnen wird, ist für den Compiler weitgehend egal.


Abbildung 25: 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

Autom

. Co

d egene rierun

g

QuellcodedateiHeaderdateiMakedatei

PlattformunabhängigeAssemblerdatei

PlattformspezifischeObjektcodedatei

Plattformspezifischeausführbare Datei

Kompletter Quellcode in einer Datei

In der Grafik in Abb. 24 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. 25 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“.

11.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 10.1 beschrieben kann man über den Schalter „Deploy to Hardware“ das Mo-dell auf den BB starten, wo es völlig autark läuft, bis es über den Befehl stopModel(meinModell) im Kommandofenster von MATLAB wieder beendet wird, falls eine unendliche Ausführungszeit ein-stellt 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.

11.3 Simulink-Beispielmodelle

11.3.1 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 BB_Blink im normalen Modus („Deploy to Hardware“) gestartet.

11.3.2 Beispielmodell: Analogspannung auslesen (ADC).

Analog wie im entsprechenden Pythonbeispiel wird an dem Steckplatz „Analog Input“ 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 Simulink-Scope dargestellt werden.

Da der Spannungswert am Potentiometer im Scope des Simulinkmodells angezeigt werden soll,


Abbildung 26: Screenshot des Simulinkmodells BB_ADC. Die Eingangspannung wurde durch Drehen des Potentiometers verändert.

muss dieses Modell im „External Mode“ gestartet werden. Dies geschieht durch Klicken des grü-nen „Run“-Schalters.

In Abb. 26 ist ein Screenplot dieses Beispielmodells BB_ADC dargestellt. Die Eingangspannung wurde durch Drehen des Potentiometers verändert.

In einem weiteren Beispielmodell BB_LED 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 Potentiometer einstellen. Wurde das früher nicht einmal viel einfacher gemacht?

11.4 Neue Sensoren mit über digitale Schnittstellen ansteuernHierfür muss ein „S-Function“-Block für den betreffenden Sensor erstellt werden: Hier wird C-Codedirekt in den Simulinkblock eingebunden. Das Verwenden von „S-Functions“ ist etwas komplexer und erfordert Grundkenntnisse in C. Näheres siehe Abschnitt 12.

11.5 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-


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

Abbildung 27: Modell BB_LED: Steuerung LED-Helligkeit über Potentiometer.

he [41]. 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 MAT-LAB/Simulink-Version 2015b nicht mehr auffindbar. ;-) Razupaltuff!

b) Toggeln eines GPIOs mit der Wiederholrate:

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

11.6 Bekannte Probleme• 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.02.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.

• Bei PWM-Blöcken ist zu beachten, dass der gewählte PWM-Ausgang im DT berücksichtigt ist (siehe Abschnitt 7.2.5).

Achtung: Oft funktionieren PWM-Blöcke in Submodels nicht. In diesem Fall platzieren Sie die entsprechen-den Blöcke im Hauptmodell.

12 Verwendung selbst erstellter S-Function BlöckeMit dem „S-Function Builder Block“ kann man selbst S-Functions erstellen, die direkt mit der Peri-pherie kommunizieren. Im „S-Function Builder Block“ definiert man die I/Os und gibt C-Quellcode ein, in dem die eigentliche Funktion selbst steckt wie z.B. das Lesen auf einem I²C Bus.Die Ihnen im SRP zur Verfügung gestellten S-Fuction Builder Blöcke können Sie hierfür als Aus-gangsbasis verwenden, daraus z.B. einen Treiberblock für einen bestimmten Sensor zu schreiben.

Letztendlich kann man aber einen vorhandenen funktionierenden „S-Function“-Block aufbohren, in dem man darin (im Fall von I²C) die Sensoradresse und allgemein die Ausleseprozeduren (Schreib-/Leseprozeduren mit bestimmten Registeradressen und -werte) für den neuen Sensor an-passt. Welche Adressen verwendet werden müssen, welche Register beschrieben und ausgelesenwerden müssen, und wie die Ausgabewerte zu interpretieren sind, schaut man Sensordatenblatt oder falls vorhanden in einem Pythonskript des neuen Sensors nach. Zur Inbetriebnahme eines neuen Sensors verwendet man ohnehin Python, da dies schneller geht, weil im Internet zu fast jedem Sensor schon fertige Pythonskripte existieren und man diese Schritt für Schritt in der Python-Shell testenkann.Insbesondere beim I²C-Bus muss man beachten, ob die Registeradressen bzw. Befehle 8 oder 16 Bit groß sind, wie viele Byte nach der Messung von einer Registeradresse ausgelesen werden müssen, und wie sich der Messwert z.B. aus zwei Bytes zusammensetzt.

Ein Beispiel für die Verwendung von „S-Functions“ für den BB findet sich auch in [9] und in [8].


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. Dabei wird keine main()-Funktion verwendet, sondern ihr Quelltext steht ohne Einklammerung unter „Outputs“.

• 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.

• Die Include-Anweisungen für die nötigen C-Bibliotheken werden getrennt vom Quelltext un-ter „Libraries“ eingegeben. Bestimmte C-Header müssen hier nach der Direktive „# ifndefMATLAB_MEX_FILE“ eingegeben werden, sonst findet der S-Function Builder diese Dateien nicht.

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.

12.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 genau so in Modellen mit den Namen „..._Test.slx“ abgespei-

chert.

Einige der Blöcke haben in ihrem C-Code (Doppelklicken auf dem Block und dann die Karteikarte „Outputs“ wählen) einen Debug-Schalter für denPräprozessor: Wenn der Befehl #define DEBUG im C-Quellcode nicht auskommentiert ist, dann werden Debugmeldungen über printf() Befehle in eine log-Datei bzw. im Terminalfenster ausgegeben. Startet man ein solches Modell auf dem BB (egal ob „External Mode“ oder nicht), erscheint diese Textausgabe zur Laufzeit weder im Kommandofenster von MATLAB nochin einer zusätzlich geöffneten Linuxkonsole des BB.

In diesem Fall findet man die Debugmeldungen aus den printf() Befehlen aber in einer Log-Datei (z.B.meinModell.log), die sich im selben Verzeichnis wie das ausführbare Pro-gramm befindet. meinModell ist der Name des Simulinkmodells.


Abbildung 29: Ö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.

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 sogar beim laufenden Modell direkt über Cloud9 anzeigen lassen:

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 Cloud917 eine Linuxkonsole geöffnet. Bei Putty muss man sich explizit als root einloggen. Aus dem hone-Verzeichnis heraus wird das Modell mit Befehl ./meinModell gestartet. Dann erscheinen wie in Abb. 29 dargestellt die Debugmeldungen aus den printf() 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 meinModell unter Simulink nicht im „Exter - nal 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 meinModell die Berechtigung geben, von allen Usern ausgeführt zu werden.

Tipp:Die Debugmeldungen möglichst ausschalten, damit die höchst mögliche Wiederholrate erreicht werden kann.

12.2 Im Praktikum verfügbare S-Function Builder Blöcke und Beispielmodelle

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 Enable-Eingang dient dazu, die Ausführung des Blocks während des laufenden Modells ein- und auszus-chalten.

12.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

Eingangsignale Parameter Ausgangssignale

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

• Auszulesende Register-adresse (Dec)

• Nummer des I²C-Busses (Dec)

• Gelesener Wert (Hex)

Modellname: BB_I2C_Read_SfctnB_Test.slx

12.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


• Enable (Boolean) • I2C-Adresse des Periphe- • Rückgelesener Wert aus

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


• Zu schreibender Wert(1 Byte)

riegeräts (Dec)• Auszulesende Register-

adresse (Dec)• Nummer des I²C-Busses

(Dec)

dem Register (1 Byte)

Modellname: BB_I2C_Write_SfctnB_Test.slx

12.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


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

• Gelesener Wert des GPIOs (Boolean)

Modellname: BB_GPIO_Read_SfctnB_Test.slx

12.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


• Enable (Boolean)• Zu schreibender Wert

(Boolean)

• Nummer des GPIOs (Dec)Die Zuordnung zum physi-kalischen 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_Test.slx

12.2.5 HCM5883L AMR 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


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


• Sensorparameter fest in C codiert.

• Magn. Flussdichte X (µT)• Magn. Flussdichte Y (µT)• Magn. Flussdichte Z (µT)• Gesamte Flussd. (µT)• Winkel zur Nordrichtung (°)

(jeweils Double)

Modellname: BB_HMC5883L_SFctnB_Test.slx

12.2.6 SRF02 Ultraschallsensor auslesen (I²C)

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

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_Test.slx

12.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




• 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_Test.slx

12.2.8 TOF-Sensor VL53L0X auslesen (I²C)

Ausgabe des aktuell gemessenen Abstandswerts.S-Function Builder Block Name: BB_VL53L0X




• Abstandswert (Dec)Werte als 16 Bit Ganzzahl in mm

Modellname: BB_VL53L0X_SFctnB_Test.slx

12.2.9 Farbsensor TCS34725 auslesen (I²C)

Ausgabe des aktuell gemessenen Helligkeitswerte für die Pixel in Rot, Grün, Blau und die farblo-sen Pixel (Clear).S-Function Builder Block Name: BB_TCS34725


• Enable (Boolean) • I2C-Adresse des Periphe-riegeräts (Dec)Nummer des I²C-Busses (Dec)

• Helligkeiten für Rot, Grün, Blau und Clear

Modellname: BB_TCS34725_SFctnB_Test.slx

12.2.10 Maussensor AADNS3080 auslesen (SPI)

Ausgabe des aktuell gemessenen Versatzes Delta_X und Delta_X sowie der Signalqualität, die im Wesentlichen durch die Ausleuchtung der anvisierten Oberfläche bestimmt wird.

Achtung: Deltawerte 0 bedeutet, dass der Sensor keine Bewegung erkannt hat.

S-Function Builder Block Name: BB_ADNS3080



• Enable (Boolean) Keine • Delta_X, Delta_Y und Si-gnal Quality

Modellname: BB_ADNS3080_SFctnB_Test.slx

12.2.11 Gestensensor APDS-9960 (I²C)

Ausgabe der aktuell gemessenen Helligkeiten der vier unterschiedlich ausgerichteten PhotodiodenU(p), D(own), L(eft) und R(ight), welche zusammen mit der LED eine Art Triangulationssensor/Lichttaster bilden. Es wird jeweils in einem Array mit 32 uint8 Helligkeitswer-ten der zeitliche Verlauf ausgegeben.

S-Function Builder Block Name: BB_APDS9960Eingangsignale Parameter Ausgangssignale

• Enable (Boolean) Keine • outUData[], outDData[], outLData[], outRData[]

Modellname: BB_APDS9960_SFctnB_Test.slx

12.2.12 Besipielmodell Modellbauservo ansteuern (PWM)

Stellen des Servoarms in Bereich von 0...180 Grad.Modellname: BB_PWM_Servo_SFctnB_Test.slx

12.3 Bekannte Probleme• Beim S-Function Builder Block unter „Parameters“, Registrierkarte „Data Type Attributes“

muss für den Enable-Eingang „boolean“ ausgewählt sein. Ist hier z.B. „double“ ausgewählt, wird der analoge Eingang evtl. nicht richtig funktionieren.Simulink gibt hier nicht unbedingt eine Fehlermeldung aus!

• Der Quelltext des Hauptprogramms (normalerweise innerhalb der main()-Funktion) steht unter „Outputs“ ohne diesen Funktionsnamen und auch ohne geschweifte Klammern.

• Werden beim S-Function Builder während des Buildprozesses Headerdateien nicht gefun-den, dann kann das daran liegen, dass diese unter „Libraries“ nicht innerhalb der Direktive „# ifndef MATLAB_MEX_FILE“ stehen.

• Bisher wurden nur C und nicht C++ Quelltexte in SFBB getestet. Es ist ratsam das C-Pro-gramm vorher getrennt in der Linuxkonsole oder via Cloud9 zu testen:In der Kommandozeile wird ein C-Quelltext beispiel.c mit gcc beispiel.c -lm -o beispiel kompiliert.Das damit erzeugte ausführbare Programm wird mit ./beispiel gestartet.

• Im C-Code sind manchmal usleep() Anweisungen enthalten. Die Sampletime muss deut-lich größer als die Summe aller dieser Anweisungen sein, damit der Code überhaupt wäh-rend einer Sampletime ausgeführt wird.

• Beim S-Function Builder Block werden die I²C-Adressen in Dezimalschreibweise angege-ben. Bei einigen Sensoren kann man die I²C-Adresse dauerhaft ändern - daher vorher im-mer in der Linuxkonsole den Sensor innerhalb des I²C-Busses identifizieren.

13 Daten in die Cloud an ThingSpeak senden und dort verar-beiten

Über den Simulink-Bllock „ThingSpeak“ können in zyklisch (minimal alle 15 Sekunden) Daten aus dem Simulinkmodell in den Webservice ThingSpeak hochgeladen und dort grafisch dargestellt undanalysiert werden.

Für den Zugriff auf ThingSpeak benötigen Sie ein MATLAB-Konto, das gleichzeitig auch ein ThingSpeak-Konto ist. Im ThingSpeak Webservice erstellen Sie dann für Ihre Daten einen neuen


„Channel“, geben diesem einen Namen und legen fest wie viele Felder (= Tabellenspalten) Sie be-nötigen. Ein Channel ist also nichts anderes als eine Tabelle in deren ersten Spalte die Zeitpunkte der Datenübertragung und in den weiteren Spalte die verschiedenen Messwerte stehen. Diese Zeitverläufe werden dann grafisch dargestellt und können im Webservice ThingSpeak mit MATALB-Befehlen analysiert werden.

Im Simulink-Bllock „ThingSpeak“ müssen Sie dann nur noch den sogenannten API-Key angeben, über den die von Ihnen hochgeladenen Daten dem richtigen Channel zugeordnet werden.

Der Simulink-Bllock „ThingSpeak“ der Version 2017a funktioniert nicht. Zur Behebung dieses Bug muss wie folgt vorgegangen werden:

Im MATLAB Command Window den Befehl

cd(fullfile(codertarget.arm_cortex_a.internal.getSpPkgRootDir, '+codertarget', '+arm_cortex_a', '+blocks'))

eingeben.

In das dadurch im MATLAB Explorer geöffnete Verzeichnis die Datei ThingSpeakWrite.p durch die gleichnamige neuere Datei aus Relax ersetzen. Anschließend unter MATLAB den Befehl re-hash toolboxcache und abschließend MATLAB neu starten.

Als Beispielmodell für die ThingSpeak finden Sie unter Relax das Modell BB_ThingSpTCS34725. Hier müssen Sie den API-Key noch anpassen. Weiter muss der BB Zugriff auf das Internet haben, um die Messdaten hochzuladen.

Wenn im Block „Print diagnostic messages“ aktiviert ist, dann können Sie beim laufenden Modell im Log-File nachschauen, ob die Kommunikation mit ThingSpeak funktioniert. In diesem Fall wird nach „ThingSpeak response:“ eine fortlaufende Zahl ausgegeben.


14 Anhang

14.1 Pinbelegung (Quelle [3])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 [21].


14.2 Das Grove Cape Version 1 (schwarz) (Quelle [12])

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

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.

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. Bei 5 V VCC wird der komplette der Full Scale Range des 12 bit ADCs von 0...1800 mV genutzt, bei 3,3 V ein entsprechend kleinerer Bereich.Egal welche VCC auf dem Cape gewählt ist, sind die Schnittstellen des BB vor einer falschen Spannung geschützt. Die VCC-Einstellung ändert jedoch nicht die Pegel der digitalen Ausgänge.

Achtung: Die Buchsenleiste J8 entspricht P9 und die Die Buchsenleiste J9 entspricht P8!

Achtung:Bitte beachten Sie, dass dies ausschließlich nur für diese Pins der Buchsenleisten des BB gilt!Verwenden Sie daher als Eingänge ausschließlich die Grove-Stecker!


14.3 Das Grove Base Cape Version 2 (grün) (Quelle [42]) Dies ist eine Weiterentwicklung der Version 1 des Grove Capes. Es besitzt ein EE-PROM, 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 ei-nen Verstärker geführt. Der Verstärkungs-faktor ist jedoch unabhängig von VCC. Die digitalen Ein- und Ausgänge laufen nicht mehr über Klemmdioden sondern über Pe-gelwandler.


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

Normalerweise wird die Cloud9 IDE so ver-wendet, dass sich der Server mit allen Quellcodedateien und Bibliotheken im Internet 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 lokalen IDE (z.B. Arduino IDE) auch macht.

Der Vorteil hierbei liegt im Wesentlichen dar-in:

1) Man greift mit allen internetfähigen Gerä-ten immer auf die aktuellen Quellcodes zu.

2) Mehrere Programmierer können von be-liebigen Orten aus an einem gemeinsamen Projekt arbeiten.

3) Der Cloud Service kümmert sich um die Bereitstellung der Bibliotheken.

4) Man kann den Quellcode in der Cloud auf verschiedenen Systemen testen.

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

Beim BB wird die Cloud9 IDE jedoch ganz anders genutzt:

Hier befindet sich der Cloud9-Server nicht im Internet son-dern lokal auf dem BB. Sie rufen diese IDE auch in Ihrem 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 er-zeugten 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 SYSTEMIhres Workspaces der Cloud9 IDE kopieren, wie in Abb. 30dargestellt.

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 Da-tei oder ein Verzeichnis auf den PC heruntergeladen wer-den (siehe Abb. 31).


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

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

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

14.5 GlossarToolchain:Hierunter versteht man die „Kette aus Werkzeugen“, diebenötigt wird, um ein Programm für ein eingebettetes Sys-tem zu schreiben, zu kompilieren, auf das System zu über-tragen und dort zu debuggen.

Cross Compiler:Der Compiler erstellt aus einem Quellcode ein ausführba-res Programm. Dies geschieht meistens auf einem PC,wobei das ausführbare Programm ebenfalls für eine PCgedacht ist. Im Praktikum wird auf dem Windows-PC derQuellcode erstellt, das ausführbare Programm muss abernicht für Windows sondern für das Linuxbetriebssystemdes BB kompiliert werden. Daher der Begriff „Cross“.

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

Host Computer:Der PC, an dem der BB via USB oder Ethernet ange-schlossen ist, wie es beispielsweise bei der Programmie-rung 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.

Image:Hiermit ist also 1:1 bitweise Kopie des Speichermediums des BB gemeint. Ein Image kann aus dem Internet herunter geladen werden und auf die SD-Karte bzw. den eMMC des BB übertragen werden. Umgekehrt kann man den Ist-Zustand des Speichermediums des BB als Image auf einen PC sichern und ihn von da auf SD-Karten anderer BB klonen.


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

14.6 Übersicht BB Hardware (Quelle [22])


14.7 Pinkonfiguration (Quelle [22]), siehe auch [21].



14.8 Nano Cheat Sheet [43]


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:

Â move to beginning of line

Ê 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

14.9 Linux Cheat Sheet [44], alternativ [45]


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

âbc^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 file

Cut and Paste

ALT-A Start marking text

CTRL-K Cut marked text or line

CTRL-U Paste text

Navigate File

ALT-/ End of file

CTRL-A Beginning of line

CTRL-E End of line

CTRL-C Show line number

CTRL-_ Go to line number

Search 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.)

14.10 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 magicU-Boot 2015.10-00001-g143c9ee (Nov 06 2015 - 15:27:19 -0600), Build: jenkins-github_Bootloader-Builder-274 Watchdog enabledI2C: readyDRAM: 512 MiBReset Source: Power-on reset has occurred.MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1Using default environmentNet: <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 rorootfstype=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 ... OKStarting kernel ...

14.11 Paketmanagement über aptNachfolgend sind die wichtigsten Befehle für das Paketmanagement via apt aufgeführt. Der Platz-halter MeinPaket steht für ein 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

Hilfe zu apt aufrufen apt-get help

14.12 Umgang mit Linuximages auf SD-KartenEin „frisches“ allgemeines Linux-Image kann unter beagleboard.org/latest-images heruntergeladenwerden. Hierfür ist unbedingt das schon ältere Image „Debian 7.9“ auszuwählen.

Um dieses Linuximage dann unter Simulink zu verwenden, muss es noch modifiziert werden, das durch den MATLABbefehl „targetupdater“ geschieht, siehe Abschnitt 10.

Das fertige Image für das SRP finden Sie als Download unter Relax.

14.12.1 Inhalt des eMMC komplett auf SD-Karte sichern (automatisch nach Booten auf entsprechend präparierter SD-Karte):

Details siehe [46].

Bemerkung: Unter Windows 7 wird DISKPART verwendet, um auf der SD-Karte ein FAT-Partition zuerstellen und diese zu aktivieren. DISKPART startet man in der Windows-Eingabeaufforderung. Wenn sich vorher eine Linuxpartition auf der Karte befand, dann reicht oft das Formatieren über den Windows Explorer nicht aus, um wieder den vollen Speicher der SD-Karte nutzen zu können.

Eventuell muss also die Größe dieser Partition noch erhöht werden. Es ist dabei ratsam nicht zu 100 % den vorhandenen Speicherplatz der Karte auszunutzen, da dies später beim Klonen auf no-minell gleich große Karten zu Problemen führen kann.

Danach wird das entpackte Image von der o.g. Webseite auf die SD-Karte mit Win32DiskImager übertragen.

Dann wird im Wurzelverzeichnis der Device Tree in am335x-bonegreen.dtb umbenannt. Dort auf der SD-Karte wird nun das Verzeichnis dtbs erzeugt und der umbenannte Device Tree dort hinein kopiert. (Zusätzlich wird er im Wurzelverzeichnis / belassen)

Die Datei uEnv.txt wird mit den Zeilen mmcdev=0 und mmcpart=1 erweitert.

Bei so konfigurierter SD-karte im BB nach Power Up (und gleichzeitig S2 gedrückt) geht dieser kurz an und schaltet sich danach wieder aus.

Nach erneutem Drücken der Powertaste am BB startet der Backupvorgang.Dieser wird über das gleichmäßige Blinken (also kein Herzschlag) der äußeren Vierer-LED ange-zeigt.

Wenn der Backupvorgang nach ca. 5-20 Minuten beendet ist, leuchtet diese LED kontinuierlich. Dann wird der BB über die Power-Taste ausgeschaltet und die SD-Karte entnommen.

Dort befindet sich dann unter dem Dateinamen BeagleBoneBlack-eMMC-image-XXXXX.img.gz (XXXXX ist eine Zufallszahl) das gepackte Image des eMMC.

Dieses Image müssen Sie auf dem PC z.B. mit 7-zip zuerst entpacken, bevor Sie es mit Win32-DiskImager auf eine SD-Karte übertragen können.

14.12.2 Partition auf SD-Karte vergrößern

Details siehe [47].

Die verfügbaren BB Images sind für 4 GB Speicherkarten ausgelegt.

Haben Sie ein solches Image auf Ihre SD-Karte übertragen, so wurde dieses Dateisystem 1:1 auf


die Speicherkarte kopiert. Das bedeutet, dass dort je eine Windows- und eine Linuxpartition ge-schrieben wurden, die zusammen knapp 4 GB groß sind, auch wenn Ihrer SD-Karte über wesent-lich mehr Speicherplatz verfügt.

Nachfolgend wird beschrieben, wie man die Linuxpartition vergrößern kann, wenn die Speicherkar-te mehr als 4 GB Speicher besitzt.

Achtung: Ein Verkleinern der Linuxpartition (auch sofort nach einer Vergrößerung) ist übrigens nicht ohne Weiteres möglich.Beachten Sie bitte, dass das Image der vergrößerten Linuxpartition dann auch nicht mehr auf eine 4 GB SD-Karte übertragbar ist, auch wenn davon nur 2 GB belegt sind. Denn das Schreiben eines Images ist ein bitweises Kopieren von einem Datenträger auf einen anderen. Dabei werden die 2 GB mit Daten genau so übertragen wie die restlichen 2 GB ohne Daten.Zu beachten ist auch die Tatsache, dass verschiedene 4 GB SD-Karten einen leicht unterschiedli-chen Gesamtspeicher besitzen. Füllt ein Image eine Karte komplett aus, dann passt es vielleicht nicht auf eine andere Karte gleicher Größe, weil nur wenige Bytes dort fehlen.

Haben Sie von einer SD-Karte aus gebootet, dann wird mit dem Befehl df -h / die aktuelle Grö-ße Linuxdateisystems ausgegeben.

root@beaglebone:~# df -h /Filesystem Size Used Avail Use% Mounted on/dev/disk/by-uuid/d273b6b1-534e-4818-8b38-69ddf0e96000 3.4G 2.0G 1.3G 62% /

In dem hier vorliegenden Fall wurde das Image auf eine 8 GB große Speicherkarte übertragen. Neben dieser Linuxpartition gibt es noch eine Windowspartition, die sich beim Anschließen des BB am PC ähnlich wie ein USB-Stick meldet.

Um beide (alle) Partitionen anzuzeigen oder zu ändern, verwendet man das Programm fdisk,

wobei /dev/mmcblk0 der Pfad der SD-Karte ist.

fdisk /dev/mmcblk0

Mit dem Befehl p unter fdisk wird die aktuelle Partitionstabelle dargestellt:

Command (m for help): pDisk /dev/mmcblk0: 7964 MB, 7964983296 bytes4 heads, 16 sectors/track, 243072 cylinders, total 15556608 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesDisk identifier: 0x00000000

Device Boot Start End Blocks Id System/dev/mmcblk0p1 * 2048 198655 98304 e W95 FAT16 (LBA)/dev/mmcblk0p2 198656 15556607 7678976 83 Linux

Wenn wie hier mit 7964 MB noch Platz auf der SD-Karte ist, dann kann die derzeit nur 3,4 GB gro-ße Linuxpartition noch erweitert werden.Dafür ist wie folgt vorzugehen:

Zuerst löscht man die Partition die man vergrößern möchte (Nummer angeben, hier 2, siehe Aus-gabe von fdisk oben) mit dem Befehl d unter fdisk:

Command (m for help): dPartition number (1-4): 2

Danach erstellt man diese Partition unter fdisk neu:

Command (m for help): nPartition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions)Select (default p): p


Bei den restlichen Optionen wählt man die Defaultwerte. Danach kann man mit dem Befehl p wie-der die aktuelle Partitionstabelle anzeigen lassen.

Anschließend werden die gemachten Änderung mit dem Befehl w unter fdisk gesichert:

Command (m for help): wThe partition table has been altered!Calling ioctl() to re-read partition table.WARNING: Re-reading the partition table failed with error 16: Device or resourcebusy.The kernel still uses the old table. The new table will be used at the next re-boot or after you run partprobe(8) or kpartx(8)Syncing disks.

Dann muss der BB neu gestartet werden (Befehl reboot).

Der nutzbare Speicherplatz auf der SD-Karte wurde mit den Befehlen zuvor schon maximiert. Nun muss aber noch die Linuxpartition selbst vergrößert werden:Deren Größe wird mit resize2fs -p /dev/mmcblk0p2 automatisch auf den maximal verfügbaren Platz eingestellt.Man kann aber auch die Partition auf eine vorgegebene Größe einstellen, z.B. 4 GB wie im nach-folgenden Beispiel:

resize2fs -p /dev/mmcblk0p2 4GAchtung:Man kann mit resize2fs aber nicht eine Partition verkleinern. Dies müsste man unter fdisk ma-chen, wovon aber abzuraten ist, da dies regelmäßig zu einem zerschossenen Betriebssystem führt.

Abschließend kann man mit df -h / das Ergebnis überprüfen (hier für eine Vergrößerung auf 4 GB):

root@beaglebone:~# df -h /Filesystem Size Used Avail Use% Mounted on/dev/disk/by-uuid/d273b6b1-534e-4818-8b38-69ddf0e96000 3.9G 2.0G 1.8G 54% /

14.13 Linuxdatei /etc/network/interfaces# This file describes the network interfaces available on your system# and how to activate them. For more information, see interfaces(5).# The loopack network interfaceauto loiface lo inet loopback# The primary network interface#auto eth0allow-hotplug eth0iface eth0 inet dhcp# Example to keep MAC address between reboots#hwaddress ether DE:AD:BE:EF:CA:FE# The secondary network interface#auto eth1#iface eth1 inet dhcp# WiFi use: -> connmanctl#auto wlan0allow-hotplug wlan0iface wlan0 inet dhcp wpa-ssid "Sensor1" wpa-psk "0123456789"# Ethernet/RNDIS gadget (g_ether)# Used by: /opt/scripts/boot/autoconfigure_usb0.shiface usb0 inet static address 192.168.7.2


netmask 255.255.255.252 network 192.168.7.0 gateway 192.168.7.1

14.14 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 Li-nuxkonsole 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.

14.15 Kommunikationsmöglichkeiten mit dem BBUm den BB zu programmieren oder für die Fehlersuche muss man mit ihm via Tastatur und Bild-schirm kommunizieren. Dafür gibt es eine Reihe verschiedener Möglichkeiten, die in der nachfol-genden 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 Mo-nitor di-rekt

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öglichkeit um Boot-meldungen zu empfan-gen

14.16 Fachbücher zum BB

Buch Bemerkung

BeagleBone Cook-book [4]

Behandelt überwiegend BoneScript in Form von Projektanleitungen, jedoch gutes Kapitel „Real-Time I/Os“ in dem die verschiedenen Möglichkeiten der PRU-Nutzungsowie spezielle C-Bibliotheken vorgestellt werden (z.B. PRU Speak).

BeagleBone For Dummies [5]

Neben BoneScript gute Einführung in Python (mit BBIO Adafruit Bibliothek), an-sonsten aber zum größten Teil Makerbuch mit vielen konkreten Projekten aber we-nig Tiefe.

30 BeagleBone Black Projects for the Evil Genius [48]

Reines Makerbuch überwiegend basierend auf BoneScript, konkrete Bauanleitun-gen mit wenig Tiefe.

BeagleBone Home Automation[49]

Verwendet Python und befasst sich mit Server-Client Kommunikation, Android wird ebenfalls berücksichtigt. Jedoch nur wenige Infos bezüglich I/Os.

BeagleBone Robotic Projects [50]

Verwendet Python und Bildverabeitung (OpenCV über Python). Wenig Tiefe da mehr Makerbuch mit Anleitung für Robotikprojekte.

BeagleBone Black Cookbook [7]

Verwendet BoneScript, C-Programmierung und Python (mit BBIO Adafruit Biblio-thek), gutes Kapitel 6 zu RealTime I/Os auch mit PRU (PyPRUSS), SDR-Beispiel. Inhaltlich mit mittlerer Tiefe, jedoch immer noch recht unstrukturiertes Makerbuch

Programming the BeagleBone [51]

Makerbuch mit BoneScript und Python (mit BBIO Adafruit Bibliothek), ein wenig IoT mit REST-API. Insgesamt aber wenig Inhalt und Tiefe.

Exploring the Beag-leBone [2]

Mit Abstand das umfassendste, am besten strukturierte und umfangreichste Buch zum BB. auf den zugehörigen Internetseiten [3] finden sich viele Videos,Codebeispiele und Aktualisierungen. Dieses Buch ist ein Muss, wenn man sich ernsthaft mit dem BB befasst.


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

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

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

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: Setting up a Raspberry Pi as a WiFi access point: learn.adafruit.com/setting-up-a-raspberry-pi-as-a-wifi-access-point/overview. Letzter Aufruf 11/2016.

15: Raspberry Pi: Netzwerk-Konfiguration: netzmafia.de/skripten/hardware/RasPi/RasPi_Network.html. Letzter Aufruf 11/2016.

16: Setting up WiFi with BeagleBone Black: learn.adafruit.com/setting-up-wifi-with-beaglebone-black/overview. Letzter Aufruf 11/2016.

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

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

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

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

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

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

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

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

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

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

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

28: Beispiele Quellcode von DTOs: github.com/beagleboard/bb.org-overlays/tree/master/src/arm. Letzter Aufruf 09/2016.

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


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

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

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

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

34: Adafruit BMP Python Library: learn.adafruit.com/using-the-bmp085-with-raspberry-pi/using-the-adafruit-bmp085-python-library. Letzter Aufruf 01/2016.

35: Woyand, H.-B.: Python für Ingenieure. Hanser Verlag, München, 2017.

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

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

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

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

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

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

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

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

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

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

46: BeagleBone Black Extracting eMMC contents: elinux.org/BeagleBone_Black_Extracting_eMMC_contents. Letzter Aufruf 11/2016.

47: Beagleboard: Expanding File System Partition On A microSD: elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD. Letzter Aufruf 11/2016.

48: Rush, C.: 30 BeagleBone Projects for the Evil Genius. Mv Graw Hill Education, New York, 2014.

49: Lumme, J.: BeagleBone Home Automation. Packt Publishing, Birmingham, 2013.

50: Grimmet, R.: BeagleBone Robotic Projects. Packt Publishing, Birmingham, 2013.

51: Chavan, Y.: Programming the BeagleBone. Packt Publishing, Birmingham, 2016.
