CAN Driver

The CAN driver page is about the hardware-facing part of communication. The board uses it to bind the generic CAN layer to the STM32 FDCAN peripheral, keep the transmit queue moving, and react quickly when the hardware raises an RX or error interrupt.

WARNING

The interrupt callbacks are part of the board's live CAN path. Keep them short and avoid heavy work there; the actual application logic should stay in the normal loop.

What the driver is responsible for

The driver initializes the hardware-backed CAN instance, connects the FIFO helpers from HAL, and gives the rest of the application a stable place to enqueue or consume frames. It also provides the callback entry points used by the FDCAN peripheral so the board can drain received traffic and recover from bus errors.

Why this matters

Without this layer, the board code would have to talk to the peripheral directly every time it wanted to send or receive a frame. With it, the rest of the application can stay focused on board behavior instead of transport details.

Typical flow

init_canbus_driver(&can_driver, HAL_FDCAN_AddMessageToTxFifoQ, HAL_FDCAN_GetTxFifoFreeLevel, &hfdcan2);

while (1)
{
    process_can_helper();
    FSM_step(&board_fsm_driver);
}

That is the shape the board uses in practice: initialize once, then let the loop and callbacks keep the bus alive.