Most SocketCAN userspace tools (like cansend) recognize the EFF by the
stringlength of the given CAN-ID: 3 -> SFF , 8 -> EFF.
This was missing in the candump filter definition and therefore the
values had to be specified with the CAN_EFF_FLAG set in the value, e.g.
92345678 for the extended CAN-ID 12345678 - this was not really nice.
Now the filtersets for extended frames can be specified as expected:
12345678:1FFFFFFF to filter for only 12345678 extended CAN-ID
000000AA:1FFFFFFF to filter for only AA extended CAN-ID.
unsigned char asc2nibble(char c);
int hexstring2candata(char *arg, struct can_frame *cf);
(see documentation in lib.h)
As prerequsite to fix the commandline interface of cangen.
is very nice when you don't have a RTC and your systemtime is somewhere
in the 1970's :)
Added a new commandline option to skip timestamp jumps greater than x
seconds to allow to concatenate different logfiles that replay
constantly and not waiting for the absolute timestamp offsets.
via serial (or quasi serial via USB) lines.
This driver is partly derived from linux/net/driver/slip.c and uses a new
tty line discipline (N_SLCAN) analogue to N_SLIP to encapsulate can_frames
sent to a slc* netdevice for the serial line and vice versa.
As only the sending and receiving of can_frames is implemented, this driver
should work with the (serial/USB) CAN hardware from:
> www.canusb.com / www.can232.com / www.mictronic.com / www.canhack.de <
The sending and receiving frames format is pretty common. The other settings
and the 'open' command 'O' of the specific adapters may be set with a
terminal programm (like minicom) before switching the CAN data stream to
the slc* netdevice using the slcan_attach userspace tool.
Feel free to send patches / extensions to slcan.c / slcan_attach.c :)
ps. There had been no performances measurements until now. As long as the
data fit's through the 'serial' line it works obviously well. The slcan-driver
nor the Linux network layer will definitely have no problems to process
the received data. Remember the 'low-cost' hardware approach. We'll see ...
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.
Now you can forward CAN frames e.g. via netcat with candump and canplayer:
candump can0 can1 -L | canplayer vcan3=can0 vcan0=can1 -t
OK, maybe it would be reasonable to write a short program for this application.
But for some tests all this can be done with existing commandline tools.
In addition the filtering possibilities of candump can be used here.
Added new tool 'canplayer' to replay logfiles generated by candump -l .
Features of canplayer:
- Input from stdin or file.
- throttling of the replay to get nearly original timestamps / message gaps
- mapping and selection of CAN interfaces (assignment)
e.g. canplay -I logfile vcan2=can2 vcan0=can1 can2=can3
means: send frames received on can1 in the logfile to vcan0 and so on ...
- if no assignment is made the original interfaces are used for replay
- handling of multiple CAN interfaces simultaneously (if in logfile)
- option: throttle disable (do not look on timestamps => very FAST replay!)
- option: change the 'sleep time' in milli seconds
Remarks:
canplayer uses nanosleep() for throttling which means that the resolution of
the canplayer is about 1ms (Kernel HZ = 1000) or 10ms (Kernel HZ = 100).
After each nanosleep() all the CAN frames are send that had to be transmitted
until the timestamp at the current time. Giving e.g. the option '-g 500' for
500ms let's you see the behaviour. Using nanosleep() makes canplay a very
performant tool with minimum CPU load.
To transfer CAN frames over a TCP/IP network you may now say something like:
candump -> netcat -> netcat -> canplayer
Oliver Hartkopp
Urs Thuermann