.TH "ioctl.c" 3 "8 Feb 2007" "can4linux" \" -*- nroff -*-.ad l.nh.SH NAMEioctl.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 4Heinz-J黵gen Oertel, port GmbH .PP\fBRevision\fP.RS 41.2 .RE.PP\fBDate\fP.RS 42006/09/08 09:47:37 .RE.PP.RE.PP.SH "Function Documentation".PP .SS "int can_ioctl (__LDDK_IOCTL_PARAM)".PPint 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.PPThe \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..PPAn 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 ..PPThe following \fIrequests\fP are defined:.PP.PD 0.IP "\(bu" 2\fCCAN_IOCTL_COMMAND\fP some commands for start, stop and reset the CAN controller chip .IP "\(bu" 2\fCCAN_IOCTL_CONFIG\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\fCCAN_IOCTL_STATUS\fP request the CAN controllers status .IP "\(bu" 2\fCCAN_IOCTL_SEND\fP a single message over the \fIioctl\fP interface .IP "\(bu" 2\fCCAN_IOCTL_RECEIVE\fP poll a receive message .IP "\(bu" 2\fCCAN_IOCTL_CONFIGURERTR\fP configure automatic rtr responses(not implemented).PPThe third argument is a parameter structure depending on the request. These are .PP.nfstruct Command_parstruct Config_parstruct CanStatusParstruct ConfigureRTR_parstruct Receive_parstruct Send_par.fi.PP described in \fBcan4linux.h\fP.PP\fBBit Timing\fP.RS 4The 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.PPExample 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.PPExample 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.PPYou 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 4On success, zero is returned. On error, -1 is returned, and errno is set appropriately..RE.PP\fBExample\fP.RS 4.PP.nfConfig_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);.fi.PP.RE.PP\fBSetting the bit timng register\fP.RS 4.RE.PPcan4linux provides direct access to the bit timing registers, besides an implicite setting using the \fIioctl\fP \fCCONF_TIMING\fP and fixed values in Kbit/s. In this case ioctl(can_fd, CAN_IOCTL_CONFIG, &cfg); is used with configuration target \fCCONF_BTR\fP The configuration structure contains two values, \fIval1\fP and \fIval2\fP . The following relation to the bit timing registers is used regarding the CAN controller:.PP.PP.nf                           val1            val2SJA1000                    BTR0            BTR1BlackFin                   CAN_CLOCK       CAN_TIMINGFlexCAN (to implement) .fi.PP.PP\fB\fP.RS 4Bit 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!)).RE.PP\fBOther CAN_IOCTL_CONFIG configuration targets\fP.RS 4.RE.PP(see \fBcan4linux.h\fP) .PP.nfCONF_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 directly registersCONF_TIMESTAMP          if set fill time stamp value in message structure                        (default true)CONF_WAKEUP             if set wake up waiting processes (default true) .fi.PP .SH "Author".PP Generated automatically by Doxygen for can4linux from the source code.