= CanFestival =


Information posted by Wolfram Wadepohl in http://www.rtems.com/ml/rtems-users/2007/june/msg00057.html:

We have implemented CANfestival (http://www.canfestival.org) in 1.31 version.

There were some issues we fixed but a general design problem remains.
The CANopen stack is completely "application driven", i. e. no CANopen process exists and from the application viewpoint it wrks like a "polled" system. That suits fine for synchronous master applications.
There are no separate input queues for different CANopen messages and the application has to take care of mixed NMT, SDO, PDO or LSS usage.

The code is well structered, with little documentation and pretty small (about 400 lines of C)
We got it licensend from the author under a different license ("LGPL or whatever you want") to make it compatible with RTEMS licensing.

It may not be portable to other architectures, because transformation of little endian (CAN) to big endian (host) is not implemented in a transparent matter (only used for SDO handling).

CANfestival 1.31 has no data dictionary and no knowledge about the data inside the PDOs. Therfore process data is in native, i. e. little endian, format and not structered. It has to be interpreted and converted by the application.

Version 2.x was incompatible from licensing.

Version 3.0 is LGPL licensed, so compatible with RTEMS but not yet evaluated.

In the [wiki:TBR/BSP/Gen5200  powerpc/gen5200] BSP a CANdriver is implemented. RTEMS community has no standard API for CAN driver usage und CAN message handling. There is currently no such thing as a "socket" for CAN as exists for ethernet.