Go here to sign up for The Embedded Muse.

Embedded Muse 200 Copyright 2010 TGG October 18, 2010

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

Are you happy with your bug rates? If not, what are you doing about it? Are you asked to do more with less? Deliver faster, with more features? What action are you taking to achieve those goals?

In fact it IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .

This is the 200th installment of The Embedded Muse. The first issue ran way back in 1997 when embedded systems used cams, cranks and steam engines. Thanks to all of you loyal readers who have contributed so much to it!

Quotes and Thoughts

If you think good architecture is expensive, try bad architecture.
- Brian Foote and Joseph Yoder

Tools and Tips

The tool tips keep pouring in! Keep `em coming.

I switched to a Mac laptop a few months ago. Finder, the Mac's equivalent of Windows Explorer, stinks. But PathFinder from http://www.cocoatech.com fixes all of Finder's flaws. At $40 it's highly recommended.

Andrew Dyer is an RPN fan: "When I am working at the computer, I use the excellent emacs 'calc.el' package. If you are an emacs fan, I can't recommend this highly enough. I mostly use simple stuff, but there is a fairly capable set of math functions in there, and it's just a few keystrokes away.

"For other times I have an app for my Android phone called droid48 which is an HP48 replica."

Fred Roeber wrote: "The tool Foxit is mentioned for viewing PDF files. Something I really wanted to be able to do was add notes to PDF files without having to buy the Adobe version that supports that feature. I had trouble with Foxit crashing on Windows platforms when I tried to use its "notes" feature. However, I've had no trouble using the free PDF-XChange viewer from www.tracker-software.com to put notes in PDF files. It's really powerful and, like Foxit, allows you to use the scroll wheel for smoothly scrolling through documents."

The discussion continues! Paul Carpenter had several comments: "This was an interesting discussion, I would agree that many aspects of the debate ends up in the standard software/embedded answer: It depends.

"Yes you can sometimes get faster to market depending on the tools learning curve and integration into your archiving methods and more importantly what is the products support lifetime. I still support 12 year old products and another has a potential 20 year life span.

"This in itself can produce nightmares of having to keep old host systems functioning, to ensure you can compile EXACTLY the same from PCB to firmware to mechanical. The nightmare of rechecking all old projects for platform/OS change is a continual nightmare.

"All tools have hidden costs, installation, integration, and those damned support contracts (more later).

"Instead of SVN support, IDE integration, auto generated build files and other such paraphernalia, there is one simple thing I would like ANY compiler to do automatically - generate a SINGLE build report that detailed in PLAIN TEXT the following:-

- Date/time of run start/end (so you know its age and how long to expect to rebuild)
- Host name built on
- Host username (if present to find out if they had some special DLL or similar)
- Host operating system and version
- Compiler and linker versions
- Target processor (NOT family)
- IDE used and version
- Included libraries/include files and paths versions of above if possible
- Every single source file, date and size compiled
- The name of the MAP file
- The summary of segment sizes
- The output file(s) name, size and date

"I don't want this stored in some proprietary database or encoded workspace/IDE/environment file, as I want to know what I might have to install to replicate the build, possibly on a different site or continent. We all know how good a lot of places are for keeping records of what things have been built with.

"Then we get to 'support contracts' this normally means you have to update your tools to latest version (and possibly host and OS). How many people check they can rebuild old projects exactly the same?

"The majority of people need support for about 1-3 months of initial version install/update.

"As I have just discovered on one tool, going from evaluation CD to latest meant some things in the compiler suite disappeared, which you had to find not by documentation but deciphering convoluted library header files. So I had to spend time discovering the difference and trying to get a workaround. I worked out a solution days before the problem was acknowledged.

"During the discussion of long term solutions it was suggested I get the 'Long Term Support Option" at 10X price for annual subscription for better version control and bug fixes.

"As far as I see it I would be paying for bug fixes, caused by updating in other words paying to fix somebody else's problems. This is software leasing by the back door.

"Personally this course of action would annually add 10% to 20% onto project costs, let alone my time to get to source of problem first. I don't know any customer who would COME BACK to me, if I insisted on similar support contracts.

"I have seen this over the years from Proprietary tools AND FOSS support contracted tools.

My simple rules are"
- NEVER change tools mid-project
- NEVER upgrade a tool just because a new version has come out (most of the new features and hopefully bugs you don't use or want)
- Keep the amount of tool changes to a minimum, for your own better productivity.
- Don't rely on special tool options to mask bad design
- Be sure you can recreate COMPLETELY any host environment for ANY tool and ANY files can be read at least for old projects that are being supported.

"Don't even get me onto licensing, node locking and similar.

"I agree totally with Keith Richeson's boss comment ("If it was your company, would you spend the money? In this case, I struggle to honestly say that if it were my company I would go out and spend $6k on a tool when I know there are free alternatives.") As being my own boss, means I agree totally with this.

"That being said, I think the thing that bothers me more about proprietary tools than the initial price is the ever popular support agreement. I'll grant you that there is no guarantee of support for a FOSS tool, but at least the source is available and I can investigate on my own and/or ask "the community" for help. For whatever reason, the whole support agreement concept really bothers me."

Jobs!

Let me know if you're hiring firmware or embedded designers. 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.

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.