Embedded Development Tools - editorial

The debate about development tools rages on. No, there's little misunderstanding at the engineer level; its the manufacturers that are still a little fuzzy about the whole thing.

Let's review, the basics, shall we?:

• You can't use the microcontroller, no matter how wonderful it is, if you can't program it.
• Nobody likes to use beta tools - how can you tell if the problem is with your code, or with the development tool?
• Generally, more sophisticated applications require more sophisticated development tools
• Simple engineers use simple development tools
• Experienced engineers will use both sophisticated and simple tools
• Everybody wants easy-to-use, bug free tools
• Both large engineering companies and small engineering companies have the same lack of tolerance for poor quality tools.

Over the past few months I've spoken to several microcontroller manufacturers about this issue. Many have excellent products, but poor quality tools. While management is willing to spend $200K - $500K developing a new microcontroller derivative of this family, no one wants to spend this same money on quality development tools. The concept seems to be "we'll target only the high volume customers, and baby sit them thru the development tools process".

Big mistake. Bad strategy, bad bad bad!!!

First of all, this is based upon the flawed premise that engineers at large companies are more tolerant of poor quality tools than engineers at smaller companies. This is analogous to a guy in high school who knows he has a crappy car, so he's only going to date the best-looking girls...

Having an amazing microcontroller architecture with lousy development tools is like owning a Porsche Turbo Carrera with no steering wheel. All that power, and no way to use it.

Because they know they control who will eventually receive a high-dollar PO, the embedded systems engineer at a larger company expects and demands superior tools and service, because he/she knows that a phone call will get them a development kit and support from any local FAE almost immediately. Remember, microcontroller marketing people, embedded systems engineers aren't intent on designing in your latest greatest micro - they didn't go to work that morning with the intent of doing you a favor. According to demographics, engineers want the following:

• A sense of accomplishment upon completing their project
• A no-hassle development process
• A chance to go home before the sun goes down

Poor development tools are counter-productive to all of the above goals.

But wait, there's more! There are some engineers out there that are... oh, how shall I say it... "technically challenged". (side note - when I worked for SGS-Thomson, a co-worker and I worked with a customer engineer that was so clueless that we nicknamed him "Rustle" - ask him a question & all you heard was the sound of the wind thru the leaves. Q: "How many bits is the 68HC05?" A: whooshhh-rustle-rustle-whoooosh) For the "technically challenged", your tools have to be extremely easy to use - especially the emulator. If the engineer can't use it, you won't get designed in. What are you going to do, complain to the guy's boss that his subordinate is too stupid to use your product???

But wait, there's more - while it's the responsibility of the microcontroller manufacturers to fund development for the best-quality 3rd party tools they can obtain, its the responsibility of the development tools manufacturer to see that the tools are bug-free and do what they're supposed to do. If a 3rd-party tools manufacturer wants you, the semiconductor manufacturer, to pay for fixing bugs in their own tool product, then its time to review the contract you have with that manufacturer and make sure they are living up to their end of the bargain.

Sound harsh? Yes, it is. But I've lost patience with poor-quality tool vendors that want the semiconductor manufacturer to pay for tool vendor's poor quality and lack of attention to the product line. Engineers are less interested in fancy new features and more interested in in having the existing features work properly.

At the September 1987 Shadows of Iga martial arts festival, as a fledgling engineer (sniff!) I listened carefully as Grandmaster Masaaki Hatsumi angrily condemned the practice of "earning" a black belt through videotaped teachings. Well, I'm just as emphatic now - you can't learn a microcontroller architecture with buggy development tools. Learning an architecture with buggy development tools is like earning a back belt with videotapes - you simply can't trust the results.

Granted, 3rd party tool vendors aren't in the charity business. Expect to pay a hefty NRE for a compiler or emulator if your microcontroller has a total of six customers, regardless of volume. Remember - a tool vendor would rather you have 100 customers buying 5Ku/year than five customers at 100Ku/year - because the tools manufacturers don't make money off of your total product volume, they make money off your total number of customers. But once the contract is signed, tool vendors shouldn't complain that the volume is too low to address bug fixes. Remember, those poor-quality tools are out there amongst customers degrading the reputation of the rest of your (high quality?) product line.

And to the embedded development engineers that want free tools I say this: try building your own C compiler then see how you feel about giving it away. The development tools business is a low-volume low-margin marketplace that requires highly specialized skills to succeed. Very few people get rich making emulators and C compilers - most development tools manufacturers are in the business for the challenge and the pleasure of making the stuff. But engineers that really know how to make a high-quality optimizing compiler suite, or build a high-speed real time emulator with trace, are very, very rare individuals. Expect to pay for the fruits of their labor if you want a carefree development experience.

This is the reality that we, as embedded systems developers, must work with.

Bill Giovino is Executive Editor of Microcontroller.com
31-Jan-2000
 

• Embedded Development Tools - Editorials and News Commentary