[Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

status:

I have Steve Batazzo's driver running on the beaglebone, using a stock
Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
from http://repos.rcn-ee.net/debian/), current driver out of tree at
https://github.com/mhaberler/rtcan-bb branch mah

I also have a preliminary HAL driver for machinekit which talks to a
Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get a
CAN PCI card).

I'm working with Steve to get the driver polished and hope we can inject it
into the Xenomai foodchain eventually, after which it will be eventually
picked up by Robert's periodic builds, and the whole thing becomes an
'apt-get install' - affair. But we're not there yet.


I have a few questions on RT-CAN (I guess really RTDM):

- can the RTDM API (
https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
used from a normal Posix thread (non-RT) just alike? from the rtcansend*
utilities src it looks like at least for setup, even if the send/receive
ops are done in an RT thread.

- socket-CAN and RT-CAN interworking: I assume this is an either-or affair,
right? (background: for some jobs the RT-CAN features are overkill, and in
that case something like the python-can binding would be convenient to use)

- in case the above answers are 'yes' and 'no, it's either/or': anybody
aware of Python bindings for RTDM?

sorry for the noobish questions, climbing the learning curve

- Michael

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Steve B]

On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler <haberlerm@gmail.com>
wrote:

> status:
>
> I have Steve Batazzo's driver running on the beaglebone, using a stock
> Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
> from http://repos.rcn-ee.net/debian/), current driver out of tree at
> https://github.com/mhaberler/rtcan-bb branch mah
>
> I also have a preliminary HAL driver for machinekit which talks to a
> Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get a
> CAN PCI card).
>
> I'm working with Steve to get the driver polished and hope we can inject it
> into the Xenomai foodchain eventually, after which it will be eventually
> picked up by Robert's periodic builds, and the whole thing becomes an
> 'apt-get install' - affair. But we're not there yet.
>
>
> I have a few questions on RT-CAN (I guess really RTDM):
>
> - can the RTDM API (
> https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
> used from a normal Posix thread (non-RT) just alike? from the rtcansend*
> utilities src it looks like at least for setup, even if the send/receive
> ops are done in an RT thread.
>
> - socket-CAN and RT-CAN interworking: I assume this is an either-or affair,
> right? (background: for some jobs the RT-CAN features are overkill, and in
> that case something like the python-can binding would be convenient to use)
>
> - in case the above answers are 'yes' and 'no, it's either/or': anybody
> aware of Python bindings for RTDM?
>
> sorry for the noobish questions, climbing the learning curve
>
> - Michael
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

I am thinking that if the RTDM version of the driver is overkill for what
you are doing, then it may be best to just use the regular Linux driver.
As I understand it from a quick and simple question I recently asked of the
list, if you're using the RTDM driver then its interrupt will be among the
few things able to pre-empt your high priority Xenomai task (assuming you
have any running at the time). So if you really don't need the CAN bus to
be "rt-safe" then it may in some cases be better to have it set up with the
regular Linux driver so that the i-pipe doesn't prioritize it over your RT
tasks. That could also depend on how often you have frames coming in and
whether or not you have danger of overrunning the hardware receive buffer
if the interrupt service routine is neglected while your RT task is still
running.

It could a bit tricky, though (modifications to the driver source), if you
wanted one CAN bus to be non-RT and one to be RT.


With the RTDM driver, I'm not sure if it uses a Xenomai system call to open
the socket (but I suspect that it may). If that's the case, then you can
open it from either a primary or secondary mode Xenomai thread, but maybe
not a regular Linux thread (i.e. a totally non-Xenomai application or a
thread opened with __real_pthread_create).

Unfortunately I don't have an answer on the Python bindings, but I can see
how that would be attractive since it's a lot easier to get up and running
than having to compile a C program. But since python is interpreted I think
you might have to be very careful if you intend to use it for a real-time
task with some strict deadlines. I suspect that it could mostly be OK
beyond initial setup of your program?
The RT socket CAN stuff in C code looks extremely similar to regular old
socket CAN, so if there exists already a socket CAN binding for python, I
suspect you could re-use it with only small modifications (including the
RTDM headers, making sure you have the right device name when you open your
socket, and replacing read/write calls with send/recv and the appropriate
argument lists).

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

2015-03-19 19:44 GMT+01:00 Steve B <sbattazzo@gmail.com>:

>
>
> On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler <haberlerm@gmail.com>
> wrote:
>
>> status:
>>
>> I have Steve Batazzo's driver running on the beaglebone, using a stock
>> Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
>> from http://repos.rcn-ee.net/debian/), current driver out of tree at
>> https://github.com/mhaberler/rtcan-bb branch mah
>>
>> I also have a preliminary HAL driver for machinekit which talks to a
>> Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get a
>> CAN PCI card).
>>
>> I'm working with Steve to get the driver polished and hope we can inject
>> it
>> into the Xenomai foodchain eventually, after which it will be eventually
>> picked up by Robert's periodic builds, and the whole thing becomes an
>> 'apt-get install' - affair. But we're not there yet.
>>
>>
>> I have a few questions on RT-CAN (I guess really RTDM):
>>
>> - can the RTDM API (
>> https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
>> used from a normal Posix thread (non-RT) just alike? from the rtcansend*
>> utilities src it looks like at least for setup, even if the send/receive
>> ops are done in an RT thread.
>>
>> - socket-CAN and RT-CAN interworking: I assume this is an either-or
>> affair,
>> right? (background: for some jobs the RT-CAN features are overkill, and in
>> that case something like the python-can binding would be convenient to
>> use)
>>
>> - in case the above answers are 'yes' and 'no, it's either/or': anybody
>> aware of Python bindings for RTDM?
>>
>> sorry for the noobish questions, climbing the learning curve
>>
>> - Michael
>> _______________________________________________
>> Xenomai mailing list
>> Xenomai@xenomai.org
>> http://www.xenomai.org/mailman/listinfo/xenomai
>>
>
> I am thinking that if the RTDM version of the driver is overkill for what
> you are doing, then it may be best to just use the regular Linux driver.
>

certainly no point in using RT-CAN for say wiggling a led or querying a
slow sensor. But if the API could be used from non-Xenomai threads as well,
then I do not have to force the decision for either-or setup ahead of time.

the specific application where socket-CAN is not an option would run as
part of a motion control loop with intelligent motor drives, which is
timing-critical for position feedback and stall detection. This is similar
to other interface types already in use in this setting, like Ethernet, so
just another modality. As for contention, I would probably not mix traffic
types on a bus.


CAN aside, part of the exercise is to learn how to modify drivers to RTDM:
for instance, we would gain big time from a SPI RTDM driver on certain
platforms (actually I would appreciate any pointers to references how to
approach that problem).


> As I understand it from a quick and simple question I recently asked of
> the list, if you're using the RTDM driver then its interrupt will be among
> the few things able to pre-empt your high priority Xenomai task (assuming
> you have any running at the time). So if you really don't need the CAN bus
> to be "rt-safe" then it may in some cases be better to have it set up with
> the regular Linux driver so that the i-pipe doesn't prioritize it over your
> RT tasks. That could also depend on how often you have frames coming in and
> whether or not you have danger of overrunning the hardware receive buffer
> if the interrupt service routine is neglected while your RT task is still
> running.
>
> It could a bit tricky, though (modifications to the driver source), if you
> wanted one CAN bus to be non-RT and one to be RT.
>
>
> With the RTDM driver, I'm not sure if it uses a Xenomai system call to
> open the socket (but I suspect that it may). If that's the case, then you
> can open it from either a primary or secondary mode Xenomai thread, but
> maybe not a regular Linux thread (i.e. a totally non-Xenomai application or
> a thread opened with __real_pthread_create).
>

reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
(create socket, bind, ioctl etc) are done in a Linux thread. Only the read
and write ops are done in an RT thread. Just to check, I added a command
line option to do rt_dev_rec*/rt_dev_send* operations from a Linux thread,
and that seems to block.

The RTDM user API manual refers to Device Profiles, but it's unclear to me
if the answer really is "generally no", "generally yes", or "depends on
driver". Probably the latter, but I still have to understand the causal
chain.

>
> Unfortunately I don't have an answer on the Python bindings
>

If no answer comes up, but the RTDM API could be used from a normal Linux
thread, then what I would likely do is to extend the python-can bindings
for this interface type. Otherwise no point anyway I guess.

- Michael

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

2015-03-20 7:15 GMT+01:00 Michael Haberler <haberlerm@gmail.com>:

>
>
> 2015-03-19 19:44 GMT+01:00 Steve B <sbattazzo@gmail.com>:
>
>>
>>
>> On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler <haberlerm@gmail.com>
>> wrote:
>>
>>> status:
>>>
>>> I have Steve Batazzo's driver running on the beaglebone, using a stock
>>> Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
>>> from http://repos.rcn-ee.net/debian/), current driver out of tree at
>>> https://github.com/mhaberler/rtcan-bb branch mah
>>>
>>> I also have a preliminary HAL driver for machinekit which talks to a
>>> Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get
>>> a
>>> CAN PCI card).
>>>
>>> I'm working with Steve to get the driver polished and hope we can inject
>>> it
>>> into the Xenomai foodchain eventually, after which it will be eventually
>>> picked up by Robert's periodic builds, and the whole thing becomes an
>>> 'apt-get install' - affair. But we're not there yet.
>>>
>>>
>>> I have a few questions on RT-CAN (I guess really RTDM):
>>>
>>> - can the RTDM API (
>>> https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
>>> used from a normal Posix thread (non-RT) just alike? from the rtcansend*
>>> utilities src it looks like at least for setup, even if the send/receive
>>> ops are done in an RT thread.
>>>
>>> - socket-CAN and RT-CAN interworking: I assume this is an either-or
>>> affair,
>>> right? (background: for some jobs the RT-CAN features are overkill, and
>>> in
>>> that case something like the python-can binding would be convenient to
>>> use)
>>>
>>> - in case the above answers are 'yes' and 'no, it's either/or': anybody
>>> aware of Python bindings for RTDM?
>>>
>>> sorry for the noobish questions, climbing the learning curve
>>>
>>> - Michael
>>> _______________________________________________
>>> Xenomai mailing list
>>> Xenomai@xenomai.org
>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>
>>
>> I am thinking that if the RTDM version of the driver is overkill for what
>> you are doing, then it may be best to just use the regular Linux driver.
>>
>
> certainly no point in using RT-CAN for say wiggling a led or querying a
> slow sensor. But if the API could be used from non-Xenomai threads as well,
> then I do not have to force the decision for either-or setup ahead of time.
>
> the specific application where socket-CAN is not an option would run as
> part of a motion control loop with intelligent motor drives, which is
> timing-critical for position feedback and stall detection. This is similar
> to other interface types already in use in this setting, like Ethernet, so
> just another modality. As for contention, I would probably not mix traffic
> types on a bus.
>
>
> CAN aside, part of the exercise is to learn how to modify drivers to RTDM:
> for instance, we would gain big time from a SPI RTDM driver on certain
> platforms (actually I would appreciate any pointers to references how to
> approach that problem).
>
>
>> As I understand it from a quick and simple question I recently asked of
>> the list, if you're using the RTDM driver then its interrupt will be among
>> the few things able to pre-empt your high priority Xenomai task (assuming
>> you have any running at the time). So if you really don't need the CAN bus
>> to be "rt-safe" then it may in some cases be better to have it set up with
>> the regular Linux driver so that the i-pipe doesn't prioritize it over your
>> RT tasks. That could also depend on how often you have frames coming in and
>> whether or not you have danger of overrunning the hardware receive buffer
>> if the interrupt service routine is neglected while your RT task is still
>> running.
>>
>> It could a bit tricky, though (modifications to the driver source), if
>> you wanted one CAN bus to be non-RT and one to be RT.
>>
>>
>> With the RTDM driver, I'm not sure if it uses a Xenomai system call to
>> open the socket (but I suspect that it may). If that's the case, then you
>> can open it from either a primary or secondary mode Xenomai thread, but
>> maybe not a regular Linux thread (i.e. a totally non-Xenomai application or
>> a thread opened with __real_pthread_create).
>>
>
> reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
> (create socket, bind, ioctl etc) are done in a Linux thread. Only the read
> and write ops are done in an RT thread. Just to check, I added a command
> line option to do rt_dev_rec*/rt_dev_send* operations from a Linux thread,
> and that seems to block.
>

correction: in this case rt_dev_send fails with EPERM

This thread suggests it is not possible to call this function from a
non-Xenomai thread: http://sourceforge.net/p/rtnet/mailman/message/19223387/

someody else tried the same thing before, looks like he did not get an
answer: http://www.xenomai.org/pipermail/xenomai/2012-April/025744.html


> The RTDM user API manual refers to Device Profiles, but it's unclear to me
> if the answer really is "generally no", "generally yes", or "depends on
> driver". Probably the latter, but I still have to understand the causal
> chain.
>
>>
>> Unfortunately I don't have an answer on the Python bindings
>>
>
> If no answer comes up, but the RTDM API could be used from a normal Linux
> thread, then what I would likely do is to extend the python-can bindings
> for this interface type. Otherwise no point anyway I guess.
>
> - Michael
>

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

2015-03-20 7:58 GMT+01:00 Michael Haberler <haberlerm@gmail.com>:

>
>
> 2015-03-20 7:15 GMT+01:00 Michael Haberler <haberlerm@gmail.com>:
>
>>
>>
>> 2015-03-19 19:44 GMT+01:00 Steve B <sbattazzo@gmail.com>:
>>
>>>
>>>
>>> On Thu, Mar 19, 2015 at 2:57 AM, Michael Haberler <haberlerm@gmail.com>
>>> wrote:
>>>
>>>> status:
>>>>
>>>> I have Steve Batazzo's driver running on the beaglebone, using a stock
>>>> Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
>>>> from http://repos.rcn-ee.net/debian/), current driver out of tree at
>>>> https://github.com/mhaberler/rtcan-bb branch mah
>>>>
>>>> I also have a preliminary HAL driver for machinekit which talks to a
>>>> Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I
>>>> get a
>>>> CAN PCI card).
>>>>
>>>> I'm working with Steve to get the driver polished and hope we can
>>>> inject it
>>>> into the Xenomai foodchain eventually, after which it will be eventually
>>>> picked up by Robert's periodic builds, and the whole thing becomes an
>>>> 'apt-get install' - affair. But we're not there yet.
>>>>
>>>>
>>>> I have a few questions on RT-CAN (I guess really RTDM):
>>>>
>>>> - can the RTDM API (
>>>> https://xenomai.org/documentation/trunk/html/api/group__userapi.html)
>>>> be
>>>> used from a normal Posix thread (non-RT) just alike? from the rtcansend*
>>>> utilities src it looks like at least for setup, even if the send/receive
>>>> ops are done in an RT thread.
>>>>
>>>> - socket-CAN and RT-CAN interworking: I assume this is an either-or
>>>> affair,
>>>> right? (background: for some jobs the RT-CAN features are overkill, and
>>>> in
>>>> that case something like the python-can binding would be convenient to
>>>> use)
>>>>
>>>> - in case the above answers are 'yes' and 'no, it's either/or': anybody
>>>> aware of Python bindings for RTDM?
>>>>
>>>> sorry for the noobish questions, climbing the learning curve
>>>>
>>>> - Michael
>>>> _______________________________________________
>>>> Xenomai mailing list
>>>> Xenomai@xenomai.org
>>>> http://www.xenomai.org/mailman/listinfo/xenomai
>>>>
>>>
>>> I am thinking that if the RTDM version of the driver is overkill for
>>> what you are doing, then it may be best to just use the regular Linux
>>> driver.
>>>
>>
>> certainly no point in using RT-CAN for say wiggling a led or querying a
>> slow sensor. But if the API could be used from non-Xenomai threads as well,
>> then I do not have to force the decision for either-or setup ahead of time.
>>
>> the specific application where socket-CAN is not an option would run as
>> part of a motion control loop with intelligent motor drives, which is
>> timing-critical for position feedback and stall detection. This is similar
>> to other interface types already in use in this setting, like Ethernet, so
>> just another modality. As for contention, I would probably not mix traffic
>> types on a bus.
>>
>>
>> CAN aside, part of the exercise is to learn how to modify drivers to
>> RTDM: for instance, we would gain big time from a SPI RTDM driver on
>> certain platforms (actually I would appreciate any pointers to references
>> how to approach that problem).
>>
>>
>>> As I understand it from a quick and simple question I recently asked of
>>> the list, if you're using the RTDM driver then its interrupt will be among
>>> the few things able to pre-empt your high priority Xenomai task (assuming
>>> you have any running at the time). So if you really don't need the CAN bus
>>> to be "rt-safe" then it may in some cases be better to have it set up with
>>> the regular Linux driver so that the i-pipe doesn't prioritize it over your
>>> RT tasks. That could also depend on how often you have frames coming in and
>>> whether or not you have danger of overrunning the hardware receive buffer
>>> if the interrupt service routine is neglected while your RT task is still
>>> running.
>>>
>>> It could a bit tricky, though (modifications to the driver source), if
>>> you wanted one CAN bus to be non-RT and one to be RT.
>>>
>>>
>>> With the RTDM driver, I'm not sure if it uses a Xenomai system call to
>>> open the socket (but I suspect that it may). If that's the case, then you
>>> can open it from either a primary or secondary mode Xenomai thread, but
>>> maybe not a regular Linux thread (i.e. a totally non-Xenomai application or
>>> a thread opened with __real_pthread_create).
>>>
>>
>> reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
>> (create socket, bind, ioctl etc) are done in a Linux thread. Only the read
>> and write ops are done in an RT thread. Just to check, I added a command
>> line option to do rt_dev_rec*/rt_dev_send* operations from a Linux thread,
>> and that seems to block.
>>
>
> correction: in this case rt_dev_send fails with EPERM
>
> This thread suggests it is not possible to call this function from a
> non-Xenomai thread:
> http://sourceforge.net/p/rtnet/mailman/message/19223387/
>
> someody else tried the same thing before, looks like he did not get an
> answer: http://www.xenomai.org/pipermail/xenomai/2012-April/025744.html
>

the reason for this is obviously the NULL definitions for recvmsg_nrt and
sendmsg_nrt in lines 1017 and 1020 here:

https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n1017

To enable non-RT recvmsg/sendmsg, is it OK to just set the recvmsg_nrt and
sendmsg_nrt pointers to rtcan_raw_recvmsg and rtcan_raw_sendmsg as is done
for instance with rtcan_raw_ioctl?

Or am I violating some fundamental assumption?

- Michael

>
>
>> The RTDM user API manual refers to Device Profiles, but it's unclear to
>> me if the answer really is "generally no", "generally yes", or "depends on
>> driver". Probably the latter, but I still have to understand the causal
>> chain.
>>
>>>
>>> Unfortunately I don't have an answer on the Python bindings
>>>
>>
>> If no answer comes up, but the RTDM API could be used from a normal Linux
>> thread, then what I would likely do is to extend the python-can bindings
>> for this interface type. Otherwise no point anyway I guess.
>>
>> - Michael
>>
>
>

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Jan Kiszka]

On 2015-03-20 08:26, Michael Haberler wrote:
>>>> As I understand it from a quick and simple question I recently asked of
>>>> the list, if you're using the RTDM driver then its interrupt will be among
>>>> the few things able to pre-empt your high priority Xenomai task (assuming
>>>> you have any running at the time). So if you really don't need the CAN bus
>>>> to be "rt-safe" then it may in some cases be better to have it set up with
>>>> the regular Linux driver so that the i-pipe doesn't prioritize it over your
>>>> RT tasks. That could also depend on how often you have frames coming in and
>>>> whether or not you have danger of overrunning the hardware receive buffer
>>>> if the interrupt service routine is neglected while your RT task is still
>>>> running.
>>>>
>>>> It could a bit tricky, though (modifications to the driver source), if
>>>> you wanted one CAN bus to be non-RT and one to be RT.
>>>>
>>>>
>>>> With the RTDM driver, I'm not sure if it uses a Xenomai system call to
>>>> open the socket (but I suspect that it may). If that's the case, then you
>>>> can open it from either a primary or secondary mode Xenomai thread, but
>>>> maybe not a regular Linux thread (i.e. a totally non-Xenomai application or
>>>> a thread opened with __real_pthread_create).
>>>>
>>>
>>> reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
>>> (create socket, bind, ioctl etc) are done in a Linux thread. Only the read
>>> and write ops are done in an RT thread. Just to check, I added a command
>>> line option to do rt_dev_rec*/rt_dev_send* operations from a Linux thread,
>>> and that seems to block.
>>>
>>
>> correction: in this case rt_dev_send fails with EPERM
>>
>> This thread suggests it is not possible to call this function from a
>> non-Xenomai thread:
>> http://sourceforge.net/p/rtnet/mailman/message/19223387/
>>
>> someody else tried the same thing before, looks like he did not get an
>> answer: http://www.xenomai.org/pipermail/xenomai/2012-April/025744.html
>>
> 
> the reason for this is obviously the NULL definitions for recvmsg_nrt and
> sendmsg_nrt in lines 1017 and 1020 here:
> 
> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n1017
> 
> To enable non-RT recvmsg/sendmsg, is it OK to just set the recvmsg_nrt and
> sendmsg_nrt pointers to rtcan_raw_recvmsg and rtcan_raw_sendmsg as is done
> for instance with rtcan_raw_ioctl?
> 
> Or am I violating some fundamental assumption?

You are: *_nrt handlers must not use any RTDM (or Xenomai) services
internally that may block the caller - because they will run over Linux
context. But that condition is clearly not fulfilled for blocking
recvmsg and probably also sendmsg (to sync on available CAN buffers etc.).

In general, if you have the need for some use cases to operate a piece
of hardware with an RT driver, all users of that hardware have to go
that path and at least have to be Xenomai threads - can also be SCHED_OTHER.

If you have a CAN adapter with multiple controllers that can be operated
separately, you may also use different drivers - if both (Linux and
RTDM) support to be attached only to a subset of controllers.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150320/a167ca03/attachment.sig>

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

Jan -

2015-03-20 8:54 GMT+01:00 Jan Kiszka <jan.kiszka@web.de>:

> On 2015-03-20 08:26, Michael Haberler wrote:
> >>>> As I understand it from a quick and simple question I recently asked
> of
> >>>> the list, if you're using the RTDM driver then its interrupt will be
> among
> >>>> the few things able to pre-empt your high priority Xenomai task
> (assuming
> >>>> you have any running at the time). So if you really don't need the
> CAN bus
> >>>> to be "rt-safe" then it may in some cases be better to have it set up
> with
> >>>> the regular Linux driver so that the i-pipe doesn't prioritize it
> over your
> >>>> RT tasks. That could also depend on how often you have frames coming
> in and
> >>>> whether or not you have danger of overrunning the hardware receive
> buffer
> >>>> if the interrupt service routine is neglected while your RT task is
> still
> >>>> running.
> >>>>
> >>>> It could a bit tricky, though (modifications to the driver source), if
> >>>> you wanted one CAN bus to be non-RT and one to be RT.
> >>>>
> >>>>
> >>>> With the RTDM driver, I'm not sure if it uses a Xenomai system call to
> >>>> open the socket (but I suspect that it may). If that's the case, then
> you
> >>>> can open it from either a primary or secondary mode Xenomai thread,
> but
> >>>> maybe not a regular Linux thread (i.e. a totally non-Xenomai
> application or
> >>>> a thread opened with __real_pthread_create).
> >>>>
> >>>
> >>> reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
> >>> (create socket, bind, ioctl etc) are done in a Linux thread. Only the
> read
> >>> and write ops are done in an RT thread. Just to check, I added a
> command
> >>> line option to do rt_dev_rec*/rt_dev_send* operations from a Linux
> thread,
> >>> and that seems to block.
> >>>
> >>
> >> correction: in this case rt_dev_send fails with EPERM
> >>
> >> This thread suggests it is not possible to call this function from a
> >> non-Xenomai thread:
> >> http://sourceforge.net/p/rtnet/mailman/message/19223387/
> >>
> >> someody else tried the same thing before, looks like he did not get an
> >> answer: http://www.xenomai.org/pipermail/xenomai/2012-April/025744.html
> >>
> >
> > the reason for this is obviously the NULL definitions for recvmsg_nrt and
> > sendmsg_nrt in lines 1017 and 1020 here:
> >
> >
> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n1017
> >
> > To enable non-RT recvmsg/sendmsg, is it OK to just set the recvmsg_nrt
> and
> > sendmsg_nrt pointers to rtcan_raw_recvmsg and rtcan_raw_sendmsg as is
> done
> > for instance with rtcan_raw_ioctl?
> >
> > Or am I violating some fundamental assumption?
>
> You are: *_nrt handlers must not use any RTDM (or Xenomai) services
> internally that may block the caller - because they will run over Linux
> context. But that condition is clearly not fulfilled for blocking
> recvmsg and probably also sendmsg (to sync on available CAN buffers etc.).
>
> In general, if you have the need for some use cases to operate a piece
> of hardware with an RT driver, all users of that hardware have to go
> that path and at least have to be Xenomai threads - can also be
> SCHED_OTHER.
>
> If you have a CAN adapter with multiple controllers that can be operated
> separately, you may also use different drivers - if both (Linux and
> RTDM) support to be attached only to a subset of controllers.
>
> Jan
>

well thanks for the education! obviously a blunder in the making.

I guess the dual-driver/controller solution you suggest is the way to go -
containment by "ships in the night" is fine.

Michael

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Steve B]

Michael,
At least for the Beaglebone Black case, it is looking like you will have a
good and simple way of picking which driver you load.
I am working on getting the driver integrated to the Xenomai tree and in
the process making minor tweaks.. by changing the "compatibility" string to
something unique it looks like you can match the CAN device to the driver
in your device tree overlay. Should be no more having to load the original
driver first.

I have a bit of an issue that I'm trying to work around with splitting the
driver into the multiple source files, but once I get that sorted out it
should be ready to work that way!

On Fri, Mar 20, 2015 at 1:02 AM, Michael Haberler <haberlerm@gmail.com>
wrote:

> Jan -
>
> 2015-03-20 8:54 GMT+01:00 Jan Kiszka <jan.kiszka@web.de>:
>
>> On 2015-03-20 08:26, Michael Haberler wrote:
>> >>>> As I understand it from a quick and simple question I recently asked
>> of
>> >>>> the list, if you're using the RTDM driver then its interrupt will be
>> among
>> >>>> the few things able to pre-empt your high priority Xenomai task
>> (assuming
>> >>>> you have any running at the time). So if you really don't need the
>> CAN bus
>> >>>> to be "rt-safe" then it may in some cases be better to have it set
>> up with
>> >>>> the regular Linux driver so that the i-pipe doesn't prioritize it
>> over your
>> >>>> RT tasks. That could also depend on how often you have frames coming
>> in and
>> >>>> whether or not you have danger of overrunning the hardware receive
>> buffer
>> >>>> if the interrupt service routine is neglected while your RT task is
>> still
>> >>>> running.
>> >>>>
>> >>>> It could a bit tricky, though (modifications to the driver source),
>> if
>> >>>> you wanted one CAN bus to be non-RT and one to be RT.
>> >>>>
>> >>>>
>> >>>> With the RTDM driver, I'm not sure if it uses a Xenomai system call
>> to
>> >>>> open the socket (but I suspect that it may). If that's the case,
>> then you
>> >>>> can open it from either a primary or secondary mode Xenomai thread,
>> but
>> >>>> maybe not a regular Linux thread (i.e. a totally non-Xenomai
>> application or
>> >>>> a thread opened with __real_pthread_create).
>> >>>>
>> >>>
>> >>> reading the rtcansend.c and rtcanrecv.c source, all the preliminaries
>> >>> (create socket, bind, ioctl etc) are done in a Linux thread. Only the
>> read
>> >>> and write ops are done in an RT thread. Just to check, I added a
>> command
>> >>> line option to do rt_dev_rec*/rt_dev_send* operations from a Linux
>> thread,
>> >>> and that seems to block.
>> >>>
>> >>
>> >> correction: in this case rt_dev_send fails with EPERM
>> >>
>> >> This thread suggests it is not possible to call this function from a
>> >> non-Xenomai thread:
>> >> http://sourceforge.net/p/rtnet/mailman/message/19223387/
>> >>
>> >> someody else tried the same thing before, looks like he did not get an
>> >> answer:
>> http://www.xenomai.org/pipermail/xenomai/2012-April/025744.html
>> >>
>> >
>> > the reason for this is obviously the NULL definitions for recvmsg_nrt
>> and
>> > sendmsg_nrt in lines 1017 and 1020 here:
>> >
>> >
>> https://git.xenomai.org/xenomai-2.6.git/tree/ksrc/drivers/can/rtcan_raw.c#n1017
>> >
>> > To enable non-RT recvmsg/sendmsg, is it OK to just set the recvmsg_nrt
>> and
>> > sendmsg_nrt pointers to rtcan_raw_recvmsg and rtcan_raw_sendmsg as is
>> done
>> > for instance with rtcan_raw_ioctl?
>> >
>> > Or am I violating some fundamental assumption?
>>
>> You are: *_nrt handlers must not use any RTDM (or Xenomai) services
>> internally that may block the caller - because they will run over Linux
>> context. But that condition is clearly not fulfilled for blocking
>> recvmsg and probably also sendmsg (to sync on available CAN buffers etc.).
>>
>> In general, if you have the need for some use cases to operate a piece
>> of hardware with an RT driver, all users of that hardware have to go
>> that path and at least have to be Xenomai threads - can also be
>> SCHED_OTHER.
>>
>> If you have a CAN adapter with multiple controllers that can be operated
>> separately, you may also use different drivers - if both (Linux and
>> RTDM) support to be attached only to a subset of controllers.
>>
>> Jan
>>
>
> well thanks for the education! obviously a blunder in the making.
>
> I guess the dual-driver/controller solution you suggest is the way to go -
> containment by "ships in the night" is fine.
>
> Michael
>
>
>

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Gilles Chanteperdrix]

On Fri, Mar 20, 2015 at 10:42:05AM -0700, Steve B wrote:
> Michael,
> At least for the Beaglebone Black case, it is looking like you will have a
> good and simple way of picking which driver you load.
> I am working on getting the driver integrated to the Xenomai tree and in
> the process making minor tweaks.. by changing the "compatibility" string to
> something unique it looks like you can match the CAN device to the driver
> in your device tree overlay. Should be no more having to load the original
> driver first.
> 
> I have a bit of an issue that I'm trying to work around with splitting the
> driver into the multiple source files, but once I get that sorted out it
> should be ready to work that way!

>From what I understood, the device tree is a description of the
hardware, so the compatibility string describes what hardware a
board/controller is based on. So, it does not make sense to change
the compatibility string to change the driver used. This is contrary
to the spirit of the device tree. A device tree is supposed to be OS
independent, the device tree files licenses for instance, have been
chosen to not prevent a device tree file from being used with BSD.

-- 
					    Gilles.

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Steve B]

On Fri, Mar 20, 2015 at 11:16 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On Fri, Mar 20, 2015 at 10:42:05AM -0700, Steve B wrote:
> > Michael,
> > At least for the Beaglebone Black case, it is looking like you will have
> a
> > good and simple way of picking which driver you load.
> > I am working on getting the driver integrated to the Xenomai tree and in
> > the process making minor tweaks.. by changing the "compatibility" string
> to
> > something unique it looks like you can match the CAN device to the driver
> > in your device tree overlay. Should be no more having to load the
> original
> > driver first.
> >
> > I have a bit of an issue that I'm trying to work around with splitting
> the
> > driver into the multiple source files, but once I get that sorted out it
> > should be ready to work that way!
>
> From what I understood, the device tree is a description of the
> hardware, so the compatibility string describes what hardware a
> board/controller is based on. So, it does not make sense to change
> the compatibility string to change the driver used. This is contrary
> to the spirit of the device tree. A device tree is supposed to be OS
> independent, the device tree files licenses for instance, have been
> chosen to not prevent a device tree file from being used with BSD.
>
> --
>                                             Gilles.
>

OK, sorry if I have it backwards. But if I have both drivers in my kernel
build and they both have the same compatibility string, they both get
loaded when I load my device tree overlay. In that case how are we supposed
to specify which one gets loaded?

Steve

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Gilles Chanteperdrix]

On Fri, Mar 20, 2015 at 11:28:21AM -0700, Steve B wrote:
> On Fri, Mar 20, 2015 at 11:16 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
> > On Fri, Mar 20, 2015 at 10:42:05AM -0700, Steve B wrote:
> > > Michael,
> > > At least for the Beaglebone Black case, it is looking like you will have
> > a
> > > good and simple way of picking which driver you load.
> > > I am working on getting the driver integrated to the Xenomai tree and in
> > > the process making minor tweaks.. by changing the "compatibility" string
> > to
> > > something unique it looks like you can match the CAN device to the driver
> > > in your device tree overlay. Should be no more having to load the
> > original
> > > driver first.
> > >
> > > I have a bit of an issue that I'm trying to work around with splitting
> > the
> > > driver into the multiple source files, but once I get that sorted out it
> > > should be ready to work that way!
> >
> > From what I understood, the device tree is a description of the
> > hardware, so the compatibility string describes what hardware a
> > board/controller is based on. So, it does not make sense to change
> > the compatibility string to change the driver used. This is contrary
> > to the spirit of the device tree. A device tree is supposed to be OS
> > independent, the device tree files licenses for instance, have been
> > chosen to not prevent a device tree file from being used with BSD.
> >
> > --
> >                                             Gilles.
> >
> 
> OK, sorry if I have it backwards. But if I have both drivers in my kernel
> build and they both have the same compatibility string, they both get
> loaded when I load my device tree overlay. In that case how are we supposed
> to specify which one gets loaded?

Loading a driver, but not initializing it is not a problem. I
believe the kernel will not start two drivers for the same device.
At least that is the way it works with other buses (like PCIe or USB).

You can unbind a device to a driver with sysfs files. Then bind the
device to another driver. I do not know if you can do this with
kernel command line arguments.

See for instance:
https://lwn.net/Articles/143397/

-- 
					    Gilles.

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Wolfgang Grandegger]

On 03/20/2015 07:16 PM, Gilles Chanteperdrix wrote:
> On Fri, Mar 20, 2015 at 10:42:05AM -0700, Steve B wrote:
>> Michael,
>> At least for the Beaglebone Black case, it is looking like you will have a
>> good and simple way of picking which driver you load.
>> I am working on getting the driver integrated to the Xenomai tree and in
>> the process making minor tweaks.. by changing the "compatibility" string to
>> something unique it looks like you can match the CAN device to the driver
>> in your device tree overlay. Should be no more having to load the original
>> driver first.
>>
>> I have a bit of an issue that I'm trying to work around with splitting the
>> driver into the multiple source files, but once I get that sorted out it
>> should be ready to work that way!
> 
>>From what I understood, the device tree is a description of the
> hardware, so the compatibility string describes what hardware a
> board/controller is based on. So, it does not make sense to change
> the compatibility string to change the driver used. This is contrary
> to the spirit of the device tree. A device tree is supposed to be OS
> independent, the device tree files licenses for instance, have been
> chosen to not prevent a device tree file from being used with BSD.

Yes, that's also my understanding and other RTCAN drivers use the same
bindings than the Linux driver. There are various options to handle
the driver binding:

- use rmmod to unload the Linux driver
- use "unbind" to disconnect the Linux driver and "bind" to connect
  the RT-variant
- do not build the Linux driver at all
- use /etc/modprobe.d/blacklist

Wolfgang.

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Wolfgang Grandegger]

On 03/19/2015 10:57 AM, Michael Haberler wrote:
> status:
> 
> I have Steve Batazzo's driver running on the beaglebone, using a stock
> Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
> from http://repos.rcn-ee.net/debian/), current driver out of tree at
> https://github.com/mhaberler/rtcan-bb branch mah
> 
> I also have a preliminary HAL driver for machinekit which talks to a
> Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get a
> CAN PCI card).
> 
> I'm working with Steve to get the driver polished and hope we can inject it
> into the Xenomai foodchain eventually, after which it will be eventually
> picked up by Robert's periodic builds, and the whole thing becomes an
> 'apt-get install' - affair. But we're not there yet.
> 
> 
> I have a few questions on RT-CAN (I guess really RTDM):
> 
> - can the RTDM API (
> https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
> used from a normal Posix thread (non-RT) just alike? from the rtcansend*
> utilities src it looks like at least for setup, even if the send/receive
> ops are done in an RT thread.
> 
> - socket-CAN and RT-CAN interworking: I assume this is an either-or affair,
> right? (background: for some jobs the RT-CAN features are overkill, and in
> that case something like the python-can binding would be convenient to use)

If the resources (irq, mem, etc.) used by the device are clearly
separated, it might be possible to use one device (of the same type) for
Linux and the other for RTCAN. It will work for sure for devices using
different drivers (belonging to different controllers).

Wolfgang.

Re: [Xenomai] RT-CAN question (was: CAN bus on beaglebone black)

[Michael Haberler]

I'll try the bind/unbind approach and see if I can both stacks to coexist,
that sounds like the most elegant way

thanks!

- Michael

2015-03-21 9:57 GMT+01:00 Wolfgang Grandegger <wg@grandegger.com>:

> On 03/19/2015 10:57 AM, Michael Haberler wrote:
> > status:
> >
> > I have Steve Batazzo's driver running on the beaglebone, using a stock
> > Xenomai kernel from Robert Nelson's repo (linux-image-3.8.13-xenomai-r71
> > from http://repos.rcn-ee.net/debian/), current driver out of tree at
> > https://github.com/mhaberler/rtcan-bb branch mah
> >
> > I also have a preliminary HAL driver for machinekit which talks to a
> > Trinamic motor over RT-CAN just fine (beaglebone for now, x86 once I get
> a
> > CAN PCI card).
> >
> > I'm working with Steve to get the driver polished and hope we can inject
> it
> > into the Xenomai foodchain eventually, after which it will be eventually
> > picked up by Robert's periodic builds, and the whole thing becomes an
> > 'apt-get install' - affair. But we're not there yet.
> >
> >
> > I have a few questions on RT-CAN (I guess really RTDM):
> >
> > - can the RTDM API (
> > https://xenomai.org/documentation/trunk/html/api/group__userapi.html) be
> > used from a normal Posix thread (non-RT) just alike? from the rtcansend*
> > utilities src it looks like at least for setup, even if the send/receive
> > ops are done in an RT thread.
> >
> > - socket-CAN and RT-CAN interworking: I assume this is an either-or
> affair,
> > right? (background: for some jobs the RT-CAN features are overkill, and
> in
> > that case something like the python-can binding would be convenient to
> use)
>
> If the resources (irq, mem, etc.) used by the device are clearly
> separated, it might be possible to use one device (of the same type) for
> Linux and the other for RTCAN. It will work for sure for devices using
> different drivers (belonging to different controllers).
>
> Wolfgang.
>
>