Zephyr: CANopen Support

[nashif]

Is your feature request related to a problem? Please describe.

CANopen is a CAN-based communication system. It comprises higher-layer protocols and profile specifications.

[henrikbrixandersen]

I am looking into a project in the near future, where we will need to integrate CANopen support in Zephyr. Still searching for an appropriate, small CANopen implementation on top of SocketCAN, that can be ported to Zephyr.

[str4t0m]

@henrikbrixandersen do you still intend to port a CANopen implementation to Zephyr?
The two libraries, that build upon SocketCAN, and I know of are CANopenNode and CANFestival. Both seem not be maintained very actively anymore.

• https://github.com/CANopenNode/CANopenNode license: GPL-2.0
• https://canfestival.org/ license: LGPL(runtime) and GPL (some tools regarding the creation of the object dictionary)

I am pretty sure you already had a look at them, do you think any of these would be appropriate?

[henrikbrixandersen]

@str4t0m Yes, I am in the process of porting CANopenNode to Zephyr.

[str4t0m]

That sounds great.
I'm thinking about a project where I could use CANopen.
Currently I am just getting started with Zephyr and haven't worked with CANopenNode yet, but I like what I have seen so far.
The management of the object dictionary seems mature compared to the Objdictedit used for Canfestival. Do you use the Object dictionary editor from the CANopenNode, or the libedssharp
editor to manage the Object dictionary?

[henrikbrixandersen]

@str4t0m I use the editor from libedssharp. It's quite good.

I have CANopenNode basic functionality up and running on Zephyr, still working on EEPROM and ROM save/load support.

[jukkar]

* https://github.com/CANopenNode/CANopenNode   license: GPL-2.0

The GPL-2.0 license is not compatible with Apache-2 license that we have in Zephyr, so your port cannot be put upstream. Did you had plans to upstream your CANopenNode port?

[henrikbrixandersen]

* https://github.com/CANopenNode/CANopenNode   license: GPL-2.0

The GPL-2.0 license is not compatible with Apache-2 license that we have in Zephyr, so your port cannot be put upstream. Did you had plans to upstream your CANopenNode port?

CANopenNode is licensed under GPL-2.0 with linking exception and the CANopenNode repository is a separate module. I was hoping to upstream it, yes.

[jukkar]

CANopenNode is licensed under GPL-2.0 with linking exception and the CANopenNode repository is a separate module. I was hoping to upstream it, yes.

ping @nashif any idea whether upstreaming this piece of code is possible?

[henrikbrixandersen]

ping @nashif any idea whether upstreaming this piece of code is possible?

The WIP integration can be seen here: https://github.com/vestas-wind-systems/zephyr/tree/canopennode

[henrikbrixandersen]

CANopenNode author comments on licensing of driver and object dictionary files can be found here: https://github.com/CANopenNode/CANopenNode/issues/105#issuecomment-533803323

[jukkar]

I am not a lawyer, but the exception looks ok to me. Anyway, it would be better if you get approval from TSC for this.

[paoloteti]

I'm wondering if lely-co, instead of CANopenNode, could be a better choice in term of code quality and license (Apache 2.0).

[henrikbrixandersen]

I'm wondering if lely-co, instead of CANopenNode, could be a better choice in term of code quality and license (Apache 2.0).

Interesting. I am interested in learning more of how you view/compare the code quality of the two projects?

[psidhu]

@jukkar @henrikbrixandersen It looks like CanOpenNode changed their license to Apache-2.0: https://github.com/CANopenNode/CANopenNode

[henrikbrixandersen]

@jukkar @henrikbrixandersen It looks like CanOpenNode changed their license to Apache-2.0: https://github.com/CANopenNode/CANopenNode

Correct. We are currently working to get #19510 ready for Zephyr v2.2.