CAN filter of 3rd CAN interface

[mikewolfram]

Working on a F765 I want to use all 3 available CAN interfaces, but ran into the issue, that there is no way to configure the filters of the 3rd CAN interface. The current implementation of mode::platform::CanFilter is made for CAN1 and CAN2 only (and on the F7 it is also missing the method to set the first bank of CAN2).

I'd like to propose the following changes:

• modm::platform::CanFilter is only to define the filter and mask types as well as the enums.
• Introduce a modm::platform::Can12Filter derived from above to set filter on CAN1 and CAN2. Including adding the missing method to configure dual CAN (1 and 2).
• Introduce a modm::platform::Can3Filter derived from above to set filter on CAN3.

Only for the MCU which provide more than one CAN interface. If there's a single CAN interface only no changes would be introduced.

I know it would break existing code as a rename from modm::platform::CanFilter to modm::platform::Can12Filter would be required. Any objections? Any better ideas?

[salkinium]

Only for the MCU which provide more than one CAN interface. If there's a single CAN interface only no changes would be introduced.

Sounds fairly reasonable to me.

[rleh]

Interesting CAN architecture in the F765 series:

I was not aware of any STM32 device with more than two bxCAN (CAN 2.0B only, no FD-CAN!).

The new devices with FDCAN have a completely different architecture:

My idea for #325 was to assign a fixed (configurable via lbuild) number of filters to every CAN interface and completely eliminate the modm::platform::CanFilter class.
Are there cases where you change the distribution of the CAN filters at runtime?

[mikewolfram]

Looking into ST MCU finder there are quite a few F4 and F7 with 3 bxCAN. I suppose they all have a dual bxCAN (CAN1/2) and an additional single CAN3.

The number of filters can be fixed during compile time, I don't see a reason to change that. But the filters itself we set during runtime (e.g. DIP switch to select node ID).

[rleh]

Currently the partitioning of the can filters has to be done at runtime:
void CanFilter::setStartFilterBankForCan2(uint8_t startBank)
I don't see a use-case to do this and would like to move this configuration to compile-time (or lbuild-time).
This would enable us to use a simplified and portable API, so that platform-independent drivers/applications e.g. CanOpen, Uavcan can use it:

// on STM32/SAM/... or with MCP2515 can controller:
myCanOpen modm::CanOpen<modm::platform::Can1>{};
myUavcan modm::Uavcan<modm::platform::Can2>{};

// linux:
myCanOpen modm::CanOpen<Can<"can0">>{};

However, this should require more effort, so I currently agree with your proposed solution modm::platform::Can12Filter / Can3Filter. 👍

[mikewolfram]

myCanOpen modm::CanOpen<modm::platform::Can1>{};

Is there already a CANopen in modm? I'm working on one, but if there is something ready to use...

[rleh]

Is there already a CANopen in modm?

No, not yet. But I'll probably need Canopen in the near future (October/November) and wanted to have a look at it and maybe integrate it into modm...

I'm working on one, but if there is something ready to use...

Nice!

[strongly-typed]

Is there already a CANopen in modm?

No, not yet. But I'll probably need Canopen in the near future (October/November) and wanted to have a look at it and maybe integrate it into modm...

I'm working on one, but if there is something ready to use...

Nice!

I already have a working application running which cranks out some ugly hand-crafted DS 402 CANopen commands. Would be great to see something more general and robust. I am using this hardware but the code should be independent of the HW.

[mikewolfram]

My code is made for the STM32 CAN interface, but it should be fairly easy to separate the hardware from the messaging handling.

I implemented a concept we already did on a Linux application. Created a property class with set/get methods, which is then used in std::variant. This way I can use visitors to get/set the objects. A map is used to look up the objects. It's beyond the scope of this issue, but we might use another one to share some code (or maybe a PR?).

For testing I use an isolated USB-CAN adapter with serial ASCII protocol on my MacBook.

[mikewolfram]

Question: How do I know in the module.lb file, which CAN has been selected in project.xml? I mean, how do I know whether it is CAN1 or CAN2 or CAN1 and CAN2? Currently thinking about best approach.

One idea is to keep the CanFilter class when it is only CAN1 or CAN2 or CAN3 if the single instance would be CAN (instead of CAN1, CAN2 or CAN3). In case of CAN1 and CAN3 I'd name the filter class CanFilter1 and CanFilter3, in case of CAN2 and CAN3 CanFilter2 and CanFilter3. If both CAN1 and CAN2 are enabled I'd name it CanFilter12.

Or maybe something completely different?

[salkinium]

How do I know in the module.lb file, which CAN has been selected in project.xml?

You can query the module tree env.has_module(":platform:can:1") or env.has_module(":platform:can:2"). Unfortunately you cannot get a full list until you're in the post_build step, mostly because I didn't implement that API.