Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 349, May 7, 2018
Copyright 2018 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 info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
Editor's Notes

A lot of prospective entrepreneurs contact me for advice. I always recommend they read the first half of The E-Myth by Michael Gerber. 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 and entropy 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.

 

On June 27-28 NIST will host the Sound Static Analysis for Security Workshop at NIST's facility in Gaithersburg, MD. To quote from their communications "this two-day workshop is focused on decreasing software security vulnerabilities by orders of magnitude, using the strong guarantees that only sound static analysis can provide. The workshop is aimed at developers, managers and evaluators of security-critical projects, as well as researchers in cybersecurity." I plan to attend. It's free, and there's more info here.

I'm on Twitter.

Quotes and Thoughts

What one programmer can do in one month, two programmers can do in two months. Fred Brooks

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.

Kyle Bostian wrote: C gibberish to English converter. No further explanation needed. Also available as a command line tool. https://cdecl.org/

Freebies and Discounts

This month, thanks to the folks at Expresslogic, we're giving away 8 copies of Real-Time Multithreading, a great book about RTOSes in general and ThreadX in particular.

Enter via this link.

Are Bugs a Problem, Given Quick Fixes (Redux)?

In TEM348 I wrote that there's a meme going around that bugs aren't really a problem, if you can fix them quickly. My take is that bugs are a problem, and instead of quick fixes we need to get the code right to begin with. Not everyone agreed! Here are some dissenting opinions. Note that in my comments I said that if a store sold me sour milk (an analogy to providing buggy code), I'd stop shopping there.

Charles Manning wrote:

Jack, a counter view of what you have written about software patching.

Software patching allows us to be far more bold in the way we release new features into the markets. If we could not do that we would have to be far more conservative about software releases and most of the utility of software would be lost. Patching allows us to make better products (ie. better feature sets and more value) faster and cheaper (ie. better price point for the customer).

Perhaps a different way to think about this is to consider what would hardware (and milk) delivery could look like if physical products could be "patched" too. Imagine the amazing innovation you could have in both cost reduction and new product introduction:

* Vanilla ice cream can be "upgraded" to chocolate ice cream. Heck, we can come up with new flavours every hour, or have open source developers making new flavours. If one of those flavours isn't quite right first time (bug!) we can update it (patch!). That would reduce the stock required, simplify the supply chain and reduce product costs. It would reduce wastage. It would mean an explosion of new flavours and icecream innovations - mushroom and venison barbecue ice cream that changes to mango-mint when you want a change - yum!

* Milk can be upgraded after you bought it. If it goes sour it can be made fresh by patching it. That means you can buy a gallon of milk even if you are only going to use a quart this week because you don't have to worry about it going off. The milk does not need refrigeration so that makes it easier to transport/store and no wastage. The store does not have to worry about product going bad, so they will always keep sufficient stock and won't run short. The grandkids come over on the week end and want chocolate milk. No problems. Upgrade it. Since a lot of the cost of milk is associated with dumping spoiled product and storage etc, the price of milk would halve. Better nutrition for the starving kids of the world!

* After driving 10,000 miles your oil and spark plugs are no longer pristine. Your car just wifis in an patch. Some new oil additive can improve mileage and is instantly upgraded. Come winter they find there's a tweak needed to the new oil formula - patch it. Your car lasts longer, runs smoother and gives better mileage. Far cheaper for you and better for the environment.

The point I am making is that the ability to patch is really part of what gives software the flexibility to rapidly provide feature sets that give people value. Without that, software would be developed and released on very conservative timescale and with very conservative feature sets. Boring, boring world!

If that new oil additive could not be patched they would have had to test it for years in a wide variety of cars: summer heat and freezing winters. Ten years later the new oil hits the market. That's a lot of investment for the oil company to make for a very risky product idea, so guess what: they don't even try!

All products have defects (eg. I bet you're had to fix/change things on your boat). Having to put up with defects (and batteries that go flat etc - also a defect of sorts) is just part of the cost people pay for the value they receive from a product.

Bryan Murdok contributed this:

You keep harping on software quality.  In this latest newsletter you say, "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."

The fact is that the size of the software industry as a whole is estimated to nearly half a trillion dollars and growing[1].  Customers continue to pay incredible amounts of money for buggy software.  I know, it doesn't really make sense to me either but at some point you have admit that there is plenty of data out there to back it up: buggy software sells.  Bill Gates became the richest man in the world by producing buggy software.  You just can't argue with this fact.

Obviously there is some level of quality needed, but going beyond that level is a waste of time, money, and effort for a seller of software in this market.  It's not what customers want.  Producing too high quality of software will put you out of business[2].  This is what you are fighting against when you advocate for higher software quality.

1. https://en.wikipedia.org/wiki/Software_industry#Size_of_the_industry

2. A recent post-mortem from a failed database business (relevant summary: MongoDB was buggier and they won):  http://www.defmacro.org/2017/01/18/why-rethinkdb-failed.html

On Declining Magazine Quality

TEM348 bemoaned the quality of technical journalism. John Black had this to say:

With regard to the feedback from your readers, and your response...

  • 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.

Sadly, I must agree with you and your survey respondents...

During my years editing our magazines at OpenSystems Publishing (in the 1980s and 1990s) I found that the very fast pace of technological evolution was outpacing the ability of many colleges and universities to provide young engineers with the new knowledge they needed to perform their jobs. I decided to try to fill that gap by providing highly technical articles in our magazines about these emerging standards and emerging technologies. 

In doing so, I found that an editor must:

(1) have a good enough technical background to recognize emerging technologies and emerging standards... early

(2) be able to identify companies who are working on new products that employ those emerging standards and technologies 

(3) articulate to the company's marketing people that their potential customers will need to be educated about the new standard or technology in order to see the value in their products.

(4) convince them that this is important enough to devote an engineer with enough expertise to the task of writing an article.

(5) be willing to expend as much effort editing the content of the article as the engineer expended in authoring it. 

I found that (5) was crucial because the overworked expert (who wrote the article) often found it to be too tedious (and too time consuming) to try to write an article that could be easily understood by more junior engineers, who would be eagerly reading that article. (Of course, this assumes that the editor will take the time to learn enough about the emerging standard or technology to ask intelligent questions - and not waste the author's time in the process.)

I believe that this approach (which we communicated with the tagline Magazines for Engineers, by Engineers) contributed to the early success of OpenSystems Publishing in the 1980s and 1990s.

However, the Internet has now changed all the incentives in the publishing business. Ad space on the web does not command as much revenue as pages in a paper magazine, and the effectiveness of those ads is now measured in click-throughs, rather of circles on bingo cards. 

As a result, most publishers have abandoned the strategy of providing highly technical tutorials to their readers, in favor of providing online Buyers Guides that can provide instant referrals of their readers to vendors, and in favor of providing outsourced electronic marketing services (such as webinars) to their advertisers. (Even my beloved OpenSystems Publishing has now changed its name to OpenSystems Media.)

With engineers currently facing...

(1) rapidly rising university tuitions

(2) the inconvenience of having to take time off work to attend classes

(3) the inability (or lack of interest) within universities to keep up with the accelerating pace of technological evolution

(4) the need for lifelong education

...we are seeing the spontaneous appearance of inexpensive online courses (such as those offered at Udemy.com) that provide crowd-sourced, just-in-time education for engineers. I believe that the sophistication of these course offerings will continue to improve over time - to the point where they will eventually be seen as an alternative to university courses. 

So, I guess it's time to leave behind any feelings of disappointment with the fact that magazines are no longer providing ongoing education, and begin looking for what will takes their place. Given current trends, I believe that Internet resources will eventually do a better job in that regard than magazines were ever able to do.

The Boston Embedded Systems Conference

The first Embedded Systems Conference was in 1989 at the Sir Francis Drake hotel, a wonderful venue where one heard the tinkle of San Francisco's streetcars over the speakers' voices. It was small, with about 400 attendees, but was soon to grow. At its peak in the 1990s some 15,000 people showed up. Motorola (now Freescale... uh, NXP) put on enormous Texas-themed parties, with oceans of beer, bands and dancing. Intel, Wind River (now not part of Intel, having just been sold) and others had huge booths and hundreds of vendor stands crowded the show floor.

The Boston ESC last month was rather a shadow of its former glory, with about 30 vendors and around 1000 attendees. Co-located with the BIOMEDevice show the floor was pretty big, though the vast majority of the booths were for the latter event. Still, it was interesting to stroll those stands and watch many 3D printers and robots at work.

I wrote in Muse 346 that pretty much all of the important oscilloscope vendors had booths at Embedded World in Germany. 20% of the ESC's booths were for scope vendors: Siglent, Tek, Pico, etc. Keysight wasn't there. Surprisingly, only three RTOS vendors showed up.

I was only able to attend a couple of talks, but those were of outstanding quality. Dan Beeker's Electromagnetic Fields for Normal Folks could have run a week and I'd still be entranced. A bit quirky at first (he played a recorded song he wrote called "It's All About the Space," which stressed the need to focus on space rather than wiring), he wants us to think in terms of waves rather than electrons. A couple of interesting factoids he gave include that the "4" in FR4 PCB material means the speed of a wave on that PCB is about one quarter that of c in a vacuum. And there's a 200 dB reduction in field strength from the top of a board to the bottom if there's a ground plane in between.

A session sponsored by Rohde&Schwarz and given by Mike Schnecker called Understanding Probes and Probing Techniques for Signal Integrity was equally compelling. Turns out, the conventional scope probe we grew up with is now called a "browser" probe, as one can browse around a circuit board with it. Alas, with modern high-speed circuits browser probes are often inadequate for our needs. Active probes with extremely-close ground connections are often needed instead, sometimes at enormous expense.

Mike showed that with a differential probe the inductance is roughly proportional to the area enclosed by the two leads; he figures a 14 pF probe and 3 cm enclosed area has a resonance of 100 MHz.

Curious, I used the formula for resonance in an LC circuit and found that this corresponds to around 150 nH.

Though the show was small there was a lot of useful material presented.

This Week's Cool Product

There was a time when a superhet radio was about the epitome of electronics. RCA sold the earliest consumer superhetrodyne radio in 1924; 148,000 flew off the shelves in the very first year at a price of $286 (about $4000 in today's dollars). It had six vacuum tubes, equivalent to six transistors. In the 1960s I had a world-war II era RBC receiver in my ham radio shack, which had 19 tubes. It must have weighed 100 pounds, not including the separate power supply box:

These hulking monsters can now be replaced by a chip weighting a gram or so. It used to be one had to be an expert at hetrodyning, mixing, and RF design to build a radio. No longer; it's now possible to get a radio on a chip.

Silicon Lab's Si4720 is a very cool example. This is a receiver/transmitter for the FM radio band. Add a microcontroller and you're pretty much done. The antennas go straight into the chip without any tuned circuits.

At only 3 x 3 mm QFP, it's $12 in singles. Hackaday has a radio project using this device.

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.

Jobs!

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

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

Advertise With Us

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.