Wait for ENTER key to process next CAN frame from the log file.
As the new line is printed each time this approach doesn't win a
design price. But this feature is very uncommon and setting the
terminal into some raw mode to get the raw keyboard hits would
introduce a big code overhead to handle e.g. CTRL-C signals which
is a vital functionality for canplayer.
Link: https://github.com/linux-can/can-utils/issues/280
Suggested-by: https://github.com/nico0481
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Commit 9c2de072a0 ("asc2log: Correct usec overflow handling") fixed the
usec overflow handling which is contained in a similar code snippet in
canplayer too.
Cc: Simon Tegelid <simon.tegelid@niradynamics.se>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
It works on dev coredump data generated by the mcp251xfd driver in
case of failures, as well as on regmap based register dumps.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The mcp251x uses half of the external OSC rate as CAN clock. In real world
applications external OSC with a clock of 16MHz or 20MHz are used. Adjust the
example ref clocks accordingly.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
It makes no sense to print the mscan bit timing register values using the
sja1000 printf function.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The logfile format which is generated with '-l' and '-L' consists of an
absolute epoch timestamp. In some use cases (e.g. for documentation) a
zero relative timestamp can be useful which was only configurable with
the '-tz' option for the classic output.
'-tz' and '-ta' are now valid options for the logfile format.
Signed-off-by: Richard Young <code@richyoung.ca>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the
CAN_ISOTP socket is switched into functional addressing mode, where
only single frame (SF) protocol data units can be send on the specified
CAN interface and the given tp.tx_id after bind().
In opposite to normal and extended addressing this socket does not
register a CAN-ID for reception which would be needed for a 1-to-1
ISOTP connection with a segmented bi-directional data transfer.
The new option '-S' sets the CAN_ISOTP_SF_BROADCAST to test the option
with different length settings, e.g. link layer data lengths.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
When CAN_ISOTP_SF_BROADCAST is set in the CAN_ISOTP_OPTS flags the
CAN_ISOTP socket is switched into functional addressing mode, where
only single frame (SF) protocol data units can be send on the specified
CAN interface and the given tp.tx_id after bind().
Add the CAN_ISOTP_SF_BROADCAST define from Linux UAPI includes.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Using epoll_wait() instead of select() gives higher
performance for listening on multiple interfaces.
Additionally, the read order has a higher chance
to resemble the true temporal order.
select() gives implicit priority to the lower index socket.
Signed-off-by: Jörg Hohensohn <joerg.hohensohn@gmx.de>
Due to a wrong test to check for existing CAN-IDs in the snifftab
it was not possible to have the CAN-ID '0' in the list and displayed.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
The can_dlc value that is passed to the kernel is not sanitized in cangw
therefore we only update the help text and some comments in gw.h.
In the case that the CAN interface supports len8_dlc by setting
CAN_CTRLMODE_CC_LEN8_DLC the can-gw module can modify the full DLC value
range (0 .. 15) for Classic CAN frames.
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>
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>
A new option '-8' has been added to generate Classical CAN frames with
DLC codes from 0 .. 15.
Fixed and random mode implemented by Oliver Hartkopp.
Incremental DLC mode 'cangen -8 -Li can0' implemented by Vincent Mailhol.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr>
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
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 for the standard output for
candump where the raw DLC value is printed in 'unusual' curly braces {}.
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>
This patch fixes the following warning:
cansequence.c:232:3: warning: expression result unused [-Wunused-value]
(unsigned char)frame.data[0]++;
^ ~~~~~~~~~~~~~~~
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc Kleine-Budde
Oliver Hartkopp
Simon Tegelid
Egor Kurnev
Kristian Sloth Lauszus
Thomas Kopp
Richard Young
Jörg Hohensohn
Tim Gates
Rosen Penev