Portability Model

NavHAL achieves portability through structured separation of hardware concerns and compile-time specialization. Instead of relying on runtime abstraction layers, the system follows a clear adaptation flow where only the required components are implemented or replaced based on the target platform.

Porting Flow Overview

Portability in NavHAL follows a layered adaptation path:

The application and interface layers remain unchanged. Porting is performed by adapting the lower layers depending on what changes in the hardware platform.

Case 1: Porting to a New Board (Same MCU)

When the microcontroller remains the same but the physical board changes, only the board layer needs to be updated.

Flow:

• Define board-specific pin mappings (e.g., mapping logical pins to actual GPIOs)

• Configure default peripherals (LEDs, communication ports, etc.)

• Update linker script if memory layout differs

Impact:

• No changes required in core or vendor layers

• No changes required in application code

This is the simplest portability case and enables reuse of the entire software stack across different hardware layouts.

Case 2: Porting to a New Microcontroller (Same Architecture)

When moving to a different microcontroller within the same architecture (e.g., STM32F401 → STM32F411), the vendor layer is adapted.

Flow:

• Define register base addresses and peripheral mappings

• Update memory layout and peripheral availability

• Provide vendor-specific definitions required by the core layer

The core layer continues to use these definitions to implement peripheral behavior.

Impact:

• Core logic remains unchanged

• Board layer may require minor updates

• Application code remains unchanged

This separation allows reuse of peripheral logic while adapting only low-level hardware details.

Case 3: Porting to a New Architecture

When targeting a completely different processor architecture (e.g., moving from Cortex-M4 to another architecture), a new core layer must be implemented.

Flow:

• Implement architecture-specific startup code and interrupt handling

• Provide core implementations for all common HAL APIs

• Integrate vendor-specific register definitions for the new platform

Impact:

• Vendor and board layers are built on top of the new core

• Interface remains unchanged

• Application code remains unchanged

Although this is the most involved step, it is performed once per architecture and reused across multiple platforms.

Compile-Time Binding

All portability decisions are resolved at compile time through build configuration parameters such as:

• Target processor (core)

• Vendor family

• Board configuration

The build system includes only the selected implementations, ensuring:

• No runtime branching or hardware detection

• Reduced binary size

• Direct mapping to hardware

Key Observation

In all cases, the upper layers of the system remain unchanged. Portability is achieved by replacing only the minimal required layer: