can_ioctl.c.3

can4linux.3.4.6.gz,一个CAN的高级协议包装

.TH "can_ioctl.c" 3 "18 Oct 2005" "can4linux" \" -*- nroff -*-
.ad l
.nh
.SH NAME
can_ioctl.c \- 
.SH SYNOPSIS
.br
.PP
.SS "Functions"

.in +1c
.ti -1c
.RI "int \fBcan_Command\fP (struct inode *inode, \fBCommand_par_t\fP *argp)"
.br
.ti -1c
.RI "int \fBcan_Send\fP (struct inode *inode, \fBcanmsg_t\fP *Tx)"
.br
.ti -1c
.RI "int \fBcan_Receive\fP (struct inode *inode, \fBcanmsg_t\fP *Rx)"
.br
.ti -1c
.RI "int \fBcan_GetStat\fP (struct inode *inode, \fBCanStatusPar_t\fP *s)"
.br
.ti -1c
.RI "int \fBcan_Config\fP (struct inode *inode, int target, unsigned long val1, unsigned long val2)"
.br
.ti -1c
.RI "int \fBcan_ioctl\fP (__LDDK_IOCTL_PARAM)"
.br
.RI "\fIint ioctl(int fd, int request, . \fP"
.in -1c
.SH "Detailed Description"
.PP 
\fBAuthor:\fP
.RS 4
Heinz-J黵gen Oertel, port GmbH 
.PP
\fBRevision\fP.RS 4
1.13 
.RE
.PP
\fBDate\fP.RS 4
2005/08/29 08:49:52 
.RE
.PP
.RE
.PP

.SH "Function Documentation"
.PP 
.SS "int can_ioctl (__LDDK_IOCTL_PARAM)"
.PP
int ioctl(int fd, int request, . 
.PP
..); the CAN controllers control interface 
.PP
\fBParameters:\fP
.RS 4
\fIfd\fP The descriptor to change properties 
.br
\fIrequest\fP special configuration request 
.br
\fI...\fP traditional a \fIchar\fP *argp
.RE
.PP
The \fIioctl\fP function manipulates the underlying device parameters of the CAN special device. In particular, many operating characteristics of character CAN driver may be controlled with \fIioctl\fP requests. The argument \fIfd\fP must be an open file descriptor.
.PP
An ioctl request has encoded in it whether the argument is an \fBin\fP parameter or \fBout\fP parameter, and the size of the argument argp in bytes. Macros and defines used in specifying an \fIioctl\fP request are located in the file \fBcan4linux.h\fP .
.PP
The following \fIrequests\fP are defined:
.PP
.PD 0
.IP "\(bu" 2
\fCCOMMAND\fP some commands for start, stop and reset the CAN controller chip 
.IP "\(bu" 2
\fCCONFIG\fP 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). 
.IP "\(bu" 2
\fCSTATUS\fP request the CAN controllers status 
.IP "\(bu" 2
\fCSEND\fP a single message over the \fIioctl\fP interface 
.IP "\(bu" 2
\fCRECEIVE\fP poll a receive message 
.IP "\(bu" 2
\fCCONFIGURERTR\fP configure automatic rtr responses(not implemented)
.PP
The third argument is a parameter structure depending on the request. These are 
.PP
.nf
struct Command_par
struct Config_par
struct CanStatusPar
struct ConfigureRTR_par
struct Receive_par
struct Send_par

.fi
.PP
 described in \fBcan4linux.h\fP
.PP
\fBBit Timing\fP.RS 4
The bit timing can be set using the \fIioctl\fP(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 \fBval1\fP (BTR0) and \fBval2\fP (BTR1).
.RE
.PP
\fBAcceptance Filtering\fP.RS 4

.RE
.PP
\fBBasic\fP \fBCAN\fP. 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
.PP
\fB\fP.RS 4
\fBPeliCAN\fP. For acceptance filtering the entries \fCAccCode\fP and \fCAccMask\fP are used like specified in the controllers manual for \fBSingle\fP \fBFilter\fP \fBConfiguration\fP . 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 \fBSingle\fP \fBFilter\fP \\ Mode .
.RE
.PP
Example for extended message format 
.PP
.nf
       Bits
 mask  31 30 .....           4  3  2  1  0
 code
 -------------------------------------------
 ID    28 27 .....           1  0  R  +--+-> unused
                                   T
                                   R

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

.fi
.PP
.PP
Example for base message format 
.PP
.nf
       Bits
 mask  31 30 .....           23 22 21 20 ... 0
 code
 -------------------------------------------
 ID    11 10 .....           1  0  R  +--+-> unused
                                   T
                                   R

.fi
.PP
.PP
You have to shift the CAN-ID by 5 bits and two bytes to shift them into ACR0 and ACR1 (acceptance code register) 
.PP
.nf
  acccode =  (id << 21) + (rtr << 20) 

.fi
.PP
 In case of the base format match the content of bits 0...20 is of no interest, it can be 0x00000 or 0xFFFFF. 
.PP
\fBReturns:\fP
.RS 4
On success, zero is returned. On error, -1 is returned, and errno is set appropriately.
.RE
.PP
\fBExample\fP.RS 4

.PP
.nf
Config_par_t  cfg;
volatile Command_par_t cmd;


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

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

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

.fi
.PP
.RE
.PP

.SH "Author"
.PP 
Generated automatically by Doxygen for can4linux from the source code.