CAN Frame Timestamping Semantics

[davidlenfesty]

I believe the current implementation of frame timestamping is correct. Namely, that it uses the timestamp provided by the Transfer. Our implementation does not do anything with this timestamp - we write it and send out the frame.

I think this because most implementations should only care about the timestamp when ensuring that messages are getting sent within a reasonable time frame, and thus the important value is the one provided by the Transfer. The question that arises then, is do we even need this timestamp at all? Should it be removed from the CanFrame object? The library user can just grab the timestamp from the original Transfer.

And is my assumption that this is fine correct? I'm not sure, I can't think of any cases where individual timestamping is required.

(This doesn't necessarily even need to be resolved, I mostly wanted a place to reference my thoughts if this ever comes up in the future).

[pavel-kirienko]

And is my assumption that this is fine correct? I'm not sure, I can't think of any cases where individual timestamping is required.

If the transmission queue is blocked (for instance, as a result of the CAN interface being disconnected), the application shall be able to remove frames that have timed out from the transmission queue. The same holds for optional-priority frames that may never be transmitted even with a fully functional network. Per-frame timestamping is one way of achieving this; if this functionality is removed, then an alternative should be offered, although I don't see a sensible one at the moment.