什么是应用程序接口_应用程序接口有什么作用

　　 应用程序接口概况

　　简称API（Application Programming Interface），就是软件系统不同组成部分衔接的约定。

　　在数据封装时，网络分层中的每个层相互之间会用接口进行交互并提供服务，其中应用层与用户之间的接口称之为应用程序接口。API实际上是一种功能集合，也可说是定义、协议的集合，无论是那种集合，它的实质都是通过抽象为用户屏蔽实现上的细节和复杂性。

　　从用户角度看应用程序接口，表现为一系列API函数，用户可以使用这些函数进行网络应用程序开发。从网络角度看，应用程序接口给用户提供了一组方法，用户可以使用这组方法向应用层发送业务请求、信息和数据，网络中的各层则依次响应，最终完成网络数据传输。

　　API的作用：

　　1.远程过程调用（RPC）：通过作用在共享数据缓存器上的过程（或任务）实现程序间的通信。

　　2.标准查询语言（SQL）：是标准的访问数据的查询语言，通过通用数据库实现应用程序间的数据共享。

　　3.文件传输：文件传输通过发送格式化文件实现应用程序间数据共享。

　　4.信息交付：指松耦合或紧耦合应用程序间的小型格式化信息，通过程序间的直接通信实现数据共享。

　　原理：

　　API是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

　　常见应用程序接口

　　应用层的应用程序接口有很多，并且发展很快，比较常见的如socket、FTP、HTTP以及telnet。这些接口从大类上可分为四类：

　　远程过程调用（RPC，Remote Procedure Call Protocol）

　　数据查询接口

　　文件类接口

　　数据通信接口

　　例如FTP协议就是文件类接口，基于FTP，用户可以实现文件在网络间的共享和传输。而socket和HTTP可归结为数据通信接口，基于这两种接口，用户可以开发网络通信应用程序，以及web页面交互程序。当然如果从编程开发角度看，无论是FTP、HTTP还是telnet，都是基于socket接口开发出来的应用层协议，是对socket接口的进一步封装和抽象，从而为用户提供更高一层的服务和接口。

　　socket有时称之为“Berkeley Socket”，它是最早由伯克利开发的应用程序接口。常用的socket类型有两种：流式socket（SOCK_STREAM）和数据报式socket（SOCK_DGRAM）。

　　流式socket是一种面向连接的socket，针对于面向连接的TCP服务应用。

　　数据报式socket是一种无连接的socket，对应于无连接的UDP服务应用。

　　从用户接口意义上讲，还有传输层的TLI接口，是由AT&T开发的，有时也称作XTI。它是传输层为用户提供的应用程序接口，可以用来在传输层进行应用开发。

　　API之主要目的是提供应用程序与开发人员以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。提供API所定义的功能的软件称作此API的实现。API是一种接口，故而是一种抽象。

#p##e#

　　以下部分包含应用程序接口的一般说明

　　每个应用程序应该通过两个步骤使用主站：

　　配置  请求主站并应用配置。 例如，创建域，配置从属并注册PDO条目（请参见第3.1节）。

　　运行  运行循环代码和交换过程数据（参见第3.2节）。

　　应用程序示例 在主站代码的examples /子目录中有一些示例应用程序。 它们被记录在源代码中。

　　3.1 主站配置

　　总线配置通过应用程序接口提供。图3.1给出了可由应用程序配置的对象的概述。

　　总线配置通过应用程序接口提供。图3.1给出了可由应用程序配置的对象的概述。

　 

　　3.1.1 从站配置

　　应用程序必须告诉主站有关预期的总线拓扑。这可以通过创建“从站配置”来完成。从站配置可以看作是预期的从站设备。当创建从站配置时，应用程序提供总线位置（见下文），供应商ID和产品代码。

　　当应用总线配置时，主站会检查，在给定位置是否存在给定供应商ID和产品代码的从站。如果存在，从站配置将“附加”到总线上的实际从站，并根据应用程序提供的设置配置从站。从站配置的状态可以通过应用程序接口或通过命令行工具查询。

　　从站位置 从站位置必须指定为“别名”和“位置”的元组。允许通过绝对总线位置或通过保存的称为“别名”的标识符或两者的混合来对从站寻址。别名是存储在从站E2PROM中的16位值。它可以通过命令行工具进行修改。表3.1显示了如何解释这些值。

　　别名位置解释

　　00-65535位置寻址。 位置参数被解释为总线中的绝对环位置。

　　1-655350-65535别名寻址。 位置参数被解释为在具有给定别名地址的第一从站之后的相对位置。

　　图3.2显示了如何连接从站配置的示例。添加了一些配置，而其他配置保持分离。下面的列表给出了从最高开始的各从站配置的原因。

　 

　　1. 别名为0意味着使用简单的位置寻址。 从站1存在，并且供应商ID和产品代码与预期值匹配。

　　2. 虽然找到了位置为0的从站，但产品代码不匹配，因此不添加配置。

　　3. 别名非0，因此使用别名寻址。 从站2是别名为0x2000的第一个从机。 由于位置值为0，因此使用相同的从站。

　　4. 没有具有给定别名的从站，因此无法添加配置。

　　5. 从站2再次是别名为0x2000的第一个从机，但位置现在为1，因此添加从站3。

　　如果主站源代码配置了–enable-wildcards，则0xffffffff将匹配任何一个供应商ID和/或产品代码。

　　3.2 循环操作

　　要进入循环操作模式，必须“激活”主站来计算过程数据映像，并首次循环操作时应用总线配置。激活后，应用程序负责发送和接收帧。激活后无法更改配置。

　　3.3 VoE处理程序

　　在配置阶段，应用程序可以创建第6.3节中描述的VoE邮箱协议的处理程序。一个VoE处理程序总是属于某个从站配置，因此创建函数是从站配置的一个方法。

　　VoE处理器管理VoE数据和用于发送和接收VoE消息的数据报。它包含传输VoE消息所需的状态机。

　　VoE状态机一次只能处理一个操作。因此，一次可以进行一个读或写操作1。操作启动后，处理程序必须循环执行，直到完成。之后，可以检索操作的结果。

　　VoE处理程序具有自己的数据报结构，它将被标记，用于在每个执行步骤之后进行交换。因此，应用程序可以决定在发送相应的EtherCAT帧之前执行多少个处理程序。

　　有关使用VoE处理程序的更多信息，请参阅examples /目录中提供的应用程序接口函数和示例应用程序的文档。

　　3.4并发主站访问

　　在某些情况下，一个主站由多个实例使用，例如，当应用程序执行循环过程数据交换的同时时，存在支持EoE的从站需要与内核交换以太网数据（参见第6.1节）。为此，主站是共享资源，并且对其的访问必须被顺序化。这通常通过锁定信号量或其他方法保护关键部分来完成。

　　主站本身不能提供锁定机制，因为它没有机会知道合适的锁定类型。例如，如果应用程序在内核空间中并且使用RTAI功能，则普通内核信号量将是不够的。为此，作出了一个重要的设计决定：预定主站的应用程序必须具有完全控制，因此它必须负责提供适当的锁定机制。如果另一个实例想要访问主站，它必须通过回调请求总线访问，这必须由应用程序提供。此外，如果应用程序认为实例在当时是不合适的，则可以拒绝对主机的访问。

　　图3.3示例显示了两个进程如何共享一个主站：应用程序的循环任务使用主站进行过程数据交换，而主站内部EoE进程使用主站与具有EoE功能的从站通信。两者都不时访问总线，但EoE进程通过“请求”应用程序

　　访问总线。这样，应用程序可以使用适当的锁定机制来避免同时访问总线。有关如何使用这些回调，请参阅应用程序接口文档（第3章）。

　 

　　3.5 分布式时钟

　　从版本1.5开始，主站支持EtherCAT的“分布式时钟”功能。可以将总线上的从站时钟同步到“参考时钟”（支持DC的第一从站的本地时钟），并且将参考时钟同步到“主站时钟”（主站的本地时钟）。总线上的所有其他时钟（在参考时钟之后）被视为“从站时钟”（见图3.4）。

 

　　本地时钟 任何支持DC的EtherCAT从站都有一个具有纳秒分辨率的本地时钟寄存器。如果从站被供电，则时钟从零开始，这意味着当从站在不同时间上电时，它们的时钟将具有不同的值。这些“偏移”必须通过分布式时钟机制来补偿。另一方面，时钟不是以相同的速度精确地运行，因为所使用的石英单元具有固有的频率偏差。该偏差通常非常小，但是在较长时间段内，误差将累积，而且本地时钟之间的差异将增大。这个时钟“漂移”也必须由DC机制补偿。

　　应用程序时间 总线的公共时基必须由应用程序提供。 使用此应用程序时间的tapp

　　1. 以配置从站的时钟偏移（见下文），

　　2. 以编程从器件的同步脉冲产生的开始时间（见下文），

　　3. 以将参考时钟同步到主时钟（可选）。

　　偏移补偿 对于偏移补偿，每个从站提供一个“系统时间偏移”寄存器toff，它被添加到内部时钟值tint以获得“系统时间”tsys：

　　tsys = tint + toff

　　⇒ tint = tsys − toff

　　主站读取两个寄存器的值，以某种方式计算新的系统时间偏移，结果系统时间应与主机的应用时间tapp匹配：

　　tsys ≅ tapp

　　⇒ tint + toff ≅ tapp

　　⇒ toff = tapp − tint

　　⇒ toff = tapp −（ tsys − toff ）

　　⇒ toff = tapp − tsys + toff

　　由读取和写入寄存器的不同时间产生的小的时间偏移误差将由漂移补偿进行补偿。

　　漂移补偿 由于每个支持DC的从站中有特殊机制，因此可以进行漂移补偿：对“系统时间”寄存器的写操作将使得内部时间控制循环对写入时间（减去编程的传输延迟，见下文）与当前系统时间进行比较。计算出的时间误差将用作时间控制器的输入，根据误差的符号将本地时钟速度调整为稍快或慢一些2。

　　传输延迟 以太网帧从从站到从站需要少量时间。所得的传输延迟时间累积在总线上，并且可以达到微秒级别，因此在漂移补偿期间必须被考虑。支持DC的EtherCAT从站提供一种测量传输延迟的机制：对于四个从站端口中的每一个，有一个接收时间寄存器。从对端口0的接收时间寄存器的写操作开始测量，一旦在相应端口上接收到帧，则当前系统时间被锁存并存储在接收时间寄存器中。主站可以读出相对接收时间，然后计算从站之间的时间延迟（使用主站对总线拓扑的定义），最后计算从参考时钟到每个从机的时间延迟。这些值通过编程被写到从站的传输延迟寄存器中。以这种方式，漂移补偿可以达到纳秒级同步。

　　检查同步性 支持DC的从站在地址0x092c处提供32位“系统时间差”寄存器，其中最后一次漂移补偿的系统时间差以纳秒分辨率和符号-幅值编码方式存储3。为了检查总线同步性，系统时间差寄存器也可以通过命令行工具循环读取（见第7.1.14节）：、

　　$ watch -n0 “ethercat reg read -p4 -tsm32 0x92c”

　　同步信号 同步时钟是总线上同步事件的先决条件。每个支持DC的从站提供两个“同步信号”，其可以被编程以创建事件，这将，例如，使得从站应用程序在某个时刻锁存其输入。同步事件可以一次生成或循环生成，取决于哪种对从站应用程序有意义。编程同步信号设置所谓的“AssignActivate”字和同步信号的周期和移位时间。AssignActivate字是从站确定的，并且必须取自XML从站描述（Device → Dc），其中还可以找到典型的同步信号配置“ OpModes”。

　　1如果需要同时发送和接收，则可以为从配置创建两个VoE处理程序。

　　2本地从时钟将每10 ns以9 ns，10 ns或 11 ns的频率递增。

　　3这允许广播读取总线上的所有系统时间差寄存器以获得向上近似