On 15.02.2011 20:18, Wolfgang Grandegger wrote:
> On 02/15/2011 05:52 PM, Oliver Hartkopp wrote:
>> On 15.02.2011 10:34, Wolfgang Grandegger wrote:
>>

>>>
>>> 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.
> 
> Well, data[1] holds all our state changes. When we start to handle
> decreasing state changes as well.

I strongly assumed the data[] bytes hold 'states' and not 'state changes' ...

Therefore missing bits would indicate that everything is fine.

>> 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.
> 
> Yes, to wait for "back-to-error-active" events when bus-off recovery has
> completed might be useful.

fine.

>>> 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;
>> ???
> 
> Why, it's a bus error just like a crc or frame error.

?? I _removed_ the CAN_ERR_BUSERR flag in my suggestion, as i don't think it
is correct here.

> CAN_ERR_ACK might
> just be useful for backward compatibility but I don't think anybody uses
> it. I would like to clean that up.

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)

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]    */

Regards,
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to