Why does my firmware need … architecture?

Every design has its architecture, but if your design is small enough, you may not need to consider it separately. I will qualify this heresy after I’ve defined how I use a couple of very important words.

Firmware — The operational program that runs on an embedded processor with significant resource constraints. Although fast 32-bit micro-controllers are now commonplace, 8 kBytes of RAM is quite normal, and 64 kBytes is undreamed-of luxury. Supported (and supportable) languages are assembler, C and C++, although the latter is rarely used. Resource limitations mean that firmware cannot support WinCE, embedded Linux or Android.

Architecture — Like “design”, “architecture” is difficult to define. It is a superficial overview of your design, but it extends down to the smallest details. Grady Booch said “All architecture is design, but not all design is architecture”. Architecture is the collected features — the significant ones — that define your design. But it is also the collected details that enable these features to be reified. Consider your design as a flower, and each significant feature as a petal. Your architecture must describe each petal well enough for it to be designed and built, but it must also describe how the features (petals) blend together to make a flower. At the detail level, even petal-attachment protocols may be needed. 😉

So why does my firmware need architecture? Like RTOSs (link), your firmware has architecture anyway, so “need” doesn’t really come into it. It has design too (link), which incorporates your architecture. In software, it is normal and desirable – if not mandatory — to consider the application’s architecture separately. This should sometimes be the case for firmware too. But, for the smallest firmware, the design is compact enough that splitting it into architecture and ‘the rest’ is one simplification beyond necessity. The whole is simple enough that it is acceptable just to consider its design (where that design silently embraces and includes the architecture).

You can tell if you should consider your application’s architecture separately by answering this simple question: Will my design be clearer and easier to understand if I split it into architecture and the rest? Just enough design applies to architecture too.

This blog post is the latest in a series that is longer than I expected it to be. 🙂 Their main (intended) purpose is to stimulate discussion, so please leave a comment. Thanks for dropping by! [Find me on Twitter as @Patternchaser.]

Why does my firmware need … architecture?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s