feat: ADCBUF driver implementation and host unit tests #85

New issue

Closed

opened 2026-07-23 13:07:03 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-23 13:07:03 +00:00

Owner

Description

Adds hal/mss/adcbuf/hal_adcbuf.c/.h — the ADCBUF driver: channel-enable/real-only/IQ-swap configuration (CFG1), per-channel sample-address configuration (CFG2/CFG3, read-modify-write hazard between paired channels), chirp-count configuration (CFG4), sample-buffer pointer accessor, and ECC enable (polls INITDONE with a bounded timeout) / clear-error for both ping and pong banks.

Use Case / Rationale

As a firmware developer, I need an hal_adcbuf_* API to configure ADC sample-buffer channels, addressing, and ECC protection, following the same driver pattern established by GPIO (#75), ESM (#77), UART (#79), I2C (#81), and SPI (#83).

User Stories

As a developer, I want hal_adcbuf_configure()/hal_adcbuf_set_channel_address()/hal_adcbuf_set_chirp_counts() to configure the ADC sample buffer without hand-computing CFG1-CFG4 bitfields myself.
As a developer, I want hal_adcbuf_ecc_enable() to bound its INITDONE poll with a timeout rather than hang forever on a stuck ECC state machine.
As a QMS reviewer, I want a host-native Catch2 test suite (testing/mss/unit/hal_functionality/test_adcbuf.c) covering channel configuration, address read-modify-write isolation, and the ECC init/enable sequence (via a simulated background "hardware" thread setting INITDONE), runnable in CI without target hardware.

Acceptance Criteria

hal/mss/adcbuf/hal_adcbuf.c/.h implemented against this project's current hal/registers/component/adcbuf.h/instance/adcbuf.h
testing/mss/unit/hal_functionality/test_adcbuf.c passes under ctest, including the threaded ECC-init-done simulation (verified stable across repeated runs, not flaky)
Sanity-checked by deliberately breaking a channel-enable bitfield and confirming the test suite catches it, then reverting

Functional Impact

None — self-contained addition alongside the already-landed GPIO/ESM/UART/I2C/SPI drivers.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No — existing risk coverage sufficient.

Relates to #4, relates to #75, relates to #77, relates to #79, relates to #81, relates to #83

### Description Adds `hal/mss/adcbuf/hal_adcbuf.c`/`.h` — the ADCBUF driver: channel-enable/real-only/IQ-swap configuration (`CFG1`), per-channel sample-address configuration (`CFG2`/`CFG3`, read-modify-write hazard between paired channels), chirp-count configuration (`CFG4`), sample-buffer pointer accessor, and ECC enable (polls `INITDONE` with a bounded timeout) / clear-error for both ping and pong banks. ### Use Case / Rationale As a firmware developer, I need an `hal_adcbuf_*` API to configure ADC sample-buffer channels, addressing, and ECC protection, following the same driver pattern established by GPIO (#75), ESM (#77), UART (#79), I2C (#81), and SPI (#83). ### User Stories - As a developer, I want `hal_adcbuf_configure()`/`hal_adcbuf_set_channel_address()`/`hal_adcbuf_set_chirp_counts()` to configure the ADC sample buffer without hand-computing `CFG1`-`CFG4` bitfields myself. - As a developer, I want `hal_adcbuf_ecc_enable()` to bound its `INITDONE` poll with a timeout rather than hang forever on a stuck ECC state machine. - As a QMS reviewer, I want a host-native Catch2 test suite (`testing/mss/unit/hal_functionality/test_adcbuf.c`) covering channel configuration, address read-modify-write isolation, and the ECC init/enable sequence (via a simulated background "hardware" thread setting `INITDONE`), runnable in CI without target hardware. ### Acceptance Criteria - [x] `hal/mss/adcbuf/hal_adcbuf.c`/`.h` implemented against this project's current `hal/registers/component/adcbuf.h`/`instance/adcbuf.h` - [x] `testing/mss/unit/hal_functionality/test_adcbuf.c` passes under `ctest`, including the threaded ECC-init-done simulation (verified stable across repeated runs, not flaky) - [x] Sanity-checked by deliberately breaking a channel-enable bitfield and confirming the test suite catches it, then reverting ### Functional Impact None — self-contained addition alongside the already-landed GPIO/ESM/UART/I2C/SPI drivers. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No — existing risk coverage sufficient. ### Related Issues / PRs Relates to #4, relates to #75, relates to #77, relates to #79, relates to #81, relates to #83

hoogv added the

labels