Embedded Muse 162 Copyright 2008 TGG July 7, 2008

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. Subscribe and unsubscribe info is at the end of this email.

EDITOR: Jack Ganssle, jack@ganssle.com

- Editorís Notes
- Multicore
- Free Book on Inspections
- Jobs!
- Joke for the Week
- About The Embedded Muse

Editorís Notes

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that itís not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/classes.htm .

VaST has issued a call for technical papers for the Virtualization of Electronics Worldwide Conference 2008 (ViEWcon08), October 6-7 2008, Santa Clara Hilton in Santa Clara, California. ViEWcon08 will host two days of technology-packed sessions, allowing embedded software and hardware developers from around the world to gain valuable insight into how virtualization technology changes how electronics systems are designed. For more information, topic suggestions and requirements for submission, please visit : https://www.regonline.com.

Freescale has a nice paper about practical ways to deal with ESD and electrical fast transients. It includes both hardware and software approaches, with examples. The paper is called: Improving the Transient Immunity Performance of Microcontroller-Based Applications, and is their application note AN2764. Itís on-line at http://www.freescale.com/files/microcontrollers/doc/app_note/AN2764.pdf .

SMT drives me batty. The coffee-shakes and middle-aged myopia make me remember the DIP days fondly. Scott Rosenthal submitted this link to a surface mount soldering/desoldering 101 video: http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101 .

Testing is a perennial problem for software developers. Itís especially difficult in the embedded world. An interesting article in the June Doctor Dobbís (http://www.ddj.com/architect/207800603 ) shows how one RTOS vendor goes about doing automated tests on their products.


One canít open a technical magazine without finding a slew of articles about multicore technology. As Herb Sutter put it ďthe free lunch is overĒ; speedups from increased clock rates and other serial-programming advances just donít do much anymore in terms of performance.

The CPU vendors are addressing this by putting more CPUs on a single chip. There are a lot of approaches, but the one touted most often is symmetric multiprocessing (SMP), where multiple versions of the same CPU live on one chip. Typically they share the same memory bus, though each core has its own microscopic L1 cache.

In my opinion this is a solution to the chip vendorsí problem: though they can add more transistors, those transistors just arenít doing much thatís useful. Multicore is a market for those transistors.

As multicore processors sport more and more cores, that shared databus becomes more of a bottleneck. Thereís plenty of talk about dozens of cores, but absent an architectural change Iím skeptical that performance improvements will even approach the growth in CPUs per package.

And, we really arenít very good at parallel programming. For 30 years researchers have looked for auto-parallelizing compilers with scant success. The good news is that Microsoft and others now have well-funded programs looking for solutions.

Perhaps multicore is just another example of Leibsonís Law (http://www.edn.com/index.asp?layout=blog&blog_id=980000298 ): It takes 10 years for any disruptive technology to become pervasive in the design community.

Iím collecting data from developers about their embedded multicore experience. Have you tried it? What were the results?

Free Book on Inspections

I follow a number of companies that offer tools to embedded developers. We humans are tool builders; we engineers in particular create and use tools ranging from the physical (e.g., a wrench or logic analyzer) to the ethereal (software like compilers). Bereft of tools weíd be utterly unable to do our jobs. Just think of our helplessness when the power fails! Here at Ganssle world headquarters we stare dumbly at each other for a minute or two before going out for ice creamÖ or a drink if itís late afternoon.

Smart Bear Software (http://smartbearsoftware.com/) offers software development tools. Their $489 Code Collaborator is an intriguing program that supports lightweight code reviews. Lightweight, because the traditional code inspection advocated by Michael Fagan and Thomas Gilb doesnít fit the needs of some teams, but the benefits of inspections are so profound that even the smallest outfits must take advantage of the technique.

Now Smart Bear has a book on the subject which summarizes the results of 2500 reviews of 3.2 million lines of code at Cisco. Using Code Collaborator, which automatically generates and preserves metrics, they were able to learn a lot about lightweight reviews in a real-world scenario. Too many studies are set in academic communities using undergraduate students on toy projects.

The authors rightly point out that Fagan, Gilb, et al promote a highly formalized process that weíre not supposed to tune much. Yet a Fagan inspection simply isnít possible in a two-person shop. And sometimes itís hard to match the process of the Fagan approach to modern agile methods. Indeed, in eXtreme Programming, for better or for worse the review takes place in real-time as a pair of developers crank code sharing a single machine.

The book refers to a number of studies, some of which are relatively obscure. For instance, did you know that when reading a function developers repeatedly return to look at variable definitions? The implication is that short term memory doesnít hold a lot, so wise teams will insist that all functions fit on a single page. Then itís easy to glance up at the declarations without shuffling through paper or screens.

The Cisco study showed a tremendous variability in inspection rates for a lot of reasons. But engineers achieved the best results when inspecting at about 200 lines of code per hour or less. And after about an hour review effectiveness plummets. We get tired.

Expect to find about 15 defects per hour.

Authors who ďannotateĒ and explain the code before the review have fewer mistakes. Clear explanations to someone else, in written form, makes the author think more deeply and thus find his or her own problems before the review takes place.

Itís a very well-written 164 page book thatís a fascinating read. Even better, ďBest Kept Secrets of Peer Code Review,Ē is free! Go to http://smartbearsoftware.com/codecollab-code-review-book.php to order it. Itís a physical volume, not a PDF which is a pain to read on-screen and annoying to print. Yes, it promotes their product, but the authors wisely relegated the sales hype to the last chapter. And do read that section carefully, too. Any tool that can help improve your processes and reduce defect rates is worth investigating.


Joke for the Week

Tjark van Dijk sent this little ditty:

Melody: Let it snow

The discharges are often striking.
The bugs are really frightening.
And since there's no time to go.
Let it blow, let it blow, let it blow.