mirror of
https://github.com/RIOT-OS/RIOT.git
synced 2025-12-15 01:23:49 +01:00
5d48376a21
Until now, STM32 MCUs classic CAN support is coded in can.c file. However CAN FD in STM32G4 family is designed in a very different way: * CAN FD channels are independant * CAN FD channel configuration is done in a dedicated RAM block called message RAM, with one message RAM per channel * Each message RAM is divided this way: - 11-bit filter (28 elements / 28 words) - 29-bit filter (8 elements / 16 words) - Rx FIFO 0 (3 elements / 54 words) - Rx FIFO 1 (3 elements / 54 words) - Tx event FIFO (3 elements / 6 words) - Tx buffers (3 elements / 54 words) Due to these design differences with other STM32 MCUs, the choice is made to split the driver in two files: * classiccan.c for STM32 MCUs that support classical CAN. This file has just been renamed (previously can.c) to avoid build conflicts but does not introduce changes * fdcan.c for STM32 MCUs that support CAN FD Message RAM definitions is not provided in CMSIS headers of the STM32G4 family, they are defined in fdcandev_stm32.h. Those definitions could be extracted to a new file for each STM32 families as some differences exist with other STM32 families that support CAN FD (for instance STM32H7). This could be done in a futher commit, according to new families requirements. CAN hardware parameters stay similar and are kept in can_params.h. There are 36 filters per channel: * 28 first filters are standard ID (11 bit) filters * 8 last filters are extended ID (29 bit) filters On each Tx frame sent, the STM32G4 can store Tx events in a dedicated FIFO. This feature is not yet implemented and Tx event FIFO is disabled by default. Automatic retransmission on arbitration loss is enabled by default by the STM32G4. About Rx, if no filter is configured, all frames are accepted by default. Signed-off-by: Gilles DOFFE <gilles.doffe@rtone.fr>