During the life of a project, you'll come to five forks in the road where you'll make major and irreversible decisions that can set you on the path to success or failure.
Any embedded system worth the name includes a few dozen components and a few thousand lines of code. Most products are one or two orders of magnitude more complex than that. That complexity represents a lot of labor and also a lot of decisions.
Some component choices are trivial (“what resistor do I use here?”) while others can be either product-defining or career-limiting. Likewise, some lines of code can feel like typing exercises while others are elegant and powerful works bordering on software sonnets.
As I see it, there are five of these major decisions in every embedded project. Five choices that have the most effect; five that bear most directly on your product and its development. Five irreversible decisions from which there is no going back.
Processor. Although I'm listing the processor first, it's not always (or often) the choice developers make first. But it is irreversible because it's almost impossible to change processors partway through development without throwing out most of the work you've done and starting over. All the hardware that touches the chip will change and most of the software will, too. Changing processors midstream is disastrous, so choosing the right chip (or chips) is key. This decision lives on long past the current product's life cycle.
Operating system. Once you choose an operating system, kernel, real-time executive, or scheduler the software die is cast. There's no going back without ripping up and restarting software development. Even hardware options can depend on your choice of operating system. In a recent study, embedded systems developers across the country said they rely on their operating system more than on any other component or tool. Change the operating system, they said, and all bets are off. The operating system often dictates the choice of processor, not vice versa.
System logic. Often dismissed as mere “glue logic,” I think the choice of system logic is important. I'm talking here about core-logic chipsets, programmable logic, FPGAs, and other hardware outside of the peripherals and processors. The decision of whether to use FPGAs, for example, can have major repercussions downstream that effect your staffing, your debug options, your performance headroom, and your upgrade path.
Development tools. No programmer denies the importance of good tools (only inexperienced managers do that). Unfamiliar or incomplete tools can make a whole development team cranky and inefficient. Downright buggy tools can wreak severe economic damage, as well as damaging the reputation of the developers.
Bus interfaces. System buses, board buses, and I/O buses all define the boundaries of your product. They're the border patrol, the gate keepers. They decide what can and can't connect to your product, both internally and externally. Choose the right buses and you're ready to expand as new chips, peripherals, or add-on products become available. Choose the wrong buses and you're at a dead end, inventing custom chips and custom software stacks when you could be working on something more interesting.