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
276 the CAN payload. There is no given byteorder on the CAN bus by
290 /* reserved for future CAN protocols address information */
313 To bind a socket to all(!) CAN interfaces the interface index must
314 be 0 (zero). In this case the socket receives CAN frames from every
315 enabled CAN interface. To determine the originating CAN interface
320 Reading CAN frames from a bound CAN_RAW socket (see above) consists
334 fprintf(stderr, "read: incomplete CAN frame\n");
338 /* do something with the received CAN frame */
340 Writing CAN frames can be done similarly, with the write(2) system call:
344 When the CAN interface is bound to 'any' existing CAN interface
346 information about the originating CAN interface is needed:
356 /* get interface name of the received CAN frame */
359 printf("Received a CAN frame from interface %s", ifr.ifr_name);
361 To write CAN frames on sockets bound to 'any' CAN interface the
372 Remark about CAN FD (flexible data rate) support:
374 Generally the handling of CAN FD is very similar to the formerly described
375 examples. The new CAN FD capable CAN controllers support two different
376 bitrates for the arbitration phase and the payload phase of the CAN FD frame
378 kernel interfaces (ABI) which heavily rely on the CAN frame with fixed eight
381 switches the socket into a mode that allows the handling of CAN FD frames
382 and (legacy) CAN frames simultaneously (see section 4.1.5).
389 __u8 flags; /* additional flags for CAN FD */
407 For details about the distinction of CAN and CAN FD capable devices and
410 The length of the two CAN(FD) frame structures define the maximum transfer
411 unit (MTU) of the CAN(FD) network interface and skbuff data length. Two
412 definitions are specified for CAN specific MTUs in include/linux/can.h :
414 #define CAN_MTU (sizeof(struct can_frame)) == 16 => 'legacy' CAN frame
415 #define CANFD_MTU (sizeof(struct canfd_frame)) == 72 => CAN FD frame
420 known access to CAN character devices. To meet the new possibilities
426 - The loopback of sent CAN frames is enabled (see chapter 3.2)
435 The reception of CAN frames using CAN_RAW sockets can be controlled
438 The CAN filter structure is defined in include/linux/can.h:
449 which is analogous to known CAN controllers hardware filter semantics.
452 contrast to CAN controller hardware filters the user may set 0 .. n
464 To disable the reception of CAN frames on the selected CAN_RAW socket:
469 data causes the raw socket to discard the received CAN frames. But
473 4.1.1.1 CAN filter usage optimisation
475 The CAN filters are processed in per-device filter lists at CAN frame
477 while walking through the filter lists the CAN core provides an optimized
478 filter handling when the filter subscription focusses on a single CAN ID.
480 For the possible 2048 SFF CAN identifiers the identifier is used as an index
482 For the 2^29 possible EFF CAN identifiers a 10 bit XOR folding is used as
485 To benefit from the optimized filters for single CAN identifiers the
488 can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is
494 both SFF frames with CAN ID 0x123 and EFF frames with 0xXXXXX123 can pass.
496 To filter for only 0x123 (SFF) and 0x12345678 (EFF) CAN identifiers the
510 As described in chapter 3.4 the CAN interface driver can generate so
512 application in the same way as other CAN frames. The possible
527 (e.g. when only one application uses the CAN bus) this loopback
536 When the local loopback is enabled, all the sent CAN frames are
537 looped back to the open CAN sockets that registered for the CAN
538 frames' CAN-ID on this given interface to meet the multi user
539 needs. The reception of the CAN frames on the same socket that was
540 sending the CAN frame is assumed to be unwanted and therefore
551 CAN FD support in CAN_RAW sockets can be enabled with a new socket option
556 Once CAN_RAW_FD_FRAMES is enabled the application can send both CAN frames
557 and CAN FD frames. OTOH the application has to handle CAN and CAN FD frames
571 printf("got CAN FD frame with length %d\n", cfd.len);
574 printf("got legacy CAN frame with length %d\n", cfd.len);
577 fprintf(stderr, "read: invalid CAN(FD) frame\n");
588 been received from the socket a legacy CAN frame has been read into the
589 provided CAN FD structure. Note that the canfd_frame.flags data field is
591 CANFD_MTU sized CAN FD frames.
593 Implementation hint for new CAN applications:
595 To build a CAN FD aware application use struct canfd_frame as basic CAN
598 socket option returns an error: No problem. You'll get legacy CAN frames
599 or CAN FD frames and can process them the same way.
601 When sending to CAN devices make sure that the device is capable to handle
602 CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU.
603 The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
607 The CAN_RAW socket can set multiple CAN identifier specific filters that
612 This socket option joines the given CAN filters in the way that only CAN
613 frames are passed to user space that matched *all* given CAN filters. The
617 where the CAN_INV_FILTER flag is set in order to notch single CAN IDs or
618 CAN ID ranges from the incoming traffic.
628 CAN driver supports the echo of frames on driver level, see 3.2 and 6.2.
634 interface to filter and send (e.g. cyclic) CAN messages in kernel space.
640 Periodic transmission tasks of CAN frames or a sequence of CAN frames can be
644 A BCM socket is not intended for sending individual CAN frames using the
649 message header with a command ('opcode') followed by zero or more CAN frames.
662 The aligned payload 'frames' uses the same basic CAN frame structure defined
688 CAN_BCM sockets are recommended to communicate on multiple CAN interfaces.
689 When the broadcast manager socket is bound to 'any' CAN interface (=> the
691 CAN interface unless the sendto() syscall is used to overrule the 'any' CAN
693 socket messages the originating CAN interface is provided in can_ifindex.
709 TX_SEND: Send one CAN frame.
732 RX_CHANGED: BCM message with updated CAN frame (detected content change).
733 Sent on first message received or on receipt of revised CAN messages.
743 and count. Starting the timer leads simultaneously to emit a CAN frame.
778 Up to 256 CAN frames can be transmitted in a sequence in the case of a cyclic
779 TX task configuration. The number of CAN frames is provided in the 'nframes'
780 element of the BCM message head. The defined number of CAN frames are added
783 /* create a struct to set up a sequence of four CAN frames */
795 With every transmission the index in the array of CAN frames is increased
805 is activated directly - even without a former CAN frame reception.
809 CAN frame is stateless as state changes within the ival2 periode may get
815 than one CAN frames can be passed in a RX_SETUP configuration message. The
816 data bytes of the first CAN frame contain the mask of relevant bits that
817 have to match in the subsequent CAN frames with the received CAN frame.
818 If one of the subsequent CAN frames is matching the bits in that frame data
820 Up to 257 CAN frames (multiplex filter bit mask CAN frame plus 256 CAN
823 /* usually used to clear CAN frame data[] - beware of endian problems! */
851 PF_CAN. CAN protocol modules are loaded by the core module at
852 runtime. The core module provides an interface for CAN protocol
853 modules to subscribe needed CAN IDs (see chapter 3.1).
867 lists to deliver received CAN frames to CAN protocol modules. These
882 In this example an application requests any CAN traffic from vcan0.
897 5.3 writing own CAN protocol modules
903 In addition to functions that register the CAN protocol and the
904 CAN device notifier chain there are functions to subscribe CAN
905 frames received by CAN interfaces and to send CAN frames:
907 can_rx_register - subscribe CAN frames from a specific interface
908 can_rx_unregister - unsubscribe CAN frames from a specific interface
909 can_send - transmit a CAN frame (optional with local loopback)
914 6. CAN network drivers
917 Writing a CAN network device driver is much easier than writing a
918 CAN character device driver. Similar to other known network device
921 - TX: Put the CAN frame from the socket buffer to the CAN controller.
922 - RX: Put the CAN frame from the CAN controller to the socket buffer.
925 for writing CAN network device driver are described below:
930 dev->flags = IFF_NOARP; /* CAN has no arp */
932 dev->mtu = CAN_MTU; /* sizeof(struct can_frame) -> legacy CAN interface */
934 or alternative, when the controller supports CAN with flexible data rate:
935 dev->mtu = CANFD_MTU; /* sizeof(struct canfd_frame) -> CAN FD interface */
942 As described in chapter 3.2 the CAN network device driver should
950 6.3 CAN controller hardware filters
952 To reduce the interrupt load on deep embedded systems some CAN
953 controllers support the filtering of CAN IDs or ranges of CAN IDs.
963 @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
966 6.4 The virtual CAN driver (vcan)
969 CAN interface. A full qualified address on CAN consists of
971 - a unique CAN Identifier (CAN ID)
972 - the CAN bus this CAN ID is transmitted on (e.g. can0)
974 so in common use cases more than one virtual CAN interface is needed.
976 The virtual CAN interfaces allow the transmission and reception of CAN
977 frames without real CAN controller hardware. Virtual CAN network
979 When compiled as a module the virtual CAN driver module is called vcan.ko
985 - Create a virtual CAN network interface:
988 - Create a virtual CAN network interface with a specific name 'vcan42':
991 - Remove a (virtual CAN) network interface 'vcan42':
994 6.5 The CAN network device driver interface
996 The CAN network device driver interface provides a generic interface
997 to setup, configure and monitor CAN network devices. The user can then
998 configure the CAN device, like setting the bit-timing parameters, via
1002 set of common functions, which all real CAN network device drivers
1008 The CAN device must be configured via netlink interface. The supported
1010 "include/linux/can/netlink.h". CAN link support for the program "ip"
1014 - Setting CAN device properties:
1038 - Display CAN device details and statistics:
1058 Shows the list of selected CAN controller modes: LOOPBACK,
1062 The current state of the CAN controller: "ERROR-ACTIVE",
1067 restart of the CAN controller will be triggered automatically
1082 tq. They allow to define the CAN bit-timing in a hardware
1083 independent format as proposed by the Bosch CAN 2.0 spec (see
1088 Shows the bit-timing constants of the CAN controller, here the
1091 bitrate pre-scaler and the CAN system clock frequency in Hz.
1101 6.5.2 Setting the CAN bit-timing
1103 The CAN bit-timing parameters can always be defined in a hardware
1104 independent format as proposed in the Bosch CAN 2.0 specification
1112 recommended CAN bit-timing parameters will be calculated if the bit-
1117 Note that this works fine for the most common CAN controllers with
1118 standard bit-rates but may *fail* for exotic bit-rates or CAN system
1121 bit-timing parameters. The CAN controller specific bit-timing
1129 6.5.3 Starting and stopping the CAN network device
1131 A CAN network device is started or stopped as usual with the command
1133 you *must* define proper bit-timing parameters for real CAN devices
1139 the CAN bus. Then no more messages are received or sent. An automatic
1146 by monitoring CAN error message frames and do a restart when
1151 Note that a restart will also create a CAN error message frame (see
1154 6.6 CAN FD (flexible data rate) driver support
1156 CAN FD capable CAN controllers support two different bitrates for the
1157 arbitration phase and the payload phase of the CAN FD frame. Therefore a
1158 second bit timing has to be specified in order to enable the CAN FD bitrate.
1160 Additionally CAN FD capable CAN controllers support up to 64 bytes of
1163 layer is a plain value from 0 .. 64 instead of the CAN 'data length code'.
1165 CAN frames anyway. The payload length to the bus-relevant DLC mapping is
1166 only performed inside the CAN drivers, preferably with the helper
1169 The CAN netdevice driver capabilities can be distinguished by the network
1172 MTU = 16 (CAN_MTU) => sizeof(struct can_frame) => 'legacy' CAN device
1173 MTU = 72 (CANFD_MTU) => sizeof(struct canfd_frame) => CAN FD capable device
1175 The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall.
1176 N.B. CAN FD capable devices can also handle and send legacy CAN frames.
1178 FIXME: Add details about the CAN FD controller configuration when available.
1180 6.7 Supported CAN hardware
1183 list of the support CAN hardware. On the SocketCAN project website
1190 The Linux CAN / SocketCAN project ressources (project site / mailing list)
1192 Search for CAN NETWORK [LAYERS|DRIVERS].
1201 CAN device driver interface, MSCAN driver)
1207 Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
1209 Uwe Koppe (CAN netdevices with PF_PACKET approach)
1210 Michael Schulze (driver layer loopback requirement, RT CAN drivers review)