Add CAN FD

[jlpoltrack]

Somewhat academic.

Had to use 160 MHz Sysclock / 80 MHz fdcan peripheral clock to play nicely with ArduPilot.

Tested on Matek H743 WLITE + mR900 TD.

Debug:

Setup:

[olliw42]

@jlpoltrack
this is very cool, but I think we first would have to ensure normal CAN working and get into the code
one question at this point:
you say FD needs 160MHz, and here

mLRS/mLRS/rx-matek-mr900-td30-g474ce/Core/Src/main.cpp

Lines 131 to 135 in 56a28c6

	// note: 170 MHz SYSCLK with 85 MHz FDCAN was tested but causes excessive stuff errors
	// and timing incompatibilities with ArduPilot at CAN FD 5 Mbps. ArduPilot uses 80 MHz
	// FDCAN clock, and the sample point / TDC timing differences at 85 MHz are problematic.
	// 170 MHz FDCAN clock only supports 1 Mbps data rate (same as nominal), not useful for FD.
	// Stick with 160 MHz SYSCLK / 80 MHz FDCAN for reliable CAN FD operation.

you explain why. I'm somewhat puzzled however. When I did the CAN support I initially had massive issues, and as a result I went in much detail into the timing things, also because nearly all codes out there seem to use 160MHz, but concluded - from the datasheet - that that there is no reason not to use 170 MHz. When you say "FD/5MB is not supported with 170 MHz", is this based on empirical evidence of issues, or some "hard" facts?

Did you ever see also the issues I had reported? I.e., did you ever try to reproduce for the conditions I had seen them?

[jlpoltrack]

ensure normal CAN working

I guess you mean on the AP side with that lost message issue. One note is that this branch also does Classic CAN until CAN FD is detected, so can do with the same firmware:

• Classic CAN at 1 Mbps
• CAN FD at 5 Mbps (configured in the device hal, Matek hardware has 5 Mbps transceivers)

also because nearly all codes out there seem to use 160MHz, but concluded - from the datasheet - that that there is no reason not to use 170 MHz

From what I gathered reading around, the different sample points caused by using 170 MHz cause all kinds of issues between the nodes at CAN FD speeds. I couldn't even get 2 Mbps to work without a lot of Bit1 and TEC errors (you can see all of the debugging added to try and understand what was going on). After about a day of fiddling around with sampling points and TDCO I switched to the 160 MHz sysclock with AP's 80 MHz CAN FD timings and things instantly worked.

[olliw42]

so is the argument that with 170MHz/5Mbps the sampling points cannot be set to work with those used for 160MHz/5Mbps ??
I find it a bit puzzling that it would be that sensitive to the sampling points ... doesn't exactly give a lot of confidence.
Or is it that the sampling points canot be adjusted with sufficient resolution?
That is, I guess, my question is, why is "the different sample points caused by using 170 MHz" a true statement, i.e., why do the sampling points have to be different.

It makes me wonder if things would also work more stable for 1Mbps if one would use 160MHz, i.e., if the issues I see are due to that.

I just would like to understand the situation better, empirical evidence is great but not satisfying ...

[jlpoltrack]

That is, I guess, my question is, why is "the different sample points caused by using 170 MHz" a true statement, i.e., why do the sampling points have to be different.

The time quanta (tq) is a function of the clock and bitrate, so they can't precisely align. Some of the calcs are noted in the g4 driver, e.g.

Note that 85 MHz can't support 2 or 4 Mbps due to this limitation as they do not divide cleanly.