Einbindung von Sensoren und Aktoren mit Industrial-IO in Linux

Für das Industrial-Input-Output-Subsystem IIO im Linux-Kernel gibt es mittlerweile an die 250 Treiber für Sensoren und Aktoren. Wie Sie eine solche Applikation schnell und richtig realisieren, zeigt der Autor am Beispiel einer Bienenwaage.

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 A/D- und D/A-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 Artikel. Damit es nicht zu theoretisch sondern anschaulich wird, wurde ein Anschauungsobjekt in etwas vereinfachter Darstellung gewählt.

Bildergalerie

Wie funktioniert Industrial-IO in Linux?

Das Industrial-IO-Subsystem im Linux-Kernel dient dazu, den Zugriff auf Sensoren und Aktoren zu vereinheitlichen. Bei klassischen Character Devices wird für jedes Gerät 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. Hier setzt Industrial-IO an mit dem Ziel sowohl die Schnittstelle für Treiber, welche Daten liefern als auch für die Verwendung der Daten im Userspace zu standardisieren.

Die Bienenwaage – als Anwendungsbeispiel

In dem für dieses Thema gewählten Projekt soll das Gewicht von Bienenstöcken gemessen werden. Dafür gibt es mehrere Use-Cases. Die Masse wird erfasst, um folgende Fragen zu klären:

• Messung des Futterverbrauches (Honig) bei der Überwinterung mit Erkennung von hungernden Völkern,

• Verfolgung des Nektareintrages und damit des angesammelten Honigs, um ihn zu schleudern,

• Erkennung von Schwärmen als natürliche Volksteilung mit der Möglichkeit diese rechtzeitig einzufangen und ein neues Volk zu gründen.

Auch Umweltdaten werden am Bienenstand aus folgenden Gründen erfasst:

• Eine Umgebungstemperatur über 12°C führt zu nennenswerter Flugaktivität.

• Bei Abfall des Luftdrucks werden die Bienen oftmals stechlustiger.

Die Skizze in Bild 1 erläutert den Informationsfluss von der Wägezelle, auf welcher der Bienenstock steht, über den A/D-Wandler (hx711) bis zum IIO-Sensor im Linux-Kernel, angebunden mittels GPIO-Bitbanging.

Temperatur, Luftdruck und Luftfeuchte können mit dem Sensor BME280 gemessen werden, wie in Bild 2 dargestellt. Dieser wiederum lässt sich mittels I²C oder SPI ansprechen und durch einen IIO-Sensor auswerten.

Verfügbare Hardwareschnittstellen

Direkt durch das Framework unterstützt werden I²C, SPI und GPIO. Für diese Schnittstellen ist die Implementierung von Treibern besonders einfach, da eine ganze Reihe an Hilfsfunktionen zur Verfügung steht. Andere Hardwareschnittstellen sind nicht ausgeschlossen und können ebenso genutzt werden. Gegebenenfalls ist etwas mehr an Implementierung vonnöten.

Ganz ohne Telegrammverkehr kann der Datenaustausch auch mittels DMA erfolgen. Hierbei werden die Daten vom Gerät direkt in einen Speicherbereich geschrieben, ohne dass ein expliziter Telegrammverkehr notwendig ist. Die Benachrichtigung über geschriebene Daten erfolgt dann mit einem Interrupt. Die Beziehungen sowohl nach unten zur Hardware, als auch nach oben zum Userspace sind in Bild 3 beispielhaft dargestellt.

Die Schnittstellen zum Userspace

Aus dem Userspace heraus können die Sensoren über 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.

In Bild 4 ist ein Beispiel für einen eingelesenen Spannungswert eines A/D-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:

root@waage: lsiio -v

Device 000: bme280
  in_temp_input
  in_humidityrelative_input
  in_pressure_input

Device 001: hx711
  in_voltage0_raw
  in_voltage1_raw

In diesem Beispiel existieren zwei IIO-Devices. Das IIO-Device 000 implementiert den Temperatur-, Luftdruck- und Luftfeuchtesensor BME280 mit seinen drei Messgrößen. Der A/D-Wandler hx711 liefert den eingelesenen Rohwert beider verfügbarer Kanäle jeweils als Spannungswert. Die Umrechnung in das Gewicht erfolgt durch die Userspace-Anwendung.

Triggerung durch hrtimer-Event

Das IIO-Framework bietet Unterstützung für das Einlesen von Sensordaten beim Auftreten eines Ereignisses, wie zum Beispiel eines Interrupts. Die dann eingelesenen Werte können in einen Speicherbereich eingestellt und asynchron mit einem Device-Node abgefragt werden.

Die am häufigsten 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ügung steht. Eine Callback-Funktion im Industrial-IO-Treiber wird aufgerufen und der Sensor abgefragt.

Die Daten können 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ümmert sich darum, dass der Timer erneut programmiert wird. Dadurch entsteht ein zyklischer Timer mit konstanter Abtastfrequenz.

(ID:45153380)