Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 415, February 1, 2021
Copyright 2021 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

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

SEGGER Embedded Studio cross platform IDE

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.

Quotes and Thoughts

If there is a 50-50 chance that something can go wrong, then 9 times out of 10 it will. Paul Harvey

Tools and Tips

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

Freebies and Discounts

February's giveaway is a nice little DMM.

Enter via this link.

Musing on Engineering

Reader Geoff had some interesting thoughts:

I've been a reader of the Embedded Muse for a couple years now - despite not being an embedded developer. I am amazed how similar the issues in embedded systems are to those in computer games/simulations!

Anyway I am currently taking a break from engineering and I have discovered that there are things other industries know that perhaps engineering could benefit from. Maybe these are known in bigger companies, but as a junior software developer in a small company, they were new to me.

If you are rushing the planning has failed.
My current work is in the conservation sector. We deploy pest traps to catch invasive animals, roam around forests removing pest plants, and monitor native bird populations. A lot of the time the work site is far enough away from civilisation that people are out of cellphone reception - sometimes for days at a time. As you may expect it is moderately hazardous work and the remoteness increases the risk. Because of this, a prominent company put together an incident database (aka bug tracker) and gradually mitigated injuries involving chainsaws, poisons, and people getting lost. Now their two major hazards are driving and people slipping/tripping. Some bright spark then realised that these are symptoms of an underlying cause: rushing. Driving is more of a hazard the more of a rush a person is in, and a person running is more likely to fall over. As a result this company promotes the idea: "Don't rush, if you are rushing the planning has failed."
A lot of effort in engineering goes into fixing software bugs, but the easiest way to fix a bug is not to have it in the first place. I wonder what percentage of bugs would be "fixed" by the philosophy of "don't rush" or how much better software would be if developers had less stress. Let's face it, you'd rather fly in a spaceship designed by a relaxed engineer than a rushing stressed one!

Is a bug on a developers machine a "near miss"?
Because incidents are physical injuries rather than failing software, this same company has decided: every person has the right to go home injury free at the end of the day. For this to happen the company has realised that: "The only acceptable target is zero injuries", and they try to get as much information about possible incidents as they can. It's very easy to go "bugs will happen" and try fix them when they do, but does anyone aim for zero bugs right from the developers chair? How different would it look if software engineers decided that any bug, even in versions local to their machine (that got fixed before review) was unacceptable? You'd have to be very sure of what you were doing before you typed a line of code.

Where does a bug become unacceptable? Clearly a bug in a product is a problem, and a bug in the mainline VCS is also an issue, but bugs on your local machine are considered OK. I guess bugs stop being acceptable somewhere just before code review time? Are bugs a manifestation of a misunderstanding? Could we try to tackle bugs while they are in developers heads rather than when they reach a computer? After all, a bug caught at code review is a near miss to having a bug in your product.

Iterate on science rather than on engineering
One of my side hobbies is 3D printing, and some issues encountered in software development are evident in the hobbyist 3D printing area. With 3D printing, it's easy to alter, share and manufacture new parts, so the simplest way to do things is to "iterate lots" - print out dozens of parts and progressively debug the physical part until a working solution is reached. Is this engineering or is it hacking?

Iteration of a part is needed when research is coupled with development. Engineering occurs when there is adequate scientific understanding before design work begins. Prototypes are used to validate a concept, not to design it.
If the shipbuilding industry can build ocean liners without iterating on multi-thousand-tonne-hulls, could software engineers produce production quality code without iterating? If you view a software developer as a guy with a welder, current development seems to involves a lot of hacksaw work. How many lines of code survive from first commit all the way to product release? 

Follow-up to Microprocessor History Articles

Muses 413 and 414 had articles detailing the history of the microprocessor. In response, Steve Taylor sent this picture of "one of the only known transistor PDP8 in existence".

The only transistorized PDP-8

This is at the Large Scale System Museum in New Kensington, PA. Others have recommended it in the past. It's one of the places I'd hope to visit once the pandemic disappears. Maybe in the dim dark vaccinated future I'll try to organize a trip for interested Muse readers.

A number of others wrote in. Eric Brewer shared some pictures:

I got interested in TTL and CMOS design and taught myself enough to build my own custom interfaces.  But I finally took the remaining leap into microprocessors and micro-computers with the Z-80.  Attached are a couple of photos of a rather dense board I designed and wire-wrapped for an S-100 bus, CP/M based system.  (The board came back to me a decade later after a research computer was decommissioned.)  The idea was to fit "everything" except CPU, RAM, and floppy disk controller onto one board.  So you'll see configurable power-on jump circuitry, a pair of 8251's for serial communications (with RS-232 level shifting and jumper-customizable handshaking), a pair of parallel ports using 74LS244's (as I recall), and an 8253 counter-timer for getting msec reaction times.  The screw stand-off's on the backside corners were for a piece of perf-board that protected everything from errant fingers and such.

Ah, back when a logic probe and a 'scope were all you needed to troubleshoot a system!  The hard part was bootstrapping -- if you designed the circuitry, wired the board, wrote the low-level "monitor" and burnt it into the EPROM yourself, a failure to boot could be literally anywhere in the system.

It's pretty amazing these things worked as well as they did, considering the noise.  Lots of bypass caps soldered in everywhere! 

Back in the early days microprocessors required a ton of support circuitry, as this board shows. You may be interested in just how many parts were required to build a working computer. This page shows (about 2/3 of the way down) schematics for a 1974-era 8008 machine.

Are We Engineers?

Are we engineers? In some states that title is restricted to those who pass professional competency tests.

The New Oxford American Dictionary (2nd edition, 2005) defines the noun "engineer" thusly: A person who designs, builds or maintains engines, machines, or public works.

The Shorter Oxford English Dictionary (6th edition) provides a number of definitions; the one most closely suited to our work is: An author or designer of something; a plotter.

Neither really addresses what we do, though I have to admit liking "a plotter" as it paints us with an air of mystery and fiendishness.

In a provocative piece in the March 2009 issue of the Communications of the ACM ("Is Software Engineering Really Engineering?" by Peter Denning and Richard Riehle) the authors wonder if software development is indeed an engineering discipline. They contend that other branches of engineering use standardized tools and metrics to produce systems with predictable outcomes. They state about software: "[no process] consistently delivers reliable, dependable, and affordable software systems. Approximately one-third of software projects fail to deliver anything, and another third deliver something workable but not satisfactory."

That huge failure rate is indeed sobering, but no other discipline produces systems of such enormous complexity. And we start from nothing. A million lines of code represents a staggering number of decisions, paths, and interactions. Mechanical and electrical engineers have big catalogs of standard parts they recycle into their creations. But our customers demand unique products that often cannot be created using any significant number of standard components.

At least, that's the story we use.

I hear constantly from developers that they cannot use a particular software component (comm stack, RTOS, whatever) because, well, how can they trust it? One wonders if 18th century engineers used the same argument to justify fabricating their own bolts and other components. It wasn't until the idea of interchangeable parts arrived that engineering evolved into a profession where one designer could benefit from another's work.

Today, mechanical engineers buy trusted components. A particular type of bolt has been tested to some standard of hardness, strength, durability and other factors.

In safety-critical applications those standard components are subjected to more strenuous requirements. A bolt may be accompanied by a stack of paperwork testifying to its provenance and suitability for the job at hand. Engineers use standardized ways to validate parts. The issue of "trust" is mostly removed.

Software engineering does have a certain amount of validated code. For instance, Micrium, Green Hills and others offer products certified or at least certifiable to various standards. Like the bolts used in avionics, these certifications don't guarantee perfection, but they do remove an enormous amount of uncertainty.

I'm sure it's hugely expensive to validate a bolt. "Man-rated" components in the space program are notoriously costly. And the expense of validating software components is also astronomical. But one wonders if such a process is a necessary next step in transforming software from art to engineering.

Failure of the Week

Luca Matteini installed the new FTTC/FTTH router, received from Vodafone, I was just checking the statistics to discover that the sent packets are a negative/fractional number...

Embedded failure of the week


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.

Joke For The Week

These jokes are archived here.

If it weren't for C, we'd all be programming in BASI and OBOL.

About The Embedded Muse

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.