On 02.02.21 12:12, Vincent MAILHOL wrote:
The CAN_ERR_FLAG has been renamed in the documentation to indicate
"error messages" from the CAN controller, as an error frame is something
completely different.
Now as we are talking about having CAN_ERR_FLAG in the TX path besides
the vcan testing stuff, we should think about an API for the really
outgoing frames.
We could not only think about "create an error frame right now" but also
think about a more intelligent CAN node, which also offers to destroy
one or more specific CAN ID(s) at a specific bit position after
detecting that CAN ID.
My original idea was to leave it unspecified until a device was
actually capable of doing such a thing. But I am not against
defining the API now :) We might just have to wait a long time
for someone to actually implement it.
We could use the CAN_RTR_FLAG and the data[] section of the outgoing
error CAN frames for such an API.
We are not limited to the CAN_RTR_FLAG and the data[]
First, we have to list the use cases.
As I wrote before, there are only two forms for the error flag:
- The active error flag: 6 consecutive dominant bits
- The passive error flag: 6 consecutive recessive bits
IMO this passive error flag stuff is pointless.
The passive error does not have any effect on the bus. Nobody sees it.
It's just a measure to continue counting error counters inside the CAN
controller. IMO it's a read-only feature about the controller internal
status.
The device can either inject the flag either during:
- bus idle
Is an error flag defined at bus idle?
Error flags are intended to destroy *other CAN controllers*
transmissions when detecting protocol violations. There can not be a
protocol violation at idle time, right?
- while it is transmitting a frame
What's the use-case for destroying your own transmission?
- while it is receiving a frame
This makes sense, especially when you can destroy specific CAN ID frames
at a specific bit position.
Or for any CAN ID at a specific bit position.
Or for any CAN ID at an undefined bit position.
The error flag can occur at any time.
Sure? (see above)
Of course we might also provide some pump gun mode which just sends an
error flag at some (any) time.
But for what reason?
Therefore I would massively reduce the following list:
My first proposal would be:
1/ One flag to specify the error flag form (active or
passive). Passive error flags can not be used when receiving
a frame.
NO
2/ One flag to specify if we inject during bus idle or not.
NO
3/ One flag to specify if we inject while transmitting or
receiving a frame.
NO - receiving only
4/ If injecting while receiving, have the ability to specify
the CAN ID, DLC and flag filters (EFF, SFF, RTR, BRS...) of
the frame on which we want to inject the error flag. I do not
see the need for a complex filter. I would propose to either
have an exact match or no match (e.g. inject on next frame
whatever this frame is).
Yes. Additionally to a bit position after detecting the CAN ID, we could
also provide these symbolic defines like 'BRS' from which position we
want to start the error flag transmission.
But we should be careful not to make the job too complex for the sending
CAN controller.
5/ One flag to specify if injection while transmitting is done
on exact match or on any frames (if done on any frames,
the filters 4/ are ignored). This flag is ignore for bus idle or
while receiving.
NO - receiving only
6/ If we inject while receiving, do it on the next normal frame
we transmit (no filter). The userland have to send two frame:
one with CAN_ERR_FLAG and one normal one on which we
will inject the error flag in order to use the feature.
Maybe the 'pump gun' could always hit the 'next' frame as default.
7/ Have an offset: the bit index on which we want to inject the
error flag. I am not yet sure if we should ignore bitstuffing
or not. If the bus is idle, wait offset bit times before
injecting. Else, start counting the bits from the Start of
Frame.
See 4/
The flags 1/, 2/, 3/, 5/ and the offset 7/ goes into the data[]
payload, the filters 3/ goes into their respective field (CAN ID,
DLC, FF, SFF, RTR, BRS flags).
Regards,
Oliver
