ioctl.c File Reference

Functions

int can_Command (struct inode *inode, struct file *file, Command_par_t *argp)
int can_Send (struct inode *inode, canmsg_t *Tx)
int can_GetStat (struct inode *inode, struct file *file, CanStatusPar_t *s)
int can_Config (struct inode *inode, struct file *file, int target, unsigned long val1, unsigned long val2)
int can_ioctl (__LDDK_IOCTL_PARAM)
 int ioctl(int fd, int request, .

Detailed Description

Author:
Heinz-Jürgen Oertel, port GmbH
Revision
1.8
Date
2009/06/03 14:34:11

Function Documentation

int can_ioctl ( __LDDK_IOCTL_PARAM   ) 

int ioctl(int fd, int request, .

..); the CAN controllers io-control interface

Parameters:
fd The descriptor to change properties
Parameters:
request special configuration request
Parameters:
... 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_StartChip 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_ChipReset 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.
The normal way of reinitializing CAN is the following ioctl()-command sequence:
  • CMD_STOP
  • CMD_CLEARBUFFERS
  • CMD_RESET
  • CMD_START
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 predifined 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 standard 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 standard 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 timng register
can4linux provides direct access to the bit timing registers, besides an implicite 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 true)
CONF_WAKEUP             if set wake up waiting processes (default true)
Generated at Di 17. Mai 08:37:03 CEST 2011 CAN driver can4linux by port GmbH service@port.de , © 1997-2011