linux socket can测试

1. Overview / What is Socket CAN

--------------------------------

The socketcan package is an implementation of CAN protocols (Controller Area Network) for Linux.  CAN is a networking technology which has widespread use in automation, embedded devices, and automotive fields.  While there have been other CAN implementations for Linux based on character devices, Socket CAN uses the Berkeley socket API, the Linux network stack and implements the CAN device drivers as network interfaces.  The CAN socket API has been designed as similar as possible to the TCP/IP protocols to allow programmers, familiar with network programming, to easily learn how to use CAN sockets.

2. Motivation / Why using the socket API

----------------------------------------

There have been CAN implementations for Linux before Socket CAN so the question arises, why we have started another project.  Most existing implementations come as a device driver for some CAN hardware, they are based on character devices and provide comparatively little functionality.  Usually, there is only a hardware-specific device driver which provides a character device interface to send and receive raw CAN frames, directly to/from the controller hardware. Queueing of frames and higher-level transport protocols like ISO-TP have to be implemented in user space applications.  Also, most character-device implementations support only one single process to open the device at a time, similar to a serial interface.  Exchanging the CAN controller requires employment of another device driver and often the need for adaption of large parts of the application to the new driver's API.

Socket CAN was designed to overcome all of these limitations.  A new protocol family has been implemented which provides a socket interface to user space applications and which builds upon the Linux network layer, so to use all of the provided queueing functionality.  A device driver for CAN controller hardware registers itself with the Linux network layer as a network device, so that CAN frames from the controller can be passed up to the network layer and on to the CAN protocol family module and also vice-versa.  Also, the protocol family module provides an API for transport protocol modules to register, so that any number of transport protocols can be loaded or unloaded dynamically.  In fact, the can core module alone does not provide any protocol and cannot be used without loading at least one additional protocol module.  Multiple sockets can be opened at the same time, on different or the same protocol module and they can listen/send frames on different or the same CAN IDs.  Several sockets listening on the same interface for frames with the same CAN ID are all passed the same received matching CAN frames.  An application wishing to communicate using a specific transport protocol, e.g. ISO-TP, just selects that protocol when opening the socket, and then can read and write application data byte streams, without having to deal with CAN-IDs, frames, etc.

Similar functionality visible from user-space could be provided by a character device, too, but this would lead to a technically inelegant solution for a couple of reasons:

* Intricate usage.  Instead of passing a protocol argument to socket(2) and using bind(2) to select a CAN interface and CAN ID, an application would have to do all these operations using ioctl(2)s.

* Code duplication.  A character device cannot make use of the Linux network queueing code, so all that code would have to be duplicated

  for CAN networking.

* Abstraction.  In most existing character-device implementations, the hardware-specific device driver for a CAN controller directly

  provides the character device for the application to work with.

  This is at least very unusual in Unix systems for both, char and

  block devices.  For example you don't have a character device for a certain UART of a serial interface, a certain sound chip in your computer, a SCSI or IDE controller providing access to your hard

  disk or tape streamer device.  Instead, you have abstraction layers which provide a unified character or block device interface to the application on the one hand, and a interface for hardware-specific device drivers on the other hand.  These abstractions are provided

  by subsystems like the tty layer, the audio subsystem or the SCSI

  and IDE subsystems for the devices mentioned above.

  The easiest way to implement a CAN device driver is as a character device without such a (complete) abstraction layer, as is done by most existing drivers.  The right way, however, would be to add such a

  layer with all the functionality like registering for certain CAN

  IDs, supporting several open file descriptors and (de)multiplexing

  CAN frames between them, (sophisticated) queueing of CAN frames, and providing an API for device drivers to register with.  However, then

  it would be no more difficult, or may be even easier, to use the networking framework provided by the Linux kernel, and this is what Socket CAN does.

  The use of the networking framework of the Linux kernel is just the natural and most appropriate way to implement CAN for Linux.

  

 

　参照http://archive.cnblogs.com/a/1916143/，交叉编译了can-utils 4.0.6的几个重要工具。busybox的文件系统还要移植ip命令。

  1、

  首先配置can0

  ip link set can0 type can tq 125 prop-seg 6  phase-seg1 7 phase-seg2 2 sjw 1

  这时dmesg可以看到sja1000_fpga_pci 0000:07:04.0: setting BTR0=0x01 BTR1=0x1c

  周立功的usbcan-2a测试模块里，波特率250kbs时就是BTR0=0x01 BTR1=0x1c

  2、

  ip -details link show can0 查看一下

  can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10

    link/can 

    can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 

    bitrate 500000 sample-point 0.875 

    tq 125 prop-seg 6 phase-seg1 7 phase-seg2 2 sjw 1

    sja1000: tseg1 1..16 tseg2 1..8 sjw 1..4 brp 1..64 brp-inc 1

    clock 16000000

 

3、接收测试，接收测试软件发送的帧：

# ./candump can0

interface = can0, family = 29, type = 3, proto = 1

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

<0x00000002> [8] 70 01 02 03 04 05 06 07 

 

4、发送测试

./cansend can0 -e 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

interface = can0, family = 29, type = 3, proto = 1

测试软件上能看到接收的帧

 

5、重启

使用内核文档说的ip link set can0 type can restart-ms 100 会报

RTNETLINK answers: Device or resource busy

使用ifconfig can0 down ;ip link set can0 up type can

即可

 

4种常见波特率：

250kbps：

ip link set can0 type can tq 125 prop-seg 6  phase-seg1 7 phase-seg2 2 sjw 1   

125kbps：                                    

ip link set can0 type can tq 250 prop-seg 6  phase-seg1 7 phase-seg2 2 sjw 1                                       

500kbps：

ip link set can0 type can tq 75 prop-seg 6  phase-seg1 7 phase-seg2 2 sjw 1 

1000kbps：

ip link set can0 up type can bitrate 2000000

常见用法：

ip -details link show can0

ifconfig can0 down ;ip link set can0 up type can

./candump can0 

./cansend   can0 -e 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88