CAN-FD support

[collin80]

Many people have asked about CAN-FD support. Technically EVTV even sells CAN-FD capable hardware and ESP32RET has support for setting the hardware to be able to send and receive FD frames. But, support for FD over the GVRET protocol does not exist and SavvyCAN has no idea what to do with FD frames should they suddenly be supported in the protocol. Currently FD is not heavily used but with every passing day it will become more and more common.

[MatinF]

Hi Collin,

Just wanted to add that we would be interested in CAN FD support for SavvyCAN at some point as well. Any updates on whether this might be possible to support?

[collin80]

The situation has advanced a bit since then. Technically the whole backend of SavvyCAN has transitioned over to the built-in CAN support in QT. These classes do support CAN-FD and so the backend of SavvyCAN technically can accept and store CAN-FD messages. However, it hasn't progressed past that yet. The chief problem is one of scale. 64 byte payloads are 8 times larger. So, how do I display that on the main screen? Should it span multiple lines or should all 64 (potential) bytes be on a single, very long line? Likewise for the rest of the program, on the screens that have byte graphs should the graphs really have upwards of 64 lines on them? For the 8x8 bitfield view found in places like FlowView should it be 8x64 or 16x32 or what? Should it have pages so you can view 8 bytes at at time and page through? Essentially I got stuck on not having decided these issues so progress halted.

It may be time for these things to be decided so that progress can continue. If you have any feedback on how to visualize upwards of 64 bytes in SavvyCAN I'm open to hearing it. Otherwise, I will try to start doing some experimenting to see what looks good and what might work best.

[MatinF]

Thanks for the insight Collin. I have listed some thoughts below:

Most important tools for CAN FD

Based on our user feedback, the most relevant tools for CAN FD initially would be to have support for the following:

1) Show CAN FD frames in the trace view (auto scroll, overwrite) This seems straightforward as this view already supports horizontal scrolling. When CAN FD frames are displayed, the Data column would expand accordingly, meaning the user might need to do a horizontal scroll to see everything. With some reduction to the width of the Timestamp and ASCII columns, there is already room for significantly longer payloads:

2) Show CAN FD frames in the custom Frame Sender view The same principle as above - the GUI already enables column width adjustment, so I'd simply suggest handling this as you already do today. I don't have strong preferences in regards to whether the payload is kept at a non-wrap single line or in e.g. two lines as in the picture, so whatever is simpler:

3) DBC decoding The DBC decoding can probably be updated to support CAN FD with very minor modifications.

The principle of CAN FD DBC decoding can be done in a fairly simplistic way. If a CAN FD frame payload has e.g. 20 bytes and the DBC specifies signals for e.g. the first 8 bytes, those would be translated as normal, with the rest of the payload ignored.

If a DBC specifies signals into the DLC >8 range, then again the same logic as usual applies. For example, a signal might be stored in bytes 15 to 16. The decoding process for this should be treated in the same way as if the signal was in bytes 2 and 3 of a normal CAN frame.

In practice there may be many signals in a single CAN FD frame, which can get a bit convoluted, but I think the trace view already handles this by enabling expansion of relevant rows for decoded data.

4) Graphical plots Once DBC decoding supports CAN FD, the graphical plots should more or less be the same as-is - users can copy signal details from a DBC and quickly plot specific signals. I do not see any FD restrictions/complexities in this regard.

Optional tools

It would be useful to have the playback functionality support CAN FD as well.

In practice, I think the CAN FD use cases for all the remaining tools will be very limited - and supporting FD on these might not be worth the effort. This includes all the "RE Tools" (except graphing, see above). Further, it includes the more niche sending tools like Fuzzing, UDS scanner and probably the scripting window.

Hope the above can be used as inputs! We expect to have a CAN FD interface for testing out functionality in the coming months, so we'd be interested in any updates on this.

[skpang]

The way PCAN-View is to use 4 lines to display the 64 bytes.

I like the colour icon to represent the FD and BRS flag.

To compose a frame there is a popup dialog box.

[MatinF]

Hi Collin, we now have a CAN FD interface that integrates with SavvyCAN in case you want us to test out a build with CAN FD support :-) enjoy the holidays as well!

[collin80]

I forgot about this issue and started another one just recently. The good news is that CAN-FD support is getting better. I still haven't implemented much of the above but now that CAN-FD is getting better supported I should be able to soon implement some of the suggestions here.