利用CANape進行基于CCP的汽車控制器的匹配標定的設計

2 基于CCP協(xié)議的接口程序?qū)崿F(xiàn)

基于CCP協(xié)議進行標定,需要MCS與ECU的應用程序都能夠支持CCP協(xié)議,這部分應用程序稱為CCP driver。本文采用Vector提供的free CCP driver[2]。由于CCP協(xié)議基于CAN總線,因此CCP driver與ECU的結(jié)合主要分為與CAN driver及與其他應用程序兩方面。

CCP driver與CAN driver的結(jié)合如圖3,主要分為以下兩方面:

圖3 CCP標定程序接口

·發(fā)送端:DTO通過CAN driver的發(fā)送子函數(shù)以CAN報文的格式上傳給MCS。

·接收端:主設備發(fā)送的命令以CAN報文的格式首先進入CAN driver的接收子函數(shù),由其判斷為CRO后,進一步交給命令處理器處理。

命令處理器作為CCP driver的一個主要組成部分,負責將接收到的CRO,通過其CRM代碼進行命令解釋,執(zhí)行相應操作,組織反饋數(shù)據(jù)并調(diào)用CAN發(fā)送子函數(shù)。DAQ處理器支持DAQ工作模式,當命令處理器判斷收到的命令為DAQ請求后,進一步將數(shù)據(jù)傳給DAQ處理器,由DAQ處理器組織數(shù)據(jù)并直接調(diào)用CAN 發(fā)送子函數(shù),以DAQ-DTO的形式定期向主設備上傳。

基于CCP協(xié)議的基本CAN通信流程如圖4所示。ECU接收到報文后,轉(zhuǎn)入CAN接收子函數(shù),在常規(guī)接收流程后,對報文的ID標識符進行判斷,如為CRO_ID,則將CCP標志位(Ccp_indicator)置位。由于采用中斷方式接收報文,為了避免占用過多中斷時間而影響其他函數(shù)或中斷級別較低的程序運行,在對ID標識符進行判斷后,并不直接在函數(shù)中調(diào)用CCP driver的命令處理器。命令處理器的調(diào)用會在主函數(shù)中進行。

圖4 接口程序基本流程圖

主函數(shù)通過判斷標志位的狀態(tài),調(diào)用CCP driver的ccpCommand()子函數(shù)。該函數(shù)是命令處理器的主要組成部分,也是命令處理器與CAN driver的接口函數(shù),它負責解釋并執(zhí)行收到的CRO命令,調(diào)用CCP driver中的其他函數(shù),進行數(shù)據(jù)處理并組織需要反饋的數(shù)據(jù)。

ccpCommand()通過調(diào)用CAN driver中的CCP發(fā)送子函數(shù)ccpSend()發(fā)送一幀DTO。ccpSend()須在CAN driver中實現(xiàn),由CCP driver調(diào)用。按實際情況,將CAN發(fā)送子函數(shù)直接以ccpSend()的形式實現(xiàn),或在保留原有發(fā)送子函數(shù)的基礎上添加一個ccpSend()子函數(shù),在其中調(diào)用CAN發(fā)送子函數(shù),以完成DTO的發(fā)送。

CCP協(xié)議為確保主設備與ECU之間正常通信,每次發(fā)送后,程序必須通過調(diào)用CCP driver中的ccpSendCallback()子函數(shù)檢查剛才的DTO是否已經(jīng)發(fā)送,否則不能發(fā)送下一幀報文。針對不同的CAN driver實現(xiàn),該函數(shù)調(diào)用的位置不同。最后主函數(shù)將CCP標志位清空,等待下一條CRO命令。

一個完整的CCP driver 接口還包括與ECU其他應用程序的接口。每次單片機初始化后,主函數(shù)調(diào)用一次CCP driver的CCP初始化子函數(shù)ccpInit(),將上次標定殘留在ECU內(nèi)存中的數(shù)據(jù)清空,為下次標定與測量做準備。