Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Document CAN-FD support #79

Closed
wants to merge 4 commits into from
Closed

Document CAN-FD support #79

wants to merge 4 commits into from

Conversation

marckleinebudde
Copy link
Contributor

This PR documents the CAN-FD support that has been added to the gs_usb Linux driver and will hit mainline soon.

This paves the road for other CAN-FD capable STM32 µC to implement CAN-FD support to their firmware.

@marckleinebudde
gs_usb.h: document used GS_CAN_MODE_* bits
f2da887 
The bits in GS_CAN_MODE_ correspond to the bits in GS_CAN_FEATURE_*.
This means the bits 5 and 6 of GS_CAN_MODE_ are not "free", document
this by adding a comment to the corresponding GS_CAN_FEATURE_*.
@marckleinebudde marckleinebudde mentioned this pull request Dec 30, 2021
Closed
@fenugrec
Copy link
Collaborator

Cool ! A few questions / points :

  • as I understand, originally the gs_usb kernel module was specifically for one kind of hardware (unobtainium now ?), and candlelight & others just were built to be as compatible as possible with gs_usb... i.e. the kernel module was our reference implementation.
  • is the "original hardware for gs_usb" still relevant or is it more or less now defined by what we here, and you guys at cantact, are doing ?
  • nitpick : your commit messages contain excellent explanations and documentation - would it be possible to have that in the code instead / as well ? Especially for the GS_CAN_MODE_* bits and LPC546xx quirks, as those are definitely not obvious from just looking at the diff.

I'm totally in favour of doing our best to keep candlelight and other firmwares "compatible", as much as possible. TBH I'm really not up to date on what cantact is doing though.

@marckleinebudde
Copy link
Contributor Author

Cool ! A few questions / points :

  • as I understand, originally the gs_usb kernel module was specifically for one kind of hardware (unobtainium now ?), and candlelight & others just were built to be as compatible as possible with gs_usb... i.e. the kernel module was our reference implementation.

ACK - The company ("Geschwister Schneider") who brought the driver mainline and sold the HW is gone now.

  • is the "original hardware for gs_usb" still relevant or is it more or less now defined by what we here, and you guys at cantact, are doing ?

As the GS company is gone now, I consider the candlelight firmware and the Linux kernel driver as the reference implementation.

  • nitpick : your commit messages contain excellent explanations and documentation - would it be possible to have that in the code instead / as well ? Especially for the GS_CAN_MODE_* bits and LPC546xx quirks, as those are definitely not obvious from just looking at the diff.

I'll add some documentation to the code.

I'm totally in favour of doing our best to keep candlelight and other firmwares "compatible", as much as possible. TBH I'm really not up to date on what cantact is doing though.

@ericevenchick designed a dual CAN-FD capable board, firmware and Linux driver. Several people are now involved to bring this Linux driver mainline. He has extended the USB protocol and there are I think 2..3 other projects implementing it.

@marckleinebudde
gs_usb.h: introduce CAN-FD support
cddd7e6 
The CANtact FD and other devices implement a gs-usb compatible USB
protocol. The protocol has been extended to support CAN-FD and the
changes on the Linux gs_usb driver will be mainlined soon.

This patch adds the new GS_CAN_MODE_*, GS_CAN_FEATURE_*,
GS_USB_BREQ_DATA_BITTIMING, and GS_CAN_FLAG_* bits as well as struct
gs_host_frame_canfd to the candlelight driver.

This is mainly for documentation purpose, as the STM32F042 and
STM32F072 don't support CAN-FD. But there are some ports to CAN-FD
capable STM32 µC that can make use of these definitions.

[1] linklayer/gs_usb_fd#2
@marckleinebudde
gs_usb.h: document GS_CAN_FEATURE_REQ_USB_QUIRK_LPC546XX
6080e4c 
The documents a workaround for a NXP chip errata on LPC546xx
controllers (Errata sheet LPC546xx / USB.15).

According to the document corruption can occur when the following
conditions are met:
* A TX (IN) transfer happens after a RX (OUT) transfer.
* The RX (OUT) transfer length is 4 + N * 16 (N >= 0) bytes.

Even though the struct gs_host_frame has a size of 76 bytes for a FD
frame, which does not apply to the above rule, corruption could be
seen.

Adding a dummy byte to break the second condition also on transfer
lengths with 4 + N * 8 bytes reliably circumvents USB transfer data
corruption.

The firmware can now request this quirk by setting
GS_CAN_FEATURE_REQ_USB_QUIRK_LPC546XX.
@marckleinebudde
gs_usb.h: document GS_CAN_FEATURE_BT_CONST_EXT and GS_USB_BREQ_BT_CON…
592659a 
…ST_EXT

Some CAN-FD capable controllers have different bittiming constants for
arbitration phase and data phase to reach maximum performance at
higher speeds.
@marckleinebudde
Copy link
Contributor Author

Good that I did the documentation bits, I found an overlap in the new GS_USB_BREQ_ values 😭. We have to sort this out on our side. I've pushed the updated branch to this PR.

@fenugrec
Copy link
Collaborator

fenugrec commented Dec 31, 2021 •
edited
Loading

We have to sort this out on our side.

Ok. As far as this PR is concerned, ready to merge or should I wait a few days to be sure ?

@marckleinebudde
Copy link
Contributor Author

Due to the discovered overlap, let's wait until @pfink-christ in the linklayer/gs_usb_fd#2 thread gives his OK.

@fenugrec fenugrec added the on hold needs work from submittter label Jan 9, 2022
@marckleinebudde
Copy link
Contributor Author

Please go ahead and merge. We have the go by @pfink-christ:
linklayer/gs_usb_fd#2 (comment)

@fenugrec fenugrec removed the on hold needs work from submittter label Jan 12, 2022
@fenugrec
Copy link
Collaborator

rebased+merged in b549cb7 . Thanks!

@fenugrec fenugrec closed this Jan 12, 2022
@marckleinebudde marckleinebudde deleted the document-can-fd-support branch January 13, 2022 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@marckleinebudde @fenugrec