You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Fixing Stuff
• Lousy - and Great - Filesystems
• Boss Management
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm for more details.

Abraham Lincoln reportedly said that, given eight hours to chop down a tree, he'd spend six sharpening his ax. We engineers rely on our tools; I've always been of the opinion that great tools are worth the money. It's hugely important to keep them tuned. For instance, is your scope reasonably calibrated? My Agilent MSO can self-calibrate, but I also occasionally check it against a voltage standard and frequency generators. My work doesn't require traceable calibrations, but a sanity check now and then is just good engineering practice. For DMMs consider the DMMCheck, which I reviewed here.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Mark Chinski likes Atom:

The Atom web site says "Atom is a text editor that's modern, approachable, yet hackable to the core - a tool you can customize to do anything but also use productively without ever touching a config file."

Andy Maginnis recommends a series of videos:

Elden Berg had info about Tek scopes:

Paul Carpenter sent a link to an interesting article about IC reliability, and the new challenges posed by finFET transistors.

Cmicrotek is again offering a free uCP20 current monitor to a lucky Muse reader. This device is used to monitor current consumption of very low-powered microprocessor-based devices.

Enter via this link.

Fred Schneider has some thoughts on repairing gear:

Fred mentions tube testers - remember those? Every drug store had one. When your TV or radio failed you'd pull all of the vacuum tubes and take them to the store, testing them one at a time till the bad one was identified. Today stuff is, unfortunately, disposable. Our TV failed recently. I like to see how things work so dismantled it. There were three PCBs; one an obvious power supply. The others were fairly simple but sported huge chips that no doubt had mega-loads of transistors. Repairable? Perhaps by swapping boards, if they were even obtainable.

A friend took a number of pictures of the recent eclipse with his Canon SL1 camera. Somehow, probably due to writing to the SD card as the battery died, the entire filesystem became corrupt and he is now sending the card out, at great expense, to a service that will attempt to extract the images. Googling around, I found may photographic sites recommending against deleting individual files, and even more adamant advice that one should never delete files from the SD card when it's inserted in a computer rather than the camera.

Yet designing robust filesystems is a solved problem. Journaling filesystems are robust even in the event of an untimely power loss. The Wikipedia article is succinct: "... a journaled file system allocates a special area - the journal - in which it records the changes it will make ahead of time. After a crash, recovery simply involves reading the journal from the file system and replaying changes from this journal until the file system is consistent again. The changes are thus said to be atomic (not divisible) in that they either succeed (succeeded originally or are replayed completely during recovery), or are not replayed at all (are skipped because they had not yet been completely written to the journal before the crash occurred)."

A number of embedded vendors sell these safe filesystems. Micrium, HCC-Embedded and others sell filesystems that won't become corrupt when the inevitable bad thing happens.

Given that about a quarter of us write our own RTOS I suspect homemade filesystems aren't uncommon. Yet getting one right is a very difficult problem, especially when it comes to flash memory which needs wear leveling. It might be fun to write one's own filesystem, but that's simply a bad business decision. It'll be cheaper to buy one (in the long run... and in the short run).

Pity the poor engineer. The victim of capricious management decisions, bearing the brunt of the boss's mood swings, suffering when a supervisor's Prozac prescription runs out, and subject to random schedule and specification changes. Or perhaps the pointy-haired boss has sub-human intelligence and less common sense, subverting the developer's best efforts to get projects out.

Maybe the honcho is harried and distracted, generally unavailable and paying little or no attention to engineering till the day before scheduled shipping, perhaps communicating so poorly that this ship date suddenly surfaces as a big surprise to all but him.

Tales of dysfunctional, disinterested and quite insane management peppers the apocrypha of engineering. Many of us do know of a leader whose style is indeed quite psychotic, but I suspect that the stories far outweigh the reality. Most engineering leads come from the universe of us, and most of us are pretty reasonable.

It's true that hiring and promotion practice is flawed when supervisors come from the ranks of the supervised without regard to leadership ability and people skills. Raw technical talent is swell, but has little relevance to managing.

Doing the work, and managing the work, are two completely different skill sets that barely overlap. There's no question that engineering proficiency is useful to a manager, but it's also clear that the progression from engineer to manager means cultivating quite important very non-technical competencies.

It's a rare individual indeed who can be master of more than one profession, especially such disparate ones as people skills and microprocessor development, whose breathtaking advance leaves even the most dedicated of techies struggling to stay up-to-date. More often than not, engineers who successfully make the transition to management start to see their development skills atrophy.

And this, I contend, is a natural part of the scheme of things. Really great engineers keep their edge by studying the field constantly, and by honing their skills through steadily building new code, designing new circuits, and developing more systems.

Really great managers tune their skills by listening closely, monitoring and correcting their own and their people's mistakes, finding ways to provide needed resources, and helping their people be more productive over the long term.

A Venn Diagram showing the intersection of these manager and engineering skill sets would come up null.

So of course the boss has no idea what you're talking about when you discuss the merits of C++ versus C, or various ways of dealing with memory allocation problems. When his eyes glaze over that doesn't indicate he's an idiot; rather, it should merely raise a flag that you're communicating poorly.

I believe management is a two way street, at least when the managed are professionals who are as intelligent and as highly educated as their bosses. If you obediently respond to the boss, and wait for the "latest bit of nonsense from that idiot in the corner office", then either your company is quite broken... or you don't understand that the difference in skills, pressures and motivations between the boss and you means you've got to proactively manage the boss as he attempts to manage you.

But first I'd like to dispel a myth about management. As a young developer I bought into the general belief that the boss was an all-powerful creature who could fire at will, capriciously, maybe even simply to create a rule of terror. Though Stalin-like purges do occasionally happen, in these days of full employment the boss is hostage to the engineers. Losing a good developer is a nightmare; if one's poor people skills means turnover ticks up even a bit, then the boss will be in a world of trouble.

And yes, I recognize that bosses span the spectrum, occupying all niches of the bell curve. Some shine, others are ogres. In my experience most do honestly want to do a good job. Too many, though, are so battered by pressures from above and below that they have difficulty making decisions that do a good job of balancing technical and customer needs. The boss needs help from his people.

A sure way to gain your leader's enmity is to present him with problems and no solutions. Saying "Uh, the flash is full and we're still only halfway done with the code" is simply a form of slow career suicide. You are the expert. Your boss is relying on you to solve these sorts of problems. Engineering is all about solving problems, not shoving them off on someone else.

Give the boss some options; help him understand the tradeoffs behind each one. Don't expect this person to suddenly master the intricacies of FPGA design to find a way to route the part; present alternatives (a bigger part, different routing strategy, perhaps reducing product features, maybe partitioning the design differently).

I've been in innumerable meetings where problems surface and no one has thought through potential solutions. Creativity can come from brainstorming sessions, but that's generally among technical peers, not in a meeting with the boss, a secretary, and a couple of engineers. Come to meetings prepared to rationally discuss alternatives and their merits.

Give options and corresponding tradeoffs. If none are appealing, you may have to go back to the drawing board, but at least the alternatives you've considered, even if rejected, will narrow the universe of choices.

Present a problem without options and you can be quite sure that the ultimate resolution will be one you don't like. Give some well thought out choices and the odds are that the result will be one you can live with.

Yes, some problems are intractable or require resources that only a manager can bring to bear. Sometimes you may just be exhausted and need to talk; the wise leader will understand and let you babble (though not in a meeting with others), perhaps even if he understands little. Sometimes it makes sense to go to the boss just to talk things through.

Far too many years ago, as a young developer I worked on a new technology that few engineers, let alone managers, understood: microprocessors. Problems abounded; as the only micro person in the group no peer could give much advice. My boss wisely understood this, and listened patiently as I'd talk about problems. He had little to offer, but understood that the act of talking things out helped me form my own understanding.

The manager's role is to facilitate your work; there's a give and take, so sometimes babbling without solutions may be appropriate. Don't use such babbling to abdicate your responsibility to generally solve problems, though.

You cannot manage your boss if you speak in a language he finds foreign. The lingo we use with our peers is incomprehensible to most of the rest of the world, and all too often to the boss as well. If you want something - a resource, a schedule extension, or even time off - put your arguments in cogent English, not in some personal extensions of the C standard.

Too many developers use talking as a way to obscure communication. Instead of a concise problem description they start off with a review of header files, interrupt masks, and all sorts of details presented in a random sequence guaranteed to confuse the most savvy of listeners. In my opinion this indicates poor critical thinking skills and an inability to parse the unimportant from the important.

Ultimately both boss and employee must recognize their individual differences, strengths and weaknesses. Just as the wise supervisor is always subtly training his subordinates to move up, those workers should be teaching him the important parts of their jobs. Not that the boss needs to learn to write C code. Instead, we must teach him how his decisions effect the product development effort.

One example is scheduling. How often has your boss asked for an off-the-cuff estimate to incorporate an enhancement in a product? There's always pressure to respond immediately, yet we know that any such answer will, in general, be meaningless.

When building a new design we know that a schedule based on a day of design work will be worthless. Until you understand the scope of the project in excruciating detail you simply can't create a valid estimate.

And, yes, I understand that agile approaches can be very effective. But the boss may have very good business reasons for needing a ship date before the project is far along. Alas, there is an essential contradiction between management's and engineering's needs when it comes to schedules, one that I believe will never be resolved.

Bugs that appear late in the project drive managers berserk, yet all too often these are the same managers who chant "why aren't you writing code" from the outset of the program. Educate everyone, including your boss, that bugs will be maximized by skipping the thoughtful up-front work like code inspections and careful design.

Dilbert depicts the worst of dysfunctional management, and in so doing encourages us to laugh at all bosses. The comic is great fun but, by making a parody of the boss-employee relationship, further polarizes development groups into "us versus them" mentalities.

We do need bosses - at least good ones, who understand our challenges in a meaningful way, and who provide us with appropriate resources and guidance. We've got to recognize that the boss/employee relationship is one fraught with tension and change, that the boss's needs and pressures may not always coincide with ours. The resulting give and take can be either a nightmarish struggle or a recognized part of being employed.

If you're a frustrated employee today, recognize that someday you may be on the other side of the fence, faced with a higher level boss who cares about nothing but getting the product out and making a profit. How will you balance that pressure against the demands of your developers?

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

The great thing about Linux is that you can do anything with it. The problem with Linux is that you must be an expert to do anything.

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. 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.