canopen开发中常见的问题.docVIP

SDO是CANopen协议中最复杂的一部分，带有应答机制，有多种传输方式，并且完整的SDO功能节点需提供1个SDO server和多个SDO client，因此SDO的实现异常困难，协议多种传输方式的解析处理还有迹可循，多个SDO client服务和多个对SDO server的访问的协调就不容易了，这里介绍一种方法——SDO线程来解决。 注意，这里的线程可不是操作系统提供的多线程技术，况且为保证协议栈良好的移植性，在CANopen协议栈核心代码里中也不好去调与操作系统相关的库函数。我们这里的SDO线程只是借鉴了操作系统多线程机制的一套SDO服务处理方法，每个SDO线程表示的是与网络上其他节点建立的一个SDO链接，相当于在两个节点间建立一个SDO通讯路径，其中每个节点都拥有一个对这个路径的描述，在该节点看来好像建立了一个线程来负责这个路径（但决不会真的创建一个系统线程），在通讯过程中双方通过这个路径来交流，SDO通讯结束则释放该线程，每个节点可以同时与多个节点建立多个这样的路径和互不影响，就如同操作系统的线程机制一样的效果。我们知道每建立一个线程都会生成一个描述线程属性的参数表和一些私有数据，类似的，SDO线程的建立也会初始化一个对应的参数和数据结构体——SDO线程参数表，以之来描述这个SDO链接的属性并提供私有通讯数据的存储。 SDO线程参数表可以说是SDO线程的核心，所有SDO线程的建立、删除和SDO通讯都要涉及到这个参数表。参数表内容包括能够描述一个SDO访问过程的所有参数，这里不详述。 一次SDO访问是这样完成的。首先SDO发起节点(SDO client)收集足够的信息，建立一个SDO线程，说白了就是初始化SDO线程参数表，将收集的信息以特定格式放入参数表，形成一帧SDO请求，发送出去。SDO服务节点(SDO server)收到这帧请求，为它建立一个SDO线程，将这帧请求分析分解以获得足够信息来初始化这个SDO线程对应的参数表，然后程序就会按照参数表的描述去执行server的功能收集数据来满足这个SDO请求，然后将收集到的数据形成SDO应答帧返回给SDO client，如果此次请求结束则释放该线程，否则等待下一帧请求到来；SDO client在收到应答后判断该请求是否还有后续请求，无则释放此SDO线程。如果在这个过程中，SDO server 和SDO client所在节点有收到其他节点的SDO请求或需要通过SDO请求其它节点，则新建SDO线程来实现，跟上面的步骤一样，这样就可以实现多个SDO server和SDO client服务都得到实现而互不干扰，相当于双向多线铁路，可比单线爽多了。 怎样利用好单片机上的存储器资源来实现OD的存储与访问 我们知道OD(对象字典)是CANopen的核心，所有功能都是围绕它开展的，是协议栈的数据中心，良好的OD实现是协议栈高效稳定运行的基础，而OD的实现最基本的一点就是怎么去保存它。因为OD的内容比较杂，读写属性上，有只读数据、只写数据、可读写数据；保存要求上有非易失和掉电丢失两种类型；数据类型上有字符型、整型、长整型等等；存储格式上有8位、16位、32位等。其它的不管，本文现只讨论怎么利用单片机的资源去尽量满足OD的存储需求。 有人会以为这还要讨论么？只读的就放在只读存储器中，可写的就放在RAM中，需要掉电保存的就放在非易失可读写存储器中。话是这么说，但实际上问题很多，罗列如下： 1． 对协议栈只读并不表示对应用程序只读。 2． 可读写而又掉电保存的数据不能放在RAM里。 3． 频繁读写的数据不能放在非易失存储器中，因为非易失存储器往往速度慢，有写次数限制。 4． 单片机资源有限，存取方式和读写速度有限值，因此得合理利用。 既然有这些问题，我们先对OD的数据进行分析分类： 1． 系统只读参数。自节点出厂就无需更改，例如，节点硬件序列号、软硬件版本等。 2． 过程数据对象。频繁读写，掉电无需保存。例如，采集的模拟量、待输出的开关量。 3． 系统配置参数。可读写，偶尔配置，大部分时间只读。 基本上所有的OD对象都可以归到这三类中去。下面再以AVR单片机为例说说单片机的几类存储资源以及其特点： 类型 运行中读写属性 访问速度 容量 特点 FLASH 程序存储器 只读 一般 较大 操作方便但只能放程序和初始化只读数据，掉电不丢失 SRAM 数据存储器 读写 最快 小 操作方便，速度快，掉电数据丢失 EEPROM 数据存储器 读写 读一般，写很慢 小 操作复杂，写速度极慢 看到上面这个表，你会马上把OD的三类数据存放位置定下来吧，系统只读参数放在FLASH中；过程数据对象放在SRAM中；系统配置参数放在EEPROM中。 实际上确