SFP+雙MCU光收發(fā)模塊升級的設(shè)計(jì)與實(shí)現(xiàn)
隨著全球光通信的日益發(fā)展,光通信的發(fā)展已經(jīng)取得了驚人的成就。Alcatel-Lucent在2007年光通信會議(OFC2007)上宣布他們成功將單根光纖傳輸數(shù)據(jù)率提高到25.6 Tbit/s,創(chuàng)造了一項(xiàng)新世界紀(jì)錄。因此,如今的光通信已經(jīng)不僅僅要解決大容量傳輸和寬帶接入的問題,更關(guān)鍵的是實(shí)現(xiàn)光層的智能化和節(jié)點(diǎn)的光交換,從而建立起動態(tài)高效、擴(kuò)展靈活、經(jīng)濟(jì)可靠的光網(wǎng)絡(luò),以滿足信息傳輸?shù)囊蟆?/p>本文引用地址:http://butianyuan.cn/article/201612/327786.htm
1 雙MCU的嵌入式系統(tǒng)升級的整體設(shè)計(jì)
SFP+波長可調(diào)諧光模塊主要由3個(gè)部分組成:光發(fā)射部分、光接收部分和控制部分,控制部分分別由MCU1和MCU2共同協(xié)作完成。本系統(tǒng)采用ADuC7023作為MCU控制模塊,運(yùn)行穩(wěn)定可靠,實(shí)現(xiàn)了波長可調(diào)。其中,MCU1主要控制模塊正常穩(wěn)定發(fā)光,而MCU2主要用于實(shí)現(xiàn)波長切換。以下便設(shè)計(jì)了一種更新此嵌入式系統(tǒng)的升級方案,具體的整體框架如圖1所示。
圖1 升級系統(tǒng)的整體架構(gòu)
1)通信協(xié)議上位機(jī):主要通過GUI(Graphical UserInterface)下發(fā)Hex文件,通過串口發(fā)送給下載板。
2)下載板:接收到串口發(fā)送的數(shù)據(jù)之后進(jìn)行判斷,如果是給MCU1下載程序則下載板將接收到的數(shù)據(jù)封裝為滿足AN806_I2C Download Protocol for ADulC70xxBCPZxxI Models下載協(xié)議的幀結(jié)構(gòu),并按照此協(xié)議的要求更新MCU1;如果是給MCU2下載程序,則下載板將收到的數(shù)據(jù)直接通過I2C(Inter—Integrated Circuit)轉(zhuǎn)發(fā)給MCU1。
3)MCU1:MCU1作為光模塊的主機(jī),MCU2作為從機(jī)。當(dāng)給MCU2下載程序時(shí),MCU1將接收到的數(shù)據(jù)封裝為滿足AN806_I2C Download Protocol for ADulC70xxBCPZxxI Models下載協(xié)議的幀結(jié)構(gòu),并按照此協(xié)議的要求更新MCU2;否則,MCU1執(zhí)行自身的程序,控制整個(gè)模塊的正常運(yùn)行。
2 雙MCU嵌入式系統(tǒng)升級的實(shí)現(xiàn)
雙MCU嵌入式系統(tǒng)升級的實(shí)現(xiàn)可分為以下幾個(gè)部分:實(shí)現(xiàn)串口數(shù)據(jù)收集,實(shí)現(xiàn)數(shù)據(jù)的封裝以及按照下載協(xié)議實(shí)現(xiàn)系統(tǒng)的更新。
2.1 串口數(shù)據(jù)收集實(shí)現(xiàn)
上位機(jī)(GUI)將Hex文件一行一行地發(fā)送給下載板,通過協(xié)議轉(zhuǎn)換模塊對數(shù)據(jù)封裝后通過下載協(xié)議更新需要升級的系統(tǒng)。而串口每次只能發(fā)送一個(gè)ASCII碼字符給下載板。下載板接收到數(shù)據(jù)后將每2個(gè)ASCII碼合并為1個(gè)相應(yīng)的十六進(jìn)制數(shù)據(jù),從而實(shí)現(xiàn)數(shù)據(jù)的收集。
2.2 數(shù)據(jù)封裝的實(shí)現(xiàn)
數(shù)據(jù)的封裝可根據(jù)具體的更新哪塊MCU分別在下載板(更新MCU1)或MCU1(更新MCU2)中完成。由于數(shù)據(jù)封裝前是Hex的幀結(jié)構(gòu),無法滿足下載協(xié)議的要求,所以在更新系統(tǒng)之前必須對數(shù)據(jù)進(jìn)行封裝,使其滿足協(xié)議的要求。下面將介紹具體的實(shí)現(xiàn)方式。
1)Hex文件的幀結(jié)構(gòu)如圖2所示。
圖2 Hex文件的幀結(jié)構(gòu)
(1)起始符:固定為“:”用于記錄一幀數(shù)據(jù)的開始。
(2)數(shù)據(jù)字節(jié)數(shù):后面的2個(gè)字符表明記錄的長度。一般情況為0x10,表明這一幀中傳送的有效數(shù)據(jù)位16 byte。
(3)地址位:4個(gè)字符表明調(diào)入的起始地址。
(4)數(shù)據(jù)類型:2個(gè)字符表明記錄的類型。以下為具體的字符對應(yīng)的不同的數(shù)據(jù)類型:
0:數(shù)據(jù)記錄。
l:記錄文件結(jié)束。
2:擴(kuò)展地址記錄。
3:開始段地址記錄。
4:擴(kuò)展線性地址記錄。
5:開始線性地址記錄。
(5)數(shù)據(jù):表明有效的數(shù)據(jù)。
(6)校驗(yàn)和:最后的2位表明校驗(yàn)和檢查,它加上前面所有的數(shù)據(jù)為0。
2)下載協(xié)議規(guī)定的數(shù)據(jù)幀結(jié)構(gòu)如圖3所示。
圖3發(fā)送數(shù)據(jù)的幀結(jié)構(gòu)
(1)起始ID:0x07和0x0E是兩個(gè)固定的有效值。
(2)數(shù)據(jù)字節(jié)數(shù):表示數(shù)據(jù)幀中傳輸?shù)臄?shù)據(jù),從Datal開始算起。最小值為5,最大值為255。
(3)數(shù)據(jù)1 CMD,如表1所示。
表1 命令功能
(4)數(shù)據(jù)2一數(shù)據(jù)5(Address:h,u,m,1):該地址字段包含一個(gè)32位地址h,u,m,l,其中h中包含最高有效位(MSB),l中包含最低有效位(LSB)。
(5)數(shù)據(jù)x(x=6~255):用戶代碼是按字節(jié)下載的,數(shù)據(jù)字節(jié)字段最多為250個(gè)數(shù)據(jù)字節(jié)。數(shù)據(jù)必須是擴(kuò)展Hex 16字節(jié)記錄格式的數(shù)據(jù)串,而且在傳輸?shù)郊虞d器之前作為上面數(shù)據(jù)表格的一部分由主機(jī)重新編譯。
(6)校驗(yàn)和:校驗(yàn)和的計(jì)算方法為所有數(shù)據(jù)的和取余。
3)幀結(jié)構(gòu)封裝的實(shí)現(xiàn)
協(xié)議轉(zhuǎn)換模塊將收到的每2個(gè)ASCII碼轉(zhuǎn)化為1個(gè)對應(yīng)的十六進(jìn)制,并存放于特定的緩存中。當(dāng)協(xié)議轉(zhuǎn)換模塊收到回車換行后就會開始幀結(jié)構(gòu)的封裝工作。按照協(xié)議規(guī)定,為數(shù)據(jù)加入Start ID;幀結(jié)構(gòu)中的No.of Data Bytes的值為Hex文件中數(shù)據(jù)的個(gè)數(shù)加5(其中主要加入了CMD Byte以及4 byte的地址);Datal則是命令Byte可根據(jù)協(xié)議要求寫入適當(dāng)?shù)拿?,在更新系統(tǒng)時(shí)應(yīng)使用寫命令W(0x57);Data2一Data5為Hex文件中指定的地址;Data x對應(yīng)Hex文件中的數(shù)據(jù)部分;Checksum則為0x00減去從Bytel~Byte x 的所有數(shù)據(jù)的和。從而實(shí)現(xiàn)對數(shù)據(jù)的封裝。
2.3 模塊更新的實(shí)現(xiàn)
AN806一I2C Download Protocol是一種廣泛使用的ADuC70xxBCPZxxI模塊的下載協(xié)議。依照協(xié)議的具體規(guī)定設(shè)計(jì)和實(shí)現(xiàn)了雙MCU模塊的升級,具體的模塊更新流程如圖4所示。
圖4模塊更新流程
1)運(yùn)行微轉(zhuǎn)換器加載器
為了防止I2C意外下載,I2C下載模式進(jìn)人前提是在復(fù)位器件串行下載保持低電平、同時(shí)Flash/EE存儲器Oxl4地址單元的內(nèi)容為0xFFFFFFFF。因此,用戶代碼必須有一個(gè)內(nèi)置機(jī)制用來擦除第0頁(Flash地址0x0到0x200)和復(fù)位器件。該機(jī)制允許進(jìn)入下載模式對器件重新編譯。在理想情況下,為了能夠在數(shù)據(jù)重編程時(shí)出現(xiàn)掉電故障或出現(xiàn)其他錯(cuò)誤時(shí)重新進(jìn)入下載模式,F(xiàn)lash地址單元Oxl4應(yīng)該最后編程。
在基于MCU的嵌入式系統(tǒng)中,程序的存儲區(qū)與數(shù)據(jù)的存儲區(qū)是一致的,有時(shí)只是為了更新程序而又希望可以保留原有的數(shù)據(jù),此時(shí)往往選擇只擦除程序部分。因此,在執(zhí)行擦除命令時(shí)要首先確定是否需要保留數(shù)據(jù)部分,避免誤操作。
2)啟動下載協(xié)議
一旦加載器進(jìn)入下載模式,加載器從機(jī)器件地址為0x04,因此,每次向加載器發(fā)送數(shù)據(jù),主機(jī)必須以字節(jié)0x04(I2c寫地址)開始,每次從加載器讀取命令應(yīng)答請求以字節(jié)0x05(I2C讀地址)開始。加載器的第一個(gè)數(shù)據(jù)包的數(shù)據(jù)必須為退格符(BS=0x08)以啟動該協(xié)議。
在收到退格符后,加載器發(fā)送如下24 byte ID數(shù)據(jù)包:
15 byte=產(chǎn)品標(biāo)示符
3 byte=硬件和固件的版本號
4 byte=保留
2 byte=換行和回車
3)加載器接收數(shù)據(jù)
為了防止在重新編程過程中出現(xiàn)的異常故障使得MCU無法再次進(jìn)入下載模式,所以Flash地址單元0x14應(yīng)該最后編程。從Hex文件的幀結(jié)構(gòu)中可以發(fā)現(xiàn)0x14在第2行Hex中,也就是說第2行Hex文件應(yīng)該在其他數(shù)據(jù)傳完之后再寫入。由于程序的起始點(diǎn)在第1行,所以Hex文件的第1行和第2行應(yīng)該放在最后寫入。協(xié)議轉(zhuǎn)換器發(fā)送數(shù)據(jù)的具體軟件流程如圖5所示。
圖5 協(xié)議轉(zhuǎn)換器發(fā)送數(shù)據(jù)的具體軟件流程圖
其中,若加載器為MCU1則協(xié)議轉(zhuǎn)換器為下載板,即數(shù)據(jù)的封裝在下載板中完成;若加載器為MCU2則協(xié)議轉(zhuǎn)換器為MCU2,即數(shù)據(jù)的封裝在MCU1中完成,此時(shí)下載板只起轉(zhuǎn)發(fā)的作用。
4)加載器接收遠(yuǎn)程執(zhí)行命令
一旦主機(jī)將所有的數(shù)據(jù)包發(fā)送到加載器,主機(jī)可以發(fā)送最后一個(gè)包以指示加載器開始執(zhí)行代碼。具體的軟件流程如圖6所示。
圖6協(xié)議轉(zhuǎn)換器重啟加載器的軟件流程圖
其中有2種不同的遠(yuǎn)程運(yùn)行方式:軟件復(fù)位(h,u,m,l=0x1)和跳轉(zhuǎn)至用戶代碼(h,u,m,l=0x0)。一般情況下,會選擇軟件復(fù)位,因?yàn)檐浖?fù)位可以重置所有外設(shè)。然而在串行接口永久接地和地址0x80014被清零的情況下,有必要采用一個(gè)跳轉(zhuǎn)直接到用戶代碼。如果采用軟件復(fù)位,則最后發(fā)送的數(shù)據(jù)包的幀結(jié)構(gòu)如表2所示。
表2 軟件復(fù)位的幀結(jié)構(gòu)
2.4 實(shí)驗(yàn)結(jié)果
圖7是使用本設(shè)計(jì)方案升級SFP+雙MCU嵌入式系統(tǒng)的測試結(jié)果,測試結(jié)果顯示MCU2在更新之前的版本號為v101,升級之后的版本號為v102。這說明本設(shè)計(jì)方案是可行可靠的。
圖7測試結(jié)果
3 結(jié)束語
如今,大多數(shù)光通信依舊使用傳統(tǒng)的基于固定波長光模塊的光源,尤其是目前被廣泛使用的10 Gbit/s光模塊都使用的這種固定波長激光器,這對光模塊的利用存在極大的局限性,而目前這種缺陷已經(jīng)漸漸地顯露出來。為了提高模塊的利用率、降低網(wǎng)絡(luò)建設(shè)的成本、減小管理的復(fù)雜性、提高網(wǎng)絡(luò)的靈活性,SFP+波長可調(diào)諧的光模塊應(yīng)運(yùn)而生。此可調(diào)諧光模塊的實(shí)現(xiàn)是基于DBR可調(diào)諧半導(dǎo)體激光器實(shí)現(xiàn)的。它可以在整個(gè)C波段,100個(gè)通道上實(shí)現(xiàn)波長切換,從而提高了光網(wǎng)絡(luò)的靈活性同時(shí)也降低了網(wǎng)絡(luò)組建的成本、降低了光模塊管理的復(fù)雜性。由于SFP+波長可調(diào)諧光模塊功能的復(fù)雜性以及PCBA本身面積的局限性,出現(xiàn)了雙MCU的系統(tǒng),這樣對于多MCU系統(tǒng)如何實(shí)現(xiàn)系統(tǒng)的升級更新是一個(gè)急需解決的問題。本文以AN806 I2C Download Protocol為基礎(chǔ),實(shí)現(xiàn)了SFP+波長可調(diào)諧光模塊雙MCU嵌入式系統(tǒng)的升級。
評論