On 15.02.2011 10:34, Wolfgang Grandegger wrote:
> 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 */
ack.
This is definitely a protocol problem that can happen on TX.
>
> and move CAN_ERR_PROT_ACTIVE to
>
> /* error status of CAN-controller / data[1] */
> #define CAN_ERR_CRTL_ACTIVE 0x40 /* back to error active */
>
Hm. So far only 'problems' have been encoded into this byte. We could define
'zero' as having 'no problems' ... but adding a new 'good situation flag'
doesn't fit to me.
IMHO i would leave this data[1] as-is and better add a new flag into the CAN-ID:
#define CAN_ERR_BUSOFF 0x00000040U /* bus off */
#define CAN_ERR_BUSERROR 0x00000080U /* bus error (may flood!) */
#define CAN_ERR_RESTARTED 0x00000100U /* controller restarted */
#define CAN_ERR_ACTIVE 0x00000200U /* controller (self) recovered */
Analogue to the bus-off flags you can filter for a self recovering controller
then.
> 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;
Better
cf->can_id |= CAN_ERR_PROT | CAN_ERR_ACK;
???
To me CAN_ERR_PROT just point's to *additional* information, if wanted.
CAN_ERR_ACK itself would be enough here also.
> 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;
>
ack. This looks good.
> 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?
IMO the cleanup is important. The earlier we do this, the better.
I assume the people going into these details are reading this mailing-list.
And as the support from the CAN controller drivers is currently very
inconsistent, i won't think anyone is really relying on these bits in a
non-development environment. But this is just a guess ...
Thanks for your RFC!
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
