tibuttzsprpe

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

first_img March 1, 2017 at 3:25 pm Log in to Reply Log in to Reply Max The Magnificent says: Max The Magnificent says: Max The Magnificent says: Log in to Reply “It’s love to see a series of regular messages and error messages being displayed — is there any chance you could post a short video on YouTube?” Log in to Reply 7 thoughts on “When life fails to provide a debugging interface, blink a RGB LED” Max The Magnificent says: “I meant to say “I’d love…”” February 28, 2017 at 7:05 pm March 1, 2017 at 3:21 pm “In a comment to Aubrey’s column, TonyTib said “A side note, the CANOpen standard specified standard colors and flashing patterns for status LEDs” and Aubrey responded as follows:n nI found a description on P9 of this documentn nhttp://www.leinelin “Another thing that just struck me is that, when they see this column, a lot of experienced engineers might think “Well, using a LED in this way is obvious.” On the one hand this is true — on the other hand, since there’s little written down about this “It’s funny when I come to think about it — because I’ve used blinking LEDs to indicate status and error conditions for years — but it never struck me to wonder if there were any standards for this sort of thing.nnIn the case of your diagrams, I’m wond “Aubrey Kagan wrote an article on this “Flashing LEDs” recently: http://www.embedded.com/electronics-blogs/without-a-paddle/4457638/Flashing-LEDs“ February 28, 2017 at 9:45 pm “The gap is there to space consecutive messages from joining together, a 1 sec gap seemed fine. And red comes first to call the user to look at it before flashing the context color. We have experimented with it and it was effective to communicate to techni felipe-lavratti says: March 2, 2017 at 10:58 pm Log in to Reply Leave a Reply Cancel reply You must Register or Login to post a comment. This site uses Akismet to reduce spam. Learn how your comment data is processed. Max The Magnificent says: Max The Magnificent says: Share this:TwitterFacebookLinkedInMoreRedditTumblrPinterestWhatsAppSkypePocketTelegram Tags: EDA Log in to Reply March 2, 2017 at 10:57 pm 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 March 1, 2017 at 8:00 pm Log in to Reply Continue Reading Previous Tasteful batteriesNext “Toyota’s Killer Firmware” and the “Single Bit Flip That Killed”? Not!last_img

Leave a Reply

Your email address will not be published. Required fields are marked *