Lines Matching refs:CAN
40 5.3 writing own CAN protocol modules
42 6 CAN network drivers
45 6.3 CAN controller hardware filters
46 6.4 The virtual CAN driver (vcan)
47 6.5 The CAN network device driver interface
49 6.5.2 Setting the CAN bit-timing
50 6.5.3 Starting and stopping the CAN network device
51 6.6 CAN FD (flexible data rate) driver support
52 6.7 supported CAN hardware
63 The socketcan package is an implementation of CAN protocols
64 (Controller Area Network) for Linux. CAN is a networking technology
66 automotive fields. While there have been other CAN implementations
68 socket API, the Linux network stack and implements the CAN device
69 drivers as network interfaces. The CAN socket API has been designed
71 familiar with network programming, to easily learn how to use CAN
77 There have been CAN implementations for Linux before SocketCAN so the
79 implementations come as a device driver for some CAN hardware, they
83 receive raw CAN frames, directly to/from the controller hardware.
88 the CAN controller requires employment of another device driver and
96 driver for CAN controller hardware registers itself with the Linux
97 network layer as a network device, so that CAN frames from the
98 controller can be passed up to the network layer and on to the CAN
106 frames on different or the same CAN IDs. Several sockets listening on
107 the same interface for frames with the same CAN ID are all passed the
108 same received matching CAN frames. An application wishing to
112 CAN-IDs, frames, etc.
119 socket(2) and using bind(2) to select a CAN interface and CAN ID, an
124 for CAN networking.
127 hardware-specific device driver for a CAN controller directly
140 The easiest way to implement a CAN device driver is as a character
143 layer with all the functionality like registering for certain CAN
145 CAN frames between them, (sophisticated) queueing of CAN frames, and
152 natural and most appropriate way to implement CAN for Linux.
160 TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
161 medium that has no MAC-layer addressing like ethernet. The CAN-identifier
162 (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
163 have to be chosen uniquely on the bus. When designing a CAN-ECU
164 network the CAN-IDs are mapped to be sent by a specific ECU.
165 For this reason a CAN-ID can be treated best as a kind of source address.
171 CAN-IDs from the same CAN network interface. The SocketCAN core
172 module - which implements the protocol family CAN - provides several
174 application opens a CAN RAW socket, the raw protocol module itself
175 requests the (range of) CAN-IDs from the SocketCAN core that are
177 CAN-IDs can be done for specific CAN interfaces or for all(!) known
178 CAN interfaces with the can_rx_(un)register() functions provided to
179 CAN protocol modules by the SocketCAN core (see chapter 5).
195 -----------------(1)- CAN bus -(2)---------------
199 some kind of local loopback of the sent CAN frames on the appropriate
204 arbitration on the CAN bus the transmission of a low prio CAN-ID
205 may be delayed by the reception of a high prio CAN frame. To
208 the CAN network interface is not capable of performing the loopback for
213 networking behaviour for CAN applications. Due to some requests from
215 separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
222 The use of the CAN bus may lead to several problems on the physical
224 layer problems is a vital requirement for CAN users to identify
229 reason the CAN interface driver can generate so called Error Message
231 same way as other CAN frames. Whenever an error on the physical layer
232 or the MAC layer is detected (e.g. by the CAN controller) the driver
234 be requested by the user application using the common CAN filter
237 by default. The format of the CAN error message frame is briefly
244 CAN network. Since SocketCAN implements a new protocol family, you
246 call. Currently, there are two CAN protocols to choose from, the raw
257 normally use the bind(2) system call to bind the socket to a CAN
262 on the socket as usual. There are also CAN specific socket options
265 The basic CAN frame structure and the sockaddr structure are defined
279 the CAN payload. There is no given byteorder on the CAN bus by
293 /* reserved for future CAN protocols address information */
316 To bind a socket to all(!) CAN interfaces the interface index must
317 be 0 (zero). In this case the socket receives CAN frames from every
318 enabled CAN interface. To determine the originating CAN interface
323 Reading CAN frames from a bound CAN_RAW socket (see above) consists
337 fprintf(stderr, "read: incomplete CAN frame\n");
341 /* do something with the received CAN frame */
343 Writing CAN frames can be done similarly, with the write(2) system call:
347 When the CAN interface is bound to 'any' existing CAN interface
349 information about the originating CAN interface is needed:
359 /* get interface name of the received CAN frame */
362 printf("Received a CAN frame from interface %s", ifr.ifr_name);
364 To write CAN frames on sockets bound to 'any' CAN interface the
375 Remark about CAN FD (flexible data rate) support:
377 Generally the handling of CAN FD is very similar to the formerly described
378 examples. The new CAN FD capable CAN controllers support two different
379 bitrates for the arbitration phase and the payload phase of the CAN FD frame
381 kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight
384 switches the socket into a mode that allows the handling of CAN FD frames
385 and (legacy) CAN frames simultaneously (see section 4.1.5).
392 __u8 flags; /* additional flags for CAN FD */
410 For details about the distinction of CAN and CAN FD capable devices and
413 The length of the two CAN(FD) frame structures define the maximum transfer
414 unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
415 definitions are specified for CAN specific MTUs in include/linux/can.h :
417 #define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame
418 #define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame
423 known access to CAN character devices. To meet the new possibilities
429 - The loopback of sent CAN frames is enabled (see chapter 3.2)
438 The reception of CAN frames using CAN_RAW sockets can be controlled
441 The CAN filter structure is defined in include/linux/can.h:
452 which is analogous to known CAN controllers hardware filter semantics.
455 contrast to CAN controller hardware filters the user may set 0 .. n
467 To disable the reception of CAN frames on the selected CAN_RAW socket:
472 data causes the raw socket to discard the received CAN frames. But
476 4.1.1.1 CAN filter usage optimisation
478 The CAN filters are processed in per-device filter lists at CAN frame
480 while walking through the filter lists the CAN core provides an optimized
481 filter handling when the filter subscription focusses on a single CAN ID.
483 For the possible 2048 SFF CAN identifiers the identifier is used as an index
485 For the 2^29 possible EFF CAN identifiers a 10 bit XOR folding is used as
488 To benefit from the optimized filters for single CAN identifiers the
491 can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is
497 both SFF frames with CAN ID 0x123 and EFF frames with 0xXXXXX123 can pass.
499 To filter for only 0x123 (SFF) and 0x12345678 (EFF) CAN identifiers the
513 As described in chapter 3.3 the CAN interface driver can generate so
515 application in the same way as other CAN frames. The possible
530 (e.g. when only one application uses the CAN bus) this loopback
539 When the local loopback is enabled, all the sent CAN frames are
540 looped back to the open CAN sockets that registered for the CAN
541 frames' CAN-ID on this given interface to meet the multi user
542 needs. The reception of the CAN frames on the same socket that was
543 sending the CAN frame is assumed to be unwanted and therefore
554 CAN FD support in CAN_RAW sockets can be enabled with a new socket option
559 Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames
560 and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames
574 printf("got CAN FD frame with length %d\n", cfd.len);
577 printf("got legacy CAN frame with length %d\n", cfd.len);
580 fprintf(stderr, "read: invalid CAN(FD) frame\n");
591 been received from the socket a legacy CAN frame has been read into the
592 provided CAN FD structure. Note that the canfd_frame.flags data field is
594 CANFD_MTU sized CAN FD frames.
596 Implementation hint for new CAN applications:
598 To build a CAN FD aware application use struct canfd_frame as basic CAN
601 socket option returns an error: No problem. You'll get legacy CAN frames
602 or CAN FD frames and can process them the same way.
604 When sending to CAN devices make sure that the device is capable to handle
605 CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU.
606 The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
610 The CAN_RAW socket can set multiple CAN identifier specific filters that
615 This socket option joines the given CAN filters in the way that only CAN
616 frames are passed to user space that matched *all* given CAN filters. The
620 where the CAN_INV_FILTER flag is set in order to notch single CAN IDs or
621 CAN ID ranges from the incoming traffic.
631 CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
637 interface to filter and send (e.g. cyclic) CAN messages in kernel space.
643 Periodic transmission tasks of CAN frames or a sequence of CAN frames can be
647 A BCM socket is not intended for sending individual CAN frames using the
652 message header with a command ('opcode') followed by zero or more CAN frames.
665 The aligned payload 'frames' uses the same basic CAN frame structure defined
691 CAN_BCM sockets are recommended to communicate on multiple CAN interfaces.
692 When the broadcast manager socket is bound to 'any' CAN interface (=> the
694 CAN interface unless the sendto() syscall is used to overrule the 'any' CAN
696 socket messages the originating CAN interface is provided in can_ifindex.
712 TX_SEND: Send one CAN frame.
735 RX_CHANGED: BCM message with updated CAN frame (detected content change).
736 Sent on first message received or on receipt of revised CAN messages.
746 and count. Starting the timer leads simultaneously to emit a CAN frame.
781 Up to 256 CAN frames can be transmitted in a sequence in the case of a cyclic
782 TX task configuration. The number of CAN frames is provided in the 'nframes'
783 element of the BCM message head. The defined number of CAN frames are added
786 /* create a struct to set up a sequence of four CAN frames */
798 With every transmission the index in the array of CAN frames is increased
808 is activated directly - even without a former CAN frame reception.
812 CAN frame is stateless as state changes within the ival2 periode may get
818 than one CAN frames can be passed in a RX_SETUP configuration message. The
819 data bytes of the first CAN frame contain the mask of relevant bits that
820 have to match in the subsequent CAN frames with the received CAN frame.
821 If one of the subsequent CAN frames is matching the bits in that frame data
823 Up to 257 CAN frames (multiplex filter bit mask CAN frame plus 256 CAN
826 /* usually used to clear CAN frame data[] - beware of endian problems! */
854 PF_CAN. CAN protocol modules are loaded by the core module at
855 runtime. The core module provides an interface for CAN protocol
856 modules to subscribe needed CAN IDs (see chapter 3.1).
870 lists to deliver received CAN frames to CAN protocol modules. These
885 In this example an application requests any CAN traffic from vcan0.
900 5.3 writing own CAN protocol modules
906 In addition to functions that register the CAN protocol and the
907 CAN device notifier chain there are functions to subscribe CAN
908 frames received by CAN interfaces and to send CAN frames:
910 can_rx_register - subscribe CAN frames from a specific interface
911 can_rx_unregister - unsubscribe CAN frames from a specific interface
912 can_send - transmit a CAN frame (optional with local loopback)
917 6. CAN network drivers
920 Writing a CAN network device driver is much easier than writing a
921 CAN character device driver. Similar to other known network device
924 - TX: Put the CAN frame from the socket buffer to the CAN controller.
925 - RX: Put the CAN frame from the CAN controller to the socket buffer.
928 for writing CAN network device driver are described below:
933 dev->flags = IFF_NOARP; /* CAN has no arp */
935 dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
937 or alternative, when the controller supports CAN with flexible data rate:
938 dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
945 As described in chapter 3.2 the CAN network device driver should
953 6.3 CAN controller hardware filters
955 To reduce the interrupt load on deep embedded systems some CAN
956 controllers support the filtering of CAN IDs or ranges of CAN IDs.
966 @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
969 6.4 The virtual CAN driver (vcan)
972 CAN interface. A full qualified address on CAN consists of
974 - a unique CAN Identifier (CAN ID)
975 - the CAN bus this CAN ID is transmitted on (e.g. can0)
977 so in common use cases more than one virtual CAN interface is needed.
979 The virtual CAN interfaces allow the transmission and reception of CAN
980 frames without real CAN controller hardware. Virtual CAN network
982 When compiled as a module the virtual CAN driver module is called vcan.ko
988 - Create a virtual CAN network interface:
991 - Create a virtual CAN network interface with a specific name 'vcan42':
994 - Remove a (virtual CAN) network interface 'vcan42':
997 6.5 The CAN network device driver interface
999 The CAN network device driver interface provides a generic interface
1000 to setup, configure and monitor CAN network devices. The user can then
1001 configure the CAN device, like setting the bit-timing parameters, via
1005 set of common functions, which all real CAN network device drivers
1011 The CAN device must be configured via netlink interface. The supported
1013 "include/linux/can/netlink.h". CAN link support for the program "ip"
1017 - Setting CAN device properties:
1050 - Display CAN device details and statistics:
1070 Shows the list of selected CAN controller modes: LOOPBACK,
1074 The current state of the CAN controller: "ERROR-ACTIVE",
1079 restart of the CAN controller will be triggered automatically
1094 tq. They allow to define the CAN bit-timing in a hardware
1095 independent format as proposed by the Bosch CAN 2.0 spec (see
1100 Shows the bit-timing constants of the CAN controller, here the
1103 bitrate pre-scaler and the CAN system clock frequency in Hz.
1113 6.5.2 Setting the CAN bit-timing
1115 The CAN bit-timing parameters can always be defined in a hardware
1116 independent format as proposed in the Bosch CAN 2.0 specification
1124 recommended CAN bit-timing parameters will be calculated if the bit-
1129 Note that this works fine for the most common CAN controllers with
1130 standard bit-rates but may *fail* for exotic bit-rates or CAN system
1133 bit-timing parameters. The CAN controller specific bit-timing
1141 6.5.3 Starting and stopping the CAN network device
1143 A CAN network device is started or stopped as usual with the command
1145 you *must* define proper bit-timing parameters for real CAN devices
1151 the CAN bus. Then no more messages are received or sent. An automatic
1158 by monitoring CAN error message frames and do a restart when
1163 Note that a restart will also create a CAN error message frame (see
1166 6.6 CAN FD (flexible data rate) driver support
1168 CAN FD capable CAN controllers support two different bitrates for the
1169 arbitration phase and the payload phase of the CAN FD frame. Therefore a
1170 second bit timing has to be specified in order to enable the CAN FD bitrate.
1172 Additionally CAN FD capable CAN controllers support up to 64 bytes of
1175 layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
1177 CAN frames anyway. The payload length to the bus-relevant DLC mapping is
1178 only performed inside the CAN drivers, preferably with the helper
1181 The CAN netdevice driver capabilities can be distinguished by the network
1184 MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device
1185 MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
1187 The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
1188 N.B. CAN FD capable devices can also handle and send legacy CAN frames.
1190 When configuring CAN FD capable CAN controllers an additional 'data' bitrate
1191 has to be set. This bitrate for the data phase of the CAN FD frame has to be
1197 specified to enable the CAN FD mode in the CAN controller. This controller
1200 The first CAN FD specification presented as whitepaper at the International
1201 CAN Conference 2012 needed to be improved for data integrity reasons.
1202 Therefore two CAN FD implementations have to be distinguished today:
1204 - ISO compliant: The ISO 11898-1:2015 CAN FD implementation (default)
1205 - non-ISO compliant: The CAN FD implementation following the 2012 whitepaper
1207 Finally there are three types of CAN FD controllers:
1211 3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK PCAN-USB FD)
1213 The current ISO/non-ISO mode is announced by the CAN controller driver via
1216 switchable CAN FD controllers only.
1237 Example when 'fd-non-iso on' is added on this switchable CAN FD adapter:
1240 6.7 Supported CAN hardware
1243 list of the support CAN hardware. On the SocketCAN project website
1250 The Linux CAN / SocketCAN project ressources (project site / mailing list)
1252 Search for CAN NETWORK [LAYERS|DRIVERS].
1261 CAN device driver interface, MSCAN driver)
1267 Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
1269 Uwe Koppe (CAN netdevices with PF_PACKET approach)
1270 Michael Schulze (driver layer loopback requirement, RT CAN drivers review)