On 17.10.2010 19:39, Daniele Venzano wrote:
> The following patch fills the BCM chapter of can.txt with some
> intro text, a description of the opcodes and flags and the TX_DELETE
> command (because it was easy).
> The patch is against latest SVN.
>
> Are all opcodes and flags are still there with the documented behaviour ?
Yes. Mostly. E.g. the operation on several CAN busses has been made possible
in SVN Revision 138:
------------------------------------------------------------------------
r138 | hartkopp | 2007-02-01 10:15:00 +0100 (Do, 01. Feb 2007) | 11 Zeilen
Complete reworked and beautified the Broadcast Manager (bcm)
The BCM now supports the binding to ifindex 0 like the raw socket does.
The first implementation of the BCM was from September 2003 and therefore
many historic stuff (e.g. unusual error reporting) was removed.
The support of ifindex 0 leads to the possibility to read from several
interfaces via one BCM-socket using sendto() / recvfrom().
See new test-apps tst-bcm-?x-sendto.c
The update of RX/TX_SETUPs 'on the run' are only possible with a smaller or
eval size of parameters now, as it is very complex in locking to provide the
other case and there was really now use-case for it ...
------------------------------------------------------------------------
The max. number of nframes has been limited to 256 and some structures exposed
to the userpace (struct bcm_msg_head) has been sanitized.
I will fix all this based on your initial patch the next days.
Many thanks!
Oliver
>
> Thanks.
>
>
> Index: kernel/2.6/Documentation/networking/can.txt
> ===================================================================
> --- kernel/2.6/Documentation/networking/can.txt (revision 1198)
> +++ kernel/2.6/Documentation/networking/can.txt (working copy)
> @@ -23,6 +23,15 @@
> 4.1.3 RAW socket option CAN_RAW_LOOPBACK
> 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
> 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
> + 4.2.1 Opening BCM sockets
> + 4.2.2 BCM messages (struct bcm_msg_head)
> + 4.2.3 TX_SETUP opcode
> + 4.2.4 TX_DELETE opcode
> + 4.2.5 TX_READ opcode
> + 4.2.6 TX_SEND opcode
> + 4.2.7 RX_SETUP opcode
> + 4.2.8 RX_DELETE opcode
> + 4.2.9 RX_READ opcode
> 4.3 connected transport protocols (SOCK_SEQPACKET)
> 4.4 unconnected transport protocols (SOCK_DGRAM)
> 4.5 Timestamps
> @@ -473,6 +482,159 @@
> &recv_own_msgs, sizeof(recv_own_msgs));
>
> 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
> +
> + The Broadcast Manager (BCM) provides functions to send CAN frames
> + once or periodically, as well as notify applications of changes in
> + received CAN frames, recognizing specific CAN IDs.
> +
> + Capabilities on the trasmission side:
> + - Cyclic transmission of a CAN frame with a given interval
> + - Modification of message content and intervals at runtime (e.g.
> + switching to a new interval with or without immediate restart of
> + the timer)
> + - Automatically switching to a second interval after a certain number
> + of frames has been sent
> + - Instant transmission of changed frames, without influencing the
> + interval cycle
> + - One-time transmission of CAN messages
> +
> + Capabilities on the receiving side:
> + - Receive filter to detect changes in frame ID, data or length (DLC)
> + - Receive filter for multiplex frames (e.g. with packet counters in
> + the data field)
> + - RTR replies to messages
> + - Time-out monitoring of frames
> + - Frequency reduction of messages (throttle function) to the user
> + application
> +
> + 4.2.1 Opening BCM sockets
> +
> + To use Broadcast-Manager include the file "bcm.h".
> + A socket for Broadcast-Manager is created with:
> +
> + s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
> +
> + The CAN interface is assigned with a call to connect() on the socket.
> +
> + addr.can_family = AF_CAN;
> + strcpy(ifr.ifr_name, "can0");
> + ioctl(s, SIOCGIFINDEX, &ifr);
> + addr.can_ifindex = ifr.ifr_ifindex;
> +
> + connect(s, (struct sockaddr *)&addr, sizeof(addr));
> +
> + If a process must operate on multiple CAN buses, it must open several
> + sockets. It is also possible for a process to open multiple sockets
> + on a single CAN-bus, if it makes sense for the application programmer
> + to structure different data flows.
> + Every single instance of Broadcast-Manager is able to manage any number of
> + filter and/or send requests.
> +
> + 4.2.2 BCM messages (struct bcm_msg_head)
> +
> + All messages from the (user) process to Broadcast-Manager have the same
> + structure. It consists of a message header with the command (opcode),
> + several options and zero or more CAN frames, depending on the command
> + used and the action requested:
> +
> + struct bcm_msg_head {
> + int opcode; /* command */
> + int flags; /* special flags */
> + int count; /* run 'count' times ival1 then ival2
> */
> + struct timeval ival1, ival2; /* intervals */
> + canid_t can_id; /* 32 Bit SFF/EFF. MSB set at EFF */
> + int nframes; /* number of can_frame's in the next
> field */
> + struct can_frame frames[0];
> + };
> +
> + The value of nframes indicates how many user data frames follow the
> + message header. The user data frames are used to describe the actual
> + content of a CAN message:
> +
> + struct can_frame {
> + canid_t can_id; /* 32 bit CAN_ID + EFF/RTR flags */
> + __u8 can_dlc; /* data length code: 0 .. 8 */
> + __u8 data[8] __attribute__ ((aligned(8)));
> + };
> +
> + The opcode defines the type of message. Messages from the user to
> + BCM control the operations of the BCM, replies from the BCM indicate
> + certain changes to the user, such as timeouts, etc.
> +
> + The transmit and receive path of the BCM are two independent functional
> + blocks.
> +
> + For the transmit path the following opcodes exist:
> +
> + TX_SETUP: for setting up and modifying transmission requests
> + TX_DELETE: to remove send requests
> + TX_READ: to read out the current broadcasting commands
> + (for debugging purposes)
> + TX_SEND: for sending a single CAN message
> +
> + For the receive path the following opcodes exist:
> +
> + RX_SETUP: for setting and modifying receive filters
> + RX_DELETE: for deleting receive filters
> + RX_READ: to read out the current receive filter (for debugging purposes)
> +
> + The Broadcast-Manager sends response messages in the same form. The
> + BCM sends these opcodes:
> +
> + TX_STATUS: in response to TX_READ
> + TX_EXPIRED: is sent when the counter count reaches ival1 (only if
> + flag TX_COUNTEVT is set, see below)
> +
> + RX_STATUS: in response to RX_READ
> + RX_TIMEOUT: sent if the time-controlled reception of a message failed
> + RX_CHANGED: sent if the first or a revised CAN message was received
> +
> + Each of these opcode needs CAN ID specified either in the "can_id" field or
> + in the first can_frame structure attached to the command.
> +
> + In addition, there are optional flags which can influence the BCM behavior:
> +
> + SETTIMER: set the value of ival1, ival2 and count
> + STARTTIMER: start the timer with the actual value of ival1, ival2 and
> count.
> + Starting the timer leads simultaneously to the transmission of a
> can_frame
> + TX_COUNTEVT: create the message TX_EXPIRED when count is reached
> + TX_ANNOUNCE: a change of data by the process is emitted with a new frame,
> + regardless of the timer status
> + TX_CP_CAN_ID: copies the can_id from the message header attached to each
> + of can_frame. This is intended only as usage simplification
> + TX_RESET_MULTI_IDX: forces a reset of the index counter from the update
> + to be sent by multiplex message even if it would not be necessary
> + because of the length
> + RX_FILTER_ID: there is no filtering of the user data. A match with the
> + received message can_id automatically leads to a RX_CHANGED. Use
> + caution in cyclic messages. If RX_FILTER_ID flag is set, the CAN
> frame
> + in RX_SETUP can be ignored (i.e., nframes = 0)
> + RX_RTR_FRAME: the filter passed is used as CAN message to be sent when
> + receiving an RTR frame
> + RX_CHECK_DLC: a change of the DLC leads to an RX_CHANGED message to the
> user
> + application
> + RX_NO_AUTOTIMER: if the timer ival1 in the RX_SETUP has been set equal to
> + zero, on receipt of the CAN message the timer for the timeout
> + monitoring is automatically started. Setting this flag prevents the
> + automatic reset of the start timer
> + RX_ANNOUNCE_RESUME: refers also to the time-out supervision of RX_SETUP.
> By
> + setting this flag, when an RX-outs occours, a RX_CHANGED will be
> + generated when the (cyclic) receive restarts. This will happen even
> + if the user data have not changed
> +
> + 4.2.3 TX_SETUP opcode
> + 4.2.4 TX_DELETE opcode
> +
> + This opcode will delete the entry for transmission of the CAN frame with
> + the specified can_id CAN identifier. The message length for the command
> + TX_DELETE is sizeof(bcm_msg_head) (only the header).
> +
> + 4.2.5 TX_READ opcode
> + 4.2.6 TX_SEND opcode
> + 4.2.7 RX_SETUP opcode
> + 4.2.8 RX_DELETE opcode
> + 4.2.9 RX_READ opcode
> +
> 4.3 connected transport protocols (SOCK_SEQPACKET)
> 4.4 unconnected transport protocols (SOCK_DGRAM)
>
>
_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users
