Vendor and understand an available CANopen protocol stack

[nazavode]

Since we reached consensus about choosing the CANFestival way, we can sketch some tasks related to this story:

• Study and investigate official CANFestival forks
• Fork the chosen code base here on GitHub
• Port to CMake
• Fix build on all supported platforms

[alalazo]

An overview on how to write or vendor a CANopen stack can be found in this Stackoverflow question. The libraries that the accepted answer suggests having a look at are:

• CANFestival (LGPL v2.1+): there are multiple forks available here. Apparently the one that 4nxt is already using is this one. Supports both Windows and Linux.
• CANopenNode (GPL v2 with classpath exception): the home of the project is here. It seems aimed at micro-controllers but a Linux socket implementation can be found in this companion project.
• Lely CANopen (Apache v2.0): the project is hosted here on GitLab. Most of the functionality of CiA 301, 302, 305, 306, 309 and 315 is provided (so we should have NMT, SDO, PDO, EDS support, etc.). It supports both POSIX platforms (Debian-based Linux distributions in particular) and Windows (Vista and higher). VS projects need to be created manually.
• openCANopen (ISC, equivalent to BSD v2): the project home is here. It's a master that runs on Linux, and seems to be the less mature implementation (personal opinion).

In addition to the 4 libraries above, @nazavode pointed also to:

• KaCANopen (BSD v3): can be found here. They provide only Linux drivers, but are compatible with CANFestival driver (that also provides Windows).

[nazavode]

Just to sum up a bit, this is what we are currently looking for in a CAN stack:

• Compatible license (no viral licenses, e.g: GPLv{2,3}, Affero)
• As pointed out by @alalazo, NMT and SDO support is all we need in this phase
• Windows support (native MSVC, no hackish stuff like cygwin and such)

Nice to have features are:

• Mock drivers (needed by by Add a CANopen mock stack #86)
• Sane (e.g.: CMake) build system

Just as a quick note, CANFestival provides a virtual driver that just prints stuff to stdout. Crafting a proper mock driver that provides testability functionalities looks doable to me.

[nazavode]

Update: after some investigation, we found that:

• The high level APIs listed above are lacking, each one in its own way (platform support and portable build system mainly)
• The de-facto standard is CanFestival, that looks written in C89 (or even pre-ANSI, we should check)
• CanFestival is low level but looks KISS and straightforward, so vendoring it should be reasonably doable
• CanFestival provides POSIX and native Windows drivers and it has decades of user feedback

We reached consensus on the fact that forking, cleaning up and porting to CMake a CanFestival codebase looks like the most promising option.

[alalazo]

Pinging @Giovepluvio and @haram80 as they might also be interested in the discussion.

[nazavode]

We reached consensus about forking here the official fork found at http://dev.automforge.net/CanFestival-3. Given the fact that the authors seem to have fixed some severe bugs (something like 4NXT/canfestival@8488d03 or 4NXT/canfestival@5a35671), still present in upstream, this looks good to @Giovepluvio too.