Implementation of CANopen and CANopen FD
For the implementation of CANopen and CANopen FD in embedded devices protocol stacks are used, which are usually offered in form of company or site licenses. HMS offers in cooperation with the company emtas comprehensively tested and ANSI-C compatible CANopen and CANopen FD protocol stacks. The stacks are available for "Slave", "Master/Slave" or "Manager" devices and proven in many applications.
To connect the CANopen or CANopen FD stacks to multiple CAN controllers and CPU types, a well-defined driver interface is used. Using this driver interface the stacks can also easily be adapted to new CAN controllers or CPU types. The stacks can be used stand-alone or with various Realtime Operating Systems such as ThreadX, FreeRTOS, Keil RTX or TI-RTOS as well as with Linux (SocketCAN, can4linux), QNX or with Real time extensions for Windows.
Learn more about the available stack variants and the supported compilers and CPUs on the Ixxat webpage.
Structure of the CANopen protocol software
What does implementation of CANopen involve?
HMS supplies its protocol stacks with comprehensive documentation and sample programs. Project files are supplied with the sample programs that allow direct integration into the corresponding development environments of the compiler manufacturer.
The implementation is carried out as follows:
- Adaptation to the hardware of the target platform (Timer, Interrupt system)
- Creation of object dictionary entries
- Adaptation of configuration file
- Compiling and testing
Early CANopen implementations on the target system can be set-up within a few days.
Alternatively, implementation can also be carried out by HMS. In this case, the requirements are specified together with the customer and then implemented by HMS. As the implementation is carried out by experienced engineers who are familiar with the software, this represents a low-cost, fast alternative to self-implementation.
Available tools for development, configuration and testing
Useful tools for development and start-up, such as the Ixxat canAnalyser or the emtas CANopen DeviceExplorer and DeviceDesigner can be found on the Ixxat webpage.
Develop or buy?
Time and again there are developers who consider whether they should develop the CANopen or CANopen FD protocol software themselves, because the specifications are freely available without license costs and there are also several open source initiatives to date. Of course this is an interesting development challenge. However, from an economic point of view it is not at all worthwhile, as mature CANopen and CANopen FD protocol software is offered nowadays by several manufacturers at very attractive prices.
For the development of a sufficiently tested and documented protocol stack a development time of at least 4 to 6 months is to be expected, even if the full functional scope of the specifications is not implemented. However, it remains to be seen whether an "initial implementation" is already a sufficiently optimized, fault-free product and whether the "subtleties" of the not exactly straightforward CANopen specification are correctly implemented. The possible setting up of free or open implementations does little to change this fact. Most of these approaches are only really of interest for training or other non-commercial environments.
If we assume that an in-house development of a CANopen protocol stack could be accomplished within 4 man months, at an hourly rate of EUR 60, the costs for such a development would be more than EUR 35.000. However this is a very optimistic estimation and a well tested and reliable solution supplied as source code off the shelf is available for a fraction of this price. Therefore an in-house development of a CANopen protocol stack is completely uninteresting from an economic point of view, including the time-to-market.