feat: GPIO (GIO) driver implementation and host unit tests

hoogv commented

2026-07-23 08:50:08 +00:00

(Migrated from codeberg.org)

Description

The register-description epic (#4) delivered hal/registers/component/*.h / instance/*.h for every peripheral, but no actual driver logic exists yet under hal/mss or hal/dss — those trees don't exist in the repo. This issue starts the HAL driver-implementation phase with the GPIO (GIO) peripheral: hal/mss/gpio/hal_gpio.c / hal_gpio.h, providing port/pin direction+pull configuration, read/write/toggle, and edge-triggered IRQ enable/priority/dispatch on top of the GIO register block.

GPIO is also the proving ground for the shared host-test infrastructure every subsequent driver PR will reuse: testing/support/fakes/registers/awr.h + testing/support/hw_fakes.c (plain read/write fake register storage that shadows the real register headers via CMake include-path ordering) and the add_hal_unit_test() CMake helper in testing/CMakeLists.txt, plus the real hal/registers/awr.h / awr6843aop.h umbrella headers the driver code includes instead of individual component/instance headers directly.

Use Case / Rationale

As a firmware developer, I need a hal_gpio_* API to configure and drive GPIO pins and dispatch port-level interrupts, instead of every caller touching GIO registers directly.

As a QMS reviewer, I need driver logic backed by an automated Catch2/fff host unit test suite (register-level RMW-hazard, IRQ-decode, and critical-section-nesting regression coverage) run on every change, the same rigor already applied to the register-description epic's SVD/TI-comparison checks.

User Stories

As a developer, I want hal_gpio_module_init()/hal_gpio_pin_init()/hal_gpio_write()/hal_gpio_toggle()/hal_gpio_read() so pin configuration and I/O don't require hand-rolled register access.
As a developer, I want GIO port-level IRQs (edge/priority config, enable/disable) dispatched through a single hal_gpio_irq_handler(port, pin) hook that applications can override.
As a QMS reviewer, I want a host-native Catch2 test suite (testing/mss/unit/hal_functionality/test_gpio.c) exercising this driver against fake register storage, runnable in CI without target hardware.

Acceptance Criteria

hal/mss/gpio/hal_gpio.c / hal_gpio.h implemented against this project's current (post-epic) hal/registers/component/gpio.h / instance/gpio.h
Shared host-test fake-register infrastructure (testing/support/fakes/registers/awr.h, testing/support/hw_fakes.c) and the real hal/registers/awr.h / awr6843aop.h umbrella headers land, covering all peripherals currently in hal/registers/component
add_hal_unit_test() CMake helper added to testing/CMakeLists.txt and wired to build/run test_gpio.c
testing/mss/unit/hal_functionality/test_gpio.c passes under ctest
Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting

Functional Impact

None — self-contained addition; no existing driver logic exists yet to regress.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No — existing risk coverage sufficient.

Relates to #4

### Description The register-description epic (#4) delivered `hal/registers/component/*.h` / `instance/*.h` for every peripheral, but no actual driver logic exists yet under `hal/mss` or `hal/dss` — those trees don't exist in the repo. This issue starts the HAL driver-implementation phase with the GPIO (GIO) peripheral: `hal/mss/gpio/hal_gpio.c` / `hal_gpio.h`, providing port/pin direction+pull configuration, read/write/toggle, and edge-triggered IRQ enable/priority/dispatch on top of the GIO register block. GPIO is also the proving ground for the shared host-test infrastructure every subsequent driver PR will reuse: `testing/support/fakes/registers/awr.h` + `testing/support/hw_fakes.c` (plain read/write fake register storage that shadows the real register headers via CMake include-path ordering) and the `add_hal_unit_test()` CMake helper in `testing/CMakeLists.txt`, plus the real `hal/registers/awr.h` / `awr6843aop.h` umbrella headers the driver code includes instead of individual component/instance headers directly. ### Use Case / Rationale As a firmware developer, I need a `hal_gpio_*` API to configure and drive GPIO pins and dispatch port-level interrupts, instead of every caller touching GIO registers directly. As a QMS reviewer, I need driver logic backed by an automated Catch2/fff host unit test suite (register-level RMW-hazard, IRQ-decode, and critical-section-nesting regression coverage) run on every change, the same rigor already applied to the register-description epic's SVD/TI-comparison checks. ### User Stories - As a developer, I want `hal_gpio_module_init()`/`hal_gpio_pin_init()`/`hal_gpio_write()`/`hal_gpio_toggle()`/`hal_gpio_read()` so pin configuration and I/O don't require hand-rolled register access. - As a developer, I want GIO port-level IRQs (edge/priority config, enable/disable) dispatched through a single `hal_gpio_irq_handler(port, pin)` hook that applications can override. - As a QMS reviewer, I want a host-native Catch2 test suite (`testing/mss/unit/hal_functionality/test_gpio.c`) exercising this driver against fake register storage, runnable in CI without target hardware. ### Acceptance Criteria - [x] `hal/mss/gpio/hal_gpio.c` / `hal_gpio.h` implemented against this project's current (post-epic) `hal/registers/component/gpio.h` / `instance/gpio.h` - [x] Shared host-test fake-register infrastructure (`testing/support/fakes/registers/awr.h`, `testing/support/hw_fakes.c`) and the real `hal/registers/awr.h` / `awr6843aop.h` umbrella headers land, covering all peripherals currently in `hal/registers/component` - [x] `add_hal_unit_test()` CMake helper added to `testing/CMakeLists.txt` and wired to build/run `test_gpio.c` - [x] `testing/mss/unit/hal_functionality/test_gpio.c` passes under `ctest` - [x] Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting ### Functional Impact None — self-contained addition; no existing driver logic exists yet to regress. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No — existing risk coverage sufficient. ### Related Issues / PRs Relates to #4