UART-Logging mit Linux

Eine einfache aber blöde Problematik: Plasterouter stürzen ab und man kann nicht schnell hingehen.

In unseren Flüchtlingsunterkünften stehen Accesspoints mit Freifunk-Firmware herum, genauer gesagt handelt es sich um Xiaomi Mi Router 4A Gigabit Edition.

Gute Preis/Leistung, für um die 25 Euro (zumindest im Frühsommer 2022) bekommt man bei ffmuc zumindest theoretisch um die 90 Mbit/s durch. (Theoretisch, weil ich den Messwert hier via WLAN nicht bestätigen konnte).

Abgesehen von der etwas umständlichen Installation von zuerst OpenWrt (und dem etwas umständlichen jailbreak via OpenWRTInvasion, dem durchklickern durch ein chinesisches WebUI im Router und der Gefahr, dass man eine Version mit inkompatiblem SPI-Flash erwischt oder einer zu neuen Firmware erwischt oder sich das Teil beim Downgrade erst einmal brickt) und dann der Freifunk-Firmware, bei der dann erst einmal kein WiFi funktionierte und man die experimental-Version des images verwenden muss (Vielen Dank für die schnelle und tolle Unterstützung an die ffmuc-Community!) funktioniert das Teil recht gut, bis auf…

…tja, bis auf der Tatsache, dass die Plastikboxen ab und zu abschmieren. Mit crontab lässt sich ein Autoreboot in der Nacht einrichten, in anderen Situationen konnte ich mich über die anderen Knoten zu den teilabgeschmierten durchhangeln und rebooten. Manchmal – und dann natürlich vermehrt an den Standorten an denen sie hinter verschlossenen Türen stehen – knallen die Dinger aber so weg, dass man hinfahren und den Stecker ziehen muss. Noch blöder, wenn es beide machen.

Was macht man in diesem Fall? Natürlich herausfinden warum. Problem: Man kommt über Netzwerk nicht an die Konsole, weil tot. Also muss was externes ran.

Auf das Gehäuse und UART suchen – den es natürlich gibt. 4 Pins, beschriftet, fein:

Die Wege fürs Logging sind vielfältig, der Einfachheit halber wollte ich schon einen OpenLog bestellen – da muss man aber auch wieder fahren um die Daten zu holen und wenn’s dumm läuft ist etwas schief gegangen.

Auf der anderen Seite liegen mehr als genügend Raspberry Pis herum, die den Job übernehmen können.

Schritt 1 für sinnvolles Logging: Heartbeats. Auf dem Knoten kommt eine zusätzliche Zeile in crontab, die jede Minute die aktuelle Systemzeit ausgibt:

* * * * * echo "::Systime:: $(date)" > /dev/kmsg

Auf der Raspi-Seite ist es schon ein bisschen schwieriger – denke ich zumindest. Das Problem sollte eigentlich vorhanden und gelöst sein. Unter Windows kann das Putty super easy, aber es soll Linux und ohne Klickibunti sein. Ein Python-Script dafür zu schreiben ist mir zu blöd. Miniterm? Hm, scheint es nicht zu können. Nach längerer Suche stolpere ich (wieder) über screen – dem Schweizer Taschenmesser, wenn man zu blöd für services ist.

Und es hat auch hier eine Lösung parat, die man sich zusammenbasteln kann. Interaktiv wächst ein Befehl, der erst einmal überhaupt nicht funktioniert, bis die Erkenntnis kommt, dass zuerst die Parameter zur Konfiguration der Session und dann der Pfad zum TTY erfolgen muss. Mit der Zeit und nach einigen Tabs im Browser später ist folgender Kommandozeilenbefehl entstanden:

screen -S mimon -L -Logfile /home/pi/mimon/mimon_%Y.%m.%d_%c.log /dev/ttyUSB0 115200

Dieser startet eine Session namens mimon, aktiviert das Logging in die Logfile nur echt im py home directory mit aktuellem Datum und Uhrzeit für ttyUSB0 mit 115200 Baud.

Flutscht. Nur soll für jeden Tag eine neue Log entstehen. Bei dem Test inkl. Uhrzeit funktioniert das natürlich nicht, weil der String nur beim Start geparst wird.

Ein wenig Superuser-Browsing später ist die Erkenntnis erlangt, dass man die Session-Parameter auch zur Laufzeit ändern kann.

screen -XS mimon logfile /home/pi/mimon/mimon_%Y.%m.%d_%c.log

funktioniert auf der Konsole, als cronjob aber nicht. Zumindest nicht ganz – Datum und Uhrzeit fehlen. Eine Escaping-Runde später funktioniert auch das. Jetzt muss nur noch screen beim Reboot starten. der Befehl von oben – natürlich ebenfalls mit Escaping geht nicht, was vermutlich damit zusammenhängt, dass die Session direkt aufgeht und interaktiv wird. Wieder mit der Hilfe von Stackoverflow (wie entwickelt man heute eigentlich noch offline und wie hat man das früher geschafft?) landet folgende Zeile in crontab:

@reboot screen -dmS mimon -L -Logfile /home/pi/mimon/mimon_\%Y.\%m.\%d_\%c.log /dev/ttyUSB0 115200

…die natürlich wieder nicht funktioniert. Keine Typos, ohne das Escaping funktioniert interaktiv alles. Die erste Idee: Zeit. Keine Ahnung, wann im Bootprozess @reboot loslegt und für die Anwendung auch weniger relevant. Die Lösung: 30 Sekunden warten – das gibt dem System auch Gelegenheit, den NTP zu fragen, welche Stunde geschlagen hat.

Bereit für die finalen Crontab-Zeilen? Let’s go:

@reboot sleep 30 && screen -dmS mimon -L -Logfile /home/pi/mimon/mimon_\%Y.\%m.\%d_\%c.log /dev/ttyUSB0 115200
0 * * * * screen -XS mimon logfile /home/pi/mimon/mimon_\%Y.\%m.\%d_\%c.log

So wird jede Stunde eine neue Logdatei angelegt, wodurch man – auch dank des Graphana-Dashboards – die Crashes recht schnell eingrenzen können sollte.

Mal sehen, wann es wieder soweit ist und was die Logs sagen.

Allerdings könnte es sich erübrigt haben – da vor ein paar Tagen eine neue Firmware ausgerollt wurde.

Code-Templates für AVR-Register

Warum sollte man sich für Dinge abmühen, die der Computer viel besser kann als man selbst?

Dieser Gedanke rückt viel zu oft in den Hintergrund. Auch wenn ich mich selbst immer wieder dabei erwische, Dinge manuell zu machen (weil man es halt doch nicht so oft braucht), poppt immer wieder folgender Gedanke hoch:

Wenn man einmal 2 Stunden für die Automatisierung einer 10-minütigen Aufgabe investiert, hat es sich nach 12-maliger Benutzung schon gelohnt. Mal ganz zu Schweigen von Flüchtigkeitsfehlern, Wiederholbarkeit, etc.

Mir war schon länger bekannt, dass Microchip Studio Definitionsdateien für Register mitbringt, das erste Mal aktiv genutzt habe ich sie beim updizombi (den ich im Nachhinein lieber updipuppeteer genannt hätte, weniger apokalyptisch), auf dessen Hilfsscript ein Tool entstand, das viel Fleißarbeit abnimmt:

Für die bessere Lesbar- und Wartbarkeit beim Schreiben von Registern habe ich mir angewöhnt, die Namensdefinitionen der Bits zu nutzen. Dafür liegt dann mindestens die Register Summary des Chips auf dem zweiten Bildschirm:

Das Abtippen ist reine (nervige, aber sinnvolle) Fleißarbeit. Nach einigen Jahren hat dann doch die Faulheit – oder Motivation? – gesiegt und es ist ein zusammengehacktes Script entstanden, das die beim Microchip Studio mitgelieferten Definitionsdateien in Codetemplates umwandelt.

Die Ausgabe sieht dann wahlweise so

...
/// Module USART - USART
/// Register group USART0 - USART
/// Register UDR0 - USART I/O Data Register 0
UDR0 = ;
/// Register UCSR0A - USART Control and Status Register A
UCSR0A = (0<<RXC0) | (0<<TXC0) | (0<<UDRE0) | (0<<FE0) | (0<<DOR0) | (0<<UPE0) | (0<<U2X0) | (0<<MPCM0);
/// Register UCSR0B - USART Control and Status Register B
...

oder so

...
/// Module USART - USART
/// Register group USART0 - USART
/// Register UDR0 - USART I/O Data Register 0
UDR0 = 
/// Register UCSR0A - USART Control and Status Register A
UCSR0A = 
      (0<<RXC0) // USART Receive Complete
    | (0<<TXC0) // USART Transmitt Complete
    | (0<<UDRE0) // USART Data Register Empty
    | (0<<FE0) // Framing Error
    | (0<<DOR0) // Data overRun
    | (0<<UPE0) // Parity Error
    | (0<<U2X0) // Double the USART transmission speed
    | (0<<MPCM0); // Multi-processor Communication Mode
...

aus.

Den Code und Details zur Benutzung gibt es im Git-Repository. Mal sehen, welche Tülchen in dem Dunstkreis sonst noch entstehen.

AVR, ferngesteuert

Die AVRs der 0/1-Serie verwenden zum Programmieren und Debuggen UPDI, welches etwas vereinfacht gesprochen ein auf UART basierendes Protokoll ist.

Dementsprechend hat es nicht lange gedauert, bis es pyupdi entstanden ist. Mit diesem Tool bzw. Library reicht eine serielle Schnittstelle vom PC (mit TTL-Level) und ein Widerstand, um Programmcode auf den Mikrocontroller zu bekommen.

Neben den Programmierfunktionen bietet die Schnittstelle ebenfalls die Möglichkeit zu Debuggen. Zu dem Funktionsumfang gehört gleichermaßen das Auslesen und Schreiben von Registern. Warum das nicht einfach nutzen, um direkt über den PC die Ports und Peripherie-Module des Chips zu verwenden?

Das Schreiben und Lesen im Adressraum der CPU sind gut dokumentiert, der einzige Haken ist, dass eine etwaig geflashte Firmware weiterläuft und einem die Suppe versalzen kann (oder andersrum). Zum Debuggen gehört natürlich auch, die Ausführung der CPU anzuhalten, wozu ich allerdings keine Dokumentation bzw. Informationen finden konnte. Aber macht nichts, einiges vom Protokoll ist ja bekannt und ein bisschen Reverse Engineering bin ich ja nicht abgeneigt. Unterm Strich ist es anscheinend recht trivial: Es muss ein Key geschrieben werden und in ein „reserviertes“ Control-Register eine 1 zum Anhalten und eine 2 zum Ausführen schreiben.

Mehr Details und ein kurzes Demo-Video ist im updizombie-Repository zu finden.

Unc2Clipboard – f..k me on GitHub

es ist natürlich „fork“ gemeint.

Ich habe mich lange gesträubt, einen Webservice für SCM (source code management) zu verwenden. Ok, ehrlich gesagt: für private Basteleien ist die Faulheit relativ groß, ein Werkzeug wie Subversion, Git oder Zip-Dateien zu verwenden.

Aber manchmal muss man einfach ein bisschen mit der Zeit gehen.

Das erste „vollständige“ Projekt ist ein kleines und hoffentlich praktisches Werkzeug für alle, die gemeinsam auf Netzwerkfreigaben auf Netzwerkfreigaben arbeiten: Unc2Clipboard.

Problemstellung: Man hat eine Ordnerfreigabe als Netzlaufwerk gemappt und möchte einen Link darauf teilen. Windows hat im Kontextmenü des Explorer zwar die Funktion „Als Pfad kopieren“ (man muss die Umschalttaste gedrückt halten, damit der Eintrag erscheint), allerdings hierbei wird der Pfad mit Laufwerksbuchstaben kopiert. Dieser funktioniert auf PC A, aber nicht zwangsläufig auf PC B.

Um Netzwerkressourcen zu adressieren benutzt Windows die Uniform Naming Convention, die unabhängig von lokalen Mappings funktioniert.

Lösung: Mit Unc2Clipboard wird ein neuer Eintrag im Kontextmenü erzeugt, mit dem der Pfad entsprechend formatiert und in die Zwischenablage kopiert werden kann:

Der Code ist unter https://github.com/chris-heo/Unc2Clipboard zu finden, für die Mutigen gibt es auch einen v1.0 Release mit Kompilat. Auch oder gerade weil der Code mit bestem Wissen und Gewissen zusammenkopiert wurde gilt: Benutzung auf eigene Gefahr.