You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Segger's IP Over USB
• Ugly Words
• On Exception Handlers
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Do you have any sense of your requirements needs and their completeness? The table above (derived from The Economics of Software Quality, by Capers Jones) is his empirical results from thousands of software projects.

As engineers we should be guided by hard numbers, both in working out formulas, and in guiding firmware development. My seminar, Better Firmware Faster, is packed full of numbers that should guide our processes, like the cost of firmware, aspects of scheduling, bug rates, and lots more. Sure, software engineering is a very new discipline and we have lots to learn. But there's lots we do know, plenty of data on which processes and approaches work. Are you happy with your team's results? Are you anxious to learn new ways to get better code to market in less time? Bring my one-day class to your facility to learn how to ground your firmware efforts in hard, quantifiable, numbers.

The satisfactions of manifesting oneself concretely in the world through manual competence have been known to make a man quiet and easy. They seem to relieve him of the felt need to offer chattering interpretations of himself to vindicate his worth. He can simply point: the building stands, the car now runs, the lights are on. Boasting is what a boy does, who has no real effect in the world. But craftsmanship must reckon with the infallible judgment of reality, where one's failures or shortcomings cannot be interpreted away. (Emphasis added) From Shop Class as Soulcraft by Matthew Crawford.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Gene Glick recommended Everything, a free file searching routine for Windows. The program builds an index for all files on your computer. Indexing took about 5 seconds for the 800,000 files on my machine. Searches then take no time. It supports boolean operators in search terms and a host of searching options, like narrowing the search by date, size, etc. It searches for file names; though it can also search files for specific content, that is rather slow.

I'd like to find a search engine that builds an index of the contents of files for ultra-fast searching. Google Desktop did that, but is now unsupported. I tried Docfetcher; there's a lot to like about it except that it often - very often - inexplicably hangs.

Though not really an embedded CPU, in the holy cow, what's next, category, Intel has announced their Core i9-7980XE processor, an 18 core beast with a TDP of 165 watts! That's a lot of power. There are a number of power supplies required, but the max amps for one is spec'd at 190A. All that to a square cm or so of silicon, in a 2066 pin package. I wonder how many pins are dedicated to power and ground? And, of course, the overclockers have cooled it with liquid nitrogen and run it at over 6 GHz, where it draws 1000 watts. $2000 per chip.

The October issue of the Communications of the ACM will have an article by Roderick Chapman, Neil White, and Jim Woodcock titled What Can Agile Methods Bring to High-Integrity Software Development? Rod sent me a pre-print copy. It does a nice job adressing some of the problems of integrating agile approaches into embedded work. For instance, how does one test when the hardware isn't available? The authors write that simulation was used, with the expectation that final hardware integration would pass all tests the first time. Not mentioned are full-system simulators like Simics. The paper discusses how some agile approaches had to be modified. For instance, due to security reasons the system had to be in a bank vault, which might have been hard to refactor in late in development! This is a worthwhile read.

Win an Aneg AN8001 true-RMS 6000 count digital multimeter. It's not particularly fancy, but the price is right for one lucky Muse reader.

Segger's new emUSB-Device-IP is a software stack that lets an embedded product communicate over a USB link using IP. When I looked at the product I thought "why would anyone want this?" But Segger's web page describes scenarios that make a lot of sense. For instance, suppose you made a Bluetooth headphone that the user charges via a USB connection. The device might have a lot of modes (e.g., a volume limiter). The user could pair it with, say, a cell phone. You'd write apps to control the headphones. But that means actually writing those apps, for Android, iOS, and perhaps others, and then maintain them as the mobile device vendors issue new versions of their operating systems.

Or consider a printer. Even a simple model is likely to have a couple of line LCD display. You could dispense with the display and handle the printer via a web browser, cutting component costs and facilitating a better user experience.

With emUSB-Device-IP you'd embed a small web server in the headphones and then the user could manage the device via any web browser via the same USB link that charges the battery. You get a solution that is completely independent of OS, with no need to build and maintain apps. (Of course, Segger also sells a web server.)

Segger's description of the product is here.

They sent me their emPower board running a demo of emUSB-Device-IP. The emPower board's web server dished up ten different web pages which showed how the emUSB-Device-IP software can interact with a user. Though the web pages are pretty bare-bones (and could use some narrative explaining things in a bit more detail), a typical interaction was to use check-boxes to turn LEDs on the board on and off.

But what didn't happen in the demo was the most instructive. I opened the emPower box, plugged the board into my PC, went to usb.local in my browser, and was immediately communicating with the board. No drivers. No configuration. Just plug and go. That's the user experience customers want.

A user manual is available here. It's very complete, but could use the deft touch of an English major. (With all of the talk of automation replacing jobs, and liberal arts majors handing out hamburgers, perhaps our tech economy will create a demand for native-language speakers to clean up our techie ramblings.)

emUSB-Device-IP requires an RTOS (any; not limited to Segger's embOS), their "emUSB-Device BASE + driver", and their embOS/IP. That consumes, not including the RTOS, about 70 KB of flash and 35KB of RAM.

The pricing model is a bit complicated. It appears to me that to get the various goodies you should figure on the price of a used Toyota.

This is an interesting product, and I think there are many products that could benefit from it.

What's the ugliest word in the English language?

Well, there are a lot of them, but when it comes to software, "programmer" may get the nod. Or worse, today "coder" seems to be the rage.

"Programmer" denotes someone who writes code; "coder" suggests some kid hunched over a computer in his bedroom, typing furiously, maybe eventually getting something to work. More or less.

When creating firmware, we're software engineers. We build software-intensive systems using a variety of techniques. Buying components. Porting OSS code. We're designing a system, creating or managing requirements. Producing documentation. And, yes, there's generally a non-trivial amount of coding involved.

The average person is understandably confused about this profession, and we've contributed to that confusion. Some of us are EEs who create firmware full- or part-time. Others have computer science degrees and have business cards with that name. Yet non-researchers practice very little science. Computer engineer is probably a pretty good description, one that many schools have a program for. And computer engineer more fully describes what many embedded people do when they're involved in both hardware and software design. I've always disliked the moniker "electrical engineer" as that doesn't encompass our work. Do we design power plants and motors? "Electronic engineer" is better but hardly rolls of the tongue.

But "programmer" and (worse) "coder" diminish our roles. We're engineers. We use the teachings of science, and of sometimes bitter experience, to create products that are new to the world.

A moderately-interesting paper makes a couple of startling claims:

• 92% of catastrophic (complete system) failures are due to incorrect handling of non-fatal errors.
• In 58% of these catastrophic failures, the problems could have been found through simple testing of error-handling code.
• In 35% of these catastrophic failures, the error-handling code problems fall into one of three categories:
  • The error handler is simply empty or only contains logging code.
  • The error handler aborts instead of taking some reasonable action.
  • The error handler contains expressions like "FIXME" or "TODO".
• In another 23% of the catastrophic failures, the error handling logic of a non-fatal error was so wrong that any statement coverage testing or more careful code reviews would have caught the bugs.

Now, this paper is about networks, not embedded systems, so take the data with a grain of salt. However, in my experience firmware mirrors, through a glass darkly, these results. The general takeaway is that error handlers are prone to bugs, and rather simple efforts could mitigate most of these defects.

A footnote in the paper is disturbing, in that we as a software engineering community have no shared language for describing faults and the like. The authors are forced to define fault, error, and failure for the context of the paper. It's striking that there is no generally accepted definition of these terms.

One of my sayings is "Exception handlers are exceptionally difficult to get right."

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

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

More on that very old division problem the Pentium once had:

Q: How many Pentium designers does it take to screw in a light bulb?

A: 1.99904274017.

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. 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.