Als het leven geen foutopsporingsinterface biedt, knippert een RGB-led

Ja dat weet ik; als we producten van goede kwaliteit willen maken, hebben we geschikte tools nodig, inclusief adequate poorten voor foutopsporing, maar het leven, zoals je weet, wordt soms vervelend.

Onlangs in mijn freelancecarrière ontdekte ik dat twee van mijn klanten er niet in waren geslaagd om enige vorm van tekstuele foutopsporing aan hun producten toe te voegen. Een keer vergaten de hardware-ontwerpingenieurs gewoon om zo'n kanaal toe te voegen, maar realiseerden zich hun fout pas nadat ze zich hadden gecommitteerd aan een grote voorraad boards. In een ander voorbeeld was het product zo geminiaturiseerd dat er geen ruimte meer was. Gelukkig was er in beide gevallen een RGB (driekleurige) LED beschikbaar die ik kon gebruiken als hulpmiddel bij het debuggen. Op basis van het feit dat wanneer je citroenen krijgt, het enige wat je kunt doen is limonade maken, heb ik uiteindelijk de RGB-led gebruikt om een ​​knipperend berichtensysteem te implementeren.

Uit deze ervaring was ik verrast om te ontdekken dat foutopsporing op basis van RGB LED uiterst praktisch en onverwacht rijk aan functies kan zijn, zolang er maar een mensvriendelijk modulatieschema wordt gebruikt.

De manier waarop mijn berichten werden gemoduleerd, was door verschillende kleuren te selecteren om de codecontext weer te geven en een knippertelling en -stijl te kiezen om een ​​specifiek bericht in die context weer te geven. Knipperingen worden in de wachtrij geplaatst en worden achtereenvolgens weergegeven op de LED, vergelijkbaar met de manier waarop een standaard tekstueel logkanaal korte tekstberichten zou verwerken.

De LED-foutopsporingsmodule had vier soorten knipperende ritmes geïmplementeerd met behulp van de volgende functies:

• led_debug_blink (kleur, getal) voor een kort knipperende indicatie.
• led_debug_blink_wide (kleur, aantal) voor een langer knipperende indicatie die wordt gebruikt voor meer relevante situaties.
• led_debug_blink_error(kleur, getal) en led_debug_blink_wide_error(kleur, getal) voor korte en langere foutindicaties, met respectievelijk dezelfde functionele handtekeningen als de andere.

Elk van deze functies zal een uniek knipperproces creëren. Normale knipperingen zijn actief gedurende één seconde, gescheiden door intervallen van een halve seconde, terwijl brede knipperingen actief zijn gedurende twee seconden, gescheiden door intervallen van een halve seconde. Foutmeldingen worden aangegeven met de rode kleur gevolgd door knipperende contextkleuren zoals geïllustreerd in Afbeelding 1.

Merk op dat de gele gebieden in figuur 1 worden gebruikt om de geselecteerde context aan te geven. Als we besluiten om de RGB-leds gewoon aan of uit te zetten, dan kunnen de gele gebieden in figuur 1 groen, blauw, geel, cyaan, magenta of wit zijn; dat wil zeggen, elke kleur die beschikbaar is door de RGB-LED's in of uit te schakelen, behalve zwart (allemaal uit) en rood (gebruikt om een ​​fout aan te geven). Als we besluiten om pulsbreedtemodulatie (PWM) te gebruiken, kunnen we een breder kleurengamma bereiken. Goedkope RGB-LED's zijn echter niet geweldig als het gaat om het mengen van kleuren, dus het kan moeilijk zijn om bepaalde combinaties te onderscheiden, terwijl andere, zoals oranje, redelijk goed lijken te werken.

De knipperende perioden en methodologie zijn zorgvuldig gekozen om de menselijke leesbaarheid te vergemakkelijken, wat voldoende bleek voor de ingenieurs tijdens de ontwikkelingsfase en ook voor de veldtechnicus tijdens tests, op voorwaarde dat overmatige berichtgeving via de LED werd vermeden.

Debuggen met een LED is niet ideaal, maar in de systemen waar ik aan werkte, hielp het de ontwikkeling en tests in het veld te versnellen door een snelle manier te bieden om de systeemstatus te observeren zonder dat er apparatuur op de producten was aangesloten. Er was wat training voor nodig om het team te laten wennen aan de betekenis van elke kleurcontext en het knipperende ritme, maar het duurde niet lang om te leren. Het belangrijkste was dat ze elk onderscheid moesten maken tussen informatieve berichten en foutmeldingen, en ons schema bood voldoende informatie om ons snel te laten bepalen welk stukje code fout was gegaan.

Ik geloof dat dit een voorbeeld is waarbij een kleine inspanning om het systeem af te stemmen op de mogelijkheden van de mensen die het gebruiken, een potentieel moeilijk te gebruiken debugging-interface in een verrassend effectieve interface transformeerde.

Felipe Lavratti heeft op internet aangesloten apparaten voor domotica ontwikkeld, embedded Linux-applicaties en stuurprogramma's voor handheld point-of-sale-machines ontwikkeld en embedded wiskundige algoritmen geïmplementeerd voor procesbesturing en dataloggers voor industriële toepassingen. Al vroeg in zijn carrière besefte Felipe het belang van kwaliteit, dus hij past elke moderne techniek toe die nodig is om robuuste producten tot leven te brengen; elk onderdeel van het ontwikkelingsproces wordt beheerd op kwaliteit:codering, testen, acceptatie, implementatie, integratie en implementatie. Momenteel werkt Felipe als freelance consultant en ontwikkelaar. Hij is bereikbaar via