Where do you begin?
When you start a project, there is at least a small set of driving ideas or requirements. This is the time to begin designing a hardware-free system. What are you trying to accomplish? What is the end goal? What is going to be driven, monitored or controlled? Once you encounter some hardware, work out all the pieces in the signal chain.

Each piece of hardware you find that connects to another piece of hardware is a potential point of disruption if it is swapped for another. Isolate each piece of hardware within a wrapper or interface. For a motor control design, look at the algorithm. What are the pieces of data used to determine the drive commands?

To the control algorithm, these should always look logical, no matter what hardware is used, whether it is a load current in amperes, or a speed in revolutions-per-minute, or a drive command in percent.

Between the hardware and the algorithm, a load current is converted to a voltage, which is sampled by an ADC and becomes a digital count, which is converted by a math function to milliamperes; each of these steps need to be "wrapped" to eliminate the impact to the software application if the underlying hardware changes.

If you follow this path throughout your design process, at the end you will see two things. First, you will see how your hardware relates to your final system, and therefore understand how a new, similar but different, project can benefit from your work. Second, someone designing a brand new project in a completely different type of application can take your project and adapt it to fit their project, replacing or removing layers that change due to the new application.

That big, complex, board support package for the microcontroller that used to be the domain of a single whiz-kid or specialty group (who always seems to be too busy to make changes when desired) has now been logically de-constructed and piece-wise associated with the functions it serves, enabling this knowledge to disseminate to the entire group.

Remember how back in college, even if you didn't get the right answer on an exam, if you worked through the problem in a clear, logical, methodical and organized fashion (comments helped, too), you still could get a fair amount of partial credit on an exam? The same is true here.

While you do not need to be rigidly organized, if you collect your wrappers and interfaces together logically, you can replace actual hardware pieces easier. For instance, If you collect all the wrappers and interfaces that are directly associated with your microcontroller in one place, changing the microcontroller at the last minute becomes easier than if these are sprinkled throughout many files.

How it works - by example
Let's take an example application, a fan whose speed is monitored and controlled according to temperature, and try to walk through the design process, designing-out the hardware as we go along. As we begin the project, the few things we know are that

1) we need to get a temperature reading,
2) we need to compute a desired fan speed based upon temperature,
3) we need to get a current fan speed reading,
4) we need to compute a new fan command based upon the current fan command and error between the desired and the current fan speed reading, and 5) we need to put the new command out to the fan.

Figure 1 below shows the logical block diagram of the system. The rectangles are hardware dependent, the ovals are not. The way this is shown, a control engineer can begin system development, perhaps using a simulation package like MatLab, and the results of his/her work can directly feed into the end design (especially if it is written in a high-level language like C which almost every microcontroller supports).

Figure 1: Simple Fan Control System

Now as the project proceeds, a decision is made to use a thermistor as the temperature sensor (maybe because it is cheap, or it has specific desirable properties).

Looking at Figure 2 below, the "Get Temperature" rectangle is expanded into separate hardware dependent functions associated with the thermistor design, including the hardware characteristics of the thermistor and its interfacing circuitry.

Temperature is represented by the device as a resistance, with signal conditioning circuitry the resistance is represented as a voltage, using the ADC described the voltage is converted to a count value between 0 and 4095, and with software the counts are converted to a temperature in a machine-storable representation (for instance fixed point value temperature with the resolution of 0.1 degrees Celsius).

We have put the temperature into a data store so that its value can be updated asynchronous to the control algorithm. This makes the temperature always as current-as-possible for the control algorithm and better isolates hardware from software.

Figure 2: Thermistor Sensing Details

Later, it is determined that for this design, the microcontroller will not be near enough to the temperature hot-spot to use a thermistor, running the analog lines all the way from the thermistor to the microcontroller pins introduces too much opportunity for noise and signal loss.

Instead we will install in the temperature zone an integrated circuit, an LM75 I2C temperature sensor, that converts temperature locally and provides a digital value onto an I2C bus as a slave device.

Now in order to get a temperature, as shown in Figure 3 below, we have to enable I2C master communications hardware in our microcontroller, read a particular set of registers in the LM75, convert the temperature from native representation (the least significant bit represents 0.125 degrees Celsius) to our previously chosen temperature representation (fixed point value temperature with the resolution of 0.1 degrees Celsius).

Figure 3: I2C Digital Temperature Sensor Details

Because we isolated our control software, even from the actual rate at which new temperature readings occur, the control application software has not been impacted at all by this hardware change.

And any peculiarities associated with the LM75 can be tucked into one of the blue rectangles of Figure 3 above, exposed to scrutiny and verification without having to disturb the control software.

For instance some of these devices start a new conversion each time the I2C master reads the temperature value/register and if this access occurs too fast or too often, the LM75 will not finish a conversion. The control algorithm doesn't need to care about these details.