You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
After over 40 years in this field I've learned that "shortcuts make for long delays" (an aphorism attributed to J.R.R Tolkien). The data is stark: doing software right means fewer bugs and earlier deliveries. Adopt best practices and your code will be better and cheaper. This is the entire thesis of the quality movement, which revolutionized manufacturing but has somehow largely missed software engineering. Studies have even shown that even safety-critical code need be no more expensive than the usual stuff if the right processes are followed.
This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.
(I had an incorrect link to this white paper in the last Muse. This one is correct).
|Quotes and Thoughts|
"It is not necessary to change. Survival is not mandatory." - W. Edwards Deming
|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 read Steve Leibson's Xilinx-focused blog every week. In it he recently referenced a new book about the Zynq FPGA. Adam Taylor has been exploring the Zynq and writing about his experiences. The book is a compendium of his journey and is a must-read for those interested in this device. It's only $7.50 in a Kindle edition. I bought it and am impressed: it's well-illustrated and covers a lot of material. The Zynq has twin Cortex A9s, FPGA fabric, and a lot of I/O. Adam covers both hardware design side and software.
Security talk is hot today; security engineering less so. Scott Romanowski offered a resource:
David Meekhof suggested checking out Unity for building tests:
More people have suggested screen capture tools. Amir Marandi wrote:
Les Hildenbrandt suggests a built-in tool:
John Johnson suggested:
Diego Serafin suggests a different sort of tool for pasting:
Richard Tomkins had four suggestions:
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.
In the last Muse I wrote about the notion of "done" in projects. Readers had comments. Phil Matthews wrote:
In high school I had a friend who was a brilliant cartoonist, usually on the blackboard (remember them?). Whenever he did a cartoon he would first stare at the space where the drawing would go for several minutes, then quickly draw in the lines accurately and perfectly. The first draft was the finished article. I asked him about this once and he told me, "I do the cartoon completely in my head first and then project it onto the paper. When I'm drawing I'm just tracing the lines".
There is a similar story in "The Shipping News", where the main character, Quoyle, commissions a boatbuilder to build a small wooden boat for him. After several visits he is dismayed to see no progress, nothing even started. The boatbuilder assures him the boat is nearly finished, in his head. Once the boatbuilder is satisfied with every detail, he starts shaping the wood and boat goes together very quickly. (I thought you might appreciate that Jack, since you are a sailing person).
I believe this way of thinking has merit for writing software, although from experience I know it is hard to justify a lot of time with no obvious output to managers. It doesn't mean you don't do testing. However, when it comes to testing, the software is more likely to work first time and have fewer bugs. The other extreme is continuous hacking and testing with plenty of output but no clear definition of when it is finished (been there, done that too!).
Howard Speegle contributed this:
Like the programmer you mentioned, I also like to work out everything in my mind before coding and the path between knowing what to do and actually walking the defined path can be tedious, as you noted.
However, you also dropped a comment about management "lopping off" some of the schedule. In my experience, most employees do their best to estimate the time it will take to do something based on their estimate of the degree of complexity involved and the amount of new knowledge that will be required. This is the estimate they give to management. It does not include "Oh, by the way"s or the frequent, "Could you work this in for me?", and certainly not the "lopping off" bit.
When the schedule extends past the calendar date management has passed on without adjusting for past history regarding the lack of correlation between that individual's estimates and actual calendar days spent since start of the project, guess who is blamed? For some reason, many managers appear to think that programmers can be forced to be more productive through clever manipulation by management. They also seem to share the curious notion that they can ask for additional tasks to be completed during the project that will not affect the time required to complete the project.
Some of the worst examples of this idiocy I have encountered were practiced by some of the same people who had experienced the problem from the other end. Perhaps our concepts of management and labor need to be re-examined?
Every manager needs a sign on his office wall that reads, "No problem" does not mean that it will not require time and money to implement your request. It simply means that the person sees no technical difficulty in complying.
Daniel Wisehart uses some agile ideas:
On "Is it Done Yet?" I feel the pressure--and shame--from making bad time estimates myself and I now see people who work for me painting themselves into the same corner.
Automated testing would be helpful but a lot of testing software has more bugs than the DUT, simply because the testing software is thrown together fast and dirty. Much of the debugging we do when a test shows errors, is figuring out that the test gave the wrong inputs or expected the wrong result.
What I find helps a great deal is pulling the question back to a scope and a timeframe where an engineer can see all of the factors involved: "What can you deliver this week?" and "If that goes well, what can you deliver next week?" Then it is up to me to see the rate at which we are making progress, the difficulty of the tasks ahead and be the fool to estimate the time until task completion, but only with the details of how I arrived at that estimate. Since my company does a good bit of research, the people asking for the estimates have to understand the consequences of not even knowing yet what all of the difficulties are.
Responding to some comments in Muse 279 about discipline in software engineering, Chris Hills wrote:
I have to agree with the comments on discipline in the newsletter.
In particular those by Dave Telling. I too had a technical military background as did my father who was involved in the design of aircraft jet engines, who also said that discipline was one of the most important traits in design. Short cuts in jet engine design could be fatal! Having discipline makes life a lot easier as many things can be done properly and automatically. Couple this with a good process and things become very efficient; things just work and you get fewer errors (bugs).
As for his comments on MISRA-C: Overall they [the MISRA-C rules] work. He mentioned relaxing some of them. Yes this is required! There are only 10 Mandatory rules. The MISRA-C team recognised that not all the rules are appropriate 100% of the time in fact my first conference presentation after the launch of MISA-C:2012 was Why MISRA-C might kill your project!
It is because many just see MISRA-C as a tick box and do not apply it with care, relaxing rules (with written justifications or deviations) as needed. If you apply 100% of the MISRA-C rules 100% of the time you get MISERY-C but you have only yourselves to blame. This second paper does explain how to implement MISRA-C: http://www.safetycritical.info/library/presentations/MISRA-C3-0002.pdf
One of the main problems is no one really understands C. I covered this in the presentation MISRA-C Curse or Cure:
I have not seen a survey or study about how developers learned C, but admit to having a copy of K&R here, in addition to many other books about the language. Chris is right about the standard; few software engineers I've talked to have a copy of any of the C standards.
The C standards are outrageously expensive and drearily dull. They are available on-line for free from some sites, but I don't know if these infringe a copyright. Wikipedia links to drafts that are very close to the final versions; for instance, a draft of C99 is available here. Though they are impossible to read straight-through, it's useful to look at different sections from time to time to improve your skills.
Some argue that they write with a simpler subset of the language to avoid corner cases that a language lawyer might use. I agree; for example, code is clearer when parenthesis are used instead of the arcane precedence rules. Some things might surprise, though. Do you know why the following probably won't work?
if ((i >= 0) || ((i++) <= value)) /* code */;
C99 standard explains why: the logical OR operator will not evaluate the second part of the decision if the first part is TRUE, so the postincrement won't happen.
This is a big area for me. I think too often the entire Computer Programming Field (Software Engineers, Programmers, etc) view it too much as "art" and therefore write off anything related to "discipline" as interfering with the "art". Thereby, it only perpetuates the problem. The challenge is that I think the field needs to simply "grow up" and mature. The field - in all forms - is relatively new compared to any other similar field, even Electrical Engineering, it's closest relative and sibling. Developers need to realize that it is not an "art"; but it's a disciplined, pragmatically driven field where code-styles need to be enforced, and if you don't like it, then oh well, get in line and do the job; where code logic structures need to be done and enforced such that best practices are performed and bring out the best software with deterministic outcomes and nothing is left to chance. And the list goes on. I've probably written to you about this prior as well. Sadly it will probably be another several decades before these things really come to pass; and sadly too often we just limp about when we could be fixing the broken bones in our collective bodies of software.
John Hart's Computer Approximations is my go-to source of polynomial coefficients for all sorts of mathematical operations. Michael Taylor has some useful thoughts:
The book Computer Approximations by John Hart is available as a reprinted edition from Krieger Publishing, ISBN-10:0-88275-642-7 ISBN-13: 978-0882756424 and Amazon. The reprint is dated 1978, rather than 1968 for the original Wiley printing. It apparently contains some (minor) corrections. The biggest benefit is besides being cheaper than used copies of the original edition in many cases, it is printed on acid-free paper so hasn't turned yellow, and as still available
That all said, I would suggest anyone wanting to learn about computing approximations techniques would be better served by Elementary Functions: Algorithms and Implementation 2nd ed. by Jean-Michel Muller (2005) which gives a state-of-the-art perspective, yet is still largely accessible to the software professional without an advanced mathematics background. Given that it is nearly half the price (~47 USD at Amazon) and far more up-to-date discussing contemporary processors and operating systems it is easy to recommend as a very suitable alternative or rather replacement to Hart's Computer Approximations. It is more theoretical than Hart, but given the availability of freely available (and often multiple public domain) implementations of varying quality in this age, the understanding is perhaps more scarce than the techniques or implementations.
Jean-Michel Muller, also has a second related but different book on floating point arithmetic itself, Handbook of Floating-Point Arithmetic (2009). This is the best technical background on floating point mathematics that I know of. It also is one of the few detailed written explanations on floating point numbers, arithmetic, and techniques that covers that revised IEEE 754-2008 floating point specification. It also covers floating point arithmetic in hardware, though at the theoretic, rather than concrete level (it is not a Verilog/VDHL cookbook of techniques). Highly recommended for anyone in scientific programming or needs to really understand floating point calculations.
The description of Elementary Functions sounds wonderful, and I have ordered a copy.
A reader who wishes to remain anonymous complained about a job posting in the last Muse:
We in the embedded systems world are used to what I call cross-domain job requirements. The job posting in Muse 280 is an example of cross-domain job requirements.
In in the embedded systems we blend technologies from electrical engineering, mixed signal, high-speed digital, VHDL, software design aka firmware, PCB layout with balanced impedance traces, RF, etc. And this blend of cross domain skills is sometimes executed well.
Though from an IT / software perspective, this article and the comments which follow illustrate this trend.
Re: excerpt from job posting for a web developer
A quote about job descriptions from that article got my attention: "Managers just don’t have the time to put them together."
I'd argue that the most important role of a manager is in finding, retaining and motivating people. A manager without time to put a job description together is simply not doing his or her job.
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 intents of this newsletter. Please keep it to 100 words. There is no charge for job ads.
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Kevin Clark sent this amusing screen shot:
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at email@example.com.
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.