search

candle-usb / candleLight_fw

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

Maintainer / which clone to use #22

Closed jhofstee closed 5 years ago

jhofstee commented 5 years ago

Hi, first of all thanks for this project. It seems a much better approach for Linux then the slcan driver. There are some trivial issues / merge request open here for more then half a year, which I can happily send a fix for and add some other improvements, but makes me wonder if we shouldn't use another fork as "upstream" of someone who has some time (and skills) to maintain it more actively.

@HubertD , @normaldotcom, @nexulm any thoughts about that? or are you all fine with randomly merging from other forks?

fenugrec commented 5 years ago

Agreed, I also have a PR gathering dust somewhere (on nexulm's fork I believe) and some misc commits

fenugrec commented 5 years ago

How about trying an "organization" here on GH instead of a personal fork ? we could have 2-3 committers, or just 1, and see how it works out.

HubertD commented 5 years ago

would be glad to have some community maintaining this project, will also try to do some work myself.

fenugrec commented 5 years ago

Marking this as closed since the repo is now part of the "candle-usb" organization and should continue to be updated !

jhofstee commented 5 years ago

Thanks, appreciated!

nexulm commented 5 years ago

Great to see that the project is still used and improvements are ongoing, maybe if a CAN-FD port/adaptation with new hardware is available I'll need an updated repo. Currently I'm glad with my canable-usb fork as it is still running as expected. :-)

daniel-santos commented 5 years ago

@nexulm Hello there! This is in progress here. Code is currently ugly and I'll be destructively committing to master once I clean up commits, so you can use the original-master tag for the historical (current) master. I was in a hurry when I wrote it.

There are a lot of challenges to face in the port and one challenge is that I must have 2Mbps performance, so I'm also attacking the Linux driver. I'm hoping this can be done without forking the driver, but I think that will depend upon negotiations with the upstream maintainer. Specifically, I'm adding a "packed frames" bulk URB so that multiple CAN frames can be bit-packed into a smaller space and reducing wasted USB bandwidth, since we only have 12Mbps to work with. Fortunately, any descent hub will be at least high-speed (480Mbps) so the bottleneck should only exist on the first USB hop.

This is currently a fork of candleLight and is in a license limbo due to conflicts with ST's license. I aim to solve that part within the next month by expunging all of the non-free "ST Ultimate Freedom License"d code, but continuing to use STM32CubeMX for generation of the µC-specific code. In theory, this will make porting easier (heavy on the "theory").

I always prefer to avoid forking, but the new firmware makes some radical departures. We'll have to see once we get it fully functioning. It would be nice to be able to integrate the changes back in.

This uses the STM32G4xx hardware and is specifically targeting the STM32G431RB (128KB flash) but will likely run on the 64KB (or even the 32 KB) flash versions when done. The STM32G474xx line has 3 CAN controllers, but I'm exceedingly pessimistic about getting 2Mbps on all 3 devices at once without dropping frames, so I'm not focusing on that.

daniel-santos commented 5 years ago

@nexulm, @HubertD Oh, I forgot that one major issue I ran into was that there's no STMGxxx port of the Mastering STM code (ld script, etc.) and I spent 9 days trying to get any CAN messages in or out to no avail until I created a new project from STM32CubeMX and just ported the candleLight code into it. I never figured out exactly what the problem was either. :*( There were also a lot of compatibility issues between the STM32Fxxx and STM32Gxxx ST libraries.