正如前文所述，CANopen的適應性在滿足實時應用需求方面發(fā)揮著至關重要的作用。本系列文章的最后一部分將向您展示 CANopen 源代碼配置的技術細節(jié)，以及實現(xiàn)高效實時性能的優(yōu)化方法。

本文將基于虹科CANopen源碼來研究具體示例，從而闡明配置、優(yōu)化和微調(diào)CANopen協(xié)議棧的過程，以滿足高級時間要求和可能的系統(tǒng)約束。

無論您是經(jīng)驗豐富希望提高優(yōu)化技能的CAN系統(tǒng)設計人員，還是希望了解實時CANopen 配置的細微差別的新手，本部分都旨在提供全面的見解和指導，將我們獲得的理論知識轉(zhuǎn)化為實際實施。

01/

不同的CANopen PDO配置及其對響應時間的影響

CANopen PDO（過程數(shù)據(jù)對象）的配置在確定各種應用中的響應時間方面起著至關重要的作用。根據(jù)所需的響應時間和跨多個節(jié)點同步信號的必要性，可以應用不同的PDO觸發(fā)機制。

100ms響應時間

對于所需響應時間為100毫秒或更長的應用，通常有兩種運行良好的配置方法（也可以組合使用）：

PDO按事件時間觸發(fā)（循環(huán)傳輸）：這里，PDO以指定的時間間隔循環(huán)傳輸，例如每50ms。這種周期性傳輸確保了一致的響應時間。

帶禁止時間的狀態(tài)變化(COS)檢測：此配置根據(jù)狀態(tài)變化傳輸PDO，傳輸之間具有最短時間（禁止時間）。該禁止時間確保切換輸入不會產(chǎn)生back-to-back消息。

使用 CANopen Architect 進行 PDO 配置

上面的屏幕截圖顯示了使用100ms事件觸發(fā)和25ms禁止時間相結合的TPDO1設置。如果TPDO中的數(shù)據(jù)沒有變化，則每100ms傳輸一次。如果確實發(fā)生變化，傳輸速度會更快，但永遠不會快于25毫秒。類似地，TPDO2和TPDO3每200ms傳輸一次。狀態(tài)改變(COS)時，它們的傳輸頻率更高，但速度不超過50毫秒。

更短的響應時間或跨多個節(jié)點的同步信號

對于需要較小響應時間或需要跨多個節(jié)點同步信號的應用，SYNC 模式成為首選方法。

SYNC模式：在此配置中，一個SYNC生成器以穩(wěn)定的重復間隔（例如每10毫秒）生成SYNC CANopen消息。此SYNC消息用作觸發(fā)機制，網(wǎng)絡中的所有設備使用它來同時同步應用數(shù)據(jù)。

高級SYNC：使用CANopenSYNC模式時，您可以利用兩個高級功能。首先，大多數(shù)SYNC消費者允許使用SYNC CAN消息標識符的配置。因此，您可以將系統(tǒng)配置為使用多個SYNC觸發(fā)消息，并選擇哪些設備對哪個觸發(fā)做出反應。其次，最新版本的CANopen支持使用帶有集成可配置計數(shù)器的SYNC。例如，可以將其配置為計數(shù)到4。在SYNC使用者端，您可以配置每個使用者偵聽的計數(shù)值，再次提供對設備進行分組以對系統(tǒng)上的特定SYNC做出反應的選項。

選擇正確的PDO配置對于實現(xiàn)最短的響應時間至關重要。雖然循環(huán)傳輸和具有禁止時間的COS檢測適用于更寬松的響應時間要求，但在處理更嚴格的時間限制或需要同步多個設備時，SYNC模式變得至關重要。

02/

CANopen協(xié)議棧中的數(shù)據(jù)流

下圖說明了CANopen系統(tǒng)中的數(shù)據(jù)流。在最低硬件級別，CAN控制器將接收CAN幀（此處通過連接的收發(fā)器從左開始）。根據(jù)過濾器的不同，它們可能會被放入預先選擇的緩沖區(qū)或隊列中，并且將生成中斷信號。實現(xiàn)處理CAN控制器代碼的處理器（通常是“驅(qū)動程序”）開始處理“CAN接收中斷服務”。更通用的驅(qū)動程序可以實現(xiàn)另一個軟件隊列以供以后處理。每當CANopen協(xié)議處理代碼被觸發(fā)處理接收到的消息時，它就會從驅(qū)動程序獲取消息并更新對象字典。

反之亦然，應用程序可能隨時更新對象字典中的一些過程數(shù)據(jù)以通過CANopen傳輸。這是由CANopen協(xié)議處理程序檢測到的，如果觸發(fā)條件正確，將觸發(fā)傳輸PDO并傳遞給驅(qū)動程序，驅(qū)動程序會將其放置在適當?shù)膫鬏斁彌_區(qū)或隊列中。

CAN設備中的數(shù)據(jù)流

請注意，通常這不是單個連續(xù)的代碼流。CAN接收通常在中斷級別進行處理，而CANopen協(xié)議棧處理則不然。

為了保持CANopen協(xié)議棧處于活動狀態(tài)，通常需要頻繁調(diào)用協(xié)議棧函數(shù)，（例如在“main while(1)”后臺循環(huán)中）。該類函數(shù)通常會首先檢查是否接收到 CANopen消息；如果是，則對其進行處理。如果數(shù)據(jù)涉及更新過程數(shù)據(jù)，則通常有一個回調(diào)函數(shù)來通知應用程序新的過程數(shù)據(jù)已到達。

當處理完所有接收到的CANopen消息后，該函數(shù)會檢查是否有任何內(nèi)容需要傳輸。它可以檢測到傳出的過程數(shù)據(jù)被應用程序修改，并根據(jù)定時器的配置和傳輸模式，啟動相應的CANopen消息的傳輸。

此類傳輸通常會傳遞到驅(qū)動程序級別，可能會傳遞到傳輸隊列中，并且具體何時將此CANopen消息傳遞到CAN控制器進行傳輸取決于驅(qū)動程序配置。

基本配置和控制選項

除非所需的處理和響應時間小于100毫秒，否則這樣的數(shù)據(jù)流對于大多數(shù)應用程序來說已經(jīng)足夠好了。如果所需的響應時間變短，您應該開始考慮可能的優(yōu)化。在查看上面的通用數(shù)據(jù)流時，可能的優(yōu)化包括：

針對接收的CAN驅(qū)動程序優(yōu)化：芯片制造商（甚至CANopen協(xié)議棧提供商）提供的許多默認驅(qū)動程序可能無法充分利用CAN控制器的特定功能。第一個可能的優(yōu)化檢查之一是確保在可能的情況下利用硬件接收過濾和硬件接收緩沖區(qū)或隊列，從而消除對長延遲軟件接收隊列的需要。

針對傳輸?shù)腃AN驅(qū)動程序優(yōu)化：在優(yōu)化之前，請考慮該設備是否可以連續(xù)傳輸盡可能多的CAN幀，或者是否應該對傳輸進行某種程度的節(jié)流以確保沒有任何單個設備可能會產(chǎn)生太長時間的高優(yōu)先級back-to-back流量。如果應該對其進行限制，請考慮實施基于計時器的傳輸觸發(fā)，例如需要每毫秒傳輸一個CAN幀，則我們可以使用1ms定時器中斷來執(zhí)行此操作，通過相應Check函數(shù)檢查傳輸隊列中是否有內(nèi)容。如果是，則在此調(diào)用周期中僅將一個報文幀傳遞到傳輸緩沖區(qū)，從而將傳輸頻率限制為每毫秒最多一次。如果需要更快的吞吐量，則可以使用更快的中斷，或可以考慮使用前文提到的協(xié)議棧處理函數(shù)"Process()"的方法。

協(xié)議棧處理函數(shù)

有關協(xié)議棧處理的一個典型問題是，應該多長時間調(diào)用一次，最壞情況下的執(zhí)行時間是多少。有些人喜歡從固定的定時器中斷而不是后臺循環(huán)中調(diào)用它。這些問題沒有通用的答案。常見做法是：

while (Process());

這將不斷重新調(diào)用該函數(shù)，直到所有待處理的CANopen任務都已執(zhí)行完畢。

直接任務觸發(fā)

協(xié)議棧處理函數(shù)主要是為那些不想深入了解從內(nèi)部執(zhí)行的所有CANopen任務的詳細信息的人提供服務。當然為了進一步優(yōu)化，我們也可以直接實現(xiàn)更具體的協(xié)議棧功能函數(shù)，比如RxPDO和TxPDO，或者是基于毫秒計時器實現(xiàn)的計時觸發(fā)函數(shù)等，從而可以更精確地調(diào)整性能和響應能力。

03/

CAN驅(qū)動程序、CANopen協(xié)議棧和應用

在大多數(shù)基于32位的微控制器上，到目前為止討論的增強功能適合將總響應時間降低到10毫秒到“幾毫秒”的范圍。這可以在不需要優(yōu)化的情況下實現(xiàn)，而優(yōu)化可能會導致完全自定義的實現(xiàn)，而這種實現(xiàn)可能難以維護。這些優(yōu)化僅限于在需要時利用單獨觸發(fā)的CANopen堆棧進程。

一般來說，這可以進一步進行。然而，在系統(tǒng)的這種內(nèi)在級別上進行更改可能會使維護或在必要時移植到不同的體系結構變得更具挑戰(zhàn)性。因此，以下內(nèi)容更多的是說明“理論上可能的情況”，將優(yōu)化推向超出系統(tǒng)易于測試、維護和移植的范圍。

在最低硬件級別，檢查您的CAN控制器是否配置為通過接收SYNC消息直接創(chuàng)建CAN接收中斷，以及您是否可以輕松檢測到與任何其他CANopen消息（例如自己的過濾器/接收緩沖區(qū)）的差異。

為了進一步提高實時性，唯一合理的CANopen PDO通信模式是CANopen SYNC模式。如果使用它并且我們集中精力優(yōu)化它，那么之前的其他優(yōu)化可能會變得多余。

專注于SYNC優(yōu)化需要我們修改CAN接收中斷服務例程，以便在收到SYNC信號時直接調(diào)用負責SYNC處理的CANopen堆棧函數(shù)。當從中斷服務程序中執(zhí)行此操作時，請記住：

不要將此SYNC存儲在常規(guī)接收隊列中（我們已經(jīng)處理過它）。

對于SYNC相關的發(fā)送和接收數(shù)據(jù)，將調(diào)用應用程序的回調(diào)函數(shù)——仍然在中斷服務級別執(zhí)行。

• 當使用RTOS時，更好的解決方案是在收到SYNC的中斷中設置觸發(fā)信號，隨后在中斷完成后立即觸發(fā)執(zhí)行任務。

通過這樣的修改，可以實現(xiàn)毫秒內(nèi)的響應時間。如果參與SYNC通信的所有設備都以相同的優(yōu)化來實現(xiàn)SYNC處理，則設備之間的變化（例如，當它們各自同步應用其輸出時）可以低至幾微秒。

然而，這些都是在測試和實驗室環(huán)境中觀察到的極端值。對于要求如此短響應或同步時間的實際應用程序，需要仔細測試以確保在所有實際情況下都能達到這些目標。

全文總結

通過戰(zhàn)略選擇來應對復雜性

硬件選擇

所需的響應時間決定了所需的硬件功能，影響對模塊、可能是微控制器和其他重要組件的決策。

操作系統(tǒng)注意事項

無論是使用 RTOS 還是實現(xiàn)更具體的定制系統(tǒng)，響應時間都會嚴重影響操作系統(tǒng)的配置方式。

網(wǎng)絡技術

根據(jù)所需的吞吐量和速度，必須考慮不同的網(wǎng)絡協(xié)議和技術。作為一個例子，本系列研究了CANopen及其配置的細節(jié)，說明了滿足不同應用需求所需的細微選擇。

優(yōu)化選擇

也許最深刻的見解之一是認識到優(yōu)化并不是一種萬能的方法。根據(jù)所需的響應時間，某些優(yōu)化變得至關重要，而其他優(yōu)化則可以繞過。這是一個微調(diào)的問題，了解哪些內(nèi)容需要利用，哪些內(nèi)容可以在不影響性能的情況下保持不變。

戰(zhàn)略無知

與利用一切可能的優(yōu)勢的本能相反，在某些情況下，時間框架允許故意忽略某些優(yōu)化。并非網(wǎng)絡控制器提供的每個寄存器都需要被利用；這是性能和特定應用程序的需求之間的平衡。

虹科是一家在工業(yè)自動化領域，特別是工業(yè)總線通訊行業(yè)經(jīng)驗超過15年的高科技公司，在CAN、CAN FD、CANopen通訊領域，虹科可提供CAN卡、中繼器、路由器、總線記錄儀、網(wǎng)關、IO模塊、熱電偶模塊、芯片及軟件等一站式解決方案，歡迎聯(lián)系虹科了解更多信息！