CAN driver proposal

[paval-shlyk]

Added support for the CAN driver (tested only on g6u6 model)
Added a flag to start the runtime (for some reason qingke does not initialize what it should)

[paval-shlyk]

Forgot to mention that CAN implementation primary was taken from this repo: https://github.com/marti157/ch32-can-rs

[andelf]

Maybe we should cite marti157/ch32-can-rs somewhere.
@marti157

[marti157]

I'm happy to see an initiative to get my CAN implementation into the HAL, since the CAN implementation already depended on the HAL. Some work needs to be done, especially with the pin remapping. I managed to fully test the implementation on a 208wbu6 device with real CAN hardware, so let me know if you need any help!

[andelf]

Thanks. I'll handle the rest.

[andelf]

These comments can be removed.

[paval-shlyk]

I will review the relevance of the comments)

[andelf]

Leave these pin configs to me. I'll get it implemented.

[paval-shlyk]

I don't mind. What should I do?)

[paval-shlyk]

I'm testing CAN on 203g6u6 and I found that the filter don't work. Let's say I have:

    let filter = CanFilter {
        bank: 0,
        mode: CanFilterMode::IdMask,
        id_value: (0x580 | 0x42) as u32,
        id_mask: 0x0FF,
    };

As I believe only frames with id equals to 0x5C2 (0x580 | 0x42) should be accepted.
But hearbeats' frames of another node are received too.
@marti157 Everything is working for you?

[paval-shlyk]

I have introduced a new api for filters' configuration (with a bit unsafe code). But I still can't set up the filter correctly (it's probably a hardware bug, but even without the filter receive method, a frame with the ID 0x1101 is created). Only the "accept_all" strategy works for me (I can intercept real message frames).

[andelf]

@paval-shlyk Thanks for your contribution. I've made some refactoring to your work:

Changes made:

1. Using generated peripheral definitions
2. Using generated pin traits and pin remapping
3. Extended support for CH32L1 series, as the peripheral layout is compatible
4. removed separate can feature flag, to match embassy-stm32

Please review these changes and let me know if everything looks good to proceed with the merge.

[paval-shlyk]

@andelf Using the feature flag is, of course, a matter of taste...) I prefer to give the user the ability to customize the library's functionality (as a way to speed up the compilation process) But for ease of use, I agree)