3. When choosing a microcontroller, software comes first.
The microcontroller (MCU) is the brain of every embedded system. Using an onboard analog-to-digital converter, it can read analog signals, "talk" to sensors, and then decide what the embedded system should be doing. So the microcontroller needs to be chosen on the basis of its hardware capabilities -- right?
Wrong, according to microcontroller suppliers; even for the MCU, software is king.
"When it comes to selecting microcontrollers or digital signal processors, there's much more to the part than just the core," said Jennifer Barry, MSP430 product marketing engineer for Texas Instruments, which makes MCUs and DSPs. "The key part of the decision is figuring out what the application needs are in relation to the software."
When embarking on an embedded development project, the first thing engineers should look at is its communications. Will it be communicating over wireless systems? USB? Ethernet? WiFi-based systems usually need DSPs or high-end MCUs, whereas USB-based systems are less software intensive, Barry said.
The choice of MCU goes beyond such considerations. Barry said today's MCUs are not just processors -- they're compilations of features specifically designed to address every part of the project, including the software development.
"Today, the microcontroller is an ecosystem -- the IC and the development tools," she said. "Of course, you're going to need the IC to do your performance and features, but without the software tools, you'll get nowhere."
4. You need a clear idea of your requirements.
In many embedded projects, engineers start writing their code before they have a clear idea of what their product will do. Then they add features along the way. Ganssle said this approach, however commonplace, is a prescription for trouble. "You have to have a really clear idea of what your requirements are, and for some reason that's usually not done. People start writing code, and then they're not sure what they're supposed to do, and then they're surprised when it doesn't work out well."
To determine what's required, Ganssle recommends these rules of thumb: Features must be testable and unambiguous, and customers must be willing to pay for them. Development teams should never add a feature simply because it's possible to do so. "From the outset, you should have a clear view of exactly what the product will do, spelled out in the simplest possible form."