Hello World!
This is the first blog post about designing reliable firmware for devices. It isn’t the first blog on this subject, but it is my first blog. So I ask for a little patience while I learn how to do this.
This is a blog about writing code for devices — what us ol’ timers would call embedded hardware. Devices are things that are held, sit on a desktop or simply attached to something else. These devices may cause things to move, push, pump, open/close or they may simply monitor the environment. It doesn’t matter whether they are industrial, medical, consumer, etc. Devices, however, are not computers in a small box. They do not run programs or “apps”. As far as I am concerned “embedded PC” and “embedded Linux” are oxymorons. Please don’t send email. You will never convince me that a “box” with more RAM and non-volatile storage (e.g. Flash) than many of the largest minicomputers running an OS whose footprint is measured in megabytes is “embedded”. (If you don’t know what a “minicomputer” is, you can follow this link to Wikipedia.)
Anyway, this blog is about the construction of firmware for devices so they operate properly. You may note that I avoid using the word “correct” to describe firmware. Correct firmware might mean many things to different people. Correct could mean simple compliance with the C90 standard; some may believe it is the smallest possible code or the fastest possible code. I have heard some rant that code is not correct unless it could not be made better. Heaven save us from these people.
To me “correct” always seemed to imply that there is some higher authority who declares code “correctness”. But there is no functional higher authority. There are no tools, no checkers and no standards that can determine whether the code works. We can have code that compiles with no warnings, passes Lint, conforms to MISRA and still doesn’t work properly. So these particular “higher authorities of correctness” are not sufficient.
I don’t discuss “correct code” with my clients; we discuss device behavior. We establish what must the device do and, just as important, what must the device “not do”. Ultimately, behavior alone is the test of a properly operating device.
In other words, “No misbehaving”.