[Xenomai-help] some problems using RTCAN on PEAK dongle

[Xenomai-help] some problems using RTCAN on PEAK dongle

[roland Tollenaar]

Hi,

Ok rtcan2 and the peak dongle seem to be working. I am now running
into new problems with my application.

The first question is how do I reset the ctrl_mode to nothing.
Listen-only and loopback are both debugging/testing states but how do
I reset them to ....what is the normal state called? At the moment I
am in loop_back mode all the time.

I am writing to rtcan2 from my application and subsequently reading
from it. Works by the look of things BUT my CPU is working overtime.
syslogd and klogd are consuming 50-60% plus 30-40% of the processor
time. Obviously everything gets sticky but I can still see that the
task times are being maintained and the actual applicaiton is using
less than 3% of the processor time.

Besides this simple can functionality there is nothing happening in
the tasks and this does not happen if I write and read on rtcan0.

Finally after a long while of running and stopping the application I
get the message

rt_dev_bind: -no space left on device.

This bind is called before the read-call.

Can anyone please shed some light on these issues. Much appreciated as usual.

Kind regards,


Roland

Re: [Xenomai-help] some problems using RTCAN on PEAK dongle

[Wolfgang Grandegger]

roland Tollenaar wrote:
> Hi,
> 
> Ok rtcan2 and the peak dongle seem to be working. I am now running
> into new problems with my application.
> 
> The first question is how do I reset the ctrl_mode to nothing.
> Listen-only and loopback are both debugging/testing states but how do
> I reset them to ....what is the normal state called? At the moment I
> am in loop_back mode all the time.

# rtcanconfig -c none rtcan0

Wiil be documented a.s.a.p.

> I am writing to rtcan2 from my application and subsequently reading
> from it. Works by the look of things BUT my CPU is working overtime.
> syslogd and klogd are consuming 50-60% plus 30-40% of the processor

O, ah, what gets logged that often?

> time. Obviously everything gets sticky but I can still see that the
> task times are being maintained and the actual applicaiton is using
> less than 3% of the processor time.

Polling too often is a typical problem of the polling method.

> Besides this simple can functionality there is nothing happening in
> the tasks and this does not happen if I write and read on rtcan0.
> 
> Finally after a long while of running and stopping the application I
> get the message
> 
> rt_dev_bind: -no space left on device.
> 
> This bind is called before the read-call.
> 
> Can anyone please shed some light on these issues. Much appreciated as 
> usual.

Grrr, I already told you that it does not make sense to use bind and 
ioctl SSIOCGIFINDEX for every read here: 
https://mail.gna.org/public/xenomai-help/2007-02/msg00354.html. Please 
(re-)read 
http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html#Bind
and
http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html#gee74ae50c8ea0a6aee277c6f124a3866
to understand why.

Nevertheless, there seem to be a memory leak when re-binding the device. 
I will have a look a.s.a.p. (but it should not be a problem for your app 
when you just do it once per socket).

Wolfgang.

> 
> Kind regards,
> 
> 
> Roland
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 
> 

Re: [Xenomai-help] some problems using RTCAN on PEAK dongle

[roland Tollenaar]

Hi Wolfgang,

> # rtcanconfig -c none rtcan0
>
> Wiil be documented a.s.a.p.

Thanks.


>
> O, ah, what gets logged that often?

This message 89.5 billion times:
xeno_can: socket buffer overflow (fd=1), message discarded
each time followed by this message
xeno_can: socket buffer overflow (fd=0), message discarded

I am not sure how this happens. I write once every cycle and when I
perform a read I  read the message buffer until it is empty. This
should not be possible unless there is yet another setting that should
remove the message read from the buffer. But the way i uderstand it
one must pass the PEEK flag in order to NOT remove the message under
normal circumstances the message should be extracted from the buffer.
What am I missing?



>
> > time. Obviously everything gets sticky but I can still see that the
> > task times are being maintained and the actual applicaiton is using
> > less than 3% of the processor time.
>
> Polling too often is a typical problem of the polling method.
Well I have this same technique operational on a vxWorks system and it
works like a charm. I can't see that reading out the buffer once every
1ms can be a problem for rtcan. Can it?


>
> > Besides this simple can functionality there is nothing happening in
> > the tasks and this does not happen if I write and read on rtcan0.
> >
> > Finally after a long while of running and stopping the application I
> > get the message
> >
> > rt_dev_bind: -no space left on device.
> >
> > This bind is called before the read-call.
> >
> > Can anyone please shed some light on these issues. Much appreciated as
> > usual.
>
> Grrr, I already told you that it does not make sense to use bind and
> ioctl SSIOCGIFINDEX for every read here:
Not explicitly you haven't. :) If its any consolation it occurred to
me that this might be a problem. But only on my way home last night.

> https://mail.gna.org/public/xenomai-help/2007-02/msg00354.html. Please
> (re-)read
> http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html#Bind
> and
> http://www.xenomai.org/documentation/trunk/html/api/group__rtcan.html#gee74ae50c8ea0a6aee277c6f124a3866
> to understand why.

Are you pulling my leg? Even if I know what I am looking for the above
documentation does not make it evident that one must only bind once
for a socket and that the socket does not get "unbound" if I exit the
function it was bound in.

>
> Nevertheless, there seem to be a memory leak when re-binding the device.
> I will have a look a.s.a.p. (but it should not be a problem for your app
> when you just do it once per socket).
Doing that now, seems to have sorted the problem out. Mind you I am
not sure you have a memory leak, I did not notice the memory filling
up.


The following new issues:
If I run my loop in normal mode with nothing attached, I presume there
will be the typical CAN Errors flying around (I can see them counting
up in /proc/rtcan/rtcan2/info).  I am trying to figure out how to get
hold of them, using rtcanrecv . The documentation is difficult to use.
For example I checked up on the control modes but the only thing
hinting that there IS a third normal mode (if one does not know this)
is the word special. Please look. Also if one is looking for how to
handle errors without knowing then the assumption develops that the
CAN errors are pumped into the message buffer along with the normal
messages and that the application must sift them out using the error
masks.

If this is the case then clearly they do not come out iwth the normal
recv read because I don't see them. So this is why i have to use the
masks. How? Well I hope that studying rtcanrecv will tell.

Is the above correct? (if not detailed and complete). Because I can
only make this out from the documentation by implication and making a
couple of guesses here and there.

Perhaps these errors are the reason that the message buffer gets
overfull? They are not read out by the normal recv. Is there any way
to flush the errors out of the message buffer?


Thanks

Regards,

Roland

>
> Wolfgang.
>
> >
> > Kind regards,
> >
> >
> > Roland
> >
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> >
> >
>
>