Re: [Socketcan-users] [Xenomai-help] Re: send error: permission denied

Re: [Socketcan-users] [Xenomai-help] Re: send error: permission denied

[Wolfgang Grandegger]

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Hi Daniel,
>>
>> Daniel Schnell wrote:
>>> Hi,
>>>
>>>  
>>>
>>> I am new to socket can.
>>>
>>>  
>>>
>>> I wanted to test the rtcan driver in combination with Linux and
>>> Xenomai and made a little program according to the rtcansend program
>>> but with some response time measurements.
>>>
>>>  
>>>
>>> However after setting up the socket I get –EPERM when trying to send a
>>> packet to the can device. As the documentation doesn’t state anything
>>> about this error when calling rt_dev_send() I wonder why the error if
>>> at all doesn’t appear earlier if I try to setup the socket. The test
>>> program already ran nicely when I tested the peak can drivers for
>>> linux. I just changed the driver specific calls.
>>>
>>>  
>>>
>>> Attached you find the complete test file, the function task() is the
>>> one to blame.
>>>
>>>  
>>>
>>> I am a bit stuck with this, so maybe someone can give me a slight hint
>>> in what i am doing wrong.
>> I tried your program on my system and got the same error. The problem
>> is, that rt_dev_send() is called from non-RT context, which is illegal.
> 
> ...but should not matter if the caller is a Xenomai thread in "Linux" mode.
> 
>> At a first glance, it's not obvious to me why. Therefore I added the
>> Xenomai Help ML to the CCs.
> 
> How did you all compile the program [1]? Using xeno-config
> --posix-cflags / --posix-ldflags?

No, ah, oh. It works using the above flags, indeed. I see, that it calls 
_rtdm_sendmsg in secondary execution mode (none-RT) first, which 
returned -ENOSYS (-38). Then I guess, the context is switch to primary 
mode and _rtdm_sendmsg is called again, correct?

> Jan
> 
> 
> PS: Daniel, if you go the POSIX way, you don't have to use rt_dev_, you
> can use the normal POSIX API directly. That services will be wrapped on
> the Xenomai core just like pthread&friends.

Cool. I was not yet aware of that.

> [1]https://lists.berlios.de/pipermail/socketcan-users/attachments/20060821/ff454f48/cantest_rt.obj

Thanks for clarifying things.

Wolfgang.

Re: [Socketcan-users] [Xenomai-help] Re: send error: permission denied

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2934 bytes --]

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Daniel,
>>>
>>> Daniel Schnell wrote:
>>>> Hi,
>>>>
>>>>  
>>>>
>>>> I am new to socket can.
>>>>
>>>>  
>>>>
>>>> I wanted to test the rtcan driver in combination with Linux and
>>>> Xenomai and made a little program according to the rtcansend program
>>>> but with some response time measurements.
>>>>
>>>>  
>>>>
>>>> However after setting up the socket I get –EPERM when trying to send a
>>>> packet to the can device. As the documentation doesn’t state anything
>>>> about this error when calling rt_dev_send() I wonder why the error if
>>>> at all doesn’t appear earlier if I try to setup the socket. The test
>>>> program already ran nicely when I tested the peak can drivers for
>>>> linux. I just changed the driver specific calls.
>>>>
>>>>  
>>>>
>>>> Attached you find the complete test file, the function task() is the
>>>> one to blame.
>>>>
>>>>  
>>>>
>>>> I am a bit stuck with this, so maybe someone can give me a slight hint
>>>> in what i am doing wrong.
>>> I tried your program on my system and got the same error. The problem
>>> is, that rt_dev_send() is called from non-RT context, which is illegal.
>>
>> ...but should not matter if the caller is a Xenomai thread in "Linux"
>> mode.
>>
>>> At a first glance, it's not obvious to me why. Therefore I added the
>>> Xenomai Help ML to the CCs.
>>
>> How did you all compile the program [1]? Using xeno-config
>> --posix-cflags / --posix-ldflags?
> 
> No, ah, oh. It works using the above flags, indeed. I see, that it calls
> _rtdm_sendmsg in secondary execution mode (none-RT) first, which
> returned -ENOSYS (-38). Then I guess, the context is switch to primary
> mode and _rtdm_sendmsg is called again, correct?
> 

Exactly, that's how it works.

>> Jan
>>
>>
>> PS: Daniel, if you go the POSIX way, you don't have to use rt_dev_, you
>> can use the normal POSIX API directly. That services will be wrapped on
>> the Xenomai core just like pthread&friends.
> 
> Cool. I was not yet aware of that.

Yes, and one should try to keep the sources clean (though mixing is
technically fine): either go native and pick real-time related services
from this API (would include task creation here) or go POSIX and use
only that API. If unsure about the status of some particular function,
see the docs or <xeno-installation>/lib/posix.wrappers for the list of
available bindings. (*)

> 
>> [1]https://lists.berlios.de/pipermail/socketcan-users/attachments/20060821/ff454f48/cantest_rt.obj
>>
> 
> Thanks for clarifying things.
> 
> Wolfgang.
> 

Jan


(*) Native has the charm of being more explicit ("This is hard-RT, any
    other service not.") and sometimes more handy to use. POSIX is
    standard, thus far easier portable. And it may already be well known
    to the programmer.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Socketcan-users] [Xenomai-help] Re: send error:permission denied

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

Daniel Schnell wrote:
> Hi,
> 
> Thanks, this looks much better. Also thanks for pointing out the POSIX only solution. Althoug the final linkstage printout now has become _really_ longish.

That has been shortened recently in Xenomai's SVN, will come with 2.3.

> 
> I have made the call to rt_timer_read() because strangely the gettimeofday() call gave me more jitter than the xenomai native call.
> Can this be confirmed by anybody ? So if I could replace this native call with a POSIX conforming call that works as good then I could get rid of -lnative from my makefile.
> I could of course add a inline assembler readtsc call and calculate it myself with consideration of the actual cpu clock. But I thought that there is already something available.
> Does anybody have any opinion about that ?
> 

gettimeofday is not provided as real-time service, use clock_gettime
instead.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]