Re: CAN-BCM periodic send signaling

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 07.01.2014 10:47, Oliver Hartkopp wrote:
> 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

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

> 
> 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
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>