Maintainer / which clone to use about candlelight_fw

[fenugrec]

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

[fenugrec]

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]

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

[fenugrec]

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

[jhofstee]

Thanks, appreciated!

[nexulm]

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]

@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]

@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.