Quando a vida falha em fornecer uma interface de depuração, piscar um LED RGB

Sim eu sei; se queremos criar produtos de boa qualidade, precisamos de ferramentas adequadas, incluindo portas de depuração adequadas, mas a vida, como você sabe, às vezes fica desagradável.

Recentemente, em minha carreira de freelancer, descobri que dois de meus clientes não conseguiram adicionar qualquer tipo de depuração textual aos seus produtos. Em uma ocasião, os engenheiros de design de hardware simplesmente se esqueceram de adicionar tal canal, só percebendo seu erro depois de se comprometerem com um grande estoque de placas. Em outro exemplo, o produto estava tão miniaturizado que não havia espaço. Felizmente, em ambos os casos, havia um LED RGB (tricolor) disponível para eu usar como auxílio na depuração. Com base no fato de que às vezes, quando você recebe limões, a única coisa que você pode fazer é fazer limonada, acabei usando o LED RGB para implementar um sistema de mensagens piscando.

Com essa experiência, fiquei surpreso ao descobrir que a depuração baseada em LED RGB pode ser extremamente prática e inesperadamente rica em recursos, contanto que um esquema de modulação amigável seja empregado.

A forma como minhas mensagens foram moduladas foi selecionando cores diferentes para representar o contexto do código e escolhendo uma contagem de piscadas e estilo para representar uma mensagem específica naquele contexto. As piscadas são enfileiradas e exibidas sequencialmente no LED, semelhante à maneira como um canal de registro textual básico lidaria com mensagens de texto curtas.

O módulo de depuração de LED tinha quatro tipos de ritmos de piscar implementados usando as seguintes funções:

• led_debug_blink (cor, número) para uma breve indicação piscante.
• led_debug_blink_wide (cor, número) para uma indicação intermitente mais longa, usada para situações mais relevantes.
• led_debug_blink_error (cor, número) e led_debug_blink_wide_error (cor, número) para indicações de erro curtas e mais longas, com as mesmas assinaturas funcionais das outras, respectivamente.

Cada uma dessas funções criará um processo único de piscar. As piscadas normais ficam ativas por um segundo separadas por intervalos de meio segundo, enquanto as piscadas amplas ficam ativas por dois segundos separados por intervalos de meio segundo. As mensagens de erro são indicadas com a cor vermelha seguida por piscadas de cor de contexto, conforme ilustrado na Figura 1.

Diagramas de tempo de intermitência para as quatro funções de depuração padrão e de erro
(Clique aqui para uma imagem maior. Fonte:Felipe Lavratti)
Observe que as áreas amarelas na Figura 1 são usadas para indicar o contexto selecionado. Se decidirmos simplesmente ligar ou desligar os LEDs RGB, as áreas amarelas na Figura 1 podem ser verdes, azuis, amarelas, ciano, magenta ou brancas; ou seja, qualquer cor disponível ao ligar ou desligar os LEDs RGB, exceto preto (todos desligados) e vermelho (usado para indicar uma condição de erro). Se decidirmos usar modulação por largura de pulso (PWM), podemos alcançar uma gama mais ampla de cores. No entanto, LEDs RGB baratos não são bons quando se trata de misturar cores, então pode ser difícil distinguir certas combinações, enquanto outras - como o laranja - parecem funcionar razoavelmente bem.

Os períodos de intermitência e a metodologia foram escolhidos criteriosamente para facilitar a legibilidade humana, o que se mostrou suficiente para os engenheiros durante a fase de desenvolvimento e também para o técnico de campo durante os testes, desde que evitasse o envio excessivo de mensagens via LED.

A depuração com um LED não é o ideal, mas nos sistemas em que trabalhei ajudou a acelerar o desenvolvimento e os testes de campo ao fornecer uma maneira rápida de observar o estado do sistema sem nenhum tipo de aparato conectado aos produtos. Foi necessário um pouco de treinamento para a equipe se acostumar com o significado de cada contexto de cor e ritmo de piscar, mas não demorou muito para aprender. Mais importante, cada um deveria distinguir entre mensagens informativas e mensagens de erro, e nosso esquema fornecia informações suficientes para nos permitir determinar rapidamente qual código estava errado.

Acredito que este seja um exemplo em que um pequeno esforço para ajustar o sistema às capacidades dos humanos que o usam transformou uma interface de depuração potencialmente difícil de usar em uma interface de depuração surpreendentemente eficaz.

Felipe Lavratti desenvolveu dispositivos conectados à Internet para automação residencial, criou aplicativos e drivers Linux embutidos para máquinas de ponto de venda portáteis e implementou algoritmos matemáticos embutidos para controle de processo e registradores de dados para aplicações industriais. No início de sua carreira, Felipe percebeu a importância da qualidade, por isso adota todas as técnicas modernas necessárias para dar vida a produtos robustos; cada parte do processo de desenvolvimento é gerenciada quanto à qualidade:codificação, teste, aceitação, implantação, integração e implantação. Atualmente, Felipe atua como consultor e desenvolvedor autônomo. Ele pode ser contatado em