CAN-BCM periodic send signaling

CAN-BCM periodic send signaling

[Boris Baskevitch]

Hello,
Happy new year everybody !
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 ? Is there a call-back that I could setup to increment my counter each time the BCM is sending my message ?

Thanks for your help !

Boris

Re: CAN-BCM periodic send signaling

[Oliver Hartkopp]

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

RE: CAN-BCM periodic send signaling

[Boris Baskevitch]

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

Re: CAN-BCM periodic send signaling

[Oliver Hartkopp]

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
> 
> 

Re: CAN-BCM periodic send signaling

[Oliver Hartkopp]

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
> 

RE: CAN-BCM periodic send signaling

[Boris Baskevitch]

Hi Oliver,

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

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
> >

Re: CAN-BCM periodic send signaling

[Oliver Hartkopp]

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
>>>
> 

RE: CAN-BCM periodic send signaling

[Boris Baskevitch]

" preserve this struct for later use"
That's great !
Why didn't I think about it before ?!

Thank you Oliver.

Boris


> -----Message d'origine-----
> De : linux-can-owner@vger.kernel.org [mailto:linux-can-
> owner@vger.kernel.org] De la part de Oliver Hartkopp
> Envoyé : mardi 7 janvier 2014 14:37
> À : Boris Baskevitch
> Cc : linux-can@vger.kernel.org
> Objet : Re: CAN-BCM periodic send signaling
> 
> 
> 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
> >>>
> >
> --
> 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