CANopen主要基於CAN套用協定，它是屬於OSI七層模型中的套用層以上的協定。相當於它對物理層CAN再進行了一次協定封裝，作為一個標準並開放出來，這樣每個廠家可以用這個協定彼此通訊，提高互操作性和兼容性。
CANopen原始碼是指可以用來下載到帶CAN控制器的MCU上的應用程式，用來完成CANopen的通訊協定解析、產品的套用/功能邏輯。CANopen原始碼編寫之前要先了解它的結構和重要概念。
可以考慮基於開原始碼或者商業版代碼來開發，幾個簡單的區別：
1、費用：開原始碼免費；商業版代碼收費，但節省了很多研發人員和測試人員的時間，節省了很多人力成本。
2、技術支持和文檔：商業版有人負責解答也有培訓，有完整的操作文檔和手冊，開源無人解答--問題解決的幾率小。
3、代碼質量和穩定性：商業代碼的質量、最佳化和效率有保證；使用開原始碼存在很大風險；
4、開發難度和時間：商業版有完整的多款不同硬體平台的樣例程式，大大降低開發移植難度和時間。開原始碼的研發工作量增加、後期測試難度和時間也增加。
5、研發/測試工具：商業版有完整的工具鏈和測試方法提供。完整的測試工具包括：網路組網和管理以及測試（導入EDS檔案組網並修改對應的數據，PDO mapping）、報文分析、快速創建對象字典 生成EDS檔案、USB-CAN卡採集數據等等。
7、支持的MCU平台demo豐富：SO-877-VP或者SO-1063-VP提供30多種不同MCU平台的demo，並且每年不斷更新和增加。
如果要做serious的產品，一般用商業版的代碼更有保障。
1、介紹
從OSI網路模型的角度來看同，現場匯流排網路一般只實現了第1層（物理層）、第2層（數據鏈路層）、第7層（套用層）。因為現場匯流排通常只包括一個網段，因此不需要第3層（傳輸層）和第4層（網路層），也不需要第5層（會話層）第6層（描述層）的作用。
CAN（Controller Area Network）現場匯流排僅僅定義了第1層、第2層（見ISO11898標準）；實際設計中，這兩層完全由硬體實現，設計人員無需再為此開發相關軟體（Software）或固件（Firmware）。
同時，CAN只定義物理層和數據鏈路層，沒有規定套用層，本身並不完整，需要一個高層協定來定義CAN報文中的11/29位標識符、8位元組數據的使用。而且，基於CAN匯流排的工業自動化套用中，越來越需要一個開放的、標準化的高層協定：這個協定支持各種CAN廠商設備的互用性、互換性，能夠實現在CAN網路中提供標準的、統一的系統通訊模式，提供設備功能描述方式，執行網路管理功能。
套用層（Application layer）：為網路中每一個有效設備都能夠提供一組有用的服務與協定。
通訊描述（Communication profile）：提供配置設備、通訊數據的含義，定義數據通訊方式。
設備描述（Device proflile）：為設備（類）增加符合規範的行為。
下面的章節將介紹基於CAN的高層協定：CAL協定和基於CAL協定擴展的CANopen協定。CANopen協定是CAN-in-Automation(CiA)定義的標準之一，並且在發布後不久就獲得了廣泛的承認。尤其是在歐洲，CANopen協定被認為是在基於CAN的工業系統中占領導地位的標準。大多數重要的設備類型，例如數字和模擬的輸入輸出模組、驅動設備、操作設備、控制器、可程式控制器或編碼器，都在稱為“設備描述”的協定中進行描述；“設備描述”定義了不同類型的標準設備及其相應的功能。依靠CANopen協定的支持，可以對不同廠商的設備通過匯流排進行配置。
在OSI模型中，CAN標準、CANopen協定之間的關係如下圖所示：
2、CAL 協定
CAL（CAN Application Layer）協定是目前基於CAN的高層通訊協定中的一種，最早由Philips醫療設備部門制定。現在CAL由獨立的CAN用戶和製造商集團CiA（CAN in Automation）協會負責管理、發展和推廣。
CAL提供了4種套用層服務功能：
CMS (CAN-based Message Specification)
CMS提供了一個開放的、面向對象的環境，用於實現用戶的套用。CMS提供基於變數、事件、域類型的對象，以設計和規定一個設備（節點）的功能如何被訪問（例如，如何上載下載超過8位元組的一組數據（域），並且有終止傳輸的功能）。
CMS從MMS (Manufacturing Message Specification)繼承而來。MMS是OSI為工業設備的遠程控制和監控而制定的套用層規範。
NMT (Network ManagemenT)
提供網路管理（如初始化、啟動和停止節點，偵測失效節點）服務。這種服務是採用主從通訊模式（所以只有一個NMT主節點）來實現的。
DBT (DistriBuTor)
提供動態分配CAN ID（正式名稱為COB-ID，Communication Object Identifier）服務。這種服務是採用主從通訊模式（所以只有一個DBT主節點）來實現的。
LMT (Layer ManagemenT)
LMT提供修改層參數的服務：一個節點（LMT Master）可以設定另外一個節點（LMT Slave）的某層參數（如改變一個節點的NMT地址，或改變CAN接口的位定時和波特率）。
CMS為它的訊息定義了8個優先權，每個優先權擁有220個COB-ID，範圍從1到1760。剩餘的標誌（0，1761-2031）保留給NMT，DBT和LMT，見表2-1。
注意這是CAN2.0A標準，11位ID範圍[0，2047]，由於歷史原因限制在[0，2031]。如果使用CAN2.0B標準，29位ID並不改變這個描述；表中的11位映射到29位COB-ID中的最高11位，以至於表中的COB-ID範圍變得增大許多。
3、CANopen
CAL提供了所有的網路管理服務和報文傳送協定，但並沒有定義CMS對象的內容或者正在通訊的對象的類型（它只定義了how，沒有定義what）。而這正是CANopen切入點。
CANopen的核心概念是設備對象字典（OD：Object Dictionary），在其它現場匯流排（Profibus，Interbus-S）系統中也使用這種設備描述形式。注意：對象字典不是CAL的一部分，而是在CANopen中實現的。
下面先介紹對象字典（OD：Object Dictionary），然後再介紹CANopen通訊機制。
3.1 對象字典OD
對象字典（OD：Object Dictionary）是一個有序的對象組；……
由於篇幅關係，更多詳細內容在這裡無法展示，不過有興趣的技術人員可以在我的文庫裡面下載，文檔名稱是：“CANopen原始碼協定介紹”或者其他與CANopen有關的資料一共有三四篇文章。下載地址和參考資料地址在以下地址欄中有提供。
註：什麼是PDO，什麼是SDO？
PDO是過程數據的傳送，實時，速度快。
SDO則是服務數據的傳送接收，實時性要求不高，主要用於從站的配置。
比如報警信息一般是PDO。如果要對一組對象字典賦值或讀取，一般是SDO。
SO-877-VP
可以實現簡單的主站功能，但是要求先將SDO服務設定好，而不能動態創建。比如SDO在接收到某個ID-A之後，傳送到另外一個ID-B中去，這個ID A和B的地址都需要預先設定和固定，而不能動態分配和創建連線。
如果需要通過撥碼開關給用戶修改CANopen主站或者從站的節點地址，用SO-877-VP是沒有問題的。只是SDO不能動態創建和對應連線的問題。
SO-1063的特性描述：
1、含有NMT Master功能
NMT提供了控制節點網路行為的服務，定義請參考/1/ DS-301。一個網路中的所有節點適用於以下情況：NMT主站提供的服務可以控制NMT從站，並且NMT主站的應用程式可以執行NMT從站。通常NMT主站套用也是套用主站的一部分。
簡潔說來，就是：控制NMT從站包括從站的操作。
2、SDO Manager
SDO Manager是一個可選擇的功能，它負責處理動態建立SDO連線。如果一個SDO Manager在系統中是存在的，它必須在同一個節點中同時與NMT主站功能一起存在。
簡潔說來，就是：動態建立SDO連線。
3、Configuration Manager
Configuration Manager是可選擇的功能，它提供了boot-up時在系統中配置節點的機制。這個機制叫做Configuration Management CMT配置管理。這個Configuration Management必須在同一個節點中與NMT主站和SDO Manager的功能同時存在。
簡潔說來，就是：在boot-up時配置節點。包括節點ID/波特率等。
4、Boot-Up Procedure
當CANopen Manager在Power-On後啟動，它會根據DS-301來執行狀態機。在將狀態從Pre-Operational（預操作）切換到 Operational（操作）狀態前，它需要啟動所有已分配從站。
CANopen程式設計流程圖如右圖1和圖2。
CANopen代碼程式流程圖-2