正如前文所述,CANopen的適應性在滿足實時應用需求方面發揮著至關重要的作用。本系列文章的最后一部分將向您展示 CANopen 源代碼配置的技術細節,以及實現高效實時性能的優化方法。
本文將基于虹科CANopen源碼來研究具體示例,從而闡明配置、優化和微調CANopen協議棧的過程,以滿足高級時間要求和可能的系統約束。
無論您是經驗豐富希望提高優化技能的CAN系統設計人員,還是希望了解實時CANopen 配置的細微差別的新手,本部分都旨在提供全面的見解和指導,將我們獲得的理論知識轉化為實際實施。
01/
不同的CANopen PDO配置及其對響應時間的影響
CANopen PDO(過程數據對象)的配置在確定各種應用中的響應時間方面起著至關重要的作用。根據所需的響應時間和跨多個節點同步信號的必要性,可以應用不同的PDO觸發機制。
100ms響應時間
對于所需響應時間為100毫秒或更長的應用,通常有兩種運行良好的配置方法(也可以組合使用):
PDO按事件時間觸發(循環傳輸):這里,PDO以指定的時間間隔循環傳輸,例如每50ms。這種周期性傳輸確保了一致的響應時間。
帶禁止時間的狀態變化(COS)檢測:此配置根據狀態變化傳輸PDO,傳輸之間具有最短時間(禁止時間)。該禁止時間確保切換輸入不會產生back-to-back消息。
使用 CANopen Architect 進行 PDO 配置
上面的屏幕截圖顯示了使用100ms事件觸發和25ms禁止時間相結合的TPDO1設置。如果TPDO中的數據沒有變化,則每100ms傳輸一次。如果確實發生變化,傳輸速度會更快,但永遠不會快于25毫秒。類似地,TPDO2和TPDO3每200ms傳輸一次。狀態改變(COS)時,它們的傳輸頻率更高,但速度不超過50毫秒。
更短的響應時間或跨多個節點的同步信號
對于需要較小響應時間或需要跨多個節點同步信號的應用,SYNC 模式成為首選方法。
SYNC模式:在此配置中,一個SYNC生成器以穩定的重復間隔(例如每10毫秒)生成SYNC CANopen消息。此SYNC消息用作觸發機制,網絡中的所有設備使用它來同時同步應用數據。
高級SYNC:使用CANopenSYNC模式時,您可以利用兩個高級功能。首先,大多數SYNC消費者允許使用SYNC CAN消息標識符的配置。因此,您可以將系統配置為使用多個SYNC觸發消息,并選擇哪些設備對哪個觸發做出反應。其次,最新版本的CANopen支持使用帶有集成可配置計數器的SYNC。例如,可以將其配置為計數到4。在SYNC使用者端,您可以配置每個使用者偵聽的計數值,再次提供對設備進行分組以對系統上的特定SYNC做出反應的選項。
選擇正確的PDO配置對于實現最短的響應時間至關重要。雖然循環傳輸和具有禁止時間的COS檢測適用于更寬松的響應時間要求,但在處理更嚴格的時間限制或需要同步多個設備時,SYNC模式變得至關重要。
02/
CANopen協議棧中的數據流
下圖說明了CANopen系統中的數據流。在最低硬件級別,CAN控制器將接收CAN幀(此處通過連接的收發器從左開始)。根據過濾器的不同,它們可能會被放入預先選擇的緩沖區或隊列中,并且將生成中斷信號。實現處理CAN控制器代碼的處理器(通常是“驅動程序”)開始處理“CAN接收中斷服務”。更通用的驅動程序可以實現另一個軟件隊列以供以后處理。每當CANopen協議處理代碼被觸發處理接收到的消息時,它就會從驅動程序獲取消息并更新對象字典。
反之亦然,應用程序可能隨時更新對象字典中的一些過程數據以通過CANopen傳輸。這是由CANopen協議處理程序檢測到的,如果觸發條件正確,將觸發傳輸PDO并傳遞給驅動程序,驅動程序會將其放置在適當的傳輸緩沖區或隊列中。
CAN設備中的數據流
請注意,通常這不是單個連續的代碼流。CAN接收通常在中斷級別進行處理,而CANopen協議棧處理則不然。
為了保持CANopen協議棧處于活動狀態,通常需要頻繁調用協議棧函數,(例如在“main while(1)”后臺循環中)。該類函數通常會首先檢查是否接收到 CANopen消息;如果是,則對其進行處理。如果數據涉及更新過程數據,則通常有一個回調函數來通知應用程序新的過程數據已到達。
當處理完所有接收到的CANopen消息后,該函數會檢查是否有任何內容需要傳輸。它可以檢測到傳出的過程數據被應用程序修改,并根據定時器的配置和傳輸模式,啟動相應的CANopen消息的傳輸。
此類傳輸通常會傳遞到驅動程序級別,可能會傳遞到傳輸隊列中,并且具體何時將此CANopen消息傳遞到CAN控制器進行傳輸取決于驅動程序配置。
基本配置和控制選項
除非所需的處理和響應時間小于100毫秒,否則這樣的數據流對于大多數應用程序來說已經足夠好了。如果所需的響應時間變短,您應該開始考慮可能的優化。在查看上面的通用數據流時,可能的優化包括:
針對接收的CAN驅動程序優化:芯片制造商(甚至CANopen協議棧提供商)提供的許多默認驅動程序可能無法充分利用CAN控制器的特定功能。第一個可能的優化檢查之一是確保在可能的情況下利用硬件接收過濾和硬件接收緩沖區或隊列,從而消除對長延遲軟件接收隊列的需要。
針對傳輸的CAN驅動程序優化:在優化之前,請考慮該設備是否可以連續傳輸盡可能多的CAN幀,或者是否應該對傳輸進行某種程度的節流以確保沒有任何單個設備可能會產生太長時間的高優先級back-to-back流量。如果應該對其進行限制,請考慮實施基于計時器的傳輸觸發,例如需要每毫秒傳輸一個CAN幀,則我們可以使用1ms定時器中斷來執行此操作,通過相應Check函數檢查傳輸隊列中是否有內容。如果是,則在此調用周期中僅將一個報文幀傳遞到傳輸緩沖區,從而將傳輸頻率限制為每毫秒最多一次。如果需要更快的吞吐量,則可以使用更快的中斷,或可以考慮使用前文提到的協議棧處理函數"Process()"的方法。
協議棧處理函數
有關協議棧處理的一個典型問題是,應該多長時間調用一次,最壞情況下的執行時間是多少。有些人喜歡從固定的定時器中斷而不是后臺循環中調用它。這些問題沒有通用的答案。常見做法是:
while (Process());
這將不斷重新調用該函數,直到所有待處理的CANopen任務都已執行完畢。
直接任務觸發
協議棧處理函數主要是為那些不想深入了解從內部執行的所有CANopen任務的詳細信息的人提供服務。當然為了進一步優化,我們也可以直接實現更具體的協議棧功能函數,比如RxPDO和TxPDO,或者是基于毫秒計時器實現的計時觸發函數等,從而可以更精確地調整性能和響應能力。
03/
CAN驅動程序、CANopen協議棧和應用
在大多數基于32位的微控制器上,到目前為止討論的增強功能適合將總響應時間降低到10毫秒到“幾毫秒”的范圍。這可以在不需要優化的情況下實現,而優化可能會導致完全自定義的實現,而這種實現可能難以維護。這些優化僅限于在需要時利用單獨觸發的CANopen堆棧進程。
一般來說,這可以進一步進行。然而,在系統的這種內在級別上進行更改可能會使維護或在必要時移植到不同的體系結構變得更具挑戰性。因此,以下內容更多的是說明“理論上可能的情況”,將優化推向超出系統易于測試、維護和移植的范圍。
在最低硬件級別,檢查您的CAN控制器是否配置為通過接收SYNC消息直接創建CAN接收中斷,以及您是否可以輕松檢測到與任何其他CANopen消息(例如自己的過濾器/接收緩沖區)的差異。
為了進一步提高實時性,唯一合理的CANopen PDO通信模式是CANopen SYNC模式。如果使用它并且我們集中精力優化它,那么之前的其他優化可能會變得多余。
專注于SYNC優化需要我們修改CAN接收中斷服務例程,以便在收到SYNC信號時直接調用負責SYNC處理的CANopen堆棧函數。當從中斷服務程序中執行此操作時,請記?。?/p>
不要將此SYNC存儲在常規接收隊列中(我們已經處理過它)。
對于SYNC相關的發送和接收數據,將調用應用程序的回調函數——仍然在中斷服務級別執行。
- 當使用RTOS時,更好的解決方案是在收到SYNC的中斷中設置觸發信號,隨后在中斷完成后立即觸發執行任務。
通過這樣的修改,可以實現毫秒內的響應時間。如果參與SYNC通信的所有設備都以相同的優化來實現SYNC處理,則設備之間的變化(例如,當它們各自同步應用其輸出時)可以低至幾微秒。
然而,這些都是在測試和實驗室環境中觀察到的極端值。對于要求如此短響應或同步時間的實際應用程序,需要仔細測試以確保在所有實際情況下都能達到這些目標。
全文總結
通過戰略選擇來應對復雜性
硬件選擇
所需的響應時間決定了所需的硬件功能,影響對模塊、可能是微控制器和其他重要組件的決策。
操作系統注意事項
無論是使用 RTOS 還是實現更具體的定制系統,響應時間都會嚴重影響操作系統的配置方式。
網絡技術
根據所需的吞吐量和速度,必須考慮不同的網絡協議和技術。作為一個例子,本系列研究了CANopen及其配置的細節,說明了滿足不同應用需求所需的細微選擇。
優化選擇
也許最深刻的見解之一是認識到優化并不是一種萬能的方法。根據所需的響應時間,某些優化變得至關重要,而其他優化則可以繞過。這是一個微調的問題,了解哪些內容需要利用,哪些內容可以在不影響性能的情況下保持不變。
戰略無知
與利用一切可能的優勢的本能相反,在某些情況下,時間框架允許故意忽略某些優化。并非網絡控制器提供的每個寄存器都需要被利用;這是性能和特定應用程序的需求之間的平衡。
虹科是一家在工業自動化領域,特別是工業總線通訊行業經驗超過15年的高科技公司,在CAN、CAN FD、CANopen通訊領域,虹科可提供CAN卡、中繼器、路由器、總線記錄儀、網關、IO模塊、熱電偶模塊、芯片及軟件等一站式解決方案,歡迎聯系虹科了解更多信息!
-
CANopen
+關注
關注
8文章
253瀏覽量
43583 -
源代碼
+關注
關注
96文章
2945瀏覽量
66733 -
數據流
+關注
關注
0文章
119瀏覽量
14349
發布評論請先 登錄
相關推薦
評論