When we design an application we like to have lots of on board resources on the microprocessor. There is a philosophy with embedded software development (especially in embedded systems) that everything must be as efficient as it possibly can.

This philosophy is necessary in specific situations. For example, if we want to specify a processor for an Ipod, we want to be very efficient in every thing we do because we will make millions of Ipods. Twenty years ago, computer hardware resources cost a lot of money, but today they are very cheap. So we try to weigh up the cost benefit of optimization through labor, verses cost of off the shelf hardware.

Sometimes the question becomes, do we use a $2.50 micro-controller and spend more man-hours to try to get a system to work, or a $5.00 controller that we know will work. Then there is also the consideration that we might like to add features and functionality in the future. One of the most important decisions in embedded system design is the processor specification, and we need to be aware of the trade-offs involved.

If only 50 products are sold each year, in the above example the client spend $125 extra. However, to optimize code for a cheaper controller might take two days or longer. The ROI would be measured in years, by which time the processor might change anyway.

Application specification and processor specification go hand in hand. If we only need to count pulses we don’t need 16 digital IO points. So, it is critical that application requirements and specifications are determined as early as possible. It is difficult to predict when an end user requires a new feature we have not thought of. We should try to elicit every possible function the user may require and make provisions for them or decide to exclude them. Although, in the real world embedded software engineers are working to deadlines and requirements they have in front of them and not potential requirements that may never get off the drawing board.

In reality we usually have a good estimate of the micro-controller family or class we are going to use, especially for high level peripheral applications like GPS, modem, pulse counters, etc. Our next job is to start looking at the embedded software design data flows and logic algorithms. We have a process for gathering requirements, which is the most important and sometimes very time-consuming part of the software development life cycle. So, it is best when you the client have a very good idea about the real world inputs needed to obtain the results required.