Allgemein

SportTracker Version 0.7 ist online

9. September 2012

Es geht voran… Langsam aber stetig ;-). Mit der neuen Version des SportTrackers kann man den Tracker schon zum Aufnehmen von GPX-Track Files verwenden. Die folgenden Funktionen habe ich bis jetzt realisiert:

  • Über den Track Start/Stop Taster kann die Aufnahme eines Tracks gestartet oder gestoppt werden
  • Die Start/Stop Taste hält die Aufnahme nur an, d.h. beim nächsten Start wird die aktuelle Datei fortgesetzt
  • Über die Lap/Reset Taste kann während der Aufnahme ein neues Track Segment gestartet werden
  • Wird die Lap/Reset Taste im Standby-Zustand für 3s gedrückt, so wird beim nächsten Start ein neues GPX-File angelegt
  • Pro Tag können 10 Tracks angelegt werden

Obwohl ich die Funktionen schon grob getestet habe sind sie allerdings noch mit Vorsicht zu genießen. Aktuell ist noch keinerlei Fehlerhandling implementiert!

Erster Kontakt mit dem GPS Receiver => NMEA Daten mit dem µC einlesen (NMEADll)

19. März 2012

GPS Receiver stellen ihre aktuellen Daten normalerweise mit Hilfe des NMEA-0183 Protokolls über eine einfache UART Schnittstelle der Außenwelt zur Verfügung. Manche Receiver bieten oft auch noch proprietäre Protokolle mit erweiterten Funktionen zur Verfügung. Auf diese möchte ich aber hier nicht eingehen. Für mich reicht der Standard völlig aus. In diesem Artikel beschreibe ich also jetzt wie man auf unterster Ebene NMEA Datensätze mit einem Mikrocontroller, in meinem Fall ein STM32, einlesen und auf Gültigkeit prüfen kann. In meinem Projekt, dass es auch hier zum Download gibt, heißt das Software Modul „nmeadll.c„.

Struktursicht

Um erst mal einen groben Überblick über die Software zu bekommen ist eine Struktursicht immer ein guter Startpunkt, da man hier sieht wie sich ein Modul in den Rest der Software einfügt. Die Struktursicht zum nmeadll-Modul sieht wie folgt aus:

Wie zu erkennen ist, wird der GPS-Receiver direkt an einen der USARTs des Controllers angeschlossen. Darüber liegt dann noch eine Softwareschicht namens „huart.c“ die eine Abstraktion der Hardware (HAL = hardware abstraction layer), bzw. des USARTs, darstellt. Damit wird die Software leichter portierbar, d.h. man kann einfach auf einen anderen Controller wechseln und muss nur das Modul huart austauschen. Danach sollte alles wieder funktionieren (soweit die Theorie ;-)). Über dem HAL liegt dann auch schon das nmeadll-Modul welches die herinkommenden NMEA Datensätze einliest und auf Gültigkeit prüft. An der Stelle ist wichtig, dass hier nur der Datensatz an sich geprüft wird und nicht dessen Inhalt. Die Überprüfung des Dateninhalts liegt in der Verantwortung des übergeordneten SW-Layers der hier mit „gps“ gekennzeichnet ist und in der Software als Task implementiert wurde. Zu guterletzt ist noch erkennbar, dass der NMEA Data Link Layer noch Services des RTOS und verschiedene Utilities verwendet. Dazu aber später mehr.

Das NMEA-0183 Protokoll

Empfangene NMEA Daten haben immer das folgende Format:

D.h. ein Frame beginnt immer mit einem $-Zeichen gefolgt von den beiden Buchstaben „GP“ was für GPS-Receiver steht. Grundsätzlich können hier auch andere zwei Buchstaben stehen aber bei GPS-Receivern sind es immer die Buchstaben GP. Im Anschluss an diese beiden Buchstaben folgen dann drei weitere Buchstaben die den Datensatz kennzeichnen. Im Beispiel oben wäre das z.B. „GSV“. Hierüber lässt sich der Aufbau des empfangenen Datensatzes ermitteln. Daran anschließend folgen dann jew. durch ein Komma getrennt die einzelnen Daten bis zum nächsten ‚*‘-Zeichen was das Ende des Datenfeldes markiert und das Checksummenfeld abgrenzt. Die Checksumme befindet sich in den folgenden beiden Zeichen. Sie wird durch eine einfache XOR-Verknüpfung über alle Datenbytes inkl. des Identifiers gebildet (s.o.). Das Ergebnis wird abschließend noch in einen String konvertiert, d.h. jedes Nibble des Bytes wird in einen Character umgewandelt sodass das Ergebnis wieder direkt lesbar ist. Abgeschlossen wird jeder NMEA Frame mit den beiden nicht lesbaren Zeichen 0x0D und 0x0A, d.h. <CR>+<LF>. Ein NMEA Datensatz kann so inkl. aller Zeichen maximal 82 Zeichen lang sein.

Wie am obigen Beispiel zu sehen ist, lässt sich ein Datensatz auch sehr gut mit Hilfe eines Terminal-Programms auswerten. Das hat mir oft auch sehr bei der Implementierung geholfen.

Gundfunktionen

Der NMEA Data Link Layer stell die folgenden Funktionen zur Verfügung:

  • Einlesen der NMEA Daten in den internen Speicher
  • Prüfen der NMEA Daten auf Gültigkeit
    • Synchronisation auf einen laufenden Datenstrom
    • Formatprüfung
    • Checksumme
  • Verwerfen von ungültigen Datensätzen
  • Speichern von mehreren gültigen Datensätzen bis zur Verarbeitung
  • Bereitstellen der Datensätze für die höher liegende Softwareschicht

Interface

Das Interface des Data Link Layers ist in der folgenden Abbildung dargestellt:

Wie zu erkennen ist, besteht die Schnittstelle zur höheren SW-Schicht aus nur vier Funktionen. Zunächst muss der Data Link Layer mit der Funktion NMEAD_vInitNMEADll() intialisiert werden. Hier werden dann alle internen Datenstruktureninitialisiert, der USART konfiguriert und ein Interrupt Handler installiert (USART Receive Interrupt) in dem das Protokoll verarbeitet wird. Diese Funktion heißt NMEAD_vNMEAProtcolRxEvent(). Auf Applkationsebene spielt sich dann alles mit Hilfe der Funktionen NMEAD_pucGetNMEAFrame() und NMEAD_vReleaseFrame() ab. Über GetFrame kann ein neuer NMEA Datensatz angefordert werden. Hier ist besonders, dass diese Funktion die aufrufende Funktion so lange blockiert bis ein neuer Datensatz empfangen wurde (siehe auch hier). Mit ReleaseFrame wird der Speicher eines Datensatzes wieder freigegeben und kann somit wieder mit neuen Daten überschrieben werden.

Einbindung in das RTOS

Die Kommunikation mit der höheren Softwareschicht ist in der folgenden Abbildung dargestellt. Hier ist auch erkennbar, wie das Betriebssystem in die Kommunikation eingebunden ist.

In obiger Abbildung ist erkennbar, dass jedes empfangene Byte vom GPS-Receiver einen Receive-Interrupt des USARTs auslöst. In diesem Interrupt (Funktion NMEAD_vNMEAProtcolRxEvent()) wird das NMEA Protokoll verarbeitet und die Daten gespeichert. Sollte ein kompletter Frame empfangen worden sein, so posted der Interrupt Handler eine Semaphore die also mit jedem vollständig empfangenen Frame um eins inkrementiert wird. Der GPS Task kann nun auf Task-Ebene die Funktion NMEAD_pucGetNMEAFrame() aufrufen. Diese Funktion fragt wiederum die Semaphore ab und blockiert so lange bis der Interrupt Handler einen neuen Datensatz eingelesen hat (Semaphore Post). Wurde ein Datensatz empfangen, so wird der Task fortgesetzt. Mit diesem Konzept ist somit sichergestellt, dass nur dann Rechenleistung verwendet wird, wenn auch Daten zu verarbeiten sind.

Pufferkonzept

Die folgende Abbildung zeigt das Pufferkonzept des Data Link Layers:

Die NMEA Daten werden im internen Speicher in Form eines Ringpuffers gespeichert. Der Ringpuffer ist dabei Datensatzweise organisiert, d.h. jedes Ringelement kann einen kompletten, bis zu 82 Zeichen langen, NMEA Datensatz speichern. Dieses Konzept ist zwar nicht ganz speicherschonend aber es ermöglicht eine einfache Verarbeitung auf der Protokollebene als auch auf der höher liegenden Verarbeitungsebene, da hier die Daten einfach in einem linearen Array liegen. Es muss also nicht speziell auf Speicherumbrüche geachtet werden.

Protokoll Statemachine

Die Statemachine des Protokollhandlers ist wie folgt organisiert:

Die Statemachine besitzt als Entry-State den Zustand Synch. Dieser Zustand synchronisiert den Protokoll-Handler also zunächst auf einen laufenden Datenstrom indem er auf das Ende eines NMEA Datensatzes wartet und bis dahin alle empfangenen Zeichen verwirft. Nach der Synchronisation wird in den Idle-State gewechselt wo der Automat auf einen neuen Datensatz wartet der immer mit dem ‚$‘-Zeichen beginnen muss. Wurde ein Datensatz erkannt, so wird dieser im State ReadFrame eingelesen und gespeichert. Das Datenfeld endet mit dem ‚*‘-Zeichen. Wird dieses Zeichen empfangen, so wechselt der Automat in den State WaitEOF wo die Checksumme ausgewertet wird und noch die letzten Zeichen (<CR> + <LF>) eingelesen werden. Weiterhin gibt es immer noch den direkten Wechsel zum Synch-Zustand, der immer dann durchgeführt wird wenn die maximale Frame-Länge überschritten wird.

Fehlerbehandlung

Grundsätzlich muss mit den folgenden Fehlern gerechnet werden:

  • Falsches Frame-Format, d.h.
    • Ein Frame beginnt nicht mit dem ‚$‘-Zeichen
    • Das Datenfeld eines Frames endet nicht mit dem ‚*‘-Zeichen
    • Die Checksumme stimmt nicht
    • Der Frame endet nicht mit <CR> + <LF>
  • Es wird auf einen laufenden Datenstrom geschaltet
  • Ein laufender Datenstrom wird unterbrochen

Das Frameformat wird von Data Link Layer komplett auf Interrupt-Ebene geprüft. Sollte das Format eines Frames nicht passen, so synchronisiert sich der Protokoll-Handler wieder neu auf den Datenstrom indem er auf das <LF>-Zeichen wartet. Auch das Aufschalten auf einen laufenden Datenstrom wird über die Synchronisation erschlagen. Ein abreißender Datenstrom wird von Protokoll Handler nicht direkt abgefangen. Sollte dieser Fall jedoch eintreten, so sollte generell die Formatprüfung, speziell die Checksummenprüfung, fehlschlagen und somit eine Neusynchronisation erzwungen werden. Alle Fehler die bei der Formatprüfung erkannt werden führen dazu, dass ein eingelesener Datensatz verworfen wird.

MicroC/OS-II: The Real-Time Kernel

4. September 2011

Hierbei handelt es sich um das Buch zum Betriebssystem welches ich für meinen SportTracker einsetzen möchte. D.h. ursprünglich wollte ich allgemein etwas über embedded Echtzeitbetriebssysteme lernen. Ich wollte also herausfinden wie so ein System „tickt“. Bei meiner Suche bin ich damals auf dieses Buch und damit auch auf uC/OS-II gestoßen.

Aus meiner Sicht ist dieses Buch ein sehr guter Einstieg in die Welt der Echtzeitbetriebssysteme. Das Buch behandelt zwar an sich nur das kommerzielle Betriebssystem uC/OS-II welches von der Firma Micrium (dessen Chef der Autor des Buches ist) vertrieben wird, aber aus meiner Sicht werden die grundlegenden Zusammenhänge die bei vielen Betriebssystemen vergleichbar sind sehr gut und anschaulich erklärt. Es ist also mehr als nur ein teures Produkt Manual das sich die Firma Micrium vergolden lässt. Weiterhin liegt der komplette Source Code des Betriebssystems in Form einer CD bei. Man kann also direkt alles im Code nachvollziehen und mit einem der vielen frei verfügbaren Portierungen von der Micrium Website alles am leben Objekt, d.h. z.B. auf einem Starterkit, ausprobieren.

Zum Aufbau:

Das Buch beginnt mir ein paar einfachen Beispielen die in die Thematik einführen. Danach werden grundsätzliche Echtzeitkonzepte wie Multitasking (preemtiv und nicht preemptiv), Events, Scheduling und so weiter erklärt.  In den folgenden Kapiteln werden dann die einzelnen Funktionen im Detail erläutert. Dabei handelt es sich nicht nur um eine Beschreibung der Anwendung der OS Service Funktionen, sondern vielmehr um das wie und warum eine Service Funktion in einer bestimmten Art und Weise implementiert wurde. Es geht also wirklich um die internen Abläufe. Nachdem alle Services erklärt wurden wird weiterhin beschrieben wie sich das Betriebssystem auf einen neue Plattform portieren lässt. Die Portierung beschränkt sich hierbei auf nur vier hardwarenahe Dateien. Meist lässt sich eine Portierung auch auf einer schon verfügbaren aufsetzen. Abgerundet wird das Buch durch das Reference Manual des OS und einer Beschreibung der Konfiguration, d.h. der Anpassung an die jeweilige Applikation.

Pro:

  • Guter Einstieg in das Thema Echtzeitbetriebssysteme
  • Sehr gute Beschreibung der Betriebssystemfunktionen
  • Graphische Darstellung der Abläufe helfen beim Verständnis
  • Quellcode liegt bei und kann von der Micrium Website heruntergeladen werden

Kontra:

  • uC/OS-II ist nur für nicht kommerzielle Zwecke frei verfügbar
  • Inzwischen wurde eine neue Version uC/OS-III herausgebracht, d.h. die Informationen sind nicht mehr 100% aktuell. Die Grundlagen stimmen aber noch
  • Zum Download des Quellcodes ist eine Registrierung notwendig

Tipp:

Das Buch zur aktuellen Version lässt sich im Moment frei von der Micrium Website herunterladen. D.h. man kann sich eine Menge Geld sparen. Auch der Quellcode des neuen Systems ist im Moment verfügbar.

Elektronik + Laufen = Spaß^2

1. September 2011

Häh? Was meint er denn damit schon wieder? Ganz einfach:

Wenn man zwei Hobbies miteinander kombinieren kann ist das auf jeden Fall eine gute Sache, sprich „Spaß hoch zwei“.

Genau das habe ich mit meinem kommenden Bastelprojekt vor. Und zwar möchte ich einen Sport Tracker bauen. Was genau meine ich damit? Im Prinzip möchte ich einen normalen GPS Tracker bauen, der natürlich wie jeder andere Tracker auch in bestimmten Zeitabständen seine aktuelle Position speichert. Ergänzen möchte ich das Ganze jedoch um verschiedene Funktionen die mich bei meinem Lauftraining unterstützen. Das sind zum Beispiel Funktionen wie:

  • Pulsmesser
  • Angabe von Pulsbereichen
  • Sonderfunktionen für Intervalltrainings, Tempoläufe und lange Läufe
  • Verbindung zum PC
  • gpx Unterstützung
  • GPS Mausfunktion
  • usw.

Jetzt kann man natürlich sagen das man das alles schon fix und fertig kaufen kann. Stimmt! Mein Garmin Forerunner 305 leistet mir jetzt auch schon über zwei Jahre gute Dienste. Aber die Sinnfrage macht besonders bei Hobbyprojekten nur selten Sinn ;-). Insgesamt geht es mir viel mehr darum bestimmte Dinge einfach mal auszuprobieren. Besonders mit einem Tracker gibt es hierzu besonders vielfältige Möglichkeiten. Also dann, auf los gehts…