Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
 Issue Number 412, December 21, 2020
Copyright 2020 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.

Contents
Editor's Notes

SEGGER Embedded Studio cross platform IDE

Tip for sending me email: My email filters are super aggressive. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.
Quotes and Thoughts

Any problem in computer science can be solved with another layer of indirection, except of course for the problem of too many indirections. Bjarne Stroustrup
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.

In response to the buck50 logic analyzer in the last Muse, Stephen Green sent in a link to a £6.80 version.

Also in reference to the buck50 LA, Paul Brower warned there are a lot of fake Blue Pill boards around. As he wrote: "Wouldn't want to see a reader frustrated and beating their head against an O-scope trying to figure out why it isn't working as expected. " More info here and here.

Gary Maxwell sent this (college professors please note well!):

The Buck50 analyzer could be a game-changer for the young (and old) to overcome the cost barrier to useful equipment. Packaged, mass-produced, and literally given away, hobbyists could see actual logic timing, and see how coding changes timing. With the advancements in hybrid analog-digital FPGAs with smart cores, could a Buck50 oscilloscope be far behind? That would be awesome, except we have the issue of cheap, inaccurate probes. Could such an oscilloscope calibrate its own probes?

That is a great thought. Test equipment has historically been too expensive for education and hobbyists. Sure, there are some nice inexpensive USB scopes around, but the buck50 technology could literally be a giveaway. Buy a book on digital logic and an LA is included! And it does include a dual-channel oscilloscope.

Jan Ciger has an alternative to regbits, which I mentioned in the last issue:

I have seen that you mentioned Regbits in your latest newsletter. Regbits is fine but it depends on the vendor libraries which which aren't always up to date (especially for newer parts) and uses GPL license which pretty much precludes its use in embedded work beyond hobbyist projects.

A few years ago I found the Kvasir library: https://github.com/kvasir-io/Kvasir   

It has similar goal (type-safe bit and register manipulation) but it also:

  • Uses vendor SVD files to generate the register descriptions, so basically any micro sold today is supported as long as there is an SVD available.
  • It can be used in a way that it coalesces multiple register accesses (e.g. setting multiple bits) into a single assignment using a bit of C++ template metaprogramming magic. This leads to both shorter and smaller code.
  • Is licensed under the Apache license which explicitly excludes code that merely uses/links to the library from being covered (and thus needing to have source code distributed - unlike GPL).
Few people seem to know about this tool even though it is really good.
Freebies and Discounts

This month's giveaway is a Pico 2207B 70 MHz USB scope.

Pico 2207B - giveaway!

Enter via this link.
Tidy Benches

In the last issue a reader asked for tips on keeping a lab bench from becoming a mess. Greg Nelson wrote:

I hung up a pegboard on the wall over my workbench.  The various hooks they offer work well for scope probes, test leads, as well as tools (cutters, strippers, drivers, etc.)  You can even organize things soldering tips into little hang-up bins.  (Particularly useful if you still need to keep strait leaded/lead-free tips, or fine and coarse tips.)

Of course, that doesn't stop my benchtop itself from being a catastrophe, but at least with the leads hung up there it's not a tangle as well...

Dale Chayes had an interesting story with a picture of his bench. I suspect decluttering guru Marie Kondo would not approve:

A "while ago" (when I was in high school) I worked a couple of summers as an apprentice in a tool and die (precision machine) shop which was part of a bigger factory.

The department lead was an "old guy" by my standards then (e.g. younger than I am now) of Germanic origin named Karl and was referred to reverentially (and not in person) as "the dutchman."  He was a meticulous in all respects.

He required that all work stop at 4:30pm on Friday and everyone spend 1/2 an hour cleaning up.

Six years later (about 1974) when I started in a research university shop, the boss (Angelo) was absolutely adamant that ALL work stopped at 4:30pm on Friday. Everyone in the building (even visitors) were required to clean-up for 1/2 an hour before happy hour started. There were no exceptions!  If you had a work deadline, you could skip happy hour but no one could skip Friday cleanup.

Both shops were orderly and clean.

Someday, I aspire to this kind of orderliness. Until then, my bench will continue to look like Jim Williams' but his level of analog understanding still and will forever escape me ;-)

Rob Fries has a comment on storing parts:

I've been using Sterilite 6-quart clear containers (their # 1642) to store parts, special wire harnesses, etc on a per-project basis.  These are stackable.  I recommend the ones with a white lid [from Home Depot or other places] rather than the ones with gray lids [at Walmart], as the white-lid version is more squared-off and stacks better.  I add a small printed label to identify the contents.  I also keep a few small rolling 4 or 5 drawer plastic cabinets under the bench and keep tools and non-project-specific cables in there.

Mark Peterson wrote:

Hang pieces of ½" or bigger pipe, stretch stiff wire, or tie taut string near your workbench and hang test leads, scope leads, adapter cords, USB cables, etc. over them.  The advantage of this method is that the leads can be spread out and easily picked out without digging it out from a pile of others.

(BTW: If a messy bench is the sign of a messy mind, what is an empty desk the sign of?)
A Risky RISC-V Bet... or Our Future?

RISC-V is an open standard instruction set architecture that is gaining a lot of traction. The Wikipedia entry gives a good overview. In the embedded world I see this as an effort to deal with the Arm tax, where licensees pay Arm a small amount for each processor they sell. For us, this means RISC-V parts could be a bit cheaper than Cortex devices. Yet these are generally already so inexpensive that it would seem to be an issue only in very high-volume applications.

Given that RISC-V is an open architecture it's possible to build a customized processor. Add your own instructions or tune others. That could be important in some limited circumstances, though going from an ISA to silicon is not cheap. An FPGA implementation saves foundry costs, though FPGAs will never be a price match for an off-the-shelf MCU.

An old argument we hardly ever hear anymore is that the Intel/AMD ISA is a problem since most of the world runs their PCs with these parts, giving a broad attack surface for bad guys. Arm is so ubiquitous that it is an attractive attack target. Diversity is good.

The Wikipedia article states that, for the embedded version, "Floating-point instructions should not be supported (the specification forbids it as uneconomical)" which strikes me as rather silly. Cortex M parts are quintessential embedded devices, yet it wasn't long before FPUs became common as floats are the leitmotiv of instrumentation and many other embedded applications.

I don't see many embedded systems using RISC-V parts, but these are early days and that could change. IAR and SEGGER both have tool chains; IAR sent me a board with this processor which I haven't had a chance to fiddle with yet.

Charles Manning has been thinking about this:

Recently I've noticed a storm of RISC-V hitting the market place and it's looking like a change might be coming.

ARM has pretty much killed the bespoke processor space in everything embedded. There is very little motivation to use non-ARMs for anything unless you're really chasing cost and are prepared to use those 3 cent 8-bitters.

But ARM still controls the IP and limits what people can do - as well as charge an arm and a leg for licensing. Concerns over ARM ownership will make this worse, as too will international players worrying about ARM embargoes etc.

This seems to be fanning the RISC-V fires a bit for reasons beyond just technical.

I've been looking at RISC-V architecture recently and it certainly seems to have various wins in terms of performance per W.

This year there has been a wave of new vendors offering RISC-V products. Many are in China, but the mainstream vendors are also getting involved with parts from NXP, Microchip and others.

There's an astounding AI processing module that costs less than $20 (indeed $20 or so buys a dev board, complete with camera and display). This thing has a dual core 64-bit RISC-V + the funky AI processor.

In the soft-core space, people are reporting getting better performance from RISC-V implemented in generic RTL than tweaked and customised vendor-provided cores (eg. Microblaze for Xilinx).

I have a feeling this RISC-V stuff is really going to take off over the next few years, but who knows in this crazy industry of ours.

What do you think?
Design Margins

A recent article in Embedded Computing Design titled "Undervolting for Embedded Systems to Improve Energy-Efficiency" does a real disservice to the EE community. It describes successful efforts to run FPGAs at voltages lower than those specified by the vendors. The probable takeaway, especially for younger engineers not yet seared by the slings and arrows of real world experience, is that one can get some goodies (lower power) by neglecting the datasheet.

To be fair, the IEEE article from which this is derived does state "The aim of this paper is to experimentally understand the power and reliability trade-off of commercial FPGAs under aggressive low-voltage operations and its impacts on a FPGA based NN accelerator." Running experiments to increase understanding is admirable. But to take that research and promote it as a possible solution to an engineering problem in a trade magazine strikes me as a disservice to the engineering community.

When I went to college we learned that there were equations one used to, for instance, bias a transistor. Run the numbers, and then buy a 2.894k resistor and voila! The circuit will work.

The professors never addressed other aspects, like you can't buy that part. Or that the gain of particular transistor's part number can vary by insane amounts.

Nor did they talk about design margins, possibly one of the most important aspects of all engineering. What happens if that 3.0V supply is actually 2.9V? Or that 10K resistor is at the end of its tolerance band? Oh, and do the students even learn that a gold band means 5%?

My dad, a mechanical engineer, told me that in the 1950s he was working on the F-11F at Grumman. In a test they could not break the tail section. The Navy was upset as the extra strength meant extra weight. When a tail antenna finally snapped the government acquiesced. The tail had, in this case, too much design margin.

Would you want to fly on a plane with too little?

One of the FPGAs the authors investigated has a Vcc spec of 1.0 V +/- 0.05. The study ran it successfully at two-thirds of that. Interesting? You bet. A good idea? Not for most designs.

In my opinion, a fundamental sin in this field is running a part outside of the rated specifications. Yeah, a gamer might immerse a CPU in liquid helium to run it at crazy clock rates, but do that in a real product and you can expect howls of anger from your (former) customers.

As a young engineer a mentor drove me mad questioning all of my design decisions. Why did I specify a 1K pullup? Did I consider the gain-bandwidth product of that op amp when the input frequency is near max? What happens to my PID loop if interrupts happen? But he was right, and his incessant badgering made me a better engineer.

A friend recently sent me an interesting circuit from a hacker forum. I guess it worked, more or less. Probably some enthusiastic high school kid came up with it. But it was riddled with flaws. On a bench it probably functioned. Make 10,000 copies deployed in the arctic and at the equator, probably not. Hacking is not engineering, whether we're talking about software or hardware design. Engineering is about making something that will work reliably. That includes following the datasheet specifications to the letter, and then adding more margin when possible.

For you older folks, perhaps one of the best things you can do as a mentor is to be that nag. Politely, of course, but insistently.

Failure of the Week

From Nathan Menhorn:
This Week's Cool Product

Not the Pluton chip

I'm not sure how cool this is, but the big semiconductor vendors are planning to integrate Microsoft's ridiculously-named Pluton chip into their CPUs. From the article: "Microsoft said that the Pluton chip would be integrated as a secure subsystem inside the SoC, adding another layer of protection on top of the internal defenses designed by Intel, AMD, and Qualcomm. The chip establishes a protected area that is physically secluded from the CPU, acting as a vault in charge of protecting secret keys and other information in the PC."

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

These jokes are archived here.

In the last issue the joke section had definitions of various tools. J.G. Harston sent in this alternative one for "hammer": a Birmingham screwdriver:
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.