Jan - 2015-03-20 8:54 GMT+01:00 Jan Kiszka <[email protected]>:
> 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 _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
