Startseite > Automation > Industrie 4.0 & IoT > IIO-Framework bindet Sensoren an Linux an

Industrial IoT

IIO-Framework bindet Sensoren an Linux an

1. April 2020, 10:30 Uhr | Martin Hofherr

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Erstellung eines eigenen IIO-Dummy-Devices

Wenn alle Kernelmodule geladen sind, kann man mit der Untersuchung des Dummy-IIO-Moduls beginnen. Im ersten Schritt muss ein eigenes IIO-Dummy-Device für die Experimente erstellt werden. Da es sich bei IIO-Dummy-Devices über reine Softwaredevices ohne tatsächliche Hardware im Hintergrund handelt, kann im Betrieb ein neues Gerät hinzugefügt werden. Dies geschieht über configfs. Um configfs auf dem Gerät zu mounten, falls noch nicht vorhanden, führt man folgendes aus:

sudo mkdir -p /config sudo mount -t configfs none /config

configfs ist ein virtuelles Dateisystem, das es erlaubt, aus dem User-Space heraus Kernel-Objekte zu erstellen, zu verwalten und zu löschen. Um ein eigenes IIO-Dummy-Device zu erstellen muss ein neuer Ordner mit dem Namen des Geräts in /config/iio/devices/dummy angelegt werden. Soll das neue Gerät my_dummy heißen, so kann es wie folgt erstellt werden:

mkdir /config/iio/devices/dummy/my_dummy

Im User-Space wird das neue Device wie bei Linux üblich durch mehrere Dateien und Ordner dargestellt. Die Einträge unter /sys/bus/iio/devices/iio:device0 repräsentieren das IIO-Device und seine Kanäle. Die Datei /dev/iio:device0 erlaubt den Zugriff auf den Buffer und die Events des Devices.

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Dateien als Ein-/Ausgänge des IIO-Dummy

In Sysfs wird das neue IIO-Device durch den Ordner /sys/bus/iio/devices/iio:device0 dargestellt. Die Dateien in diesem Ordner stellen die verschiedenen Kanäle dar, die vom IIO-Dummy-Device simuliert werden und bieten zusätzlich die Möglichkeit, die Datenerfassung zu konfigurieren. Dateien mit dem Präfix in_ und dem Suffix _raw stellen die einzelnen Eingangskanäle des Devices dar. Mit diesen Dateien kann man direkt den Wert des Eingangskanals lesen. So stellt die Datei in_accel_x_raw den aktuellen Wert der Beschleunigung in x-Richtung dar:

cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw 34

Dieser Wert ist bei dem simulierten Beschleunigungskanal fest auf den Wert 34 codiert. Zusätzlich können den Dateien weitere Informationen zu den einzelnen Kanälen entnommen werden. So stellen die Dateien mit dem Suffix _scale den passenden Konvertierungsfaktor zur Verfügung, um die Rohwerte in physikalische Einheiten umzurechnen.

Mit IIO ist es nicht nur möglich Werte einzulesen, sondern auch Ausgänge zu steuern. So stellt zum Beispiel die Datei out_voltage0_raw einen D/A-Ausgang dar. Für erste Tests ist es natürlich interessant, die Werte direkt über die Dateien des Interfaces Sysfs auszulesen. Für eine reale Anwendung ist es jedoch oft notwendig, den Abtastzeitpunkt genauer zu steuern. Außerdem wird diese Methode bei mehreren Kanälen, die immer wieder gelesen werden müssen, schnell aufwendig. Hier kommen die Trigger ins Spiel. Im nächsten Abschnitt wird deren Funktionsweise an einem Beispiel dargestellt.

Trigger für Eigangssignale

Mit dem bisher Dargestellten ist es möglich, ein durch einen Trigger gesteuertes Sampling durch das IIO-Dummy-Device aufzusetzen. Dazu wird ein Sysfs-Trigger verwendet. Falls noch nicht geschehen, muss dazu als erstes das IIO-Sysfs-Triggermodul geladen werden:>

modprobe iio_trig_sysfs>

Danach existiert ein neues Device unter /sys/bus/iio/devices/iio_sysfs_trigger. Dieser Ordner enthält mehrere Dateien, die zur Konfiguration des IIO-Sysfs-Triggers dienen, jedoch noch kein eigentliches Trigger-Device. Um dieses Trigger-Device zu erstellen, wird in die Datei add_trigger geschrieben:

echo 0 > /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger

Dadurch wurde ein neues Triggerdevice trigger0 erzeugt, dessen Konfigurationsdateien unter /sys/bus/iio/devices/trigger0/ liegen. Die Datei name enthält die Bezeichnung des Triggers, unter der er im IIO-Core registriert ist.

cat /sys/bus/iio/devices/iio_sysfs_trigger/trigger0/name sysfstrig0

Mit diesem Bezeichner ist es möglich, den Trigger an IIO-Devices zu binden, indem man ihn in die Datei current_trigger des entsprechenden Devices schreibt. Der neu erstellte Trigger wird als Trigger für das Dummy-Device registriert:

cat /sys/bus/iio/devices/trigger0/name > trigger/current_trigger

Im nächsten Schritt muss ausgewählt werden, welche Kanäle durch das Triggerevent ausgelesen werden sollen. Zur Konfiguration dienen die Dateien im Ordner scan_elements. Im Folgenden soll der vom IIO-Dummy-Treiber simulierte Beschleunigungskanal in x-Richtung ausgelesen werden.

echo 1 > /sys/bus/iio/devices/iio:device0/scan_elements/in_accel_x_raw

Im letzten Schritt muss der Puffer des Devices aktiviert werden. Dazu wird der Wert 1 in die Datei /sys/bus/iio/devices/iio:device0/buffer/enable geschrieben.

echo 1 > /sys/bus/iio/devices/iio:device0/buffer/enable

Jedes Auftreten eines Triggersignales legt jetzt einen Wert der x-Achsenbeschleunigung im Puffer des IIO device my_dummy ab. Die Daten werden über das Character Device /dev/iio:device0 bereitgestellt. Ein Lesezugriff auf dieses Device wird blockiert, bis genügend Daten vorhanden sind. Die Größe des Puffers wird über die Datei /sys/bus/iio/devices/iio:device0/buffer/length eingestellt. Bis zu welchem Füllgrad ein lesender Prozess blockiert werden soll, wird über die Datei /sys/bus/iio/devices/iio:device0/buffer/watermark festgelegt. Folgende Anweisungen konfigurieren, dass der Puffer zum Beispiel 100 Werte groß sein und lesende Prozesse blockieren soll, bis 64 Werte im Puffer abgelegt worden sind

echo 100 > /sys/bus/iio/devices/iio:device0/buffer/length echo 64 > /sys/bus/iio/devices/iio:device0/buffer/watermark

Um sofort ein Ergebnis zu erhalten, werden die Pufferlänge auf 2 und die Triggerschwelle auf 1 gesetzt. In einem separaten Terminal wird das Char Device ausgelesen:

cat /dev/iio:device0 | xxd

Wenn /sys/bus/iio/devices/iio_sysfs_trigger/trigger0/trigger_now auf den Wert 1 gesetzt wird, wird in dem Terminal mit dem lesenden Prozess ein Wert angezeigt. Natürlich ist das Lesen eines einzelnen Kanals mit einem Sysfs-Trigger nicht besonders sinnvoll, da man den Wert auch direkt aus der entsprechenden Datei aus dem Sysfs-Interface lesen könnte. Zum simultanen Auslesen mehrerer Kanäle ist es hingegen sehr nützlich, einen Sysfs-Trigger zu verwenden. Die jeweiligen Kanäle müssen im Ordner scan_elements aktiviert werden.

Trigger mit hochauflösendem Timer

Der High-Resolution-Timer-Trigger ermöglicht es, periodische Trigger aufzusetzen. Der Trigger existiert als das Kernelmodul iio_trig_hrtimer, für das ebenfalls ein eigenes Trigger-Device über Configfs erstellt werden muss. Nach dem Laden des Moduls taucht in der IIO-Hierarchie in Configfs ein neuer Ordner mit dem Namen triggers/hrtimer auf. Ein High-Resolution-Timer-Trigger-Device kann durch Anlegen eines Unterordners in diesem Ordner angelegt werden:

mkdir /config/iio/triggers/hrtimer/my_hrt_trigger

Dadurch wird unter /sys/bus/iio/devices/ ein neuer Trigger angelegt. Da durch das vorherige Experiment mit dem Sysfs-Trigger bereits ein Trigger-Device trigger0 existiert, erhält der neue Trigger die Bezeichnung trigger1. Der Inhalt des neues Trigger-Ordners enthält neben der bereits bekannten Datei name noch eine weitere sampling_frequency, in die die Abtastfrequenz in Hertz geschrieben werden kann. Steht der Wert 10 in der Datei, entspricht dem ein Triggersignal mit einer Frequenz von 10 Hz. Natürlich ist zu beachten, dass bei realen Geräten die tatsächlich erreichbare Samplingfrequenz noch immer von der Hardware abhängig ist. Der High-Resolution-Timer-Trigger wird genauso genutzt wie der Sysfs-Trigger.
Dieses Framework bietet noch wesent-lich mehr Möglichkeiten, als in dieser Übersicht dargestellt werden konnten und die Zahl der unterstützten Geräte wächst stetig. Zusätzlich steht mit libiio auch eine Bibliothek zur vereinfachten Nutzung von IIO-Geräten zur Verfügung, die noch zusätzliche Funktionen wie Steuerung über das Netzwerk bieten.