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.