Hi all,

I just bluntly jump in and capture this posting for the original issue
behind it. :->

Oliver Hartkopp wrote:
> Hello Wolfgang,
> indeed you are right with all your examples.
> To get more practice i would suggest to check out the possibilities by 
> using the tools 'cangen', 'cansend' and 'candump'.
> E.g. these are /your/ examples on the virtual CAN interface vcan0:
>> The following filter will select all messages, extended and standard 
>> messages:
>>   rfilter[0].can_id   = 0x0;
>>   rfilter[0].can_mask = 0x0;
> candump vcan0
> or
> candump -m 0 -v 0 vcan0
> /* mask = value = 0 is the default */
>> The following filter will select only extended messages:
>>   rfilter[0].can_id   = CAN_EFF_FLAG;
>>   rfilter[0].can_mask = CAN_EFF_FLAG;
> candump -m 0x80000000 -v 0x80000000 vcan0
>> The following filter will select only standard messages:
>>   rfilter[0].can_id   = CAN_EFF_FLAG | CAN_INV_FILTER;
>>   rfilter[0].can_mask = CAN_EFF_FLAG;
> candump -m 0x80000000 -v 0x80000000 -i 1 vcan0

...and I guess this would work as well:

candump -m 0x80000000 -v 0x00000000 vcan0

>> And RTR-Messages could be filtered in a similar way. Is this correct?
> Yes. E.g.
> candump -m 0x40000000 -v 0x40000000 vcan0

Makes perfect sense, it's considering EFF and RTR as yet some more bits
of the CAN ID. That's what I actually tried to apply yesterday under
Xenomai and wondered why it didn't work. :o)

So, to align RT-Socket-CAN with plain Socket-CAN again, we (Xenomai) should

a) include EFF and RTS transparently into mask building and ID
b) add support for inverse masks

Wolfgang, as we currently have some "exception" specified in the CAN
profile, I would just fix the code in this regard (for 2.3.1). The two
changes above should be queued for Xenomai 2.4 together with a profile
and revision number update - to avoid breakage inside the stable series.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to