CAN Bus 工作原理 - 資料連結層

前面提到 CAN bus物理層的工作原理
現在來聊聊Layer 2的工作

借用一下 Wiki圖片，看不到圖片的，請另開新頁，上 Wiki瀏覽：

* 參考 [訊框] 後 [基本訊框格式] 圖示

首先， 當 CAN bus上 無通訊時，CAN bus處於 1(隱性)狀態。
當 有人需要開始傳送資料時，會將 CAN bus電壓拉開，處於 0（顯性）狀態；
此時 同bus上的其他人，將會知道有人要傳送資料，而處於靜默狀態。
若不幸的，有兩個以上設備，在同一時間點，均想要傳送資料，同一時間將 SOF(Start Of Frame)提升至 0（顯性）狀態 ... 

* SOF
1 bit Start Of Frame


	a. 緊接於 SOF後面的，即是 Message ID ！ 
		 - 之前有提到 不能有人共用相同 Message ID，所以，此處 ID肯定會不相同，則...
	b. 於 Message ID 送出 1(隱性)狀態 bit 的設備，於送出 1(隱性)狀態 bit後，
		 - 必須監聽此時的 CAN bus是否真實處於 1(隱性)狀態:
		i. 若是，則 繼續發送
		ii. 若否，則 CAN bus上，肯定有其他設備也正在發送資料，且 Message ID較自己優先；則 自己閉嘴，不再繼續發送資料。

當 設備發送完 Message ID後，此時 碰撞機制及仲裁機制，均已完成(除RTR外) !!

* RTR
1 bit Remote transmission request
當 有節點需要別人提供資料，則 送出 "別人的 Message ID" ！ 並加上 RTR！
此時 是 要求 "別人傳送資料" ！ 而不是自己要送出資料！
但是，當 相同 Message ID的擁有人，恰好也正在送資料？
此時 即借鑑上述仲裁機制：
	1. RTR = 0；資料訊框中為顯性
	2. RTR = 1；遠端訊框中位隱性
提出 RTR需求的人，自然會閉嘴!!


* IDE
1 bit 拓展訊框格式
IDE=0，表示此Frame為 Base frame format(基本訊框格式)， Message ID僅為前方 11 bits
IDE=1，表示此Frame為 Extended frame format(拓展訊框格式)， Message ID高達 29 bits
IDE=1具有兩段 Message ID，除了上述格式完全相同外，後面新增添了另一段 Message ID；
(應該是後來發現僅 11 bits的 Message ID不夠使用了 才如此修改添加的？)
IDE=1 的 拓展訊框格式 暫時不多解釋 


*R0
1 bit 預留位
實際被 CAN FD拿來表示為 CAN FD格式


* DLC(Data Length Code)
顧名思義，即為後方緊接著的 資料欄位 長度
占用 4 bits，可以表達數字 0~15；但 礙於規定，於 IDE=0(Base frame format)下，最大值僅能設定為 =8
於 Base Frame Format下，設定 值 8-15 均會被解釋為 =8


* Data 
可以是 0 bytes, 最多僅能使用 8 bytes (IDE=0, Base frame format)
(據說是怕占用到其他設備通訊太久時間，才定這麼短的?)


* CRC & CRC定界符
CRC 15 bits
CRC定界符 1 bit
該Bus上的所有設備，均須計算 CRC； 
由傳送此Frame的人傳送該CRC資料
其他設備做CRC檢驗！
Sender固定對CRC定界符送出 =1 訊號！
除了自己以外的其他設備 檢測到，Frame中CRC與自己計算出的CRC值：
	a. 相符，則 幫忙填寫 CRC定界符 為 =0
    b. 不相符，則 什麼都不用做!!
只要有一個其他設備將 CRC定界符 設定為 =0，則 CRC定界符即為 =0
此時表示 CRC正確！ 或者說 至少有一人收到正確的 CRC值
此時， Frame CRC check也完成 並被回報給Sender知曉
省去了 遭遇碰撞後重傳時間，也省去了詢問/等待CRC等錯誤回報時間 


* EOF
7 bits End of Frame
固定為 =1
表示 該Frame結束


* IF
3 Bits+ 訊框間內容(?)
至少 三個連續的1 組成(不確定是否包含 EOF的1，抑或EOF外再添加?)
其後的第一個 =0 bit 將會被視為 下一個 Frame的開始(SOF) 


此處還要另外說明一下 位填充 機制
如果 你是直接使用 示波器下去做檢視
偶爾會出現Frame中多1 bit的狀況
這不是雜訊!!!這不是雜訊!!!這不是雜訊!!!
而是位填充機制：
所以， sender在 相同極性的五個連續bit後 插入一個相反的極性的bit訊號 
CAN bus上 出現 連續6個相同bits，會被視為錯誤
此亦為錯誤檢測機制的一部分
若是自行撰寫 RAW Data轉換的人，解碼時 請記得優先將此bit拿掉 才是真正的Frame Data !!!


也由於這種仲裁機制，這就意味著 Message ID較小的frame有著較高的傳送優先權
所以，在設計/設定Message ID的時候，比較重要 攸關性命 需要及時反映的設備，務必使用較小ID
相反的，不重要的東西， 就給他丟到最後面幾個ID讓他慢慢被碰撞吧... 
不會有人希望見到自己的安全氣囊，比別人家的，慢個半秒鐘才做動吧!?