Re: CAN-BCM periodic send signaling

[Oliver Hartkopp <socketcan@hartkopp.net>]

On 07.01.2014 13:52, Boris Baskevitch wrote:

> You're right, the frame counter is not incremented but it is reset.
> In my case this results to showing only frame[0] of the bus as the payload
> is updated more frequently than the message period.
> I changed my updating function to let it change the 16 frames of the
> message, but it's still not working:
> I see no way to update a message frame without touching one byte (the last
> one in my case) of the frame (to keep the frame counter untouched).
> Reading the bcm.c source code, it uses the following memcopy command which
> overwrite the whole frame.
> http://lxr.free-electrons.com/source/net/can/bcm.c#L861
> 

Yes it does.

Create a struct like this:

struct {
	struct bcm_msg_head msg_head;
	struct can_frame frame[16];
} msg;

Set the can_id, can_dlc in all 16 frames to the same values.
Set the counter in the last byte according to your wanted sequence.

Don't know if this is your correct use-case:
Put identical content in data[0..6] of all 16 CAN frames.

send TX_SETUP with this struct (and preserve this struct for later use).

On changes:
Put identical content in data[0..6] of all 16 CAN frames.
send TX_SETUP (without timer restart) with this struct.

This does not harm your counter value nor the sequence nor the timers.

Regards,
Oliver


> Boris
> 
> 
>> -----Message d'origine-----
>> De : Oliver Hartkopp [mailto:socketcan@hartkopp.net]
>> Envoyé : mardi 7 janvier 2014 13:19
>> À : Boris Baskevitch
>> Cc : linux-can@vger.kernel.org
>> Objet : Re: CAN-BCM periodic send signaling
>>
>>
>>
>> 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
>>>
>