基于CAN的遠程下載技術(shù)開發(fā)及應(yīng)用
加入技術(shù)交流群
1.2 系統(tǒng)功能設(shè)計
在整個設(shè)計開發(fā)中，關(guān)鍵之處是目標(biāo)端 Bootloader 自舉程序的開發(fā)。結(jié)合到VRV 空調(diào)系統(tǒng)的實際應(yīng)用，整個系統(tǒng)應(yīng)該至少具有以下功能：
(1)多種下載方式的提供。VRV 空調(diào)系統(tǒng)運行當(dāng)中，可能需要根據(jù)實際情況采用不同的方式來進行遠程下載。因而需要實現(xiàn)對單點、多點及廣播等通訊方式的支持。
(2)軟件復(fù)位功能。即便是目標(biāo)端設(shè)備已經(jīng)具備利用Bootloader 自舉程序來實現(xiàn)遠程下載的能力，但由于Bootloader 機制需要目標(biāo)端先復(fù)位，才能重新再執(zhí)行Bootloader 自舉程序。
然而現(xiàn)場環(huán)境往往不能實施掉電或其他硬件方式復(fù)位目標(biāo)端設(shè)備，這便需要有軟件實現(xiàn)復(fù)位的手段。在此，將軟件復(fù)位作為自定義的通訊協(xié)議中一個命令，由主機端發(fā)送給目標(biāo)端，目標(biāo)端的用戶應(yīng)用程序內(nèi)接收到這一命令，經(jīng)過解析、確認(rèn)后進行復(fù)位。
(3)加/解密功能。鑒于多聯(lián)機空調(diào)系統(tǒng)的商用價值，Bootloader 程序應(yīng)當(dāng)具備加密的功能，保護知識產(chǎn)權(quán)。這可以通過主機端和目標(biāo)端之間采用一種密鑰或加、解密算法，融合到通訊數(shù)據(jù)中實現(xiàn)。
(4)異常處理功能。在通訊過程中，很有可能出現(xiàn)如主機端出現(xiàn)故障，造成當(dāng)前的數(shù)據(jù)不能繼續(xù)成功發(fā)給目標(biāo)端。目標(biāo)端運行自舉程序時，只有等到主機端數(shù)據(jù)全部通訊完畢，才可以跳轉(zhuǎn)到用戶應(yīng)用程序，繼續(xù)執(zhí)行。此會造成目標(biāo)端一直處于等待狀態(tài)，效率低下或者接收錯誤數(shù)據(jù)并執(zhí)行，以致出現(xiàn)嚴(yán)重后果。在系統(tǒng)設(shè)計開發(fā)時需要預(yù)留一個能夠?qū)崿F(xiàn)異常處理的命令以便主機端恢復(fù)后，將這個命令下發(fā)，目標(biāo)段根據(jù)這個命令，重新接收正確的數(shù)據(jù)。
2 協(xié)議設(shè)計
要將系統(tǒng)的目標(biāo)端和主機端之間，設(shè)計成支持單點、多點以及廣播等多種遠程下載方式，并且支持、軟件復(fù)位和異常處理、加解密等功能，可以充分利用 CAN 總線數(shù)據(jù)幀的29 位（遵循CAN2.0B 協(xié)議）標(biāo)識符來實現(xiàn)。定制的通訊協(xié)議中CAN 的幀格式如表1 所示，將CAN 的29 位標(biāo)示符分為五段：優(yōu)先級、控制域、通訊方式、節(jié)點編號、命令編號。
表 1 數(shù)據(jù)幀29 位標(biāo)識符分配表
數(shù)據(jù)幀29 位標(biāo)識符分配表
優(yōu)先級：00->01->10->11 優(yōu)先級別依次降低，默認(rèn)優(yōu)先級別為11，故障報警優(yōu)先級最高為00，數(shù)據(jù)傳輸優(yōu)先級為01，命令下傳優(yōu)先級為10，應(yīng)答返回優(yōu)先級為11。
控制域：ID26/ID22，用以表示當(dāng)前的數(shù)據(jù)幀屬于哪一種類型：故障為00、數(shù)據(jù)為01、命令10、應(yīng)答11。
通訊方式：ID24/ID15，指定當(dāng)前的數(shù)據(jù)幀是廣播傳輸或者單點傳輸，全為0 是單點而全為1 是廣播。
節(jié)點編號：ID14/ID8，共7 位，足夠標(biāo)識CAN 總線支持的多達112 個節(jié)點的最大負(fù)載。
命令編號：這里存放的是根據(jù)實際需要定制的一些命令，如軟件復(fù)位命令、異常處理命令。主機端將定制的命令編號下發(fā)，目標(biāo)端接收到命令后，解析后執(zhí)行相應(yīng)動作。仿照上表，配置各個目標(biāo)端的接收過濾碼和接收屏蔽碼，便可以實現(xiàn)單點、多點以及廣播通訊。另外，對于單點通訊方式下的遠程下載，為保證主機端和目標(biāo)端的通訊數(shù)據(jù)的正確和可靠傳輸，采用應(yīng)答機制來實現(xiàn)，并定制了一套圖3 所示的通訊鏈路機制。
主機端和目標(biāo)端應(yīng)答鏈路機制圖
圖 3 主機端和目標(biāo)端應(yīng)答鏈路機制圖
遠程下載的通訊只能由主機端開啟。主機端先發(fā)送讀取器件型號命令，讀取目標(biāo)端器件芯片型號，目標(biāo)端收到這個命令，回復(fù)本身的型號數(shù)據(jù)作為一個應(yīng)答，主機端根據(jù)這個型號，再開辟動態(tài)內(nèi)存和組織要下傳的數(shù)據(jù)。主機端接著下發(fā)一個讀取器件PROM 命令，以獲取目標(biāo)端器件位于地址0x00 處的數(shù)據(jù)，將和從主機端讀取并解析、組織后的HEX 文件一起下傳。主機端收到這一步的應(yīng)答后，開始發(fā)送寫PROM 命令和PROM 數(shù)據(jù)，目標(biāo)端將接收到的數(shù)據(jù)寫入相應(yīng)的地址段，每完成一頁寫操作，返回一個應(yīng)答,接著接收主機端下傳的下一頁數(shù)據(jù)。PROM 寫數(shù)據(jù)發(fā)送完后，主機端接著發(fā)送寫CM 數(shù)據(jù)命令和寫CM 數(shù)據(jù)，過程和寫PROM 是一樣的。最后，主機端下發(fā)一個跳轉(zhuǎn)命令，目標(biāo)端收到這個命令后，跳轉(zhuǎn)到程序存儲器的0x00 地址處。然后，目標(biāo)端根據(jù)地址0x00 處存放的數(shù)據(jù)，跳轉(zhuǎn)到用戶應(yīng)用程序。
而對于多點或廣播，通常都是對數(shù)百甚至上千目標(biāo)端進行下載。如果目標(biāo)端都應(yīng)答，會造成總線上數(shù)據(jù)的堵塞，浪費大量的總線時間。所以采用非應(yīng)答機制，直接燒寫程序存儲器。
此時主機端數(shù)據(jù)的下傳，采用定時器觸發(fā)方式。每當(dāng)定時時間到達時，觸發(fā)一次數(shù)據(jù)的發(fā)送。
直至最后，發(fā)送一個跳轉(zhuǎn)命令。如果目標(biāo)端沒有執(zhí)行跳轉(zhuǎn)，那么認(rèn)為當(dāng)前目標(biāo)端沒能正確接收主機端發(fā)送的數(shù)據(jù)，主機端重新對當(dāng)前目標(biāo)端進行一次單點方式下的遠程下載。
3 目標(biāo)端設(shè)計方案
目標(biāo)端Bootloader 自舉程序一般只是一個簡單的通訊程序，負(fù)責(zé)接收和發(fā)送數(shù)據(jù)，通常只需極少的存儲空間，可以位于單片機程序存儲器特定的Boot Segment 區(qū)域。程序存儲器還有一段稱為General Segment 區(qū)域可用于存儲用戶應(yīng)用程序。單片機的程序存儲器大多都是FLASH 閃存，數(shù)據(jù)是以一個個數(shù)據(jù)頁的形式存儲，必須先對當(dāng)前存儲頁擦除，然后才能寫入數(shù)據(jù)。自舉程序還需使用dsPIC33 單片機器件中斷向量表 (IVT) 中的復(fù)位向量實現(xiàn)程序的跳轉(zhuǎn)、以及器件上的CAN 通信模塊。單片機的程序存儲器的地址映射如下圖4 所示。
dsPIC33F 程序存儲器地址映射圖
圖 4 dsPIC33F 程序存儲器地址映射圖
評論