Archive for September, 2006

Free as in, well, Free Software

Wednesday, September 27th, 2006 Michael Barr

There’s no such thing as free beer. But free software abounds. It seems that everywhere I look these days companies are offering their embedded operating systems and tools for free evaluation. Often, the price includes full access to the source code.

Examples just this week include the announcement that Quantum Leaps would make the source code for its previously proprietary QP-nano product available under GPL, that Micrium would release the source code for the TCP/IP stack it developed at great expense under a 45-day evaluation license, and that Hitachi‘s brand new Entier relational database could be downloaded for use in 30-day trials.

Given access to the source code of a complicated product such as an operating system, network stack, or relational database how many people pay? A restrictive license is perhaps a legal consideration, but if these guys can afford to give their source code out wily nily how do you feel about being the only schmuck to actually cough up dough? Does anyone buy embedded software components anymore?

Educating Engineers

Friday, September 22nd, 2006 Michael Barr

Engineering is a fast-moving field. Even embedded systems design, which is known to use decades old tools, sees new processors and new peripherals and higher speeds and new languages and new techniques arrive continuously.

Unlike the medical profession, which requires continuing education to keep pace with changes in the knowledge base, engineers generally stop learning formally once they obtain a University degree. There is no such thing as Continuing Engineering Education credits.

Symptoms of the resulting intellectual stasis include not only a failure to keep up with evolving best practices, but also the perpetual desire of businesses to hire younger, freshly-educated engineers whether here or abroad.

If we as engineers are to continue to deliver value commensurate with our growing salaries, we must dedicate ourselves to the kind of perpetual learning required in other professions. Only then will the trend toward the use of more fresh-out and offshore engineers be slowed.

What do you think?

Embedded Systems Bloggers

Wednesday, September 20th, 2006 Michael Barr

There are currently just a handful of bloggers writing about embedded systems development. So I thought I’d take a minute to introduce the others I’ve run across.

There are, of course, three of us blogging at EmbeddedGurus.net. The others are: Nigel Jones who writes Stack Overflow and Dr. Miro Samek who authors State Space. Each of these guys has unique expertise that is very different from my own.

Another embedded developer who blogs is Harvey Sugar; he calls his blog Nerd1951. I’m hoping to run into Harvey at the Embedded Systems Conference next week in Boston–an event from which I’ll be blogging quite a bit.

On a related but different note, industry analyst Christopher Lanfear calls his blog about the tool vendors and their funding On Target.

Please let me know if you’ve found other related blogs (or you write one).

Perils of Preemption

Saturday, September 16th, 2006 Michael Barr

Embedded.com just picked up a paper I wrote for the upcoming Embedded Systems Conference in Boston. The paper is about the downsides of the dominant RTOS (real-time operating system) scheduling algorithm. It turns out that priority-based preemptive scheduling has one key benefit but more than ten important caveats.

Unfortunately, the formatting and editing was screwed up in several ways in Embedded.com’s publication of this paper. But I have republished it at http://www.netrino.com/Embedded-Systems/How-To/Preemption-Perils.

I’ll be speaking about alternatives to priority-based preemptive RTOSes in Boston on Tuesday, September 26.

Firmware Code of Ethics

Friday, September 15th, 2006 Michael Barr

WE THE MEMBERS OF THE EMBEDDED SOFTWARE COMMUNITY, in order to protect our customers (and their customers) from the risks inherent in our products, extend product lifetimes, lower long-term maintenance costs, promote the general welfare of society, and advance the integrity and reputation of our profession, do hereby ordain and establish the following code of ethical conduct.

Check return codes. If a function can return an error code, it will almost certainly return one eventually. How will our software recover if it doesn’t even know an error has occurred? We will, therefore, always check all return codes. When an error is detected, we will take whatever action is required to recover safely.

Document reasoning. We make dozens of design and implementation decisions each week; we forget the reasoning behind others at a similar pace. We will, therefore, document all of our reasoning in the code itself. Furthermore, we will update these comments if our reasoning changes.

Use version control. Even when done carefully and with discipline, making backup copies of source directories, commenting out code that might be needed again, and tracking changes in comments is insufficient. The use of a good configuration management tool is a must. Furthermore, we agree to always perform a diff and provide a good description of the explanation for all changes each time a file is checked in.

Enforce coding standards. No matter how proud we may be of our abilities, we do not “own” the code we produce. Our employers and clients own it; we and others are hired to develop and maintain it. The true owners have the right to enforce a coding standard upon our work. If they do not choose to exercise this right, we will self-enforce a standard in line with generally accepted programming practices.

Run lint regularly. Compilers are more concerned with generating code than the correctness of your syntax. Only a static analysis tool like lint can watch over our shoulders to ensure we’re not straying into dangerous or non-portable programming constructs. We will, therefore, include lint in our development process. If we don’t remove all code with warnings, we will at least understand why each and every warning remains.

Perform code inspections. Automated tools are helpful, but nothing is better than a peer review for finding logic errors. Code inspections have been shown to be many times more efficient than any other single debugging tool. We will always review our code as a group at least once before each release.

Assign one tester to every developer. Programmers make lousy testers, especially when it’s their own code they’re testing. For best results, one independent tester should be hired for every developer. And the testing team must maintain and rerun regression tests regularly, to certify that a new release is at least as good as the previous one.

Measure performance. Of course, there are some kinds of tests that are best performed by the engineers themselves. In real-time systems, we shall directly measure interrupt latency and the time it takes each of our critical subroutines to complete. An oscilloscope and a spare I/O pin are quite handy in this regard.

These best practices are easy things to do, and all are inexpensive to implement. A one or two person design team can as easily follow these rules as a 50-person engineering department. If you aren’t following these rules today, there are no excuses for tomorrow.