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
• Serious About Security?
• Tips for Aspiring Developers
• How to Measure Good Design?
• More on Upgrading Windows
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Better Firmware Faster classes in Denmark and Minneapolis

One phrase I repeat in my firmware seminars is that a focus on fixing bugs will not lead to a quality product. This is the entire thesis of the quality movement, which revolutionized manufacturing but has somehow largely missed software engineering. This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers.

I'm holding public versions of this seminar in two cities in Denmark - Roskilde (near Copenhagen) and Aarhus October 24 and 26. More details here.

I'm also holding a public version of the class in partnership with Microchip Technology in Minneapolis October 17. More info is here.

"'Everything takes a week' was the mantra of a seasoned engineer friend of mine. At first we didn't believe it, but when you factor in all the details that need to get done to get a change into production, even the smallest tweak takes a week." - Source unknown

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

Chris Hemingway submitted this:

I've had one of Digilent's Analog Discovery USB oscilloscopes around here for some time and will be giving it to a lucky winner at the end of October. It's a nice unit - 5 MHz, two analog channels, 16 digital, and a pair of waveform generators. Note: The little black Analog Discovery is this month's giveaway, not the Agilent scope in the background! (I reviewed the Analog Discovery here).

Enter via this link.

Last month I attended the Cybersecurity Summit in Farmville, VA at Longwood University. The dean of the business school is a friend; he invited my wife and me to the Summit and a reception afterwards.

Longwood, founded in 1839, is a small school in a very pretty town. The first vice-presidential debate of this agonizing campaign season will be held there tomorrow, October 4th. Dean Barrett was brought in some years ago to jazz up the college and to bring in some new thinking. He founded one of the first cybersecurity programs in the country, which was a natural fit for the Summit.

The panel had some heavy-hitters, including retired General James Cartwright, formerly the number two person in the army. The moderator, Roben Farzad of NPR was witty and asked some great questions. Participants stressed the importance of security, issues with passwords, privacy and more. They touched on the IoT though didn't delve deeply into that subject which is so near and dear to our embedded hearts. Plenty was said about how important security will be to the massively connected world that's coming.

But one point was not addressed, and I wonder if it's something only practitioners grok. Security has no value, especially in the embedded space. Everyone wants it, of course. But no one – to a first approximation – is willing to pay for it.

How many extra months is your boss willing to add to the schedule to ensure the product can't be hacked? I bet the number is exactly zero. Does he simply assume the team will build a robust product that's safe in the awful threat environment that exists today, and that will get much worse in the future?

Does your boss even know what the Common Criteria is? Is the phrase "evaluation assurance level" foreign to your team's work?

Today you can buy connected toothbrushes that monitor your brushing habits (next year: one that videos your mouth), and I've even seen a smart Bluetooth spoon that counts how much food gets shoveled into a customer's mouth. These are potential attack surfaces and vectors. We all know about the vast number of automotive hacks, and even pacemakers have been compromised (though in artificial lab environments… for now).

When everything is connected, everything is at risk of compromise.

It's not unreasonable to think that no one would have the slightest interest in hacking your niche product, and indeed security through the sheer banality of a smart device might be effective. Who is going to figure out how to break into that MSP430, anyway?

But many products do use common software platforms. The worst thing a team could do is write their own TCP/IP stack; instead it makes much more sense to use a COTS or FOSS solution. But when everyone uses a relatively small set of common platforms the attack surface gets much broader. While the recent proliferation of Cortex-M MCUs very cool, a common instruction set running common platforms opens the door to the Bad Guys.

Then there are patches. One of my oscilloscopes runs Windows. It has never had a software upgrade, though Microsoft has released innumerable security fixes over the years it has graced my lab bench. (For a variety of reasons I never put it on the network.) Linux, too, changes quickly. The truth is, though, that most embedded systems never get upgrades. The sheer nuisance of doing them would infuriate our customers. We tolerate these on our PCs, but just barely.

I know of an embedded device running Windows that automatically did an OS upgrade – over a satellite link. The data charge was tens of thousands of dollars.

Even with the best intentions and funding, managing security updates is a daunting prospect for many embedded products.

Unfortunately, I've come to the conclusion that when it comes to embedded devices, most talk about security is simply BS – there's no polite way to put it. Yes, pundits gush lots of words and digital ink, but until the boss is willing to pay for it security will be mostly hot air.

There have been plenty of high-profile attacks on and through embedded systems, like Target's POS terminals. Or the Akamai DDoS attack which is thought to have come from a million or so IoT devices. Or the recent OVH attack, also from IoT units.

Unfortunately, it seems security is valuable only after a breech.

How much does your team spend on making your products secure?

Reader Michael James asks:

I'd say:

• Study widely
• Think hard about the problem before writing code.
• Think hard about what you're doing while writing the code.
• Think hard about what you just wrote before testing.
• Have your mentor review that code before testing.

Some writers call the last point "baby killing." Great novelists subject their work to review by editors, friends and associates and accept the fact that their "baby" - the prose - may need to be greatly revised and even completely rewritten. Code may need the same treatment before it becomes Great Code.

What would you recommend to an aspiring developer?

In the last issue Charles Manning posed a question for the readership: How can one measure, hopefully quantitatively, whether a software design is good or not?

Jack Bombeeck wrote:

Steohen Bernhoeft had a nice short list:

Paul Bennett wrote:

Paul Carpenter makes a good point about copied code:

David Trierweiler had a final comment on upgrading Windows:

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.

Remember the old FDIV bug in the Pentium? Here are the top ten slogans for the part:

9.9999973251   It's a FLAW, not a Bug
8.9999163362   It's Close Enough
7.9999414610   Nearly 300 Correct Opcodes
6.9999831538   You Don't Need to Know What's Inside
5.9999835137   Redefining the PC -- and Mathematics As Well
4.9999999021   We Fixed It, Really
3.9998245917   Division Considered Harmful
2.9991523619   Why Do You Think They Call It *Floating* Point?
1.9999103517   We're Looking for a Few Good Flaws
0.9999999998   Errata Inside

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.