Follow @jack_ganssle
TEM Logo The Embedded Muse
Issue Number 313, September 19 2016
Copyright 2016 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact info@ganssle.com.

Contents
Editor's Notes

 

VDC is running their annual survey of the embedded space. Take the survey here, and I'll report the results in a future Muse. They're offering a $30 gift card or the same amount as a contribution to Doctors Without Borders.

Better Firmware Faster classes in Denmark and Minneapolis

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 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.

I'm holding public versions of this seminar in two cities in Denmark - Roskilde (near Copenhagen) and Aarhus October 24 and 26. More details here. The last time I did public versions of this class in Denmark (in 2008) the rooms were full, so sign up early! (There's a discount for early registrants). The discount for early registration ends September 24.

I'm also holding a public version of the class in partnership with Microchip Technology in Minneapolis October 17. More info is here.

I'm now on Twitter.

Quotes and Thoughts

Even if 100% test coverage were possible, that's not enough. 35-40% of software defects emerge from missing logic paths, and another 40% from the execution of a unique combination of logic paths. They will not be caught by 100% testing. - From Glass, Facts and Fallacies of Software Engineering.

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.

Crosstalk is a USAF bimonthly on-line publication that more often than not isn't terribly interesting. However, I read it as about one out of three issues has some really worthwhile material.

The latest issue has a fascinating article by the always-interesting Capers Jones about the causes of litigation in software matters, in particular for breach of contract when the code doesn't live up to the promises. Litigation? Who cares? But the article is a nice way to think about how one should approach a major development project; in other words, what pitfalls to avoid. (Mr. Jones hates the lines of code metric and uses function points. In C a function point is 100-150 lines of C).

There's also a moderately-interesting article about becoming a better software project manager. Lawrence Peters makes the point that management is very different from development. It's amazing that so many of us are promoted into leadership roles but are given no real training in the art.

Freebies and Discounts

This month's giveaway is a 30 V 5 A power supply. Alas, it takes 110 VAC only. (It's hard to imagine anyone designing a product that way in this day). But it seems like a nice unit.

Enter via this link.

More on Upgrading Windows

In the last issue Bob Snyder write about hassles updating Windows 7. Mark Fiedler weighed in:

I ran into this same problem with a refurbished notebook that I bought last month. The refurbisher had installed a clean version of Windows 7 Professional. Not only could I not get any O/S updates, I couldn't update Internet Explorer or Windows Defender either. I thought I had just bought a totally insecure and crippled system. Before packing it up and sending it back, I did a web search and found a forum post with the answer.

Apparently, the latest Windows Update Server is not backwards compatible with the old version of the Windows Update client service that is part of the clean install. So to get around this problem, I had to manually download just the update for the Windows Update client and manually install it. Once I did that, Windows Update immediately found 100's of updates totaling 750 MB and installed them without a hitch. And now I love my new notebook. Unfortunately, I didn't save the link to the download site for the Windows Update patch, but I am sure it would be easy to find.

The patch I downloaded was a typical Microsoft update with a name in the form KBnnnnnnnn (where nnnnnnnn is a number). I downloaded it directly from Microsoft by going to their page that gave the details for this particular patch.

Steve Foschino wrote:

In issue 312 of TEM, reader Bob Snyder lamented about the painful process of applying all Windows 7 updates into a clean install. I suffered thru that also but found a way to get around it. Microsoft published a single file 'rollup' that installs all windows 7 updates (up to a very recent point). I followed the directions on how-to-geek (link below), downloaded all the files necessary to a thumb drive beforehand and had a clean, fully updated install of Windows 7 up and running in a few hours instead of days. Of course, even after this rollup, there was still a few updates to download and apply, but they were few. You should also locate and download IE11 for Win7 from Microsoft. Even after all the updates are applied, IE remains outdated (I think at v9) and doesn't work with the Microsoft website.

Note: I was not able to download the necessary files from the Microsoft website using the current version of Firefox. I had to use another computer with a compatible version of IE.

http://www.howtogeek.com/255435/how-to-update-windows-7-all-at-once-with-microsofts-convenience-rollup/

How to Measure Good Design?

Charles Manning

The last two months or so, I've been burning some null cycles trying to ponder what makes for well designed vs poorly designed software body, and it is very challenging to get a handle on any objective measures.

Over the last 36+ years - including some time tutoring CS at university and many years as a consultant, I've seen a lot of code. Some has been well designed and some terribly designed. Unfortunately the terrible is vastly more common than the beautiful.

But that assessment has been rather subjective - even very difficult to articulate.

Software is very abstract. From the outside you cannot see software duct tape. Nor can you see a an over-engineered monstrosity that is equivalent to a car built out of I-beams and craft glue.

With enough effort, even the most awfully designed software can be made to run - even reliably, so working or not working is not a good measure.

So far my pondering has only given me two measurements:

1) How long it takes to fix a bug once clear symptoms are known, Does it take a few minutes? Does it take days? Poorly designed code has convoluted code paths which make it very difficult to nail down where something is going wrong. Both well designed and poorly designed code have bugs, but poorly designed code is harder to fix, meaning the bugs live longer and take more effort to kill.

In the 1980s IBM tried developing some quality metrics. One they used was bugs tracked on a module by module basis. What they found was that bugs were not randomly scattered around. Some modules would tend to have more bugs than others. Certainly some modules are more difficult to design than others, but some must surely be attributed to good vs poor design.

2) Code complexity for the job at hand. When there's an order of magnitude more files and code than there should be then the chances are that the code body is poorly designed. The "code effectiveness" is very low and there's a lot of "lazy" code coming along for the ride.

That "lazy code" is often a result of trying to band-aid over corner cases where the main code path fails, or code duplication. Both are signs of poor design.

Neither of these are very satisfactory measures.

I do think this is an important question, but have some doubts that there is any sort of quantitative metric or metrics.

Active/Idle Timer

In the last Muse Andreas Hagele contributed an idea for measuring idle time. Steve Paik has some suggestions:

I just got around to reading this issue of the muse. I like Andreas Hagele's idea for instrumenting the idle timer, but don't really like the approach with the timer. In particular, he's using 50 timer ISR calls to execute what could be done in 2. IOW, if he dynamically sets the timer's counter value each time, he could save 96-98% of the processing that is associated with this. I.e:

 interrupt void timer_irq(void)
     {
         if(off_duty < SAMPLE_INTERVAL) {
             DEBUG_IO_ON();
             // LED on for some period of time to complete 100ms period
             set_timer_count(SAMPLE_INTERVAL - off_duty);
             off_duty = SAMPLE_INTERVAL;
         } else {
             DEBUG_IO_OFF();
             if(loop_count < IDLE_COUNT) {
                 off_duty = loop_count * SAMPLE_INTERVAL / IDLE_COUNT;
             } else {
                 off_duty = SAMPLE_INTERVAL;
             }
             // LED off for off_duty * 2ms ticks
             set_timer_count(off_duty);
             loop_count = 0;
         }
     } 

Of course, there's more optimization to be done here, but I think this is a good first step.

100ms period for this sort of PWM might will have flicker.... if he's OK using a timer tick every 2ms, I'd opt for a period closer to 20ms total (still only 10 interrupts per 100ms) to reduce noticeable flicker.

Jobs!

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 at www.ganssle.com/jokes.htm.

From Harold Kraus:

Hexose sugars like glucose, mannose, and galactose are isomers, all having the formula C6H12O6. In these cyclic hexose isomers, there are 4 hydroxyl groups with alternate positions. The particular positions determine such effects as relative sweetness and optical characteristics of each isomer. With 4 variable hydroxyl groups there are 16 possible isomers.

So, the next time someone asks if you would like something sweet, you can answer, "Maybe just a nibble."

Advertise With Us

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

About The Embedded Muse

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. 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 info@ganssle.com for more information.