You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• On Systems Descriptions
• Dumbing Down Engineering Education
• Rage Against the EULA
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

John Carter's Law: "Arguably a check can be buggy and hence fire unnecessarily .  But it's far better to pinpoint the exact location of a bug, making reproduction and finding and fixing fast and deterministic, than let a sporadic unreproducible bug escape into the field."

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

In response to an article in the last Muse, Johan Kraft writes:

Kaiwan N Billimoria has a new book out named Linux Kernel Programming, and it's a heck of a volume. At 741 pages it is very comprehensive. The book is very well-written and Kaiwan makes working on the kernel crystal clear, starting with basic concepts and giving detailed examples. If you've never built the kernel he goes through the process step by step. His follow-on book Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization is about creating user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts. Kaiwan kindly sent both books for this month's giveaway.

Enter via this link.

Daniel McBrearty responds to the last issue's note on maintainability:

I agree. If you can't describe a system in clear vernacular then you shouldn't be implementing it. So often a developer will start building a project without a clear idea of where he's going. It's sort of like scratching one's head and thinking, "well let's try void main() and see what happens."

Long ago I traveled with a failed engineer-turned-marketer. We'd meet with a potential client who would start outlining a problem and before we had a good idea of what was wanted, he'd start telling all that we'd use such-and-such processor at so many MHz.

I never saw him close a sale.

His boss, who knew little about anything, consequently listened intently and let the techies back in the office come up with a proposal. He was pretty successful.

David Laurence writes:

I respect nations' sovereignty so won't comment on the UK. However, there are similar moves here in the USA which strike me as rather short-sighted. I see two basic versions of this.

The first is an attempt to teach "coding" via some abbreviated schedule. Some of that is just HTML or CSS which doesn't require much erudition.

The second is more concerning. Dumbing down the engineering curriculum by trimming math and science strikes me as a disservice to the student and to society in general. As a certified Old Fart I know that few engineering students really know what sort of work they will be doing. Some will design factory automation equipment. Others medical gear. Or smart toys. There are hundreds or thousands of embedded product domains and an engineering education simply cannot train anyone for all of these.

What schooling can do, however, is give the student a good grounding in the sciences and math that can translate into any of these areas. I hated chemistry in college but spent years designing gear that did chemical analysis of the output of a factory. Physics enabled me to build devices that interacted in predictable ways with the real world.

What about math? How often do you use calculus? For me, hardly ever, maybe once or twice a year. Or differential equations? Pretty much never. But those have been useful many times in reading - and understanding - scientific papers upon which some designs were based.

This weekend I driving, mind idle, and wondered what fraction of the sun's output hit the Earth. But, embarrassingly, I couldn't remember the formula for a sphere's area. It occurred to me it had to be the first derivative of the volume, (4/3)πr³, a trivial calculation.

An engineering education parsimonious in math and science won't prepare the student for a career of invention and understanding. Sure, you can write code like a casual chef, following detailed cookbook instructions. Only a well-educated engineer can write that cookbook.

A couple of readers have written complaining about EULAs. I wrote this a decade ago:

Maybe it was a slow news day. Tiger was in rehab. The Salahis were hiding behind the 5th. Whatever, I was installing a tool chain and actually read the license agreement, always a bad idea unless one has a strong appetite for the absurd. At 4646 words, some seven pages, riddled with lawyer-speak, it sure appears designed to induce narcolepsy.

The vendor is a great company with a marvelous product, and has provided fantastic support. And I'm a big believer in the legitimacy of copyrights. But these so-called EULAs have become outrageous.

First, the EULA is titled an "agreement." While it meets the definition of that word, it feels much more like coercion. There's no provision to modify the language in even the slightest form to fit the technical or legal needs of the customer. The "agreement" spells out all of the vendor's rights and none of the user's.

Secondly, the sheer length of said "agreement" insures few will read it before clicking the "accept" button. Of course we have a responsibility to read and understand contracts. But confronted with a blizzard of fine print every day, it's awfully hard to do so.

Then there's the provision that we, mere engineers, agree to bind the entire corporation to the terms of the EULA. Huh? That's probably not legal, certainly not likely, and is sure to get one fired if the boss finds out we're making such commitments.

The "agreement" stays in effect for an "indefinite" period in time. That word means either forever, or for a neither precise nor exact time period. That sounds like somewhere between a microsecond and eternity, so means nothing.

One is further required to keep records of the use of the software. Do you?

Finally and perhaps most importantly, the only warranty given is that the media will be defect-free. I downloaded the stuff, so even that weak guarantee is pretty lame. Would you buy an appliance whose only guarantee is that the box it is shipped in will be intact? To quote a pithy section from Software for Dependable Systems – Sufficient Evidence?,  "No software should be considered dependable if it is supplied with a disclaimer that withhold the manufacturer's commitment to provide a warranty or other remedies for software that fails to meet its dependability claims."

Many see EULAs as more motivation for the use of open source software. But proprietary tools do have an important place in this business.

A two-fer:

Scott Rosenthal sent this:

And Ed Criscuolo was in a horrific heat wave in Maine (this is the USA so all temperatures are in °F):

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

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.

These jokes are archived here.

John Carter sent this:

A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.

The car's occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

"I know," said the department manager, "Let's have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way."

"No, no," said the hardware engineer, "That will take far too long, and besides, that method has never worked before. I've got my Swiss Army knife with me, and in no time at all I can strip down the car's braking system, isolate the fault, fix it and we can be on our way."

"Well," said the software engineer, "Before we do anything, I think we should push the car back up the road and see if it happens again."

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. can take now to improve firmware quality and decrease development time.