Overview

Informative

What the memory driver is, its boundaries, and where it sits. Non-binding orientation; the normative contract is in Mem — Requirements. The driver builds on the shared foundation (type system, error model, naming, memory mapping) in General.

In one sentence: the memory driver (MemDrv) provides a memory-technology-agnostic interface for read, write, erase, and blank-check operations on physically segmented memory devices (typically flash), running each operation as an asynchronous job.

What it does

  • Reads, writes, erases, and blank-checks a memory instance, plus optional suspend/resume and a hardware-specific service dispatcher.

  • Runs each operation as an asynchronous job, driven by Mem_PollFunction and observed with Mem_GetJobResult.

  • Supports multiple memory instances per driver instance, and multiple driver instances.

  • Optionally ships as a self-contained relocatable binary image for dynamic driver activation.

What it does not do

  • No job queue — at most one job at a time per instance; a request while a job is pending is rejected.

  • No block devices (e.g. NAND) — only physically segmented memory (pages, sectors).

  • No alignment or buffering — the caller MUST align addresses and lengths to the device’s write page / sector; the driver does not buffer sub-page writes.

  • No result verification — the driver does not read back to confirm a write or erase.

  • No data-integrity features — no checksums or redundancy.

  • No system-resource setup — clock, port pins, and interrupt controller are prerequisites another module configures before Mem_Init.

Where it sits

        flowchart TB
   UL["Upper layer (e.g. a flash manager)"]
   DRV["Chiisai Memory Driver"]
   HWA["Hardware abstraction<br/>(clock, port, interrupt)"]
   HW["Memory device (flash)"]

   UL -->|"Mem_Read, Mem_Write, Mem_Erase,<br/>Mem_GetJobResult, ..."| DRV
   DRV -->|"job results, Mem_OnError"| UL
   DRV --> HWA
   HWA --> HW

   classDef driver fill:#FEDCD2,stroke:#c66,stroke-width:2px;
   class DRV driver;

External memory (e.g. over SPI) may be reached through another driver; on-chip flash is accessed directly. The hardware-abstraction layer is set up by other modules before Mem_Init.

Dependencies

Depends on

For

System resources (clock, port, interrupt)

Timing and, for external memory, the bus (e.g. SPI). These must be set up by another module before Mem_Init.

Expected upper-layer interfaces

The services the driver calls back into (Mem_OnError from the ECC handler, LogM_Report). See API Reference → Expected interfaces.

The shared foundation

The common type system, compiler abstraction, error model, naming scheme, and memory mapping defined in General.

References

No.

Document

[1]

The Chiisai HAL General part — the shared contract this module builds on.