Go here to sign up for The Embedded Muse.

Embedded Muse 221 Copyright 2012 TGG March 6, 2012

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

The latest issue of Crosstalk Magazine (http://www.crosstalkonline.org/storage/issue-archives/2012/201201/201201-0-Issue.pdf) has an article (High Maturity Pays Off - It is Hard to Believe Unless You Do It) about how adopting better software engineering practices makes companies more money. It describes how one outfit went from years of losses to consistent profits - and happier customers - entirely as a result of improving their software processes. Most interesting is that each of their gradual improvements immediately netted tangible results to the bottom line.

But why would anyone be surprised? The quality movement's central observation is that building in quality inevitably results in lower costs. That's the focus on my Better Firmware Faster course. It IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how to have this class at your facility. See https://www.ganssle.com/onsite.htm .

Quotes and Thoughts

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

Response to Quotes

Last week's Quotes and Thoughts prompted James Grenning to write: "I'm in agreement with Robert Glass when he says `100% test coverage is insufficient. 35% of the faults are missing logic paths.' If you have an automated unit test suite, low code coverage is an indication that you need more tests. Unfortunately, high code coverage does not tell you if you have enough tests or the right tests. Adding to Robert Glass' observation, executed code is not necessarily tested code. Imagine a test case that runs through many lines of code, but never checks that they are doing the right thing. At best this is the `I don't have any bad pointers' test.

"Here is Gerard Meszaros' Four Phase Test Pattern:
1) Setup preconditions
2) Exercise the code under test
3) Check the desired behavior
4) Restore the system to its original state

"You can get 100% test coverage (executing every line of code) and never do step 3. The code is initialized and exercised, but we are not sure if it is correct. Low test coverage is telling, while high test coverage can be meaningless. Here is an example test case:

{
// init for scenario A

result = MyComplexOperation(a,b,c,d);

CHECK(result == TRUE);
}

TEST(MyComplexThing, ScenarioB)
{
// init for scenario B

result = MyComplexOperation(a,b,c,d);

CHECK(result == TRUE);
}

TEST(MyComplexThing, ScenarioC)
{
// init for scenario C

result = MyComplexOperation(a,b,c,d);

CHECK(result == FALSE);
}

"If MyComplexOperation() operation has a cyclomatic complexity of 3, I should be able to test it with three test cases, one for each execution scenario. If all MyComplexOperation() does is return a result, this is adequate. If it interacts with some other part of the system, it is not adequate. There are no checks to see if it did the right thing.

"Metrics are important, and it is equally important to understand what they do and do not tell us."

For the Want of a WDT

A few years ago Ed VanderPloeg wrote to describe how he had to reboot his oven's hood fan, which seemed a low in the state of the art of embedded design. This week Marion Moon contributed this: "[My tenant was having trouble with her air conditioning.] She called and said that she couldn't stop or raise the temperature -- she said it was like a meat locker.

"When I got to her house, I couldn't see why the thermostat wasn't working. I could have simply pulled the plug on the air handler but wanted to see what might be wrong. I thought the t-stat was a conventional White-Rogers or old-style Honeywell. After a bit, I thought that the newer one might have a processor in it so, I pulled the plug and left the unit off for several seconds. When I plugged the AC in again, it started working ok. I was surprised that such a simple t-stat had a processor in it as it didn't have nor need soft start or other functional operations.

"The manual was silent on the topic. If I did not have the background on embedded apps, I nor others would not have been able to do this. I don't know how many people deal with these situations. Even the HVAC techs I use can't deal with these cases. There is no excuse for this in my opinion."

A software bug? Perhaps. Or maybe a brown-out corrupted logic states. But it's possible that the design was perfect, and a cosmic ray zapped a bit. These high-energy particles can flip random bits in ICs. Just imagine the implications if a CPU's program counter suddenly changes.

Intel's Ivy Bridge processor, whose launch was recently delayed till June, is built with 22 nm technology, which Intel claims stacks 100 million transistors in an area the size of a head of a pin (http://download.intel.com/newsroom/kits/22nm/pdfs/22nm_Fun_Facts.pdf). At this process node it doesn't take much energy to flip bits. A 2001 article, back when parts were made with design rules in the hundreds of nanometers, claims just 10 femtocoulombs was enough energy to toggle an SRAM cell. A femtocoulomb is the charge carried by about 6,000 electrons.

In one Intel patent (number 7,309,866) the company claims that a cosmic ray-produced alpha particle can travel up to 100 microns through a chunk of silicon. At the 22 nm node that big of ugliness passes through an awful lot of transistors.

Another study (http://www.rcnp.osaka-u.ac.jp/~annurep/2001/genkou/sec3/kobayashi.pdf) claims the soft error rate is three times higher in 180 nm SRAMs than in those at 250 nm. I haven't been able to find data about the much smaller nodes now common. But many FPGAs today contain ECC logic specifically designed to correct for cosmic-ray induced errors.

A 2008 paper (Single Event Upset: An Embedded Tutorial
Fan Wang and Vishwani D. Agrawal) showed that a modern SRAM can expect 1000 failures in time (FIT) per Mbit. FIT refers to the number of failures in a billion hours of operation. That suggests a 1 GB SRAM can expect a bit flip about every four days. In the real world many of those won't matter, so systems will likely experience a lower failure rate.

Intel's 22 nm parts won't turn up in many embedded applications, so do we need to worry? In a word, yes. TI's latest OMAP part is made in 28 nm, and TSMC has already taped out 20 nm Cortex parts.

As recently discussed in the Muse, careful engineering requires we be pessimists and include extra margin in our designs. The margin is there to deal with the unexpected. A watchdog timer (see https://www.ganssle.com/watchdogs.htm for lots more about this) is a last line of defense against unexpected problems, and is a must-use for a lot of systems. Alas, I see plenty of systems that have the WDT hardware idled for lack of a bit of code.

Magazines - To Read Them or Trash Them?

At this particular instant there are six unread technical magazines on my desk. That number will probably change by the end of the day as the FIFO grows and shrinks.

I get about 20 tech magazines a month, and page through each one. Some are constants in size and scope, like Communications of the ACM and IEEE Computer. Others are shrunken versions of their former selves: EETimes, EDN and ESD come to mind, their page count hugely diminished as advertising dollars were all diverted to the web. I find this change both sad and frustrating. While the `net is wonderful, Google will never replace the serendipity of the "push" technology of a print magazine. You never know what you'll learn while paging through a printed magazine, while a search engine is just an obedient servant that merely responds to a specific question.

But it is time consuming to dig through so many publications. I do feel that we engineers have a responsibility to keep up with the latest developments, so that time investment is just part of being professionals. The university is merely the start of our education, and we cannot afford to stagnate.

Yet in recent months I've heard from many engineers that they haven't the time, or in some cases the interest, to keep up with the flood of information. Specifically, many have said they just don't read technical magazines. A survey I did a while back suggested that the average embedded person reads just one tech magazine a month.

What do you think? Is print worth the paper it is on? Which magazines do you read? How many a month? Is the `net your primary source of information?

Tools and Tips

Nigel Orr wrote: "Jack, in all the discussion about tools, I've not seen any mention of the Stripmaster wire strippers. After using them in a previous workplace, I found a pair for not much on eBay, they are indispensable, particularly for stripping insulation from fragile conductors or when you can't afford to nick cores. http://www.idealindustries.co.uk/products/wire_processing/hand_tools/ has details. They are expensive new (when you can get very cheap wire strippers), but very well put together, and a worthwhile investment to speed up development."

Jon Titus sent this: "On the discussion of USB tools: Texas Instruments has a nice IEEE 802.15.4 wireless-packet sniffer plug-in module, CC2531EMK that costs about $60. When combined with TI's free packet-sniffer software it gives people a way to look at packet communications in the 2.4 GHz ISM band. Engineers and programmers can use other TI wireless boards and modules, but the CC2531EMK comes with the sniffer firmware already loaded. The "SmartRF Packet Sniffer User Manual," SWRU187F, incorrectly notes that users must load this software via a TI CC Debugger pod. People do not need this debugger. I recently used the TI sniffer to monitor communications between 802.15.4 radios on my lab bench and left the sniffer running overnight. It picked up communications on nearby personal-area networks, but I have no idea which neighbors have PAN- or ZigBee-enabled devices."

Joke for the Week

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Phil Matthews had a follow-on to the joke in the last issue:

An important conference was being attended an Engineer, a Physicist and a Mathematician. After the conference they retired to their hotel where, late in the evening, a fire broke out. The Engineer rushed out of his room and tried to put out the fire with the nearest fire extinguisher. But the fire was too big, so he banged on the next door and woke the Physicist. The Physicist assessed the fire, estimated thermal energy production and did a quick mental calculation of the rate the fire would spread factoring in the properties of the surrounding materials. After a few equations he came up with an answer, "We have enough time to get everyone out!". So they both ran down the corridor and banged on the next door. A bleary eyed mathematician appeared looking distracted. When the Engineer and Mathematician told him about the fire he held up his hand and felt the heat and said, "It exists" and went back to bed.

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.

Embedded Muse 221 Copyright 2012 TGG March 6, 2012

Contents:

Editor's Notes

Quotes and Thoughts

Response to Quotes

For the Want of a WDT

Magazines - To Read Them or Trash Them?

Tools and Tips

Joke for the Week

About The Embedded Muse