CANopen源代码
CANopen主要基于CAN应用协议，它是属于OSI七层模型中的应用层以上的协议。相当于它对物理层CAN再进行了一次协议封装，作为一个标准并开放出来，这样每个厂家可以用这个协议彼此通讯，提高互操作性和兼容性。
CANopen源代码是指可以用来下载到带CAN控制器的MCU上的应用程序，用来完成CANopen的通讯协议解析、产品的应用/功能逻辑。CANopen源代码编写之前要先了解它的结构和重要概念。
可以考虑基于开源代码或者商业版代码来开发，几个简单的区别：
1、费用：开源代码免费；商业版代码收费，但节省了很多研发人员和测试人员的时间，节省了很多人力成本。
2、技术支持和文档：商业版有人负责解答也有培训，有完整的操作文档和手册，开源无人解答--问题解决的几率小。
3、代码质量和稳定性：商业代码的质量、优化和效率有保证；使用开源代码存在很大风险；
4、开发难度和时间：商业版有完整的多款不同硬件平台的样例程序，大大降低开发移植难度和时间。开源代码的研发工作量增加、后期测试难度和时间也增加。
5、研发/测试工具：商业版有完整的工具链和测试方法提供。完整的测试工具包括：网络组网和管理以及测试（导入EDS文件组网并修改对应的数据，PDO mapping）、报文分析、快速创建对象字典 生成EDS文件、USB-CAN卡采集数据等等。
7、支持的MCU平台demo丰富：SO-877-VP或者SO-1063-VP提供30多种不同MCU平台的demo，并且每年不断更新和增加。
如果要做serious的产品，一般用商业版的代码更有保障。
介绍
从OSI网络模型的角度来看同，现场总线网络一般只实现了第1层（物理层）、第2层（数据链路层）、第7层（应用层）。因为现场总线通常只包括一个网段，因此不需要第3层（传输层）和第4层（网络层），也不需要第5层（会话层）第6层（描述层）的作用。
CAN（Controller Area Network）现场总线仅仅定义了第1层、第2层（见ISO11898标准）；实际设计中，这两层完全由硬件实现，设计人员无需再为此开发相关软件（Software）或固件（Firmware）。
同时，CAN只定义物理层和数据链路层，没有规定应用层，本身并不完整，需要一个高层协议来定义CAN报文中的11/29位标识符、8字节数据的使用。而且，基于CAN总线的工业自动化应用中，越来越需要一个开放的、标准化的高层协议：这个协议支持各种CAN厂商设备的互用性、互换性，能够实现在CAN网络中提供标准的、统一的系统通讯模式，提供设备功能描述方式，执行网络管理功能。
应用层（Application layer）：为网络中每一个有效设备都能够提供一组有用的服务与协议。
通讯描述（Communication profile）：提供配置设备、通讯数据的含义，定义数据通讯方式。
设备描述（Device proflile）：为设备（类）增加符合规范的行为。
下面的章节将介绍基于CAN的高层协议：CAL协议和基于CAL协议扩展的CANopen协议。CANopen协议是CAN-in-Automation(CiA)定义的标准之一，并且在发布后不久就获得了广泛的承认。尤其是在欧洲，CANopen协议被认为是在基于CAN的工业系统中占领导地位的标准。大多数重要的设备类型，例如数字和模拟的输入输出模块、驱动设备、操作设备、控制器、可编程控制器或编码器，都在称为“设备描述”的协议中进行描述；“设备描述”定义了不同类型的标准设备及其相应的功能。依靠CANopen协议的支持，可以对不同厂商的设备通过总线进行配置。
在OSI模型中，CAN标准、CANopen协议之间的关系如下图所示：
CAL协议
CAL（CAN Application Layer）协议是目前基于CAN的高层通讯协议中的一种，最早由Philips医疗设备部门制定。现在CAL由独立的CAN用户和制造商集团CiA（CAN in Automation）协会负责管理、发展和推广。
CAL提供了4种应用层服务功能：
CMS (CAN-based Message Specification)
CMS提供了一个开放的、面向对象的环境，用于实现用户的应用。CMS提供基于变量、事件、域类型的对象，以设计和规定一个设备（节点）的功能如何被访问（例如，如何上载下载超过8字节的一组数据（域），并且有终止传输的功能）。
CMS从MMS (Manufacturing Message Specification)继承而来。MMS是OSI为工业设备的远程控制和监控而制定的应用层规范。
NMT (Network ManagemenT)
提供网络管理（如初始化、启动和停止节点，侦测失效节点）服务。这种服务是采用主从通讯模式（所以只有一个NMT主节点）来实现的。
DBT (DistriBuTor)