Two sides of reliability

daniel — Tue, 11 Mar 2008 05:38:00 GMT

One of the projects I finished recently was to assembly a microcontroller board and written the "driver" for the small LCD screen. The board uses an RISC AVR-microcontroller from ATMEL (ATmega8) with only 8K FLASH and 1K RAM and is connected to a 2x16 characters display. As you can see after few days of "debugging", the controller learns to spell "Advanced Windows Debugging", nicely centered on the LCD.

While working on this project I understood better the difference in the entry barrier between building hardware building software. What are exactly the differences?

First there are the tools.

For software development, the free tools can be found everywhere and we can use them after a simple download. For example, in "Advanced Windows Debugging" book we used WDK(free) to build the applications, we used Debugging Tools for Windows (free) to troubleshoot the applications which can be written created very well in any text editor(Notepad is free).

Looking for highly integrated or managed code development tools? Many are also available for free. For example Microsoft offers for download an "Express" version to all development tools for free.

If open source software is an option, you can easily find a tool that suits you needs.

The tools used in hardware development are not free for a good reason. With few exceptions most are physical objects. You cannot just download a COPY of a physical object, you have to pay the manufacturing and distribution costs. And you need tools from the moment you start building the hardware. Once the circuit is ready and powered on, you need measurement equipment for validating the design correctness. If the circuit uses processors, you must have another set of tools (usually expensive) to validate the application correctness and to debug the code running inside the embedded processors.

After the design is complete, the process of removing the remaining bugs from the products is also different. In software a bug is usually fixed by adding a code line, removing a code line, of even re-architecting a code section. In any case the cost of implementing those changes is relatively small.

The bugs discovered after the products release are easily fixed with a downloadable patch.

In hardware the problems are more difficult to fix dues to the high cost of prototyping and the cost of redesigning the circuits. And most important the bugs discovered by customers are causing product returns.

Although it seems that it is in fairly inexpensive and easy to release "bug-free" software products, we somehow accepted the error in software applications. When an internet browser crashes, we just restart it without any bad feelings. However, we have different expectation for a hardware device. If a cell phone, or a TV, or a music player freezes and require a "restart" we are not happy. When it happens too often, we end-up returning the products.

Due to the flexibility offered by providing some of the functionality in software the later devices incorporate more capabilities offered by software modules. Because this trend will continue and even accelerate, is interested what will happen with their reliability? We will learn to live devices that are not working properly or software running on such devices will be more reliable than the current desktop applications?

Daniel's blog : Firmware, Reliability

Two sides of reliability