Embedded Muse 132 Copyright 2006 TGG August 17, 2006

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Survey Results
- Failure Story
- Tools
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editor’s Notes

Numerous readers submitted
http://www.youtube.com/watch?v=2Y_Jp6PxsSQ in response to my comments on the Show Myth in the last issue of the Muse. It’s pretty funny.

The Embedded Systems Conference will be in Boston September 25-28. It’s always an interesting and fun event. I’m giving three talks. Some 150 exhibitors will be showing off their latest offerings. I’ll be wandering the show floor; stop me and say “hello.”

Design by Contract is a fascinating programming technique pioneered by Bertrand Meyer. Though it has little mind-share in embedded systems, plenty of firmware could benefit from the concept. I’d appreciate any stories from those of you who have used or even considered using the approach.

Survey results

The problem with surveys, of course, is that they tend to be quite unscientific. Some respondents make mistakes or manipulate the answers in funny ways. So I was greatly amused to find that 3 of us use polymorphism on 8 bit machines, and 14 run Linux on 8 or 16 bitters. Windows seems more popular on small machines, with 19 indicating they run XP or some variant on 8/16 bitters!

But all in all the responses were quite interesting. One question asked how much one can spend on tools or an RTOS without prior approval. The mean was $1447, but the mode, very surprisingly, was a stunning $0! In fact 70% reported zero dollars, and only 21% could spend over $1000.

Another query wondered how many new firmware designs readers personally are involved with in a typical year. The average is 2.2 with a mode of 2 and standard deviation of 2.1. 68% reported one or less.

How long do you spend on a project? The numbers were all over the map, with one wag saying “so long I can’t remember!” But the mean is 13 months, and a median of 12 and standard deviation of 10.8 months. The longest project took 84 months – 7 dreary years.

The RTOS question, whose results are below, elicited some interesting results. 35% of us still use an in-house RTOS while 29% use none. I think the latter reflects the wide range of embedded apps. Though some zealots believe in stuffing an operating system into even an electronic greeting card, it’s just one of many useful tools. Though only 24% reported embedding Linux, that number swells to 33% of 32 bit developers.

Here are more results. Note that multiple responses were allowed on some questions so totals may exceed 100%.

Please select all of the types of products you have personally helped design in the last 12 months.
22.8% Consumer electronics
9.1% Office/business automation
11.3% Automotive
16.4% Military/aerospace
11.4% Medical
24.5% Telecom/datacom
27.8% Industrial automation
19.4% Other (please specify)

Please select all of the features of object-oriented programming (OOP) that you are personally using on your *current* embedded programming project.
34.7% Encapsulation
22.2% Inheritance
14.5% Polymorphism
63.7% None of the above

How much experience do you have with these aspects of the graphical Unified Modeling Language (UML)?
Class diagrams
47% I know little or nothing
29% I’m familiar with the notation
20% I’ve used the notation in a design document
4% I’ve auto-generated code

Statecharts
37% I know little or nothing
28% I’m familiar with the notation
28% I’ve used the notation in a design document
7% I’ve auto-generated code

Sequence diagrams
44% I know little or nothing
24% I’m familiar with the notation
29% I’ve used the notation in a design document
3% I’ve auto-generated code

Please select all of the operating systems embedded in a product you worked on in the last 12 months.
29.3% None
35.2% In-House
3.7% eCOS
1.9% Integrity
23.5% Linux
0.6% LynxOS
6% Nucleus
1.9% QNX
2.3% RTX
4% ThreadX
5.6% TI DSP/BIOS
10.5% uC/OS-II
15.1% VxWorks
10.6% Windows (CE/XPE/Other)
19.1% Other

How much decision authority do you have to buy tools such as compilers, debuggers, and operating systems?
4.6% None
60.3% I am just one participant in decisions like these
16.7% It’s entirely my decision what tools to buy
15.6% I have the final say, but seek input from others
2.8% Other

Where is the engineering team (hardware and software) for your *current* project physically located?
10.5% It’s just me!
52.5% We’re all in the same office/complex
10.1% We’re distributed throughout the U.S.
4.3% We’re distributed throughout another country
19% We’re distributed around the world
3.6% Other

Are you a consultant to multiple companies
18.4% Yes
81.6% No

Failure Story

I was one of the last remaining programmers on a PC/Windows v. 2.11 (!) based system, used to survey and parametize an automatic heating and ventilation system.

The system was reported to lock up sometimes, so I was sent to the site, to investigate. I installed new software with special debugging output, I replaced the PC, etc. I could not reproduce the problem.

So after 2 days in the janitor's office (he was quite nice about it, and a nice person himself), I gave up. I reassembled the system, including a cable for a serial connection to a PC in the next office, used to transfer measurement data for off-line analysis of the energy comsumption of the system.

At the exact moment I inserted the cable, the system locked up! The cable had not been connected during all the time I was looking for the problem.

That gave me a lead to where the problem could be. And sure enough, there was an error in the communication section. A 5 second time-out was implemented, to be able to abort on erroneous or spurious input.

This was implemented as a busy wait loop, checking on the second value of the real-time clock. And only that! So if the time out period started during the last 5 seconds of a minute (values 55 to 59), and no input ever came, it would sit in the loop forever, since the second value will never reach 60 or higher. And since Windows 2.11 is non-preemptive, the system would lock up.

The funny thing is, I had a 1 of out 12 chance to have seen this - since this time-out calculation worked OK for second values 0-54.

The lock up usually happened in the morning, probably when the person in the neighbouring office arrived and turned on the PC, making spurious noise on the serial communication port, which would be mistaken as the arrival of a character. Since it was in the next office, the coincidence was never noticed.

Tools

Jobs!

Joke for the Week

1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
5. Repeat steps 3 and 4 three times.
6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
7. Users find 137 new bugs.
8. Original programmer, having cashed his royalty check, is nowhere to be found.
9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
13. Programmer produces code he believes is bug-free.