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.
We're presenting a public version of this seminar in Denmark, Sweden and Finland:
There's more information here.
Jack's latest blog: Goto Considered Necessary.
I'm on Twitter.
|Quotes and Thoughts|
In writing code and prose, it is sagacious to eschew obfuscation.
|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.
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.
|Freebies and Discounts|
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.
|Performance of the Arm Cortex M Floating Point Unit|
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:
32-bit floating point with the FPU:
64-bit double without the FPU:
64-bit double with the FPU:
A couple of interesting points:
A couple of more data points:
sqrt() (the FPU does have a sqrt function):
cos() (the FPU has no support for trig. Also note that I limited the range of arguments to zero to 2π):
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"
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.
|The Fourth Law of Robotics|
75 years ago Isaac Asimov defined the now famous Three Laws of Robotics:
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:
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 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 With Us|
Advertise in The Embedded Muse! Over 29,000 embedded developers get this twice-monthly publication. For more information email us at email@example.com.
|About The Embedded Muse|
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
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 email@example.com for more information.