CAN2Host diverse protocols support

[KozhinovAlexander]

@henrikbrixandersen I have general questiuons to you here, before I miss something or start doing something:

1. Do you have experience with: https://www.can-cia.org/can-knowledge/cia-315-canopen-generic-frame-for-wireless-tunneling-of-can-messages-and-for-transfer-of-diagnostic-data Could we maybe establish a sample within Zephyr RTOS for it together?
2. Were you already thinking implementing native zephyr_can_usb Linux SocketCAN driver and corresponding python lib for it?

Also possible drawbacks, complications, meaningful points are welcome here.

May be this discussion will be helpful for forces join for the future? I will be happy to participate, help, maintain etc.

[henrikbrixandersen]

1. Do you have experience with: can-cia.org/can-knowledge/cia-315-canopen-generic-frame-for-wireless-tunneling-of-can-messages-and-for-transfer-of-diagnostic-data Could we maybe establish a sample within Zephyr RTOS for it together?

No, I have no experience with CiA 315 and no immediate plans to implement support for it in Zephyr. It sounds more complex than what we usually put in a Zephyr sample, though.

2. Were you already thinking implementing native zephyr_can_usb Linux SocketCAN driver and corresponding python lib for it?

No, why would this be needed? The whole idea is to make a USB device, which is compatible with the existing Linux and Python support for the "gs_usb" protocol. Perhaps I've misunderstood your question?

[KozhinovAlexander]

1. Do you have experience with: can-cia.org/can-knowledge/cia-315-canopen-generic-frame-for-wireless-tunneling-of-can-messages-and-for-transfer-of-diagnostic-data Could we maybe establish a sample within Zephyr RTOS for it together?

No, I have no experience with CiA 315 and no immediate plans to implement support for it in Zephyr. It sounds more complex than what we usually put in a Zephyr sample, though.

2. Were you already thinking implementing native zephyr_can_usb Linux SocketCAN driver and corresponding python lib for it?

No, why would this be needed? The whole idea is to make a USB device, which is compatible with the existing Linux and Python support for the "gs_usb" protocol. Perhaps I've misunderstood your question?

A Linux driver for zephyr socket-can could be interesting due to three problems with current gs_usb implementation:

1. gs_usb has fixed endpoint andresses. And according to @jfischer-no host USB driver shall be able to update ep addresses after connection. Or speaking other way around: current zephyr USB stack implementation will change ep addresses if last 4 bytes of ep in/out addressed are not same: https://docs.zephyrproject.org/latest/connectivity/usb/device/usb_device.html#id15

2. for very limited HW MCUs zephyr native USB host driver will generate less byte overhead, if can_msg structs will be used directly to transfer to the host.

3. Zephyr native Linux socket can driver will add more flexibility for alter adaptations.

[jfischer-no]

And according to @jfischer-no host USB driver shall be able to update ep addresses after connection.

I never said that, nor is it described that way here. The correct way is to read the endpoint descriptors and get the endpoint addresses from there. I am sure you are welcome to improve gs_usb driver in the Linux kernel.

[KozhinovAlexander]

And according to @jfischer-no host USB driver shall be able to update ep addresses after connection.

I never said that, nor is it described that way here. The correct way is to read the endpoint descriptors and get the endpoint addresses from there. I am sure you are welcome to improve gs_usb driver in the Linux kernel.

I may be interpreting it wrong, but thanks for the correction.
I think, changing gs_usb in Linux Kernel may take waaaay longer. :)