search

candle-usb / candleLight_fw

gs_usb compatible firmware for candleLight, cantact and canable
Other
659 stars 290 forks source link

Supporting different processor families #67

Open normaldotcom opened 3 years ago

normaldotcom commented 3 years ago

Hey! I'm working on porting candlelight firmware to another processor of a different family (specifically the G431).

I have adapted the existing cmake build system to compile for multiple targets of different processor types/families, pulling in the correct CMSIS, HAL libraries, startup files, linker files, etc for each. It's a bit rough around the edges at the moment, but it does work!

Is there any interest in mainlining support for processors from other families using cmake? It would be great to merge in this work once I have it cleaned up a bit more. I was initially planning on forking for the G431 processor, but keeping a common codebase between processors would be fantastic.

fenugrec commented 3 years ago

Agreed about limiting the # of forks... would really be nice to keep a solid upstream here. I wish I had time to be a more productive maintainer.

I was glad to move to cmake, this should be exactly the type of thing it does well. That said, it sounds like a large changeset ... I'm just about drowning in projects in general and this bloody issue #58 and PR #62 are driving me insane.

So... if you think it's possible to make this happen one tiny , bite-size PR at a time, it could work. The only thing I can promise : there is a very real risk that I won't have time to review/test/merge !

Does G431 at least use the same version of the bxcan periph ?

normaldotcom commented 3 years ago

I'll do my best to keep the PRs as concise as possible. I'll be testing quite extensively on my end once I get further along. I've been meaning to try and replicate #58 as well but haven't gotten around to it yet.

The caveat with the G431 is that it uses the new fdcan peripheral, not the bxcan peripheral. The new peripheral is great, but has a completely different register set. I'm still working on getting all functionality ported over (classic CAN only), but it does potentially open the door to fdcan support in the future.

fritz-net commented 3 years ago

canfd would be nice, but does the gs_usb driver support setting up can fd?

mattiasbus commented 3 years ago

@normaldotcom @fritz-net I am interrested in using the STM32G491CC or STM32G0C1VE for CAN FD to USB. Can you share anything about the effort of adapting the firmware and Linux driver?

fritz-net commented 3 years ago

@mattiasbus no, sorry I can't.

I think the gs_usb driver is part of the main linux repo, I don't know how merging new changes there would work. Additionally I don't know to make the fd version compatible with the old one.

However I think programming effort is not the issue, I think keeping everything compatible and the multiarchitecture part for this repo are the challenges (not to hard)

EDIT: I don't know how libusb works with linux. Maybe this is like win10 and you could totally bypass the OS drivers and write them within your software -> no issues with driver compatibility nor merge issues (however if there is a good solution I think this should be in the main driver - to support other tools too)

fenugrec commented 3 years ago

@fritz-net , on linux the nice thing with the gs_usb driver is that the device appears as another socketcan device (i.e. can0 etc) which I don't think is possible with userland libusb unfortunately.

I'm not sure what the options are for eventual canFD support, if gs_usb doesn't support it... since we're "piggybacking" on that driver anyway (i.e. candlelight isn't the main device type targetted by that driver, so we could never change protocol details just for our benefit; not to mention having kernel patches accepted is not trivial).

marckleinebudde commented 3 years ago

Drop me a note, if you have any changes for the Linux gs-usb driver. Happy to review and take it.

normaldotcom commented 3 years ago

To make a connection-- @ericevenchick has created a modified version of the gs-usb driver that works with his CANtact Pro device. I haven't looked at it in detail yet to check on backwards compatability/etc, but it might be a good starting point for something that could get mainlined. (https://github.com/linklayer/gs_usb_fd).

I do have candlelight running nicely on the G431 using the FDCAN peripheral with a (particularly messy) build system that compiles for multiple processor families. No support for CANFD packets at the moment, just classic CAN. Hoping to do some cleanup on the build system soon.

I do have hardware on hand if anyone would like to do some testing!

marckleinebudde commented 3 years ago

Hey @ndushman

Last year I asked @ericevenchick to post the driver on the linux-can mailing list for review, but he never responded.

https://lore.kernel.org/linux-can/84075a2d-de68-da73-6db2-beb10122242d@pengutronix.de/

The first step would be to merge the gs_usb_fd.c into a Linux repo and post the patch on the linux-can mailing list: linux-can@vger.kernel.org.

ericevenchick commented 3 years ago

Thanks for the poke on this @marckleinebudde, I am up for sorting out the review. Just need to learn the process for submitting it and clean it up to match the Linux style requirements.

ndushman commented 3 years ago

Hey @ndushman

@marckleinebudde Did you mean to tag me on this? I'm guessing you intended @normaldotcom and an autocomplete starting with n got me instead.

marckleinebudde commented 3 years ago

Doh, sorry for the noise.

fenugrec commented 3 years ago

@marckleinebudde thanks for dropping by ! I can't help with the kernel patching and gs_usb driver extensions, but I can assist integrating in our build system. Would be great to keep one upstream for all this, if there is enough common code of course.