Details
-
Suggestion
-
Resolution: Done
-
P3: Somewhat important
-
5.8.0 Alpha
-
None
-
6441cf2dc3dd8654a12959cab6438721701c7cdb
Description
(This somewhat applies to the CAN Example too, but I think canbusutil is more affected now)
SocketCAN cansend give the following help:
Wrong CAN-frame format! Try:
<can_id>#{R|data} for CAN 2.0 frames
<can_id>##<flags>{data} for CAN FD frames
<can_id> can have 3 (SFF) or 8 (EFF) hex chars
{data} has 0..8 (0..64 CAN FD) ASCII hex-values (optionally separated by '.')
<flags> a single ASCII Hex value (0 .. F) which defines canfd_frame.flags
e.g. 5A1#11.2233.44556677.88 / 123#DEADBEEF / 5AA# / 123##1 / 213##311
1F334455#1122334455667788 / 123#R for remote transmission request.
They have a non-optional flags field for CAN FD right after ##
As I figured out, this flags for now affects two options:
#define CANFD_BRS 0x01 /* bit rate switch (second bitrate for payload data) */ #define CANFD_ESI 0x02 /* error state indicator of the transmitting node */
Even if these options are not used by canbusutil by now, we should consider them for later. I think we have two options now:
1. Also add a flags field in our payload data (would be compatible to cansend, but should be done before 5.8)
2. Add options to canbusutil like --bitrate-switch (could be easily added later)
If we go for option 1, I will prepare a patch soon.
Attachments
Issue Links
- depends on
-
QTBUG-56720 Improve CAN FD support
-
- Closed
-