The latest Target-Os (TgtOs) interface for SYS TEC’s CANopen stacks enables a protocol integration on operating system based target platforms. It is available for Linux/POSIX, Windows, and embOS-based target systems.
Many CANopen applications should be integrated on target platforms, where an operating system (OS) is running and the CANopen process interacts only as one of many other different processes on that system. Most of the available CANopen protocol stacks on the market are working based on the polling method, which the CANopen stack does not internally call any OS-specific API (application programming interface) function. The application has to take care that the process function is cyclically called with short delays to reduce the jitter for the communication over the CAN network.
The application is also responsible for the synchronization of the shared data. The bottleneck of this method is often the high CPU processor load, which is resulting in a longer reaction time of the CANopen applications. In order to offer the possibility of implementing multi-threaded applications and to use the advantages of an operating system, the software provider has developed the TgtOs interface, which acts as a uniform API interface to the different operating system functions. The CANopen stack only calls the functions of the TgtOs interface and is therefore independent of any operating system. The actual functions of the operating system are implemented within the TgtOs-function set.
By calling the INIT-function, the CANopen stack automatically opens itself a new task. This task handles and processes all events of the CANopen stack. The CANopen application does not have to call the process function. For this purpose, the TgtOs interface for operating systems is used within the CANopen stack. Events that wake up the (internal) CANopen task are: receipt of a new CAN message; a timer is expired (e.g. receipt of a new CAN message); calling a CANopen API-function (e.g. changing of a configuration in the OD). The callback functions are called up in the CANopen application from the context of the (internal) CANopen task. The latest TgtOs interface is available for the company’s CANopen Master & Slave Source Code CiA 301 as well as for the CANopen Manager Source Code CiA 302.
The CANopen protocol stack implements the complete functionality pursuant to the latest CiA 301 as well as CiA 302 draft standard. A library of CANopen manager, master and slave services supports the design of CANopen master or slave devices. This includes NMT master (Network Management), LSS master (Layer Setting Services), and SDO clients. A range of add-on packages is available to extend the runtime functionality, including CANopen manager extensions, safety protocol, and SDO gateways.
The stack is organized in a modular fashion where an individual module can be incorporated into or removed from a project, depending on the required functionality, said the company. The multi-instance support enables different logical CANopen devices to be connected on a single physical hardware platform. Written in ANSI C, with a defined device layer, the stack is portable to a range of the systems.
The API allows for a straightforward use of the CANopen services, without having to dive into the details of its implementation. The package includes example programs, demo projects, and documentation. This provides a step-by-step assistance. In addition, a set of configuration and analysis tools are also available to simplify the overall development, testing and integration of CANopen applications.
News and reports