When life fails to provide a debugging interface, blink a RGB LED

February 28, 2017

felipe-lavratti-February 28, 2017

Yes I know; if we want to create good quality products we need appropriate tools, including adequate debugging ports, but life, as you know, sometimes gets nasty.

Recently in my freelancing career, I discovered that two of my clients had failed to add any kind of textual debugging textual their products. On one occasion, the hardware design engineers simply forgot to add such a channel, only realizing their mistake after they had committed themselves to a large stock of boards. In another example, the product was so miniaturized that there was no space. Fortunately, in both cases there was an RGB (tri-color) LED available for me to use as an aid to debugging. On the basis that sometimes when you are given lemons the only thing you can do is make lemonade, I ended up using the RGB LED to implement a blinking messaging system.

From these experience, I was surprised to discover that RGB LED-based debugging can be extremely practical and unexpectedly feature rich, just so long as a human-friendly modulation scheme is employed.

The way my messages were modulated was by selecting different colors to represent the code context and choosing a blink count and style to represent a specific message in that context. Blinks are queued and displayed sequentially on the LED, similar to the way in which a basic textual logging channel would handle short text messages.

The LED debugging module had four types of blinking rhythms implemented using the following functions:

  • led_debug_blink (color, number) for a short blinking indication.
  • led_debug_blink_wide (color, number) for a longer blinking indication used for more relevant situations.
  • led_debug_blink_error(color, number) and led_debug_blink_wide_error(color, number) for short and longer error indications, with the same functional signatures as the others, respectively.

Each of these functions will create a unique blinking process. Normal blinks are active for one second separated by half-second intervals, while wide blinks are active for two seconds separated by half-second intervals. Error messages are indicated with the red color followed by context color blinks as illustrated in Figure 1.


Blink time diagrams for the four standard and error debug functions
(Click Here for a larger image. Source: Felipe Lavratti)

Note that the yellow areas in Figure 1 are used to indicate the selected context. If we decide to simply turn the RGB LEDs on or off, then the yellow areas in Figure 1 could be green, blue, yellow, cyan, magenta, or white; that is, any color available from turning the RGB LEDs on or off apart from black (all off) and red (used to indicate an error condition). If we decide to use pulse-width modulation (PWM), we can achieve a wider gamut of colors. However, cheap RGB LEDs aren’t great when it comes to mixing colors, so it can be difficult to distinguish certain combinations, while others -- like orange -- seem to work reasonably well.

The blinking periods and methodology were carefully chosen to ease human readability, which proved to be sufficient for the engineers during the development phase and also for the field technician during tests, providing that excessive messaging via the LED was avoided.

Debugging with a LED is not ideal, but in the systems I was working on it helped speed development and tests in the field by providing a fast way to observe the system state without any kind of apparatus connected to the products. It required a little training in order for the team get used to the meaning of each color context and blinking rhythm, but it didn’t take long to learn. Most importantly, it was each to distinguish between informational messages and error messages, and our scheme provided sufficient information to let us quickly determine which piece of code had gone wrong.

I believe this is an example where a small amount of effort to tune the system to the capabilities of the humans using it transformed a potentially hard-to-use debugging interface into a surprisingly effective one.

Felipe Lavratti has developed Internet connected devices for home automation, created embedded Linux applications and drivers for handheld Point-of Sale machines, and implemented embedded mathematical algorithms for process control and data loggers for the industrial applications. Early on in his career, Felipe realized the importance of quality, so he adopts every modern technique necessary to bring robust products to life; each part of the development process is managed for quality: coding, testing, acceptance, deployment, integration, and deployment. Currently, Felipe works as a freelance consultant and developer. He can be contacted at felipelav@gmail.com

Loading comments...