Stop Reinventing the Wheel

Every embedded project that I've worked on has involved the creation of some type of error logging system. They've all varied in conception, design, and implementation. Some have been very elaborate. None of them were completed before other (sometimes large) portions of the rest of the system had been written; this mean that these parts of the system had to be reworked to integrate with the error logging system. Even worse, some subsystems had created their own error message systems -- sometimes with elaborate filtering capabilities, and never compatible with the design of the main logging system.

Features that are commonly built into a logging system include:

• logging
• error message storage
• error message severity
• error message types
• filtering based on severity, type, or source
• output to a remote source (e.g. syslog)

Some systems are even designed so that it is simple to extract the text of the messages and replace it with a translation for easier internationalization.

In an effort to solve some of these problems -- in short to provide a better logging interface than is provided with vxWorks -- I've created a new logging module: "elogLib". (The "e" is for enhanced. Yes I know -- not very original, but at least you know what it is supposed to do.)

This module is a drop-in replacement for the standard logLib, and it is backwards compatible. All of the old interfaces have been retained and 99% of the behavior is exactly the same. The improvement comes from the addition of a filtering module (logFilterLib) that works with elogLib. Using logFilterLib allows you to filter log messages by task, severity level, or both. A new variant of the logMsg function is provided so that error messages may be assigned a severity level.

 At the start of a new project, this will allow the entire team to use a single interface for message filtering so that you don't have to later attempt to integrate several distinct flavors of filtering or logging. When integrated during the development of a project, it allows you to retain the behavior of existing calls to logMsg while gaining the filtering capabilities of elogLib for new code that is added. Finally, by integrating elogLib during the maintenance phase of a project,  it is possible to instrument portions of code being debugged in a piecemeal fashion while leaving other code undisturbed.

One of the design goals for elogLib was that there should be no need to change any existing code. In fact, it isn't even necessary to recompile existing code -- none of the interfaces have changed and elogLib conforms to the declarations in logLib.h. Installation is a matter of removing logLib.o from your archive and adding elogLib.o to the archive. You won't even notice any changes unless you also install and use logFilterLib.

(This last part isn't completely accurate. Above, I was careful to say that 99% of the behavior is exactly the same. The one behavior that isn't mimicked by elogLib is the "NN messages from interrupt level lost" that comes from tExcTask if an ISR overflows the log message queue. The number of messages lost is instead available by querying a global variable exported by elogLib.)

The whole package is available in binary form for the SIMNT and PowerPC targets for $500 (royalty free). Binaries for other targets may also be available. Source drops are negotiable. You shouldn't really need support; I'd be willing to negotiate a support contract, but I think it would be dishonest (see my bug fix policy). At any rate, if you have to contact me for help you can take solace in the fact that you'll be talking directly to the guy that wrote the software instead of a "customer care representative" at a call center. I love feedback and I'm always eager to incorporate suggestions from users into the product. To get elogLib, email me (brian(at)bstpierre.org, or click the little envelope in the margin of the page).

© Copyright 2002 Brian St. Pierre. Last update: 7/15/2002; 3:51:57 PM.