Hi,
the overflowing of the buffer.
CAN socket buffer overflow --> kernel prints warnings --> syslogd logs these
warnings
thanks this helps.
As I stated in another mail you can silence the overflow message by
configuring it out. But ask yourself if this is really what you want. Losing
messages due to an overflowing buffer is nothing that should appear regularly
but rather as exception. The kernel message is meant to inform you of this
exceptional situation. If you lose messages under RT conditions you very
likely have more severe problems than a kernel printing out too much
information.
True. Very true. Well lets pursue this line of thought then. My node is
set to sending 1 message every 1ms if the position changes. I am reading
out the message buffer and it seems to work. But in theory I should only
be findin 1 or zero messages in the buffer every time I read. Why don't
I? Is the messagebuffer perhaps not cleaned out when I do a read? I only
get an overflow when the sensor moves and emits readings. the readings
are fine and I don;t have any masks set for errors anyway so I assume
that my reads are not cleaning out the entire buffer. I have pasted in
the code in which I do the reading. Am I doing something wrong?
while(ret>=0){
ret = rt_dev_recv (can_fd, (void *)&Rxframe,
sizeof(can_frame_t), MSG_DONTWAIT);
if (ret < 0) {
switch (ret) {
case -ETIMEDOUT:
printf("rt_dev_recv: timed out");
break;
case -EBADF:
printf("rt_dev_recv: aborted because
socket was closed");
break;
}
}
}//while message buffer not empty
//when exiting this loop the message buffer will be empty??????
I have cleared out some of the code in the loop for selecting the
message I want and so on but it will in essence not influence the
beahvior above.
Right. In fact, for the RAW protocol layer this is the very same situation as
with the error frames. In my opinion, a clean design approach is not to
silence the warnings because the discarding of CAN frames takes place
regardless of this. I think you have to options:
1. If messages are lost sporadically try to enlarge the socker buffer size.
Have considered this but it will slow down the reading routine (while
loop in above snippet runs longer)
2. If messages are lost permanently your real-time task is overloaded. Try to
lower the baud rate, set an appropriate filter or, more likely, rethink your
whole system design.
The design should be right. At the moment I am only looking for one
message and only one message seems to be filling the message buffer.
Filtering that will give me no reading.
If CAN frames are piling up in the socket buffer and
your application isn't quick enough to read them out although it does nothing
else than receiving them, then there is something going wrong.
Probably. Hope you see something wrong in the reading loop.
According to the documentation a normal recv will remove the message
from the buffer unless PEAK_something flag is used. So I assume that I
am clearing out the buffer in the above code.
Regard,s
Roland
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
