DeviceNet—开发者指南（译自CIA）

Devicenet开发者必须考虑一些问题如通讯要求，CAN收发器和协议控制器的选择等。设计人员要从DeviceNet协议栈的特点和所使用的开发工具出发，来决定这些事项。市场上的大部分DeviceNet产品都只有从站功能，因此大部分的文章都只讨论从站的开发设计。如果你考虑要设计带有主站功能的产品，我们建议你与一个或几个提供DeviceNet服务的公司联系。
  从站开发中首先要考虑的是I/O通讯的方式。初期，Devicenet只定义了位选通（bit-strobe）和轮询（polled）两种I/O通讯的方式可以在主站中使用。然而，随着一些公司的带有状态改变（COS）或循环（Cyclic）I/O交换方式的主站产品如所有的Allen-Bradley的扫描模块得到应用，即使今天的客户可以不要求这些功能，但在设计的时候也要考虑到这些I/O数据交换方式。
  位选通（Bit-strobe）主要用于传感器设备或其它一些只有很少（1Bit）或没有输出数据（output data）要求的从站。除此外，位选通也用于将输出数据同步送达多个设备。但是，由于选通帧的使用并未在Devicenet协议中被标准化，因此一些设备自身拥有的应用将受到限制。
  轮询（Polling）属于“bread and butter”型的I/O交换方式。由于所有的主站设备都支持这种方式，所以这是开发必须考虑的。
  状态改变（COS）是一种功能很强大的I/O数据交换方式，它能增加网络的吞吐量，降低某一时间的网络负载。这些数据交换方式都允许完全使用CAN协议固有的多主系统能力，因此对于所有新的开发都要考虑到。虽然位选能（Bit-strobe）仅限于最大1bit消耗数据（consumed data）和64bits生产数据（produced data），但轮询，状态改变和循环的I/O数据交换方式都没有这样的限制。如果你的I/O数据要求大于CAN固有的64bits（8bytes）的数据长度，则要考虑分段协议，用户将不必处理任何分段协议的细节，因为所有的分段和重组都由Devicenet协议自动完成。
  尽管分段协议不是必须要支持的，但如果允许在回应显性报文的消息中使用完整的32个字符长的产品名称，则要考虑使用分段协议。如果你支持一些特性如通过Devicenet完成组态下载或固件升级的功能，你就必须使用分段协议来发送和接收报文。
--------------------------------------------------------------------------------
物理层要求
  Devicenet标准允许使用四种连接器：迷你型（mini），微型（micro），开放型（open）和带螺丝终端（screw terminals）。如果可能，使用迷你型，微型，开放型连接器允许随意的即插即用安装。所有非IP65/67的设备都可以使用Phoenix或其它一些厂商的开放型连接器。螺丝终端仅用于不能使用其它连接器的地方。螺丝终端同样支持从网络上断开而不影响主干线。如果你不使用迷你型，微型或开放型连接器，那建议你在早期的开发过程中与一致性测试实验室联系，以考虑他们在连接方法的一致性方面的意见。
  如果你想把SDS（Smart Distributed System）的产品转换为Devicenet或在后期在你的产品上实现SDS协议，那你要知道事实上微型和开放型连接器的开口销与DeviceNet协议不一样。因此，已经存在的SDS和CAN OPEN设备的电路可能不符合DeviceNet的接线保护要求，所以将来可能会必须作修改。DeviceNet所要求的接线保护电路并未被排除在SDS或CANopen环境之外。
  Devicenet只支持125K，250K，500K波特率，而不支持另外一些基于CAN的网络（如SDS和CANopen）所支持的1M波特率，因为此波特率下对网络长度有严格的限制。DeviceNet并不要求三种波特率都支持，尽管不支持所有的波特率的产品在市场上会处于劣势，但DeviceNet并未要求都支持所有的波特率。
  Devicenet对收发器（transceivers）的要求超过了ISO11898的要求，主要是因为DeviceNet的物理节点会扩展到64个。是否使用物理隔离一般是基于你的产品类型的，与外部无电气连接且完全使用总线供电的设备，典型的如传感器就不需要隔离，但与外部有连接的设备几乎都要有物理隔离的。使用隔离光耦要注意，因为这将增加收发器的延迟，协议要求通过光耦的最大延迟时间为40ns，记住使用快速的光耦就意味着低的传送延迟。目前DeviceNet使用的典型器件是500MHz的器件。
  所有的Devicenet节点都要求CAN的收发器部分从总线上获取电源，以保证连接到总线的CAN收发器不会因未加电而影响到总线的数据传送。
--------------------------------------------------------------------------------
CAN协议控制器硬件
  由于有各种不同的CAN芯片和单片机芯片可以使用，所以这里只给出一些通用的做法：
  * 不要使用SLIO。在现今的SLIO设备中，你已经无法用它来实现Devicenet协议规定的最小要求了。
  * 所有使用11-bit确认区的CAN芯片都可以使用。Devicenet网络既不要求使用29-bit长确认区也不允许其存在于网络之中。
  * BasicCAN芯片可以很好的使用在只有group 2 only 的从设备中。协议中的group 2 only的描述对BasicCAN是最优化的。
  * 当使用结合了CAN芯片的微处理器时要将其组件减到最少，这可能只推荐使用于微处理器与CAN芯片集成在一起并精确的符合设备的要求的场合。选择独立于单片机的CAN芯片可以实现更加复杂的设计，在作出选择之前，要考虑到任何一个带CAN芯片的处理器其指令的处理方式。
  * 每一个Devicenet节点都必须支持一个32-bit的序列号（serial number），它是由厂商提供的每台设备都有的唯一识别码。因此，你的设备可能需要非易失可读写存储器，如果你的设备支持可以设定参数，则非易失存储器是必须的。
  * 当CAN控制器复位和加电/掉电的时候要特别注意CAN_H和CAN_L线上的状态。这时CAN芯片将会漂移或被驱动到不同的电平，使总线被驱动为显性。所以使用被动上拉或下拉，设置控制寄存器和在TXD到收发器之间使用逆变器以保证上述情况不会对总线产生不良影响。
  * 不能允许不使用CAN控制器的输入（RX0或RX1）而将其留空。应将其连接到收发器的VCC/2或使用电压分配器，将输入留空基本上一定会引起错误帧。一些CAN控制器也提供一个寄存器来关闭未使用输入的功能，直到不出现这一现象，甚至当引脚被禁止掉也会起作用。
--------------------------------------------------------------------------------
Devicenet协议的软件
  由于没有人一定要从别人那里购买Devicenet软件，所以市场上有各种不同的DeviceNet软件包可以很成功的用来组合成DeviceNet产品。选择使用一个特殊的软件包要考虑其工具的特点和供应商提供的服务支持。定价会成为一个问题，但通常都说你只是支付你获得的部分。
  一些基本的问题必须考虑：
  * 所考虑的软件是否在我的硬件上可以使用？
  * 有没有任何汇编的代码需要重写？
  * 需要重写多少硬件驱动程序？
  * 执行的速度是否符合我的应用要求？
  * 我的应用是否要求所有的通讯方式（I/O和Explicit messaging）？
  * 是否支持分段协议（如果我的应用要求）？
  * 使用什么编译器？我所使用的是否和此编译器相似？
  * 是否支持EDS文件？
  * 我可以从此软件包的供应商获得什么支持？
  这是每个电气设备供应商必须参考的，做出决定应该考虑如下问题：
  * 公司内部是否有足够的基础技术，如CAN和单片机技术？
  * 这是一次性的工作呢，还是可以按自己的期望对产品进行更深的修改？
  简单的从站可以很容易实现（一些公司可以在几星期内实现基本的设备功能），但对于更复杂的设备，尤其是带主站功能的设备，建议你在商业软件包的基础上进行设计。
--------------------------------------------------------------------------------
组态（configuration）需求
  EDS （Electronic Data Sheet）是一种用于Devicenet设备组态的强有力工具，无论你的设备可能没有或是很少有参数可以通过网络访问来进行修改，都强烈推荐你生成EDS文件。
  设备的组态可以分为两个部分，第一部分是与网络通讯相关的参数设定，包括波特率和MAC ID。许多设备通过拨码开关来设定其参数，而另外一些设备可以通过Devicenet连接来访问这些参数，这在Allen-Bradley DeviceNet管理软件里被称为“device commissioning”。一些产品支持自动波特率侦测，对于用户来说这使用起来会简单些，但显然必须要有些设备能够先在网络上建立一个固定的波特率。换句话说，自动波特率侦测必须要求至少有一个节点设定了一种波特率，或预先配置了一种波特率。出于此原因所以建议主站设备不要使用自动波特率侦测以提供给网络一个可参考的波特率。
  另一部分是设备组态的主要部分，即与应用相关的参数设定。如果一个设备的EDS被配置后，所有的参数（可写的和只读的）都会以文本或帮助指令的开式集中显示。可以用通俗的方式和实际的格式来修改参数，且bits和bytes不会混乱。设备“增强配置”中的参数显示也可以在线监视参数的实际值，对参数的监视反映了通过EDS参数列表来对参数进行访问。然而，这些参数可以通过显性报文来读取，因此快速的传送可能丢失但静态值则不会出现问题。
  EDS文件非常容易编写，如果一个产品支持参数类（parameter class）的实例，可以通过Devicenet管理软件来在线生成EDS文件。DeviceNet规范第二卷第四章包括了如果生成这个文件的细节和例子。
--------------------------------------------------------------------------------
一致性测试
  一致性测试可以由ODVA测试实验室来完成。测试包括了协议兼容性，也包括物理层的兼容性，结果分为通过或失败。互操作性测试也在进行，但目前还没有正式的测试步骤。互操作性的测试的结果会提交给供应商，但不会有通过或失败的定义。
  尽管强烈推荐你进行一致性测试，且有些用户明确要求，但ODVA或Devicenet并不强迫你做任何一致性测试。通过一致性测试将增强你的用户对你的产品的信任，且可以帮助你开发更好的产品。一致性测试分为两步：
  第一步，设计者使用一致性测试软件（可从ODVA获得）的描述工具描述产品所具有的对象的细节。这个描述是一致性测试软件对产品所具有的协议特性进行测试所必需的。自从一致性测试软件可以运行于开发模式，可以对协议某个部分进行测试以来，开发者就可以在开发的过程中进行预测试。强烈建议在代码调试的早期就开始使用一致性测试软件。一致性特别兴趣小组把它看着是一开发工具，同时也是协议确认工具。
  如果产品通过开发实验室的测试，就可以进行第二步，在ODVA注册产品的一致性测试，然后开发者必须联系其中一个ODVA测试实验室以安排测试会议，开发者并不必一定参加实际的测试，不过建议参加实际测试以可以快速排出一个小问题。
  如果产品通过测试，ODVA将发布测试结果，如果测试不通过，则只有测试实验室和ODVA知道结果。
--------------------------------------------------------------------------------
开发工具
  这部分内容不是提供开发产品所必需的工具的完整列表，只是指出一些所必须的工具的类型。
  通常假设你充分具备了单片机开发的技术，因此，此部分将只讨论Devicenet（CAN）相关的工具。
  作为最小开发系统，你需要一个CAN监视器，典型的为一张插入PC的CAN卡及配套的应用软件。兼容PC的Devicenet卡可以从一些公司获得如Softing, STZP, Huron Networks, SST或是其它一些公司。参考最新的ODVA产品列表或在线列表，可以找到一个完整的提供这种卡的厂商列表，性能与报价各有不同，确认他的产品与你的PC的兼容性及在这张卡上运行的软件的类型后，再作出选择。
  Devicenet或CAN监视软件包有不同的价格和性能，Allen-Bradley的从站开发工具是典型的低端工具，而Vector的CANalyzer显然是一商端的工具，价格比Allen-Bradley产品高出十倍，通常一分钱一分货。因此，一个低端的工具可能是一个好的起点，在整个简单产品的开发中都可以使用，但对于复杂的产品当然得使用更加强大的工具。再次强调，ODVA产品列表（文档或在线版本）是很好的信息来源，如果你只从事CAN级的工作，则有很多公司提供支持CAN第二层协议的监视器，CiA（CAN in Automation）可以帮助你。
  一旦你的产品可以操作了，你可能想把产品放到更典型的工业控制环境中运行，首先你应该把产品放到将来产品所要用到的典型环境中运行。包括在组态工具中运行，看看你的产品如果回应显示报文请求以改变你的设备的可配置属性值。这也可以检查EDS文件是否正确。
--------------------------------------------------------------------------------
最小模式要求
  Devicenet是一个限制很少的很开放的网络，但某些原则在开发开始之前也应该考虑到，且在产品投放到市场之前必须遵守。
  唯一的注册要求是注册厂商ID号，厂商ID号必须与现有产品的厂商号不同，购买协议规范后你可以从ODVA获得你的厂商号，标记包括同意使用的时间并返回给ODVA。一旦你收到你的厂商ID号，则必须在你的公司的所有产品中使用，不同的分公司可以申请不同的厂商ID号，但他们必须分别购买协议规范并标明同意使用的时间期限。
  无一致性测试的ID号可能被取代，除非ODVA已经将此ID号分配给你的公司