{"id":135845,"date":"2018-08-24T11:11:00","date_gmt":"2018-08-24T08:11:00","guid":{"rendered":"https:\/\/ruuvi.com\/ruuvi-firmware-teil-5-umweltsensorik\/"},"modified":"2026-06-11T08:48:58","modified_gmt":"2026-06-11T05:48:58","slug":"ruuvi-firmware-teil-5-umweltsensorik","status":"publish","type":"post","link":"https:\/\/ruuvi.com\/de\/ruuvi-firmware-teil-5-umweltsensorik\/","title":{"rendered":"Ruuvi Firmware \u2013 Teil 5: Umweltsensorik"},"content":{"rendered":"\n
\"Introbild<\/figure><\/div>\n\n

In diesem Teil des Tutorials entwickeln wir eine Sensorschnittstelle, die jedes Backend zum Auslesen von Sensordaten nutzen kann, und implementieren das Backend mit dem integrierten Temperatursensor des nRF52. Danach schreiben wir SPI-Treiber zum Auslesen externer Sensoren und implementieren das Sensor-Backend mit dem Bosch BME280. Den finalen Code findest du auf Ruuvi GitHub<\/a> im ruuviblog<\/em>-Branch, Tag 3.5.0-alpha<\/em>. Bitte folge Teil 1 der Serie<\/a> f\u00fcr Details dazu, wie du das Repository klonst und den Code kompilierst. Das finale Hex dieses Tutorials kannst du von Ruuvi Jenkins<\/a> herunterladen. <\/p>\n\n

\"Die<\/figure><\/div>\n\n

Sensorschnittstelle<\/h2>\n\n

Im Allgemeinen hat jeder Sensor, den wir verwenden, einige gemeinsame Parameter, wie Aufl\u00f6sung, Abtastrate, Skalierung, Digital-Signal-Processing-(DSP)-Funktion und Parameter f\u00fcr das DSP. Au\u00dferdem k\u00f6nnten wir daran interessiert sein, den Sensor zu starten, zu stoppen oder eine Single-Shot-Messung durchzuf\u00fchren. <\/p>\n\n

Wir wollen au\u00dferdem ein paar feste Bedeutungen f\u00fcr unsere Sensoren definieren, wie RESOLUTION_MAX<\/strong> oder SCALE_MIN.<\/strong> So k\u00f6nnen wir eine Vielzahl von Sensoren einrichten, ohne die genauen F\u00e4higkeiten des zugrunde liegenden Ger\u00e4ts zu kennen. Au\u00dferdem verwenden wir 0<\/strong> als sinnvollen Standard<\/em>-Wert. Dadurch k\u00f6nnen wir die Konfiguration per memset<\/em> auf lauter Nullen setzen und erhalten am Ende sinnvolle Werte, ohne Parameter explizit setzen zu m\u00fcssen, die uns eigentlich nicht interessieren. <\/p>\n\n

Da wir die Konfiguration sp\u00e4ter per BLE \u00fcbertragen wollen, sparen wir in unserer Schnittstelle Platz. Wir verwenden uint8_t<\/em>-Werte, um die Sensoren zu konfigurieren. DSP-Funktionen sind Bit-Flags, damit sich mehrere Optionen kombinieren lassen. <\/p>\n\n

\"Konstanten
Konstanten f\u00fcr die Sensorkonfiguration<\/figcaption><\/figure><\/div>\n\n

Da wir jeden verf\u00fcgbaren Sensor nutzen wollen, definieren wir eine gemeinsame Schnittstelle zum zugrunde liegenden Sensor \u00fcber Funktionszeiger. So k\u00f6nnen wir denselben Code mit dem nRF52<\/strong><\/a>-Temperatursensor und dem BME280<\/strong><\/a>-Umweltsensor verwenden, um Umweltdaten zu erhalten; nRF52<\/strong> liefert bei Druck und Luftfeuchtigkeit einfach \u201eung\u00fcltige\u201c Werte zur\u00fcck. Man k\u00f6nnte argumentieren, dass C++ die bessere Wahl f\u00fcr Schnittstellen w\u00e4re, allerdings werden wir die beiden nicht mischen, au\u00dfer es ist aus irgendeinem Grund unbedingt n\u00f6tig. <\/p>\n\n

\"ruuvi_driver_sensor.h,
ruuvi_driver_sensor.h \u2014 Schnittstellenfunktionen<\/figcaption><\/figure><\/div>\n\n

Unsere Initialisierung erlaubt es, den Bus<\/em> zu definieren; damit k\u00f6nnen wir unterst\u00fctzen, ob der Sensortreiber mit dem jeweiligen Sensor I2C<\/strong> oder SPI<\/strong> verwenden soll. Au\u00dferdem \u00fcbergeben wir ein uint8_t handle<\/em>, das dem Programm hilft, den richtigen Sensor auszuw\u00e4hlen. Bei I2C<\/strong> ist dieses Handle die Adresse des Sensors, bei SPI<\/strong> ist es der GPIO<\/strong>-Pin, der zum Ausw\u00e4hlen des Sensors verwendet wird. <\/p>\n\n

Wir versuchen, unsere Schnittstelle einfach zu halten. Die Abtastrate ist in Hz<\/em> und die Aufl\u00f6sung in Bits. Werte von 1 \u2026 200 sind erlaubt, wobei 0 die besondere Bedeutung Standard<\/em> hat und Werte \u00fcber 200 f\u00fcr Konstanten mit spezieller Bedeutung reserviert sind. Wenn unser Sensor den exakt angegebenen Wert nicht unterst\u00fctzt, interpretieren wir den Wert als mindestens<\/em>. Wenn zum Beispiel eine Aufl\u00f6sung von 9 Bit angefordert wird, aber 8 und 10 Bit unterst\u00fctzt werden, w\u00e4hlen wir 10 Bit Aufl\u00f6sung. <\/p>\n\n

Eine schwierigere Frage ist, was Aufl\u00f6sung und Skalierung darstellen sollen, wenn sie nicht MIN<\/strong>, MAX<\/strong> oder DEFAULT<\/strong> sind. Skalierung ist mit uint8_t<\/em> als Typ schwerer darzustellen als Aufl\u00f6sung. F\u00fcr etwas wie die Beschleunigungssensor-Skalierung funktioniert es gut, weil wir problemlos 2, 4, 8, 16 G<\/em> haben k\u00f6nnen. Einheiten wie Pascal<\/em> sind anspruchsvoller: Wir k\u00f6nnten so etwas wie 100 000 Pa<\/em> haben, das durch die Skalierungszahl repr\u00e4sentiert werden sollte. <\/p>\n\n

Um unsere Schnittstelle einfach zu halten, wenden wir dasselbe Prinzip an wie bei Abtastrate und Aufl\u00f6sung. Die Skalierung ist in einer sinnvollen physikalischen Einheit wie G<\/em>. Gleiches gilt f\u00fcr die Abtastrate: Ein Beschleunigungssensor k\u00f6nnte im Low-Resolution-Modus 5 kHz erreichen, aber jeder Wert au\u00dferhalb des Bereichs wird mit MAX<\/strong> dargestellt. Das schr\u00e4nkt zwar einige Sonderf\u00e4lle ein, aber wir akzeptieren, dass jeder spezielle Use Case mehr Arbeit erfordert, und versuchen, die allgemeinen Bed\u00fcrfnisse zu erf\u00fcllen. <\/p>\n\n

Digital-Signal-Processing-Funktionen sind ein noch gemischteres Feld, da es unterschiedliche gew\u00fcnschte Funktionskombinationen geben kann, die komplett andere Parameter erfordern. Um beim Prinzip \u201eeinfach halten\u201c zu bleiben, erlauben wir ein Bit-Flag der hardwareunterst\u00fctzten DSP-Funktionen und \u00fcbergeben einen einzelnen, gemeinsamen Parameter daf\u00fcr. <\/p>\n\n

Die Sensorschnittstelle definiert Funktionszeiger zum Setzen und Auslesen jedes Parameters. Die Schnittstelle passt die \u00fcbergebenen Werte an den tats\u00e4chlich geschriebenen Wert an oder an default <\/em>, wenn der Sensor den angegebenen Parameter nicht unterst\u00fctzt. Der R\u00fcckgabecode ist SUCCESS<\/strong>, wenn eine sinnvolle Aktion m\u00f6glich war, oder ein Fehlercode wie NOT_SUPPORTED<\/strong>, wenn es keine M\u00f6glichkeit gibt, die angeforderte Einstellung zu erf\u00fcllen. <\/p>\n\n

Umweltsensor<\/h2>\n\n

Schnittstelle f\u00fcr Umweltsensordaten<\/h3>\n\n

Wir verwenden Floats in unserem Sensordatenformat, da wir damit gen\u00fcgend Skalierung in sinnvollen SI-Einheiten haben. Au\u00dferdem f\u00fcgen wir den Daten einen Zeitstempel in Millisekunden hinzu, auch wenn wir noch kein RTC<\/strong> implementiert haben. <\/p>\n\n

\"ruuvi_interface_environmental.h\"
ruuvi_interface_environmental.h<\/figcaption><\/figure><\/div>\n\n

Variablen bekommen als Suffix den Namen der Einheit, um jede Mehrdeutigkeit dar\u00fcber zu vermeiden, um welche Art von Werten es im Code geht.<\/p>\n\n

Implementierung des nRF52-Umweltsensors<\/h3>\n\n

Die Umgebungs-Implementierung ist beim nRF52<\/strong> einfach, da wir dort nur eine einfache, einzelne synchrone data_get<\/em>-Funktion in nRF52<\/strong> zur Verf\u00fcgung haben. Unsere Initialisierungsfunktion richtet das Offset-Kompensationsregister des nRF52<\/strong> und die Funktionszeiger ein. Die Definitionen von Bus<\/em> und handle<\/em> k\u00f6nnen hier ignoriert werden. Die Deinitialisierung setzt die Funktionszeiger auf NULL<\/strong>, weitere Aktionen sind nicht n\u00f6tig. <\/p>\n\n

\"ruuvi_platform_environmental_mcu.c
ruuvi_platform_environmental_mcu.c \u2014 Initialisierung<\/figcaption><\/figure><\/div>\n\n

Die Set-Funktionen geben RUUVI_DRIVER_ERROR_NOT_SUPPORTED<\/strong> zur\u00fcck, au\u00dfer der Nutzer gibt zuf\u00e4llig den Standardwert der Einstellung ein, z. B. eine Aufl\u00f6sung von 10 Bit. Au\u00dferdem erlauben wir DEFAULT<\/strong>, MIN<\/strong>, MAX<\/strong> und NO_CHANGE<\/strong>. Getter markieren den Wert, auf den gezeigt wird, als default <\/em> und geben RUUVI_DRIVER_SUCCESS<\/strong> zur\u00fcck. <\/p>\n\n

\"ruuvi_platform_environmental_mcu.c
ruuvi_platform_environmental_mcu.c \u2014 Setter und Getter f\u00fcr Aufl\u00f6sung<\/figcaption><\/figure><\/div>\n\n

Wir ahmen die kontinuierliche Sampling-Funktionalit\u00e4t nach, indem wir ein Flag setzen, um die Daten bei data_get.<\/em> zu aktualisieren. So k\u00f6nnen Programme, die beim Umweltsensor auf den Continuous Mode angewiesen sind, auch mit dem nRF52<\/strong>-Temperatursensor sinnvoll arbeiten.<\/p>\n\n

\"Mode-Setter
ruuvi_platform_environmental_mcu.c \u2014 Mode-Setter und -Getter, Datenlesefunktion<\/figcaption><\/figure><\/div>\n\n

Implementierung des BME280-Umweltsensors<\/h3>\n\n

Die BME280<\/strong>-Implementierung ist deutlich komplexer, weil wir \u00fcber den SPI<\/strong>-Bus mit einem externen Sensor kommunizieren m\u00fcssen. Zum Gl\u00fcck stellt Bosch einen plattformunabh\u00e4ngigen C-Treiber f\u00fcr den BME280<\/strong> bereit, und wir m\u00fcssen nur ein paar grundlegende Funktionen bereitstellen, um ihn zu nutzen. <\/p>\n\n

Die Initialisierung ist \u00e4hnlich wie bei der nRF52 <\/strong>-Implementierung. Wir pr\u00fcfen, ob der ausgew\u00e4hlte Bus SPI<\/strong> war, richten das Handle sowie die read<\/em>\/write<\/em>\/delay <\/em>-Funktionen ein, rufen den Bosch-Treiber zur Initialisierung des BME280<\/strong> auf, f\u00fchren einen Self-Test<\/em> aus und machen einen Soft Reset<\/em>. Zum Schluss setzen wir das Oversampling f\u00fcr jedes Sensorelement auf 1, um den Stolperstein zu vermeiden, dass der BME280<\/strong> nicht sampelt, wenn das Oversampling nicht mindestens 1 ist. Wenn keine Fehler aufgetreten sind, richten wir die Funktionszeiger ein und geben SUCCESS<\/strong> zur\u00fcck. <\/p>\n\n

\"ruuvi_interface_bme280.c
ruuvi_interface_bme280.c \u2014 Initialisierung<\/figcaption><\/figure><\/div>\n\n

Der BME280<\/strong> hat nat\u00fcrlich deutlich mehr Umweltsensor-Features als der nRF52<\/strong>, aber die meisten davon zu nutzen ist ziemlich geradlinig \u00fcber Switch-Cases zur Auswahl der passenden Optionen. Die einzigen Stolpersteine sind: Das Oversampling jeder Sensorkomponente muss mindestens 1 sein, es gibt keine feste Abtastrate, sondern eine Verz\u00f6gerung zwischen Samples, und die Sampling-Zeit h\u00e4ngt von der Oversampling-Einstellung ab. Wir akzeptieren eine gewisse Ungenauigkeit bei der Abtastrate und nehmen einfach an, dass wir die gew\u00fcnschte Rate erreichen, indem wir die Verz\u00f6gerung w\u00e4hlen, die die gew\u00fcnschte Abtastrate ergibt. <\/p>\n\n

\"ruuvi_interface_bme280.h
ruuvi_interface_bme280.h \u2014 Setter und Getter f\u00fcr Abtastrate.<\/figcaption><\/figure><\/div>\n\n

Aufl\u00f6sung und Skalierung sind schwer als einzelne Zahl zu definieren, da wir es mit drei verschiedenen Ma\u00dfeinheiten zu tun haben. Daher geben wir default<\/em> als Parameterwert zur\u00fcck und liefern einen Fehler, wenn der Setter etwas anderes als MIN<\/strong>, <\/em>MAX<\/strong>, <\/em>DEFAULT<\/strong> oder <\/em>NO_CHANGE.<\/strong> erhalten hat. <\/p>\n\n

\"ruuvi_interface_bme280.h
ruuvi_interface_bme280.h \u2014 Setter und Getter f\u00fcr Skalierung.<\/figcaption><\/figure><\/div>\n\n

SPI-Treiber<\/h2>\n\n

Schnittstelle<\/h3>\n\n

Unsere Schnittstelle hat zwei Funktionen: Initialization<\/em> und einen blockierenden Full-Duplex-transfer<\/em>. Unsere anderen Treiber f\u00fcr Peripherie implementieren Wrapper, die die Transfer-Funktion verwenden. <\/p>\n\n

Die Schnittstelle definiert SPI<\/strong>-Mode- und Frequenz-Enumerationen sowie eine Initialisierungsstruktur. So vermeiden wir, den Treiber an die Board-Definitionen zu binden, aber die Anwendung muss die Board-Einstellungen passend zum Treiber konfigurieren. <\/p>\n\n

\"ruuvi_interface_spi.h\"
ruuvi_interface_spi.h<\/figcaption><\/figure><\/div>\n\n

Implementierung<\/h3>\n\n

Die Implementierung selbst enth\u00e4lt nichts, was wir nicht schon gesehen h\u00e4tten: Wir pr\u00fcfen die Eingabeparameter, reichen sie an das Nordic SDK<\/a> weiter und geben eventuelle Fehlercodes zur\u00fcck. Das Nordic SDK w\u00fcrde viel Feinschliff mit Direct Memory Access (DMA<\/strong>) und Peripheral-Peripheral Interconnect (PPI<\/strong>) unterst\u00fctzen, aber wir entscheiden uns vorerst f\u00fcr einfache blockierende Transfer-Funktionen. Vielleicht schauen wir uns die Implementierungen sp\u00e4ter noch einmal an, wenn das Power-Profiling zeigt, dass die funktionale Firmware bei den SPI<\/strong>-Reads viel Strom verbraucht \u2013 aber im Moment w\u00e4re das verfr\u00fchte Optimierung. <\/p>\n\n

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

Der Bosch-BME280<\/strong>-Treiber erwartet read<\/em>-, write<\/em>– und delay<\/em>-Funktionen mit den folgenden Signaturen:<\/p>\n\n

int8_t ruuvi_interface_spi_bme280_write(uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t len);int8_t ruuvi_interface_spi_bme280_read (uint8_t dev_id, uint8_t reg_addr, uint8_t *reg_data, uint16_t len);void bosch_delay_ms(uint32_t time_ms);<\/code><\/pre>\n\n
Delay<\/em> ist einfach: Wir reichen den Aufruf an ruuvi_platform_delay_ms<\/em> weiter und ignorieren den R\u00fcckgabewert. Read<\/em> und write<\/em> erfordern etwas mehr Arbeit: Unsere SPI<\/strong>-Transfer-Funktion ist Full-Duplex mit zwei Buffern, w\u00e4hrend die Bosch-Funktion Adresse + R\/W-Daten verwendet.<\/p>\n\n
Wir implementieren die BME280<\/strong>–SPI<\/strong>-Funktionen in der Schnittstelle<\/em>, also als plattform<\/em>unabh\u00e4ngig. Im Wrapper rufen wir die vom Platform<\/em> bereitgestellten GPIO<\/strong>-Steuerfunktionen und die SPI<\/strong>-Transfer-Funktion auf. <\/p>\n\n
\"ruuvi_interface_spi_bme280.c\"
ruuvi_interface_spi_bme280.c<\/figcaption><\/figure><\/div>\n\n
Im Wesentlichen teilen wir hier einen Funktionsaufruf aus dem Bosch-Treiber in vier Aufrufe auf:<\/p>\n\n