利用CANape進(jìn)行基于CCP的汽車(chē)控制器的匹配標定的設計

2 基于CCP協(xié)議的接口程序實(shí)現

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

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

圖3 CCP標定程序接口

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

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

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

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

圖4 接口程序基本流程圖

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

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

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

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