LinCAN Driver API

Driver API Overview

Each driver is a subsystem which has no direct application level API. The operating system is responsible for user space calls transformation into driver functions calls or dispatch routines invocations. The CAN driver is implemented as a character device with the standard device node names /dev/can0, /dev/can1, etc. The application program communicates with the driver through the standard system low level input/output primitives (open, close, read, write, select and ioctl). The CAN driver convention of usage of these functions is described in the next subsection.

The read and write functions need to transfer one or more CAN messages. The structure canmsg_t is defined for this purpose and is defined in include file can/can.h. The canmsg_t structure has next fields:

      struct canmsg_t { 
          short flags; 
          int cob; 
          unsigned long id; 
          unsigned long timestamp; 
          unsigned int length; 
          unsigned char
          data[CAN_MSG_LENGTH]; 
      } PACKED;

flags

The flags field holds information about message type. The bit MSG_RTR marks remote transmission request messages. Writing of such message into the CAN message object handle results in transmission of the RTR message. The RTR message can be received by the read call if no buffer with corresponding ID is pre-filled in the driver. The bit MSG_EXT indicates that the message with extended (bit 29 set) ID will be send or was received. The bit MSG_OVR is intended for fast indication of the reception message queue overfill.

cob

The field reserved for a holding message communication object number. It could be used for serialization of received messages from more message object into one message queue in the future.

id

CAN message ID.

timestamp

The field intended for storing of the message reception time.

length

The number of the data bytes send or received in the CAN message. The number of data load bytes is from 0 to 8.

data

The byte array holding message data.

As was mentioned above, direct communication with the driver through system calls is not encouraged because this interface is partially system dependent and cannot be ported to all environments. The suggested alternative is to use OCERA provided VCA library which defines the portable and clean interface to the CAN driver implementation.

The other issue is addition of the support for new CAN interface boards and CAN controller chips. The subsection Board Support Functions describes template functions, which needs to be implemented for newly supported board. The template of board support can be found in the file src/template.c.

The other task for more brave souls is addition of the support for the unsupported chip type. The source supporting the SJA1000 chip in the PeliCAN mode can serve as an example. The full source of this chip support is stored in the file src/sja1000p.c. The subsection Chip Support Functions describes basic functions necessary for the new chip support.