drivers: can: stm32: support for dual CAN instances #46646
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
martinjaeger
requested review from
erwango,
alexanderwachter,
henrikbrixandersen,
ABOSTM and
FRASTM
as code owners
str4t0m
requested changes
Jun 17, 2022
There was a problem hiding this comment.
Thanks for this enhancement! I have not tested it on hardware, but I'd like to highlight two points.
- one-shot mode:
The config initialization got lost during the multi instance refactoring. - locking of filter registers:
Locking is done per instance, but both instances access the filter registers of CAN1 (master_can).
I believe we should make sure that the filter configuration happens mutually exclusive.
|
I have tested this on hardware, and can confirm it works :) Caveats: I am not using one-shot mode or any special filter config, but I am using heavy traffic (ISO-TP bootloader on CAN2) while simultaneously sending messages from CAN1. |
This commit unifies the driver initialization for can1 and can2 instances so that a single macro can be used. Enabling the master clock for can2 as introduced in 8ab81b0 had to be moved to devicetree in order to have the same CAN_STM32_CONFIG_INST macro for all instances. Signed-off-by: Martin Jäger <[email protected]>
Remove two functions which were only called from one place and did not improve readibility of the code. Signed-off-by: Martin Jäger <[email protected]>
CAN1 and CAN2 share the memory for the filter banks. This commit adds an offset for filters installed for CAN2, allowing to use both CAN instances simultaneously. The hardware allows to freely split the avalable 28 filters between CAN1 and CAN2. In order to simplify the driver implementation, it only supports an equal split of 14 filters per instance. This is the same amount of filters as available in MCUs with only a single CAN. Signed-off-by: Martin Jäger <[email protected]>
Choose can2 as the zephyr,canbus instance and add necessary settings for testing of the STM32 dual CAN driver implementation. Signed-off-by: Martin Jäger <[email protected]>
martinjaeger
force-pushed
the
stm32-dual-can
branch
from
ebbcb6c to
2f13b82
Compare
Good spot! I must have accidentally dropped that line. It's now added back.
That's also a good point. Added a static |
henrikbrixandersen
approved these changes
Jun 21, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements support for the STM32 dual CAN, where CAN1 and CAN2 share the memory for the filter banks.
Compared to the previous proposal #40531, this implementation only supports an equal split of the available 28 filter banks, which leads to the same amount of 14 filter banks per instance independent of the number of instances available in the MCU. This simplifies the driver implementation significantly and should cover most use cases.
The implementation was tested on a Nucleo F446RE and passes all tests with the following command (the board definition was updated to use
can2instance instead ofcan1for testing):In theory, also CAN3 available on some STM32F7 series MCUs should work if the missing devicetree nodes are added, but I don't have any hardware to test.