Bjarne and Trevor have both written some compelling perspectives on the use of microcontroller firmware, particularly about how to constrain its scope. Here’s another perspective.
Recently we had a discussion about a new product we’re developing and the role of firmware in it. Trevor suggested that the entire functionality could be achieved completely in logic and hardware. A fuzzy thought about apples and oranges came to mind: If I wrote some firmware to implement the resulting logic, it would be the simplest and lowest risk firmware ever. In this instance, the suggestion was an option to keep project cost and scope in check but it occurred to me that applying this as a thought-experiment to other projects might be a useful tool, even if those projects ended up including firmware after all.
Putting a micro into a design has some huge advantages: Reduced part count, simpler hardware, increased flexibility in the design and increased feature set with minimal BOM cost impact. It would only be fair to also point out some of the disadvantages as well: Increased design complexity, the burden of code versioning, lack of design transparency and increased potential for scope creep. Perhaps the one with the biggest potential for causing disasters is that last one. If you’ve got a reasonably creative engineer working on the project it will be almost impossible to prevent all sorts of cool features being snuck in. Firmware is frequently the largest and most complex part of modern medical electronic devices so pinching off this scope bloat is pretty important. This was Trevor’s point in a nutshell.
So what would this thought-experiment accomplish? When I design hardware I tend to distill requirements to the essentials which helps squeeze the functionality into the minimum PCB real-estate and component count. Keeping logic simple, elegant and well-drawn in the schematic are broadly understood techniques which result in successful designs. The engineer is constantly pushing to reduce scope. Oddly, these same techniques don’t seem to be applied when designing firmware. In fact, there is a pervasive perception that features in firmware come for free. This may be somewhat true in production but it really, really isn’t during product development. If your micro has 1K left and 20% of its CPU cycles unallocated, then adding that great additional feature may not increase the BOM cost a bit but the effort to add, debug and document any additional hazard mitigations of that feature was likely not planned for. Maybe if additional features had such an obvious cost impact as they do in hardware, they would be considered more carefully. With that in mind it might be quite helpful to use this technique as a means to push back on the firmware requirements.
Another advantage of this thought-experiment is that it allows us to think about the problem in a more tangible way. Good software and firmware design usually begins with creating a model for your code to aid in design and debugging. This traditionally is done with flowcharts and nowadays UML adds a few extra twists as well. These methods try to visually represent the complex interactions of the algorithms that the firmware implements in a way that helps us analyze and communicate all of the intricacies. Perhaps thinking about and solving a problem using well-known logic building blocks like flip-flops, gates, counters, and the like will constrain the problem to a more intuitive solution-space and it may also be simpler to communicate. It certainly communicates complexity better than the abstract line or function count that might otherwise be used to measure traditional firmware.
I guess I’m always looking for different ways to attack problems that might result in better solutions. This idea of thinking in logic to write firmware has the benefit of attacking the problem and the scope at the same time.