|You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email.|
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 http://www.ganssle.com/onsite.htm . It's a full, fast-paced day in which we cover a lot of material.
|Quotes and Thoughts|
"Science is about what is; engineering is about what can be." Neil Armstrong
|Tools and Tips|
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.
|More on Stacks|
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.
|On Getting Things Done|
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!
|A Shuttle Failure Averted|
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!This is software engineering at its best. Instead of quickly fixing the bug and moving on - as most of us do - the development team transformed the defect into an opportunity to improve the code
|Joke For the Week|
| Note: These jokes are archived at www.ganssle.com/jokes.htm.
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 With Us|
Advertise in The Embedded Muse! Over 23,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.