Bluetooth Low Energy firmware applications have their inherent complexities. They’re structured as event-driven systems. That basically mean they react to “events” that can occur at any time. That’s physical event sources like button presses, battery alerts, and sensors inputs, but also to incoming Bluetooth communications from an App. In our experience, even top-tier chip vendors like Nordic Semiconductors provide subpar guidance on how to best orchestrate this system of events and reactions.
An unsuspecting developer may feel they’re using a lean approach, linking event sources in code to their corresponding reactions in a piecemeal fashion. The complexity of this patch network soon grows exponentially and starts feeling like a firmware savant is required just to make sense of it all. As the project grows, the event-reaction mappings grow in quantity and likely require being dynamically re-mapped in different modes of operation. If left untreated, the affliction can get the best of you, spreading faster than you add features. If you’re anything like us, there’s an inevitable face-the-music moment where this event-driven spaghetti code can no longer be tolerated.
This isn’t the glutinous spaghetti that you bite with your teeth. It’s the kind that compiles into bytes and bites to deal with. If you’re not aware of spaghetti code and its nauseating effects, then let’s briefly recap. “Spaghetti code” is a slang term for code with convoluted structure, so much that it’s difficult to debug and and maintain it.
