Hello Wolfgang,
>> >>>> I expect to get the bus error recovery event also over the >> CAN_ERR_CRTL >>>> event class, because we deal here with CAN controller state change >>>> (currently I am pretty sure that I do not get anything on error >>>> recovery, >>>> not even CAN_ERR_RESTARTED). >>> >>> I'm pretty sure that you get CAN_ERR_RESTARTED with a recent version of >>> Socket-CAN. If not, it's a bug. >> >> OK, will recheck that. >> >> >> >>>> CAN_ERR_PROT_ACTIVE and CAN_ERR_RESTARTED are another classes of >> events, >>>> so >>>> I think it is conceptually not the right way to signal error recovery >>>> over >>>> that events. >>> >>> The CAN_ERR_RESTARTED was introduced for that purpose but I agree that >>> the CAN error state change should be signaled to the user as well. What >>> do you think about signaling *any* state change to the user, not just >>> when the state gets worse? >> >> Well, I don't see any reason to tell the user only the bad news 8) >> Our CANopen Stack (as an example of the user application) cares also >> about >> resuming from error state. >OK, that's something I would like to change anyway. Going to prepare a >RFC patch for the SJA1000 as soon as time permits. Nevertheless, for the >for bus error recovery CAN_ERR_RESTARTED should be used. A better name >would be CAN_ERR_RECOVERED, but historically it was used in a more >general context. I have rechecked my event parcer, and see now, that I do get the CAN_ERR_RESTARTED event on the manual "bus-off recovery". Regards, Vladislav _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
