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 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>
The display of Classical CAN raw DLC values is an expert feature which is
not enabled by default to not break toolchains that use the candump
standard output for further processing. (N.B. using the log file format and
the functions from lib.h/lib.c provide convenient CAN frame conversions)
After enabling the raw DLC for Classical CAN with the '-8' option the raw
DLC value is printed in 'unusual' curly braces {}.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
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>
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. As the struct can_frame only provides a 'len' element (formerly 'can_dlc')
which contains the plain payload length ( 0 .. 8 ) of the CAN frame, the raw
DLC is not visible to the application programmer, e.g. for testing use-cases.
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 len8_dlc element is filled by the CAN interface driver and used for CAN
frame creation by the CAN driver when the CAN_CTRLMODE_CC_LEN8_DLC flag is
supported by the driver and enabled via netlink configuration interface.
Reported-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The PTX flavour canutils have a useful utility for generating a sequence of CAN
frames with an incrementing payload and checking such a sequence for missed and
reordered frames.
Recently, it has helped finding a regression in the kernel pfifo_fast qdisc,
which led to reordered frames.
To bring the utility to a greater audience, import the current state, including
its history, into the linux-can set of utilities.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch fixes the indention, which was broken while renaming the j1939
tools.
Fixes: 8106214b55 ("Rename j* to j1939\1")
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Without this, the extended identifier flag was not important when
filtering on CAN frames. Add this to mask to only receive the frame type
we want to recieve.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
- added poll support if sender
- add cmd line option for can_id
- setup canfilter to disable receiving in sender mode
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Oliver Hartkopp
Vincent Mailhol
Marc Kleine-Budde