Optional nanosecond timestamp logging

[RikusW]

Use timespec instead of timeval so timestamp values with nanosecond resolution can be displayed.

[marckleinebudde]

I think we're not allowed to change the output for the -l format. The tool canplayer relies on 6 decimal places:

candump any -f foo &
cangen vcan0 -I 2 -Li -Di -p 10 -g 100 -n 10
killall candump
canplayer -I ./foo

Otherwise this is a good enhancement for the hardware timestamps.

[hartkopp]

Yes. The 6 decimal places are fix in the CAN log file format for 20+ years now. And having the maximum rate of CAN frames on the CAN bus in mind we are already far beyond what is needed as a timestamp precision.

Of course everyone might use a higher precision from timespec inside a SocketCAN application - but we have to stay with 6 decimal places in the log file format.

[RikusW]

We are using MCP2518FD with 25ns resolution and are planning to correlate that to PTP time.
I've made the nanosecond format optional with microseconds being default.

[marckleinebudde]

@RikusW Can you elaborate on you use case a but more, I have some proof of concept patches that implement a PTP clock for the mcp251xfd driver.

[RikusW]

@marckleinebudde We will be using 8 CAN ports with all of them exactly in sync and will be doing the PTP part in userspace for now. I'm working on https://tsn.systems/en/products/basicsolution/tsn-basicsolution-octocan/
I had to remove timecounter_cyc2time since it introduces 100ms of jitter... currently using raw counter values.

[hartkopp]

I'm not generally against creating a new log file format flavor that supports a nanosecond resolution with a -N option.
But the highest impact to can-utils will be to make the consumers of those new log files , especially canplayer and log2asc aware of 9 digits and adapt themselves at runtime. These tools need to be converted until candump starts to provide such log files.

[RikusW]

For now I just need to be able to view nanosecond timestamps, transmit/replay ability could be done at a later time even.
Adding us/ns autodetection should be easy enough, I'll have a look at that a bit later.

[hartkopp]

Let's hold this PR in mind until it is completed with the other tools then.

[RikusW]

I've re-based onto the newest master and added us/ns auto detection.
canplayer and log2asc was tested and log2long buffer was enlarged.
A potential canplayer sscanf buffer overflow bug was also fixed.

[RikusW]

Squashed into a single commit

[RikusW]

Looks like libc broke in some test setups...

[marckleinebudde]

Looks like libc broke in some test setups...

yes - debian and ubuntu have some problems.

[RikusW]

Looks like libc broke in some test setups...

yes - debian and ubuntu have some problems.

At least it is not my patch that is the problem here...

[marckleinebudde]

ACK

[RikusW]

Any news on the broken distributions ?

[hartkopp]

I would prefer a comment that talks about nanoseconds instead of float.

[RikusW]

I kept this comment the same as in canplayer.c except for adding "or 9"

[hartkopp]

limiting the string reading is a good idea but is not in the scope of this patch.
Please create a separate patch with a separate commit message for it.

[RikusW]

Removed this, I can squash, or it can be squashed when merging ?

[RikusW]

Looks like the 2 failing checks is the distribution build system failing and unrelated to this patch ?

[marckleinebudde]

@hartkopp What do you think about this patch?

[hartkopp]

Sorry. Yes, I think it's a good work an can be merged.
Did you take a look yourself too?