Remote-Url: http://www.ganssle.com/tem/tem432.html
Retrieved-at: 2021-10-23 13:45:20.758017+00:00
The Ganssle Group logo
The Ganssle Group logo
* Click here for a navigation menu
* Firmware
Classes
+ Public Training
+ On-Site Training
* Newsletter
+ Subscribe
+ Back Issues
* Expert
Witness
* Blog
* Videos
* Tool & Book
Reviews
+ Tool Reviews
+ Jack's Books
+ Other Embedded Books
* Special
Reports
+ Designing Ultra-Low Power Systems
+ Surprising Scope Probe Issues
+ 2020 Salary Survey
+ Debouncing Contacts
+ Watchdog Timers
+ Microprocessor History
+ Being a Consultant
+ Write-only Memory
+ Process Improvement for the Boss
+ Commenting Code
+ Testing RAM
+ Getting Into Embedded Work
+ Code Inspections
+ Automatic Bug-Finding
+ eXtreme Instrumenting
+ Math Approximations - Trig
+ Math Approximations - Other Functions
+ Better Resumes
* Articles
+ All Articles
+ Analog, Filtering, etc
+ Communications
+ Debugging
+ Fun Embedded Stuff
+ Hardware
+ Historical
+ Managing Projects
+ Math in Computers
+ Memory
+ Philosophical and Career
+ Real Time
+ Software & Firmware
+ Tools for Embedded Developers
+ Sailing!
* Random
Rants
+ Electronics
+ Business Issues
+ Software Engineering
+ Products and Reviews
+ Philosophy of Engineering
+ Miscellaneous
+ History of Electronics and Embedded
+ Software
+ Random Thoughts
+ Fun Stuff
+ Real-Time Issues
* Humor
* Contact/Search
+ Contact Info
+ Advertise With Us
+ Search This Site
+ Jack's Bio
+ Expert Witness
+ Our Privacy Policy
Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse Jack
Issue Number 432, October 18, 2021 Ganssle,
Copyright 2021 The Ganssle Group Editor
of The
Editor: Jack Ganssle, jack@ganssle.com 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
* Quotes and Thoughts
* Tools and Tips
* Freebies and Discounts
* A Solution to the Chip Shortage
* Even More on Grammar
* Staying Current
* Failure of the Week
* Jobs!
* Joke for the Week
* About The Embedded Muse
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
[tem432-per]
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:
[wirecare-4]
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:
[tem432-eet]
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:
[tem432-fail]
This is from Dave Sewuk:
[tem432-fail1]
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.
R&D Software Development Engineers - Control System
programming
Energy Control Technologies (ECTpac.com) is actively hiring
control system engineers and
programmers for development of advanced turbo-machinery
applications.
You will have the opportunity to work on some of the most
complex and critical machines that
directly affect the efficiency and operation of energy
production plants across the world.
* Design and develop control architectures to achieve
desired outcomes
* Design logic sequences and write PLC code for a variety of
hardware platforms
* World Travel opportunities and employee benefits are
included
* Knowledge of Honeywell, Siemens, or Rockwell Automation
PLC products
Contact GJohnson@ECTPac.com
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.
Do you need to eliminate bugs in your firmware? Shorten schedules? My Better
Firmware Faster seminar will teach your team how to operate at a world-class
level, producing code with far fewer bugs in less time. It's fast-paced, fun,
and covers the unique issues faced by embedded developers. Here's information
about how this class, taught at your facility, will measurably improve your
team's effectiveness.
Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that
goes to 44,000+ engineers. Click here to sign up or enter your email here:
[ ] [Submit]
Latest Embedded Muse: A solution to the chip shortage and ideas on staying up
to date in this field.
-------------------------------------------------------------------------------
The Ganssle Group - info@ganssle.com - copyright TGG, all rights reserved.
Contact info here.