The ASC file provides an information whether the CAN frame is sent (Tx)
or received (Rx) on the local CAN node.
With the new '-d' option the generation of this information is disabled
for the log file generation to simplify the comparision of log files.
E.g. log1 -> asc -> log2 always created the T/R information in the log2
file which is then hard to compare to the log1 file which might not
have the T/R information at all.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Since using the %n feature the tmp1 buffer is only used for the handling
of the CAN identifier. So this buffer can be shrinked for that use case.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
TxRq messages are internal measurement messages that document the time of
a transmission request (to the CAN driver) to be checked against the real
transmission time, when the CAN message has been sent.
There is no such feature in the SocketCAN log format, so we detect this
tag but skip TxRq messages in the ASC log files.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Make sure the library functions to convert CAN frames into ASCII
represenation do not exceed the given buffer size. This also applies
to the long CAN frame output library function.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Move the curly brackets to the start of the next line to follow the
common coding style in can-utils.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Replace maxdlen parameter and use CANFD_FDF flags instead.
Since the CANFD_FDF flag has been introduced in can.h the struct canfd_frame
can be used for CAN CC and CAN FD frames as a dual-use data structure.
Remove the extra maxdlen parameter in library calls and only use the
CANFD_FDF flag to differentiate the two CAN CC/FD frames.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In commit 6799180bd0 ("log asc converter: support len8_dlc for Classical
CAN frames") the len8_dlc support was accidentally only implemented for
the new CANFD asc format. This patch adds len8_dlc support for the 'old'
Classical CAN asc format which in fact always supported len8_dlc.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
We need to check for different sscanf() failures and the number of read
items in the data frames. So move the simple check to the beginning.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The helper functions can_len2dlc and can_dlc2len are only relevant for
CAN FD data length code (DLC) conversion.
Update to latest in-kernel naming scheme:
can_dlc2len -> can_fd_dlc2len to get the payload length from the DLC
can_len2dlc -> can_fd_len2dlc to get the DLC from the payload length
Suggested-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CANFD format in asc logfiles can be used to describe Classical CAN
frame content too. As this CANFD format has two different elements to
transport the payload length and the 'raw data length code' the new
len8_dlc option now allows to support the full qualified conversion.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch adds a fourth string field in the can logfile format.
This new field contains the rx/tx direction information R/T as the
first entry (only one character separated from the CAN frame by space).
To generate the logfile format with this extra field candump has to be
called with the '-x' option for extra message infos,
e.g. 'candump -x -l can0' or 'candump -x -L can0'
log2asc and asc2log are extended to support the direction information
but still support the previous format without direction information.
The format extension does not affect legacy tools, e.g. the existing
canplayer ignores this extra information and does not need to be changed.
Therefore the existing logfiles remain valid and usable.
The extra message infos will be colon separated when there's need for
additional content beyond the rx/tx direction information, e.g. R:xx:yyy
Suggested-by: Pallavi Revanna https://github.com/brpallu
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As reported by Oleksij Rempel here
https://github.com/linux-can/can-utils/issues/233#issuecomment-674818935
the representation of timeval timestamps are signed values which leads to
negative values on 32 bit machines addressing the year 2038 unix sec counter
overflow.
Fix the issue on 32 bit systems by converting the timeval values to unsigned
ASCII value representations.
Fixes: https://github.com/linux-can/can-utils/issues/234
Reported-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
While strptime() does not support fractions of seconds in the date/time
string some new asc files support the milliseconds resolution.
When detecting this new format the msecs are retrieved by a separate
sscanf() invocation and added to the timeval's tv_usec element.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Add some more sanity checks and increase readability for the sscanf()
procedure to read a CANFD tagged line.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
strptime() does not support milliseconds but the latest ASC logfile
also provides a fraction of seconds, e.g.
date Fri May 8 08:49:04.052 pm 2020
Read the value into the year variable before parsing the real year.
We will therefore omit the milliseconds resolution for now.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
outfile is closed as well, so do this symmetrically for infile.
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This is a major upgrade of the basic tools to handle CAN FD frames.
The library to parse and print CAN frames and logfiles has been extended.
In detail:
asc2log.c | 5 +
candump.c | 24 ++++---
cangen.c | 172 +++++++++++++++++++++++++++++++++------------------
canlogserver.c | 28 +++++---
canplayer.c | 25 ++++---
cansend.c | 55 ++++++++++++----
lib.c | 189 ++++++++++++++++++++++++++++++++++++++-------------------
lib.h | 109 ++++++++++++++++++++++++--------
log2asc.c | 8 +-
log2long.c | 26 ++++++-
10 files changed, 440 insertions(+), 201 deletions(-)
asc2log.c / log2asc.c
- updates for new lib functions
- still can only handle CAN2.0 frames (no new info about ASC file layout)
log2long.c / canlogserver.c / canplayer.c
- updates for new lib functions to handle CAN FD
lib.h / lib.c
- reworked lib functions to handle CAN FD
- parse_canframe() now returns CAN_MTU and CANFD_MTU on success, 0 at failure
- added can_dlc2len() and can_len2dlc() helpers
- moved hexstring2candata to hexstring2data to support simple byte buffers
- in the long CAN frame representation use %03X/%08X instead of %3X/%8X
- introduced unified buffer size definitions for ASCII CAN frames
- updated documentation
cangen.c
- support CAN FD frames (added -f option to create CAN FD frames)
- added -m option ('mix') to create random extended / RTR / CAN FD frames
- fixed the 'fixed data' option which was zero'ing the payload by the time
- updated help text
candump.c
- support CAN FD frames (print, bridge, log)
- distinguish frame types by length info: [0] = CAN2.0 [00] = CAN FD frame
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Oliver Hartkopp
vuquangtrong
TyK
weichslgartner
Simon Tegelid
Rosen Penev
Alexander Gerasiov
Yegor Yefremov
Marc Kleine-Budde
Robert Schwebel