In diesem Teil des Tutorials verwenden wir die in Teil 1 erstellten GPIO-Treiber, um endlich die LEDs unseres RuuviTag blinken zu lassen. Den finalen Code dieses Blogbeitrags kannst du auf Ruuvi GitHub im ruuviblog-Branch, Tag 3.3.0-alpha, herunterladen. Folge bitte Teil 1 der Serie für Details zum Klonen des Repositorys und Kompilieren des Codes. Wenn du die kompilierte Hex-Datei herunterladen möchtest, findest du sie unter http://jenkins.ruuvi.com/job/ruuvi.firmware.c/13/
Tasks
Da unser Programm komplexer wird, teilen wir es in separate unabhängige Tasks auf, anstatt alles in main.c zu behalten. Wie zuvor sind bereits eingeführte Teile in Blau, geänderte Teile haben einen Farbverlauf und neue Teile sind in Grün.
Wir fügen 3 Tasks für LEDs hinzu. Init konfiguriert die Pins, write setzt eine LED auf den gewünschten Zustand und cycle durchläuft die LEDs und schaltet sie nacheinander ein und dann wieder aus.
Zusätzlich zu den Funktionsdefinitionen fügen wir ein Enum für den LED-Zustand hinzu. Wir könnten genauso gut RUUVI_BOARD_LEDS_ACTIVE_STATE und !RUUVI_BOARD_LEDS_ACTIVE_STATE direkt verwenden. Die eigentliche Implementierung ist extrem einfach, wir rufen einfach den in Teil 1 der Beiträge implementierten GPIO-Treiber auf:
Schließlich rufen wir diese Tasks in der main.c auf:
Der Programmablauf ähnelt der aktuellen offiziellen RuuviTag-Firmware. Wir starten Logging und Peripheriegeräte und schalten dann die ROTE LED ein. Sobald der Selbsttest bestanden ist, schalten wir die ROTE LED aus und die GRÜNE LED ein. Nach einer Sekunde starten wir die Hauptschleife, in diesem Fall das LED-Blinken.
Stromverbrauch
Unsere Delay-Implementierung versetzt das Tag nicht in den Schlafmodus, sondern hält den MCU aktiv, bis das Timeout eintritt. Daher liegt unser Stromverbrauch bei mehreren Milliampere, was für batteriebetriebenen Betrieb absolut nicht machbar ist.
Man kann leicht erkennen, wie die LEDs in den Stufen des Profils ein- und ausgeschaltet werden. Derzeit liegt unser Stromverbrauch etwa beim 1.750-fachen des Verbrauchs aus dem vorherigen Beitrag, daher ist dies offensichtlich keine akzeptable Lösung auf lange Sicht.
Im nächsten Teil des Ruuvi Firmware-Blogs fügen wir Interrupts vom Button zum Programmablauf hinzu, was es uns ermöglicht, bis zum nächsten Tastendruck zu schlafen.
Bleib dran und folge @ojousima und @ruuvicom auf Twitter für #FirmwareFriday-Beiträge!