API ideas: Filterbank builder pattern

[Timo Kröger]

I’m in the process of porting this to stm32f1xx devices with two CAN instances.

With the current API its easy to forget to enable filters especially when only using CAN2.
I propose following API to ensure filters are configured:

// Single intsance
let filters = can
    .filters()
    .bank(…)
    .bank(…)
    .enable(); // Clears the FINIT bit

// Multiple intsances
let (can1_filters, can2_filters) = can1
    .filters()
    .bank(…)
    .bank(…)
    .slave_filters()
    .bank(…)
    .bank(…)
    .enable(); // Clears the FINIT bit

// Require the filters so the user does not forget to set them up and
// starts debugging because no messages are received at all.
can1.enable(can1_filters);
can2.enable(can2_filters);

What do you think? Any pitfalls I overlooked?

[Jonas Schievink]

Yeah, sounds like a good idea to offer a better interface here. You can still forget to call enable though, even if it requires the filters as an argument.

There might also be cases in which the filters are configured in one place, but enable is called in another, which makes it hard or impossible to pass the argument to enable. If we're fine with restricting the interface like that, we could also call enable internally or offer a more "all-in-one" API that sets up filters, data rate, and enables the peripheral.

Not sure what the best solution here is.

[Timo Kröger]

Good points, I’m gonna draft a stm32f1xx implementation and examples with the current API. From that we can evolve the API.

[Jonas Schievink]

This is now basically implemented: MasterFilters will clear FINIT on drop. Enabling the peripheral is independent though, since you can modify filters while the peripheral is already enabled.