ioctl.c File Reference

Functions
long	can_ioctl (struct file *file, unsigned int cmd, unsigned long arg)
	int ioctl(int fd, int request, ...); the CAN controllers io-control interface More...

Detailed Description

Author

Heinz-Jürgen Oertel, port GmbH

Function Documentation

long can_ioctl	(	struct file *	file,
		unsigned int	cmd,
		unsigned long	arg
	)

int ioctl(int fd, int request, ...); the CAN controllers io-control interface

Parameters

fd	The descriptor to change properties
request	special configuration request
...	traditional a char *argp

The ioctl function manipulates the underlying device parameters of the CAN special device. In particular, many operating characteristics of character CAN driver may be controlled with ioctl requests. The argument fd must be an open file descriptor.

An ioctl request has encoded in it whether the argument is an in parameter or out parameter, and the size of the argument argp in bytes. Macros and defines used in specifying an ioctl request are located in the file can4linux.h .

The following requests are defined:

• CAN_IOCTL_COMMAND some commands for start, stop and reset the CAN controller chip
• CAN_IOCTL_CONFIG configure some of the device properties like acceptance filtering, bit timings, mode of the output control register or the optional software message filter configuration(not implemented yet).
• CAN_IOCTL_STATUS request the CAN controllers status
• CAN_IOCTL_SEND a single message over the ioctl interface
• CAN_IOCTL_RECEIVE poll a receive message
• CAN_IOCTL_CONFIGURERTR configure automatic RTR responses(not implemented)

The third argument is a parameter structure depending on the request. These are

struct Command_par
struct Config_par
struct CanStatusPar
struct ConfigureRTR_par
struct Receive_par
struct Send_par

described in can4linux.h

The following commands are available

• CMD_START calls the target specific can_start_chip function. This normally clears all pending interrupts, enables interrupts and starts the CAN controller by releasing the RESET bit.
• CMD_STOP calls the target specific can_stopchip function. This sets only the RESET bit of the CAN controller which will stop working.
• CMD_RESET calls the target specific can_chip_reset function. This command also sets the RESET bit of the CAN controller, but additionally initializes CAN bit timing the output control register and acceptance and mask registers. The CAN controller itself stays in the RESET mode until CMD_START is called.
• CMD_CLEARBUFFERS clears/empties both the RX fifo of the associated process and the one and only global TX fifo.
• CMD_CTRL_LED control on board LEDs The driver defines different LEDs red, gree, yellow are standard, but may be more and each of the LEDS can have a state on or off.

The normal way of reinitializing CAN is the following ioctl()-command sequence:

• CMD_STOP
• CMD_CLEARBUFFERS
• CMD_RESET
• CMD_START

If the driver is used by more than one application, one should take care that this functionality (like some others) can not be called by any application. Stopping the shared CAN will stop it for all other processes as well. In can4linux the first process opening a device like /dev/canX gets some more privileges marked in the private structure .su as TRUE.

Bit Timing

The bit timing can be set using the ioctl(CONFIG,.. ) and the targets CONF_TIMING or CONF_BTR. CONFIG_TIMING should be used only for the predefined Bit Rates (given in kbit/s). With CONF_BTR it is possible to set the CAN controllers bit timing registers individually by providing the values in val1 (BTR0) and val2 (BTR1).

Acceptance Filtering

Basic CAN. In the case of using base format identifiers in Basic CAN mode for receiving CAN messages only the low bytes are used to set acceptance code and mask for bits ID.10 ... ID.3

PeliCAN. For acceptance filtering the entries AccCode and AccMask are used like specified in the controllers manual for Single Filter Configuration . Both are 4 byte entries. In the case of using base format identifiers for receiving CAN messages also all 4 bytes can be used. In this case two bytes are used for acceptance code and mask for all 11 identifier bits plus additional the first two data bytes. The SJA1000 is working in the Single Filter \ Mode .

Example for extended message format

      Bits
mask  31 30 .....           4  3  2  1  0
code
-------------------------------------------
ID    28 27 .....           1  0  R  +--+-> unused
                                  T
                                  R

 acccode =  (id << 3) + (rtr << 2)

Example for base message format

      Bits
mask  31 30 .....           23 22 21 20 ... 0
code
-------------------------------------------
ID    11 10 .....           1  0  R  +--+-> unused
                                  T
                                  R

You have to shift the CAN-ID by 5 bits and two bytes to shift them into ACR0 and ACR1 (acceptance code register)

acccode =  (id << 21) + (rtr << 20)

In case of the base format match the content of bits 0...20 is of no interest, it can be 0x00000 or 0xFFFFF.

Returns

On success, zero is returned. On error, -1 is returned, and errno is set appropriately.

Example

config_par_t  cfg;
volatile command_par_t cmd;


    cmd.cmd = CMD_STOP;
    ioctl(can_fd, CAN_IOCTL_COMMAND, &cmd);

    cfg.target = CONF_ACCM;
    cfg.val    = acc_mask;
    ioctl(can_fd, CAN_IOCTL_CONFIG, &cfg);
    cfg.target = CONF_ACCC;
    cfg.val    = acc_code;
    ioctl(can_fd, CAN_IOCTL_CONFIG, &cfg);

    cmd.cmd = CMD_START;
    ioctl(can_fd, CAN_IOCTL_COMMAND, &cmd);

Setting the bit timing register

can4linux provides direct access to the bit timing registers, besides an implicit setting using the ioctl CONF_TIMING and fixed values in Kbit/s. In this case ioctl(can_fd, CAN_IOCTL_CONFIG, &cfg); is used with configuration target CONF_BTR The configuration structure contains two values, val1 and val2 . The following relation to the bit timing registers is used regarding the CAN controller:

                           val1            val2
SJA1000                    BTR0            BTR1
BlackFin                   CAN_CLOCK       CAN_TIMING
FlexCAN (to implement)

Bit timings are coded in a table in the <hardware>funcs.c file. The values for the bit timing registers are calculated based on a fixed CAN controller clock. This can lead to wrong bit timings if the processor (or CAN) uses another clock as assumed at compile time. Please check carefully. Depending on the clock, it might be possible that not all bit rates can be generated. (e.g. th Blackfin only supports 100, 125, 250, 500 and 1000 Kbit/s (currently!))

Other CAN_IOCTL_CONFIG configuration targets

(see can4linux.h)

CONF_LISTEN_ONLY_MODE   if set switch to listen only mode
                        (default false)
CONF_SELF_RECEPTION     if set place sent messages back in the RX queue
                        (default false)
CONF_BTR                configure bit timing registers directly
CONF_TIMESTAMP          if set fill time stamp value in message structure
                        (default value 1)
                        Different values are possible and are selecting the
                        time stamp format
                        0 - no time stamp (time stamp is zero)
                        1 - absolute time as gettimeofday()
                        2 - absolute rate monotonic time
                        3 - time difference to the last event (received message)
CONF_WAKEUP             if set wake up waiting processes (default true)