There are, broadly speaking, two distinct approaches to the design of software: bottom-up or top-down. It is most common to approach it top-down. Design, say, the user interface first and the underlying functionality afterwards. The implementation of the design – the actual coding of the software – is another matter.

There is some logic to doing the implementation top-down – following the logic of the design. This would involve creating the high-level functions first (like the user interface) and leave the lower-level functions as “stubs,” initially. When developing desktop software, I have always liked this approach, because initial progress seems rapid; the software “comes alive” and does something visual early on. There are clear psychological benefits here.

With an embedded software application, this is less likely to be possible for two reasons:

1)The lower-level software (start-up code, operating system, middleware, drivers etc.) needs to be in place before anything can really run.

2)All embedded systems have limited resources.

It is the second reason that really drives a bottom-up implementation. There is normally a fixed amount of memory, a specific amount of CPU power and a power-consumption (energy) budget. If the software is developed top-down, as resource limit may be hit at a late stage in development, when there is little opportunity to address it.

Developing the software bottom-up entails the creation of a series of increasingly complex components. The resource utilization of each component can be measured and optimized straight away, which mitigates the possibilities for surprises at a later stage. The measurements need the right skills and tools:

• Memory footprint is normally easy to read from the linker map. This is a zero-cost option, that simply requires the engineer to be aware of the requirement.
• Measuring the performance (speed) of software is more challenging. An instrument like an oscilloscope was traditional but is a rather frightening option for many modern developers. Using CPU tick timers or instruction-accurate simulation tools are other options.
• Power consumption is an increasingly important facet of embedded software development. Power measurement tools should be available to enable developers to optimize the power profile (CPU voltage/frequency, peripheral shut-down and standby/hibernate usage, for example) to be fine-tuned.

I am sure that there are other perspectives and arguments against my proscription ...