You may redistribute this newsletter for non-commercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go here or drop Jack an email.
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.
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|
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.
|Freebies and Discounts|
I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.
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:
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.
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:
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...
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.
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 email@example.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 firstname.lastname@example.org for more information.