...
They will create a virtual (emulated) CAN interface in the guest and connect it to the CAN interface can0 of the host. The controller emulated in the Guest is the Kvaser PCI CAN-S (single SJA1000 channel) board, which is supported by the mainline kernel. It’s important to point out that the CAN interface of the host has to be proper set up and powered up. The configuration from emulated devices is not propagated to the physical host interface[14].
The emulated CAN interface can be used inside the Guest just as a physical one:
...
Table 2: General requirements for CAN support on EVE
Requirement | Description |
|---|---|
R.1 | CAN bus should be supported by EVE’s kernel |
R.2 | EVE should support CAN controllers present in the hardware |
R.3 | EVE should support Virtual CAN interfaces |
R.4 | EVE should be able to configure CAN interfaces (physical or virtual) and set all parameters supported by iproute2 |
R.5 | EVE should be able to passthrough one or more CAN interfaces (physical or virtual) to one or more Edge Applications, i.e., containers and/or VMs |
R.6 | EVE should get the configuration for CAN interfaces (physical or virtual) from the device model |
R.7 | EVE should not allow dynamic adding/removal of virtual CAN interfaces |
Table 3 presents the specification of each requirement from Table 2.
Table 3: Requirements for CAN support on EVE
Requirement | Description | ||
|---|---|---|---|
RS.1 | CAN bus should be supported by EVE’s kernel The SocketCAN Framework must be built/enabled in the kernel. | ||
RS.2 | EVE should support CAN controllers present in the hardware All the devices officially supported by EVE and equipped with CAN controllers must have the corresponding device drivers built/enabled in the kernel (when available). Device drivers for USB CAN adapters can also be provided as modules. | ||
RS.3 | EVE should support Virtual CAN interfaces The Virtual CAN interface device driver should be built/enabled in the kernel (CONFIG_CAN_VCAN), as well as the drivers for QEMU’s CAN virtio devices:
| ||
RS.4 | EVE should be able to configure CAN interfaces (physical or virtual) and set all parameters supported by iproute2 EVE should be able to understand and setup the parameters described on Table 4. Notice that some CAN controllers, including the Virtual CAN, don’t support all the parameters, so only those specified in the configuration for a specific interface must be set by EVE. | ||
RS.5 | EVE should be able to passthrough one or more CAN interfaces (physical or virtual) to one or more Edge Applications, i.e., containers and/or VMs Pillar + Domain manager should generate the corresponding QEMU configuration for a VM/Container with all CAN interfaces with passing-through required. There will be no distinction between a Virtual and Physical CAN interface
| ||
RS.6 | EVE should get the configuration for CAN interfaces (physical or virtual) from the device model The parameters of Table 4 should be specified for each CAN interface (to be used by EVE) in the device model (JSON format). Only the parameters that are supported by the CAN controller should be provided. EVE should not change/set any parameter that is not specified in the device model | ||
RS.7 | EVE should not allow dynamic adding/removal of virtual CAN interfaces The configuration for CAN interfaces (Virtual CAN, etc) are fixed in the device model, EVE should not change it, unless the device model is updated. EVE should proceed the following steps:
Any CAN interface that is not described in the configuration should be left untouched by EVE. EVE should not add/remove any Virtual CAN during runtime, unless the device model is updated. |
Table 4: Parameters of a CAN interface. Not all parameters should be supported by all controllers, including Virtual CAN
Parameter | Allowed values |
|---|---|
bitrate | NUMBER in bps |
sample-point | 0.000..0.999 |
tq | NUMBER in ns |
prop-seg | NUMBER in tq |
phase-seg1 | NUMBER in tq |
phase-seg2 | NUMBER in tq |
sjw | NUMBER in tq |
dbitrate | NUMBER in bps |
dsample-point | 0.000..0.999 |
dtq | NUMBER in ns |
dprop-seg | NUMBER in tq |
dphase-seg1 | NUMBER in tq |
dphase-seg2 | NUMBER in tq |
dsjw | NUMBER in tq |
tdcv | NUMBER in tc |
tdco | NUMBER in tc |
tdcf | NUMBER in tc |
loopback | on | off |
listen-only | on | off |
triple-sampling | on | off |
one-shot | on | off |
berr-reporting | on | off |
fd | on | off |
fd-non-iso | on | off |
presume-ack | on | off |
cc-len8-dlc | on | off |
tdc-mode | auto | manual | off |
restart-ms | 0 | NUMBER in ms |
restart | True | False |
termination | 0..65535 |
Use cases
This section describes the main use cases with different configurations and/or uses of CAN bus by Edge Applications and EVE-OS. In all examples it will be considered a hypothetical device running EVE-OS with three Edge Applications deployed (no matter their type, i.e., if they are Containers and/or VMs). However, all these examples can be expanded to different combinations and setups.
...
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
References
https://www.ti.com/lit/an/sloa101b/sloa101b.pdf?ts=1699421104828
https://www.csselectronics.com/pages/can-bus-simple-intro-tutorial
https://www.kampis-elektroecke.de/can-hausbus/can-bus-bit-timing/
https://www.ti.com/lit/an/sprac35/sprac35.pdf?ts=1702295040569
https://www.can-cia.org/fileadmin/resources/documents/proceedings/2013_hartwich_v2.pdf
https://www.ni.com/docs/de-DE/bundle/ni-xnet/page/can-fd-iso-versus-non-iso.html
https://docs.espressif.com/projects/esp-idf/en/v4.1.1/api-reference/peripherals/can.html
https://python-can.readthedocs.io/en/2.2.1/interfaces/socketcan.html
Presentation of this proposal at the EVE’s Community call: https://zoom.us/rec/share/G7GXmXKTWZP3p5wu-O0zPIPK8AmuCE3FssvdZDmbJAkKAb24miZbs8Sn8GXr6DcC.fireCQoUTKwI-Id_
...