This will be (I think) the last post in the exploration of LED pattern control. I’m going to build on the previous post to explore how we might include brightness in the design, as this was one of the features that would have been delivered if we had used “The Electrical Engineer Way”. There are two main designs that spring to mind here (nevermind there are many ways to achieve them):

The last post ended just before the real deal…patterns with colours. However, this post is hot on its heals because adding colour support is straightforward…it is entirely controlled by the “application space” code. That’s right…all of the “Led Manager” stuff can be used unchanged…as can all of the code that changes the states. The only code that needs to be adjusted is the code that registers the patterns. It needs to be updated to:

So where to next? The code from the end of the last post is a long way from anything useful, but the point is to illustrate an idea more than deliver a library. We should, however, have the goal of some sort of “Led Manager” in mind, that can encapsulate some of this behaviour around managing LEDs and the patterns we want them to show. A LED Manager, how it might look One of my favourite Eric Evans quotes is (paraphased) “client code ignores the implementation, developers do not”.

Every embedded product since the first Blinky program has had its own variety of LED flash patterns. You know the ones I mean, flash green once every two seconds if everything is ok, and once every half a second if something bad has happened. But it never stays that simple. There’s always someone who says “that’s great…but for serious errors can you flash like this, and for warnings like that”, and before long you have a plethora of patterns that make the POST beep patterns look paltry.