Einbindung von Sensoren und Aktoren mit Industrial-IO in Linux<\/p>\n
Autor: Andreas Klinger, IT-Klinger<\/p>\n
Seit 2011 gibt es im Linux-Kernel das Industrial-Input-Output-Subsystem, kurz IIO. Inzwischen wurden von der recht eifrigen Community rund um die Mailingliste linux-iio beinahe 248 IIO-Treiber (stable v4.13, ohne Variationen und Staging) mainline gebracht. Beispiele sind AD- und DA-Wandler, Beschleunigungssensoren, Licht-, Feuchte-, Luftdruck-, Temperaturmessung usw. Was sind die Besonderheiten von IIO-Treibern und wie kann ich diese in meinem Projekt verwenden? Genau davon handelt dieser Beitrag. Damit es nicht zu theoretisch sondern anschaulich wird, wurde als Anschauungsobjekt ein konkretes Projekt in etwas vereinfachter Darstellung gew\u00e4hlt.<\/strong><\/p>\n Das Industrial-IO-Subsystem im Linux-Kernel dient dazu, den Zugriff auf Sensoren und Aktoren zu vereinheitlichen. Bei klassischen Character Devices wird f\u00fcr jedes Ger\u00e4t ein eigener Treiber mit seinen eigenen Funktionen und seiner oft recht individuellen Schnittstelle zum Userspace (z. B. ioctl(), sysfs-Attribute, Verwendung von Timern) implementiert. Dies bedeutet oftmals, dass der Zugriff auf unterschiedliche Treiber eigens implementiert werden muss. Selbst bei Treibern der gleichen Art, wie beispielsweise Temperatursensoren ist es unwahrscheinlich, dass zwei Treiber das gleiche Interface anbieten. Wird nun ein Sensor durch einen anderen ersetzt ist die Anwendung an den neuen Treiber anzupassen.<\/p>\n Hier setzt Industrial-IO an mit dem Ziel, sowohl die Schnittstelle f\u00fcr Treiber, welche Daten liefern, als auch f\u00fcr die Verwendung der Daten im Userspace zu standardisieren.<\/p>\n In dem f\u00fcr dieses Thema gew\u00e4hlten Projekt soll das Gewicht von Bienenst\u00f6cken gemessen werden. Daf\u00fcr gibt es mehrere Use-Cases. Die Masse wird erfasst, um folgende Fragen zu kl\u00e4ren:<\/p>\n Die Skizze in Abbildung 1 (siehe\u00a0PDF<\/a>) erl\u00e4utert den Informationsfluss von der W\u00e4gezelle, auf welcher der Bienenstock steht, \u00fcber den AD-Wandler (hx711) bis zum IIO-Sensor im Linux-Kernel, angebunden mittels GPIO-Bitbanging.<\/p>\n Temperatur, Luftdruck und Luftfeuchte k\u00f6nnen mit dem Sensor BME280 gemessen werden, wie in Abbildung 2 (siehe\u00a0PDF<\/a>) dargestellt. Dieser wiederum l\u00e4sst sich mittels I2C oder SPI ansprechen und durch einen IIO-Sensor auswerten.<\/p>\n Direkt durch das Framework unterst\u00fctzt werden<\/p>\n F\u00fcr diese Schnittstellen ist die Implementierung von Treibern besonders einfach, da eine ganze Reihe an Hilfsfunktionen zur Verf\u00fcgung steht. Andere Hardwareschnittstellen sind nicht ausgeschlossen und k\u00f6nnen ebenso genutzt werden. Gegebenenfalls ist etwas mehr an Implementierung vonn\u00f6ten.<\/p>\n Ganz ohne Telegrammverkehr kann der Datenaustausch auch mittels DMA erfolgen. Hierbei werden die Daten vom Ger\u00e4t direkt in einen Speicherbereich geschrieben, ohne dass ein expliziter Telegrammverkehr notwendig ist. Die Benachrichtigung \u00fcber geschriebene Daten erfolgt dann mit einem Interrupt.<\/p>\n Die Beziehungen sowohl nach unten zur Hardware als auch nach oben zum Userspace sind in Abbildung 3 (siehe\u00a0PDF<\/a>) beispielhaft dargestellt.<\/p>\n Aus dem Userspace heraus k\u00f6nnen die Sensoren \u00fcber ein vereinheitlichtes Interface abgefragt und eingestellt werden. Dazu existiert ein eigenes Bussystem namens iio. Dementsprechend sind die registrierten Devices in Unterverzeichnissen von \/sys\/bus\/iio\/devices auffindbar.<\/p>\n In Abbildung 4\u00a0(siehe\u00a0PDF<\/a>) ist ein Beispiel f\u00fcr einen eingelesenen Spannungswert eines AD-Wandlers zu sehen. Die einzelnen Namensbestandteile werden systematisch zusammengebaut und sind daher gut durch einen Algorithmus verwendbar. Mit dem Tool lsiio aus dem Verzeichnis tools\/iio\/ der Kernelsourcen kann abgefragt werden, welche IIO-Devices erkannt wurden und welche Nummer diese bekommen haben:<\/p>\n root@waage: lsiio -v<\/p>\n Device 000: bme280 Device 001: hx711 In diesem Beispiel existieren zwei IIO-Devices. Das IIO-Device 000 implementiert den Temperatur-, Luftdruck- und Luftfeuchtesensor BME280 mit seinen drei Messgr\u00f6\u00dfen. Der AD-Wandler hx711 liefert den eingelesenen Rohwert beider verf\u00fcgbarer Kan\u00e4le jeweils als Spannungswert. Die Umrechnung in das Gewicht erfolgt durch die Userspace-Anwendung.<\/p>\n Das IIO-Framework bietet Unterst\u00fctzung f\u00fcr das Einlesen von Sensordaten beim Auftreten eines Ereignisses, wie zum Beispiel eines Interrupts. Die dann eingelesenen Werte k\u00f6nnen in einen Speicherbereich eingestellt und asynchron mit einem Device-Node abgefragt werden.<\/p>\n Die am h\u00e4ufigsten eingesetzte Triggerung ist der hrtimer-Event. Hierbei wird der Hardware-Timer durch das hrtimer-Framework auf einen Zeitpunkt in der Zukunft programmiert. Tritt der Zeitpunkt ein, liefert der Hardware-Timer einen Interrupt, welcher als hrtimer-Event zur Verf\u00fcgung steht. Eine Callback-Funktion im Industrial-IO-Treiber wird aufgerufen und der Sensor abgefragt.<\/p>\n Die Daten k\u00f6nnen in einen Puffer eingestellt werden. Dieser muss im Treiber eingerichtet werden und dient der Zwischenspeicherung der Daten, bis diese mithilfe des Device-Nodes (\/dev\/iio:device<N>) abgefragt werden. Das IIO-Framework k\u00fcmmert sich darum, dass der Timer erneut programmiert wird. Dadurch entsteht ein zyklischer Timer mit konstanter Abtastfrequenz.<\/p>\n F\u00fcr die Abfrage der Daten existiert im Verzeichnis tools\/iio der Linux-Sourcen ein Hilfsprogramm namens iio_generic_buffer. Diesem wird mitgeteilt, von welchem Device mit welchem Trigger welche Daten wie h\u00e4ufig abgefragt werden.<\/p>\n Nachfolgendes Beispiel zeigt, wie man hrtimer-Events aus dem Userspace heraus verwendet:<\/p>\n root@silo: cd \/sys\/kernel\/config\/iio\/triggers\/hrtimer […]<\/p>\n \/sys\/bus\/iio\/devices\/iio:device0 mytmr<\/p>\n 0.080000 1502965687594511120<\/span> Zun\u00e4chst wird der hrtimer-Trigger generiert. Dies erfolgt im configfs durch Anlegen eines neuen Verzeichnisses. Als Name daf\u00fcr wurde im Beispiel mytmr gew\u00e4hlt. Handelt es sich um den ersten angelegten Trigger, dann hat dieser die Nummer 0. Im sysfs ist ein neues Device-Verzeichnis mit dem Namen trigger<T> entstanden, wobei T die Nummer des Triggers ist. In diesem Verzeichnis kann der Trigger parametrisiert werden. In obigem Beispiel wird die Frequenz auf 1 Hz eingestellt.<\/p>\n Die Datenabfrage erfolgt mit dem Programm iio_generic_buffer. Es werden alle Kan\u00e4le (-a) 3 mal (-c3) vom Device mit der Nummer 0 (-N0) unter Verwendung des Triggers mit der Nummer 0 (-T0) abgefragt.<\/p>\n Das IIO-Subsystem ist, wie oben ausgef\u00fchrt, sehr systematisch nach bekannten und dokumierten Regeln aufgebaut. Dass dies so bleibt, dar\u00fcber wachen die Reviewer und der Maintainer. Bevor neue Definitionen verwendet werden, wird versucht, neue Treiber in die bestehenden Interfaces zu integrieren.<\/p>\n Am Framework angemeldete IIO-Ger\u00e4te werden in der Reihenfolge der Anmeldung durchnummeriert. Dies erfordert vom Userspace-Entwickler, dass er den Zusammenhang zwischen Device-Nummer und dem gew\u00fcnschten Treiber herstellen kann. Er muss die Devices im sysfs durchlaufen und anhand des Attributes name den betreffenden Treiber erkennen. Analog dazu funktioniert die Erkennung von Trigger-Events.<\/p>\n Dies ist m\u00fchsame Routine und kann aufgrund der Systematik von IIO gut auf eine Library ausgelagert werden. Die libiio ist genau daf\u00fcr erschaffen worden. Mit ihr kann gut automatisiert werden:<\/p>\n Sourcen der im Artikel verwendeten Treiber:<\/p>\n Andreas Klinger ist selbst\u00e4ndiger Trainer und Entwickler. Seit Abschluss des Studiums der Elektrotechnik im Jahre 1998 arbeitet er im Bereich der systemnahen Softwareentwicklung mit den Schwerpunkten Treiberentwicklung, Embedded Linux und Echtzeit. Als Spezialist f\u00fcr Linux besch\u00e4ftigt er sich mit dem internen Aufbau des Kernels, den Systemmechanismen sowie vor allem mit deren Einsatz in Embedded Systemen.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source \/ Embedded Software Engineering.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Open Source \/ Embedded Software Engineering steht\u00a0hier\u00a0<\/strong><\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nWas ist Industrial-IO in Linux?<\/h2>\n
Anwendungsbeispiel: Bienenwaage<\/h3>\n
\n
Hardwareschnittstellen<\/h3>\n
\n
Schnittstellen zum Userspace<\/h3>\n
\nin_temp_input
\nin_humidityrelative_input
\nin_pressure_input<\/p>\n
\nin_voltage0_raw
\nin_voltage1_raw<\/p>\nTriggerung durch hrtimer-Event<\/h3>\n
\nroot@silo: mkdir mytmr
\nroot@silo: cd \/sys\/bus\/iio\/devices\/trigger0
\nroot@silo: echo 1 > sampling_frequency
\nroot@silo: iio_generic_buffer -a -c3 -N0 -T0<\/p>\n
\n0.230000 1502965688594510720<\/span>
\n0.240000 1502965689594510840<\/span><\/p>\nUserspace-Libraries<\/h3>\n
\n
Verweise<\/h2>\n
\n
Autor<\/h2>\n
\nOpen Source – unsere Trainings & Coachings<\/h2>\n
\nOpen Source – Fachwissen<\/h2>\n