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
http://www.linux.it/~rubini/software/ocan/ocan.html

We have a OCAN driver for the i82527 on our  FTP  server  (tested  on
TQM8xxL  PowerPC  systems).  See  http://www.denx.de/ , next to last
entry in the "News" column.

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:

http://www.peak-system.com/linux/index.htm

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:
http://www.CAN-Wiki.info/CanInterfaceAPI

Heinz

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



I know!

Sven

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

...


Nice! So let me ask two questions:

1.) Will concurrent access be possible?
2.) Where is the code?

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

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