You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email at firstname.lastname@example.org.
EDITOR: Jack Ganssle, email@example.com
- Editor’s Notes
- Quotes and Thoughts
- Salary Survey
- Book Review
- Tools and Tips
- Joke for the Week
- About The Embedded Muse
I’ve been in this industry since the first 8 bit microprocessor appeared. In the intervening years the technology has changed in breathtaking ways.
The most radical change, though, is in how the business environment has been driving engineering. I’m not referring to the current economic woes; rather, communications technology has improved so that globally-distributed teams now work together to build a product. When I was a child a long-distance phone call (even one from an adjoining state) was so rare, and so expensive that the household came to a halt as dad took the call. It could take weeks to trade letters with a correspondent in Europe, and few of us knew anyone, other than soldiers, who had traveled outside the US and Canada.
Today it’s all but free to call any place on the planet, and the Internet means all of our data is always connected.
The result: a global competitive environment heretofore unknown that drives management to demand more, better, faster. If you can design an ASIC with 100 million gates and a million lines of C in a month, well, they’ll soon demand it in a week. And for good reason, as every company realizes that someone else will be looking for a way to get those kinds of productivity gains.
Sure, the economy is bad right now. You’re buried in getting a project done and don’t have time to find new ways to do things better. I’m reminded of the classic cartoon of a medieval battle being waged with swords and rocks; the general sniffs that he just doesn’t have time to see the salesman, who product is a box of machine guns.
More, better, faster. I think that’s the mantra that will drive this industry for the foreseeable future. How will you achieve those goals? Take a day to learn how to meet that objective. Learn how at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm .
Quotes and Thoughts
"The primary duty of an exception handler is to get the error out of the lap of the programmer and into the surprised face of the user. Provided you keep this cardinal rule in mind, you can't go far wrong." - Verity Stob, sent in by Harold Kraus.
Gads, it’s been three years since I did a salary survey. In these troubled times (getting better Real Soon Now, we hear) the data might be especially interesting. Please take this very short survey at http://www.ganssle.com/survey.html . I’ll share the results in the coming weeks.
I detested my college class on statistics and probability. The professor made no attempt to explain why the various sorts of tests were used, leaving many of us thinking this was an exercise in memorization. Besides, as an electrical engineer I’d never need any of that information.
Turns out that many embedded systems are instruments that handle messy real-world data. Sometimes that information needs to be analyzed for suitability to a task, or tortured into a curve-fit. Statistics is important in this industry, and too many of us come out of the university with plenty of distaste for the subject but insufficient useful knowledge.
Sarah Boslaugh and Paul Andrew Watters have a new book published by O’Reilly titled “Statistics in a Nutshell.” It’s the best book I have read on the subject. Though hardly lively (I still can’t get turned on by the subject) it’s very readable and accessible to anyone with basic algebra skills.
Most of the chapters end with the requisite problems, but what sets this book apart from many others is that complete solutions are presented as well, making the book idea for self-study.
The chapters are bite-sized, typically 20-30 pages, making it easy to digest an idea in a short reading session.
This is not an advanced text; it covers all of the basics of statistics. But it’s very accessible and highly recommended.
Tools and Tips
David Bley sent: “I have been using some software tools that have been very helpful to me. They are not embedded tools but helpful nonetheless.
“MWSnap - http://www.mirekw.com/ - This is a screen capture tool. It lets you capture a part or all of the screen and put the image into your word document. Great for manuals, procedures and instructions.
“EasyCAD www.fastcad.com This is a 2D cad package that is very powerful, easy to use, 1/10th the cost of AutoCAD and imports and exports DWG and DXF files. I use it for front panel layouts, PC Board outlines, sheet metal drawings, etc.
“Google TASKS Google has just added this task manager that goes wherever Google goes. You can have multiple lists, multiple indentions in a list, extended text notes and deadlines. When a task is finished, you check it and it lets you know what you have done. Look for it on the Gmail page.”
Scott Finneran contributed: “Peter Miller's srecord tool is interesting (http://srecord.sourceforge.net/). This isn't just a file format conversion tool and it certainly works with more file types than just Motorola S-Records. It is and incredibly powerful tool for manipulating binary files (ie firmware images). Just a few of the things it can do:
- Splice/Merge/Split binary files
- Convert file formats (with 32 formats currently supported)
- Calculate and insert CRCs/Checksums
- Chop/Crop/Filter/Move sections of files
- Correct malformed files generated by buggy toolchains
- And many many more.
“Because it is driven from the command line, it can be included in Makefiles (or IDE batch/script files) to automate the building of target images. It's used by Motorola and Intel for manipulating Motorola S-Record and Intel Hex format files. It runs under Linux/Unix/OSX/Windows. Best of all, it's Free/Open Source Software.”
Joke for the Week
Hippocratic Oath For Software Engineers:
Never write a line of code that someone else can understand.
Make the simplest line of code appear complex. Use long counter intuitive names. Don't ever code "a=b", rather do something like:
Never use direct references to anything ever. Bury everything in macros. Bury the macros in include files. Reference those include files indirectly from other include files. Use macros to reference those include files.
Never generate new sources. Always ifdef the old ones. Every binary in the world should be generated from the same sources.
Never code a function to return a value. All functions must return a pointer to a structure which contains a pointer to a value.
Load all sentences either written or spoken with alphabet soup. When someone asks you out to lunch, reply:
"I can't because I've almost got my RISC-based OSI/TCP/IP
client connected by BIBUS VMS VAX using SMTP over TCP
sending SNMP inquiry results to be encapsulated in UDP
packets for transmission to a SUN 4/280 NFS 4.3 BSD with
release 3.6 of RPC/XDR supporting our ONC effort working."
Never clean your office. Absolutely never throw away an old listing.
Never say hello to someone in hallway. Absolutely never address someone by name. If you must address someone by name, mumble or use the wrong name. Always maintain the mystique of being spaced out from concentrating on complex logic.
Never wear a shirt that matches your pants. Wear a wrinkled shirt whenever possible. Your shirt must never be tucked in completely. Button the top button without wearing a tie. This will maximize your mystique.