...
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.
...
ztype
phylabel
logicallabel
cbattr (at least bitrate should be present for IO_TYPE_CAN or IO_TYPE_VCAN typestype)
Parameters not supported by the CAN interface shall be omitted from the device model file.
...
Code Block |
---|
"ioMemberList": [ { "ztype": "IO_TYPE_CAN", "phylabel": "can0", "logicallabel": "can0", "assigngrp" : "", "phyaddrs" : { "ifname" : "can0" }, "cbattr" : { "bitrate": "125000", } }, { "ztype": "IO_TYPE_LCAN", "phylabel": "can0.1", "logicallabel": "app1CANcan0.1", "assigngrp" : "app1CANcan0.1", "phyaddrs" : { "ifname" : "can0" }, }, { "ztype": "IO_TYPE_LCAN", "phylabel": "can0.2", "logicallabel": "app2CANcan0.2", "assigngrp" : "app2CANcan0.2", "phyaddrs" : { "ifname" : "can0" }, }, { "ztype": "IO_TYPE_LCAN", "phylabel": "can0.3", "logicallabel": "app3CANcan0.3", "assigngrp" : "app3CANcan0.3", "phyaddrs" : { "ifname" : "can0" }, } ] |
So logically the device is presented with 4 CAN interfaces, the physical (real) controller plus 3 logical interfaces, where each one can be passed-through to each Edge Application. However, all of them point to the same physical can0. In the device model, the interface can0 is the one that describes the physical CAN interface and contains the proper parameters to set up the controller. The logical interfaces app1CAN, app2CAN and app3CANcan0.1, can0.2 and can0.3 point to can0 and can be passed-through the the applications.
...
Code Block |
---|
"ioMemberList": [ { "ztype": "IO_TYPE_VCAN", "phylabel": "vcan0", "logicallabel": "vcan0", "assigngrp" : "", "phyaddrs" : { "ifname" : "vcan0" }, "cbattr" : { "bitrate": "125000", } }, { "ztype": "IO_TYPE_LCAN", "phylabel": "vcan0.1", "logicallabel": "app1VCANvcan0.1", "assigngrp" : "app1VCANvcan0.1", "phyaddrs" : { "ifname" : "vcan0" }, }, { "ztype": "IO_TYPE_LCAN", "phylabel": "vcan0.2", "logicallabel": "app2VCANvcan0.2", "assigngrp" : "app2VCANvcan0.2", "phyaddrs" : { "ifname" : "vcan0" }, }, { "ztype": "IO_TYPE_LCAN", "phylabel": "vcan0.3", "logicallabel": "app3VCANvcan0.3", "assigngrp" : "app3VCANvcan0.3", "phyaddrs" : { "ifname" : "vcan0" }, }, { "ztype": "IO_TYPE_CAN", "phylabel": "can0", "logicallabel": "can0", "assigngrp" : "", "phyaddrs" : { "ifname" : "can0" }, "cbattr" : { "bitrate": "125000", } }, { "ztype": "IO_TYPE_LCAN", "phylabel": "can0.1", "logicallabel": "app1CANcan0.1", "assigngrp" : "app1CANcan0.1", "phyaddrs" : { "ifname" : "can0" }, } ] |
Notice that only one interface should have the type IO_TYPE_VCAN, which is the one that creates the virtual interface on the system. The other interfaces that point to vcan0 should be created as logical CAN interfaces. A single logical CAN interface can also be created for can0, even though it’s going to be accessed by only one application. Thus, a total of six CAN interfaces will be presented to the user: can0 (physical) and app1CANcan0.1 (which can be passed-through to EdgeApp 1); vcan0, which defines the virtual CAN interface; app1VCAN, app2VCAN and app3VCAN vcan0.1, vcan0.2 and vcan0.3, which can be passed-through to EdgeApp 1, EdgeApp 2 and EdgeApp 3, respectively.
...
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_
...