電子發燒友App
應用程序接口概況
簡稱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是一種接口，故而是一種抽象。
#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這允許廣播讀取總線上的所有系統時間差寄存器以獲得向上近似
工商網監
評論