Firmware

Implementierungsphase

WLAN/BLE Kommunikation

 

Für die Entwicklung der WLAN Kommunikation mit der App wurde das Modul ESP-WROOM32 verwendet.
Es beinhaltet eine WLAN und Bluetooth LE Schnittstelle in einem Modul und einen eigenen Dual-Core Processor.
Zur Übertragung der SKI-Aufeichnungsdaten  kann die schnellere WLAN Kommunikation verwendet werden und bei Nichtverwendung abgeschaltet werden.
Für den Austausch von Konifigurationsdaten für das SKI-Sytem kann dann BLE verwendet werden (ist aber nicht Ziel des ersten Prototypen, die Hardware wurde aber vorgesehen).
Somit kann der Stromverbrauch verringert werden.

Damit die Entwicklung der WLAN Kommunikation auch ohne fertiger Hardware starten konnte, wurde ein Breakoutboard angeschafft:

 

 

 

 

 

 

 

 

 

 

 

 

 

UART Ausgabe mit Debuginformationen wurden mit dem Seriellen Monitor der Arduino IDE ampfangen und dargestellt:

 

GPS

Zur Ermittlung der Position sowie der Uhrzeit wird ein GPS-Modul eingesetzt. Es wird der GPS-Empfänger A2135-H von Maestro-Wireless eingesetzt. Der Vorteil dieses Moduls ist der geringe Stromverbrauch. Außerdem wird es als Breakout-Board mit eingebauter Antenne ausgeliefert.

Das Modul kann mittels UART oder SPI angesteuert werden. Wir verwenden UART, da hier das international standardisierte Protokoll „NMEA“ verwendet wird. Dies lässt die Möglichkeit offen mit wenig Aufwand ein anderes GPS Modul nutzen zu können.

Außerdem gibt es für das NMEA Protokoll die Open-Source Bibliothek https://github.com/kosma/minmea, welche für unseren Einsatz geeignet ist.

NMEA Protokolldaten

Das Schwierige bei der Umsetzung war die Datenabfrage. Das Modul ist so vorkonfiguriert, dass die GPS Daten von sich aus mit einem Takt von 1Hz gesendet werden. Ein 5 Hz Modus wird angeboten.

In dieser Konfiguration würden die Daten aber in von uns nicht kontrollierbaren Zeitpunkten empfangen werden. Da dies nicht kompatibel ist mit dem internen Datenverarbeitungsablauf (fixes Intervall zu fixen Zeiten) müssen die Daten gepollt werden.

Weiters benötigen wir für die Sensordaten einen Zeitstempel. Dieser wird vom GPS Modul geliefert. Dazu wird beim Aktivieren einer Aufzeichnung einmalig die Zeit vom GPS Modul abgefragt und das auf dem Sensor vorhandene RTC-Modul konfiguriert.

Flash

Wir haben uns für eine Speicherung auf dem SkiMaX entschieden. SD-Karten haben einen hohen Stromverbrauch und ein NVRAM war uns wegen der mechanischen Befestigung der Batterie zu unsicher (ähnliches gilt ebenso für die SD-Karte). Ein EEPROM wäre teurer auch wenn die Anzahl der Schreibzyklen höher ist als beim Flash. Zusätzlich ist beim EEPROM das Gehäuse zu groß.

Die Lösung für uns war ein Flash. Genauer der Winbond W25N01GVZEIG mit 128 MB aufgeteilt in 65536 pages zu je 2048 Bytes. Angesteuert wird der Baustein über SPI. Folgende Einschränkungen waren bei der Auswahl für uns wichtig:

  • Ein Schitag muss aufgezeichnet werden können (12 h)
  • Verlötet
  • Genügend Schreibzyklen (100 000)
  • Gehäuse möglichst klein bei benötigtem Speicher

Die Implementierung der Firmware erwies sich weniger einfach. Im Gegensatz zum IMU-Sensor wurde kein fertiger Treiber mitgeliefert.

Zu Beginn wurde der Algorithmus zum Schreiben und Lesen der Sensordaten aus dem Flash entwickelt. Das Modul trägt den Namen FlashSave. Man kann es sich wie ein eigenes kleines Filesystem vorstellen. Die Funktionsweise ist wie folgt:

  • Ein Buffer in der Größe einer Page wird im Modul intern als Puffer genutzt.
  • Ein Schreibzugriff umfasst immer ein Paket an Sensordaten (GPS und IMU-Daten)
    1. Zu Beginn werden die Daten im internen Buffer gespeichert
    2. Ist dieser voll -> Page bereit -> Flash beschreiben
    3. Ist der Buffer noch nicht voll auf weiter Daten warten bis der Buffer und damit die Page vollständig ist und weiter mit 2.
  • Ein Lesezugriff liefert ein ganzes Paket an Sensordaten zurück
    1. Page wird vom Flash in den internen Buffer geladen
    2. Ist das Paket vollständig -> umkopieren in den Zielspeicher
    3. Meistens ist es unvollstädig -> Paketteil im Speicher in den Zielspeicher kopieren
    4. Nächste Page in den Buffer laden -> restlichen Paketteil in den Zielspeicher kopieren

Der low level driver der den Zugriff liefert wurde erst danach bzw. inmitten der Entwicklung von FlashSave begonnen. Im wesentlichen werden hier die SPI-Befehle durch Funktionen abstrahiert. Die gesamte Konfiguration und der Zugriff auf die wichtigsten Funktionen wurden im Treiber als Modul (Winbond_W25N01GVxxIG) abgebildet. FlashSave nutzt den low level driver, um die Pages in den intern Buffer zu laden und die zuvor erwähnen Algorithmen zu ermöglichen.

Folgende Punkte haben die Entwicklung verzögert:

  • Flash-Schreibzugriffe können Bits nur von 1 auf 0 geändert werden -> Langwierige Fehlersuche wenn das nicht weiß
  • Flash muss Blockweise gelöscht werden und Pageweise geschrieben -> Algorithmus wird komplexer
  • Schwieriges Testen -> Ist der Fehler beim Schreiben oder beim Lesen aufgreten?

IMU (inertial measurement unit)

Als IMU wurd der Bosch BMX055 verwendet. Dieser Sensor inkludiert Accelerometer, Gyrometer und Magnetometer in einem Gehäuse. Der Zugriff funktioniert ebenso über SPI. Wobei jeder Teilsensor eine eigen Chip Select Leitung hat und alle anderen SPI-Schnittstellen geteilt werden. Daraus folgt das jeder Sensor nur nacheinander und nicht gleizeitig abgefragt werden kann. Die Entwicklung war denkbar einfach da es bereits einen Treiber von Bosch gibt. Die Kunst bestand darin den Treiber zu verwenden, da nur Kommentare und keine Doku vorhanden sind.

Nachdem eine Konfiguration ohne Power Saving features gefunden wurde, die funktioniert, war die Ansteuerung bereits abgeschlossen und konnte direkt im Task für das Samplen der IMU-Werte verwendet werden.

Die genaue Konfiguration des IMUs hinsichtlich Filterung, Sensitivität, etc. war für die Erstimplementierung zweitrangig und kann beim Initialisieren einfach verändert werden.

 

Integration

 

 

Unser Firmware-Entwicklungsteam bei der Arbeit

 

 

Prototyp für Benutzerschnittstelle am Embedded System zur Firmware-Entwicklung.

 

XP: Integration freeRTOS Tasks.

 

Testphase

Hier folgen Bilder aus der Testphase.

Live-Test mit GPS-Modul.

 

Live-Test mit GPS-Modul.

 

Optimierung des freeRTOS mittels SystemView.


Zurück zur Seite „Hardware“                                                                                                                                                                           Weiter zur Seite „App“