On 06/18/2010 05:55 PM, [email protected] wrote: > Hello Wolfgang, > >>> We have used SocketCAN SW (rev 1033) with sysfs control for our > CANopen SW. >>> Everything was working just fine. We have received CAN error control >>> messages (can_id CAN_ERR_CRTL with flag CAN_ERR_FLAG set) to react on > the >>> following events: >>> - bus-off >>> - CAN Rx overrun >>> - error passive >>> - error active (recovery from errors) >>> >>> The "error active" was indicated by the error control message with > the value >>> CAN_ERR_CRTL_UNSPEC in the databyte 1. >> >> To understand better your requirements and usecase: do you use it just >> for bus error recovery? For that purpose we send "CAN_ERR_RESTARTED". >> > > Yes, exactly. What I am missing is a signal, that CAN controller has > been > recovered from the error. > > Over the CAN_ERR_CTRL I do get following events correctly signaled: > - bus-off > - CAN Rx overrun > - error passive/warning > > 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. > 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? Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
