{"id":135828,"date":"2018-08-31T12:01:00","date_gmt":"2018-08-31T09:01:00","guid":{"rendered":"https:\/\/ruuvi.com\/ruuvi-firmware-part-6-accelerometer-polling\/"},"modified":"2026-06-11T08:48:57","modified_gmt":"2026-06-11T05:48:57","slug":"ruuvi-firmware-part-6-accelerometer-polling","status":"publish","type":"post","link":"https:\/\/ruuvi.com\/de\/ruuvi-firmware-part-6-accelerometer-polling\/","title":{"rendered":"Ruuvi Firmware – Teil 6: Abfrage des Beschleunigungssensors"},"content":{"rendered":"\n
\"Einführungsbild<\/figure><\/div>\n\n

In diesem Teil des Tutorials bauen wir auf Teil 5 des Tutorials auf und f\u00fcgen Unterst\u00fctzung f\u00fcr den LIS2DH12<\/strong><\/a> an Bord des RuuviTag Modells + hinzu. Der finale Code dieses Blogbeitrags kann auf Ruuvi GitHub<\/a> im ruuviblog<\/em>-Branch, Tag 3.6.0-alpha<\/em>, heruntergeladen werden. <\/p>\n\n

Bitte folge Teil 1 der Serie<\/a> f\u00fcr Details zum Klonen des Repositories und Kompilieren des Codes. Die finale Hex-Datei dieses Tutorials kann vom Ruuvi Jenkins<\/a> heruntergeladen werden. <\/p>\n\n

\"ruuvi.firmware.c
ruuvi.firmware.c Architektur 3.6.0<\/figcaption><\/figure><\/div>\n\n

Hinzuf\u00fcgen von LIS2DH12-Treibern<\/h2>\n\n

SPI-Wrapper<\/h3>\n\n

STMicroelectronics bietet C-Treiber<\/a> f\u00fcr einige ihrer Sensoren an, darunter den LIS2DH12<\/strong>. Wir werden ihr Github-Projekt als Submodul zu unserem Projekt hinzuf\u00fcgen. Wie der Bosch BME280<\/strong>-Treiber erwartet auch der LIS2DH12<\/strong>-Treiber Schnittstellenfunktionen zum Schreiben und Lesen. <\/p>\n\n

int32_t platform_write(void *handle, uint8_t Reg, uint8_t *Bufp, uint16_t len)int32_t platform_read(void *handle, uint8_t Reg, uint8_t *Bufp, uint16_t len)<\/code><\/pre>\n\n
Erweitern wir unsere SPI<\/strong>–Schnittstelle<\/em> um LIS2DH12<\/strong>-Unterst\u00fctzung:<\/p>\n\n
\"ruuvi_interface_spi_lis2dh12.c\"
ruuvi_interface_spi_lis2dh12.c<\/figcaption><\/figure><\/div>\n\n
Die Funktionen sind fast identisch mit denen des BME280<\/strong>, aber unser R\u00fcckgabewert ist vom Typ int32_t<\/em> und das Handle ist ein void<\/em>-Zeiger. Zus\u00e4tzlich hat der LIS2DH12<\/strong> eine spezielle Handhabung des Lesens\/Schreibens \u00fcber den SPI<\/strong>-Bus und von Mehrbyte-Lese-\/Schreibvorg\u00e4ngen. Der Lese-\/Schreibmodus wird durch das h\u00f6chstwertige Bit der Registeradresse bestimmt, und das zweith\u00f6chstwertige Bit der reg_addr<\/em> muss gesetzt werden, wenn wir mehr als ein Byte gleichzeitig \u00fcbertragen m\u00f6chten.  <\/p>\n\n
Implementierung der Sensorschnittstelle<\/strong><\/h3>\n\n
Die Sensorschnittstelle hat genau die gleichen Funktionen wie unser Umweltsensor, nur data_get<\/em> setzt einen anderen Datentyp auf den void-Zeiger. Streng genommen k\u00f6nnten wir Beschleunigungsdaten an den Umweltsensordaten-Typ \u00fcbergeben, da beide uint64_t<\/em> und drei Floats<\/em> haben, aber die Definition der Einheit im Datentyp verdeutlicht die Bedeutung jedes Floats. <\/p>\n\n
\"ruuvi_interface_acceleration.h\"
ruuvi_interface_acceleration.h<\/figcaption><\/figure><\/div>\n\n
Vorerst werden wir keine gepufferten Lesevorg\u00e4nge vom LIS2DH12<\/strong> First-In-First-Out (FIFO<\/strong>) implementieren, da dies f\u00fcr die Ruuvi-Datenformate<\/a> nicht erforderlich ist. Vielleicht werden wir die Schnittstelle sp\u00e4ter erweitern, oder wir werden FIFO<\/strong> als einen weiteren Sonderfall betrachten, der von der Anwendung behandelt werden muss. <\/p>\n\n
Die Implementierung selbst umfasst \u00fcber 600 Zeilen, wobei der gr\u00f6\u00dfte Teil aus Eingabepr\u00fcfungen und Switch-Cases besteht. Der Selbsttest muss die Sensoren abtasten und \u00fcberpr\u00fcfen, ob sich die Ausgabe der Achsen wie angegeben \u00e4ndert. <\/p>\n\n
\"ruuvi_interface_lis2dh12.c
ruuvi_interface_lis2dh12.c \u2014 Selbsttest<\/figcaption><\/figure><\/div>\n\n
Hier sto\u00dfen wir an die Grenzen unseres Sensorkonfigurationsdatenformats. Der LIS2DH12<\/strong> k\u00f6nnte im 8-Bit-Modus bis zu 5 kHz<\/em> erreichen, w\u00e4hrend unser Sensorabtastratenwert nur bis zu 200 Hz<\/em> darstellen kann. Wieder einmal halten wir die Dinge einfach und begrenzen unseren Sensor auf 200 Hz<\/em> Abtastung. Wenn jemand eine Vibrationsanalyse am RuuviTag durchf\u00fchren und h\u00f6here Abtastraten ben\u00f6tigt, kann er den LIS2DH12<\/strong>-Treiber direkt anstelle dieser Schnittstelle verwenden.  <\/p>\n\n
Die Funktion der digitalen Signalverarbeitung (DSP<\/strong>) ist ebenfalls etwas knifflig, da das LIS2DH12<\/strong>-Datenblatt<\/a> uns nicht wirklich sagt, was das Register f\u00fcr die Hochpass-Grenzfrequenz<\/em> (HPCF<\/strong>) bewirkt. Der ST-Treiber enth\u00e4lt etwas mehr Informationen, da es eine Enumeration lis2dh12_hpcf_t<\/em> gibt, die die Einstellungen mit einer Skala von LIGHT<\/strong> bis AGGRESSIVE<\/strong> benennt. Wir akzeptieren den DSP<\/strong>-Parameter von 0 bis 3 und definieren 0 als die am wenigsten aggressive und 3 als die aggressivste Einstellung. Es gibt auch eine Konfigurationsoption f\u00fcr die Verwendung eines Hochpasses f\u00fcr Interrupt-Funktionen, aber diese werden wir vorerst ignorieren.   <\/p>\n\n
Abfrage des LIS2DH12 im Programm<\/h2>\n\n
Nachdem der Treiber implementiert ist, testen wir ihn, indem wir die Beschleunigungswerte zusammen mit den Umgebungswerten bei einem Tastendruck ausgeben. Die Anpassung der Hauptfunktion ist einfach: <\/p>\n\n
\"main.c\"
main.c<\/figcaption><\/figure><\/div>\n\n
Wir haben die Initialisierung des Beschleunigungssensors in Zeile 49 hinzugef\u00fcgt und die Tastenaufgabe in Zeile 53 auf task_button_on_press<\/em> ge\u00e4ndert. Unsere Tastenaufgabe ruft die Umgebungs- und Beschleunigungsaufgaben auf und l\u00e4sst die rote LED blinken. Die Initialisierung des Beschleunigungssensors \u00e4hnelt der Initialisierung des Umweltsensors: Wir laden die Standardkonfiguration aus application_config.h und schreiben sie in den Sensor.  <\/p>\n\n
\"task_accelerometer.c
task_accelerometer.c \u2014 Initialisierung<\/figcaption><\/figure><\/div>\n\n
Die Datenleseaufgabe \u00e4hnelt ebenfalls der Umweltsensoraufgabe. Wir lesen die Daten vom Sensor und geben sie auf der Konsole aus. <\/p>\n\n
\"task_accelerometer.c
task_accelerometer.c \u2014 Datenausgabe<\/figcaption><\/figure><\/div>\n\n
\"Beschleunigungswerte\"
Beschleunigungswerte<\/figcaption><\/figure><\/div>\n\n
Der Beschleunigungssensor zeigt insgesamt 1,068 G<\/em> an (Quadratwurzel der Quadrate der X-, Y- und Z-Komponenten), was nahe genug an den erwarteten 1,000 G<\/em> liegt. Die Umgebungswerte sind plausibel, die Temperatur ist etwas hoch, da das nRF52-DK<\/strong> unter meinem Ruuvi-Devkit den RuuviTag<\/strong> etwas aufheizt. <\/p>\n\n
\u00dcberpr\u00fcfen wir den Stromverbrauch:<\/p>\n\n
\"Ein
Ein RuuviTag+ im Leerlauf<\/figcaption><\/figure><\/div>\n\n
Der Stromverbrauch betr\u00e4gt jetzt 5,4 \u03bcA<\/em>, gegen\u00fcber 3,4 \u03bcA<\/em> im letzten Teil. Dies ist ein erwartetes Verhalten, da der LIS2DH12<\/strong> bei 1 Hz<\/em> und 10 Bit Aufl\u00f6sung eine Abtastung von 2 \u03bcA<\/em> verbrauchen soll. Das Lesen der Probe selbst macht keinen gro\u00dfen Unterschied im Vergleich zum Warten, bis der BME280<\/strong> den 16-fachen Oversampling-Prozess abgeschlossen hat, wie unten gezeigt. Die Abtastung kann mit der einfachen Umgebungsabtastung im vorherigen Beitrag verglichen werden.   <\/p>\n\n
\"Ein
Ein RuuviTag+ beim Abtasten der Sensoren<\/figcaption><\/figure><\/div>\n\n
Testen<\/h2>\n\n
Im Laufe der Blogserie wurden einige Dinge auf die lange Bank geschoben. Obwohl wir sowohl Vanilla-ARMGCC<\/strong>– als auch Segger Embedded Studio<\/a> (SES<\/strong>)-Builds unterst\u00fctzen, testet unser Jenkins<\/a> derzeit nur, ob er das Programm mit ARMGCC<\/strong> kompilieren kann. Mindestens zwei Probleme sind bekannt:  <\/p>\n\n