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.
Wouldn't you want to be in the top tier of developers? That is part of 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.
Mat Kramer won the Siglent SDS1204X-E oscilloscope in last month's contest.
|Quotes and Thoughts|
"Digital? Any idiot can count to one." Bob Widlar, famous (and quirky) analog designer
|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.
By the way, did you know the original title of that publication was Dr Dobb's Journal of Computing Calisthenics and Orthodontia (Running Light Without Overbyte)? It started as a quirky newsletter by the People's Computer Company (it was 1976, after all), and as the readers matured into professionals, it did as well. The first year's compendium is rather fun. It includes code for a Tiny Basic interpreter that needed just a couple of kB of memory; to achieve that remarkable goal the interpreter was written in a custom interpreted language. So a Basic program was interpreted twice as it executed. Very clever idea in an era when memory was in scant supply. It's copyright notification was: "@COPYLEFT ALL WRONGS RESERVED".
|A Reason For Automatic-Reboots|
Kevin Hess had some interesting comments about a router that routinely reboots itself:
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
While the news is full of stories of software disasters, it is instructive to look at successes, and nowhere is there more success than in avionics. DO-178C (AKA ED-12C in Europe) is the standard to which commercial avionics is developed. It's quite arcane. Leanna Rierson's book Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance is the best guide I've found for demystifying the guidelines. DO-178C stresses developing accurate requirements and then insuring that every requirement has associated tests, and no code exists for which there is no requirement. Traceability from requirements to low-level code is a must.
In her book Leanna spells out the characteristics of a well-thought-out requirement. She has kindly allowed my to cite her work:
Good requirements do not just happen. They require considerable effort, focus, and discipline. To write good requirements, it is important to understand the characteristics of such requirements. Requirements authors and reviewers should incorporate the following characteristics of good system requirements:
I'm often asked about developing requirements. Karl Weigers' Software Requirements is an excellent resource.
I'm an advocate of collecting and analyzing metrics in firmware engineering. After all, engineering is about three things:
- Predict what is going to happen.
- Make it happen.
- Measure to see if it really happened the way you expected.
Leave off the third step and this is art, not engineering.
We have a lot of quantitative information about the nature of good code which should guide our development. And, there are a lot of great tools available for collecting the metrics. One of my favorites is a freebie called SourceMonitor by Campwood Software. You aim the tool at your source code and you'll get a screen like this:
The top window shows up first and gives numbers for the entire project. Double-click on that and the bottom window appears, which breaks things down by source file.
Some of the numbers are self-explanatory. Others include:
- Average statements/function - well, that's pretty obvious, but is important as we know, in general, that we should restrict functions to about 50 lines of code.
- Max Complexity is the cyclomatic complexity of the most complex function in the file. Ten to 15 is a good upper bound.
- Max Depth is the most deeply-nested block in the code. Steve McConnell believes three is a good limit; other authorities will allow five. But the 7 in manage.c means one of the functions is too deep for mere mortals to grok.
- % Comments is the percentage of non-blank lines that are comments, or that have comments. In Measuring Software Quality: A Case Study, Thomas Drake studied 30 million lines of code at NSA and found that the best code with the fewest problems averaged 60% comments. To quote from the paper: "This may raise some eyebrows, but NSA has a huge base of legacy code, some of which has been running for decades."
Click on one of the files and this appears:
This makes it easy to drill down and see where the problems are in the file.
Another option is to examine details about one of the files to get statistics about each function:
Double-click on a function name and an editor appears with the focus on the selected function.
The program is small and very fast. One annoying "feature" is that it doesn't remember what directory you've been in, and every time it starts you have to navigate from the Program Files directory to your code. It's for Windows only. Recommended.
Somehow I missed this when it came out a while ago. Express Logic, which sells the ThreadX RTOS, has a feature called "Modules." With most RTOSes one must link the entire product's code together as one executable. That's rather different from using, for instance, Windows, where many applications can be loaded and unloaded from memory. With Modules a deeply-embedded system can have the same sort of functionality. Applications can be built independently from the RTOS and loaded as needed, or can execute-in-place. There's a pretty good write-up here, and a glitzy sales page here. With an MPU or MMU each application can be completely isolated. I can see a lot of use for this in some systems.
In other RTOS news, Amazon has taken over FreeRTOS, and Richard Barry now works for them. It appears Amazon wants microcontroller-based devices to connect to their cloud. And with the company now offering FPGA instances, well, all one can say is "One Company to rule them all, One Company to find them, One Company to bring them all and in the darkness bind them, in the land of Amazon where the economy lies."
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 at www.ganssle.com/jokes.htm.
A woman gets a $284 billion electric bill and wonders if it was because of her Christmas lights.
Advertise in The Embedded Muse! Over 27,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.