← NavHAL

Resource Management

NavHAL adopts a minimal and explicit approach to resource management, prioritizing determinism and low overhead over dynamic flexibility. Unlike traditional abstraction layers that manage hardware resources through runtime allocation or centralized control, NavHAL delegates resource ownership and coordination to the application or execution layer.

Static Resource Binding

All hardware resources in NavHAL are bound at compile time. Peripheral instances such as GPIO pins, UART ports, I2C buses, and timers are selected through configuration parameters and encoded identifiers.

This approach ensures that:

  • No runtime allocation or initialization of resources is required

  • Peripheral mappings are fixed and known at build time

  • Binary size is minimized by excluding unused components

As a result, resource access remains predictable and free from dynamic overhead.

No Implicit Ownership Model

NavHAL does not enforce ownership or locking mechanisms for hardware resources. Multiple modules can access the same peripheral without restriction at the abstraction layer.

This design avoids:

  • Mutexes or synchronization primitives within the HAL

  • Hidden state or resource tracking

  • Runtime arbitration logic

Instead, it provides direct access to hardware, leaving coordination responsibility to higher layers.

Execution-Layer Responsibility

In systems where concurrency is present (e.g., when using VAIOS), resource management is handled externally. The execution layer is responsible for:

  • Preventing conflicting access to shared peripherals

  • Scheduling tasks that interact with hardware

  • Ensuring safe interaction across multiple execution contexts

This separation keeps NavHAL lightweight while allowing flexible system design.

Deterministic Access Model

By avoiding dynamic allocation and runtime arbitration, NavHAL ensures that all hardware interactions have predictable execution characteristics. Each operation directly translates to register-level access, with no hidden delays or blocking behavior introduced by the abstraction layer.

Design Trade-offs

The chosen approach trades centralized resource management for simplicity and performance. While this requires careful coordination at the application or execution layer, it provides:

  • Lower latency and reduced overhead

  • Greater transparency in hardware interaction

  • Full control over peripheral usage patterns

This model aligns with the requirements of real-time systems, where predictability and efficiency are often more critical than dynamic flexibility.