Changes between Version 3 and Version 4 of Projects/CanFestival


Ignore:
Timestamp:
Jun 13, 2007, 7:19:46 PM (13 years ago)
Author:
Wadepohl
Comment:

CANfestival 1.31: pretty small, but limited CANopen stack

Legend:

Unmodified
Added
Removed
Modified
  • Projects/CanFestival

    v3 v4  
    55
    66We have implemented CANfestival (http://www.canfestival.org) in 1.31 version.
    7 There were many issuues we fixed but a general design problem remains, which I would explain if anybody is interested.
    8 We got it licensend from the author under a diffent license to make it compatible with RTEMS licensing.
     7
     8There were some issues we fixed but a general design problem remains.
     9The 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.
     10There are no separate input queues for different CANopen messages and the application has to take care of mixed NMT, SDO, PDO or LSS usage.
     11
     12The code is well structered, with little documentation and pretty small (about 400 lines of C)
     13We got it licensend from the author under a different license ("LGPL or whatever you want") to make it compatible with RTEMS licensing.
     14
     15It 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).
     16
     17CANfestival 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.
    918
    1019Version 2.x was incompatible from licensing.
    1120
    12 Version 3.0 is LGPL licensed, so compatible with RTEMS but I have not looked at it.
     21Version 3.0 is LGPL licensed, so compatible with RTEMS but not yet evaluated.
    1322
    14 In the [wiki:TBR/BSP/Gen5200  powerpc/gen5200] BSP is a CANdriver implemented. there is no standard
    15 interface from middleware as CANopen to access the driver.
     23In 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.