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 ... 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. 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 */ > #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. > It's getting more and more clear now what to do. Yes. Regards, Oliver _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
