-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Add support for NXP S32 CAN driver #52450
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
Add support for NXP S32 CAN driver #52450
Conversation
henrikbrixandersen
left a comment
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.
@congnguyenhuu Thank you for your contribution. However, please split the suggested API change for the CAN RX filters into a separate PR so that it can be reviewed stand-alone (the current approach will cause all other boards to fail as they do not implement filtering of FD frames). You can put this PR as draft until a decision regarding the API change has been made and merged.
|
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
include/zephyr/drivers/can.h
Outdated
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 am still not 100% sold on this change.
We need to document that the full width of the timestamp field is not used by all drivers; some timestamps will wrap around at 32 bit. You also need to look into the format specifiers used (e.g. in the CAN shell). They likely need updating to match the 64 bit size?
Another option could be to mask the upper 32 bit of the timestamp on NXP CANXL, as this seems to be the only device supporting 64 bit timestamps for now?
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 still keep change timestamp 64bit. I updated document and related files.
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 have tried to survey the market for other CAN controllers supporting 64 bit timestamps, but came up short. Please leave out this change for now.
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.
Before you said that there are some CAN controllers supporting 32 bits timestamp, So I updated to support that.
What do you think that?
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 am sorry, my initial comment said 32 bit, where I meant the existing 16 bits. Please leave out any changes to the timestamp counter bit size from this PR and - if deemed needed - submit a separate PR for this after the S32 CAN driver PR goes in.
drivers/can/can_nxp_s32_canxl.c
Outdated
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.
How should this error be handled?
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 seems my error msg is not correct with which handling here. In this handler called Canexcel_Ip_ReceiveFD to check MB empty (complete receive msg)to ready for receiving next msg. the msg should be MB %d is not ready for receiving next message
drivers/can/can_nxp_s32_canxl.c
Outdated
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.
If so, it needs to be enabled in listen-only mode so it does not disturb the bus with ACKs/error frames until explicitly enabled by calling can_start().
|
@henrikbrixandersen, thank you for your feedback and review on this PR. Can you highlight which items are still considered a blocker so the author can address them? |
manuargue
left a comment
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.
Just a minor request in the docs
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.
Hi @henrikbrixandersen, thanks for the thoroughly review. Could you please have another look to the changes to see if there are still unresolved comments? We would like to have this feature included in v3.4 if possible. We can also consider having a first working version merged, and address further improvements with a follow up PR.
|
@henrikbrixandersen can you return to this PR to determine if your change requests have been addressed? |
include/zephyr/drivers/can.h
Outdated
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 have tried to survey the market for other CAN controllers supporting 64 bit timestamps, but came up short. Please leave out this change for now.
drivers/can/can_nxp_s32_canxl.c
Outdated
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.
So, does setting .retransmission = 0 mean no retransmissions? If so, it is a violation of the Zephyr can_send() API when CAN_MODE_ONE_SHOT is not set.
include/zephyr/drivers/can.h
Outdated
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.
Please leave these additions out.
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 left out the update for support counter statistic
drivers/can/can_nxp_s32_canxl.c
Outdated
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.
Please point me to where this is done?
|
@henrikbrixandersen Thank for revisiting this PR. I addressed all comment. |
henrikbrixandersen
left a comment
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.
Please leave out the timestamp changes, at least for now, and I think we're good to go.
This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral. CAN protocol supporting: - CAN classic - CAN FD Remote transmission request is not supported as this feature is not available on NXP S32 CANXL HAL. Signed-off-by: Cong Nguyen Huu <[email protected]>
Enable CAN instances on s32z270dc2_r52 boards Signed-off-by: Cong Nguyen Huu <[email protected]>
Add CAN document to the list of supported features Signed-off-by: Cong Nguyen Huu <[email protected]>
|
@henrikbrixandersen I left out the timestamp change. Do you have any blocker for PR? |
henrikbrixandersen
left a comment
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.
Thank you, looks good - and thank you for your patience with the review process!
|
@congnguyenhuu please remove the west.yml from your PR. The HAL change was merged a while ago and is part of the current Zephyr west.yml. |
|
@dleach02 I removed it as soon as the HAL change was merged. |
This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral. CAN protocol supporting:
Currently, remote transmission request is not supported as this feature is not available on NXP S32 CANXL HAL.
Updates in NXP HAL: zephyrproject-rtos/hal_nxp#206