• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• Kilobyte Couture
• More on Stacks
• On Getting Things Done
• A Shuttle Failure Averted
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm . It's a full, fast-paced day in which we cover a lot of material.

"Science is about what is; engineering is about what can be." Neil Armstrong

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

Royce Muchmore wrote: I'm not sure this qualifies as a traditional tool, but over the years I have acquired a large number of bookmarks (Favorites) that I periodically merge between work and home computers.  Recently I have been looking at online bookmark sites as a better solution.  There are some very specialized sites for creating publications, and many subscription fee based sites.  The web site I ended up using was a free site:  http://www.protopage.com/.  One of the noticeable differences between bookmarks saved on my computer vs. bookmarks saved online is the organization structure. Bookmarks on my computer are organized in a hierarchical file structure.  Most online bookmarks are organized in categories which are only 1 level deep.  The online bookmarks can be tagged and filtered.  However, it's not straightforward to map from computer bookmarks to online bookmarks.  On the the protopage web site bookmarks can be grouped as tabs.  The tabs can be shared with others or kept private.  In addition to bookmarks other widgets can be placed in tabs such as notes, pictures, web pages...  One hurdle I see is that I don't know how to export/backup the online bookmarks.  I would hate to spend all this time converting to online bookmarks only to see the web site disappear. I would be curious to know what other reader's experiences are in dealing with this.

Steve Fairhead said: I recently bought one of these: http://www.digilentinc.com/AnalogDiscovery. It's both a scope and a logic analyser, and is astonishing for the price.

After reading Steve's email and looking at the Digilent web site I'm also astonished by the claimed features. The company is sending me one and I'll have a report on it soon.

Brad Safranski also has comments about a USB scope: I wanted to contribute that a couple years ago I purchased a Hantek DSO2150 USB Oscilloscope.  It has a 150 Msps rate across 2 channels (1 channel at 150 Msps or 2 simultaneously at 75 Msps each) and has BNC connectors for the channels and for external triggering.  The unit is relatively compact and light.  The scope includes a software disc that provides drivers and the essential scope functions for your PC.  The package also includes two probes.  This scope was very helpful in my postgraduate education and in hobby projects--it saved me many trips to the lab and friends love to borrow it!  It can be had on auction sites for around $200 and there are other scopes in the DSO2000 line and with higher or lower sampling rates.

Best practices of code review from Smartbear.

You're kidding me - 30% of young folks admit to updating their Facebook pages while driving!

Bob Paddock's latest on state rules for licensing engineers.

My wife, who beads (constantly!), brought a book named Kilobyte Couture home recently. What has that to do with embedded systems? Well, the entire tome is about making jewelry using electronic components.

The "IEEE Necklace"

The author, Brittany Forks, shows quite a range of jewelry made from resistors, caps, transistors and the like. It is a little jarring to read the bills of materials for these items; a typical entry is "5 light brown capacitors," rather than the usual "10 µF 10V tantalum capacitor."

Her web site seems to be down.

Martin L Buchanan had some thoughts on stacks: Two other solutions for detecting stack overflow may be worth mentioning:

1. In a processor with an MMU, have an invalid page table entry for the page below the valid stack area. The memory management code will ideally cooperate, know that the pages above are a stack, and indicate a distinctive exception.

2. Less useful as segmented memory architectures are rarely used now, but in a processor like the 8086, the stack area can be a distinct memory segment and the processor can detect an attempt to move the stack pointer (in a downward extending stack) below offset 0. (Though I have not dug out the processor reference materials to verify that it does.)

A completely unrelated comment: Am I the only developer who reads journals much less now that those journals are all digital? EE Times and SQL Server magazine may still claim the same circulation, but are getting far fewer page views from me than the paper editions did.

Chris Jones contributed this: I’ve appreciated some of the discussion you’ve had in your newsletters on development “in the zone” and the time required to get there, the dangers of interruptions, etc. etc.  I came across another article with some really helpful (to me, anyway) insights from Paul Graham:  “Maker's Schedule, Manager's Schedule”.  He compares and contrasts “to-do tasks” and creative-type tasks (for our industry, like up-front software design, or implantation, or what-have-you).  Worth the read!

And beyond that, I read another article called “Getting Creative Things Done: How To Fit Hard Thinking Into a Busy Schedule” where the author came up with a systematized way of using Mr. Graham’s insights.  Block out LARGE chunks of time, set specific rules for those chunks (for example, no email), and “Focus on process, not goals.”

There were definitely some ideas I’d heard before, but some new ones too.  Thought you might be interested!

The second Space Shuttle launch in 1981 was delayed by a month when a fuel spill loosened a number of its tiles. The crew booked simulator time in Houston to practice a number of scenarios, including a “Transatlantic Abort”, where the vehicle can neither make orbit nor can return to the launch site. Suddenly, all four main Shuttle computers (in the simulator) crashed. Part of the abort scenario requires fuel dumps to lighten the spacecraft. It was during the second of these dumps that the crash occurred.

After a couple of days of analysis, programmers discovered that the fuel management module, which had done one dump and successfully exited, when recalled for the second fuel dump, restarted thinking that this was it’s first incarnation. Counters in the code had not been properly reinitialized, though, causing what was essentially a computed GOTO to branch out of the code, into a random section of memory.

A simple fix took care of the problem. More interesting, though, was the realization that this same sort of bug had appeared in different modules before. The programmers were committed to producing only the best code, so decided to see if they could come up with a systematic way to eliminate these generic sorts of bugs in the future.

They developed a list of seven questions that had a high probability of isolating similar problems. A different group of programmers then applied these questions to the bad fuel dumping module (to see if they would indeed pick up the known problem), as well as other modules.

The questions detected every one of the bugs. 17 additional, previously unknown, problems surfaced!

Mark Griswold contributed this, though I'm not sure it's a joke: At a recent software engineering management course in the US, the participants were given an awkward question to answer. "If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software how many of you would disembark immediately?" Among the ensuing forest of raised hands, only one man sat motionless. When asked what he would do, he replied that he would be quite content to stay onboard.

With his team's software, he said, the plane was unlikely to even taxi as far as the runway, let alone take off.

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

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.