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

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

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

01/

不同的CANopen PDO配置及其對響應(yīng)時間的影響

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

100ms響應(yīng)時間

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

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

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

使用 CANopen Architect 進行 PDO 配置

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

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

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

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

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

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

02/

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

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

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

CAN設(shè)備中的數(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ù)來通知應(yīng)用程序新的過程數(shù)據(jù)已到達。

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

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

基本配置和控制選項

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

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

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

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

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

while (Process());

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

直接任務(wù)觸發(fā)

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

03/

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

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

一般來說，這可以進一步進行。然而，在系統(tǒng)的這種內(nèi)在級別上進行更改可能會使維護或在必要時移植到不同的體系結(jié)構(gòu)變得更具挑戰(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接收中斷服務(wù)例程，以便在收到SYNC信號時直接調(diào)用負(fù)責(zé)SYNC處理的CANopen堆棧函數(shù)。當(dāng)從中斷服務(wù)程序中執(zhí)行此操作時，請記?。?/p>

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

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

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

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

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

全文總結(jié)

通過戰(zhàn)略選擇來應(yīng)對復(fù)雜性

硬件選擇

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

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

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

網(wǎng)絡(luò)技術(shù)

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

優(yōu)化選擇

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

戰(zhàn)略無知

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

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