Hello,
I now want to fix the CAN_ERR_ACK issue. As you might have realized, the
so called "no-ack-on-tx" or "ack slot" bus error is not handled
consistently. That's the error we get when no cable is connected.
The inconstancy is that some drivers just set:
cf->can_id |= CAN_ERR_ACK;
while the SJA1000 sets:
cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
cf->data[3] |= CAN_ERR_PROT_LOC_ACK;
Unfortunately, CAN_ERR_ACK defines it's own error class like
CAN_ERR_BUSERROR even if it's just another bus error. Therefore
it belongs to the protocol violation types in data[2]:
/* 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_OVERLOAD 0x20 /* bus overload */
#define CAN_ERR_PROT_ACTIVE 0x40 /* active error announcement */
#define CAN_ERR_PROT_TX 0x80 /* error occured on transmission */
All bits are already used, but CAN_ERR_PROT_ACTIVE is misplaced
here as well :-(. It belongs to the controller problems in data[1].
So, for a correct solution I would add here:
#define CAN_ERR_PROT_ACK 0x40 /* received no ACK on transmission */
and move CAN_ERR_PROT_ACTIVE to
/* error status of CAN-controller / data[1] */
#define CAN_ERR_CRTL_ACTIVE 0x40 /* back to error active */
Then the error message for the "no-ack-on-tx" error would be
composed the following way:
cf->can_id |= CAN_ERR_PROT | CAN_ERR_BUSERROR;
cf->data[2] = CAN_ERR_PROT_ACK;
And CAN controllers providing more information like the SJA1000
would additionally set:
cf->data[3] |= CAN_ERR_PROT_LOC_ACK;
Unfortunately, the *correct* solution could rise some portability
issues as some users might already use CAN_ERR_PROT_ACK and especially
CAN_ERR_PROT_ACTIVE. What that be acceptible? What do you think?
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
