Embedded Linux SS 2014

Transkript

1 Baulicht Embedded Linux SS 2014 Christoph Keller Pascal Schmid Fabian Weisshaar Projektbeschreibung Unser Setup Hardware Programmierumgebungen PyCharm Android Studio Qt Creator Entwicklung Aufbau der Hardware Aufsetzen des Toolchains Genauer Überblick der Dienste Webseite RESTful API PyBaulicht (MiddleWare) Android App Command Line Interface Ausgabe per Qt (Output Service) D Bus Einführung zu D Bus Busse Konfiguration Verbindungen Object Model Objekte Proxies Methods Signale Interfaces Basistypen Containertypen D Bus Tools Unsere definierten Interfaces Das aufgebaute Baulicht Geplante Erweiterungen Ausblick in die Zukunft 1

2 Projektbeschreibung Unser Projekt umfasst eine Schnittstelle, durch die man ein Baulich zum Darstellen von Text bzw. Morsen verwenden kann. Hierzu verwenden wir folgende verbreitete Techniken: D Bus: Einer der wichtigsten Systemdienste auf jedem Linux. Der D Bus Messagebus bietet Programmen die Möglichkeit, miteinander zu kommunizieren. Der Kommunikationspartner muss hierbei nicht immer direkt bekannt sein, da man auch ähnlich wie in einem Netzwerk Signale aussenden kann, um andere Teilnehmer über Geschehnisse zu informieren. Dienste, die D Bus implementieren, können sehr gut über die Kommandozeile getestet werden. Auf diesem Weg integrieren sie sich perfekt in die Linux Umgebung, da hier auch über Bash Skripte Dienste getestet werden können. Python: Python ist eine sehr beliebte Programmiersprache, die wenig Overhead besitzt und auch direkt C Bibliotheken verwenden kann, sollte doch einmal ein gewünschtes Modul fehlen. Die Sprache eignet sich sehr gut für Webdienste, da hier sehr viel zur Laufzeit angepasst bzw. erzeugt werden kann. C++/Qt: Das C++ Framework Qt bietet von Haus aus guten Support für D Bus auf Hochsprachenniveau. Andererseits kann man die GPIO Ports falls nötig doch direkt in C programmieren. Aufgeteilt wird das Projekt in drei Bereiche: API Service: Dies ist ein Webservice, der auf dem embedded Gerät läuft und eine HTTP Schnittstelle anbietet, mit der man die angebotenen Dienste steuern kann. Über diesen Webservice können auch noch weitere Anbindungen wie z.b. eine Smartphone App ermöglicht werden. Middleware Service: Dieser Dienst läuft ebenfalls auf dem embedded Gerät und bietet eine System Schnittstelle, die über einen D Bus Dienst bereitgestellt wird. Hier ist auch die eigentliche Logik des gesamten Projekts enthalten. Output Service: Der Middleware Service kommuniziert mit dem Output Service ebenfalls über die D Bus System Schnittstelle. Hier werden die eigentlichen Ausgabe aktionen durchgeführt. Wird das anzusteuernde Gerät ausgetauscht oder soll ein weiteres hinzugefügt werden, so muss nichts an der Middleware angepasst werden. 2

3 Unser Setup Hardware Als embedded board haben wir uns für das Raspberry Pi entschieden, da dieses Gerät jeder von uns bereits zuhause hat und wir so einzelne Module auch ohne ein gemeinsames Treffen weiter entwickeln bzw. testen können. Das Board in der von uns verwendeten Fassung (Model B) hat die folgenden Hardwaremerkmale: Dimensions 85mm x 56mm Chip Broadcom BCM2835 SoC full HD multimedia applications processor CPU 700 MHz Low Power ARM1176JZ F Applications Processor GPU Dual Core VideoCore IV Multimedia Co Processor RAM Storage USB 2.0 Ethernet Video Connections 512 MB 400 MHz SDCard 2x USB Ports 1x 10/100mb Ethernet RJ45 Jack HDMI, Composite RCA Supported Resolutions to , including 1080p, PAL & NTSC standards Audio Multi Channel HD Audio over HDMI, Stereo from 3.5 mm jack Operating Systems Raspbian, RaspBMC, Arch Linux, Risc OS, OpenELEC, Pidora Power Draw / voltage 750mA up to 5V 3

4 GPIO 26 Other Connectivity 1x CSI 2 for Raspberry Pi camera modules 1x DSI for Raspberry Pi displays Power Source 1x Micro USB (Quelle: ?ICID=RPi modelbplus compchart) Für uns war der ausschlaggebende Grund für dieses Board und Model der vorhandene Netzwerkanschluss, den wir für die Eingabemöglichkeit gewollt haben. Programmierumgebungen 1 Für den Django und Python teil haben wir PyCharm von Jetbrains verwendet, da die Hochschule hierfür Lizenzen hat (es gibt auch eine Open Source Community Edition, die unter der Apache Lizenz steht) und wir damit schon Erfahrungen hatten. 2 Für alles was C und C++ (samt Qt) anbelangt haben wir den Qt Creator genommen auch mit dem Hintergrund der vorhandenen sehr guten Erfahrungen. Er unterstützt das automatische Hochladen des Binarys auf das Board und remote debugging per GDB. 3 Die App für Android haben wir mit Hilfe des Android Studio entwickelt, welches ebenfalls aus der Softwareschmiede Jetbrains entspringt project.org/wiki/category:tools::qtcreator 3 4

5 PyCharm Für die Webseite haben wir Django benutzt. Damit man die Webseite starten kann, braucht man folgende Abhängigkeiten zu Python 2.7: django django bootstrap form djangorestframework pybaulicht (für die Ansteuerung des D Bus Dienstes) Die nicht im Projekt vorhanden (die ersten 3 Abhängigkeiten) kann man mit pip (einer Paketverwaltung für Python) auf folgende Weise installieren: # sudo pip install django django bootstrap form djangorestframework PyCharm mit dem geöffneten Message model (Webinterface/) 5

6 Android Studio Um sein Projekt zu testen, braucht man entweder ein virtuelles Android, dass man sich per 4 Android SDK zusammenklickt, oder man kann es mit dem Programm adb (Android Debug Bridge) auf sein physikalisches Telefon hochladen und dort remote debuggen. Android Studio mit dem geöffneten Projekt unserer Androidapp (AndroidApp/) 4 6

7 Qt Creator Qt Creator mit der geöffneten Mainfunktion unseres Baulichts (Service/) 7

8 Entwicklung Aufbau der Hardware Über die GPIOs setzen wir direkt das Signal, jenachdem, ob geradedaslicht komplett aus ist oder ein dit (kurzes Signal) bzw. ein dah (langes Signal bzw. Strich) kommt.die Länge kann durch die Variable dit (in Service/Baulichtexecutor.cpp) bestimmt werden. Ein dahist3mal so langwieein ditunddie Pause ist 7malsolang.EinePausezwischen denzeichenbestehtaus3maldemzeitintervalleinesdit5. Aufsetzen des Toolchains DownloadundInstallationdesQtCreatorsunterDebian basiertensystemen: 5 8

9 # sudo apt get install qtcreator Wenn man das Raspbian (oder irgendein anderes Linuximage für den Raspberry Pi) entpackt hat und das Image file auf eine SD Karte geschrieben hat, kann man sich das Rootfilesystem auf den Entwicklungsrechner kopieren. Sollte man keine SD Karte zur Hand haben, helfen folgende Befehle: # sudo fdisk lu disk.img Dies zeigt einem die Partitionen des Images an. Man muss sich die Sektorgröße und den Startblock der zweiten Partition (die als Linux markiert wird) merken. Die beiden Werte geben den Startblock der zweiten Partition an, den wir wieder brauchen: # sudo mount o loop,offset=$startblock image.img /mnt So kann man sich auch das Rootfilesystem kopieren. Zudem brauchen wir noch diverse Pakete, die zur Emulation des Geräts dienen: # sudo apt get install scratchbox2 qemu user static binfmt support \ # g++ arm linux gnueabi gdb Dann können wir auf dem virtuellen Gerät Einstellungen machen # cp /usr/bin/qemu arm static /mnt/usr/bin/ # sudo chroot /mnt/usr/bin # apt get install libqt4 dev gdb && exit Für die Scratchbox muss man folgende Einstellungen machen: # cd /mnt # sb2 init armel arm linux gnueabi gcc Damit qmake und make lokal im Rootfilesystem ausgeführt werden, muss man 2 Dateien erstellen, diese ausführbar machen und den eingerückten Text hineinschreiben: 9

10 # touch qmake # #! /bin/sh # sb2 qmake qt4 $@ # chmod +x./qmake # # touch make # #! /bin/sh # sb2 make $@ # chmod +x./make Möchte man die kompilierten Binaries per SSH auf das Board schicken, muss zuerst ein SSH Schlüsselpaar erzeugt werden: # ssh keygen t rsa # ssh copy id i.ssh/id_rsa.pub root@ Die Einstellungen sollten an das eigene Setup ungefähr so aussehen: Nun muss man nur noch ein sogenanntes Kit anlegen sprich eine Verbindung aus Compiler für ARM und der dazugehörigen Qt Version. Dies geht in den Einstellungen unter Compiler. Dort muss man den ARM g++ angeben, den man vorhin installiert hat, sowie die Qt Version im Rootfilesystem, die man einfügt, indem man auf das erstellte qmake file hinweist, das ebenfalls im Rootfilesystem liegt. Möchte man nun ein Projekt starten, muss in die.pro Datei (das qmake spezifische Makefile) folgendes geschrieben werden: 10

11 target.path = /root/ INSTALLS += target Genauer Überblick der Dienste Im folgenden gehen wir genauer auf die einzelnen Aufgaben und Schnittstellen der Dienste ein. Webseite Schematischer Aufbau Die in Django/Python geschriebene Webseite gibt uns die Möglichkeit von jedem mobilen Endgerät aus Nachrichten zu versenden bzw. den aktuellen Status der Nachrichten zu überblicken. Ausschnitt aus der Hauptwebseite: 11

12 12

13 Man kann sich auch die aktuelle Warteschlange anzeigen lassen: Möchte man eine Nachricht eingeben, so kann man auf der Hauptseite auf den Button Sende deine Nachricht klicken und erhält folgenden Dialog: 13

14 Die Schritte zum Webseite starten lauten wie folgt: #./manage.py syncdb (muss einmalig zum Erstellen der Datenbank ausgeführt werden) #./manage.py runserver 8080 Somit läuft der Server auf Port 8080 und man kann im Browser unter die Webseite aufrufen. Es muss außerdem noch das Output Plugin laufen, ansonsten wird die Webseite nicht gestartet. RESTful-API Diese ist Teil der Webseite. Mit einem GET Request an kann man sich die aktuellen Nachrichten in der Queue als JSON kodiertes Objekt ansehen. Ferner können mit einem POST Request auch Nachrichten an den Server gesendet werden. Durch den Einsatz der REST schnittstelle können wir Entwicklern eine API bereitstellen, mit der sie nicht über den Browser, sondern wie von uns demonstriert eine mobile 14

15 Anwendung schreiben, mit der sie den gleichen Funktionsumfang haben wie über die Webseite. PyBaulicht (MiddleWare) Damit die Webseite Zugriff auf den D Bus Daemon hat, haben wir eine Schnittstelle namens pybaulicht geschrieben, die aus 3 Komponenten besteht: 1. BaulichtDbus 2. BaulichtSettings 3. BaulichtText Während in allen dreien der Namespace definiert, sowie allgemein die Verbindung zum Bus aufgebaut wird, wird der Klasse BaulichtDbus der Text übergeben (Instanz von BaulichtText, int oder str) bzw. darin der Status verwaltet. Zudem werden hier Texte hinzugefügt, gelöscht oder aufgelistet. In den BaulichtSettings werden die Pins des Boards sowie die Länge eines dits bzw. des text spacings festgelegt. BaulichtText repräsentiert die Nachricht, die man senden möchte. Sie enthält den Text, das Erstellungsdatum sowie eine Zahl, wie oft sie wiederholt werden soll. Android App Durch die REST Schnittstelle war es uns möglich eine Android App zu bauen, mit der man Texte senden und die Queue sowie aktive Texte ansehen kann. 15

16 Hauptbildschirm Aktive Texte Warteschlange Command Line Interface Nachdem wir ganz nach Objektorientiertem Programmierparadigma eine Schichtentrennung durchgeführt haben, ist es möglich, den Service auch per CLI zu steuern. Die Hilfeausgabe lautet wie folgt: usage: baulicht cli.py [ h] [ l] [ a <string>] [ r <int>] [ s <int>] [ p {on,off}] [ pin <int>] [ status] [ start] [ stop] Baulicht command line interface to list, add, remove texts and change settings. optional arguments: h, help show this help message and exit l, list List all active texts 16

17 a <string>, add <string> Add Text to morse r <int>, remove <int> Remove Text by ID s <int>, speed <int> length of a dit in ms p {on,off}, pause {on,off} Stop morse/blink pin <int> Set GPIO Pin status Show current status start Start morse/blink stop Stop morse/blink Das Binary greift hierbei auf das von uns geschriebene pybaulicht zurück, um die Werte 6 abzufragen bzw. zu verändern sowie argparse, da es die Aufgabe des Argumenten parsens wahnsinnig einfach macht. Ausgabe per Qt (Output Service) Anfangs wollten wir auf eine vorhandene C API zurück greifen, die man unter der folgenden URL findet: Da wir die Funktionen der Schnittstelle nicht vollständig gebraucht haben, haben wir versucht direkt die Schritte in C nachzubauen, die man so auch auf der Kommandozeile ausführt. Den Port auf GPIO festlegen: # echo 7 > /sys/kernel/debug/omap_mux/gpmc_ad4 Port exportieren: # echo 36 > /sys/class/gpio/export Den Port auf Output stellen: # echo out > /sys/class/gpio/gpio36/direction Mit echo kann man nun den GPIO ein und ausschalten: # echo 1 > /sys/class/gpio/gpio36/value # echo 0 > /sys/class/gpio/gpio36/value

18 Das Ganze als C Code: if ((fp = fopen("/sys/class/gpio/export", "w")) == NULL){ printf("cannot open export file.\n"); exit(1); } fprintf( fp, "%d", 30 ); fclose(fp); if ((fp = fopen("/sys/class/gpio/gpio30/direction", "rb+")) == NULL){ printf("cannot open direction file.\n"); exit(1); } fprintf(fp, "high"); fclose(fp); if ((fp = fopen("/sys/class/gpio/gpio30/value", "rb+")) == NULL){ printf("cannot open value file.\n"); exit(1); } Da aber nach dem zweiten Versuch der Code nicht laufen wollte, hat Christoph Keller sich dazu entschlossen, dass wir das Ganze gleich in Qt schreiben. Ein zentraler Teil der Programms auf nativer Seite ist die Baulicht Klasse, in deren Header sich unter anderem folgende Qt properties finden lassen: Q_CLASSINFO("D Bus Interface", "de.naptower.baulicht") Q_PROPERTY(int mode READ mode WRITE setmode NOTIFY modechanged) Dort werden 2 wichtige Funktionen (nicht programmiertechnisch, sondern funktional gesehen) definiert: Das DBus Interface, das die Klasse implementiert Ein Modusattribut, das bei einer Zustandsänderung ein SIGNAL ausgibt, auf das ein SLOT reagiert so wird in Qt asynchroner Programmfluss realisiert 18

19 Die main Methode instanziiert eine QDBusConnection auf dem Sessionbus, wobei diese vorerst noch keine Einstellungen besitzt. Danach werden die Settings sowie das Baulicht instantiiert, welchem die Settings übergeben werden. Danach werden sowohl die Settings als auch das Baulicht als Objekt am DBus registriert. Was beide Klassen machen, lässt sich leicht an den Headern der beiden Klassen sehen: Baulicht public: enum Mode { TextMode = 0, BlinkMode = 1 }; void setsettings(settings *settings); Settings* settings() const; public slots: void setmode(int mode); int mode() const; void setpaused(bool paused); bool paused() const; QString addtext(const QString& text, int repeat); void removetext(const QString& path); QStringList texts() const; void clear(); void start(); void stop(); signals: void modechanged(int mode); void pausedchanged(bool paused); void textadded(const QString& path); 19

20 Settings public slots: void setdit(int milliseconds); int dit() const; void settextspacing(int milliseconds); int textspacing() const; void setpin(int pin); int pin() const; signals: void ditchanged(int dit); void textspacingchanged(int textspacing); void pinchanged(int pin); D-Bus Einführung zu D-Bus Was ist D Bus? Dazu die offizielle Beschreibung des Projekts: D Bus is a message bus system, a simple way for applications to talk to one another. In addition to interprocess communication, D Bus helps coordinate process lifecycle; it makes it simple and reliable to code a "single instance" application or daemon, and to launch applications and daemons on demand when their services are needed. D Bus supplies both a system daemon (for events such as "new hardware device added" or "printer queue changed") and a per user login session daemon (for general IPC needs among user applications). Also, the message bus is built on top of a general one to one message passing framework, which can be used by any two apps to communicate directly (without going through the message bus daemon). Currently the communicating applications are on one computer, or 20

21 through unencrypted TCP/IP suitable for use behind a firewall with shared NFS home directories. (Help wanted with better remote transports the transport 7 mechanism is well abstracted and extensible.) D Bus ist nur als IPC Ersatz gedacht, nicht für Kommunikation auf verschiedenen Hosts. Es ist verbindungsorientiert und hat einen Status (nicht wie bspw. UDP). Andererseits transportiert es immer Nachrichten fester Länge nicht einen Strom an Daten wie TCP. Es hat eine feste Varietät an ganzen Zahlen, Gleitkommazahlen und Strings. Dadurch kann eine falsch übertragene Nachricht erkannt werden. Für D Bus existieren diverse Bindings an Programmiersprachen, so dass niemand den C Code darunter direkt anfassen muss. In manchen Sprachen geht das sogar soweit, dass der Programmierer von D Bus gar nichts mit bekommt. Auf der offiziellen Webseite von D Bus findet sich folgender prägender Satz in der 8 Dokumentation der Referenzimplementierung : If you use this low level API directly, you're signing up for some pain. Selbst die Handhabung von D Bus mit der high level API GLIB ist immer noch sehr aufwendig und man sollte sich überlegen, ob man nicht dbus cxx oder ähnliches nimmt. Ein Beispiel für die Anwendung von D Bus ist zum Beispiel das Instant Messaging 9 Programm Pidgin, dass verschiedenste Signale aussendet und anhand derer etwa Desktopbenachrichtigungen angezeigt werden können, wenn ein Kontakt online kommt, eine Nachricht empfangen wird und ähnliches. Busse D Bus bietet 2 Arten der Kommunikation: Library oder daemon basiert. Während bei der Library theoretisch nur 2 Prozesse miteinander Daten austauschen können ist es bei der daemon basierten Kommunikation so, dass tatsächlich ein Bus bereit gestellt wird. Dadurch wird eine einmal gesendete Nachricht auf den Bus geschickt und jeder Empfänger, der sich dafür interessiert, fängt die Nachricht ab. Es ist möglich, dass mehrere Busse gleichzeitig auf einem System laufen, ohne sich gegenseitig zu stören. Unter Linux gab es zuvor immer 2 Arten von Bussen: Den Systembus, der z.b. dafür verantwortlich war, das Event eines angesteckten Geräts mit zu bekommen oder der Sessionbus, der benutzerabhängig Events verarbeitet hat. Dieser Sessionbus wurde von

22 D Bus so erweitert, dass er Benutzer unterscheiden kann und sogar dazu noch Benutzer authentifizieren bzw. eine Zugangskontrolle bereitstellen kann. Schematische Übersicht über D Bus (Quelle Bus.freedesktop.org/doc/diagram.png) Jeder Bus hat eine Adresse, die genau beschreibt, wie man sich mit ihr zu verbinden hat. Normalerweise wird das durch einen Filenamen eines Unix domain sockets wie /tmp/.socket abgebildet. Durch die D Bus API wird dies aber komplett versteckt. Konfiguration Um D Bus zu konfigurieren, muss man ein so genanntes busconfig schreiben, was wiederum in einem XML basierten Format geschrieben wird Beispiele dazu findet man üblicherweise unter /etc/d Bus 1/system.conf oder /etc/d Bus 1/session.conf im Filesystem eines jeden Linux. 22

23 Verbindungen Jede Verbindung zu D Bus kann mit einem oder mehreren Namen assoziiert werden. Diese sind als die Bus names der Verbindungen bezeichnet. Die Namen sind Namen der Verbindungen, nicht Namen der Busse. Bus names bestehen aus einer Serie von eindeutigen Kennungen, die durch Punkte getrennt werden: Sie dürfen Buchstaben, Zahlen, Striche und Unterstriche enthalten. Damit besitzt die Verbindung den bus name, wie es im D Bus jargon heißt. Wenn eine Verbindung aufgebaut wird, nimmt sich der Bus sofort einen festen bus name, die ihm solang zugewiesen bleibt, wie der Bus existiert. Dies sind die unique connection names, denn keine andere Verbindung auf dem Bus wird den gleichen bus name haben auch wenn die Verbindung getrennt wird und andere erzeugt werden. Sie können daran erkannt werden, dass sie mit einem Doppelpunkt anfangen (etwa : ). Eine Verbindung kann auch zusätzliche Namen beantragen, um z.b. einen Service unter einem bekannten Namen anzubieten, die anhand einer Konvention ausgehandelt werden: Sie müssen aus zwei oder mehr punkt separierten Elementen bestehen: de.naptower.baulicht etwa. Nur eine Verbindung kann diesen Namen auf dem Bus gleichzeitig haben, aber abgesehen von den unique connection names, können bus names auch wieder abgegeben werden und von einem anderen Client genutzt werden. Object Model Objekte Bei der Kommunikation gibt es Endpunkte, die sich Objekte nennen. Diese werden vom Clientprozess erzeugt und existieren nur innerhalb der Verbindung des Clients zum Bus. Das Objekt bietet dem Clientprozess die Möglichkeit seine Services auf dem Bus anzubieten, dabei darf jeder Client eine beliebige Anzahl an Objekten erzeugen. Jede der Nachrichten fällt in eine der 3 Kategorien: 1. Anfragen des Clientprozesses an Objekte 2. Antworten auf die Anfragen sie gehen vom Objekt zurück zum Prozess 3. One way Nachrichten, die von Objekten ausgehen. Das sind Broadcasts an jeden verbundenen Client, der Interesse an den Nachrichten angegeben hat 23

24 Jeder Bus hat mindestens ein Objekt, das den Bus selbst repräsentiert. Clients können Informationen über den Busstatus abfragen, indem sie Anfragen an das Objekt schicken. Proxies Objekte können auf dem Bus durch Referenzen angesprochen werden, die im D Bus Jargon Proxies heißen. Ob man direkt mit dem Objekt oder aber mit einem Proxy spricht, kommt auf die Abstraktionsebene an, die durch das Languagebinding gegeben ist. Objekte haben Namen, die so genannten paths. Diesen Namen haben sie erhalten, da sie wie Dateisystempfade in der Unixwelt durch Slashes getrennt werden. Ein Objektname muss nur innerhalb der Verbindung zum Bus eindeutig sein. Da jedes Objekt innerhalb eines Kontextes der Verbindung lebt, braucht es eine Kombination aus der bus name Verbindung und dem Objektnamen, um es zu finden. Sobald man dies getan hat und es nochmal benutzen möchte, wird man sich eine Variable zulegen, die den Proxy zum Objekt darstellt. In machen Languagebindings bieten Proxies failovers an. Wenn man einen Proxy hat und dieser Client sich trennt, unter dem gleichen Namen wieder verbindet und das Objekt wieder belebt, kann es sein, dass das Programm, das auf dem Proxy aufbaut, von dem Vorgang gar nichts mit bekommt. Methods Wenn ein Client eine Anfrage an ein Objekt schickt sieht es diese Anfrage durch Aufruf einer Methode des Objekts: Das Objekt wird angewiesen, spezifische, benannte Aktion auszuführen. Normalerweise, wenn ein Client versucht eine Methode eines Objekts aufzurufen, die das Objekt nicht anbietet, wird ein Fehler ausgelöst. Die Methodendefinition kann verlangen, dass bestimmte Informationen in der Anfrage als Argumente übergeben werden. Für jede Anfrage enthält die Antwort das Ergebnis, neben entweder den Daten des Ergebnisses oder im Falle einer nicht durchführbaren Aktion Exceptioninformationen. Diese enthalten mindestens einen Exceptionnamen und eine Fehlernachricht. Die meisten D Bus Bindings bieten für den komplizierten Vorgang eine Vereinfachung. Wenn beispielsweise einem Objekt ein String als Argument übergeben wird, so wird dem 24

25 Funktionsaufruf auch nur ein String übergeben. Man muss hier nicht den String konvertieren und diesen dann in ein Datenfeld einer Nachricht überführen. Der Vorgang der Datenkapselung in Nachrichten wird marshalling genannt. Wird eine Nachricht gesendet, so hat man nicht unbedingt auf das Ergebnis zu warten, so dass der Programmfluss solange in einer Schleife verharrt. D Bus bietet Möglichkeiten mehrere Anfragen asynchron zu handhaben. Signale Eine andere Form der Kommunikation sind Signale. Diese one way Kommunikation kommt von einem Objekt und geht nirgendwo bestimmtes hin (broadcast). Clientprozesse können ihr Interesse an einem Signal eines bestimmten Namens bekunden und sobald ein passendes Signal ausgelöst wird, werden alle interessierten Clients eine Kopie dieses Signals empfangen. Für Signale gibt es keine Antworten: Das Objekt, dass das Signal aussendet, kann also nicht wissen, ob ein oder mehrere oder vielleicht auch gar kein Empfänger das Signal verarbeitet. Signale können Parameter übertragen, Clients können bestimmten, dass sie nur Signale empfangen wollen, deren Parameter bestimmten Werten entspricht. Interfaces Jedes Objekt hat bestimmte Methoden und schickt bestimmte Signale zusammengefasst bezeichnet man das als die member des Objekts. Alle Member werden in einem Interface spezifiziert. Genauso wie in der Objektorientierten Programmierung ist ein Interface ein Set an Deklarationen. Wenn man dieses Interface implementieren will, so muss man alle Methoden bereitstellen und die Verfügbarkeit der Signale an alle Listener verkünden.. Jeder der Member muss die Parameter akzeptieren oder bereitstellen, wie sie im Interface genannt werden. Jedes Objekt kann ein Interface implementieren, genauso wie in Java kann eine beliebige Anzahl an Objekten ein Interface implementieren. Genauso kann ein Objekt aber auch eine beliebige Anzahl an Interfaces implementieren. Die Kombination aus allen unterstützten Interfaces nennt man den type eines Objekts. 25

26 Wenn ein Client eine Methode aufruft oder auf ein Signal horcht, muss es das Objekt und die Member, auf die es sich bezieht deutlich machen. Zusätzlich dazu kann der Client das Interface, in welchem der Member erstellt wurde, benennen. Das kann in manchen Fällen notwendig sein: Wenn ein Objekt zwei Interfaces erstellt, die beide eine Methode namens foo spezifizieren, so muss man sie noch unterscheiden können. (Quelle: Basistypen Char y b n q i u x t Code Data Type 8 bit unsigned integer boolean value 16 bit signed integer 16 bit unsigned integer 32 bit signed integer 32 bit unsigned integer 64 bit signed integer 64 bit unsigned integer d double precision floating point (IEEE 754) s o g a UTF 8 string (no embedded null characters) D Bus Object Path string D Bus Signature string Array ( ) Structure start and end v Variant { } Dictionary/Map begin and end h Unix file descriptor 26

27 Containertypen D Bus erlaubt 4 verschiedene Containertypen: 1. Structs Structs sind von Klammern begrenzt und können jeden D Bus Basistyp enthalten. Z.B. enthält (ii) zwei Integer und ((ii)s) enthält ein Struct aus 2 Integern und einem darauf folgenden String. 2. Arrays Definieren eine Liste an member eines festen Typs. Der Buchstabe a muss direkt vor den im Array enthaltenen Typ geschrieben werden. Beispiele wären ai für ein int Array oder a(ii) für ein Array aus structs. 3. Variants Dürfen jeden validen Typ enthalten. Ein enthaltener Wert ist neben der Typsignatur automatisch gespeichert. 4. Dictionaries Dicts sind structs in der Syntax ähnlich, allerdings mit geschweiften Klammern. Sie enthalten immer 2 Werte für key value. Beispiel: a{ss} string key string value. Der Key muss ein Basistyp sein (kein Container), während der value jeder Wert sein darf. (Quelle: D-Bus Tools 27

28 10 Mit dem Tool D Feet, das vom Gnome Projekt entwickelt wird, kann man sich Systemund Session bus anschauen. 11 D Bus liefert standardmäßig aber auch ein Tool namens dbus monitor mit, mit dem man untersuchen kann, was zurzeit für Nachrichten über den Bus gehen, was wie folgt aussieht: method call sender=:1.15 > dest=org.freedesktop.dbus serial=941 path=/org/freedesktop/dbus; interface=org.freedesktop.dbus; member=namehasowner string "org.kde.activitymanager" method call sender=:1.17 > dest=org.kde.klauncher serial=686 path=/klauncher; interface=org.kde.klauncher; member=start_service_by_desktop_path string "/usr/share/applications/turpial.desktop" array [ ] array [ string "DISPLAY=:0" ] string "scumm pc; ;80815;626_time953707" boolean true method return sender=:1.1 > dest=:1.17 reply_serial=686 int32 0 string "" string "" int Das Tool dbus send erlaubt es einem eine Nachricht auf den Bus zu schicken. Standardmäßig wird der Sessionbus genommen. Ein Ziel wird keines definiert, außer man gibt die Option dest an. 13 Eine Übersicht über die verschiedenen Werte bietet die manpage von dbus send: <contents> ::= <item> <container> [ <item> <container>...] monitor.1.html 12 send.1.html 13 send 28

29 <item> ::=<type>:<value> <container>::=<array> <dict> <variant> <array> ::=array:<type>:<value>[,<value>...] <dict> ::=dict:<type>:<type>:<key>,<value>[,<key>,<value>...] <variant> ::=variant:<type>:<value> <type> ::=string int16 uint16 int32 uint32 int64 uint64 double byte boolean objpath Unsere definierten Interfaces WirhabenmehrereD BusInterfacesdefiniert: de.naptower.baulicht.blink de.naptower.baulicht.settings de.naptower.baulicht.text DiesewerdenallebeieinemDienstnamens de.naptower.baulicht Dienstregistriert. Wasmanhiersehenkann,istderBaumartigeAufbauderD BusInterfaces. Das aufgebaute Baulicht DasaufgehängteBaulichtimoberenDritteldesHotelturms 29

30 Geplante Erweiterungen Kontroll LCD (Ein LCD Display mit einer Zeile, um den aktuellen Text anzuzeigen) Gehäuse Hardware Button zum Ein und Ausschalten Zeitschaltung ohne Cron Job Settings über Webinterface Ausblick in die Zukunft Momentan gibt es noch keine öffentliche Möglichkeit, das Baulicht Nachrichten morsen zu lassen, aber sobald Fabian Weisshaar das Portforwarding eingerichtet hat, wird es unter möglich sein die Webseite zu erreichen. 30