Wenn das Leben keine Debugging-Schnittstelle bietet, blinken Sie eine RGB-LED

Ja, ich weiß; Wenn wir qualitativ hochwertige Produkte erstellen wollen, brauchen wir entsprechende Tools, einschließlich angemessener Debugging-Ports, aber das Leben wird, wie Sie wissen, manchmal unangenehm.

Vor kurzem in meiner freiberuflichen Karriere entdeckte ich, dass zwei meiner Kunden es versäumt hatten, ihren Produkten irgendeine Art von textuellem Debugging hinzuzufügen. Einmal haben die Hardware-Konstrukteure einfach vergessen, einen solchen Kanal hinzuzufügen, und haben ihren Fehler erst bemerkt, nachdem sie sich auf einen großen Vorrat an Boards festgelegt hatten. In einem anderen Beispiel war das Produkt so miniaturisiert, dass kein Platz vorhanden war. Glücklicherweise stand in beiden Fällen eine RGB-LED (dreifarbig) zur Verfügung, die ich als Debugging-Hilfe verwenden konnte. Ausgehend davon, dass man manchmal, wenn man Zitronen bekommt, nur Limonade zubereiten kann, habe ich die RGB-LED verwendet, um ein blinkendes Nachrichtensystem zu implementieren.

Aufgrund dieser Erfahrungen war ich überrascht zu entdecken, dass RGB-LED-basiertes Debugging äußerst praktisch und unerwartet reich an Funktionen sein kann, solange ein menschenfreundliches Modulationsschema verwendet wird.

Meine Nachrichten wurden moduliert, indem ich verschiedene Farben auswählte, um den Codekontext darzustellen, und eine Blinkanzahl und einen Stil wählte, um eine bestimmte Nachricht in diesem Kontext darzustellen. Blinks werden in eine Warteschlange gestellt und nacheinander auf der LED angezeigt, ähnlich wie ein einfacher Textprotokollierungskanal kurze Textnachrichten verarbeiten würde.

Das LED-Debugging-Modul hatte vier Arten von Blinkrhythmen, die mit den folgenden Funktionen implementiert wurden:

• led_debug_blink (Farbe, Zahl) für ein kurzes Blinken.
• led_debug_blink_wide (Farbe, Zahl) für eine längere blinkende Anzeige, die für relevantere Situationen verwendet wird.
• led_debug_blink_error(Farbe, Zahl) und led_debug_blink_wide_error(Farbe, Zahl) für kurze und längere Fehleranzeigen, jeweils mit den gleichen Funktionssignaturen wie die anderen.

Jede dieser Funktionen erzeugt einen einzigartigen Blinkvorgang. Normales Blinken ist eine Sekunde lang in Halbsekunden-Intervallen aktiv, während breites Blinken zwei Sekunden lang in Halbsekunden-Intervallen aktiv ist. Fehlermeldungen werden mit roter Farbe gefolgt von blinkenden Kontextfarben angezeigt, wie in Abbildung 1 dargestellt.

Beachten Sie, dass die gelben Bereiche in Abbildung 1 verwendet werden, um den ausgewählten Kontext anzuzeigen. Wenn wir uns entscheiden, die RGB-LEDs einfach ein- oder auszuschalten, könnten die gelben Bereiche in Abbildung 1 grün, blau, gelb, cyan, magenta oder weiß sein; das heißt, jede Farbe, die durch das Ein- oder Ausschalten der RGB-LEDs verfügbar ist, abgesehen von Schwarz (alle aus) und Rot (wird verwendet, um einen Fehlerzustand anzuzeigen). Wenn wir uns für die Pulsweitenmodulation (PWM) entscheiden, können wir eine größere Farbskala erreichen. Allerdings sind billige RGB-LEDs nicht so toll, wenn es um das Mischen von Farben geht, daher kann es schwierig sein, bestimmte Kombinationen zu unterscheiden, während andere – wie Orange – einigermaßen gut zu funktionieren scheinen.

Die Blinkzeiten und die Methodik wurden sorgfältig gewählt, um die menschliche Lesbarkeit zu erleichtern, was sich für die Ingenieure während der Entwicklungsphase und auch für den Außendiensttechniker während der Tests als ausreichend erwies, sofern eine übermäßige Nachrichtenübermittlung über die LED vermieden wurde.

Das Debuggen mit einer LED ist nicht ideal, aber in den Systemen, an denen ich arbeitete, half es, die Entwicklung und Tests im Feld zu beschleunigen, indem es eine schnelle Möglichkeit bot, den Systemzustand zu beobachten, ohne dass irgendwelche Geräte an die Produkte angeschlossen waren. Es erforderte ein wenig Training, damit sich das Team an die Bedeutung der einzelnen Farbzusammenhänge und Blinkrhythmen gewöhnte, aber es dauerte nicht lange, um es zu lernen. Am wichtigsten war es, zwischen Informations- und Fehlermeldungen zu unterscheiden, und unser Schema lieferte genügend Informationen, um schnell feststellen zu können, welcher Code schief gelaufen war.

Ich glaube, dies ist ein Beispiel, bei dem ein kleiner Aufwand, um das System auf die Fähigkeiten der Benutzer abzustimmen, eine potenziell schwer zu verwendende Debugging-Schnittstelle in eine überraschend effektive verwandelt hat.

Felipe Lavratti hat mit dem Internet verbundene Geräte für die Heimautomatisierung entwickelt, eingebettete Linux-Anwendungen und Treiber für tragbare Point-of-Sale-Maschinen entwickelt und eingebettete mathematische Algorithmen für die Prozesssteuerung und Datenlogger für industrielle Anwendungen implementiert. Zu Beginn seiner Karriere erkannte Felipe die Bedeutung von Qualität und wendet alle modernen Techniken an, die erforderlich sind, um robuste Produkte zum Leben zu erwecken. Jeder Teil des Entwicklungsprozesses wird auf Qualität hin verwaltet:Codierung, Test, Abnahme, Bereitstellung, Integration und Bereitstellung. Derzeit arbeitet Felipe als freiberuflicher Berater und Entwickler. Er ist erreichbar unter