Overview

Informative

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

In one sentence: the CAN driver (CanDrv) provides a thin, portable abstraction over a CAN controller — it initialises the hardware, transmits and receives L-PDUs, manages per-channel state, and reports events to the upper layer.

What it does

  • Brings CAN channels up and down and manages their state (stopped / started / sleep).

  • Transmits L-PDUs (classic CAN and CAN FD) and receives them, notifying the upper layer.

  • Handles TX, RX, and bus-off/error events in either interrupt or polling mode, per channel.

  • Reports bus-off and unrecoverable hardware errors to the upper layer.

What it does not do

  • No remote frames. The driver neither transmits nor answers remote transmission requests.

  • No automatic bus-off recovery. Recovery is delegated to the upper layer (see Design Decisions).

  • No wakeup detection. SLEEP is a logical sleep state; the driver does not implement transceiver wakeup detection.

  • No software priority emulation. Transmit priority is left to hardware or the upper layer.

  • No setup of clock, port, or interrupt controller — these are prerequisites another module configures before Can_Init.

Where it sits

        flowchart TB
   UL["Upper layer (CanIf)"]
   DRV["Chiisai CAN Driver"]
   HWA["Hardware abstraction<br/>(clock, port, interrupt)"]
   HW["CAN controller hardware"]

   UL -->|"Can_Init, Can_Transmit,<br/>Can_SetChannelState, ..."| DRV
   DRV -->|"CanIf_On* callbacks<br/>(OnReception, OnTransmission,<br/>OnChannelState, OnError)"| UL
   DRV --> HWA
   HWA --> HW

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

The hardware-abstraction layer (clock, port pins, interrupt controller) is set up by other modules before Can_Init; the CAN driver assumes it is ready.

Purpose

The CAN driver is the lowest software layer above a CAN controller. It presents a hardware-independent interface for transmitting and receiving CAN L-PDUs, so that an upper layer (typically a CAN interface, CanIf) can be written once and run on any conformant driver.

The driver is intentionally small: it targets cost-sensitive MCUs and covers only what a minimal CAN data path needs. It does not implement a bus state manager, network management, or a transport protocol — those belong to layers above it.

Dependencies

The CanDrv does not call other driver modules directly, but it relies on:

Depends on

For

System resources (clock, port, interrupt)

Bit timing, pin routing, and interrupt configuration for the CAN controller. These must be set up by another module before Can_Init.

Expected upper-layer interfaces

The callbacks and services the driver calls back into (CanIf_On*, LogM_Report, and optional critical-section services). 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.

[2]

ISO 11898 — Road vehicles — Controller area network (CAN)

[3]

CiA 601-2 — CAN FD node and system design, Part 2: Protocol controller interface