Lines Matching full:can
3 Controller Area Network (CAN) Host Tests
9 This test suite uses `python-can`_ for testing Controller Area Network (CAN) communication between a
17 * The python-can library installed on the host PC.
18 * A CAN fixture creating a CAN bus between the host PC and the DUT.
20 The Zephyr end of the CAN fixture can be configured as follows:
22 * The CAN controller to be used is set using the ``zephyr,canbus`` chosen devicetree node.
23 * The CAN bitrates are set using :kconfig:option:`CONFIG_CAN_DEFAULT_BITRATE` and
24 :kconfig:option:`CONFIG_CAN_DEFAULT_BITRATE_DATA`, but can be overridden on a board level using
25 the ``bitrate`` and ``bitrate-data`` CAN controller devicetree properties if needed. Default
26 bitrates are 125 kbits/s for the arbitration phase/CAN classic and 1 Mbit/s for the CAN FD data
29 The host end of the CAN fixture can be configured through python-can. Available configuration
30 options depend on the type of host CAN adapter used. The python-can library provides a lot of
31 flexibility for configuration as decribed in the `python-can configuration`_ page, all centered
32 around the concept of a configuration "context. The configuration context for this test suite can be
35 * By default, the python-can configuration context is not specified, causing python-can to use the
37 * A specific configuration context can be provided along with the ``can`` fixture separated by a
38 ``:`` (i.e. specify fixture ``can:zcan0`` to use the ``zcan0`` python-can configuration context).
39 * The configuration context can be overridden using the ``--can-context`` test suite argument
40 (i.e. run ``twister`` with the ``--pytest-args=--can-context=zcan0`` argument to use the ``zcan0``
41 python-can configuration context).
49 Running the test suite on :ref:`native_sim` relies on the `Linux SocketCAN`_ virtual CAN driver
50 (vcan) providing a virtual CAN interface named ``zcan0``.
60 Next, python-can needs to be configured for the ``zcan0`` interface. One option is to use a
70 Once the virtual SocketCAN interface has been created, brought up, and configured the test suite can
75 west twister -v -p native_sim/native/64 -X can:zcan0 -T tests/drivers/can/host/
77 After the test suite has completed, the virtual SocketCAN interface can be removed again:
86 Running the test suite on hardware requires a physical CAN adapter connected to the host PC. The CAN
87 adapter must be supported by python-can. The examples below assumes using a Linux SocketCAN
88 interface named ``can0``. For other platforms/adapters, please see the `python-can`_ documentation.
90 The CAN bus of the CAN adapter must be connected to the CAN connector of the device under test.
91 Make sure the CAN bus is terminated with 120 ohm resistors at both ends. The termination resistor
92 may already be present on the device under test, but CAN adapters typically require external bus
97 # Leave out "dbitrate 1000000 fd on" if can0 does not support CAN FD
98 sudo ip link set can0 type can restart-ms 1000 bitrate 125000 dbitrate 1000000 fd on
101 Next, python-can needs to be configured for the ``can0`` interface. One option is to use a dedicated
109 # Set "fd = False" if can0 does not support CAN FD
112 Once the SocketCAN interface has been brought up and configured the test suite can be launched using
117 …55s36/lpc55s36 --device-testing --device-serial /dev/ttyACM0 -X can:can0 -T tests/drivers/can/host/
119 After the test suite has completed, the SocketCAN interface can be brought down again:
125 .. _python-can:
126 https://python-can.readthedocs.io
128 .. _python-can configuration:
129 https://python-can.readthedocs.io/en/stable/configuration.html
132 https://www.kernel.org/doc/html/latest/networking/can.html