New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
can: isotp: Add CAN-FD support to ISO-TP #60323
Conversation
Just scrolled over it. Looks good at a first glance! You may extend the copyright notice, because it is a bigger extension of functionality. |
@alexanderwachter thanks! If you have time, could you please have a look over this RFC #59896 and give some feedback? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution, only got some minor comments.
May I ask you to move the changes related to CONFIG_ISOTP_ENABLE_TX_PADDING
and CONFIG_ISOTP_REQUIRE_RX_PADDING
into a dedicated commit? As far as I can see they are not related to CAN-FD support. This will make it easier to understand why the change was made in the future.
@martinjaeger Okay, will do |
@martinjaeger here is the padding fix PR #60661 |
ad26165
to
d5be785
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is ISO-TP via CAN-FD part of ISO 15765-2?
Yes, it's part of the third edition of the spec (from 2016). |
2ee0235
to
e0f1f01
Compare
Please ignore the first two commits. The will be removed through rebasing after #61732 is merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, @martinjaeger. I'd prefer if the last commit could be squashed into the previous commits to avoid the odd history, though.
@@ -1106,7 +1124,7 @@ void *isotp_conformance_setup(void) | |||
zassert_true(device_is_ready(can_dev), "CAN device not ready"); | |||
|
|||
ret = can_set_mode(can_dev, CAN_MODE_LOOPBACK | | |||
(IS_ENABLED(CONFIG_ISOTP_USE_CAN_FD) ? CAN_MODE_FD : 0)); | |||
(IS_ENABLED(CONFIG_CAN_FD_MODE) ? CAN_MODE_FD : 0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to fallback to classic CAN if the CAN controller does not support CAN-FD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case IS_ENABLED(CONFIG_CAN_FD_MODE)
should evaluate to 0
and FD would not be enabled.
Or do you have a case in mind where we'd have one controller with FD capabilities and one without on the same board/SOC, so that we have CONFIG_CAN_FD_MODE=y
even though one controller doesn't support it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CONFIG_CAN_FD_MODE
can be enabled whether the CAN controller supports CAN-FD or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's exactly how the test is run at the moment, e.g. with native_posix
. The first case is with default setup CONFIG_CAN_FD_MODE=n
(even though it would be supported) and the two other cases with extra config CONFIG_CAN_FD_MODE=y
and some different max data length settings.
Or maybe I misunderstand your question/request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The tests need to be able to run on any CAN controller, regardless of CONFIG_CAN_FD_MODE
being y
or n
and whether the CAN controller driver supports CAN-FD or not.
I'd suggest using can_get_capabilities()
to determine if CAN_MODE_FD
should be passed to can_set_mode()
. That does not require any #ifdef
on CONFIG_CAN_FD_MODE
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was slightly more complicated than just checking with can_get_capabilities
and applying the mode accordingly. Now we have the existing main
test suite, which is skipped if FD is enabled for a controller that does not have FD capabilities. To check that correct errors are returned in such cases, I added another test suite canfd_notsup.c
.
I added a new commit so that the authorship of the different changes is clear. But I'm fine with squashing it if @gramsay0 agrees. |
fb28a86
to
c31f938
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work!
c31f938
to
b8b7625
Compare
ISO-TP CAN-FD support can be enabled at runtime. Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com> Signed-off-by: Martin Jäger <martin@libre.solar>
Enable this sample to be used with CAN-FD Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Allow existing tests to run with CAN-FD. Add new CAN-FD specific tests. Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com> Signed-off-by: Martin Jäger <martin@libre.solar>
b8b7625
to
4b0e31f
Compare
I hope that all review comments are addressed now and unrelated CI failures are gone. The ISO-TP test suites and sample were successfully tested on the following boards:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. A couple of minor observations:
# | Case # | Controller type | Selected mode | Example board | | ||
# +--------+------------------------+----------------------+----------------+ | ||
# | 1 | Classical CAN only | CONFIG_CAN_FD_MODE=n | nucleo_f072 | | ||
# | 2 | Classical CAN only | CONFIG_CAN_FD_MODE=y | nucleo_f072 | | ||
# | 3 | Classical CAN + CAN-FD | CONFIG_CAN_FD_MODE=n | native_posix | | ||
# | 4 | Classical CAN + CAN-FD | CONFIG_CAN_FD_MODE=y | native_posix | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These cases significantly increase the time required for running the ISO-TP conformance test suite on real hardware. Can the tests be optimized in time somehow?
Example of time spent running this test suite on five random boards on my desk:
INFO - 6/35 frdm_k64f tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 8.151s)
INFO - 7/35 lpcxpresso55s36 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 001069887263, 14.602s)
INFO - 8/35 stm32f3_disco tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 066EFF555052836687113518, 4.123s)
INFO - 9/35 mimxrt1060_evkb tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 33.479s)
INFO - 10/35 nucleo_g474re tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0041001B3438510B34313939, 13.539s)
INFO - 11/35 frdm_k64f tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 10.311s)
INFO - 12/35 lpcxpresso55s36 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 001069887263, 11.119s)
INFO - 13/35 stm32f3_disco tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 066EFF555052836687113518, 3.966s)
INFO - 14/35 mimxrt1060_evkb tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 37.112s)
INFO - 15/35 nucleo_g474re tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0041001B3438510B34313939, 13.679s)
INFO - 16/35 frdm_k64f tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 16.917s)
INFO - 17/35 lpcxpresso55s36 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 001069887263, 10.552s)
INFO - 18/35 stm32f3_disco tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 066EFF555052836687113518, 14.584s)
INFO - 19/35 mimxrt1060_evkb tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 33.130s)
INFO - 20/35 nucleo_g474re tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0041001B3438510B34313939, 14.217s)
INFO - 21/35 frdm_k64f tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 17.851s)
INFO - 22/35 lpcxpresso55s36 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 001069887263, 11.913s)
INFO - 23/35 mimxrt1060_evkb tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 31.035s)
INFO - 24/35 stm32f3_disco tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 066EFF555052836687113518, 14.670s)
INFO - 25/35 nucleo_g474re tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0041001B3438510B34313939, 14.054s)
Do we really need to test with different TX_DLs on all boards or could a simple unit-like test (e.g. on POSIX) be sufficient for the different configurations? I mean, these tests validate the protocol implementation, not as much as the protocol interaction with the particular CAN controller?
Another option could be to tag some of these tests as "slow".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There will be some more upcoming ISO-TP updates. Let's leave the optimization of test time for a future PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
f412a17
4b0e31f
to
f412a17
Compare
Fixed the typo in the test naming identified by @henrikbrixandersen. Please re-approve once again, @alexanderwachter . Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approval and thanks for the parts of the work @gramsay0 and @dale-herman have done. Also thanks for all reviews.
Add a test to check error codes if attempting to use ISO-TP with CAN FD mode even though the controller supports classical CAN only. Signed-off-by: Martin Jäger <martin@libre.solar>
Even though it was leading to the same result, the function should use its parameter and not the global variable for desired frames. Signed-off-by: Martin Jäger <martin@libre.solar>
f412a17
to
c108c4d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Martin!
Thanks @dale-herman for doing most of the work