Linux can bus socket interface test using

Reprinted from: http://blog.chinaunix.net/uid-26119896-id-3452315.html

Classification:

Original address: Linux can bus socket interface test using Deep_pro

Recently debug a sja1000 can drive, found that the 2.6.36,linux can bus package into a network interface. The reasons for this change are given in the kernel documentation. 1. Overview/what is Socket can--------------------------------the Socketcan package is an implementation of can protocol S (Controller area Network) for Linux.  can is a networking technology which have widespread use of automation, embedded devices, and automotive fields.  while There has been other can implementations for Linux based on character devices, Socket CAN uses the Berkeley s Ocket 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 W ITH network programming, to easily learn how to use CAN sockets.2. Motivation/why using the socket API----------------------------------------There has been CAN implementations for Linux Before Socket CAN so the question arises and why we have started another project.  most existing implementations come as a Device driver for some CAN hardware, they is 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 rec Eive Raw CAN frames, directly to/from the controller hardware. Queueing of frames and higher-level transport protocols like ISO-TP has to is 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 is designed to overcome all of these limitations.  a new protocol family have been implemented which provides A socket interface to user space applications and which BU Ilds 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 th At can frames from the controller CAN is passed up to the network layer and 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 T Ransport protocols can be loaded or unloaded dynamically.  in fact, the can core module alone does not provide any protocol and cannot is used without loading at least one add Itional Protocol module.  multiple sockets can opened at the same time, on different or the same protocol module and they can listen/send F Rames on different or the same CAN IDs.  several sockets listening on the same interface for frames with the same CAN ID is all passed the same received Mat Ching 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 have to D EAL with Can-ids, frames, etc. Similar functionality visible from User-space could is provided by a character device, too, and this would leads to a techn Ically inelegant solution for a couple of reasons:* intricate usage.  instead of passing a protocol argument to sockets (2) and using bind (2) to select a can interface and can IDs, an appli Cation would has the 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 has to be duplicated& nbsp 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 comput Er, a SCSI or IDE controller providing access to your hard  disk or tape streamer device.  instead, you are 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 is provided  by subsystems like the TTY layer, the audio subsystem or the scsi  and ID E subsystems for the devices mentioned above.  the easiest it to implement a CAN device driver is as a character dev Ice without such a (complete) abstraction layer, as was done by the most existing drivers.  the right, however, would is to add such a  layer with all the functionality like registering for certain C an  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 is no more difficult, or may is even easier, to use the networking framework provided B Y the Linux kernel, and this was what Socket CAN does.  the use of the networking framework of the Linux kernel is jus T the natural and most appropriate-implement CAN for linux.         & nbsp;  Well, I'm working, and I like the drive that comes with the kernel. PLX_PCI.C is a plx905x extension of several sja1000 drivers. I am here FPGA made Pci-localbus Bridge, expand 2 pieces of sja1000. It's just for me, it's going to change quickly. The driver, ifocnfig-a can also see can node.   But how to use the Socket can API is very anxious AH. Referring to http://archive.cnblogs.com/a/1916143/, cross-compiling several important tools of Can-utils 4.0.6. The BusyBox file system also has to port the IP command.   1,   First configure can0  IP link set can0 type can TQ prop-seg 6  phase-seg1 7 phase-seg2 2 SJW 1  at this time D MESG can see Sja1000_fpga_pci 0000:07:04.0:setting btr0=0x01 btr1=0x1c  ucos test module, the baud rate of 250kbs is USBCAN-2A btr1=0x1c  2,   ip-details link ShowCan0 Check   can0: <NOARP,UP,LOWER_UP,ECHO> MTU qdisc pfifo_fast State UNKNOWN qlen 10    LINK/CAN&N bsp;    can state error-active (berr-counter TX 0 Rx 0) restart-ms 0     bitrate 500000 Sample-po int 0.875     TQ 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, receive test, receive Ucos test software sent frames: #./candump can0interface = can0, fam ily = 01, type = 3, proto = 1<0x00000002> [8] Geneva 07 <0x00000002> [8] 70 02 03 04 05 07 <0x00000002> [8] in Geneva, 07 <0x00000002> [8] Geneva-07 <0x0 0000002> [8] in Geneva, 07 <0x00000002> [8] in Geneva, 07 <0x00000002> [8] 70 07 <0x00000002> [8] in Geneva, 07 <0x00000002> [8] 70 01 02 03 04 05 06 07  4, send test./CAnsend can0-e 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88interface = can0, family =, type = 3, proto = 1 weeks the receiving frame can be seen on the software test. &NB Sp;5, restart using the kernel document said IP link set can0 type can restart-ms 100 will be reported Rtnetlink Answers:device or resource busy use ifconfig can0 down; IP link Set can0 up type can   does not have the configuration of sja1000 baud rate. Explore 4 Common baud rates: 250KBPS:IP link set Can0 type can TQ prop-seg 6  phase-seg1 7 phase-seg2 2 SJW 1   125kbps:                          ,         &NB SP;IP link Set Can0 type can TQ prop-seg 6  phase-seg1 7 phase-seg2 2 SJW 1           &N Bsp                         &NBSP;&NBSP;500KBPS:IP link set can0 t Ype can TQ prop-seg 6  phase-seg1 7 phase-seg2 2 sjw 1 1000kbps:ip link set can0 up type can bitrate 2000000 often See Usage: ip-details link show can0ifconfig can0 down, IP link set can0 up type Can./candumP can0 ./cansend   CAN0-E 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88

Linux can bus socket interface test using