linux-can
Use timespec
Use timespec instead of timeval so timestamp values with nanosecond resolution can be displayed.
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.
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.
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.
@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.
@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.
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.
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.
Let's hold this PR in mind until it is completed with the other tools then.
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.
Looks like libc broke in some test setups...
yes - debian and ubuntu have some problems.
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...
Looks like the 2 failing checks is the distribution build system failing and unrelated to this patch ?
Sorry. Yes, I think it's a good work an can be merged. Did you take a look yourself too?