Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 375, June 3, 2019
Copyright 2019 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

Express Logic

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

Quotes and Thoughts

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

Tools and Tips

SEGGER emPack The complete OS for embedded systems

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:

I got annoyed at that myself, and I like to put in something slightly different.  Instead of one pad to solder a lead to, I put two pads and solder in a little hoop of wire (resistor lead off-cuts).

Think like a little croquet hoop:

Ground reference point

It has several advantages:

  1. The clip doesn't twirl around it (as much)
  2. It doesn't stick up very far (well, if SMT, it does)
  3. It's much stronger than one wire
  4. It doesn't get accidentally bent over something important
  5. It's cheap...

Paul Carpenter also had thoughts:

A particular bug-bear of mine is this one. I typically use something like this:

Ground reference hook

Drill a 1mm hole, on production leave the part off and the hole there. Typically on a Eurocard size board (100 x 60 mm) I will put at least 4:

  • One in each corner
  • If possible one in centre
  • All power rails have one, for quick power rail checks meter or scope
  • Common clocks
  • SPI/I2C bus signals
  • ANYTHING that requires measurement as part of test/setup/calibration

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.

Freebies and Discounts

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.

Joulescope for giveaway

Enter via this link.

Regulation of Connected Devices

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:

1798.91.04. (a) A manufacturer of a connected device shall equip the device with a reasonable security feature or features that are all of the following:

(1) Appropriate to the nature and function of the device.

(2) Appropriate to the information it may collect, contain, or transmit.

(3) Designed to protect the device and any information contained therein from unauthorized access, destruction, use, modification, or disclosure.

(b) Subject to all of the requirements of subdivision (a), if a connected device is equipped with a means for authentication outside a local area network, it shall be deemed a reasonable security feature under subdivision (a) if either of the following requirements are met:

(1) The preprogrammed password is unique to each device manufactured.

(2) The device contains a security feature that requires a user to generate a new means of authentication before access is granted to the device for the first time.

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.

Seeing Signals

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.

A siglent SDS5034X next to a Tektronix MSO5

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

Firmware's Stability as a Feature

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

Here's something I've been thinking about, about the place of embedded systems in the world.  Basically: Machines last longer than general-purpose computers and need more long-term stability.  What runs this year still needs to run 15 years from now.

As you may know, I'm an avid amateur astronomer (www.dslrbook.com).  To take long-exposure photographs, we use digitally controlled motorized telescope mounts to track the stars against the earth's rotation.  But the motors and gears aren't perfect, so it is customary to "autoguide," using a second small telescope mounted on the main one to watch a star with a CMOS camera and issue tiny corrections to the motorized drive system.  That way, irregularities in the gears are smoothed out, and even unpredictable changes can be corrected (e.g., gradual bending of some part of the system as the load shifts).

The usual way to autoguide is to use a laptop PC connected to the autoguiding camera and the mount.  This allows us to use very sophisticated (and constantly competing) software and experiment with control algorithms.

But this little gadget is in the early stages of taking the world by storm, though it's not yet marketed in the US.  I don't have one yet, but give me three months...

The underlying idea here is to use a small handheld box (with enough computing power in it) rather than a PC.

Besides compactness, it has another advantage we should think about: its OS and firmware aren't going to change except when we change them.  The telescope mount and autoguide camera, and their own firmware, don't change, so we don't want the autoguide controller to change either.  Machines last longer than PCs and need more long-term stability.  Some telescope mounts are now entering the market that require a Windows PC for at least the initial setup at every session, and most of us view that with deep trepidation.  In 20 years, the mechanism will be just fine, but will computers exist that can talk to it?  If so, what will we need to do to get the software for it?  What if the manufacturer "orphans" the product?

The big down side of using a PC is that every three months it's different.  Unless the PC is reserved for just this use, it's constantly getting OS updates and updates to other software that might interact with autoguiding.  One notorious Windows update, a few years ago, temporarily killed all direct access to video cameras from software.

So I am looking forward to autoguiding with a small special-purpose handheld computer rather than a PC.  It's just like the reason I don't control my microwave oven with my PC, even if theoretically I could.  The embedded system needs to serve a specific purpose and be stable.  It does not need to interoperate with every digital device in the world!

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

This Week's Cool Product

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.

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 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"

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.