Embedded Muse 201 Copyright 2010 TGG December 3, 2010
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 at email@example.com.
EDITOR: Jack Ganssle, firstname.lastname@example.org
- Editor's Notes
- Quotes and Thoughts
- Tools and Tips
- Advanced Degrees
- More on FOSS
- Joke for the Week
- About The Embedded Muse
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 http://www.ganssle.com/onsite.htm .
Bob Paddock sent notice that Watts Humphrey has passed away. He was known as the father of software quality, and contributed greatly to this field.
Quotes and Thoughts
I am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. - Douglas Adams
Tools and Tips
The tool tips keep pouring in! Keep `em coming.
John Johnson wrote: "I had a section of a spreadsheet, a Gantt Chart, I wanted to save as a PNG to be able to insert it into a document as an image. found the following: http://spreadsheetpage.com/index.php/tip/saving_a_range_as_a_graphic_file/
"And then I found: http://www.getpaint.net/download.html
"Result: A Gantt chart in a PNG."
I found myself in an odd position recently. In a patent dispute the judge ruled that "one of ordinary skill in the art" of embedded systems was someone with a degree in computer science and at least two years experience. I don't have a degree, so was ruled as a person without even ordinary, let alone advanced, skills in this field. That proved more of an amusing diversion than something of importance, but it did get me thinking.
My academic career ended three courses shy of an EE degree. I had to work to pay for college, and had been employed as an electronics technician since high school. But I started college in 1971. the very year Intel invented the microprocessor. A year or so later they came out with the 8008, and the outfit where I worked decided to incorporate one into a new line of products. None of the engineers knew how to write programs, and only one knew how to design computer systems. My misspent geek youth in the pursuit of all things digital finally proved worthwhile, and I was recruited into engineering. The job proved more interesting than school, and working full-time while going to school was tough, so I eventually (and foolishly) abandoned life at the University of Maryland. Ironically, decades later I taught an EE class at the same institution.
I was lucky to stumble into a decent engineering job despite being sans degree, and spent a decade at that company, eventually becoming the manager of the digital department which grew at a pace reflecting the growth of the microprocessor. But I've pushed my kids very hard to complete college as the degree is a passport that is practically indispensable to success in a professional field.
But is a BS, at least in computer science or electrical engineering, enough in today's hypercompetitive world?
Most engineering jobs require a BS and only rarely mention an MS or PhD. I wonder, though, if an advanced degree opens doors or makes one more competitive in a hiring situation than just the bachelors.
What's your take?
More on FOSS
Greg Nelson had some thoughts about the FOSS discussion: "Other authors have already said most of what I would say about FOSS versus proprietary solutions. Clearly there are some advantages to commercial products. For office use, I have Keil's suite for 8051 type processors, but I can't afford that for my home business, so I use SDCC... and can barely fit an application that Keil manages to squeeze into about 1/4 the space. That's some *intelligent* optimization there...
"Still, there is another possibility that I didn't see mentioned: roll your own. There are two parts to the puzzle -- the tools themselves, and the components that become part of your product. I have the impression that many people build tools for their own desktop, but for one reason or another, they are more reluctant when it comes to production code.
"Over the last 15 years, I have used both FOSS and proprietary solutions, from Linux to uC-OS to XMK to VxWorks. The one conclusion I have come to is that it's REALLY painful to debug someone else's code. And worse if it's poorly documented, and also if it tries to support every feature under the sun.
"Overall, our experience is that, for a certain class of common embedded projects, it literally takes longer to debug the problems in someone else's code than it does to implement the same functions yourself from scratch. FOSS nominally makes it possible to debug it yourself, but it's not straightforward to rely on the community for answers, partly because the software itself is a moving target. Proprietary software offers formal "support" but it is a rare company that sees that as encompassing more than updating your license or telling you that "it will be fixed in the next version."
"On the VxWorks front, I once had to dissect their interrupt jump table code sufficiently that I could overwrite appropriate portions of it with my own code. VxWorks presents a wonderfully uniform platform across a vast number of different processors... and in the process renders the best features and optimizations of those processors completely inaccessible. In this case, I was trying to use the "fast interrupt" feature of a PowerPC405, and the latency of their N levels of wrappers was multiple times longer than the handler I was trying to execute. Their tech support was no help at all on this so I just bypassed it.
"I've confronted both a conventional BSD networking port, and LWIP, and been left with network stacks that would work well enough for the home user (think "Windows ME") but not for industrial embedded use. In the BSD case, which would often crash due to other traffic on the network, we eventually rolled our own because the lightweight needs we had (e.g. UDP only) were so completely different from what it was designed for. After that, the product was reliable. In the LWIP case, the product seems to operate for 52 days before it crashes. Imagine trying to debug someone else's code when you have to wait 52 days every time you restart the application. Heck, my Windows-hosted development environment doesn't reliably stay up long enough to wait for the bug.
"We once cancelled an entire project because we found out that the Linux drivers for ECP (as opposed to a conventional parallel port) were incapable of doing the same things that were being done on a different platform. We couldn't find anyone who knew enough about them, who was even willing to help us understand them well enough to solve the problem. In the end it came down to a sense that "you can't do that under Linux" because the control we needed and the architecture of the operating system were at odds."
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.
Joke for the Week
The Sysop's Night Before Christmas
'Twas the night before Christmas, when all through the house
Not a peripheral was stirring, not even a mouse.
The modem was plugged to the phone line with care
In hopes that a download soon would be there.
Our pirates were nestled all snug in their beds
While visions of unprotects danced in their heads.
And Mama in her kerchief, and I in my cap
Had just settled down for a long winter's nap.
When up on the hard drive there arose such a clatter,
I sprang from the bed to see what was the matter.
Away to the monitor I flew like a flash,
Sat down at the keyboard, gave the spacebar a mash.
The sight on the screen, all a'flicker with snow,
Gave the luster of power surge to the menu below.
When, what to my wondering eyes should appear,
But an autoexec.bat that seemed rather queer.
With a little print driver so lively and quick,
I knew in a moment I had seen a new trick.
More rapid than eagles the cursors they came;
My MIDI whistled, and shouted, and called them by name!
"Now Format, now Rename, now Copy, and Enter!
On Num Lock, on Caps Lock, on Scroll Lock, and Printer!
"To the top of the page, to the top of the doc,
Now tab it and bold it and merge it and block!"
As utilities that build up the CPU speed
Clash with just the programs I need,
So up to the screen top the cursors they flew,
With a RAM full of memory and an expansion board too.
And then, in a twinkling I heard on the speaker,
The grinding of the hard drive growing much weaker.
As I tried to reboot and turn it around,
The attributes changed from blue into brown.
I hit the control, the alt, and delete.
The screen message it gave me, I cannot repeat.
It asked me to Ignore, Retry, or Abort.
It told me the parallel had become the comm port.
Its lights how they twinkled; its pixels how merry,
Its prompts were all scrambled, like a bowl full of cherries.
It sounded just like it wanted to blow;
The screen was suddenly white as the snow.
It scrolled its directory before my eyes
With programs I didn't even recognize.
It wouldn't see D:, it wouldn't see E:;
I couldn't get out of B: into C:.
Norton's tried to read it, finally finding the FAT;
But alas! The disk was faulty, and couldn't reformat.
Away flew the DBase; away flew the DOS-es;
Away flew the WordStar; right out with the Windows.
The spreadsheets were spreading; the footers were headings;
What once had been memory was close to forgetting.
When the grinding was over and the smoke had all cleared,
I looked at the hard drive; it was just as I feared.
The 600 meg wonder had crashed in the night;
I'll never be able to block out that sight!
So tell everyone you know to avoid my plight;
Back up your files! Merry Christmas! Good Night!
About The Embedded Muse
The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at email@example.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 firstname.lastname@example.org for more information.