Books for Coders and Thinkers

Jean Labrosse’s new work MicroC/OS-II, The Real Time Kernel ¹ appeared this past November. This volume replaces Labrosse’s previous book on his RTOS, and is virtually a complete rewrite. In it he discusses mC/OS-II. It’s predecessor, mC/OS, is famous as the most popular of the free RTOSes around.

With the new version, the licensing restrictions have been tightened up a bit. If you’re building a commercial for-profit product, a fee is now associated with the OS. This charge seems reasonable to me, as software costs money. I often wonder if free software isn’t some of the most expensive code around. Without some sort of effective—and always expensive—support organization, it’s awfully hard to do justice to complex code.

If you’re engaged on a project that already uses a commercial RTOS, this book may offer little of use. However, various surveys indicate that between 50% and 70% of all RTOSes used today are homebrewed; even more embedded projects make no use of an OS at all. There’s little doubt that the trend is strongly towards the use of these useful beasts.

There’s equally little doubt that rolling your own is, in nearly all circumstances, a mistake. A quick glance at mC/OS-II and a bit of math illustrates just how silly it is to build an OS from scratch. Labrosse’s code weighs in at about 4,000 lines of C, surely not huge by any measure. When our egos subjugate rational thought, many of us are tempted to think we could crank 4K lines of C in a week or two, but we can’t. After years of collecting cost data on embedded systems, I’ve found most commercial code costs around $15 to $30 per line, regardless of language. Labrosse’s mC/OS, then, represents as much as $120,000 of software engineering. Don’t believe me? Even if you divide the numbers by five, it’s clear that the cost of writing an RTOS is very high.

Many other commercial RTOSes are available for a few kilobucks, with and without royalty fees. That’s essentially zero cost compared to creating your own. It’s true that mC/OS isn’t the most feature-rich of products; most commercial versions will offer more capabilities with correspondingly more code and equivalent cost.

Please forgive the rant: I’m constantly astounded that we parrot the principles of software reuse when we can’t even buy something as cleanly canned as the operating system. Some 80 vendors (see the Embedded Systems Buyer’s Guide ) offer different flavors of RTOSes for virtually any CPU, with an astonishing range of footprints and costs. Until we learn to buy every component possible—just as the hardware crowd does—software engineering is going to be a very expensive, error-ridden proposition.

Most of the homebrew RTOSes I see are surprisingly compact. Generally this is because the developers have a twisted view of the essential components of an OS. Usually they’re little more than context switchers that let a handful of independent tasks run more or less concurrently. While multitasking underlies any RTOS, multitasking alone leads to real-time nightmares.

To my way of thinking, one of the most important resources an OS provides is a rich set of messaging primitives. How will task A communicate with task B? Through a global variable? We all know that because any routine can alter shared variables at will, globals tend to rapidly escalate debugging time. What’s less understood is that globals are intrinsically not reentrant; when a task that is fiddling with a global gets preempted, that value, possibly then used by another task, may be totally corrupt.

In my opinion, passing data around a real-time system in globals is akin to playing Russian roulette.

Every commercial RTOS, as well as mC/OS, provides OS-level messaging protocols that let you safely, without globals, send information between tasks, as well as synchronize activities of multiple tasks. Queues, semaphores, mailboxes, and a number of other resources are safe—reentrant and non-global—ways to pass data around a real-time system. An RTOS that gives multitasking without messaging is a toy, not a stable foundation for a product your company’s livelihood depends on.

I’d wager that in the next five years most real-time embedded systems will have some sort of RTOS as an essential part of the firmware. Given that the RTOS is becoming such a critical component it’s clear we’ll all have to master this technology—or become dinosaurs. And that’s where Labrosse’s book does the industry a true service.

Chapter 2 is a concise, readable, and complete 40-page introduction to the concepts of tasking and intertask communication. It’s worth the price of the book alone. If you have never used an RTOS, this section will give you a grasp of all of the essential ideas used. Read it once to get the basic ideas, and then again to understand how each part of an RTOS plays together, creating a synergistic tool that changes the very way we write real-time code.

Chapters 3 to 7 discuss the design of mC/OS itself, generally in the context of useful examples (like reading analog inputs using tasks and queues). Memory management—a subject also little covered in a useful way in most programming books—is stressed in an important way. Old embedded hands have learned to fear malloc() and its potential for heap fragmentation, as well as its often poor determinism. Labrosse shows an alternative that is used in his OS, as well as many commercial products.

The original mC/OS has been successfully ported to many dozens of microprocessors. In this book the author gives explicit porting directions.

If you currently do not use an RTOS, read this book to gain a deep understanding of what these powerful tools can do for your code. If you’re looking at commercial products, read the book to understand some of the trade-offs and gain an appreciation for what happens when in an OS. And if you just like to see how to write beautiful, well-documented code, check out the included disk to see how rigorously applied software standards and coding discipline can make code read like a novel. Well, almost.

The PSP
The Software Engineering Institute ( www.sei.cmu.edu) wages war on poor software practices via their seminars, conferences, on-line materials, and their Capability Maturity Model (CMM). I’ve discussed the CMM in previous articles; suffice to say that it outlines a way to move from a chaotic, ad hoc process to one that results in predictable deliveries and costs.

The CMM, though, is a bitter pill to swallow. Without total commitment from the top of the organization on down it is doomed to failure, as the practices it entails are far from easy. Going the CMM route is surely as difficult and costly as getting ISO9000 certified.

Watts Humphrey, one of the architects of the CMM, realized that too many organizations will never be able to climb the rungs of the CMM ladder, yet are crying for ways to improve their software processes. His seminal work, A Discipline for Software Engineering ² outlined what he calls the Personal Software Process (PSP), which lets us take charge of things as individuals and improve the way we generate code, on our own, with no commitment from management.

Now he’s followed that book with Introduction to the Personal Software Process . ³ Where the original book was long-winded and filled with heady statistics, Introduction is practical, down-to-earth, and filled with action plans. Introduction is the book to get if you want a step-by-step way to improve your estimation and coding skills. Humphrey claims that most engineers can achieve a 70% improvement—or better—from a “one semester” exposure to the PSP.

I presume most people reading this have left “semesters” long behind in a happily forgotten past. However, as professionals we can never stop learning new things, even if management is unsupportive of our efforts. Humprey’s original book feels, smells, and reads like a conventional college textbook; this successor is more of an “Idiot’s Guide” to the PSP, and is much more accessible.

However, nothing important ever comes easily. In my experience it takes the average engineer who pursues the PSP on his or her own about six months of steady work, a couple of evenings a week, to master the concepts. Though this could be shortened considerably by management that makes a few hours during the workweek available, finding such enlightened bosses is rare.

If your company won’t give you the time to do the PSP, go after it yourself, at night. Shut down the TV for a few hours here and there; the benefits are too great to ignore. Use Humphrey’s new book, Introduction , as it’s so much more tractable than the first.

Serial ports
If you’ve been in this industry for a good long while, perhaps earned some gray hair and an ulcer in the pursuit of embedded ones and zeroes, you probably still get mixed up about serial protocols. Is a “one” a negative or positive level in RS-232? In what order are the bits transmitted? What pin is what on a DCE vs. DTE device?

Jan Axelson (author of the also-recommended The Microcontroller Idea Book and Parallel Port Complete ) addresses all of these issues and more in his Serial Port Complete . ⁴

The book starts off with a description of the asynchronous protocol used by RS-232, and then moves on to the PC’s serial port structure. The companion disk includes complete drivers for the PC, from simple drivers to auto-detection of useful ports. The appropriate Windows 32-bit API functions are discussed, as well.

For the embedded person, though, the interesting stuff starts with an overview of 8051 and PIC serial ports, again accompanied by code. Axelson goes on to give a complete look at the characteristics and use of RS-232 for connecting two devices—including the usually ignored problem of powering a device from the RS-232 port.

If you’ve ever built systems that communicate via RS-232, you know how difficult it can be to get things working properly. Axelson goes over both the problem of communications between an embedded system and the PC, and between networks of embedded systems. In fact, he includes all of the code needed to support a seven-node network of devices communicating over a serial link. RS-485 is covered as well, even to the extent of pictures from an oscilloscope showing what signals should look like.

Axelson’s book is about as complete a reference as you’ll find on serial communications (excepting binary packetized protocols like TCP/IP). The code could save you some time; the reference material surely will.

Code inspections
In August I discussed the benefits and procedures for a formal code inspection process. The idea is to look at your code in a formal manner before testing it. The benefits are profound, as inspections tend to be 10 to 20 times more efficient at finding problems than debugging.

Since then I’ve been inundated for requests for more information on the two references in the article: Software Inspection by Tom Gilb and Dorothy Graham ⁵ and Software Inspection—An Industry Best Practice by David Wheeler, Bill Brykczynski, and Reginald Meeson. ⁶ Though a lot of other sources of information on this subject exist, these two books give a balanced view of the requirements and realities of the process.

Gilb and Graham’s book is one of the industry-standard references about inspections. It’s complete yet remains quite readable. Virtually every aspect of the inspection process is discussed clearly.

The appendices are especially useful, as they include detailed procedures of who does what and how. Forms are included, as well as suggested metrics.

The Gilb/Graham book is probably the bible of the subject and should be on every developer’s must-read list. In my opinion, though, the authors approach the subject in a manner best emulated by large development teams that have an appetite for lots of paperwork. Few embedded groups have the resources for such overhead.

And that’s where the IEEE book balances Gilb and Graham’s. Software Inspection—An Industry Best Practice is a collection of 22 papers by various authors. Some weigh in heavily in the academic-gotta-publish-regardless-of-content category; others are gems of hard-hitting how-to information. Fagan’s original 1976 paper introducing the concept is included, and despite its age, is still a model of clarity.

When inspections fail—as all too often happens for a variety of reasons—we’re tempted to abandon them in frustration rather than tuning the process. Read “How Inspections Fail,” ⁷ a paper in this collection, which gives a perspective on the subject and suggested remedies. Better, read this paper first , before your inspections fail, and take proactive action.

Throughout the book, though, the papers are rife with accounts showing quantitatively how successful inspections save money and time. Read it, if nothing else, as inspiration when you’re battling the cowboy coders who refuse to participate in any disciplined software process.

A cheap hobby
If you, too, are a lover of books, get on the mailing list of Daedalus Books. ⁸ They offer a wide range of often eclectic titles—though nothing to do with computing! Many are remaindered items, offered at astonishingly low prices.

Amazon.com, despite a string of money-losing quarters, continues to dominate the Internet book venue. Try annabooks.com as well, as they specialize in books for engineering and computer professionals, offering most titles at a discount with much better delivery terms than those from Amazon.

And always support your local used bookstore. My folks talk of a time where entire streets in New York City were devoted to the used book trade. Now most of these are gone, perhaps victims of the TV generation. In most of the used stores I frequent paperbacks go for 50 cents to a buck, a tremendously better deal than the $6.99 that’s de rigeur today. At that price, reading remains one of the cheapest—and always most fulfilling—hobbies around.

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challanges. He founded two companies specializing in embedded systems. Contact him at jack@ganssle.com.

References

1. Lawrence, KS: R&D Books, 1998.
2. New York: Addison-Wesley, 1995.
3. New York: Addison Wesley Longman, 1997.
4. Madison, WI: Lakeview Research, 1998.
5. London: TJ Press, 1993.
6. Los Alamitos, CA: IEEE Computer Society Press, 1996.
7. G. C. Shirey, p. 97.
8. P.O. Box 6000, Columbia, MD 21045-6000, or visit www.daedalus-music.com.