When developing embedded software, one of the most critical components is the Board Support Package (BSP). ​ In this article, we’ll explore what a microcontroller BSP is, why it’s important to avoid direct referencing, and how the concept of an Indirect BSP can simplify development and improve maintainability. ​

What is a Microcontroller BSP? ​

A microcontroller BSP (Board Support Package) is a software layer that abstracts the hardware details of a microcontroller and its associated board. ​ It serves as the interface between the hardware and the software application. ​ Here’s what a BSP typically includes:

• MCU Registers Abstraction: Provides access to the microcontroller’s registers. ​
• Board Schematic Abstraction: Maps the hardware design of the target board. ​
• Compiler-Specific Toolchain Code: Includes code specific to the compiler, such as the vector table. ​
• Vendor-Supplied SDK Code: This also include code auto generated by MCU vendor tools like ST’s Cube or Microchip’s Harmony. ​

Key Characteristics of a BSP

1. Specificity: A BSP is tailored to a specific MCU, board, and even PCB revision. ​ It is the only layer with direct knowledge of MCU registers and compiler-specific code. ​
2. Encapsulation: It encapsulates the MCU vendor’s SDK. ​
3. Application Independence: A BSP should not contain application logic and must remain independent of any specific application. ​
4. Minimalism: The BSP layer should be as small and thin as possible. ​
5. Non-Reusability: BSPs are not intended to be reused across different hardware targets. ​ Each new hardware target requires a unique BSP due to the nuances of individual boards and revisions. ​

Why Indirect Referencing is Important

Directly referencing BSP headers in driver code can lead to maintenance challenges, especially when transitioning between hardware platforms. ​ For example, if you develop a driver for an evaluation board and later switch to a custom-designed board, direct references to the evaluation board’s BSP would require code changes to the driver. Which in turn would break the driver’s existing eval board projects and unit-tests.

One solution to this problem is to use indirect referencing when accessing the BSP interfaces. This approach allows driver code to work with any BSP that satisfies its Hardware Abstraction Layer (HAL) requirements without needing to edit existing files. ​ Indirect referencing is achieved through intermediate header files using the LHeader Pattern.  For example in the PIM/EPC code bases the src/Bsp/Api.h header file act as the bridge between the driver and a specific BSP. ​

LHeader Pattern

The LHeader pattern is a method for implementing indirect header includes using the compiler’s header search path. ​ Here’s how it works:

1. The driver code includes a generic intermediate header file, such as src/Bsp/Api.h. ​
2. This intermediate header file includes a project-specific header file, which is resolved using the compiler’s search path. ​
3. Each project or unit test has its own instance of a global unique header file, such as colony_map.h, which provides project-specific resolutions for indirect header includes. ​

This pattern ensures that driver code has access to BSP interfaces while having the flexibility to be used with more than one BSP.

Explicit HAL vs Implicit HAL

For my faithful readers – you know I preach all the time the importance of HAL layers when it comes to platform independence.  So where does the HAL interface come into play with a BSP?  When designing HAL (Hardware Abstraction Layer) interfaces, there are two approaches:

1. Explicit HAL Interface: Defined by the developer, this interface specifies the services required by the client code from the hardware. ​ It is hardware-agnostic and provides greater flexibility and reusability across different platforms.  This is the preferred approach.
2. Implicit HAL Interface: Provided by the BSP layer, this interface exposes the header files of the MCU vendor’s SDK. While it is limited to specific hardware (e.g., a particular MCU family), it is more efficient as it eliminates an additional abstraction layer.  This approach is simple and effective but requires awareness and oversight with respect to managing different versions of the vendor’s SDK.

Pros and Cons of Implicit HAL Interfaces

Advantages

• Higher efficiency due to fewer abstraction layers. ​
• Suitable for application-level drivers that are unique to specific MCUs. ​

Disadvantages

• Assumes consistent syntax and semantics across different BSPs, which can lead to issues if SDK versions differ. ​
• Breaking changes in SDK versions can cause compiler errors or unexpected behavior. ​

To mitigate these risks, it’s essential to document the expected SDK version for any implicit HAL interface in source code comments or readme files. ​

Conclusion

The Indirect BSP approach is yet another tool in your toolbox of best practices for achieving platform independence. By avoiding direct references to BSP headers you can seamlessly transition your application through the many iterations of your project’s hardware.