Embedded Muse 162 Copyright 2008 TGG July 7, 2008

EDITOR: Jack Ganssle, jack@ganssle.com

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

Editor’s Notes

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.

Multicore

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

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.

Jobs!

Joke for the Week

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.