Re: CAN-BCM periodic send signaling

[Oliver Hartkopp <socketcan@hartkopp.net>]

Hi Boris,

when you update the tx job please make sure that the nframes remains 16 and
the entire message to the BCM contains 16 CAN frames.

In your example below you switch back to a tx job with one single CAN frame
(== no sequence of 16 frames).

Updating a BCM tx job content is just about copying the CAN frame contents:
http://lxr.free-electrons.com/source/net/can/bcm.c#L847

When you send only one frame in the updated tx job only this frame is copied
and the new nframes (==1) is taken for the job. Bye bye message sequence :-)

http://lxr.free-electrons.com/source/net/can/bcm.c#L847

Regards,
Oliver

On 07.01.2014 09:29, Boris Baskevitch wrote:
> Hi Oliver,
> Thanks for the reply, the counter works well this way.
> But I also need to update the message with real payload in the other bytes of the message.
> I placed the counter in the last byte of the message, I setup the periodic message as you described (I extended it to a 4-bit counter, using 16 frames).
> Then I use the following function to update the payload without touching the frame counter.
> This function if called much more frequently than the message period, I don’t use TX_ANNOUNCE in it to make sure the message period is stable on the bus.
> Unfortunately, doing this way is corrupting the frame counter: it seems that calling the update function is incrementing the frame pointer of the message.
> Note that when I update the payload, I update only msg.frame[0] and not the 15 other frames of the message, but on the bus, I can see that all the frames are updated with my payload. That's why I think the frame pointer is updated each time I call the update function.
> Is there a way to update the payload without touching the frame pointer ?
> 
> void UpdatePeriodicSendValues(void)
> {
>      struct {
> 	struct bcm_msg_head msg_head;
> 	struct can_frame frame[1];
>      } msg;
>     
>     msg.msg_head.opcode = TX_SETUP;
>     msg.msg_head.flags = TX_CP_CAN_ID;
>     msg.msg_head.count = 0;
>     msg.msg_head.can_id = 0x42;
>     msg.msg_head.nframes = 1;
>     msg.frame[0].can_dlc = 8;
> 
>     msg.frame[0].data[0] = MyData1 ;
>     msg.frame[0].data[1] = MyData2;
>     msg.frame[0].data[2] = 0;
>     msg.frame[0].data[3] = 0;
>     msg.frame[0].data[4] = 0;
>     msg.frame[0].data[5] = 0;
>     msg.frame[0].data[6] = 0;
>     //msg.frame[0].data[7] = this is the frame counter, don't touch it !
> 
>     write(m_fd, &msg, sizeof(msg));
> 
>     return;
> }
> 
> 
> 
> Boris
> 
> 
> 
>> -----Message d'origine-----
>> De : Oliver Hartkopp [mailto:socketcan@hartkopp.net]
>> Envoyé : lundi 6 janvier 2014 19:09
>> À : Boris Baskevitch
>> Cc : linux-can@vger.kernel.org
>> Objet : Re: CAN-BCM periodic send signaling
>>
>> Hey Boris,
>>
>> On 06.01.2014 18:11, Boris Baskevitch wrote:
>>
>>> I'm using the CAN-BCM to send periodic CAN messages on the bus.
>>> In one of those messages, I need to send a counter value which is
>> incremented each time the message is sent.
>>> How can I do that ?
>>
>> E.g. if you have a 4 bit counter, you just send 16 "struct can_frames" at
>> TX_SETUP time - also set nframes to 16 then.
>>
>> When nframes > 1 a sequence of CAN frames is sent automatically.
>> You may alter these CAN frames at runtime.
>> If you do so, the tx index may be set to "0" (start) with TX_RESET_MULTI_IDX.
>>
>> See tst-bcm-cycle.c from the git://gitorious.org/linux-can/can-tests.git
>>
>> Here's the patch to demonstrate it based on can-tests repository with
>> nframes=4:
>>
>> diff --git a/tst-bcm-cycle.c b/tst-bcm-cycle.c
>> index b85ceed..adb2fd6 100644
>> --- a/tst-bcm-cycle.c
>> +++ b/tst-bcm-cycle.c
>> @@ -89,16 +89,29 @@ int main(int argc, char **argv)
>>
>>  	msg.msg_head.opcode  = TX_SETUP;
>>  	msg.msg_head.can_id  = 0x42;
>> -	msg.msg_head.flags   = SETTIMER|STARTTIMER;
>> -	msg.msg_head.nframes = 1;
>> -	msg.msg_head.count = 10;
>> -	msg.msg_head.ival1.tv_sec = 1;
>> +	msg.msg_head.flags   = SETTIMER|STARTTIMER|TX_CP_CAN_ID;
>> +	msg.msg_head.nframes = 4;
>> +	msg.msg_head.count = 0;
>> +	msg.msg_head.ival1.tv_sec = 0;
>>  	msg.msg_head.ival1.tv_usec = 0;
>>  	msg.msg_head.ival2.tv_sec = 0;
>> -	msg.msg_head.ival2.tv_usec = 0;
>> -	msg.frame[0].can_id    = 0x42;
>> +	msg.msg_head.ival2.tv_usec = 200000;
>> +
>> +	//msg.frame[0].can_id    = 0x42; /* obsolete due to TX_CP_CAN_ID */
>>  	msg.frame[0].can_dlc   = 8;
>> -	U64_DATA(&msg.frame[0]) = (__u64) 0xdeadbeefdeadbeefULL;
>> +	U64_DATA(&msg.frame[0]) = (__u64) 0x01000000deadbeefULL;
>> +
>> +	//msg.frame[1].can_id    = 0x42; /* obsolete due to TX_CP_CAN_ID */
>> +	msg.frame[1].can_dlc   = 8;
>> +	U64_DATA(&msg.frame[1]) = (__u64) 0x02000000deadbeefULL;
>> +
>> +	//msg.frame[2].can_id    = 0x42; /* obsolete due to TX_CP_CAN_ID */
>> +	msg.frame[2].can_dlc   = 8;
>> +	U64_DATA(&msg.frame[2]) = (__u64) 0x03000000deadbeefULL;
>> +
>> +	//msg.frame[3].can_id    = 0x42; /* obsolete due to TX_CP_CAN_ID */
>> +	msg.frame[3].can_dlc   = 8;
>> +	U64_DATA(&msg.frame[3]) = (__u64) 0x04000000deadbeefULL;
>>
>>  	if (write(s, &msg, sizeof(msg)) < 0)
>>  		perror("write");
>>
>> Does this fit your needs?
>>
>> Regards,
>> Oliver
> 
>