Tweet Follow @jack_ganssle

Embedded Muse 132 Copyright 2006 TGG August 17, 2006


You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

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


I wonít present my public seminar ďBetter Firmware FasterĒ till November or so. Locations and dates will be set soon. Meanwhile I can do the class at your facility, for your engineers. See http://www.ganssle.com/classes.htm .


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


Many thanks to the 659 of you who completed the survey. Dinesh Kumar was the lucky winner of the iPod.

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 CPU sizes included in your *current* embedded project, where ĎCPU sizeí is defined as the register width.
0% 4-bit
42.3% 8-bit
4.5% 12/14-bit
36.3% 16-bit
1.5% 24-bit
64.5% 32-bit
3.4% 64-bit

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


Frank Jacobsen wrote about one problem that caused real headaches for him:

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


Rainer Ogger submitted: I would like to propose PSPAD, see www.pspad.com. That one has a quite small footprint, is fast and great as an universal editor. Some of the features: templates/highlighting for several programming languages, hex editor, good search facilities, code explorer, etc.


Jobs!


Joke for the Week


The software development cycle:

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.