Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Stéphane ANCELOT wrote:
Sebastian Smolorz wrote:
Note that the current implementation of RT-Socket-CAN shows this
behaviour on purpose. See also [1] ("may flood!"). Whether this is the
right handling or not may be discussed here. I admit that the current
implementation forces an application developer to take more
responsibility but that is not a bug of the underlying driver/stack per
se. Look, you don't connect anything to the CAN bus, start a
*real-time* application which sends a message to a non-existent CAN
node. This is an error situation an it is more than ever for a
real-time task. So the proper reaction for a RT-application would be to
handle those errors and e.g. shut down the CAN interface which in this
case will force the CAN hardware to stop its endless attempts to send
the message.
I agree and this is what I was doing , however this does not seem to
work as expected in the driver.
What does not work? The shutdown and stopping transmitting the CAN
messages?
--
Sebastian
Yes, this is exactly what has happened to me and rolland problem , one
rtcansend launched and BEI interrupt come always....
Yes, I know. But when you stop the CAN interface in such a situation the
interrupts must disappear because the controller does not try to send the
message any more.
since the error management shoudl be done by appplication process, I
think that BUS ERROR INTERRUPT can be reported however the ECC reading
must not be done by the interrupt routine.
I don't think that reading the ECC is the critical point, rather the interrupt
flodding is.
Since it permits a next bus error interrupt. the ECC reading should be
left to user application eg through an ioctl.
Error reporting in RT-Socket-CAN is the same as in Socket-CAN for plain Linux.
It is done via error frames sent to the application. So your suggestion would
break the API here and frankly is not necessary. You have several
possibilities to detect a bus error due to a disconnected bus and can handle
the situation properly (e.g. restart the interface). If a series of error
frames are generated which shows you TX bus errors with missing
acknowledgments you can be quite sure that no other node is connected to the
bus.
This may be an option or a error mode selectable by the programmer at
startup .
what do you think ?
Last summer we had a discussion about the BEI issue on the socketcan-ML. Two
additional handling policies popped up:
1. The interface could restart itself after an amount of BEIs, thus taking
responsibility from the user application.
2. The BEI could be completely disabled if no one is interested in this type
of error frame.
I tried to implement 2. for SJA1000, but re-enabling the BIE on the fly
does not work. :-(. The controller requires a re-start of the device to
get the bus error reporting back to work.
Maybe it is time to think about the implementation of these policies as more
and more users seem to run into the BEI issue with a disconnected bus.
Wolfgang, Jan, what is your opinion?
Well, solution 2. with the limitations mentioned above is therefore less
attractive because it interrupts the CAN traffic. The Socket-CAN
implementation actually restarts the CAN controller after a certain
amount of bus error interrupts (200 by default) which matches your first
policy above. But in RT-Socket-CAN, we do not automatically re-start the
device by purpose. Therefore I tend to just stop the device. It's then
up to the application to restart it. What do you think?
Wolfgang.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
