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....
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.
Since it permits a next bus error interrupt. the ECC reading should be
left to user application eg through an ioctl.
This may be an option or a error mode selectable by the programmer at
startup .
what do you think ?
Regards
steph
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
