|
Embedded Muse 199 Copyright 2010 TGG September 25, 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
Contents:
- Editor's Notes
- Quotes and Thoughts
- Tools and Tips
- Jobs!
- Joke for the Week
- About The Embedded Muse
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 .
Quotes and Thoughts
When Herbert Hoover told a lady he was an engineer, she replied, "Why, I thought you were a gentleman!"
A Thought About Free Software
A number of folks responded to a reader's thoughts on FOSS last issue. It's a hot-button issue for some, a calm engineering decision for others. Steve Paik wrote: "To answer Edwin's question, I had an experience at a previous company last year where the CTO insisted, against all good reason, to use Linux in our product. The CTO is an RF engineer and has zero SW experience. At the time, the organization had no SW manager, and they had three embedded project engineers. Anyway, the CTO's idea was to use Linux on a Cortex-M3 processor that had only 512 KB of effective program memory.
"His rationale was that he wanted a free, open source operating system because the last time they used a proprietary OS (VxWorks), they had all sorts of problems with "bugs" and the ability to integrate a 3rd party file system. He didn't see any sense in paying money for an OS that "didn't work".
"When I arrived at the company, they had been working on porting Linux to this embedded processor (there were no ports available at the time) and could barely fit a kernel inside the 512KB. Let alone a shell.
"I recommended ThreadX, but again, they wanted free. So I eventually found FreeRTOS.org. Amazingly, this Free RTOS did everything we required of it, and best of all, it was free! Performance was reasonable, too!
"It took about a month to convince him that this was a better alternative to Linux. The free RTOS kernel size was about 3KB and provided all the functionality that we required. He clung to Linux until the bitter end.
"After that, he wanted a free FFS, and wanted to know if we could use JFFS2 or YAFFS.
"In addition to this, he wanted a free IDE, such as Eclipse.
"Not to mention a free implementation for a CAN bus driver.
"The project had a deadline to ship in 3 months, and I told him that these were the wrong tools for the job, for a variety of reasons. We ended up selecting a proprietary file system from Blunk Micro, and used IAR's IDE for development. I finally quit before we even got around to the CAN bus implementation.
"It was the most frustrating thing ever, trying to explain why "free" really isn't free. Since my manager didn't understand SW development, I kept asking him why he insists on paying for ORCAD to do his circuit layout, instead of using a "free" PCB tool? His response was that he'd rather use a free tool since ORCAD sucks, but it's all he knows how to use."
John Eaton commented: "You need to understand the relationship between free and proprietary tools. FOSS will establish a floor in terms of quality and features for the industry. If you are trying to sell a tool that is no better than the free alternative then you will soon find yourself out of business. Having a selection of free tools will drive up the quality of proprietary tools and keep their prices in check. Even if you have no intention of switching over to FOSS you should set up a parallel development track simply to benchmark your process against a free one so that you fully understand what you are getting when you buy a tool. You might be surprised to find that FOSS can cover a lot of your requirements.
"As far as bosses go this is an old issue best described by a quote from a boss in "The soul of a new machine" by Tracy Kidder: "Why buy expensive test equipment? Overtime for engineers is free."
"The bottom line is that if you cannot convince your boss that you are worth the money then you better change bosses."
From John Carter: "The real question is not about whether they are prepared to buy proprietary, but whether they are prepared to fund FOSS.
"Buying proprietary is a "quick & dirty fix for this problem now". And given time to market constraints I can understand that on occasion.
"The correct solution that we _all_ benefit from for now and _all_ time is funding FOSS.
"Funding FOSS is a _very_ flexible thing and comes in a large variety of shapes to fit every budget.
* Taking the time to submit proper bug reports and test cases.
* Taking the time to test patches.
* Helping with documentation.
* Submitting proper patches against latest version.
* Letting employees work on FOSS that benefits the company.
* Contributing money to primary developers to develop certain features fixes.
* Contributing to trust funds that fund FOSS.
* Mentoring summer students / Google SoC to work on FOSS beneficial to your company.
* Buying support services from the primary developers."
Frequent contributor Steve Litt sent this: "I'll attempt to answer Edwin Decoene's question from my business's point of view. First the facts.
"From 1988 through 1998, during which I was a full time software developer (office automation), I purchased between $1000 and $2000 on proprietary software annually. In the 00's, when I was primarily a trainer, author and courseware developer, I spent less than $400 total on proprietary software during the entire decade. Part of the reason is I don't need compilers any more, but that's not the entire reason. Before 2000 I regularly spent money on word processors, spreadsheets, help file authoring tools (at one time my eBooks were help files), and the like. I still need those things. So my business shift alone can't account for the change. As a matter of fact, there are some proprietary and documentation tools I'd love to have, but I don't.
"There's no doubt that in the age of free software, my price expectations for software expenditures has gone down. But no way would I reject software just because it costs money.
"The main reason I no longer buy proprietary software is because of the hassle factor. License tracking. Calling home. License keys that get lost. Having to beg for the privilege of re-installing my already paid for software either on the same computer, or, after deleting it from one computer, on another computer. Read this: http://news.cnet.com/2008-1082_3-5065859.html
"Who needs all that noise? I don't. I don't want the BSA, or whatever they're calling themselves these days, banging down my door. So I just refuse to run proprietary software, and it's not an issue.
"Another reason I eschew proprietary software is that all too often it doesn't run on my operating system, Linux. The Clarion programming language (from SoftVelocity) is far and away the most productive Rapid Application Development environment I've ever seen. I'd gladly pay $1000.00 for the Professional edition. But it's Windows only.
"And then there's the fact that a lot of free software is better. LyX is hugely better for writing books than MS Word (I know that's not apples v apples but I never bought desktop publishing programs). I prefer the Gnumeric spreadsheet to Excel.
"So, in answer to Edwin's question, I'd definitely say the existence free software has caused me not to use proprietary. But price is only a small part of the dynamic."
And Luca Matteini sent this: "in your latest EM198 I read with interest the short thoughts about free software and its use/acceptance, because I found myself often debating it (especially in the past, when it was still kind of a "novelty").
"First, I very often use free software, especially for the daily chores on my systems. And on any occasion, before buying the mainstream application I need, I do always peek at what's available as free: for me, as a freelancer sailing in a sea of crises, is everyday more important saving on budget.
"Moreover, there's another important factor: how much do I plan to use the billion features of a commercial product, when I would just need a dozen of those thousand ones given by a free product?
"If you buy a t*rx screwdriver of a size you don't own one, and you plan to just remove just a couple of those screws, in years, would you buy the $2 Chinese one or the $40 one from the best brand?
"Then things have changed over time: years ago was harder to find so much good quality free tools, in so many fields of application.
Looking for a good and free C compiler for an embedded target 10-15 years ago, was often frustrating. If you do the same search today you have so many more chances to feel pleased, with what you find.
Again, I have customers with which I use expensive and fine IAR compilers, while with others I'm happy with SDCC or some GCC flavor.
"Much of the software I produce is intended for a single customer, that would never like me to share it: they pay me for giving them a professional advantage over their competitors. A stock broker wouldn't share the best investments with everyone, or they become no more the best, I suspect.
"Finally, there's a consideration on what is "free", "open", etc., and I'm very critical about it. If you read well the intentions in licenses like GPL v3, the word "free" means you're free to do exactly what the license forces you to do. Free as in freedom? This is certainly not the case. A license like BSD would be more in the sense of freedom.
"My conclusion is: viva free software, as long as its quality and features fulfill my needs, and I don't have to sign with blood the way I'm gonna using it."
James Thayer wrote: "This is a very interesting question. Where I work, it is sometimes easier to successfully justify proprietary software than to use Open Source. In our case, at least, Open Source is not free (as in neither beer nor free speech.)
"In the former sense, Open Source Software is not without cost. Sure it may be available for gratis but any new use of Open Source Software triggers a legal review that costs plenty in terms of both time and money. (Time often turns out to be far more important than money...if the legal review is going to take longer than the project can afford, it's a non-starter.)
"In latter sense, Open Source Software can come with a whole range of entanglements that may restrict its use -- depending on the specifics of the associated license (GPL, et al.), intellectual property issues, and the agreements we may have with our partners and customers (to name just a few of the considerations that need to be taken into account.)
"This is not to say that we do not use OSS. On the contrary, we use a lot of Open Source Software. And we contribute back to the Open Source community as well. But use of Open Source Software is never a decision that we can take lightly and as a result of that, it can actually be easier to justify commercially available software over Open Source."
Tom Sheppard contributed this: "Yes, and doing so at my loaded labour rate cost the company far more than just buying a license for the tool. Never did find anything as good as the proprietary tool so we continued to waste more time and money shoehorning in a "free" tool so it would work in our environment. Oh yeah, and then we owned the source code because we modified it outside the open source project. Cute."
Finally Keith Richeson wrote: "Regarding your question around FOSS tools, while I too am willing to pay for a quality tool I find the price of some present day toolchains to be a bit exorbitant. For example, one major compiler vendor charges in the neighborhood of $6k (USD) for their ARM toolset. While my management is exceptionally supportive of buying whatever tools we need to get the job done, they also sometimes ask a simple question. 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.
"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."
Tools and Tips
The tool tips keep pouring in! Keep `em coming.
From Larry Rachman: "RPN calculators, eh? The discussion really can't be considered complete without a mention of xcalc (http://www.tordivel.no/xcalc/) a freeware implementation done by a very nice fellow in Scandinavia. His licensing policy: 'try it, share it, if you like it, send me some spices'. Once I installed it on all my machines I pretty much lost interest in handheld devices - being small and light they sometimes get lost, but my computer is big and heavy and hardly ever get lost."
Don Peterson is into RPN, too: "I'm also a big fan of HP calculators and loved the early LED ones. However, my favorite HP calculator was the HP-42s, which was an HP-41 replacement. I wrote an RPN calculator program that contains many of the elementary HP-42s functions and runs in a console. It's intended to look pretty simple, but it has features like arbitrary precision, interval arithmetic, and pretty tight control over the output formats. It's called hc.py on google code."
Vlad Z isn't so keen on it: "I have to say that I never really fell in love with RPN. I used the HP calculators in the past, when there was nothing else. back in the USSR, in the 70s, I borrowed one now and then from a lucky owner who could afford it. I held it in my hands with the feeling of awe, like having attained a nirvana-like state. still, i avoid RPN when I can. these days, when I am mostly in Linux or on Windows, with Perl installed on both, I use the following script and let Perl do the work:
$ cat `which calc`
#!/usr/bin/perl -w
# normal expression based calculator: let perl do the work
(@ARGV < 1) && print("USAGE: $0 quoted_expression \n") && exit 0;
my $z = eval $ARGV[0];
if ( $ARGV[0] =~ /\./ ) {
printf "%f \n", $z;
}
else {
printf "0x%x (%d)\n", $z, $z;
}
exit 0;
"The invocation has to be quoted and looks like this:
$ calc '(0xfafa * 5.2) / 10'
33410.000000
"I find it much easier on the old brain than RPN... ;)"
RPN wasn't the only thing readers were thinking about. John Johnson wrote: "My bad. I could have sent his in a long time ago and doing so simply skipped my mind.
"I would recommend Qfsm as a tool that helps create finite state machine diagrams and does this task much better than does Visio.
"For a while I have been reviewing FPGA development and have used Qfsm in this work. From the Qfsm About window the tool is described as "A graphical tool for designing and simulating finite state machines".
"From the Qfsm page on Sourceforge: We are very happy to announce that Qfsm won an "Editors pick" award by Brothersoft, one of the leading software download sites.
"I might say that because Qfsm could be seen as a "documentation" tool it might not gain acceptance from communities that typically disdain documentation, e.g. software/firmware programmers, developers, hardware designers, etc. <smile>"
Joke for the Week
I Shot A Query Into The Net
I shot a query into the net.
I haven't got an answer yet,
But seven people gave me hell
And said I ought to learn to spell;
A posted message called me rotten
For ignoring mail I'd never gotten;
An angry message asked me, Please
Don't send such drivel overseas;
A lawyer sent me private mail
And swore he'd slap my ass in jail --
I'd mentioned Un*x in my gem
And failed to add the T and M;
One netter thought it was a hoax:
"Hereafter, post to net dot jokes!";
Another called my grammar vile
And criticized my writing style.
Each day I scan each Subject line
In hopes the topic will be mine;
I shot a query into the net.
I haven't got an answer yet ...
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.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.