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

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

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

圖3 CCP標(biāo)定程序接口

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

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

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

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

圖4 接口程序基本流程圖

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

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

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

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