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
• The Magazines We Read
• Are Bugs a Problem - Given Quick Fixes?
• A Fluid Computer
• This Week's Cool Product
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

I'll be at The Embedded Systems Conference in Boston this week - if you're there, say howdy!

A lot of prospective entrepreneurs contact me for advice. I always recommend they read the first half of The E-Myth by Michael Gerber (the second half is pretty dreadful). Gerber's contention, which I've observed countless times, is that too many owners of small businesses are completely focused on working in the business - that is, doing the consulting, making the products, and generally engaging in the main business activity. Instead, one should (at least some of the time) focus on working on this business. That might include finding ways to increase productivity. Reduce taxes owed. Deliver faster. But unless one is actively making the business better, decay, entropy and the competition will prevail.

This is what my Better Firmware Faster seminar is about. Take a day with your team to learn to be more efficient and deliver measurably-better code. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

Intel is selling Wind River after a nine-year marriage. Wind's fame stemmed from their VxWorks RTOS, but that product's market share has been in decline. According to last year's EETimes survey it garners on 4% of the embedded OS market. Compare that to FreeRTOS which is pegged at 20%... and which was also recently acquired (in a rumored fire sale), in this case by Amazon, of all companies.

"One can construct convincing proofs quite readily of the ultimate futility of exhaustive testing of a program and even of testing by sampling." Tony Hoare

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

According to Capers Jones, a very rough guide to estimating the number of people needed on a project, and the project's duration, is:

• Number of developers = (function points)/150
• Calendar months = (function points)^0.4

One function point is somewhere around 130 lines of C code .

Many of the participants in the recent salary survey also indicated what publications they read to keep up with technology. 621 people listed the magazines and websites they read.

Here are the resources cited by at least twenty respondents (the Embedded Muse is not listed due to selection bias):

There are a couple of interesting points, and some useful comments:

• Only 6 individuals cited ACM publications. Yet the ACM is really the software person's main professional organization.
• Over 80 did mention IEEE pubs, but several complained about the barrage of email the IEEE generates. I agree, and despite many unsubscribes the Institute still manages to leak gobs of unwanted emails through. I'd add email filters but am afraid to miss the yearly renewal emails.
• Only one person mentioned Digi-Key's resources, yet they have a significant outreach program which commissions lots of articles from various authors (me included).
• 8 people mentioned YouTube, while over 50 watch Dave Jones' EEVblog. I was surprised, expecting more consumption of video media.
• Many, many complained about the former print publications that now appear in on-line form only. Folks are unhappy with superficial content, too much vendor bias, and a lack of interesting articles.

I have to agree with the last point. Too many ex-magazines that now exist only as websites are overrun with user comments rather than hard-hitting technical content. I find some of these resources barely readable.

Does that tell me anything or make me want to read the article? No on both accounts. Ironically, the linked article is pretty interesting.

Uninteresting articles and infrequent updates are the conundrum faced by publishing today. Many of these were monthly print publications; transitioning to a newspaper-like hourly update schedule isn't possible as there have been so many layoffs in the industry that staffs are completely hollowed out. One almost wonders if they are edging to a new model where those machine-generated titles will soon link to machine-generated articles.

I have an issue with the increasingly-common lack of an author's affiliation. Dig around, and you find that article about using the Acme 123 analog/digital converter was written by an engineer - or worse, marketer - at Acme. This is an old tension; Tyler Sperry, first editor at Embedded Programming Programming magazine, was fanatical in not letting vendors write articles for fear of printing biased stories. I felt, and feel, that often the vendors often know more about a subject that some others, so should have a role in disseminating knowledge. But the articles should be attributed in the interest of honesty and disclosure.

Then there's the eternal quest for page views. You go to an article, read to the bottom, and then discover this is page one of ten. We know the reason for this, but as a reader I find it very annoying. Since ticking off your customers is very bad business, this practice screams that the publications' real customers are the advertisers. The readers are just eyeballs, basically unimportant sheep the publishers wish to deceive into a repetitive motion injury from hitting that mouse button.

Finally, in my opinion too much space is expended in publishing glorified press releases. Some on-line sources are really little more than aggregations of marketing material. PRs are important as they let us know about useful products. But they should be tempered with hard-hitting technical content.

On the other hand, most of the technical print publications are still very good. Circuit Cellar, IEEE Spectrum, IEEE Computer, Communications of the ACM - they do a good job (though the latter three don't devote much space to embedded issues). The old-fashioned model of expensive printing means editors have to carefully curate what they publish.

A recent meme in the blogosphere claims bugs are not a problem - if you can fix them fast. The proponents of this idea do exclude safety-critical applications. As I understand the argument, a quick fix means no real foul. These are explicitly errors that have made it into the field; mistakes that impact a customer.

I think this is an idea only a software person could embrace. Someone whose focus is on the code to the exclusion of all else. In the real world, there's really only one person who matters: the customer. The customer is a magical creature who ultimately makes our paychecks possible, who feeds our kids and who underwrites the engineering department. Slamming out a never-ending stream of bugs, even if fixed quickly, is simply going to to tick the customer off.

If a grocery store sold me sour milk more than once, and even if that entity replaced the noxious goo with the freshest of the fresh, microseconds from the cow's udder, in mere seconds after my first sip of the repulsive liquid, I'd stop buying milk and pretty much everything else from that store.

It strikes me as the height of navel-gazing to think that software, unlike any other product, doesn't have to work correctly. "Software is hard so we blessed software engineers should be given a pass on quality" is a sure path to losing customers to more businesslike competitors.

We have cable Internet in our house which benchmarks at a remarkable 250 mbps. I can't help wonder, though, if a never-ending stream of patches, coupled with the explosion of IoT devices and too much tolerance for error-ridden code that can get fast fixes, means most of the bandwidth will one day be consumed by firmware updates?

Errors are inevitable. We will ship bugs. But we need a laser-like focus on getting the code right, not a tacit acceptance of poor quality tamed, to some extent, by training our customers to tolerate problems. How right? We have metrics; we know how many bugs the best and mediocre teams ship. Defect Removal Efficiency (DRE) is a well-known metric used to evaluate quality of shipped code; it's the percentage of the entire universe of bugs found in a product that were removed prior to shipping (it's measured until 90 days after release). The following chart shows DRE for teams producing different quality code:

One wonders if those advocating continuous patching have any idea where they stand on the DRE scale. Is their code generally so sub-par that frequent fast fixes are unavoidable?

What's your take? Should we favor buggy releases and quick patches? I prefer the model employed by the people behind the Space Shuttle: when an error occurs they fix it, of course, but then ask "how did this slip out? What can we change so this never happens again?" And they go further, looking to see if the same mistake was made in any other software component.

Patent 3190554, granted in 1965, describes in great detail a computer with no electronics. All operations are mediated by fluid flow.  

This is pretty cool. It has four instructions:

I'm not quite sure how this would work absent a subtraction or complement instruction.

So, how does it work? Here's an OR gate:

The patent describes the gate thusly:

FIGURE 6 shows in diagrammatic form a passive OR gate. It also is typically a laminated structure the center lamination of which is cut to provide a pair of converging input ducts 333 and 334 which converge to a common throat area 336 and then into a common, tapered, output duct 335. A pair of fan shaped release ports may branch off the throat area as shown. The operation of this element is such that a high pressure input A or B applied to either input duct 333 or 334 or both will yield the logical sum on the output duct as indicated by the expression A+B in the drawing.

Other components are listed, like a flip-flop, though the operation of that is quite complex.

The power supply looks like this:

Here's just a portion of the control logic:

The patent was assigned to Sperry Rand, which was a mainframe giant. I spent many lovely hours with one of their Univac 1108 machines, but don't remember fluid leaking out of it.

ST has a new time-of-flight sensor used to measure distance to an object via an infra-red light beam. The range is only about 4 m, but the entire module is only 4.9 x 2.5 x 1.56 mm. It has an I²C interface and the usual plethora of modes.

The datasheet is lacking in details, but the "Single photon avalanche diode" (SPAD) sounds very much like a semiconductor version of a photomultiplier tube. In this device the SPAD is a 16 x 16 pixel array with an adjustable field of view.

Operational details are sketchy, but with a minimum minimum range is 4 cm the component likely uses sub-nanosecond pulse widths.

Mouser lists the part at under $4 in volume.

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.

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.

From Steve Land:

ME: so this is a RAID array

YOU: but the A in RAID is for "array" so isn't saying "RAID array" redundant?

ME: Yes, that's what the R is for.

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.