gs_usb: CAN - USB Adapter

[KozhinovAlexander]

Dear Zephyr RTOS community,

I was able to (re-)implement gs_usb CAN-Bus to USB adapter Firmware based in Zephyr RTOS, which (still in development) can be found here: https://github.com/KozhinovAlexander/zephyr/tree/gs_usb use following command to build:

west build -p auto -d <ZEPHYR_DIR>/samples/drivers/can/gs_usb/build -b nucleo_h745zi_q/stm32h745xx/m7 <ZEPHYR_DIR>/samples/drivers/can/gs_usb  -DDTC_OVERLAY_FILE=<ZEPHYR_DIR>/samples/drivers/can/gs_usb/nucleo_h745zi_q.overlay

GS_USB is a OpenMoko Geschwister Schneider CAN adapter system including Linux CAN-USB driver. It has also VID and PID from it.

The great thing about it, there is a pretty a lot of SW sub-projects doing:

1. Python support here
2. Linux SocketCAN driver support here
3. CandleLight bare metall FW here

and there are also a lot of STM32 based HW available:

1. candleLight from Linux Automation here
2. MKS Canable v2.0 here, can be found for a nice price on Ali-Express here

With my FW Zephyr RTOS based clone I have already all the funbctionality (except, find-my-device and generic support of multiple CAN-Endpoints).

What I plan to do? I need your advice and/or support in following questions:

1. How to handle licensing? Since Linux-Kernel driver is GPL-2.0 only, is it legitime for me to release my FW clone under Apache 2.0 within Zephyr RTOS?
2. Since my GS_USB is a FW clone implmenting a USB-Class, shall it be added to USB class sub -folder of Zephyr RTOS project or putted as a sample?

From my point of view the right persons to answer this questions may be @jfischer-no @henrikbrixandersen @martinjaeger @alexanderwachter If I putted falsily your name here, please let me know, I will remove it.

I will also be happy to get in touch if necessary and/or to discuss additions. Basically with some minor clean-ups I shall be ready release this work soon.

I appreciate your help. Thanks a lot.

[henrikbrixandersen]

I wish you had reached out before embarking on this. I have a fully functional, multi-endpoint gs_can implementation ready to be submitted after the current feature freeze ends.

[KozhinovAlexander]

I wish you had reached out before embarking on this. I have a fully functional, multi-endpoint gs_can implementation ready to be submitted after the current feature freeze ends.

Very good point. Well, I have no problem, you submit it and stay maintainer. I've gathered a lot of experience implementing my code and can support you and/or do a review, if you okay with it.
Would you like to submit your code s.t. we can join our forces?
I have already x2 MKS Canable v2.0 with stm32g4 from AliExpress and can create bsp for them too and of course test them. Nice thing about them - they're open hardware.

[henrikbrixandersen]

Awesome. I would really like to have your experienced eyes reviewing the implementation. I'll brush off the last documentation bits and pieces and ping you.

[KozhinovAlexander]

Awesome. I would really like to have your experienced eyes reviewing the implementation. I'll brush off the last documentation bits and pieces and ping you.

Great. I am happy to see it soon.
BTW: My implementation does not have twister tests at the moment. Does your's have it?

[henrikbrixandersen]

BTW: My implementation does not have twister tests at the moment. Does your's have it?

Only a basic console-based test scenario. The USB device class itself is better verified using the stress testing tools from Linux can-utils.

[KozhinovAlexander]

BTW: My implementation does not have twister tests at the moment. Does your's have it?

Only a basic console-based test scenario. The USB device class itself is better verified using the stress testing tools from Linux can-utils.

Sounds plausible. In my branch above you can also find a bash script for cyclic can message sending with can-utils, fyi.

[KozhinovAlexander]

@henrikbrixandersen Do you plan also to update gs_usb linux kernel driver to be able to discover in/out bulk pipe addresses at probe time to be compatible with Zephyr's USB stack too?

[henrikbrixandersen]

@henrikbrixandersen Do you plan also to update gs_usb linux kernel driver to be able to discover in/out bulk pipe addresses at probe time to be compatible with Zephyr's USB stack too?

I plan on addressing that issue, yes, but it's not the first thing on my TODO list. If you want to give it a go, please do.

[KozhinovAlexander]

Thanks. I'll take a look on it.

[KozhinovAlexander]

@henrikbrixandersen Do you plan also to update gs_usb linux kernel driver to be able to discover in/out bulk pipe addresses at probe time to be compatible with Zephyr's USB stack too?

I plan on addressing that issue, yes, but it's not the first thing on my TODO list. If you want to give it a go, please do.

Could you please test updated Linux kernel gs_usb driver with dynamic EP assignemnt:

• Linux driver is hier: torvalds/linux@master...KozhinovAlexander:linux:fix_gs_usb
  • HowTo Build/Install:

  cd <location of gs_usb.c file>
  make build
  sudo make install

• My Zephry gs_usb implementation with necessary USB EP interface changes is here: 18b2e65?diff=split&w=0

I've tested it with two separate gs_usb hardware instances conneted to my host over USB and transfering CAN messages between each other.
The script I've used to test could be found here: https://github.com/KozhinovAlexander/zephyr/blob/gs_usb/samples/drivers/can/gs_usb/scripts/can_dev_test.sh

Thank you for taking a look on it. ;)

[RomainPelletant]

[henrikbrixandersen]

The following question is probably out of scope but: is it possible to instantiate a virtual CAN bus (for example implement CiA 301 Master) and make it accessible via USB on Linux using SocketCAN (to implement a CiA 301 slave)?

I am not sure I fully understand the architecture of what you are asking, but it is definitely not in the scope of this topic.

Feel free to open a new discussion with more details in the architecture and use-case.

[RomainPelletant]

Do you have an idea when you will push a PR? I would benchmark the solution with a PEAK product :)

[henrikbrixandersen]

Hi! Thank you for the interest! I hope to be able to push it later this week, finalising the last error handling right now.

[KozhinovAlexander]

Maybe following bash script could be helpful for you in (performance-)testing: https://github.com/KozhinovAlexander/zephyr/blob/gs_usb/samples%2Fdrivers%2Fcan%2Fgs_usb%2Fscripts%2Fcan_dev_test.sh
Fell free to use it, copy, modify etc. ;)

[henrikbrixandersen]

Now publicly available: https://github.com/CANnectivity/cannectivity

As you can see, I opted to put the gs_usb protocol implementation in a Zephyr module, at least for now while it matures. The upside is, that the repository above contains a full fledged firmware implementation compatible with the gs_usb protocol (and e.g. the gs_usb Linux kernel SocketCAN driver).

Comments and feedback is most welcome!

[henrikbrixandersen]

Sounds very promising. Thank you @henrikbrixandersen. Do you still plan to merge it in Zephyr RTOS and give a small sample based on your gs_usb Zephyr driver implementation?

Maybe, once it has matured. Note that you can already start using the USB class implementation in your own project, should you wish to, by pulling in CANnectivity as a Zephyr module.

Are there any licence constraints, which motivated you not to merge it into Zephyr?

License question were also one of my questions in the origin of this discussion.

No license constraints, no. The firmware is licensed under the Apache-2.0 license, same as Zephyr itself.

[KozhinovAlexander]

I've already skimmed over your implementation and saw very good work. Albeit this there are some places, I would do different. But it is only Design. choice. Definitely I would prefer to see your implementation in Zephyr itself and reuse in your project as a part. But it is definitely up to you.

Therefore I forward here my update from previous messages, to be fair:

UPDATE: Would it be okay for you if I try to merge my gs_usb implementation into Zephyr main branch? Of course I will mention your project in the header of sources of I take some quicks of your implementation,.if you wish.

[henrikbrixandersen]

UPDATE: Would it be okay for you if I try to merge my gs_usb implementation into Zephyr main branch? Of course I will mention your project in the header of sources of I take some quicks of your implementation,.if you wish.

I must admit I don't see any reason for that.

[RomainPelletant]

Thank you so much @henrikbrixandersen. I will give it a try and come back to you!

[KozhinovAlexander]

UPDATE: Would it be okay for you if I try to merge my gs_usb implementation into Zephyr main branch? Of course I will mention your project in the header of sources of I take some quicks of your implementation,.if you wish.

I must admit I don't see any reason for that.

I definitely would prefer your implementation to be merged into Zephyr and you to be the maintainer, because your implementation is really great and do not need to be hidden from the main branch.

The reasons to put one of implementations (preferably yours) into Zephyr are obvious:

• Usage of knowing toolset/sdk/environment.
• Higher improvement velocity through bigger community.
• Higher visibility from community.
• Higher probability to be tested over more SoC(s) boards.

and my personal one:

• Giving people something to start with their next project.

What if you put your version to zephyr and (at the same time) reuse it in your project and or will have copy in you repository?

[KozhinovAlexander]

@henrikbrixandersen I would say we can close the discussion as soon as we have one of the changes merged to zephyr itself? Do you see it like this?

[henrikbrixandersen]

@henrikbrixandersen I would say we can close the discussion as soon as we have one of the changes merged to zephyr itself? Do you see it like this?

As said earlier, I don't think that goal necessarily makes sense. A gs_usb USB protocol implementation is not a generic functionally needed by many firmware applications (unlike e.g. USB HID, DFU, etc).

Not all software functionality needs to reside within the main Zephyr tree, especially when it's already provided as a reusable implementation by a module.

As the CAN maintainer, I would vote against merging it upstream from the reasons given above (and earlier in this discussion).

[KozhinovAlexander]

Thank you. I see your points. Since there is solution available now, let first close this discussion and marking as answered.
One last topic stays for me still opened: How to reach as much dev(s) as possible, to be aware of your implementation :D

[henrikbrixandersen]

One last topic stays for me still opened: How to reach as much dev(s) as possible, to be aware of your implementation

Thanks. So far I've mentioned CANnectivity on the Zephyr Discord, on the Zephyr User mailing list, listed it on https://github.com/zephyrproject-rtos/awesome-zephyr-rtos, you've mentioned it on the linux-can mailing list, ...

I am currently waiting for pidcodes/pidcodes.github.com#965 to go through, so I can update the default USB PID in CANnectivity. Once this is done, I'll submit a patch for the Linux kernel gs_usb driver adding the CANnectivity USB VID:PID, and start "advertising" it on SoME, which could also help getting some more attention to the project.

[KozhinovAlexander]

Well. As I know - vid:pid is costly. Very nice you push it forward. In that case I see additional value here.

[KozhinovAlexander]

I see this discussion as closed, since most of the questions were answered.