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
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.