-
Notifications
You must be signed in to change notification settings - Fork 331
add support for multichannel and CAN-FD #139
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
base: master
Are you sure you want to change the base?
Conversation
src/main.c
Outdated
struct gs_host_frame *msgbuf = calloc(CAN_QUEUE_SIZE, sizeof(struct gs_host_frame)); | ||
assert_basic(msgbuf); | ||
can_init(channel, CAN_INTERFACE); | ||
can_disable(channel); | ||
|
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.
Should we come up with a better way of handling the init? Rather have some type of indexed table with [channel][CAN_INTERFACE] instead of having to add defines here for each new channel.
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.
You mean a read only array of structs, with a struct describing the HW configuration of a single channel. Sounds good. Which information do we need per channel?
memcpy(¶m_u32, hcan->ep0_buf, sizeof(param_u32)); | ||
if (set_term(req->wValue, param_u32) == GS_CAN_TERMINATION_UNSUPPORTED) { | ||
USBD_CtlError(pdev, req); | ||
} |
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.
Termination GPIO is channel based. Should we stub that out here as part of the multichannel change?
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.
Should come after we thought about per channel configuration.
d1e0c57
to
203cfac
Compare
It's not yet stable, |
203cfac
to
bb32688
Compare
changes:
|
bb32688
to
f3dbeec
Compare
changes:
|
f3dbeec
to
0ec5d41
Compare
changes:
|
0ec5d41
to
adfa1f1
Compare
adfa1f1
to
7a9e176
Compare
7a9e176
to
dba4baa
Compare
FYI: @lichtfeind will now work on STM32G0 support. |
015b9a7
to
eef6f97
Compare
eef6f97
to
ca78d19
Compare
fdec4bf
to
343714f
Compare
25726c4
to
eb15d9d
Compare
99d5695
to
7f6a8b2
Compare
Hi all Can you pls clarify if this has finally been merged to main_dev - or - if we need to get code from [marckleinebudde]'s (https://github.com/marckleinebudde) fork? The discussion seems to indicate support for the G0 is mature, but it's unclear if/what's been merged to this main branch. Thanks, |
It's not mainline. Please use https://github.com/marckleinebudde/candleLight_fw/tree/multichannel for now |
Hi there! Multichannel means that this will rise can0 and can1 interfaces? |
This means on STM32G0B1 devices you have 2 interfaces, |
Add code to support the M_CAN core found on the newer STM32 devices. Co-developed-by: Ryan Edwards <ryan.edwards@gmail.com> Co-developed-by: Jonas Martin <j.martin@pengutronix.de> Co-developed-by: Venelin Efremov <ghent360@iqury.us> Co-developed-by: Phil Greenland <phil@beamconnectivity.com> Co-developed-by: Marc Kleine-Budde <mkl@pengutronix.de>
267022a
to
7fb37e7
Compare
This PR should add multichannel and CAN-FD support. Currently it's WIP.