Business
How to choose embedded tools
Three tips for choosing the right tools for your next embedded project.
Choosing embedded software tools, such as assemblers, compilers, and linkers, can be quite daunting. Sometimes the decision is made for you; for instance, when there's only one tool-chain available, the semiconductor manufacturer sells it, and it costs a small fortune. You're forced to pay the big bucks and move on.
But how do you choose embedded tools when there are options? Here are three tips:
1. The more you pay, the worse the tools
My first rule is to buy the cheapest tools that work. I don't mean that you should skimp on tools; it's just that the most expensive tools aren't necessarily the best. Actually, it's been my experience that the more you pay for tools, the worse they are.
This surprisingly makes sense: Expensive tools are usually costly because a small user-base or a complacent vendor--or both--sustain them. That's a recipe for unreliability. (And guess who winds up finding the bugs?)
2. Count the users
I recently made the mistake of following this "cheap is best" advice too blindly. I was tempted to replace a $10,000+ software tool-chain (which wasn't fancy, except for the price) with some new alternative development tools that cost a few hundred dollars. The new tools promised to do the same job at a fraction of the price. At that price, we could afford to have a copy for each developer, instead of having a single tool tied to one PC.
I placed the order, the software arrived, and I duly put it through its paces. Several days later, I still couldn't persuade it to build a simple real-life project. The tool-chain was bug-ridden. The vendor fixed the bugs promptly but we found more--and so it continued. The low, up-front cost of a few hundred dollars was eclipsed by the cost of downtime we spent trying to get it to work. I gave up and returned to the mega-buck tools.
What happened? Though the tools were cheap, I overlooked (or chose to ignore) that the tools had very few existing users, just like some of the expensive counterparts. I was back to being a beta tester on someone else's project. I should have asked the vendor to supply references, i.e., some real users who could speak about their experiences with the tools.
Don't be afraid to ask for references (and follow up on them) if you find yourself in a similar situation.
Some companies get things right. Microchip is a case in point; it offers good tools at reasonable prices. However, most semiconductor companies don't get it. I dislike paying a premium for their tools just for the privilege of being able to design their hardware into end products. I also object to paying even more for dongles and sub-standard, glossy-looking text editors, when all I need are reliable command-line tools at a reasonable price.
3. Open source wins
The logical solution is to use freeware or open source tools when possible. These tools are free, you get the source code, and the tools usually have many users.
Picking the right embedded tools can be a difficult process, so take your time. The wrong choice can hit your project hard where it hurts: in bugs and missed deadlines.
David Brenan is an independent embedded systems developer with more than 15 years of experience. His work includes the design of award-winning professional digital audio products.
But how do you choose embedded tools when there are options? Here are three tips:
1. The more you pay, the worse the tools
My first rule is to buy the cheapest tools that work. I don't mean that you should skimp on tools; it's just that the most expensive tools aren't necessarily the best. Actually, it's been my experience that the more you pay for tools, the worse they are.
This surprisingly makes sense: Expensive tools are usually costly because a small user-base or a complacent vendor--or both--sustain them. That's a recipe for unreliability. (And guess who winds up finding the bugs?)
2. Count the users
I recently made the mistake of following this "cheap is best" advice too blindly. I was tempted to replace a $10,000+ software tool-chain (which wasn't fancy, except for the price) with some new alternative development tools that cost a few hundred dollars. The new tools promised to do the same job at a fraction of the price. At that price, we could afford to have a copy for each developer, instead of having a single tool tied to one PC.
I placed the order, the software arrived, and I duly put it through its paces. Several days later, I still couldn't persuade it to build a simple real-life project. The tool-chain was bug-ridden. The vendor fixed the bugs promptly but we found more--and so it continued. The low, up-front cost of a few hundred dollars was eclipsed by the cost of downtime we spent trying to get it to work. I gave up and returned to the mega-buck tools.
What happened? Though the tools were cheap, I overlooked (or chose to ignore) that the tools had very few existing users, just like some of the expensive counterparts. I was back to being a beta tester on someone else's project. I should have asked the vendor to supply references, i.e., some real users who could speak about their experiences with the tools.
Don't be afraid to ask for references (and follow up on them) if you find yourself in a similar situation.
Some companies get things right. Microchip is a case in point; it offers good tools at reasonable prices. However, most semiconductor companies don't get it. I dislike paying a premium for their tools just for the privilege of being able to design their hardware into end products. I also object to paying even more for dongles and sub-standard, glossy-looking text editors, when all I need are reliable command-line tools at a reasonable price.
3. Open source wins
The logical solution is to use freeware or open source tools when possible. These tools are free, you get the source code, and the tools usually have many users.
Picking the right embedded tools can be a difficult process, so take your time. The wrong choice can hit your project hard where it hurts: in bugs and missed deadlines.
David Brenan is an independent embedded systems developer with more than 15 years of experience. His work includes the design of award-winning professional digital audio products.