-
Notifications
You must be signed in to change notification settings - Fork 304
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 the STM32Gxx chipset and add CANFD functionality to the driver #126
base: master
Are you sure you want to change the base?
Changes from all commits
ace1dcf
005e0ae
b529ef8
ed2982b
052bdec
6cd5fb4
6e5b893
a0b1d0f
25bc304
a809d4c
9ad9177
6682ebf
d7bace8
1efa7eb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -311,4 +311,7 @@ struct gs_host_frame_canfd { | |
u8 reserved; | ||
|
||
u8 data[64]; | ||
|
||
u32 timestamp_us; | ||
|
||
} __packed __aligned(4); |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -36,8 +36,13 @@ THE SOFTWARE. | |
|
||
/* Define these here so they can be referenced in other files */ | ||
|
||
#if defined(FDCAN1) | ||
#define CAN_DATA_MAX_PACKET_SIZE 64 /* Endpoint IN & OUT Packet size */ | ||
#define CAN_CMD_PACKET_SIZE 72 /* Control Endpoint Packet size */ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you sure this works? AFAIK USB 2 packets are limited to 64 bytes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ACK - This is wrong. Full Speed USB frames, this is 11 Mbit/s, that all devices use for now, is limited to 64 bytes. Some of the STM µC support USB high speed (480 Mbit/s) with an external PHY, but that's not supported for now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No...you are confusing bulk packet size with message packet size. The labeling of these parameters with "packet" may be confusing. Data payloads are automatically "chunked" by the USB stack. Since the control message to handle the data bitrate config (USBD_GS_CAN_btconst_extended) is larger than 64 bytes it is technically split into two "frames". The stack automatically takes care of this and the callback receives a 72 byte message. If this is not 72 then the "ep0_buf" will overflow in the "GS_USB_BREQ_DATA_BITTIMING" case in the "USBD_GS_CAN_EP0_RxReady" function and VERY bad things happen! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've learned though other USB projects to not assume anything based on the "64 byte" rule. Many stack implementations do not follow the USB 2.0 spec perfectly and you will run into buffer overruns or missed packets very easily. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @marckleinebudde I checked your branch and it is the correct method for implementation (as usual) :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To avoid confusion I've renamed
The There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's still untested :) |
||
#else | ||
#define CAN_DATA_MAX_PACKET_SIZE 32 /* Endpoint IN & OUT Packet size */ | ||
#define CAN_CMD_PACKET_SIZE 64 /* Control Endpoint Packet size */ | ||
#endif | ||
#define USB_CAN_CONFIG_DESC_SIZ 50 | ||
#define NUM_CAN_CHANNEL 1 | ||
#define USBD_GS_CAN_VENDOR_CODE 0x20 | ||
|
@@ -58,6 +63,9 @@ extern USBD_ClassTypeDef USBD_GS_CAN; | |
// RX FIFO size chosen according to reference manual RM0368 which suggests | ||
// using (largest packet size / 4) + 1 | ||
# define USB_RX_FIFO_SIZE ((256U / 4U) + 1U) | ||
#elif defined(STM32G0) | ||
# define USB_INTERFACE USB_DRD_FS | ||
# define USB_INTERRUPT USB_UCPD1_2_IRQn | ||
#endif | ||
|
||
uint8_t USBD_GS_CAN_Init(USBD_HandleTypeDef *pdev, queue_t *q_frame_pool, queue_t *q_from_host, led_data_t *leds); | ||
|
@@ -70,5 +78,5 @@ bool USBD_GS_CAN_CustomDeviceRequest(USBD_HandleTypeDef *pdev, USBD_SetupReqType | |
bool USBD_GS_CAN_CustomInterfaceRequest(USBD_HandleTypeDef *pdev, USBD_SetupReqTypedef *req); | ||
|
||
bool USBD_GS_CAN_DfuDetachRequested(USBD_HandleTypeDef *pdev); | ||
uint8_t USBD_GS_CAN_SendFrame(USBD_HandleTypeDef *pdev, struct gs_host_frame *frame); | ||
uint8_t USBD_GS_CAN_SendFrame(USBD_HandleTypeDef *pdev, struct GS_HOST_FRAME *frame); | ||
uint8_t USBD_GS_CAN_Transmit(USBD_HandleTypeDef *pdev, uint8_t *buf, uint16_t len); |
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 is probably best not to use FDCAN1 directly, but abstract it to STM_FDCAN_SUPPORT or something similar.
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've renamed this
CONFIG_CANFD
in my 97e4b1a#diff-f20ab3eb0041360bbad27bdb1173ada9c2818c430536c89ccd514d822c43a1ecL240 branch.We decided to not take this PR, but to clean it up and add multichannel support first. The multichannel work is happening in #139. It already contains cleanups for CAN-FD support.
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 did this to match many other implementation that use the HAL. Making an extra define adds an extra step. I used FDCAN1 in all areas where the HARDWARE needs to be configured (specific to the differences between the bxCAN and FDCAN registers). In another codebase I developed, though, I used "CANFD_SUPPORT" in areas that are non-HW dependent to turn on and off the USB driver level FD features since FDCAN can also run in classic mode if, lets say, a board was developed that is using an FDCAN uC but does not have the xcvr or desire to "report" CANFD support.