RT-CANopen architecture

RT-CAN driver

RT-CAN driver resides in the RT-Linux address space as the real-time thread. It means, that any CAN message can be handled in a deterministic time horizon.

Two interfaces are exported. First one is the set of handlers needed for device /dev/canxx. The second one is the Virtual CAN API (VCA) designed for driver communication with POSIX threads.

As you can see in the following figures, RT-CAN driver contains the table of buffers for transmitted and received CAN messages. This buffers can be considered, from the CANopen point of view, to serve as the RPDO and TPDO buffers. The COB-ID mask can be registered to each buffer. Driver also contains the FIFO for receiving and transmitting the CAN messages. This FIFO will be used for the SDO communication.

Next figures show possible usage of the VCA.

RT-Linux space VCA usage

Real-time application thread uses directly VCA of RT-CAN driver for the communication with a CAN bus.

User space VCA usage

In Figure 8-9 the application thread and CAN driver reside in different address spaces. To connect kernel space and user space, we use device /dev/can xx. The applications which will not use VCA can use directly /dev/can and the standard set of I/O operations (read, write, ioctl). A libCAN is needed to grant the same API to user space and kernel space threads. This approach supports portability of application threads between the kernel and user spaces on the source code level.

CAN bus substituting layer with VCA

On Figure 8-10 we can see option, that gives us an opportunity to exploit the VCA even if no real CAN hardware is used. This solution is designed mainly for development purposes and testing. The dashed line in the figure means that CAN substitution layer can optionally operate on some other device than /dev/can (ie. Ethernet). CAN substitution layer can be also a kind of user space application providing the VCA. This can be very useful during development or for educational purposes.

Overview

RT-CANopen slave (only slave or CANopen slave will be used instead in rest of this section) is the software solution based on the hardware, RT-CANopen FSM threads, EDS file and HDS file (see Figure 8-11).

CANopen slave components description

Slave FSM: Slave FSM means set of RT-Linux threads providing PDO and SDO communication via CAN driver VCA. Slave FSM also calls appropriate handler PDO communication and looks into the slave's object dictionary in case of SDO request.

PDO handlers: User written module containing handlers for reading/writing PDO mapped object data from/to hardware.

EDS: EDS means the Electronic Data Sheet, text file describing all objects in the slave object dictionary. EDS is parsed in order to create the slave OD.

HDS: HDS means the Handler Definition Sheet, text file describing the linking PDO's COB-ID with required handler in order to grant correspondence between the CANopen object value and technological process data from the hardware. For example a thermometer with the analog output connected to PC A/D convertor card needs handler which reads temperature from the card output port and gives it to the FSM. The slave designer have to write this handler code while the FSM source code remains always the same, OCERA written.

User space OD slave architecture

As can be seen on figure above CAN driver sends the CAN messages to CANopen FSM via VCA. FSM handles messages of two main categories, process data (PDO) and service data (SDO, NMT, SFO).

The process data (PDO objects) are handled separately of the service ones. Slave FSM exploits CAN driver message buffers as the buffers for the slave PDOs. This approach is necessary because some CAN chips have such buffers integrated. On the other hand this can speed up PDO object handling. Slave FSM role lies in updating this buffers after device specific event such is timer event or process object value change. The CAN driver sends objects from its buffers when needed (after SYNC object or as a response to RTR object). Consequently slave FSM has to read this buffers after WPDO object arrival.

The PDO handler module is used to synchronize PDO mapped objects values and real world data examined or set by computer hardware. Every PDO mapped object has assigned its reading and writing routine called PDO handler. These handlers are written by control system developer in order to fit general FSM concept to specific hardware and real world process.

Some of SFO are handled directly by CAN driver. Such objects are the SYNC or RTR frames

Other objects (SDO, NMT) are sent through the SDO API to OD driver. OD driver is responsible for all object dictionary manipulations, that means getting and setting object values. If the PDO mapping change occurs due to SDO object processing, OD driver informs slave FSM (via SDO API) to correct PDO handlers table to reflect PDO mapping status in OD properly.

OD driver communicates with OD daemon, which resides in the user space, through RT FIFOs. OD daemon offers set of primitives to provide basic manipulations with OD like get/set object value, add object, delete object etc. OD daemon also owns slave OD in its memory space.

Slave OD can be loaded onto OD daemon memory by EDS parser. EDS parser is the graphical front end to the OD daemon connected with it via Unix socket. This gives us the opportunity to control the daemon and slave OD remotely using TCP/IP. EDS parser is also responsible to read HDS and make appropriate changes in daemon OD and also (via daemon SDO API) in slave FSM PDO handler table. This ensures that the proper handlers will be called for certain PDO objects.

For diagnostic and visualization purposes the diagnostic couple of pipes exists. This pipes can be connected to the diagnostic and monitoring application.

Kernel space OD slave architecture

This architecture is very similar to the previous one. The main difference lies in OD position which is a part of OD driver module now. Every other part of slave remain the same. OD driver module is compiled from source code generated by EDS parser from the slave EDS, HDS and the empty OD driver template.

Benefits of the kernel space solution

• Faster SDO object processing.

• Slave does not need user space applications to work properly.

• Slave can be implemented to other POSIX compliant real-time OS like RTEMS.

• Suitable for CANopen slave realization in embedded systems.

Disadvantages of the kernel space solution

• OD is static, no objects can be added or removed.

• EDS parser can not explore OD any more. The diagnostic pipe has to be used for that purpose and all the information must be communicated through SDO API and slave FSM.