On 02/15/2011 09:56 PM, Oliver Hartkopp wrote: > On 15.02.2011 21:21, Wolfgang Grandegger wrote: > >>> I strongly assumed the data[] bytes hold 'states' and not 'state changes' >>> ... >> >> Yep, but we treat error active as state as well. Anyway, I'm fine with >> the CAN_ERR_ACTIVE class (in can_id). > > ok > > >>> >>> Hm - my intention was that most of the interesting states are available in >>> the >>> CAN-ID directly (e.g. _BUSOFF, _RESTARTED, _ACK and now _ACTIVE) >> >> Why is especially _ACK interesting. As I said, it belongs to the bus >> errors. There are 5 different error types (which are not mutually >> exclusive): >> >> - BIT ERROR >> - STUFF ERROR >> - CRC ERROR >> - FORM ERROR >> - ACKNOWLEDGMENT ERROR >> >> It does make little sense to me to just have a bit for the last error in >> the CAN id (and not the others as well). They all below to CAN_ERR_BUSERROR. > > Ah, got it now. > > So when CAN_ERR_BUSERROR is set, i may check CAN_ERR_PROT and then into > data [2..3], right? > > So CAN_ERR_ACK would be obsolete ...
Yes. > I think, the reason why CAN_ERR_ACK has made it's way into the error class > bits in the CAN-ID was because of missing ACKs usually happen, when there's > only one CAN node on the bus. The idea was to detect missing CAN nodes or > wrong termination directly through CAN_ERR_ACK. Yes, you seem to remember correctly. See: https://lists.berlios.de/pipermail/socketcan-core/2006-May/000089.html But wrong termination may result in other errors as well and there I think it could not be used reliably for the purpose you describe above. > Logically this is redundant to the bitvalue in CAN_ERR_PROT_ACK > >>> These bits are only enablers for the additional information in data[..] : >>> >>> #define CAN_ERR_LOSTARB 0x00000002U /* lost arbitration / data[0] >>> */ >>> #define CAN_ERR_CRTL 0x00000004U /* controller problems / data[1] >>> */ >>> #define CAN_ERR_PROT 0x00000008U /* protocol violations / data[2..3] >>> */ >>> #define CAN_ERR_TRX 0x00000010U /* transceiver status / data[4] >>> */ >> >> The problem we have is that the errors are mainly derived from the >> reporting capabilities of the SJA1000. Then we added some other flags >> for errors from other controllers. There are other inconsistencies. >> We do not have a bit for CRC errors. Therefore the at91_can.c just sets: >> > > (leaving out the mess :-) > >> >> Puh, what a mess. OK, I think what we need is: >> >> /* error in CAN protocol (type) / data[2] */ >> #define CAN_ERR_PROT_UNSPEC 0x00 /* unspecified */ >> #define CAN_ERR_PROT_BIT 0x01 /* single bit error */ >> #define CAN_ERR_PROT_FORM 0x02 /* frame format error */ >> #define CAN_ERR_PROT_STUFF 0x04 /* bit stuffing error */ >> #define CAN_ERR_PROT_BIT0 0x08 /* unable to send dominant bit */ >> #define CAN_ERR_PROT_BIT1 0x10 /* unable to send recessive bit */ >> #define CAN_ERR_PROT_CRC 0x20 /* crc error */ >> #define CAN_ERR_PROT_ACK 0x40 /* active error announcement */ > > copy&paste problem in this comment? > > Should be > #define CAN_ERR_PROT_ACK 0x40 /* received no ACK on transmission */ Yep. >> #define CAN_ERR_PROT_TX 0x80 /* error occured on transmission >> >> Apart from CAN_ERR_PROT_ACTIVE I removed CAN_ERR_PROT_OVERLOAD which is >> *not* used in any driver and added the missing two bus error types >> CAN_ERR_PROT_CRC, CAN_ERR_PROT_ACK. For BIT errors we have three bits >> and in principle we could set (CAN_ERR_PROT_BIT0 ¦ CAN_ERR_PROT_BIT1) >> for CAN controllers not distinguishing BIT0 and BIT1 errors. data[3] >> would only be filled by the SJA1000. CAN_ERR_PROT and CAN_ERR_BUSERROR >> are more or less redundant. > > Yes. From the current point of view they are. I thought a CAN_ERR_BUSERROR > could be triggered by anything else then protocol violations ... > Then it might have become interesting when using a special filter mask for > error frames. You mean a bit in the CAN id for the five bus error types? >> It's getting more and more clear now what to do. > > Yes. We then could or even should add a version information into the error message. I think data[5] could be used for that purpose. Wolfgang. _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
