Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 432, October 18, 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 info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

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

Last week at a wedding I had a long chat with a very successful uncle who was an early investor in Analog Devices. He's a smart guy with little knowledge of the sciences and engineering. He is concerned about China's saber-rattling over Taiwan and what that could mean for semiconductor production. He told me that modern cars have as many as 50 semiconductors. Digging deeper, I found that he, and others in the group, conflate "semiconductor" with "chip" and with "microprocessor." None had heard of the term "microcontroller." It seems that the "chip shortage" means "semiconductor shortage" to more than a few people. While discussing this we were drinking from glasses that sensed liquid and, when present, toggled a slew of colored LEDs in bright patterns (I brought one home to dissect). When I mentioned that the glasses probably had a computer in them, faces radiated astonishment. I was a bit stunned that after a half-century of embedded systems so many were so uninformed about semiconductors. Where's the curiosity? The sense of wonder that raises questions a quick trip to Wikipedia would answer?

Percepio is running free monthly webinars with roundtable discussions about embedded and IoT development. Held the first Tuesday of each month the focus is on debugging common runtime issues, with tips about how to avoid these problems. A Q&A follows. The next one is November 2 and focuses on using Tracealyzer with the OSS Zephyr RTOS.

IEEE has a new salary survey. It doesn't break out numbers for embedded people, but the median income in the USA for "Non-Internet Software Development" is $166k. "Hardware Design or Hardware Support" folks make $184K. I'm not sure I believe these numbers.

Quotes and Thoughts

If there’s one thing the software industry is repeatable at, it’s doing the same silly things on project after project. Use retrospectives to learn, to understand, and to improve continually. - Karl Wiegers

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.

Paul Carpenter sent along these links for calculating trace sizes on PCBs:

https://www.gemcircuits.co.uk/tools/traces_width.aspx
https://www.digikey.co.uk/en/resources/conversion-calculators/conversion-calculator-pcb-trace-width
https://www.multi-circuit-boards.eu/en/pcb-design-aid/impedance-calculation.html

History and formulas at bottom of this one https://www.multi-circuit-boards.eu/en/pcb-design-aid/surface/conductor-ampacity.html

Excel version
http://www.tgdesigns.plus.com/pcbden/files/PCB-trace-calc.xls

Luca Matteini, thinking about the recent comments on grammar, suggests this tool:    https://app.grammarly.com/

Freebies and Discounts

 Zeroplus has graciously given us three of their Wirecare AC circuit testers which I reviewed here. Three lucky winners will each get one of these: 

Enter via this link.

A Solution to the Chip Shortage

(This is one of my recent blog posts).

Sometimes one comes across a solution to a problem that is so mind-numbingly ridiculous one has to scream "enough!"

We've all heard about how the automotive industry is suffering from a shortage of chips. When the pandemic hit they cut back on semiconductor orders, anticipating a slowdown in sales. That didn't happen and now $50k cars are parked waiting for $0.50 MCUs.

According to this September 17, 2021  piece in Fortune, the problem is that car makers rely on parts with 45 to 90 nm geometry when they should be thinking 16 nm. Indeed, Intel's chief executive Pat Gelsinger berated them for this poor decision making, and says he's willing to "make them as many Intel 16 [nanometer] chips as they want."     

Mr. Gelsinger has a point. Why use a ten cent MCU to control a window motor when a $300 Intel Inside® microprocessor can raise that window in nanoseconds? Customers are sick of waiting literally for seconds for windows to raise and lower. And using a Core I7 processor means these will be Windows 11 windows which will provide (according to Microsoft) "A new Windows experience bringing you closer to the people and things you love." Studies have shown that drivers are more than willing to wait in their driveways for a half hour for the frequent OS upgrades to install when the benefit is being closer to the people you love, including the screaming kids.

Of course, the $300 CPU will need 16 GB of RAM, a 1 TB hard disk, network controller for OS updates, and a 32-layer PCB. At some 100 amps figure on a pair of 2/0 battery cables to feed the thing. With luck the 0.605" diameter of those cables won't impede smooth door openings and closings all that much, and the buck-a-foot price multiplied by the 50 to 100 controllers in the average car won't affect the vehicle's sales price by more than 50% or so. Counter-rotating cooling fans will prevent the vehicle from spinning on its axis at power-up.      

At 100+ watts per processor the car's air conditioner would have to be beefed up to a three-ton unit. But that would fit comfortably on the roof. Many vehicles come with towing hitches, which could conveniently tow the cooling unit's 20kW generator. Quick-disconnect 200 conductor 2/0 cable connectors are in development.

I guess the corollary to this thinking is that using (gasp!) 8 bit MCUs instead of the latest in processor technology is engineering malpractice. What designer would consign his products to dead-end 45 nm technology? Sure, it is cheap, proven reliable, and a good fit for the application. But the benefits of higher cost, lower reliability, longer startup times and massive profits for Intel are just too obvious to state. It's good for the automotive folks, too, as the vehicles will now become obsolete as often as PCs. Win-win! (If one neglects the customers).

The article in Fortune concludes: "If semiconductor suppliers like Intel and Qualcomm have their way, however, the days of the auto industry relying on these cheap commodity chips are numbered." (Emphasis added)

Ya think?

(It's strangely appropriate that when writing this I wanted to go to Microsoft's site for the quote above, but based on my browsing history Firefox suggested "Microchip" instead.)

Even More on Grammar

Responding to thoughts on using correct grammar and spelling, even in comments, many more comments poured in. Here are a few.

Neil Cherry had an amusing take::

Uhm, I'm guilty of bad English (and it's fragrant abuse ;-) yes, I know: it's = it is).

I wrote a For Dummies book and my editor drilled into me one particular question: What is "it"? That still weighs on my mind whenever I write (& don't use "it's" spell it out).

English as a second language (for Software and hardware Engineers):

   Let's eat Grandma!
   Let's eat, Grandma!
   Comma's save lives

I have the tea-shirt (I've spilled tea on it more than a few times).

I regularly abuse the English language on long bike rides with my friends. I love to talk about farm land that is furloughed.

What?

It's not being worked. ;-) Obviously our discussions tend go sideways often.

The Great Train Robbery (true story:) I was out riding my bike and was held up by a train. It took for ever to clear the crossing.

I took some extra classes (another degree) so I needed to write some technical articles for the class. One of the students wrote the whole article in txt. She couldn't understand why it wasn't a valid technical article. I tried to explain the technical and legal problems of such 'vague' terminology.

But I'm just as guilty as I wrote an email loaded with TLAs (Three Letter Acronyms). While the audience completely understood the TLA laced message it was noted that the message was Not Safe For Work if read a certain way. I'm a lot more careful about the abuse of TLAs.

Final note, one that drove me a bit nuts in my additional courses. I was taking a network class (I was developing Network Services in a Lab) and the instructor and the book stated that network switched route packets. Routers route packets (they can now switch packets but that's another discussion) and switches switch frames. My discussion on the problems with the technical wording did not endear me to the instructor.

Clearly lax standards or practices can lead to such sloppiness.

PS: I'm also a stickler for the addition of parenthesis in math formula and programming logic. You can never be to clear in these areas. The computer is dumb enough to do what you ask of it.

Daniel McBrearty makes an important point about non-native English speakers:

Hmm.  I want to weigh in on the issue of grammar and punctuation. Now I'm all about good use of language, and communicating our intent clearly is really important, whatever the context.

But please let's spare a thought for those for whom English is not a native language. I work in a company where that is true for most people, even though English is still the default (this is common in Belgium and Netherlands.) We also use excellent sub contractors based in the Czech Republic.

I speak decent French and Dutch and am currently learning Italian (using the excellent Duolingo app, which I highly recommend to anyone who wants to take on the challenge of learning a new language).

Learning a language is one of those things where it's not that hard to pick up a few phrases, but achieving some fluency, and getting the details right is really hard. Those little irregularities and shades of meaning are the things that get you, over and over.

In today's connected world, it's very likely that most readers of this newsletter interact professionally with at least a few non native speakers. We native English speakers have been handed an entirely unearned advantage, in that our language is the international default (despite its insanely difficult spelling).

However before we criticise those who don't share that advantage, we might ourselves take up the challenge of learning a foreign language or two, if we didn't already do so.

Where communication is a bit tough because if this, perhaps repeating our understanding back, in simple and clear phrases, to the other party, is a more productive path.

Angus Logan mirrors my obsession with assertions:

A quick thought on the discussion around grammatical and spelling errors in comments. A common thread is that “language is not precise”. This is (yet) another good reason to use more assertions in code. Comments can be slightly misspelt (or indeed misspelled!) or become incorrect over time. Assertions, of course, must always be constructed to be logically correct so there is no chance of ambiguity in their use. They also must keep up with changes to the functional code, which is again an improvement on relying solely on comments. While I agree wholeheartedly that comments should be grammatically correct and as precise as possible, this is still no substitute for real logical statements of how the program should work.

J.G. Harston on ensure v. insure (a mistake I make too often):

Regarding using decent English in coding, I can put up with "colour" vs "color", "-ize" vs "-ise", but what really gets my goat is the American inability to differentiate "ensure" and "insure", using "insure" for both cases. Especially annoying in a technical environment, and especially in coding as they are two completely different concepts, almost opposites.

*EN*suring something is putting things in place so that failures do not happen.

*IN*suring something is putting things in place in the expectation that failures *will* happen, and providing facilities to pick up after that failure.

You *en*sure you don't get wet when it rains by using an umbrella.

You *in*sure for the possibility of getting caught in the rain not by using an umbrella but having a towel at home.

You *en*sure that bridge does not fall down by sizing the girders appropriately and fixing the joints the correct way around.

You *in*sure that bridge can be rebuilt after falling down by putting up a financial surety to be called on after it has fallen down and you are sued.

In Unix-land it's the difference between sync() and signal().

It's the coding difference between:

signal(sig_ioerror, attempt_to_pick_up_pieces);  write(handle, data);

and:

loop {
 result=write(handle,data);
 } until (result=ok OR result=unrecoverable_failure)

I've seen it propagating more and more into coding documentation and teaching, which propagates flawed thinking. It inculcates a culture of "getting it right doesn't matter, we'll pick it up when it falls over". But you Don't. Want. It. To. Fall. Over.

It does seem to be a transpondian thing, coding concepts I've seen as originating this side of the pond seem to have an understanding of "ensure" built in, things like "call and return ok or fault". Coding concepts I've seen from your side of the pond seem to originate "chuck it out and worry later" things like catch/try constructs.

Finally, Larry Marks cites a classic failure:

Are comments important? Just remember that the Canadian (English-speaking) team that ported the code to the Therac-25 got code that was thoroughly commented...in French! Probably including variable names.

--Nancy Leveson, 1991, University of Washington.

Staying Current

How do you stay up to date in this field? I'm finding it increasingly hard to find good sources of information. There are plenty of great books, many of which I've reviewed here.

Here are some sites that I review (generally) weekly:

Embedded Artistry's newsletter. A monthly compendium of ideas and links to other sites. I always find something useful.

Memfault's blog. All hard-hitting embedded concepts. No fluff.

IEEE Spectrum. Occasionally something useful engineering-related. Way too much about robotics. Never any technical depth.

EETimes. Some good stuff, occasionally, about the business of electronics. Rarely anything technical that's useful.

Embedded Computing Design. Mostly just gussied-up press releases. While PR is important so we know what products are available, I prefer the old model of a mix of deep technical articles with a section of PR.

EE Journal. Alas, Jim Turley retired from this recently; his columns were gems. Steve Leibson's articles are always worthwhile.

Clive Maxfield's blog. Though rarely any useful tech content, Max's (wordy but charming) pieces are fun.

The Amp Hour. (Which has the great tag line: Keep Current). To be honest, I don't listen to this as I don't care for video and audio blogs. It's much faster to read material than to listen or watch. But Chris and Dave are smart guys and if you're into that sort of thing, this is worthwhile.

The AdaCore blog. Yes, Ada does work on MCUs and if you're an Ada junkie, this is worthwhile.

EE World Online. Way too much sponsored content. However, Bill Schweber's articles are generally great and insightful.

Electronic Design. There's some good tech content. But it just isn't the ED of the olden days. This is one of the few professional electronic magazines one can still get in print. I find I pay more attention to the printed magazine than the online version.

EDN. Remember EDN in the pre-Internet days? It came out weekly, as I recall, and it took a week to get through it. While a pale version of the old print version, EDN still has great technical content.

Embedded Related. Rarely updated, but when it is the articles are often interesting.

Feabhas's blog. A good blog with (sometimes excessively) detailed tech content.

Embedded.com. My old home. I check it every week but rarely find something interesting.

Unfortunately, many of these that attempt to be traditional trade publications (i.e., not blogs and the like) are poorly put together. Home pages often have much duplication - the same article is referenced two and three times, which is a waste of mental bandwidth. And it's common to have an article's title and a short description that doesn't describe anything; one has the feeling a computer just excerpted part of the article's first sentence. An example from last week's EETimes:

Huh? Why would one follow that link?

Are there any sites you consider necessary as an embedded engineer?

Failure of the Week

A lot of readers have submitted failures for this section of the Muse. To catch up on the backlog, here's a two-fer:

This is from Andrzej Telszewski. It was taken on a tram in the Polish city of Szczecin. The message reads "Departure in 371 minutes." However, it was already going:

This is from Dave Sewuk:

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

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

These jokes are archived here.

Heisenberg and Schroedinger we driving on the freeway when they get pulled over by
the highway patrol. The cop comes around to the driver side and says to
Heisenberg, "Do you know how fast you were going?" And so Heisenberg says,
"No, but I knew where I was". The cop scratches his head, and says, "Pop the
trunk, I want to take a look". He walks back, looks in and then walks around
to the right side and says to Schroedinger, "Do you know you have a dead
cat in the trunk?" Schroedinger says, "I do now".

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.