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
• Freebies and Discounts
• Regulation of Connected Devices
• Seeing Signals
• Firmware's Stability as a Feature
• This Week's Cool Product
• Jobs!
• Joke for the Week
• About The Embedded Muse

Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes.

Attendees have blogged about the seminar, for example, here, here and here.

Jack's latest (off-topic!) blog: On Cataracts

From Luis G. Uribe: "Engineering is the art of modeling materials we do not wholly understand, into shapes we cannot precisely analyze so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance" A.R. Dykes, Scottish Branch, Institution of Structural Engineers 1946

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

Ian Stedman responded to my thoughts on providing ground test points in Muse 374:

Paul Carpenter also had thoughts:

Is Moore's Law dead? I've heard predictions of it running out of steam for 20 years. But there are physical limits, and before we hit those financial concerns may make further shrinks uneconomical. A lot of work is going on in 3D chips. An interesting article about stacking dies is here. Another here. And now TSMC is using 13.7 nm X-rays for the 5 nm node. But, one wonders what "5 nm" really means? It has been a long time since the nominal node really meant much.

Phil Koopman has an interesting article about the ethics of self-driving cars here.

The fine folks at Joulescope are making one of their Joulescope energy meters available for the June giveaway. I reviewed it here. It samples an astonishing range from 1.5 nA to 3A, with short bursts to 10 A at 2 mSa/s.

Enter via this link.

If you're building a device connected to the internet and not actively considering security, well, that will change. As I wrote in Muse 342, Europe's General Data Protection Regulations are now in force and fines can be as high as 4% of yearly gross receipts - billions for big companies. It applies to all businesses selling into the EU, regardless of whether they have an office on the continent. I have no idea how a fine can be collected from a company outside the EU, but Google has already been hit with a €50m fine (which they are appealing).

Yet most of us neglect security. According to various surveys only 10 to 20% of embedded teams consider it. A lot of companies have scary amounts of exposure.

California passed a law that goes into effect January 1, 2020 mandating security for all connected devices. And as California goes, so goes the nation. The meat of the regulation is:

I'm not sure how one protects a device from "destruction" other than mandating it lives inside a vault. And "reasonable security" isn't defined. Figure on plenty of business for legal firms. This law will affect the entire country, as it doesn't make much sense to sell both a California and "the other 49 States" versions.

The non-profit IoT Security Foundation is dedicated to improving security. They offer a mark companies can put on products to assure customers the device is indeed secure. However, the mark is obtained through self-certification so isn't particularly compelling. They do offer a number of free publications on the subject that are worthwhile.

There are rumblings (grumblings?) in Congress of a federal IoT security law. Since pretty much nothing passes in this session I expect it to fail. But you can be sure similar bills will appear in succeeding years. We're pretty good a legislation by catastrophe, so at some point after yet another massive breech consumers will demand action.

The honeymoon is over. It's time to get serious about securing the connected products we design.

I often review oscilloscopes in the Muse, as a scope is a vital hardware/firmware debugging tool.

What do you want in an oscilloscope? Sure, bandwidth, sample rate, memory depth and many other features are important. But the one thing we really want, the meta-feature of scopes, is to see the signal. All of those features contribute to visualizing a waveform. Yet since the dawn of electronics scopes were poor-to-adequate in presenting acquired data. Half a century ago I knew an accomplished inventor who had a scope with a 1" CRT. How much can you see with that? Most of us grew up with 5" CRTs. Often the scope's panel had five to ten times the area of the display for knobs and controls.

That's changing. Displays are getting bigger. They now occupy most of the panel space.

Siglent sent me their latest version, the SDS5034X, which has a huge 10" screen. It's fantastic as you can put a ton of info on the display. A review will come soon.

A few days later a friend came by with his latest purchase, a Tektronix MSO5. This enormous scope is 309 mm high, 454 mm wide and 297 mm deep. It's a monster that eats a big portion of a bench. But it's all screen, with a nearly 16" display.

On the left, the huge 10" screen of the Siglent SDS5034X. On the right, the all-screen Tektronix MSO5. The Siglent is a very big scope. The Tek is a monster.

Most scopes have more or less similar features, and if you've driven one you can handle any other. The MSO5 is a complete re-think of oscilloscopes. I couldn't figure out how to use it, at first, as the UI is so different from any other scope. You drive it with a mouse, and it's really a computer with a fantastic data acquisition system. Like a desktop PC, you can have multiple windows, which can be moved and resized. Want one for a couple of analog channels, another for the FFT, and a few more for the protocol decoders? No problem.

Every interaction between engineer and instrument is different from every other scope, and is generally an improvement, facilitated by an honest windowing system and the mouse. We only played with it for a few hours, not enough time for a review, but I salute Tek for a very new approach to scopes.

(This is not to compare the two products, as the Tek is almost 5 times as expensive as the Siglent).

Michael Covington had some thoughts about the stability of firmware vs. PC operating systems:

One only has to read the news to see more of this. The US's move to cut Huawei's access to Western technology means they will (unless things change) be somewhat adrift with regards to Android. They've also lost access to new Arm IP. One wonders about the future of reuse when reuseable components can be made unavailable by governmental fiat. (Don't fall into the trap of thinking Huawei is just a copycat Chinese tech company; they have pretty amazing IC design and fab capabilities.)

CodeLingo purports to be a tool that inspects and improves your code. It sounds intriguing, though the website, like so many others today, is long on whitespace and short on details. It sounds like it does some level of code inspection and even refactoring.

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

From Carl Smith:

How Much Does Your Software Weigh?

I am reminded of a story told to me by Professor Claire Cardie of the AI laboratory at Cornell University. She was once involved in a team to develop guidance software for the space shuttle.

NASA required every project developing technology for the shuttle to determine how much its contribution weighed. For weeks, Claire's team insisted that its software didn't weigh anything!

But NASA didn't buy it. One day, someone proposed that they could store the software on old-fashioned punch cards, and weigh the resultant stack of cards (that weight would still be insignificant compared to the weight of the space shuttle). But then someone pointed out the problem with that approach: the software doesn't consist of the cards, it consists of the holes.

Ultimately, it was decided to simply enter the smallest weight NASA would allow

Source: Page 38 of "Bug Patterns in Java"

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.