LIN总线协议
LIN，Interconnect Network，適用于速度和可靠性要求不高、低成本的場合，LIN的使用場景包括車窗、天窗、座椅、門鎖、空調、照明等舒適性相關的地方
LIN網絡
主機節點/從機節點
不同協議的網絡需要網關相連接，所以LIN網絡與CAN總線相連時，需要加入CAN-LIN網關，這個網關一般由LIN網絡的主機節點充當
LIN是單線總線，最大傳輸速率為20kbps，它采用的是一主多從的概念，就是一個LIN網絡只會有一個主機，多個從機
由于物理層限制，一個LIN網絡最多有16個節點，那么除去一個主機節點是有且唯一，從機節點的數量就是1到15個
主機任務/從機任務
主機節點（Master Node）包含主機任務（Master Task）和從機任務（Slave Task），從機節點（Slave Node）只有從機任務（Slave Task）
主機任務負責
-
調度總線上幀的傳輸次序
-
監測數據，處理錯誤
-
作為標準時鐘參考
-
接收從機節點發出的總線喚醒命令
從機任務不能夠主動發送數據，需要接收主機發送的幀頭，根據幀頭所包含的信息判斷：
-
發送應答
-
接收應答
-
既不接收也不發送應答
幀的結構
幀包括幀頭和應答兩個部分，主機節點里的主機任務負責發送幀頭，主機節點或從機節點里的從機任務接收幀頭，并對幀頭所包含的信息進行解析，然后決定是發送應答，還是接收應答，還是不作任何反應
幀的結構
幀頭
幀頭包括同步間隔段、同步段和PID段
同步間隔段
同步間隔段的作用：
這里就要講到LIN總線的顯性電平和隱性電平
上圖中，值0為顯性電平，值1為隱性電平，當總線上有大于等于一個節點發送顯性電平時，總線呈顯性電平；當所有的節點都發送隱性電平或不發送信息時，總線呈隱性電平，所以能看出顯性電平起主導作用
同步間隔段由同步間隔和同步間隔段間隔符組成，同步間隔是至少13位的顯性電平，除了同步間隔段，沒有任何其他情況會發出大于9個的顯性電平，那么13個顯性電平的同步間隔段，就可以作為一個幀的開始的標志
同步間隔段間隔符是一個隱性電平
同步段
在講同步段之前，先了解一個概念，字節域
字節域以顯性電平開始，以隱性電平結束，是一種標準的UART數據傳輸格式
在LIN的幀中，除了同步間隔段以外，其他各段都是以字節域的格式傳輸的
這里也可以看到數據段里的各byte字節，也是按照字節域的格式傳輸的
LIN總線為了節約成本，沒有采用高精度時鐘，采用了精度和成本相對較低的時鐘，這樣就會導致從機節點與主機節點的時鐘誤差，而同步段就是為了調整從機節點數據的位速率與主機節點一致
PID
“PID，Protected Identifier Field，受保護的ID
”為什么叫受保護的ID？
PID有8個bit，其中只有前6個bit是實際位，叫幀ID，后面兩個bit是前6個bit奇偶校驗后得到的值，叫奇偶校驗位
從機任務是根據收到的幀ID作出反應的，所以需要驗證幀ID是否正確，就是根據奇偶校驗位，這也就是為什么叫作PID的原因
校驗位P0 = ID0 @ ID1 @ ID2 @ ID3 @ ID4
校驗位P1 = ~(ID1 @ ID2 @ ID3 @ ID4 @ ID5)
@表示異或運算，~表示取反
“由此可以看出，PID不可能出現全0或全1的情況，如果從機任務收到了0xFF或0x00，可以判斷為傳輸錯誤
”根據幀ID的不同，將LIN幀分為
應答
應答包括數據段和校驗和段
數據段
數據段是節點發送的數據，1到8個字節不等，它承載著信號或診斷消息兩種數據類型
信號由信號攜帶幀傳遞，一個幀ID對應的數據段可能包含一個或多個信號，發送信號的節點稱為發布節點，接收信號的節點稱為收聽節點
一般情況下，對于一個幀中的應答，總線上只存在一個發布節點，否則就會出現錯誤
但是對于事件觸發幀，可能存在0個、1個或多個發布節點
診斷消息由診斷幀傳遞
校驗和段
校驗和段是對數據段內容進行校驗，它只有1個字節
校驗和根據不同的場景分為：標準型校驗和、增強型校驗和
采用哪種校驗和是由主機節點管理的，發布節點和收聽節點根據幀ID判斷采用哪種校驗和
計算方法很簡單：數據段內的各字節依次相加，如果有進位，則加到低位，最終得出的值取反
收聽節點如何校驗呢？同樣地，把數據段內的各字節依次相加，如果有進位，則加到低位，得到的值不取反，與接收到的校驗和相加，最終得到0xFF，校驗無誤
幀傳輸時間的計算
這里有幾個需要注意的時間，由于幀里面的各段間有間隔，這也是要花掉時間的
所以
幀頭的余量T_Header_Rest包含字節間間隔，規定為T_Header_Nominal的百分之40
應答的余量T_Response_Rest包含應答間隔以及字節間間隔，規定為T_Response_Nominal的百分之40。
N_data為數據段內的字節數
幀的類型
無條件幀
無條件幀的幀頭從主機任務發出后，必定有從機任務應答，也就是說必定有從機任務發出無條件幀中的信號，無論信號是否發生變化
有且只有一個從機任務對無條件幀的幀頭作出應答，發出信號
從這里是否可以明白一些東西
“主機節點里的主機任務負責發送幀頭，主機節點和從機節點里從機任務根據事先設計好的規則，負責對接收到的幀頭信息進行分析，以確定自己是否要把這個幀的數據發出去，或是否要接收這個幀的數據（來自其他從機任務的）
”這和CAN總線通信還是很不一樣的，后面我會進行分析和總結
無條件幀的典型應用場景如下
這里其實有很多的細節沒畫出來
第一個場景
“-
主機節點的主機任務發送了一條LIN幀的幀頭給所有的從機任務(包括主機節點里的從機任務)，所有的從機任務收到幀頭后分析幀ID=0x30，判斷是要發這個幀的數據，還是收這個幀的數據，或者是不作處理
-
從機節點1的從機任務收到幀ID 0x30，發現自己需要把某些信號值發出去，這些信號值就是屬于幀ID 0x30的
-
主機節點的從機任務收到幀ID 0x30，發現自己需要接收別人發來的信號值并作處理
-
從機節點2的從機任務收到幀ID 0x30，發現自己既不需要發送信號，也不需要接收信號
-
這個場景的典型應用就是從機節點1向主機節點報告自身某信號的狀態
從上面的分析中我們能總結出LIN總線通信方式
“一條幀的幀頭和數據段不是一起發出的，也不一定是同一個節點發出的
幀頭必定是由主機節點的主機任務發給從機任務，從機任務根據幀ID判斷是要發出信號值，還是接收信號值，或是不作反應
由此看出從機任務負責發送數據、接收數據或不作反應，一切都是根據收到的幀ID做判斷
雖然幀ID和數據是分開發送的，但是它們在LIN數據庫內也是一條完整的幀，只是幀ID由主機任務發送，數據放在某個節點里由從機任務發送
主機節點除了主機任務以外，還有從機任務，因為主機節點也是節點，它也是需要發送信號和接收信號的
不管是幀頭還是數據，除了發送節點以外的其他節點都會收到，只是是否要做處理，需要根據幀ID按照自己的內部規則作出判斷
第二個場景
“-
主機節點的主機任務把幀頭(幀ID 0x31)發給主機節點、從機節點1和從機節點2的從機任務，它們收到幀頭后分析幀ID 0x31發現
-
主機節點的從機任務需要發出幀ID 0x31的數據
-
從機節點1的從機任務需要接收發來的數據
-
從機節點2的從機任務需要接收發來的數據
-
這個場景的典型應用就是主機節點向從機節點發布信息
第三個場景
“-
主機節點的主機任務把幀頭(幀ID 0x32)發給主機節點、從機節點1和從機節點2的從機任務，它們收到幀頭后分析幀ID 0x32發現
-
主機節點的從機任務不作反應
-
從機節點1的從機任務需要接收發來的數據
-
從機節點2的從機任務需要發出幀ID 0x32的數據
-
這個場景的典型應用就是從機節點間的通信
事件觸發幀
當節點里的信號發生變化的頻率較低時，再用無條件幀一遍又一遍地讓它應答，這樣做很不合適，因為會占用LIN總線的帶寬
與無條件幀不論信號是否發生變化必定有從機任務應答不同，事件觸發幀只有信號發生變化才需要應答，所以事件觸發幀允許無節點應答(只有幀頭無應答)，也允許兩個以上的節點對幀頭作應答
當兩個以上的節點同時應答時，不會被視為錯誤，但是主機節點需要解決這個沖突，怎么辦呢？
主機節點的主機任務需要立刻中斷當前的進度表，然后啟動沖突解決進度表，調用這些沖突信號關聯的無條件幀，發送幀頭，獲得應答
由上圖可以看出
“-
主機節點的主機任務發送事件觸發幀的幀頭0x10，請求從機任務的應答，但是由于信號沒有變化，從機任務不應答
-
下一個循環，主機節點的主機任務又發送幀頭0x10，只有從機節點1的信號發生變化，從機節點1的從機任務作應答
-
下一個循環，主機節點的主機任務又發送幀頭0x10，從機節點1和2的信號同時變化，同時應答，造成沖突
-
中斷當前進度表，啟動沖突解決進度表
-
主機任務發送從機節點1的事件觸發幀的信號相關聯的無條件幀的幀頭0x11，從機節點1的從機任務就會把信號發給主機節點的從機任務
-
主機任務發送從機節點2的事件觸發幀的信號相關聯的無條件幀的幀頭0x12，從機節點2的從機任務就會把信號發給主機節點的從機任務
可以總結出
“事件觸發幀的信號必須有變化，信號所屬的從機任務才會發送
事件觸發幀的信號，也和無條件幀相關聯，換句話說，也是無條件幀里的信號，這樣做的目的是當事件觸發幀的應答沖突時，還可以用無條件幀去請求信號值
事件觸發幀的每一個應答節點對應一個不同的無條件幀
事件觸發幀的信號發生變化才應答的特點，很適合應用在對車門的開關狀態進行檢測的場景
對于事件觸發幀來說，由于有可能有多個節點應答，如何知道是哪個節點發來的應答呢？
這個其實也簡單
“既然應答沖突時會輪詢調用事件觸發幀的所有對應的無條件幀，說明一個無條件幀代表一個節點，那么只需要把事件觸發幀的應答中第一個字節設置為無條件幀的PID即可
”由于事件觸發幀的長度固定，所以各節點的應答固定，那么對應的無條件幀的應答長度也就固定了
所以
與事件觸發幀對應的所有無條件幀需要滿足
-
數據段長度相同
-
數據段的校驗和類型相同
-
數據段的第一個字節為該無條件幀的PID
-
由不同的從機節點發布
-
不能與事件觸發幀處于同一個進度表
偶發幀
事件觸發幀是主機節點為了獲取從機節點的信號狀態而發送的幀
那么主機節點里的信號狀態又要如何讓從機節點知道呢
這里就引入了偶發幀，偶發幀可以當作是主機節點的事件觸發幀
當主機節點的信號發生變化時，主機節點的主機任務就會發送偶發幀的幀頭，主機節點的從機任務收到幀頭后，發送信號，其他從機節點根據自身需要選擇是否接收(其實也是分析幀ID后判斷的)
上面說的是一個應答，一個偶發幀可能對應多個應答信號，如果同時有多個應答時，怎么辦？
和解決事件觸發幀的應答沖突一樣，一個偶發幀也關聯多個無條件幀，每個無條件幀對應一個應答，當同時有多個應答時，主機節點會根據LDF(LIN的數據庫文件)中定義好的優先級順序，依次在同一時隙時發送
偶發幀的無條件幀的發送方式，和事件觸發幀的還有所不同
事件觸發幀的無條件幀是啟用的沖突解決進度表來發送，會一個挨著一個發送，沖突解決進度表中的所有無條件幀發送完畢后，才會重新回到主進度表中繼續調度
而偶發幀的應答沖突時，并不會啟動沖突解決進度表，還是在主表內，在這個偶發幀的時隙時，調用優先級最高的無條件幀，然后等下一個輪詢，又輪到了偶發幀的機會時，再調用優先級次高的無條件幀
由于是主機節點的信號，如果它的信號沒有變化，偶發幀都沒必要發出去，因為信號沒變化，從機節點也沒必要判斷是否要接收，那主機節點也沒必要發偶發幀的幀頭，那么這個時隙就會保持沉默
診斷幀
診斷幀分為：主機請求幀、從機應答幀
主機請求幀
幀ID = 0x3C
應答由主機節點的從機任務發布
從機應答幀
幀ID = 0x3D
應答由從機節點的從機任務發布
保留幀
保留幀的幀ID為0x3E和0x3F，為將來擴展用
總結
- 上一篇： 全景视频资源网（VR），可下载全景视频
- 下一篇： 芯片制造流程