Received the March 1992 CUJ. Robert did a good job on the cover. Noticed the headline article on Real-Time Embedded Systems, so I went straight to that. As a publisher you have an obligation to show fairness to all topics, however when a writer takes the liberty that Keith Cox did in this article and your editor stays out of the article I begin to wonder about editor's understanding of that responsibility. It is a common practice for an editor to step into an article and cushion the impact of some of the less experienced writers like Keith Cox. Where was your editor when this article went to print?

I ask you to refer to the article in question on page 25, column 1, second to the last sentence in what I might add is a very poorly written paragraph. "My own experience with these systems (real-time operating systems) is that they are expensive in terms of RAM, ROM, and dollars, are impossible to troubleshoot, and that their vendors provide less than adequate techical support." There was no reason for this writer to make that statement, for a real-time kernel was not even considered for this design. He could have made his point without taking such liberty. But he did make that statement and you allowed it, so the topic is now open for discussion. Just what are the qualifications of Keith Cox? What real-time kernel vendors has he contacted to research this article? There are seven real-time kernel vendors advertised in this month's publication, which ones has he contacted? If not those vendors, then whom? And what about the damage to the quality vendors who take their product to market through your publication?

In a twist to this topic let's consider the firm NH Research, that employees Keith Cox. Did you know it is located at 16601 Hale Ave. in Irvine, CA, or at least was there during the summer of 1990. Their phone number is 714-474-3900 and their fax number is 714-474-7062. NH Research also employs David Nguyen and his boss, Tom Fairburn. (By the way, my research informs me that Mr. Nguyen and Mr. Fairburn are still employed by NH Research, which is still located on Hale Ave.) Mr. Nguyen first requested information from A.T. Barrett & Associates in August 1990 with a phone call to this firm on the 9th of August. On the 9th of September Tom Fairburn sent a fax requesting our demo. The firm uses the Microtec Compiler and has been a long term user of the PSOS operating system for sometime. However, they have no practical experience with our real-time kernel. Tom Fairburn uses his secretary to screen all his calls so he was very hard to contact.

When one considers the marriage that exists between PSOS and Microtec and it makes me wonder for whom Keith Cox is working. After several unanswered calls to this firm through November 1990 I dropped them from my active file. No one from NH Research firm has contacted A.T. Barrett & Associates since September 1990. Mr. Nguyen and Tom Fairburn did not even take the time to request an evaluation distribution diskette of RTXC, which I offered to them.

Now, I find Keith Cox, this writer taking liberties that he is not allowed to, at least not allowed to based on his experience. He and the other employees of NH Research have never questioned myself or the engineers of this firm nor have they examined our product. If all he needed was a two task kernel, we supply, as mentioned above, our evaluation diskette with all of our kernel services free of charge to anyone who requests it! For free the engineer could use this two task kernel on any Intel x86 processor.

Even if the engineer needed a little more or a different processor port, consider that our Basic Library at $995 is a field proven and well documented solution with over 20 services. I question how he could advise any engineer to spend time writing his own kernel to save money?

Certainly a very poor suggestion for time management. Let's just say for conservation's sake that an engineer was able to write and debug such a routine in a week's time. (Realize that this engineer does not have Mr. Cox's experience.) At first glance it might appear that he saved money. As far as the firm is concerned he just wasted over $1,000 and there is no guarantee that the code will even run, so where is the documentation? (The User's Manual for RTXC is almost 500 pages. The $1,000 loss is calculated by taking a conservative $50 per hour rate for one week of 40 hours.)

When I first saw the article in question I found myself wishing my ad was located where the Byte-Boss ad was. Now I am pleased to find our ad nested next to a nice listing of C source code back on page 48. A quick review of the Advertiser's Index and I find no less the seven real-time kernel vendors. However, not one of them is PSOS nor is Microtec one of the advertisers.

This article could have done so much more than it did. Engineers want to know how to get started with real-time applications, it was a wonderful opportunity to do so much. Now, this "expert" has stepped forward to lay claims that can only be interpreted by the less experienced and unknowing in a way that is going to cause them loss of time, and outlay of cash as they overlook solutions on the market, just because they read an article in the CUJ that says these solutions are "impossible to troubleshoot, and that their vendors provide less than adequate technical support."

I now challenge you to correct the error that your editor has made and additionally request in the future a closer review of a writer's qualifications be considered when such "opinions" are made.

Sincerely,

Ron Hodge
A.T. Barrett & Associates
11501 Chimney Rock
Houston, TX 77035

Mea culpa. Technical types often express opinions without regard to tact or a fuller perspective. My job is to eliminate such bald statements, or tone them down, if they don't contribute to the technical meat of an article. Where they do contribute, my job is to soften the sting with an editorial remark in square brackets. In this case, I didn't do my job.

I have already apologized to Mr. Hodge by telephone. He was gracious enough to accept the apology at face value. I now further apologize to our readers and to the other vendors of real-time operating systems. Mr. Cox is entitled to his opinions, to be sure. But it is not the business of this magazine to endorse, or even appear to endorse, all the opinions of its contributors. — pjp

Dear Mr. Ward,

I enjoyed Keith Cox's "Building an Embedded System." He left out an important issue in his discussion of the development environment — specifically, tools.

I deal with folks every day who don't seem to understand that the demands of the embedded environment are a lot different than cranking out PC-hosted C code. You need something to see what the code is doing, whether this is an emulator, remote debugger, ROM monitor, or whatever. Unfortunately, too many people wait until very late in the project before realizing this, causing no end of grief.

Many debugging strategies change when dealing with multiple interrupt and DMA sources. Further, programmers must be ready to put on their hardware hat; embedded code can never stray far from the hardware in the target system.

Sincerely,

Jack G. Ganssle
Softaid, Inc.
8300 Guilford Rd.
Columbia, MD 21046

Dear Bill,

After reading (and enjoying) your fine publication for quite some time, I feel compelled to write to you regarding a recent article by Mr. Keith Cox of Perfect Circle Computing.

In the midst of an otherwise in formative and useful article, Mr. Cox makes two statements that deserve comment. He states that a system with "only two or three tasks" doesn't require a kernel, while a system with ten or more might justify using a kernel.To imply that the fundamental nature of the problem changes somewhere between three and ten is simply wrong.

The real decision point is when you have more than one task and your system response requirements dictate task preemption. One of the most complex parts of any multitasking operating system or kernel is the task context switching logic, especially in combination with handling interrupts. This complexity arises when you cross the boundary from one to two tasks. A designer should seriously consider buying a kernel if there is a preemptive multitasking requirement.

More importantly, Mr. Cox does a disservice to your readers and an entire industry, that of commercial real-time kernels, when he states that "these systems" are "expensive," "impossible to troubleshoot, and their vendors provide less than adequate technical support." I don't have any idea of Mr. Cox's experience in this area, but I have to assume it is relatively limited. The phrase "My own experience with these systems" is not quantified. The statement Mr. Cox makes regarding his difficulties implies an industry-wide condemnation, with no facts to substantiate his opinion. An unsubstantiated blanket statement such as this does not belong in a technical article.

We at JMI can cite hundreds of satisfied customers who have designed everything from hand-held data recorders to cardiac monitors, laser printers, and civilian and military radar systems using our real-time kernel, C EXECUTIVE(R). There are many other vendors in the industry (many of whose ads appear in the very same issue) who could provide similar testimonials.

As an example of the complexities of context switching and handling interrupts for two or more tasks, I refer you to the method JMI invented to accomplish this on the Intel i960. Ms. Susan Wainer, whom you know from one of your previous incarnations, invented a method to run the i960 literally "inside out" to greatly improve its performance while executing a task switch as the result of an interrupt.

This method was invented not by the chip vendor (Intel) or by one of the multi-billion dollar aerospace giants using the i960 in military avionics programs, but by a small professional organization specializing in providing a multitasking (i.e., more than one task), real-time operating system kernel for over 20 CPU architectures.

Very truly yours,

Edward J. Rathje, Vice President
JMI Software Consultants, Inc.
P.O. Box 481
904 Sheble Lane
Spring House, PA 19477

Dear Sir,

I make extensive use of a version of the assert macro in our C code and find it is a great benefit, as it builds in a considerable amount of error trapping during development.

However, the macro has at least two distinct limitations — it is only effective when that piece of code is run, and it adds unnecessary code and data to the debug version of the program.

As many errors can — and should — be trapped at compile time, I have also used preprocessor constructs of the form

#if ((B + C) > 100)
#error A must not be greater than 100
#endif

I recently started using a construct like this

#ifdef DEBUG
#define CASSERT(exp) if (!(exp)) exit(1/(exp))
#else
#define CASSERT(exp)
#endif

Any suggestions?

Yours truly

Gary J. Raynor, General Manager
Procon Construction Systems
131 Woodland St. Balgowlah, NSW 2093
Australia

I assume your CASSERT macro is restricted to constant expressions. Otherwise, you must have a pretty smart compiler. Not all compilers will stop on the zero divide, by the way. But all are obliged to flag it for a constant expression. I don't know of a more gracious solution than yours. — pjp