The fixed values are given in hexadecimal letters only for the CAN-ID (-I)
and for the data (-D). The length information (-L) is a decimal value.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Currently, the -8 option allows DLCs greater than 8 in mix mode only.
Add the option to also generate such DLCs in increment
mode. e.g.: 'cangen -8 -Li can0'
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
As we have introduced struct can_frame *ccf = (struct can_frame *)&frame;
on top level we can remove this local assignment inside the if statement.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The variable 'frame' is declared on the stack and is reused at each
iteration of the while loop.
If not flushed, garbage data from the previous iteration of the loop
could remain causing unexpected behavior. This is the case in DLC
random mode: the field frame.len8_dlc is not cleared when the dlc is
exactly 8 and the len8_dlc value of the previous iteration will be
sent again.
This can be observed by running 'cangen -8 can0'. Once a frame of DLC
in the range 9..15 is generated, no more frames of DLC 8 show out in
the log.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Generating Classical CAN frames with raw DLC values greater than 8 is an
expert feature that should only be enabled on demand.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
ISO 11898-1 Chapter 8.4.2.3 defines a 4 bit data length code (DLC) table which
maps the DLC to the payload length of the CAN frame in bytes:
DLC -> payload length
0 .. 8 -> 0 .. 8
9 .. 15 -> 8
Although the DLC values 8 .. 15 in Classical CAN always result in a payload
length of 8 bytes these DLC values are transparently transmitted on the CAN
bus.
To access the raw DLC values 9 .. 15 the len8_dlc element is introduced, which
is only valid when the payload length 'len' is 8 and the DLC is greater than 8.
The extension for len8_dlc has been implemented for the Classic CAN frame
representation in the log file format and analogue for cansend.
cangen can now randomly generate Classic CAN DLC values from 0 .. 15.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
In commit https://github.com/linux-can/can-utils/commit/b153fe3f3591
("clang-tidy: sort includes alphabetically") the position of the "lib.h"
include has been moved in a way that struct canfd_frame has not been
defined anymore and lead to a warning when compiling cangen.c
This patch reverts that specific move and unifies the location of local
includes at the end of the include list.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The CAN FD frames support BTR and ESI as special flags. While BTR could
be generated by cangen the ESI bit could not be generated so far.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
added -c option for bursty output.
specify -c 100 to have 100 packets sent in burst before a gap.
use for example -p 1000 to avoid TX buffer full errors
GitHub user 'crossband' raised an issue regarding the strict-aliasing compiler
warning in his specific setup: https://github.com/linux-can/can-utils/issues/42
In fact memcpy() and memset() are a better solution than the former pointer
magics, so remove the issues and the compiler warning flag too.
Reported-by: crossband (https://github.com/crossband)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
This patch fixes a bug in cangen.c
Bug: When used with -m option, if a CAN FD frame with BRS option set is
sent, that flag never gets cleared for the subsequent frames.
Fix: Reset frame.flags at the start of iteration.
Signed-off-by: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>
Signed-off-by: Sven Schmitt <sven.schmitt@gmx.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sven Schmitt <sven.schmitt@gmx.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The computation of nanosleep times for the "-g" option (delay between sends)
overflows when more than 2100ms are given.
Signed-off-by: Konrad Anton <konrad.anton@awinia.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>
This way a user can specify a gap below 1ms. This is somehwat similar
to setting the gap to 0, but the ENOBUFS are greatly reduced, so a given
amount of CAN messages by -n is still usefull and useable.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
As pointed out by Andre Naujoks the pseudo random generator should be
initialized with a seed to prevend this ugly behaviour:
$ ./cangen vcan2 -v & ./cangen vcan1 -v
[1] 5995
vcan2 567#69.98.3C.64.73.48
vcan1 567#69.98.3C.64.73.48
vcan2 451#4A.94.E8.2A.EC.58.55.62
vcan1 451#4A.94.E8.2A.EC.58.55.62
vcan2 729#BA.58.1B.3D.AB.D7.7E.50
vcan1 729#BA.58.1B.3D.AB.D7.7E.50
(..)
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
- added sprint_* functions for CAN-frame output in lib.c / lib.h
- added comments / cosmetics
candump.c:
- removed support for the output in ASC representation (moved to log2asc.c)
- added option '-l' for logfile creation e.g. 'candump-2007-01-01_164123.log'
- added funtionality to terminate candump by pressing [ENTER] (not only ^C)
- added error frame support
- added color support even when reading from 'any'
- three different color levels (e.g. -c -c -c)
- making use if lib.c
cangen.c:
- CAN frames generator for testing purposes (e.g. on vcanx)
(nice when you're on vacancy at the baltic sea and have no real CAN source :)
log2long.c:
- convert compact CAN frame representation into user readable representation
log2asc.c:
- convert compact CAN frame logfile to ASC logfile for 3rd party CAN tools
Next step: Create a tool to replay candump logfiles.
Oliver Hartkopp
Vincent Mailhol
Rosen Penev
Rasmus Pedersen
Alexander Gerasiov
Yegor Yefremov
Ramesh Shanmugasundaram
Sven Schmitt
Konrad Anton
Marc Kleine-Budde