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
• Performance of the Arm Cortex Floating Point Unit
• Software Warranties
• The Fourth Law of Robotics
• Jobs!
• Joke for the Week
• Advertise with us
• 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.

We're presenting a public version of this seminar in Denmark, Sweden and Finland:

• Aarhus: May 10, 2019
• Copenhagen: May 14, 2019
• Stockholm: May 16, 2019
• Helsinki: May 17, 2019

There's more information here.

Jack's latest blog: Goto Considered Necessary.

In writing code and prose, it is sagacious to eschew obfuscation.

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

James Wilson has created a nice setup to add voice control to Keysight oscilloscopes with the use of a Raspberry Pi. Here's the repo for the code and this is a video about it.

I believe that operating FETs in the subthreshold region will become very important for ultra-low power digital electronics. Here's a recent article about this.

Courtesy of the fine folks at Keysight, this month's giveaway is another of their brand new $2200 DSOX-1204G bench 200 MHz 4-channel scopes, which I reviewed here:

Enter via this link.

The optional floating-point unit available on ARM Cortex M4s and above is a nice feature, but what does it really do for you? It's a 32-bit FPU; do compilers run some special magic to take advantage of it when doing double-precision math?

I thought it might be interesting to run some experiments. The numbers are going to be more useful in terms of comparing operations to each other, rather than as an indicator of absolute execution times, as the Cortex processors vary widely in caches, tricks for flash access speedups, and the like, so take these with a grain of salt. These are on an M4F running at 120 MHz with no cache and one wait state, interrupts off. The IAR compiler and IDE did the heavy lifting.

The "size" figure is the relative size of the executable compared to 32-bit float addition with the FPU disabled. Some of the size numbers are a bit hard to understand. The executable was about 15 KB, so some sort of compiler variability may have been at play.

In many cases I found a range of execution times, as the experiment used tens of thousands of randomly-generated numbers for the arguments.

32-bit floating point without the FPU:

• Addition: 181 to 321 ns depending on the arguments. Relative size: 0 bytes
• Subtraction: 181 to 321 ns depending on the arguments. Relative size: 12 bytes
• Multiplication: 259 ns regardless of arguments. Relative size: 0 bytes
• Division: 458 to 533 ns depending on the arguments. Relative size: -20 bytes

32-bit floating point with the FPU:

• Addition: 17 ns regardless of the arguments. Relative size: -786 bytes
• Subtraction: 17 ns regardless of the arguments. Relative size: -786 bytes
• Multiplication: 17 ns regardless of the arguments. Relative size: -786 bytes
• Division: 83 ns regardless of the arguments. Relative size: -786 bytes

64-bit double without the FPU:

• Addition: 293 ns to 745 ns depending on the arguments. Relative size: 488 bytes
• Subtraction: 290 ns to 703 ns depending on the arguments. Relative size: 488 bytes
• Multiplication: 525 ns to 533 ns depending on the arguments. Relative size: -100 bytes
• Division: 1035 ns to 1329 ns depending on the arguments. Relative size: -100 bytes

64-bit double with the FPU:

• Addition: 293 ns to 745 ns depending on the arguments. Relative size: -310 bytes
• Subtraction: 290 ns to 703 ns depending on the arguments. Relative size: -310 bytes
• Multiplication: 525 ns to 533 ns depending on the arguments. Relative size: -898 bytes
• Division: 1035 ns to 1329 ns depending on the arguments. Relative size: -898 bytes

A couple of interesting points:

A couple of more data points:

sqrt() (the FPU does have a sqrt function):

• With the FPU: 5.06 µs to 5.18 µs depending on the arguments.
• Without the FPU: 4.95 µs to 5.05 µs. The compiler generates a call to a different runtime routine, but the FPU does a 32-bit sqrt(), and the C standard requires sqrt() to use doubles.

cos() (the FPU has no support for trig. Also note that I limited the range of arguments to zero to 2π):

• It executes in 254 ns with an argument of zero.
• With the FPU: 11.4 µs to 18.6 µs depending on the non-zero arguments, with a mean of 17.4 µs.
• Without the FPU: 10.8 µs to 18.0 µ depending on the non-zero arguments, with a mean of 16.8 µs.
• In both cases, if the argument is over π/4 radians the execution time will be 17 to 18 or so µs. Under π/4 and it's around 11 µs. I suspect that the runtime library reduces all cosine arguments to the range π/4, a standard way to compute this function. If the argument is already in that octant of the circle, the range reduction isn't needed and things are speedier.

It's puzzling that cos() runs slower with the FPU than without. I rebuilt the code and reran the test several times but consistently got the same results.

The FPU's 32-bit performance is truly remarkable. I wonder if some clever algorithm could take advantage of it for some amount of speedup of double-precision math.

In a brilliant 168 page report called "Software for Dependable Systems: Sufficient Evidence?" (available here) the authors take a stab at much Commercial-Off-The-Shelf (COTS) software: "Clearly, no software should be considered dependable if it is supplied with a disclaimer that withholds the manufacturer's commitment to provide a warranty or other remedies for software that fails to meet its dependability claims."

Ouch. What application software comes without such a disclaimer?

Some might argue that so much COTS software is so complex that such disclaimers are inevitable. I suspect vendors worry more about prospective lawsuits. Yet cars come with warranties, and a failure, say of the brakes, could result in plenty of liability.

A TV comes with a strong warranty. Tools do as does just about any physical product. My Stihl chainsaw - talk about a product that can wreak injury! - has a warranty. I can buy something from most reputable vendors and return it, no questions asked. If it causes damages, the usual remedies are available. What's different about software?

The disclaimer that comes with software is the total antithesis of a warranty. That disclaimer typically disavows every guarantee other than the integrity of the media. That's like claiming the cardboard box that a computer ships in will function properly, but if the computer doesn't work or bursts into flames it's the consumer's problem.

Open source programs fare no better. Provision 15 of version 3 of the GPL reads (in all caps just as shown): "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION."

Certainly there are very good reasons for this provision, not the least is that holding a series of authors legally accountable will remove any incentive to contribute to the community.

But if software should only be considered dependable only if it comes with a strong warranty, GPLed code fails the test as miserably as software from the most difficult of proprietary code vendors.

In the PC industry this may not be much of an issue. Firmware is different. We provide a component of a product (say, the code that runs an engine control unit), and that product certainly will have a warranty. Building a guaranteed product out of un-guaranteed, or un-guaranteeable, components is as absurd as constructing a rigid skyscraper from packets of Jello.

What about the firmware we acquire? Most semiconductor vendors provide code for their microcontrollers. Here's part of a header for some driver code from an MCU vendor:

* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.

There are some bright spots. HCC-Embedded, for instance, sells a various firmware components. Their web site states "We warrant that all of our software will operate correctly". Express Logic's products have been acquiring certifications to safety-critical standards faster than Michael Phelps gathered Olympic medals.

The facts are stark. Users demand ever more functionality. Firmware grows at a staggering rate. More of us are turning to COTS to get this added functionality in a reasonable timeframe. But most COTS vendors offer only the weakest warranties.

I suspect winners in the COTS business will be those who offer solid warranties backed up by proofs (e.g., certifications). While expensive, that will be a cost of doing business as developers get more demanding from the vendors.

75 years ago Isaac Asimov defined the now famous Three Laws of Robotics:

1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
2. A robot must obey orders given to it by human beings except where such orders would conflict with the First Law.
3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

When he wrote the I, Robot stories the word "robot" viscerally meant to John Q Public a mechanical being which invariably looked human. Indeed, that perception lived even into Star Trek: Data not only looked entirely human, he grappled with emotions.

But with the advent of inexpensive computing "robot" no longer means a human-like machine. The car's cruise control is a form of robot; the agents that scour the net are called "bots," and mail-delivering robots roam the halls of the Pentagon and other buildings. They look more like filing cabinets on wheels than Data. So I think it's reasonable to substitute "computer" for "robot" in the Three Laws.

And it's time to add a Fourth Law:

4. A computer may not piss off a human, as long as such behavior doesn't conflict with the first, second or third laws.

For example, I was on a long flight recently and the seatback TV screens were behaving badly. They reset constantly. They'd freeze. The flight crew cycled power a couple of times and eventually the units started running reasonably well.

But I wanted to sleep so turned my unit off. Abid, seated to my right in 31H, also flicked his unit off. We each reclined.

And, minutes later, both screens came back on. We turned them off, and they came on again. And again and again.

Abid 31H and I shared only the universal language of annoyed computer users, so could merely point at these poorly-implemented devices and laugh. The screens won, we lost, and on they stayed while the Lunesta finally kicked in.

Embedded computers are unlike any other devices on this planet. Other engineered products respond to a user's actions: the car follows inputs into the steering wheel and pedals. Lights go on when we throw the switch. But a computer does the commanding; it uses both inputs and a set of rules defined by a programmer to control something. Though I have no idea how to actually build Laws into firmware, I can't help but think these products could use some sort of analogous meta-guidance. In Asimov's stories the Laws are somehow distinct from, and above, the programming details, just as the Ten Commandments supersede the hundreds of thousands of pages of extant law and precedent that guide judges.

Redefining the Four Laws using "computer" instead of "robot" moves the responsibility for conforming to the Laws to the designers rather than to the robots. It's up to us to build systems that are safe... and that don't piss off our users.

Possible Fifth Law:

• Don't leak any human's private info
• Delight your human master
• Fulfill your human master's expectations
• Procure the winning lottery ticket

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 Ian Paull:

A man goes into a bar and orders 1.00000000009 root beers.

The bartender says "I will have to charge you extra for that, because it's a float."

The man responds "In that case, you might as well make it a double!"

Advertise in The Embedded Muse! Over 29,000 embedded developers get this twice-monthly publication. .

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.