Comparison of CANopen Development Solutions
When developing a CANopen node, engineering can choose between several options on how to get CANopen functionality into their system. The software handling the CANopen protocol could be developed from scratch or using a commercial source code package. Other options include the integration of CANopen hardware, such as the CANopenIA chips or modules. Another solution is using a CANopen binary that implements one or multiple CANopen device profiles for a specific microcontroller.
The following table compares the methods of developing the software from scratch with using CANopenIA solutions.
| Development and Design Criteria | Do It Yourself Development | Use CANopenIA Solutions |
|---|---|---|
| one-time purchases | high (tools and possibly code) | low or none |
| learning curve | in-depth knowledge required | only basic CANopen knowledge required |
| hardware development | in-depth knowledge required | minimal |
| software development | in-depth knowledge required | minimal or none |
| CANopen features | high flexibility and customizability | configurable, customization through ESAcademy |
| future change of physical layer | use of CAN-FD or Ethernet requires new HW design | possibly by exchange of chip or module |
| real-time behaviour | must be ensured by custom application software | ensured by CANopenIA implementation |
| security | must be ensured by custom application software | increased due to separation of CANopen software and application |
In summary a CANopen development using CANopen own or purchased source code should only be considered for high-volume applications where the large number of systems sold justifies the high start-up costs and long development cycles. In all other cases, CANopenIA offers drastically shortened development cycles and reduced one-time purchases.
