Intel 82527 CAN-driver

You must be missing something, then.

Right. This one is pretty dead.

But there is Alessandro Rubini's OCAN project; see for example

We have a OCAN driver for the i82527 on our FTP server (tested on TQM8xxL PowerPC systems). See

Best regards,

Wolfgang Denk

OK, this one is for 82527 based Hardware only. For this reason it has not been an Option for me, since all my devices used to be SJA1000 based.

It would be nice to have a somewhat standardised CAN-Bus API or finaly something which could be included in the Mainstream kernel.

This is not something which will happen sometime soon, as the can4linux code is somewhat ugly (IMO). I did not have a look at Alessandros sources but I expect them to be much more clean (as he is the Author of Linux Device Drivers after all).

Probably we should try to join forces on this Topic.

I once also wrote my own device drive which still has a feature that all the others (AFAIK) lack. My driver is capable of connecting more than one process. For this reason this beast is still in use in a project I'm working on but I would like to finaly port this Software to a common API.

Sven

OK, this one is for 82527 based Hardware only. For this reason it has not been an Option for me, since all my devices used to be SJA1000 based.

It would be a very good thing to have a somewhat standardised CAN-Bus API (like COMEDI has for Data Aquisition) hiding the differences between Hardware (82527, SJA1000, ...).

Even better would be something which could be included in the Mainstream kernel!

Unfortunately this will not happen sometime soon, as non of the currently available driver packages would qualify for this ambitious goal!

Probably we should try to join forces on this Topic!

IMO can4linux suffers from a somewhat ugly Codebase while all the other drivers I have seen support way to few devices.

I also have my own CAN-BUS device driver, which has been written because the can4linux Project has obviously been dead at this stage and I needed something usable.

It can be found here, but it lacks a lot of features (namely support for extended CAN frames whic I did not need at this time):

ftp://wsd.iitb.fhg.de/pub/linux/can-driver-0.5.tar.gz

Anyway, it still has a feature that all the others (AFAIK) lack:

Concurrent access to the CAN-Bus by multiple processes!

For this reason this driver is still in active use here in a project I'm working on. Anyway I would prefer to finaly port the application Software to a common CAN-Bus API.

Some time ago I came across another Linux CAN-Bus driver which is quite up to date and has something I would call readable code:

The downside with this is, that they have support for their own Hardware (SJA100 based AFAIR) only.

Sven

You are right. For the Motorola Coldfire can4linux is already in the uClinux-kernel CVS-tree. It can be used with the FlexCAN and SJA1000. Support for the 82527 is planned and development is underway.

Hmm. It is still alive. Maybe not quite so actively as some might wish.

And they don't used the "normal" device-access methods via read, write and fcntl. At least when I last checked it.

the newest, just in development, supports this requested feature by providing an rx/tx-buffer for each process opening the CAN device.

can4linux is open for all who want to provide input. The chance to talk about an API is always at:

Heinz

just curious, what kind of device you are implementing. From the CANopen view, which CANopen Device profile is used, or from the NMT view a network slave or master. In any case how many "communication objects" will the device use, SDOs, PDOs, EMCY, NMT ...?

Heinz

You are right. Another shortcoming of OCAN is that it does not integrate with RTAI.

Maybe; but a clean separate package would be useful, too.

Maybe it happens faster than you think :-)

Here is what we are thinking about (eCAN = Embedded CAN):

=====================================================================

eCAN driver design goals and implementation details

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

o Generic support for standalone CAN controllers like Intel 82527, Infineon SAK 82C900, Philips SJA 1000, MPC5200 MSCAN, etc. The driver should also support non-standard features of a chip somehow.

o Support for RTAI and Linux: There will be a function API for RTAI and a Linux driver. Note that you can either us the Linux driver or the RTAI API to control the CAN bus but not both at the same time.

o The CAN Linux driver can easily be integrated into the kernel tree allowing static and dynamic linking. The driver and some options can be selected with the kernel configuration tools as usual (make config). Likely we will make it even available in our linux kernel trees.

o The RTAI function API can easily be integrated as a loadable RTAI kernel module.

o CAN channel setup and usage: A CAN RX channel can be setup as shown in the code fragment below and it should support software and hardware filtering:

can_chan_t rx_chan; can_msg_t msg; int fd, rc;

rx_chan.node_nr = 1; // Controller or Bus number rx_chan.obj_nr = 0; // Object number (=0 for MSCAN). rx_chan.flags = CAN_CHAN_READ; rx_chan.queue_size = 32; rx_chan.filter_type = 0; // No filtering

fd = open("/dev/can", flags);

ioctl(fd, CAN_REQUEST_RX_CHAN, &rx_chan);

rc = read(fd, &msg, sizeof(msg));

Note that a channel is always assigned to one file descriptor.

Filtering permits to handle groups of CAN message identifiers and the filtering could be done in software or hardware if applicable. Here are code examples on how this could be done:

// Hardware filter: MSCAN has up to 8 filters rx_chan.filter_type = CAN_HARD_FILTER; rx_chan.filder_id = 2; // Number of pre-defined filter.

// Software filter: rx_chan.filter_type = CAN_SOFT_FILTER; rx_chan.filter_id = 0x120 rx_chan.filter_mask = 0x3f0

Note: The soft filter definitions are stored in linked lists and when a new CAN message arrives it will be scanned to find the appropriate channel.

The TX channel setup can be done as shown below. This example support the priority field of the three CAN TX message objects:

can_chan_t tx_chan; can_msg_t msg; int fd, rc;

fd = open("/dev/can", flags);

tx_chan.node_nr = 0; // Controller or Bus number tx_chan.obj_nr = 1; // Object number (0..2 for MSCAN). tx_chan.queue_size = 32;

ioctl(fd, CAN_REQUEST_TX_CHAN, &tx_chan);

msg.id = 0x123; msg.type = CAN_TYPE_STANDARD; msg.prio = 2; // Support for MSCAN priority msg.dlc = 2; msg.data[0] = 0x12; msg.data[1] = 0x34;

rc = write(fd, &msg, sizeof(msg));

o There will be basic functions and ioctl requests for reset, setting the timing parameters and reading/writing registers of the CAN controller.

o There will be support for basic error handling but the real requirement has to be specified e.g. how should an error be reported to the application. In Linux this could be done via:

- Asynchronous notification (as done in OCAN). - Poll/select mechanism. - Simple polling using ioctl function calls.

In RTAI a callback function could be defined and used.

o There will be basic test programs to demonstrate the RX and TX of CAN messages with the Linux driver and the RTAI API.

o There will be no deferred interrupt handling. This could be implemented in a second step using bottom halfs in Linux or a service task in RTAI.

=====================================================================

How does that sound?

We have a modified version of the PCAN driver running on the Motorola MPC5200 internal MSCAN controllers...

Best regards,

Wolfgang Denk

fine! This will probably mean, that I can switch my Application to can4linux

I know!

Sven

...

Nice! So let me ask two questions:

Sven, using at least 4 different SJA1000 based CAN-Bus devices

I think so, although this is not a major objective for the first version.

Under design. Feel free to contact me if you want to help sponsoring the project.

Best regards,

Wolfgang Denk