CanManager Implementation

Define the implementation architecture for the type-safe CAN transport layer.

This section specifies the CanManager design, template architecture, and integration with the modm hardware abstraction layer.

Design Goals

The CanManager implementation achieves:

1. Complete abstraction of FDCAN hardware from application code.

2. Zero-cost compile-time type checking of message permissions.

3. Automatic hardware initialization via template parameters.

4. Automatic filter configuration from CAN map metadata.

5. No dynamic allocation in transmission or reception paths.

6. Deterministic bounded execution time.

7. Separation of transport logic from application logic.

Software Stack

Layer Descriptions

User Application Layer

The user works exclusively with CAN map structs and normal C++ types.

Key characteristics:

• Direct field access: msg.fx = 123

• Type-safe API: can.send(msg)

• Automatic message processing: can.processMessages()

• No bit manipulation required

• No hardware knowledge needed

CanManager (Transport Layer)

Template-based transport layer providing:

• send<Message>(msg) - Type-checked message transmission with automatic serialization

• processMessages() - Polls hardware FIFOs, deserializes, and dispatches to handlers

• Constructor - Automatic hardware initialization and filter configuration

All hardware complexity is hidden from the user.

Generated Code Layer

Auto-generated from YAML source:

• can0.hpp - Message struct definitions with metadata

• can0_serialize.hpp - Deterministic pack/unpack functions

• NodeTraits - Compile-time permissions (TxMessages, RxMessages)

Provides:

• Single source of truth

• Compile-time validation

• Type safety guarantees

modm HAL Layer

Hardware abstraction layer providing:

• FDCAN peripheral drivers

• GPIO configuration

• Interrupt handling

• Platform-specific implementations

The CanManager calls modm APIs but hides them from the user.

Hardware Layer

Physical layer:

• STM32G4 FDCAN peripheral

• CAN bus interface

• 1 Mbit/s nominal bitrate

• 5 Mbit/s data phase (CAN-FD)

Data Flows

Send Flow (TX)

1. User creates message struct

2. Calls can.send(msg)

3. CanManager checks compile-time permissions

4. Automatic serialization via generated code

5. modm transmits frame

6. Hardware sends to CAN bus

Receive Flow (RX)

1. CAN bus receives frame

2. Hardware stores in RX FIFO

3. User calls can.processMessages()

4. CanManager polls FIFO

5. Matches ID to message type

6. Automatic deserialization

7. Calls user’s onMessage(msg) handler

Initialization Flow

Single constructor call handles:

1. GPIO pin connection

2. FDCAN peripheral initialization

3. CAN-FD mode configuration

4. Reads RxMessages from NodeTraits

5. Configures hardware filters automatically

6. Ready to send/receive!

Key Abstraction Principle

What the User Sees

• CAN map structs (SensorNode::StrainData)

• Normal C++ types (int32_t, float, uint8_t)

• Simple API (send(), processMessages())

What is Hidden

• modm::can::Message

• Bit shifting and masking

• Hardware register access

• Filter configuration

• Serialization logic

The user works at a high level of abstraction, never touching low-level details.