You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The CAN devices are common on our devices. The support for them is limited in labgrid, so let's start with the crucial part -- local can resources:
RawCANPort - device specified by the interface name
USBCANPort - udev matching (useful for USB-CAN adapters)
The goal is to have NetworkCANPort. It will be discussed in a separate issue.
I don't plan any Driver now, as I don't see a need (and I hope that it is possible to use it this way). Our test infrastructure needs just the interface name at the moment.
I was also thinking about it. I'm proposing the separate Resource because:
There will probably be new attributes ('speed' at the moment), and the NetworkCANPort will have different bridging similar to ser2net (I will create a new issue to summarize the discussion we had at EOSS2023). There might be a CAN Driver in the future, which should be bound only to the respective resource. I like the SocketCAN abstraction, but on the other hand, I see CAN as a different type of interface with different approaches under the hood.
The CAN devices are common on our devices. The support for them is limited in labgrid, so let's start with the crucial part -- local can resources:
The goal is to have NetworkCANPort. It will be discussed in a separate issue.
I don't plan any Driver now, as I don't see a need (and I hope that it is possible to use it this way). Our test infrastructure needs just the interface name at the moment.
The checklist:
I'm playing with it in our fork at https://gitlab.com/vzlu/tools/labgrid/-/tree/tom/add_can_resource.
The text was updated successfully, but these errors were encountered: