以下內容來源于《汽車電子與軟件》
一、引 言
J1939Tp是我學習AUTOSAR CP諸多BSW模塊的起點,其分層架構完美體現了AUTOSAR規范的精髓,掌握J1939Tp有助于深入理解通信(COM)相關模塊的程序執行過程。
本文依舊從傳統的手工編程入手,講述J1939Tp工具鏈編程的操作步驟,對模塊的內部機理僅做簡單介紹,感興趣的讀者可參考相應AUTOSAR規范。
二、J1939Tp模塊介紹
美國汽車工程師協會(SAE)制定的主要針對商用車的CAN總線通訊協議,其基于CAN 2.0B協議。
表2-1列出了J1939協議的主要內容和對應文檔。
表2-1: J1939內容和參考資料匯總
表中的“SAE J1939-21”描述了數據鏈路和傳輸層,包括2種傳輸協議類型:BAM用于廣播消息,CMDT用于點對點連接。
J1939Tp為“SAE J1939-21”在AUTOSAR架構中的實現,主要完成下列功能。
(1)直接或分段發送數據
(2)直接或重組接收數據
(3)數據流控制
(4)超時管理
(5)分段和組包過程中的錯誤檢測
2.1 數據鏈路層
數據鏈路層為物理連接之間提供可靠的數據傳輸,包括發送CAN數據幀所必須的同步、順序控制、出錯控制和流控制。本節主要介紹數據分段收發過程。
傳輸多于8字節的數據須采用多幀傳輸機制,即采用多包報文,在連接管理報文的協調下進行多幀傳輸。
長度大于8字節的報文無法用單個CAN數據幀來裝載。因此,它們必須被拆分為若干個小的數據包,然后使用單個的數據幀對其逐一傳送。而接收方必須能夠接收這些單個的數據幀,然后解析各個數據包并重組成原始的信息。
CAN數據幀包含一個8字節的數據域。由于組成長信息的單個數據包必須能被識別出來以便正確重組,因此把數據域的首字節定義為數據包的序列編號。每個數據包都會被分配到一個從1到255的序列編號。由此可知,多幀傳輸最大的數據長度是(255包×7字節/包=)1785字節(雖然協議理論上支持1785 字節,但大多數 ECU 實際不會發送如此大長度,可能因內存或總線負載需限制更小最大長度)。
序列編號是在數據拆裝時分配給每個數據包,然后通過網絡傳送給接收方。接收方接收后,利用這些編號把數據包重組成原始信息。
序列編號從1開始,依次分配給每個數據包,直到整個數據都被拆裝和傳送完畢。這些數據包從編號為1的數據包開始按編號的遞增順序發送。
第一個數據傳送包包含序列編號1 和字符串的頭7個字節,其后的7個字節跟隨序列編號2存放在另一個CAN數據幀中,再隨后的7個字節與編號3一起,直到原始信息中所有的字節都被存放到CAN數據幀中并被傳送。
傳送的每個數據包(除了傳送隊列中的最后一個數據包)都裝載著原始數據中的7個字節。而最后一個數據包的數據域的8個字節包含:數據包的序列編號和參數組至少一個字節的數據,余下未使用的字節全部設置為“0xFF”。
數據包被順序接收。按照序列編號的順序把多包消息的數據包重新組合成一多字節字符串。這個字符串被作為長信息的應答傳送給應用程序模塊。
2.2 協議數據單元
協議數據單元由七部分組成,分別是優先級、保留位、數據頁、PDU格式、PDU特定域(可作為目標地址、組擴展或專用)、源地址和數據域。PDU被封裝在一個或多個CAN數據幀中,通過物理介質傳送到其他網絡設備。每個CAN數據幀只能有一個PDU。
其中,優先權、擴展數據頁、數據頁、PDU格式、PDU特定域和源地址構成29位標志符;擴展數據頁、數據頁、PDU格式和PDU特定域構成參數組編號PGN;整體構成協議數據單元PDU。
2.2.1 請求PGN報文
定義:用于從一個或多個網絡設備請求參數組
傳輸速率:用戶子定義,推薦每秒請求不多于2或3次
數據長度:3字節
數據頁:0
PDU格式:0xEA
PDU特定域:目標地址(全局或特定)
缺省優先級:0x06
參數組編號:0xEA00
參數定義:
0-2字節:被請求的參數組編號
對于特定目標地址的請求,目標地址必須做出響應。如果目標地址不支持請求的PGN,也必須發出一個NACK的響應以表明它不支持該PGN。有些PGN是多包的,因此一個單幀請求的響應可能有多個CAN數據幀。如果是全局請求,當一個節點不支持某個PGN時,不能發出NACK響應。
2.2.2 確認報文
定義:用來提供發送方與接收方之間的握手機制
傳輸速率:收到需要此類型的確認的PGN時
數據長度:8字節
數據頁:0
PDU格式:0xE8
PDU特定域:目標地址 = 全局(0xFF)
缺省優先級:0x06
參數組編號:0xE800
參數定義:
0字節:控制字節。0表示肯定確認(ACK);1表示否定確認(NACK);2表示拒絕訪問;3表示無法響應
1字節:組功能值(若適用)
2-4字節:0xFF
5-7字節:被請求報文的參數組編號
2.2.3 連接管理報文(TP.CM)
定義:用于9字節及以上數據參數組的傳輸
傳輸速度:由傳送的參數組編號決定
數據長度:8字節
數據頁:0
PDU格式:0xEC
PDU特定域:目標地址
缺省優先級:0x07
參數組編號:0xEC00
參數定義:第0字節為控制字,其它字節的定義依賴于第0字節控制字的值
(1)連接模式下的請求發送(TP.CM_RTS):指定目標地址
0字節:0x10,指定目標地址的請求發送(RTS)
1-2字節:整個報文大小的字節數
3字節:全部數據包數
4字節:每次CTS 中允許發送的最大幀數(Packets per block)
5-7字節:PGN(Parameter Group Number)
打包報文的參數組編號
(2)連接模式下的準許發送(TP.CM_CTS):指定目標地址
0字節:0x11,指定目標地址的準許發送(CTS)
1字節:可發送的數據包數
2字節:下一個要發送的數據包編號
3-4字節:保留 (通常 0xFF)
5-7字節:PGN打包報文的參數組編號
(3)報文結束應答
(TP.CM_EndofMsgAck):指定目標地址
0字節:0x13,報文結束應答
1-2字節:整個報文的字節數
3字節:全部數據包個數
4字節:0xFF
5-7字節:打包報文的參數組編號
(4)放棄連接(TP.CM_Abort):指定目標地址
0字節:0xFF,放棄連接
1-4字節:0xFF
5-7字節:打包報文的參數組編號
(5)廣播公告報文(TP.CM_BAM):全局目標地址
0字節:0x20,廣播公告報文(BAM)
1-2字節:整個報文的字節數
3字節:全部數據包數
4字節:0xFF
5-7字節:打包報文的參數組編號
2.2.4 數據發送報文
定義:用于9字節及以上數據參數組的傳輸
傳輸速度:由傳送的參數組編號決定
數據長度:8字節
數據頁:0
PDU格式:0xEB
PDU特定域:目標地址
缺省優先級:0x07
參數組編號:0xEB00
參數定義:
0字節:數據包編號
1-7字節:報文數據
三、手寫代碼實現方法
下面簡要介紹J1939數據鏈路層手工編程的實現要點。
3.1 多幀傳輸機制—接收
接收多于8字節的數據流有單播(特定目標地址)和廣播(全局目標地址)兩種情況,下面分別進行說明。
3.1.1 單播方式
單播方式接收多于8字節的數據流按照下列步驟進行。
(1)接收發送方的“連接模式下的請求發送(TP.CM_RTS):指定目標地址”報文
收到這類報文后,首先檢查其是否同時滿足下面兩個條件,若滿足繼續下面的操作。
·參數組編號為0xD700或符合本地指定CA的要求(參數組編號、發送CA的地址或名字)
·接收到的“整個報文的字節數”和“全部數據包數”匹配
該檢查通過后,獲取CAN接收控制節點并對其初始化,再將該節點設置為“分段接收起始狀態”。
若在上述過程中出現了任何異常,發送“放棄連接(TP.CM_Abort):指定目標地址”報文。
(2)回發“連接模式下的準許發送(TP.CM_CTS):指定目標地址”報文
在接收并處理RTS報文之后進行,要求對方一次性將數據發完。報文發送成功后將對應CAN接收控制節點設置為“連續接收”狀態。
(3)接收并整合數據
連續接收PGN為0xEB00的包并將有效數據依次存放到相應CAN接收控制節點中,待報文中的所有數據接收完畢后,發送“報文結束應答(TP.CM_EndofMsgAck):指定目標地址”并將對應CAN接收控制節點設置為“接收終止”狀態。
數據接收過程中須滿足以下幾個要求,否則將發送“放棄連接(TP.CM_Abort):指定目標地址”報文并將對應CAN接收控制節點設置為“接收終止”狀態。
·數據包編號正確
·收到相鄰兩個數據包的時間間隔小于750ms
·發送CTS消息到收到第1個數據包的時間間隔小于1250ms
(4)處理接收到的報文
根據接收報文的參數組編號對其做出相應處理并將對應CAN接收控制節點還原。
3.1.2 廣播方式
廣播方式接收多于8字節的數據流按照下列步驟進行。
(1)接收發送方的“廣播公告報文(TP.CM_BAM):全局目標地址”
收到這類報文后,首先檢查其是否同時滿足下面三個條件,若滿足繼續下面的操作。
·參數組編號為0xFED8或符合本地任何一個CA的要求(參數組編號、發送CA的地址或名字)
·目標地址為0xFF且源地址與接收報文匹配的CAN接收控制節點不存在
·接收到的“整個報文的字節數”和“全部數據包數”匹配
該檢查通過后,獲取CAN接收控制節點并對其初始化,再將該節點設置為“連續接收”狀態。
(2)接收并整合數據
連續接收PGN為0xEB00的包并將有效數據依次存放到相應CAN接收控制節點中,待報文中的所有數據接收完畢后,將對應CAN接收控制節點設置為“接收終止”狀態。
數據接收過程中須滿足以下幾個要求,否則將對應CAN接收控制節點設置為“接收終止”狀態。
·數據包編號正確
·收到相鄰兩幀數據的時間間隔小于750ms
(3)處理接收到的報文
根據接收報文的參數組編號對其做出相應處理并將對應CAN接收控制節點還原。
3.2 多幀傳輸機制-發送
發送多于8字節的數據流有單播(特定目標地址)和廣播(全局目標地址)兩種情況,下面分別進行說明。
3.2.1 單播方式
單播方式發送多于8字節的數據流按照下列步驟進行。
(1)準備工作
獲取一個CAN發送控制節點,將其初始化并設置為“初始狀態”。
(2)發送“連接模式下的請求發送(TP.CM_RTS):指定目標地址”報文
該報文發送成功后將對應CAN發送控制節點設置為“準許發送等待狀態”。
(3)接收“連接模式下的準許發送(TP.CM_CTS):指定目標地址”報文
發送RTS后的1250ms內必須收到此報文,否則將發送“放棄連接(TP.CM_Abort):指定目標地址”報文并將對應CAN發送控制節點設置為“發送終止”狀態。
這里稱“可發送的數據包數”為0的CTS為“保持連接報文”,接收到此類報文后的1050ms內必須再次收到CTS,否則也將發送Abort報文并將對應CAN發送控制節點設置為“發送終止”狀態。
注意:如果Abort報文發送失敗,須將對應CAN發送控制節點設置為“放棄連接報文發送”狀態,這樣下一個周期將再次發送Abort報文。
如果在規定的時間內收到正確的CTS且其“可發送的數據包數”不為0,則發送第一個數據幀,同時將對應CAN發送控制節點設置為“連續發送”狀態。
(4)連續發送數據
程序將每個發出的數據幀添加至CAN接收處理緩沖區,該操作完成后才繼續發送下一個數據幀,直到本次CTS要求的數據包全部發完為止。在此過程中連續兩個數據幀的發送時間間隔不能超過750ms,否則將發送Abort報文并將對應CAN發送控制節點設置為“發送終止”狀態。
在連續發送數據的過程中不允許接收到除“保持連接報文”之外的CTS(收到此類報文后應停止數據幀的發送轉而等待下一個CTS),否則也將發送Abort報文并將對應CAN發送控制節點設置為“發送終止”狀態。
本次CTS要求的數據包發送完畢后,將對應CAN發送控制節點設置為“準許發送等待狀態”,然后重復(3)和(4)的步驟,直到所有數據發送完成。這時將對應CAN發送控制節點設置為“報文結束應答等待狀態”。
(5)接收“報文結束應答(TP.CM_EndofMsgAck):指定目標地址”
發送最后一個數據幀后的1250ms內必須收到此報文,否則將發送Abort報文并將對應CAN發送控制節點設置為“發送終止”狀態。如果EndofMsgAck的“整個報文大小的字節數”和“全部數據包數”匹配,說明發送圓滿完成,此時將對應CAN發送控制節點設置為“發送終止”狀態并還原該節點。
3.2.2 廣播方式
廣播方式發送多于8字節的數據流按照下列步驟進行。
(1)準備工作
獲取一個CAN發送控制節點,將其初始化并設置為“初始狀態”。
(2)自發自收“廣播公告報文(TP.CM_BAM):全局目標地址”
發送BAM并將對應CAN發送控制節點設置為“廣播公告報文等待狀態”。如果在之后的750ms內接收到自發的BAM,將節點設置為“連續發送”狀態,并在50ms后啟動數據幀發送;否則將節點設置為“發送終止”狀態。
(3)連續發送數據
每個發出的數據幀都將被接收并添加至CAN接收處理緩沖區,該操作完成后延時50ms才繼續發送下一個數據幀,直到全部數據包發完為止。每個數據幀發送和接收的時間間隔不能超過750ms,在此過程中對應CAN發送控制節點處于“數據報文等待狀態”。
當所有數據包發送完成或出現任何異常時,將對應CAN發送控制節點設置為“發送終止”狀態并還原該節點。
3.3 請求PGN報文
這里主要介紹接收到“請求PGN”報文時的處理方式,被請求的參數組編號分為“0xEE00”和“其它”兩類。
3.3.1 請求PGN為0xEE00的參數組
收到此種報文后將對本地所有CA的狀態進行判斷,對于已經成功聲明過地址的CA,立即發送“地址聲明報文”;對于狀態異常的CA,在0-153ms的隨機時間后發送“不能聲明地址報文”。
3.3.2 請求PGN為非0xEE00的參數組
如果請求參數組的PGN和SA滿足本地CA的要求,發送“肯定確認”報文;否則發送“拒絕訪問”報文(僅限于特定目標地址)。
四、AUTOSAR工具鏈實現方法
下面描述J1939數據鏈路層工具鏈實現的基本步驟,整個過程在ETAS的ISOLAR_AB 4.0和EB公司的EB Tresos工具下完成。
4.1 模塊介紹
下面介紹J1939Tp的設計步驟和目標。
4.1.1 設計步驟
J1939Tp設計主要在ISOLAR-AB環境下進行。
(1)ARXML創建
在ISOLAR-AB中創建J1939Tp_EcucValues.arxml文件,再在其中創建如表4-1所示的AR Package。
表4-1: ARXML文件內容
(2)模塊配置
依次配置Can、EcuC、J1939DcmCDD、PduR、CanIf、J1939Tp模塊(如表4-2所列),圖4-1為不同模塊間的層級關系。
表 4-2: ARXML文件內容
圖 4-1: J1939Tp相關模塊層級關系
4.1.2 設計目標
本文實現符合J1939協議的多字節發送和接收的協議棧。
(1)數據發送
發送一幀18字節的數據,如圖4-2所示。
圖 4-2: 多字節數據發送執行結果
(2)數據接收
實時接收一幀數據并將其存儲至緩沖區中,如圖4-3所示。
圖 4-3: 多字節數據接收執行結果
4.2 J1939Tp模塊創建和通用配置
首先需要在ISOLAR-B中創建J1939Tp模塊及其ARXML文件,再對其進行“通用配置”,這是后續一系列配置操作的基礎。
4.2.1 J1939Tp模塊創建
按照圖4-4和圖4-5所示的步驟創建J1939Tp模塊。
圖 4-4: J1939Tp模塊創建啟動
圖 4-5: J1939Tp模塊創建操作
下面對J1939Tp模塊創建過程做幾點說明。
(1)AR Package路徑現階段必須為“/ETAS_Project/...”,否則在生成“RTA-BSW”后程序工程的許多配置項需要手動修改;后續新建ISOLAR-AB項目可嘗試將該路徑改為“/Foton_Project/...”。
(2)新建的ARXML文件存儲至“StaticCfg”文件夾下,圖3-2中步驟④和⑤的次序不能改變。
4.2.2 J1939Tp通用配置
按照圖4-6所示進入J1939Tp通用配置界面,表4-3為其配置情況。
圖 4-6: J1939Tp通用配置界面進入
表 4-3: J1939Tp通用參數配置
4.3 Can配置
Can模塊執行硬件操作并為上層模塊提供與硬件無關的API接口。唯一一個能訪問Can模塊的上層模塊是CanIf模塊。
4.3.1 Can模塊創建
按照圖4-7和圖4-8所示創建Can模塊,用于J1939Tp模塊相關報文的配置。
圖 4-7: Can模塊創建啟動
圖 4-8: Can模塊創建配置
這樣在ISOLAR-B中出現了2個Can模塊(可能需要刷新操作),如圖4-9所示。
圖 4-9: Can模塊創建后的效果
(1)統一路徑操作
從圖4-9可以看出,CanEcucValues.arxml和J1939Tp_EcucValues.arxml中各有一個Can模塊,為統一配置,須將兩者的路徑設定為一致,這個操作在“AUTOSAR Explorer”中完成,具體參見圖4-10和圖4-11。
圖 4-10: 進入”AUTOSAR Explorer”的操作
圖 4-11: 在J1939Tp_EcucValues.arxml中創建Ar Package
將新建的“Ar Package”命名為“Can”,并將前面創建的Can模塊拖入其中,執行效果如圖4-12所示。
圖 4-12: Can模塊路徑更改執行效果
(2)多余配置項刪除
原有Can模塊的配置參數存放在CanEcucValues.arxml中,新創建Can模塊的配置參數存放在J1939Tp_EcucValues.arxml中,它們分別為Can模塊的一部分。為防止BSW代碼生成時產生重復性錯誤,需要把新創建Can模塊下的“CanConfigSet”和“CanGeneral”刪除,如圖4-13所示。
圖 4-13: Can模塊多余配置項刪除
(3)配置文件選擇
在配置Can模塊的參數時,雙擊“Can “Can” [CanEcucValues.arxml]”配置將改變CanEcucValues.arxml的內容,雙擊“Can “Can” [J1939Tp_EcucValues.arxml]”配置將改變J1939Tp_EcucValues.arxml的內容。由于本文希望將J1939Tp相關的配置存放在J1939Tp_EcucValues.arxml中,故需要雙擊“Can “Can” [J1939Tp_EcucValues.arxml]”來配置Can模塊。
4.3.2 添加和配置硬件對象
添加J1939通信所需的3個“CanHardwareObjects”,如表4-4所列。
表4-4: CAN硬件對象
圖4-14為添加Can硬件對象的方法,表4-5、表4-6和表4-7分別列出各硬件對象的配置參數。
圖4-14: Can硬件對象添加方法
表4-5:連接管理報文接收硬件對象配置
表 4-6: 數據傳輸報文接收硬件對象配置
? 4-7:?連接管理報文或數據傳輸報文發送硬件對象配置 ?
4.4 Ecuc配置
在ECU配置時有一些信息需要多個BSW模塊共享,在不好確定這些共享信息屬于哪個模塊的情況下,使用虛擬Ecuc模塊來進行ECU配置參數定義。
4.4.1 Ecuc模塊創建
按照圖4-15和圖4-16所示創建Ecuc模塊,用于添加和配置J1939通信所用到的協議數據單元。
圖 4-15: Ecuc模塊創建啟動
圖 4-16: Ecuc模塊創建配置
后續需要依次進行Ecuc模塊的多余配置項刪除和配置文件選擇(無需統一路徑操作),這些步驟與前文的Can模塊操作基本相同。
4.4.2 添加和配置協議數據單元
添加J1939通信所需的8個“Pdus”,如表4-8所列。圖4-17繪制出這些協議數據單元的功用。
表 4-8: Ecuc模塊須添加的協議數據單元
圖 4-17: Ecuc創建協議數據單元功用示意圖
圖4-18為添加Pdus的方法,表4-9、表4-10、表4-11、表4-12、表4-13、表4-14、表4-15和表4-16分別列出各協議數據單元的配置參數。
圖 4-18: Ecuc協議數據單元添加方法
表 4-9: 發送連接管理幀從J1939Tp到CanIf配置
表4-10: 發送數據傳輸幀從J1939Tp到CanIf配置
表4-11: 發送幀從PduR到J1939Tp配置
表4-12: 發送幀從J1939Dcm到PudR配置
表4-13: 接收連接管理幀從CanIf到J1939Tp配置
表4-14: 接收數據傳輸幀從CanIf到J1939Tp配置
表4-15: 接收幀從J1939Tp到PduR配置
表4-16: 接收幀從PduR到J1939Dcm配置
4.5 J1939DcmCDD配置
J1939DcmCDD模塊用于測試J1939協議棧,即多于8字節數據的收發。
4.5.1 Cdd模塊創建
按照圖4-19和圖4-20所示創建Cdd模塊,并將其更名為J1939DcmCDD。
圖 4-19: Cdd模塊創建啟動
圖 4-20: Cdd模塊創建配置
為剛剛創建的Cdd模塊添加“CddComStackContribution -> CddPduRUpperLayerContribution”,再配置RxPdu和TxPdu各1個。
4.5.2 通信棧分配配置
Cdd模塊的配置參數如表4-17所列。
表 4-17: J1939DcmCDD通信棧分配配置
4.6 PduR配置
PDU路由器模塊為I-PDUs的路由提供服務。
4.6.1 PduR模塊創建
按照圖4-21和圖4-22所示創建PduR模塊。
圖 4-21: PduR模塊創建啟動
圖 4-22: PduR模塊創建配置
后續需要依次進行PduR模塊的多余配置項刪除和配置文件選擇(無需統一路徑操作),這些步驟與前文的Can模塊操作基本相同。
4.6.2 Bsw模塊配置
需要對PduR上層或下層的BSW模塊(與PduR有接口)進行配置,這里添加J1939Tp和J1939DcmCDD兩個模塊,圖4-23為BSW模塊的添加方法。
圖 4-23: PduR相關BSW模塊添加
J1939Tp和J1939DcmCDD模塊的配置方法如表4-18和表4-19所列
表 4-18: J1939Tp模塊配置
表4-19: J1939DcmCDD模塊配置
4.6.3 PduR路由路徑配置
這里配置J1939DcmCDD和J1939Tp收發2個路由路徑,如圖4-24所示。
圖 4-24: J1939DcmCDD和J1939Tp路由路徑
圖4-25為PduR添加路由路徑的方法,表4-20和表4-21為收發2個方向的路由配置參數。
圖 4-25: PduR路由路徑添加
表 4-20: 發送路由路徑配置
表4-21: NPDU接收路由路徑配置
4.7 CanIf配置
CanIf模塊位于底層CAN設備驅動和上層通信服務層之間,提供CAN驅動服務向上層通信層的接口。
4.7.1 CanIf模塊創建
按照圖4-26和圖4-27所示創建CanIf模塊。
圖 4-26: CanIf模塊創建啟動
圖 4-27: CanIf模塊創建配置
后續需要依次進行CanIf模塊的多余配置項刪除和配置文件選擇(無需統一路徑操作),這些步驟與前文的Can模塊操作基本相同。
表4-22列出了CanIf模塊包含的配置箱。
表 4-22: CanIf模塊所含配置箱
4.7.2 CanIf私有配置
這個配置箱包含了CanIf的私有配置參數,如表4-23所列。
表 4-23: CanIf私有配置
4.7.3 CanIf公有配置
這個配置箱包含了CanIf的公共配置參數,如表4-24所列。
表 4-24: CanIf公共配置
①在重新生成RTA-BSW后可能需要手動重配
4.7.4 CanIf初始化配置
表4-25列出了CanIf初始化包含的子配置箱。
表 4-25: CanIf初始化所含子配置箱
(1)CanIf初始化硬件對象句柄配置
添加2個接收句柄和1個發送句柄,如表4-26、表4-27和表4-28所列。
表 4-26: CanIf連接管理報文接收句柄配置
表4-27: CanIf數據傳輸報文接收句柄配置
表4-28: CanIf發送句柄配置
(3)CanIf緩沖區配置
添加1個CanIf緩沖區,如表4-29所列。
表4-29: CanIf緩沖區配置
(3)CanIf接收Pdu配置
添加2個接收Pdu,如表4-30和表4-31所列。
表 4-30: CanIf接收連接管理Pdu配置
表4-31: CanIf接收數據傳輸Pdu配置
(4)CanIf發送Pdu配置
添加2個發送Pdu,如表4-32和表4-33所列。
表 4-32: CanIf發送連接管理Pdu配置
表4-33: CanIf發送數據傳輸Pdu配置
4.7.5 CanIf控制驅動配置
無需配置。
4.7.6 CanIf處理配置
無需配置。
4.8 J1939Tp配置
前文已經進行了J1939Tp模塊的創建和通用配置,下面進行其收發通道的配置。
4.8.1 J1939Tp接收通道配置
按照圖4-28和圖4-29所示進入J1939Tp接收通道配置界面,可以配置1個或多個接收通道。
圖 4-28: J1939Tp配置界面進入
圖 4-29: J1939Tp接收通道或發送通道添加
(1)接收通道通用配置
表4-34列出J1939Tp接收通道通用配置參數。
表 4-34: J1939Tp接收通道通用參數配置
(2)接收連接管理報文
配置J1939傳輸協議的TP.CM幀,用于BAM和CMDT初始化連接,配置參數如表4-35所列。
表 4-35: J1939Tp接收通道接收連接管理報文參數配置
(3)接收數據報文
配置J1939傳輸協議的TP.DT幀,用于BAM和CMDT數據傳輸,配置參數如表4-36所列。
表 4-36: J1939Tp接收通道接收數據報文參數配置
(4)接收參數組
配置被J1939傳輸層接收的參數組,配置參數如表4-37、表4-38和表4-39所列。
表 4-37: J1939Tp接收通道接收參數組配置
表 4-38: J1939Tp接收通道接收直接NPdu配置
表4-39: J1939Tp接收通道接收NSdu配置
(5)發送連接管理報文
配置使用CMDT協議類型時接收方發送的TP.CM幀,配置參數如表4-40所列。
表 4-40: J1939Tp接收通道發送連接管理報文參數配置
4.8.2 J1939Tp發送通道配置
可以配置1個或多個發送通道。
(1)發送通道通用配置
表4-41列出J1939Tp發送通道通用配置參數。
表 4-41: J1939Tp發送通道通用參數配置
(2)接收連接管理報文
配置J1939傳輸協議的TP.CM幀,僅適用于CMDT協議類型(J1939TpTxProtocolType配置為“J1939TP_PROTOCOL_CMDT”或不配置),配置參數如表4-42所列。
表 4-42: J1939Tp發送通道接收連接管理報文參數配置
(3)發送連接管理報文
配置J1939傳輸協議的TP.CM幀,用于BAM和CMDT初始化連接,配置參數如表4-43所列。
表 4-43: J1939Tp發送通道發送連接管理報文參數配置
(4)發送數據報文
配置J1939傳輸協議的TP.DT幀,用于BAM和CMDT數據傳輸,配置參數如表4-44所列。
表 4-44: J1939Tp發送通道發送數據報文參數配置
(5)發送參數組
配置被J1939傳輸層發送的參數組,配置參數如表4-45、表4-46和表4-47所列。
表 4-45: J1939Tp發送通道發送參數組配置
表4-46: J1939Tp發送通道發送直接NPdu配置
表4-47: J1939Tp發送通道發送NSdu配置
4.9 相關模塊配置
在J1939Tp及其相關模塊配置完成后,還需要在程序中調用J1939Tp的初始化和執行函數。
4.9.1 BswM
J1939Tp模塊的初始化函數是J1939Tp_Init,其調用在BswM中配置。
(1)BswM行為創建
新建1個名為“BswM_AI_J1939TpInit”的行為,再為其添加1個“BswMUserCallOut”,在其中調用J1939Tp_Init()函數。
(2)BswM行為列表添加
將“BswM_AI_J1939TpInit”添加到“BswM_AL_BswMSwitchRun”行為列表中。
4.9.2 任務調度
須以10ms為周期循環調用J1939Tp_MainFunction,圖4-30為其操作方法。
圖 4-30: J1939Tp主函數周期性調用配置
4.9.3 CanIf
每次生成RTA-BSW后,需按照表4-48所列配置CanIf。
表 4-48: 生成RTA-BSW后CanIf模塊配置項
4.10 MCAL配置
由于J1939Tp新增了3個CAN硬件對象,故需要配置MCAL的CAN模塊。
4.10.1 CAN過濾掩碼增加
在CAN4通道增加1路過濾掩碼,如圖4-31所示。
圖 4-31: CAN4通道過濾掩碼添加
4.10.2 CAN硬件對象配置
手動添加3路“CanHardwareObject”,如圖4-32所示;注意更改2個接收硬件對象的“CanFilterMaskRef”。
圖 4-32: CAN硬件對象添加
4.11 軟件集成
下面列出軟件集成和代碼編寫的步驟。
4.11.1 靜態代碼移植
在ISOLAR-AB環境下生成J1939Tp模塊的靜態代碼并將其拷貝到“...srcBSWsrcBSWGenJ1939Tp”路徑下,如圖4-33所示。
圖4-33: BSW靜態代碼生成
4.11.2 集成文件移植
在ISOLAR-AB環境下生成J1939Tp模塊的集成代碼并將J1939Tp_Cfg_SchM.h文件拷貝到“...srcINFRAschminc”路徑下。
4.11.3 內存映射文件移植
將J1939Tp_MemMap.h和J1939Tp_Cfg_MemMap.h內存映射頭文件拷貝到“...srcINFRAmemmap”文件夾下,這類文件在生成RTE時輸出程序文件模板,需要手動優化。
4.11.4 生成操作系統代碼
在“RTA-OS”工具中重新生成OS代碼。
4.11.5 J1939DcmCDD代碼實現
創建J1939DcmCDD.c和J1939DcmCDD.h程序文件并在其中完成下列函數的實現:
J1939DcmCDD_StartOfReception;
J1939DcmCDD_CopyRxData;
J1939DcmCDD_CopyTxData;
J1939DcmCDD_TpRxIndication;
J1939DcmCDD_TpTxConfirmation。
4.11.6 Hightec配置
在Hightec中添加下列頭文件路徑。
...srcCDDJ1939Dcminc;
...srcBSWsrcBSWGenJ1939Tpapi;
...srcBSWsrcBSWGenJ1939Tpsrc;
...srcBSWsrcBSWGenJ1939Tp。
4.12 軟件調試
這里記錄J1939Tp協議棧的調試過程,調試環境為PCAN,CAN通道為CAN4,波特率250K。
4.12.1 調試代碼編寫
數據發送:在J1939DcmCDD.c中編寫J1939DcmCDD_MainFunction函數,實現18字節數據的CAN發送;再在Os_SWC中以500ms為周期調用之。
數據接收:禁止上述18字節數據的周期性發送。
4.12.2 J1939發送調試
圖4-34為J1939數據發送調試截圖。VCU以500ms為周期發送18字節數據,包括1個連接管理報文和3個數據報文,這4個報文之間的發送間隔為60ms(這個時間間隔沒有搞明白原因)。
圖 4-34: J1939發送調試截圖
盡管多于8字節數據的報文發送正確,但在調試少于或等于8字節報文的發送時出現了問題,數據無法發出。
經過研讀AUTOSAR規范和分析靜態代碼,找到了出現上述問題的原因,是由于J1939Tp_Transmit函數的缺陷導致的,如圖4-35所示。
圖 4-35: J1939Tp發送函數問題分析
經過進一步分析,發現J1939TpTxPgDynLength配置項的功用并沒有體現在J1939Tp的靜態代碼中,故對J1939Tp_Transmit函數進行了如下改動(見圖4-36)。
圖 4-36: J1939Tp發送函數修改后的代碼
4.13 J1939接收調試
圖4-37為J1939數據接收調試截圖,第1、3、4、5個報文為PC機發送,第2、6個報文為VCU回饋。
圖 4-37: J1939接收調試截圖
修改靜態代碼前后,VCU均能正確接收到多于8字節和少于或等于8字節報文的數據。
五、下期預告
在AUTOSAR規范中,內存映射(Memory Map)似乎是非核心的模塊,但在解決各類工程問題(如數據標定區增加了幾個標定量就越界)的過程中,往往發揮著至關重要的作用。
在下期中,我們討論下內存映射的功用和實現方法,著重分享內存映射在AUTOSAR CP工程實踐中的妙用。
-
CAN總線
+關注
關注
145文章
1986瀏覽量
132810 -
AUTOSAR
+關注
關注
10文章
379瀏覽量
22647 -
通訊協議
+關注
關注
10文章
289瀏覽量
20843
原文標題:從手寫代碼到AUTOSAR工具鏈(J1939Tp應用篇)
文章出處:【微信號:ETASChina,微信公眾號:ETAS易特馳】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
基于J1939協議的組合儀表的設計與實現
J1939基礎入門知識分享
SAE J1939 協議源代碼分享
基于J1939協議的組合儀表的設計與實現
基于J1939的汽車CAN總線教學實驗系統
SAE J1939協議分析指南
基于SAE J1939協議的車輛網絡通信

CAN高層協議J1939的基礎和應用以及開發介紹

基于恩智浦MPC5744P的SAE J1939協議棧開發

從手寫代碼到AUTOSAR工具鏈_MCAL應用篇

評論