On 09/07/2009 11:16 AM, Sebastian Haas wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Wolfgang Grandegger schrieb: >> Hi Vladislav, >> >> On 09/07/2009 10:31 AM, [email protected] wrote: >>> Hi, >>> >>> my interpretation of ISO 11898-1 is that it is indeed allowed >>> to recover from bus off to error-active after 128*11 recessive >>> bits AND "user request", where "user request" is SW or HW >>> request. >>> So the HW (CAN controller) is allowed to implement auto recovery >>> feature (may even make auto recovery to the permanent and the >>> only behavior). >>> >>>> From the CAN point of view the bus off is a protection mechanism, >>> the CAN controller goes to bus off because something is seriously >>> wrong with itself, wires or other nodes. So it is very often not >>> really good idea to make automatic recovery which is with other >>> words simply ignoring that serious problems (well, the reception >>> of 128*11 recessive bits is a good sign that the problem has gone, >>> but still..). The application may want the CAN controller to >>> signal the bus off and stay off the bus until the application >>> decides to recover the communication. >>> >>> So if the CAN controller only supports auto recovery and cannot >>> keep hands off from the bus, the option for the manual recovery >>> in the socket CAN driver is to reset CAN controller in the bus off >>> interrupt (I remember this was proposes by Sebastian, and I >>> agree on this). >> >> Yes, the question is if we should support auto-recovery at all, e.g. as >> proposed in >> https://lists.berlios.de/pipermail/socketcan-core/2009-September/002971.html >> >> I tend to disallow it, also to have a common behavior of auto and manual >> recovery. > Why not supporting it and let the user choose to enable or disable it. > But by default it should be disabled, IMHO.
I would like to avoid another configuration option if possible. Because firstly to keep the code simply and secondly to not confuse the user even more. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
