Race Cars vs. Embedded Processors

[JTurl]

I drive race cars on the weekends, and there's an old saying in racing: You can have a fast car, a reliable car, or a cheap car – pick any two. In other words, your race car can be fast and reliable, but it ain't gonna be cheap. Or it can be solid and (relatively) affordable, but not fast. You get the idea.

The same axiom tends to hold true in the electrical engineering world. You can have the latest cutting-edge technology, *or* a solid and reliable product, *or* a cost-effective solution, but not all at once. Super-advanced technology is generally unreliable and expensive. Safe technology is typically dull; and developing a low-cost product will make it slow, boring, and unreliable. So which compromise do you pick? Fortunately, engineering is not a zero-sum game. There's no physical law that says we can't have fast, reliable, and cheap all at once. That's just our somewhat cynical observation. It seems like too much to ask, but is it really? When you meet a beautiful, talented, attractive, intelligent, and accomplished person at a party, they seem like a paradox. How that that person have looks, brains, and charm all at once? Life, like engineering is not a zero-sum game. You don't necessarily have to give up something to gain something else. Which brings me around to my second-favorite favorite topic: choosing microprocessors. Most engineers and programmers treat the choice of CPU as either (a) a foregone conclusion, or (b) a trial to be endured. Very few treat it as, well, a treat. Personally, I love picking out CPU chips, but maybe that's just me. Picking your next processor doesn't have to be miserable. Just think about what characteristics you really want, and start to eliminate the chips that don't deliver. Setting aside preconceptions is an important start, because we've all got ingrained notions about what chips are or aren't our favorites. For most developers today, the software tool chain is the most important part. They really, really, want to retain their familiar compilers, debuggers, linker, and so on. That's reasonable; we spend more time with our hands on the tools than on anything else. So sometimes the first step in picking your favorite chip is to not start with the chip. http://www.intel.com/content/www/us/en/intelligent-systems/industrial-applications/time-money-talent-pick-any-three-paper.html?wapkw=time%2c+money%2c+talent There's a good story about an engineering-services company that just went through this process, here. Next, you want to reuse (or in marketing speak, leverage) all the talent that you and your colleagues have already got. No point in turning everyone into a beginner. Third, you'll want a chip family that's well-known and well-supported, so that you can ask questions, get technical support, and hire people with experience. Trying out something new means foregoing all these benefits and blazing your own trail, and while that might be fun, it's also a recipe for delays, cost overruns, and frustration. You know the old saying: the trailblazers are the guys with the arrows in their backs. Syntronic, the company I mentioned above, weighed all these factors and more, and came up with what they felt was the best choice: an Intel x86 chip. That's because (a) everyone was familiar with x86 architecture; (b) software tools were easy to come by; (c) there was a long upgrade (and downgrade) path to faster or smaller chips, should they need to do that; and (d) support was easy to get. Taken all in all, Syntronic felt like x86 was not only a safe choice, it was also the most high-tech choice. You see, you can get fast, safe, and cheap all in the same package.