Go here to sign up for The Embedded Muse.

Embedded Muse 196 Copyright 2010 TGG May 17, 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 .

The Embedded Muse is going on vacation for the (northern hemisphere) summer and will resume in August. I hope everyone has some quality vacation time.

Quotes and Thoughts

Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code. - Eric Raymond

On Honesty in Resumes

John Black responded to my comments last issue: "I have always enjoyed learning how to do new things, and early in my career I recall telling one of my fellow engineers that it was always my ambition to "get someone to pay me to do something I don't know how to do." When I was unsuccessful at getting my employer to put me to work on something I wanted to learn about, I would find a way to learn on my own time. For example, when I was working for Sperry Flight Systems and Motorola introduced the 6800 microprocessor, I built a 6800-based computer at home, and learned how to program in assembly code.

"That "extracurricular activity" got me a job as one of the first 3 engineers in Motorola's new Microsystems Department. During my subsequent years at Motorola, as I rose from engineer to project manager to department manager, I witnessed many cases where my colleagues would search through dozens (sometimes even hundreds) of resumes, looking for the person with "just the right" experience. However, I felt that what makes valuable employees is not so much the knowledge/experience that they enter my door with, but how readily they are able to educate themselves to take on the task that needs doing.

"In today's fast-moving technological marketplace, skills that are highly valued today rapidly become outdated. I would much rather hire someone who is eager and able acquire new skills, than to hire someone who has acquired a specialized skill, and intends to continue doing that for the foreseeable future.

"So, what to put on a resume? Rather than anguish over "what I currently know" (which is going to change anyway) I would emphasize how I have educated myself to do a wide variety of tasks, and that I am able to learn quickly as new challenges arise. What smart potential employer would not value that? (If a potential employer would rather keep looking for a person with exactly the right skills, I wouldn't want to work for him anyway."

Steve deRosier wrote: "The line on resumes is simple: don't lie. It does your potential employer a disservice and starts the new relationship out on a false foot. It's simply unprofessional and wrong. And if that's not enough, it hurts your career, even if not found out:

"Imagine if the previously mentioned "analog engineer" had not lied on his resume. His skills as an analog engineer were "adequate but less than stellar". And that likely had an impact on his future career path. Perhaps he was passed over for promotions, raises, etc. Or had a difficult time moving on later in his career to digital design. If instead he had gone to work in a more appropriate job, perhaps he'd have had a position he could have shined in.

>> it's still rather hard to prove that Joe Coder never actually did
>>write the Linux TCP/IP stack.

"This of course assumes that Joe Coder isn't lying about who he/she is...

"The best resume polishing advice comes from the career tools podcasts at: http://www.manager-tools.com/podcasts/career-tools ."

Superprogrammers

From a reader who wishes to remain anonymous: "You mentioned that superprogrammers get lost in big projects because of the required high-interactive nature of the size of the team. I have seen that in the company that I used to be employed with but am now working as a contract worker for them. As a non-company employee, I am not invited to weekly or monthly company meetings nor am I given managerial, architectural, or team lead responsibilities with their associated interactions with others. Instead, I get to sit at my desk and be productive.

"I have surprised the company's manager on several occasions because of how I have been able to complete the various programming tasks, often way ahead of schedule, and with good-quality code, as compared to the company engineers who are mired in the big-team bog-down that you discuss. I have enjoyed it because I, as a self-proclaimed superprogrammer, am operating in a very efficient, productive, and low-interruption environment. It jives with what you said."

Tools and Tips

Ray Keefe recommended a number of tools: Resource Standard Metrics http://msquaredtechnologies.com/ - This is a very versatile tool. We use it for coding standard conformance verification, code quality metrics, ensuring copyright notices are present in every file, general coding metrics and as one of the inputs to every code review we do. It is free for up to 20 files and USD$200 for anything bigger. For C and C++ development this is one of our mainstay tools for reviews and project metrics.

PC-Lint http://www.gimpel.com/ - This tool languished for a few years but has recently been brought fully up to speed and maintained again. It is great for catching coding issues and classes of bugs that are common. Once again, an invaluable input into our code reviews.

Ultraedit and Ultrastudio http://www.ultraedit.com/ - We use both. A very complete editor with a wide range of features and at an extremely good price point. The flexible formatting features as well as the clipboard history system, functions tracking, macro editing, searching including use of regular expressions and the general editing behaviour that supports the way programmers want to edit make this a real productivity booster.

For project level behaviour, Ultrastudio is great. Many embedded toolsets are getting better IDE's these days but most of them are not up to the level you need them to be. So this is the answer. All the editing capabilities of Ultraedit with the ability to manage project level builds and including autocomplete and structure element completion. A real time saver.

Duplo http://duplo.sourceforge.net/ - A sourceforge project published under GNU GPL this finds duplicated blocks of code. The idea is to refactor common blocks of code to make projects more maintainable. You can select the number of consecutive identical lines required for a match. It strips comments before comparing and also ignores white space so it is looking at just the code. The weakness is that it treats variable names the same as it does keywords so if you name your loop variable differently then it will look different to Duplo. But we still use it at the project review level to identify ways to make the software more modular and more maintainable for the long haul.

Doxygen http://www.stack.nl/~dimitri/doxygen/ - We are huge fans of this product. It is a great way to document code and also to examine code you are unfamiliar with. It will document code without the included documentation specific comments however it really comes into its own when you do included them. You can also add graphical call graphs and caller graphs and it shows the structure of the include files graphically as well. You can also select whether to inline the code with the documentation or keep them separate. And it creates references for every define, macro, variable and function in the entire project.

For the graphics make sure you also install the Graphviz tool http://www.graphviz.org/. Free and very comprehensive. With this, you can embed state machine, flow charts and execution or data flow diagrams directly into the Doxygen documentation and you need it to get the best results from the other graphics Doxygen produces.

And both are free. Highly recommended.

Snagit http://www.techsmith.com/ - We also use this screen capture utility and it saves a lot of time. Our primary use is generating documentation of programming procedures, testing procedures and program operation. The ability to capture the current window so we can paste it into the documentation is a real time saver and it operates quickly and efficiently with a range of graphics tools for adding features like arrows and text labels. Great for capturing a PCB from our CAD package then adding arrows pointing to test points with annotations about what the test point is for and colour coding the lot to make it easy to identify the test point.

Also great for capturing the details of bugs so you can send of bug reports with evidence from their own windows.

SciLab http://www.scilab.org/ - This is an open source project with a GPL like license. If you want a tool to do maths like Matlab but the license cost is prohibitive then this is one of your options. It is not 100% Matlab compatible but is close in many areas and easier to use than other tools like Octave. It includes a LabView gateway.

Bruno Muswieck has an alternative to Crystal Revs: I found a free tool to convert the code to flowchart and the structure of the program on tree view style. Using a print to pdf tool you have a good tool for documentation and to help you to understand code. It's a nice tool not so powerful like Crystal, but it's for free, nice!
EasyStructure http://www.ablegoldcomputers.com/

A related funny but true story: I had been using this gem of a tool at work, recently was working with a bright guy from another company. We had to do a conversion, and I said, Wait, Ive got this great tool on my PC. This guy looks it over, tells me to look at Help/About, and there in black and white it says Copyright 1994-2010 David Bernazanni. I almost fell off my chair the guy that I had been working with was the author of this tool that I use every single day! Its freeware, although you can make a simple $5 donation via PayPal if you want.

Shalom Bresticker wrote: Since you have an item in the Table of Contents for Verilog, you might want to list http://www.veripool.org/.

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.

Joke for the Week

From Edward Gibbins: The other day a colleague asked me for some pointers for dealing with a difficult manager in the company....

I suggested 0x0000A4F5, 0x00008EEF and 0x0000B32A.

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.