Sometimes you just feel that your firmware isn't robust enough, isn't reliable enough. What if my firmware isn't handling edge cases very well?

First of all, I admire your concerns, because if you really think that way, that means you have a high standard when it comes to firmware development, really.

Because the majority of embedded engineers aren't even aware that their firmware should be robust and reliable. For them, as long as the firmware isn't crashing after 5 minutes of running, it's good and they move on to implement the next cool things.

That's very wrong on so many levels.

The firmware should be well-tested and you should understand every line of code you've written. The firmware should meet the requirements, and pass the performance threshold. For me, such firmware is called confident firmware.

You can be reasonably confident that your work is good enough to survive common scenarios and some special edge cases. Make no mistake, because confident firmware isn't equal to bug-free firmware. But whenever the firmware has bugs, you can confidently pinpoint the root cause and immediately fix the issue.

The unsure feeling you have can be eliminated (or at least reduced) when you know everything about the firmware you develop, this is including:

1. how each module interacts with the others
2. how each module has been tested
3. how each module is written

That's why I call my method as 3D Method: Draw, Dissect, Detect.

3D: Draw, Dissect, Detect

Now, let's delve into each step:

Draw

Every great software should have at least one diagram to explain the interaction between modules.

Humans, by nature, cannot comprehend chaos and complexity. That's why we invented maps to navigate the road, that's why we created organizational diagrams to show who is responsible for what.

In other words, we create abstraction to help ourselves manage chaos and complexity.

When it comes to firmware development, that means we draw firmware architecture diagrams, program flow diagrams, and hardware design diagrams. In my paid firmware development guide, I explain more deeply how you can draw diagram for your embedded project. Here's an example of a firmware architecture diagram I've drawn for the guide:

If you mastered the Draw step, you will be far more confident in your firmware design. You know which parts will do A, which part will do B, etc. Even if your project has bugs, you will immediately know where to look.

Dissect

Dissecting your code, or reviewing your code, is a sure way to make sure the firmware will work as intended. Sometimes you can do it alone, or you can ask your senior or even junior engineers to help dissect/review your code. Because as Linus Torvalds said:

given enough eyeballs, all bugs are shallow

Linus's Law

Yes, the more reviews, the more bugs can be discovered earlier.

If you think reviewing code is a tedious process, you are right, but you are also a bit wrong. Because I didn't say only humans can review your code. Sometimes robots (aka software) can help you catch silly mistakes here and there.

A good example of this robot is static analyzer. It's software that scans your entire firmware code to find some potential issues, sometimes it spits false-positive issues, but often it catches serious mistakes (like vulnerabilities or semantical errors).

So, use both humans and robots to maximize profit confidence.

Detect

Detect problems by testing your firmware code.

This can be achieved by writing unit tests, where you test each module with a set of inputs and expect certain outputs.

Testing can be automated. In fact, code testing should be automated. You can achieve this by using automation tools like GitHub Actions, so whenever you push changes to GitHub, it will automatically rerun the tests you've written, and report the result.

I recommend you to use Catch2, because it is simple enough and easy enough to get started. Combine it with CMake and GitHub Actions, your life will be far easier. I cover this much deeper in my paid firmware guide, I also give you a demo to setup GitHub Actions.

Summary

That's all to know. To make yourself more confident in your firmware, implement my 3D Method above and you will finally sleep better tonight.

Just remember that confidence doesn't guarantee bug-free, you still need to check and hunt for bugs. But at least, when you are confident, you can locate the issues much faster.

Whenever you're ready, there are 2 ways I can help you:

1. FREE Firmware Development Email Course. A free 7-Day Email Course to teach you the foundational concepts you should know to start firmware development. Full of practical tips and industrial insights.

2. FREE Embedded Freelancing Email Course. Another free Email Course to help you grasp the basics of embedded freelancing and make more money as an embedded engineer.