.TH "can_ioctl.c" 3 "14 Sep 2001" "can4linux" \" -*- nroff -*-.ad l.nh.SH NAMEcan_ioctl.c \-  .SH SYNOPSIS.br.PP.SS Functions.in +1c.ti -1c.RI "int \fBcan_Command\fR (struct inode *inode, int cmd)".br.ti -1c.RI "int \fBcan_Send\fR (struct inode *inode, \fBcanmsg_t\fR *Tx)".br.ti -1c.RI "int \fBcan_Receive\fR (struct inode *inode, \fBcanmsg_t\fR *Rx)".br.ti -1c.RI "int \fBcan_GetStat\fR (struct inode *inode, \fBCanSja1000Status_par_t\fR *s)".br.ti -1c.RI "int \fBcan_Config\fR (struct inode *inode, int target, unsigned long val1, unsigned long val2)".br.ti -1c.RI "int \fBcan_ioctl\fR (__LDDK_IOCTL_PARAM)".br.RI "\fIint ioctl(int fd, int request, ...); the CAN controllers control interface.\fR".in -1c.SH DETAILED DESCRIPTION.PP  .PP\fBAuthor(s): \fR.in +1cHeinz-J黵gen Oertel, port GmbH .PP\fBRevision: \fR.in +1c 1.2  .PP\fBDate: \fR.in +1c 2001/09/04 15:51:44 .PP.SH FUNCTION DOCUMENTATION.PP .SS int can_ioctl (__LDDK_IOCTL_PARAM).PPint ioctl(int fd, int request, ...); the CAN controllers control interface..PP\fBParameters: \fR.in +1c.TP\fB\fIfd\fR\fRThe descriptor to change properties .TP\fB\fIrequest\fR\fRspecial configuration request .TP\fB\fI...\fR\fRtraditional a \fIchar\fR *argp.PPThe \fIioctl\fR 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\fR requests. The argument \fIfd\fR must be an open file descriptor..PPAn ioctl request has encoded in it whether the argument is an \fBin\fR parameter or \fBout\fR parameter, and the size of the argument argp in bytes. Macros and defines used in specifying an \fIioctl\fR request are located in the file \fBcan.h\fR ..PPThe following \fIrequests\fR are defined:.PP.TP \fCCOMMAND\fR some commands for start, stop and reset the CAN controller chip .TP \fCCONFIG\fR 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). .TP \fCSTATUS\fR request the CAN controllers status .TP \fCSEND\fR a single message over the \fIioctl\fR interface  .TP \fCRECEIVE\fR poll a receive message .TP \fCCONFIGURERTR\fR configure automatic rtr responses(not implemented)The third argument is a parameter structure depending on the request. These are .PP.nfstruct Command_parstruct Config_parstruct CanSja1000Status_parstruct ConfigureRTR_parstruct Receive_parstruct Send_par.fi described in \fBcan.h\fR.PP\fBAcceptance Filtering\fR.in +1c\fBBasic\fR \fBCAN\fR. 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\fBPeliCAN\fR. For acceptance filtering the entries \fCAccCode\fR and \fCAccMask\fR are used like specified in the controllers manual for \fBSingle\fR \fBFilter\fR \fBConfiguration\fR . 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\fR \fBFilter\fR \\ Mode . .PP.nf       Bits mask  31 30 .....           4  3  2  1  0 code ------------------------------------------- ID    28 27 .....           1  0  R  +--+-> unused                                   T                                   R.fi.PP\fBReturns: \fR.in +1cOn success, zero is returned. On error, -1 is returned, and errno is set appropriately..PP\fBExample\fR.in +1c.PP.nfConfig_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 .SH AUTHOR.PP Generated automatically by Doxygen for can4linux from the source code.