Additional CAN trait for extended features

[mlsvrts]

The current embedded-hal CAN trait seems to only support 'transmit' and 'receive', but commonly higher level applications will need support at least:

• Opening and closing the node
• Setting the baudrate

Additionally, it can be useful to have support for:

• Reading the bus state flags
• Putting the device into listen-only mode

For instance, consider the options supported by the linux can-utils slcand daemon: https://github.com/linux-can/can-utils/blob/master/slcand.c

I think that it would be reasonable to have some CanState trait, that supports open/close, alongside a CanSpeed trait that allows setting (+getting?) the device baudrate -- but I would be interested to hear other opinions/comments.

[ryankurte]

howdy, thanks for the issue!

the main goal with e-h is to abstract what is required for drivers rather than how to interact with a given platform, because that differs so substantially between platforms and cross platform applications must address this configuration -anyway- (think mapping pins, clocks, etc.)

i have not seen a specific need for these yet, but if there are drivers with a demonstrable need for these APIs at runtime the first steps would be to ensure your proposed traits could be supported by a collection of platforms and used by a driver or two, then to open the appropriate PRs.

[mlsvrts]

@ryankurte Thanks for the feedback!

Maybe I'm misunderstanding the goals of this project. I expect a stack like:

host system
------
comm. transport (usb, uart, i2c, etc.)
------
can hal  <------------- embedded hal goes here
------
can controller (embedded hardware specific)

I'm not actually aware of many CAN stacks that don't support programmable baudrates: kvaser, pcan, linux vcan, etc. all support programmable bitrates, and Zephyr RTOS also seems to consider it a integral CanBus API feature.

So if I want to write a uart --> can driver using e-h, I'll find myself unable to implement all of the supported features (namely, programming the bitrate and open/close).

If all you need is drivers + hardware that support a shared feature-set, I'm happy to provide a list and open a PR with my suggested traits. Or do you need something more concrete than that?

[timokroeger]

Related discussion: https://github.com/rust-embedded/embedded-hal/pull/212#issuecomment-635822962

[adamgreig]

The traits in embedded-hal are meant to be implemented by device-specific HALs and consumed by drivers that communicate over CAN, or by higher-level CAN protocol stacks that might implement something like ISO TP or CANopen.

The implementors would use something like vcan, or talk over SPI to a CAN controller, or use a microcontroller's embedded CAN controller - there's a big diversity in possible implementations, many of them on bare-metal embedded platforms.

The users of the traits are then things like a driver for a motor controller that's controlled over CAN (which might be part of an application or a standalone crate), so that it can easily be generic over different underlying hardware. In general those drivers shouldn't need to perform configuration operations like opening/closing the node or setting the baud rate; we consider that sort of configuration as out of scope for embedded-hal traits. Instead, the specific implementations (eg on top of vcan, or the STM32's bxcan peripheral, etc) should provide their own methods for configuration of baud rate, enable/disable, etc etc; applications use those methods to bring the bus up, and then drivers can use the generic traits to actually send and receive frames.