Zephyr CAN-USB Support

[KozhinovAlexander]

Dear Zephyr RTOS community,

I would like to propose adding Zephyr's own CAN-USB driver with SocketCAN for Linux support to the project. It would include following steps:

• Zephyr RTOS CAN-USB driver development
• Linux Kernel SocketCAN driver development matching Zephyr RTOS side
• Python/C/C++ implementation for usage as a pip package
• (oprional) WebUSB layer

Adding Zephyr's own CAN-USB implementation shall open following opportunities:

• Independent SW base with full Apache 2.0 license
• Tight integration with Zephyr project
• Higher speed of development/improvements within bigger comunity

CAN-USB is widely used for CAN-Bus data logging/tarnsmission over USB to the host PC. One of the examples is a PEAK-CAN-USB device series with according open-source linux kernel driver.

Bofore I begin with the implementation I have following open questions to USB (@jfischer-no) and CAN (@henrikbrixandersen) maintainers:

• Do you both see anythin, what could prevent merging such project?
• @jfischer-no would it be possible to reserve PID inside Zephyr's VID for such project as soon it reaches certain maturity level?

Thank you all.

Appendix:
At the moment there are two main alternatives based on gs_usb Linux kernel driver and Zephyr opüposite FW side:

1. CANnectivity (by @henrikbrixandersen): https://github.com/CANnectivity/cannectivity
2. gs_usb (by me): https://github.com/KozhinovAlexander/zephyr/tree/gs_usb

CANnectivity is very well done and already has a good performance, but is maintained outside of Zephyr RTOS. It's huge advantage albite the others - it brings own USB VID:PID.
My gs_usb is not seen as reasonable inside Zephyr RTOS (see this discussion).

[fabiobaltieri]

@KozhinovAlexander is the suggestion to develop a new USB-CAN driver from scratch? USB protocol, kernel driver(s), tooling etc? Seems like a lot of duplicated effort considering the popularity of gs_usb solutions out there. There seem to be an interest into merging back the CANnectivity implementation down the road, that seems like a more effective solution to me. Is there any drawback of that beside having the protocol part out-of-tree right now?

[KozhinovAlexander]

@fabiobaltieri Thank you for your message.

@KozhinovAlexander is the suggestion to develop a new USB-CAN driver from scratch?USB protocol, kernel driver(s), tooling etc?

That's right.

Seems like a lot of duplicated effort considering the popularity of gs_usb solutions out there.

It is true partially. The work is definitely duplication in some aspects. But I am plannign to use Apache 2.0 on Zephyr and linux side. Compared to gs_usb and peak_can_usb it shall allow business/hobbyists etc. be independent from license issues. I see a huge advantage thus in licensing model.

There seem to be an interest into merging back the CANnectivity implementation down the road, that seems like a more effective solution to me.

CANnectivity is great and my aproach does not prevent it to be merged and also existing in parallel.

Is there any drawback of that beside having the protocol part out-of-tree right now?

From the technical side there is definitely no drawback. From the practical side it is visibility. The probability for developers to see some code inside Zephyr tree is much more higher - but this is only my opinion.

My general vision is regarding Zephyr customized implementation is:

• Simple less restrictive licensing (Apache 2.0 inside Zephy and linux kernel)
• Visibility/Accessibility inside Zephyr RTOS and linux kernel projects
• Less dependencies on other projects (like gs_usb on candleLight_fw at the moment)
• Zephyr RTOS oriented CAN protocoll data format

[henrikbrixandersen]

From the technical side there is definitely no drawback. From the practical side it is visibility. The probability for developers to see some code inside Zephyr tree is much more higher - but this is only my opinion.

Did you see CANnectivity is now linked from the Zephyr RTOS documentation? https://docs.zephyrproject.org/latest/develop/manifest/external/cannectivity.html

My general vision is regarding Zephyr customized implementation is:

• Simple less restrictive licensing (Apache 2.0 inside Zephy and linux kernel)

CANnectivity is Apache-2.0 licensed and can be used as a Zephyr module (see the link above).

I don't believe you can even create an Apache-2.0 licensed Linux kernel CAN driver as many of the required symbols are only exported to GPL-licensed code (EXPORT_SYMBOL_GPL()). Furthermore, loading an Apache-2.0 licensed Linux kernel module would "taint" the Linux kernel (see https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html).

• Visibility/Accessibility inside Zephyr RTOS and linux kernel projects

Please see above for visibility within the Zephyr project.

As for visibility within the Linux kernel project, I doubt an externally hosted kernel module will bring much visibility there. Also, as already replied to you in another discussion regarding this, I will submit the CANnectivity USB VID:PID to the Linux kernel gs_usb driver, which should bring some attention the people involved in Linux CAN (see #75207 (reply in thread)).

• Less dependencies on other projects (like gs_usb on candleLight_fw at the moment)

I don't understand this part. The gs_usb protocol (and Linux driver for that matter) has no dependency on the candleLight_fw? As an example, the protocol features currently supported by the gs_usb Linux kernel driver are not all supported by the candleLight_fw.

Please elaborate on which dependencies, you see here.

• Zephyr RTOS oriented CAN protocoll data format

Please elaborate?

[KozhinovAlexander]

From the technical side there is definitely no drawback. From the practical side it is visibility. The probability for developers to see some code inside Zephyr tree is much more higher - but this is only my opinion.

Did you see CANnectivity is now linked from the Zephyr RTOS documentation? https://docs.zephyrproject.org/latest/develop/manifest/external/cannectivity.html

No. Thank you pointion to it. I like it :)

My general vision is regarding Zephyr customized implementation is:

• Simple less restrictive licensing (Apache 2.0 inside Zephy and linux kernel)

CANnectivity is Apache-2.0 licensed and can be used as a Zephyr module (see the link above).

I don't believe you can even create an Apache-2.0 licensed Linux kernel CAN driver as many of the required symbols are only exported to GPL-licensed code (EXPORT_SYMBOL_GPL()). Furthermore, loading an Apache-2.0 licensed Linux kernel module would "taint" the Linux kernel (see https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html).

You're right, I will conisder it. Good point.

• Visibility/Accessibility inside Zephyr RTOS and linux kernel projects

Please see above for visibility within the Zephyr project.

As for visibility within the Linux kernel project, I doubt an externally hosted kernel module will bring much visibility there. Also, as already replied to you in another discussion regarding this, I will submit the CANnectivity USB VID:PID to the Linux kernel gs_usb driver, which should bring some attention the people involved in Linux CAN (see #75207 (reply in thread)).

Yes, it is true about VID:PID. I still remember it. Regarding visibility my approach will be of course conservative if it does not get PID within zephyr itself. But I think in long term it is possible.

• Less dependencies on other projects (like gs_usb on candleLight_fw at the moment)

I don't understand this part. The gs_usb protocol (and Linux driver for that matter) has no dependency on the candleLight_fw? As an example, the protocol features currently supported by the gs_usb Linux kernel driver are not all supported by the candleLight_fw.

Please elaborate on which dependencies, you see here.

Thanks for asking it. Speaking about dependency I mean of course project dependency. For example some feature breaking change without technical possibility for backward-compatibility in gs_usb linux kernel driver will put candeLight_fw and CANnectivity in need for change. On the other side my approach will be able to support changes on both sides (zephyr, linux etc.) faster just by updating version.

• Zephyr RTOS oriented CAN protocoll data format

Please elaborate?

It is more about byte-order between host and client. With my idea it shall be possible to overload the host with byte-ordering and data-formatting, which shall reduce overhead on the side of zephyr rtos device. It shall lead to some savings especially for very ressource constrained devices. You may disagree here and maybe will be right. But we can compare numbers (ROM/RAM usage) on same device if there will be counterpart implementation in Zephyr.

@henrikbrixandersen Really thanks a lot for your comments and reasonable critical view on the approach. I believe such discussions bring quality.
In the end speaking about suggested idea I am mostly interested if anybody plans to start with similiar approach. I just do not want waste my time if you or anybody else says me in the end, that there is additional work like mine, like it happened to you and me with gs_usb 😉 Thus syning is important.
Also I am not striving to destroy other approaches, insead adding a range of choises. I think nobody looses anything, if I can start such implementation, but win. Thus please let me know, if such an approach have a chance to be reviewed/merged by you as a maintainer into zephyr as soon as it reaches necessary maturity of course.

[henrikbrixandersen]

Yes, it is true about VID:PID. I still remember it. Regarding visibility my approach will be of course conservative if it does not get PID within zephyr itself. But I think in long term it is possible.

The Zephyr Project has no USB VID:PIDs to hand out to products. The VID used for samples belong to Nordic Semiconductor and can only be used for samples, not products.

Thanks for asking it. Speaking about dependency I mean of course project dependency. For example some feature breaking change without technical possibility for backward-compatibility in gs_usb linux kernel driver will put candeLight_fw and CANnectivity in need for change. On the other side my approach will be able to support changes on both sides (zephyr, linux etc.) faster just by updating version.

Nobody wants to introduce breaking changes in a protocol like gs_usb. It would render all earlier firmware versions/products unusable with newer driver implementations. The gs_usb protocol is designed to allow for future extensions (and quite a few have been added already compared to the original protocol) without breaking backwards compatibility.

It is more about byte-order between host and client. With my idea it shall be possible to overload the host with byte-ordering and data-formatting, which shall reduce overhead on the side of zephyr rtos device. It shall lead to some savings especially for very ressource constrained devices. You may disagree here and maybe will be right. But we can compare numbers (ROM/RAM usage) on same device if there will be counterpart implementation in Zephyr.

The gs_usb protocol uses little endian data format, rendering the various sys_le32_to_cpu() and sys_cpu_to_le32() used in e.g. CANnectivity as no-ops when built for little endian architectures. Are you using a big endian MCU in your USB to CAN adapter designs? If so, which one?

Apart from this, the gs_usb protocol actually supports both little and big endian data formats, but the Linux kernel gs_usb driver only implements support for little endian so far. If you really have a need for big endian data format, you could send a patch adding support for it.

[KozhinovAlexander]

Are you using a big endian MCU in your USB to CAN adapter designs? If so, which one?

I am on LE one. But in general Zephyr shall support both endianess types, that's why I mentioned it.

[fabiobaltieri]

There's no technical reasons why two different can-usb implementations could not live in the code base, but for the sake of code maintainability I think one would rather avoid it and only have to maintain a single one. I could understand if it was two well known standard, but in this case there's an existing widely adopted one (gs_usb) and nothing else, I would not start developing a second one unless you find a fundamental protocol flaw in the existing protocol that justifies developing a new one.

There's a precedence of this in the code base by the way, there are two USB-ethernet protocols (CDC-ECM and RNDIS) implemented in the USB stack and one of those is going to not be ported to the new stack.

In my opinion this effort would only make sense if there was a class defined protocol (a CDC-CAN of some sort) to be implemented.

[KozhinovAlexander]

@fabiobaltieri You bring it to the point. I agree with you in absolutely all points except CDC-ECM/RNDIS. Basically RNDIS is a solution on crutches from Microsoft 😄 But this is different story.
Going with two solutions leads, as you say, to one going to be dropped. And that is exactly reason, I would do it. Best one will survieve.

[KozhinovAlexander]

@henrikbrixandersen @fabiobaltieri Thank you a lot for this great discussion and also for your convince work. I've got your points, I see your experience, I agree with a lot you say, but some stuff I see different. But, hey, this is how it works.
At that point we can stop the discussion, cause @fabiobaltieri has summaraised it well. @fabiobaltieri If it is okay for you, I would mark your last post as an answer.