Hi Vincent,
On 24.10.20 15:00, Oliver Hartkopp wrote:
On 24.10.20 14:00, Vincent MAILHOL wrote:
* Set up two channels can0 and can1 and connected those to the same
bus.
* Ran 'cangen can0' and 'candump any' simultaneously.
Results of candump:
can0 539 [8] 05 21 8C 5C F7 B0 7C 69
can1 539 [8] 05 21 8C 5C F7 B0 7C 69
can0 47E [1] 53
can1 47E [1] 53
can0 317 [6] E5 00 B5 73 66 CF
can1 317 [6] E5 00 B5 73 66 CF
can0 524 [E] 64 C3 B0 6E 55 7A D7 2E
can1 524 [E] 64 C3 B0 6E 55 7A D7 2E
can0 39C [D] 63 18 96 69 F6 7A AB 36
can1 39C [D] 63 18 96 69 F6 7A AB 36
can0 60D [F] F2 C6 B6 1D 80 FB BC 7E
can1 60D [F] F2 C6 B6 1D 80 FB BC 7E
can0 5DD [9] 7E 55 56 5B C0 23 B0 53
can1 5DD [9] 7E 55 56 5B C0 23 B0 53
can0 573 [E] 20 8E A3 31 1B 54 B2 16
can1 573 [E] 20 8E A3 31 1B 54 B2 16
can0 470 [3] 31 9C 06
can1 470 [3] 31 9C 06
can0 465 [4] 93 75 A2 08
can1 465 [4] 93 75 A2 08
Works fine :-)
I'm not really sure about the view of Classical CAN DLCs in this 'long'
candump representation.
There are people that use this format as base for further processing -
instead of the logfile format m(
So it may be a bad decision to put the DLC value in the length position
here.
I changed the logfile format in a backward compatible way and therefore
the cansend command line format too:
(1604004658.444168) vcan0 2C0##02643
(1604004658.494492) vcan0 615#R8_9
(1604004658.645395) vcan0 6FF#
(1604004658.695682) vcan0 623##318F88F7043C0
(1604004658.746046) vcan0 63A##28D1F37
(1604004658.796214) vcan0 1117DEA5##0BC281D711098
(1604004658.846397) vcan0 1490B893#R8_F
(1604004658.896585) vcan0 1F494EC8##39C47E2
(1604004658.947142) vcan0 1D1EC448#3DC1C81345D7ED7E_D
(1604004658.997689) vcan0 1C8661BB##14DEA7568D459160D
(1604004659.047851) vcan0 2D8#AFE0546E6522130D_E
(1604004659.098216) vcan0 1596E833##3E6789514EF10B466E6789514EF10B466
My can-utils len8_dlc test setup is here:
https://github.com/hartkopp/can-utils
Feel free to do some tests, e.g. with cangen, candump, canplayer.
Feedback is appreciated.
Best,
Oliver
