Different interface boards and target micro controlllers are supported (see TARGET=VARIABLE in Makefile). The most popular interfaces are the AT-CAN-MINI http://www.port.de/engl/canprod/hw_at.html and CPC-PCI http://www.port.de/engl/canprod/hw_cpcpci.html .
This project was done in cooperation with the LINUX LLP Project to control laboratory or automation devices via CAN. It started already in 1995 and is now considered as mature.
The former and older can4linux version 1.x did support many different interface boards. It was possible to use different kinds of boards at the same time. Up to four boards could be placed in one computer. With this feature it was possible to use /dev/can0 and /dev/can2 for two boards AT-CAN-MINI with SJA1000 and /dev/can1 and /dev/can3 with two CPC-XT equipped with Intel 82527.
Attention: This can4linux version isn't supported anymore !
Instead the new version has to be compiled for the target hardware. It was unlikely in the past that a PC or embedded device was equipped with different CAN controllers.
In all these configurations the programmer sees the same driver interface with open(), close(), read(), write() and ioctl() calls ( can_open(), can_close(), can_read(), can_write(), can_ioctl() ).
The driver itself is highly configurable using the /proc interface of the LINUX kernel.
The following listing shows a typical configuration with three boards:
$ grep . /proc/sys/Can/\* /proc/sys/Can/AccCode: -1 -1 -1 -1 /proc/sys/Can/AccMask: -1 -1 -1 -1 /proc/sys/Can/Base: 800 672 832 896 /proc/sys/Can/Baud: 125 125 125 250 /proc/sys/Can/Chipset: SJA1000 /proc/sys/Can/IOModel: pppp /proc/sys/Can/IRQ: 5 7 3 5 /proc/sys/Can/Outc: 250 250 250 0 /proc/sys/Can/Overrun: 0 0 0 0 /proc/sys/Can/RxErr: 0 0 0 0 /proc/sys/Can/Timeout: 100 100 100 100 /proc/sys/Can/TxErr: 0 0 0 0 /proc/sys/Can/dbgMask: 0 /proc/sys/Can/version: 3.0_ATCANMINI_PELICAN
This above mentioned full flexibility is not needed in embedded applications. For this applications, a stripped-down version exists. It uses the same programming interface but does the most configurations at compile time. That means especially that only one CAN controller support with a special register access method is compiled into the driver. Actually the only CAN controller supported by this version is the Philips SJA 1000 in both the compatibility mode BasicCAN and the Philips PeliCAN mode (compile time selectable).
The version of can4linux currently available at the uClinux CVS tree is also supporting the Motorola FlexCAN module as ist is implemented on Motorolas ColdFire 5282 CPU and the Analog Devices BlackFin DSP with CAN.
Since version 3.4.6 can4linux assumes that your distribution uses udev to have the device `/dev/can[0-9]' automatically created. It is usually necessary to change the device access rights set by udev . With the Fedora Core >= 4 or SuSE/novell you can do:
echo 'KERNEL=="[Cc]an*", NAME="%k", MODE="0666"' \ > /etc/udev/rules.d/91-Can.rules
Alternatively create the device inodes in /lib/udev/devices . At system start-up, the contents of that directory is copied to the /dev directory with the same ownership and permissions as the files in /lib/udev/devices.
The driver creates class Can, with information in /sys/class/Can/
See also udev (7)
The following sections are describing the sysctl entries.
Bit 0 print all debug messages
Bit 1 print function entry message
Bit 2 print function exit message
Bit 3 print if a function branches intwo differnt branches
Bit 4 print debug data statements
For initially writing these sysctl entries after loading the driver (or at any time) a shell script utility does exist. It uses a board configuration file that is written over /proc/sys/Can .
utils/cansetup port.conf
CONFIG := $(shell uname -n)
# load host specific CAN configuration
load:
@echo "Loading etc/$(CONFIG).conf CAN configuration"
utils/cansetup etc/$(CONFIG).conf
echo 0 >/proc/sys/Can/dbgMask
service@port.de ,
© 1997-2006