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.
|
Do It Yourself Development |
CANopenIA
Chips or Modules |
CANopenIA
Binaries |
|
Longest learning curve and development time |
Shortest learning curve and development time |
Short learning curve and development time |
|
High start-up cost due to many one-time purchases
such as development tools and source code |
Low
start-up cost due to minimal one-time purchases |
Low start-up cost due to minimal one-time purchases |
|
Low price per node in high volume applications |
High
price per node for high volume applications |
Low price per node, mostly independent from volume |
|
High price per node for lower volume applications |
Low
price per node in lower volume applications |
Low price per node, mostly independent from volume |
|
Biggest flexibility in regards to hardware design |
Limited flexibility in regards to hardware design |
High flexibility in regards to hardware design |
|
Biggest flexibility in regards to CANopen features
and customizability |
CANopen features are pre-selected for typical usage |
CANopen features are pre-selected, but also
customizable on request |
In summary a CANopen development using CANopen 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.
The CANopenIA binaries offer the most benefits. The development cycle is
drastically shortened and the one-time purchases heavily reduced.
