Maintaining a single codebase between embedded and non-embedded code [closed]

Question

I'm working on a robotics research project that involves programming a microcontroller. I'd like to be able to decouple testing the software from testing the hardware to the greatest extent possible. This is both to increase development speed and also so that I can more easily unit test/simulate the code before putting it on the robot. So for example, I might write a "MyRobot" library. Then I could include this library both in the embedded code and my non-embedded simulation/testing code. At runtime, I'd provide function pointers that would either read (in the embedded case) or simulate (in the simulation) sensor data and feed that into the library.

So it seems like all I would need to do is generate two libraries at compile time: one for the embedded code, and one for the non-embedded code.

My question is whether or not this is feasible/if there are better ways to do it/if there are any gotcha's I should watch out for.

Thanks in advance!

Answer 1

This is a common situation in embedded systems development, and your approach of creating two libraries is usually the recommended solution. It's considered a best practice to decouple the low-level hardware from the software in embedded systems firmware.

The library you mentioned is commonly known as a "Hardware Abstraction Layer", or HAL. The API (application programming interface) for the HAL can be provided in a single header file named something like hal.h. Every source module in your software that needs to access the hardware would have the following line at the top of the source file:

#include "hal.h"

Benefits of designing your system like this include:

• Modularity. If you need to make a timing change on, say a UART or SPI interface that reads a sensor, you only need to change the HAL library even though there may be multiple locations in your code that read that sensor.
• Portability. If you later need to migrate your project to a different microcontroller, only the HAL layer would need to change.
• Encapsulation. The details of the hardware are hidden within the HAL layer, which allows your other software to operate at a higher level of abstraction. If you are using a device library provided by the microcontroller manufacturer that provides the addresses of registers, I/O ports, etc., you can encapsulate the references to this library within your HAL library, so that your application code need have no knowledge of it.
• Testability. This was the primary focus of your question. You can write a special version of the HAL layer that can be run on a different platform (such as Windows, for example) for testing of your application software. This special version would not need to include the device library provided by the microcontroller manufacturer, because when you are running in the test environment, the microcontroller doesn't exist, so its registers and I/O ports don't need to be accessed by your software.

For your two scenarios, as you suggested, you would create two versions of the HAL library: the standard version that contains the code that runs on your embedded hardware, and the simulation version that simulates the hardware for the purpose of testing your software in a controlled manner. You might name the standard library hal.lib (perhaps with a different extension depending on your development environment), and the simulation library hal_simulated.lib. Both would have the same interface, as described in hal.h. That is, both libraries would contain all functions declared in hal.h, such as void halInit(), int halReadProximitySensor(), etc.

Assuming your IDE supports Release and Debug configurations, you could create a third configuration for your software testing that is named SW_Test. This configuration would be a duplicate of your Debug configuration, except that the hal_simulated.lib would be linked into the project instead of the standard hal.lib.

See also

Hardware Abstraction (Wikipedia)