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>
Added asc2log.c to convert existing CANoe/CANalyser logfiles into socketcan
logfiles (with absolute and full qualified timestamps).
The date and the other settings (dec/hex absolute/relative) are taken from
the head of the ASC files.