Details
-
Bug
-
Resolution: Done
-
P2: Important
-
5.6.0
-
None
-
Linux
-
55ad040de1ac6a33b4f2efe29038e97e8d43dbc2 4cd1146041e788ceb1d8fb283f5257e743579843 0317755dc0bc3d8bebe838f0715c14ed63173f38 aa4222f350a59ad2d90f14a1dfb88f83bf2d2c78
Description
Both the CAN Example and the canutil have problems displaying incoming frames.
- CAN Example
- Silently drops messages with DLC = 0
- Does not distinguish between messages with Std. (11 bit) and Ext. ID (29 bit)
- canutil
- Does not distinguish between messages with Std. (11 bit) and Ext. ID (29 bit)
Technical background: CAN-Messages with the "Extended" flag are transmitted with 29 bit identifier, even if the ID would fit into a Standard frame. This is how candump and canutils displays the message:
candump: fills with zeros to show this is an extended frame
can0 000007FF [0]
canutil: the information about extended ID is gone
Id: 7ff bytes: 0 data:
Expeced behavior:
- Messages with Extended ID should be marked so
- Messages with DLC = 0 should be displayed
- Remote request could be displayed like candump does:
can0 123 [0] remote request can0 000007FF [8] remote request
- canutil displays remote requests with DLC > 0 like this, which is wrong as the message does not contain data:
RTR: Id: 7ff bytes: 8 data: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
- candump also pretty aligns the messages in a table:
can0 00000800 [8] 11 22 33 44 55 66 77 88 can0 004 [1] C8 can0 004 [1] CC can0 123 [0] remote request can0 123 [0] can0 000007FF [0] can0 000007FF [8] remote request