SFP+雙MCU光收發(fā)模塊升級的設計與實(shí)現

隨著(zhù)全球光通信的日益發(fā)展，光通信的發(fā)展已經(jīng)取得了驚人的成就。Alcatel-Lucent在2007年光通信會(huì )議(OFC2007)上宣布他們成功將單根光纖傳輸數據率提高到25.6 Tbit/s，創(chuàng )造了一項新世界紀錄。因此，如今的光通信已經(jīng)不僅僅要解決大容量傳輸和寬帶接入的問(wèn)題，更關(guān)鍵的是實(shí)現光層的智能化和節點(diǎn)的光交換，從而建立起動(dòng)態(tài)高效、擴展靈活、經(jīng)濟可靠的光網(wǎng)絡(luò )，以滿(mǎn)足信息傳輸的要求。

1 雙MCU的嵌入式系統升級的整體設計

SFP+波長(cháng)可調諧光模塊主要由3個(gè)部分組成：光發(fā)射部分、光接收部分和控制部分，控制部分分別由MCU1和MCU2共同協(xié)作完成。本系統采用ADuC7023作為MCU控制模塊，運行穩定可靠，實(shí)現了波長(cháng)可調。其中，MCU1主要控制模塊正常穩定發(fā)光，而MCU2主要用于實(shí)現波長(cháng)切換。以下便設計了一種更新此嵌入式系統的升級方案，具體的整體框架如圖1所示。

圖1 升級系統的整體架構

1)通信協(xié)議上位機：主要通過(guò)GUI(Graphical UserInterface)下發(fā)Hex文件，通過(guò)串口發(fā)送給下載板。

2)下載板：接收到串口發(fā)送的數據之后進(jìn)行判斷，如果是給MCU1下載程序則下載板將接收到的數據封裝為滿(mǎn)足AN806_I2C Download Protocol for ADulC70xxBCPZxxI Models下載協(xié)議的幀結構，并按照此協(xié)議的要求更新MCU1;如果是給MCU2下載程序，則下載板將收到的數據直接通過(guò)I2C(Inter—Integrated Circuit)轉發(fā)給MCU1。

3)MCU1：MCU1作為光模塊的主機，MCU2作為從機。當給MCU2下載程序時(shí)，MCU1將接收到的數據封裝為滿(mǎn)足AN806_I2C Download Protocol for ADulC70xxBCPZxxI Models下載協(xié)議的幀結構，并按照此協(xié)議的要求更新MCU2;否則，MCU1執行自身的程序，控制整個(gè)模塊的正常運行。

2 雙MCU嵌入式系統升級的實(shí)現

雙MCU嵌入式系統升級的實(shí)現可分為以下幾個(gè)部分：實(shí)現串口數據收集，實(shí)現數據的封裝以及按照下載協(xié)議實(shí)現系統的更新。

2.1 串口數據收集實(shí)現

上位機(GUI)將Hex文件一行一行地發(fā)送給下載板，通過(guò)協(xié)議轉換模塊對數據封裝后通過(guò)下載協(xié)議更新需要升級的系統。而串口每次只能發(fā)送一個(gè)ASCII碼字符給下載板。下載板接收到數據后將每2個(gè)ASCII碼合并為1個(gè)相應的十六進(jìn)制數據，從而實(shí)現數據的收集。

2.2 數據封裝的實(shí)現

數據的封裝可根據具體的更新哪塊MCU分別在下載板(更新MCU1)或MCU1(更新MCU2)中完成。由于數據封裝前是Hex的幀結構，無(wú)法滿(mǎn)足下載協(xié)議的要求，所以在更新系統之前必須對數據進(jìn)行封裝，使其滿(mǎn)足協(xié)議的要求。下面將介紹具體的實(shí)現方式。

1)Hex文件的幀結構如圖2所示。

圖2 Hex文件的幀結構

(1)起始符：固定為“：”用于記錄一幀數據的開(kāi)始。

(2)數據字節數：后面的2個(gè)字符表明記錄的長(cháng)度。一般情況為0x10，表明這一幀中傳送的有效數據位16 byte。

(3)地址位：4個(gè)字符表明調入的起始地址。

(4)數據類(lèi)型：2個(gè)字符表明記錄的類(lèi)型。以下為具體的字符對應的不同的數據類(lèi)型：

0：數據記錄。

l：記錄文件結束。

2：擴展地址記錄。

3：開(kāi)始段地址記錄。

4：擴展線(xiàn)性地址記錄。

5：開(kāi)始線(xiàn)性地址記錄。

(5)數據：表明有效的數據。

(6)校驗和：最后的2位表明校驗和檢查，它加上前面所有的數據為0。

2)下載協(xié)議規定的數據幀結構如圖3所示。

圖3發(fā)送數據的幀結構

(1)起始ID：0x07和0x0E是兩個(gè)固定的有效值。

(2)數據字節數：表示數據幀中傳輸的數據，從Datal開(kāi)始算起。最小值為5，最大值為255。

(3)數據1 CMD，如表1所示。

表1 命令功能

(4)數據2一數據5(Address：h，u，m，1)：該地址字段包含一個(gè)32位地址h，u，m，l，其中h中包含最高有效位(MSB)，l中包含最低有效位(LSB)。

(5)數據x(x=6～255)：用戶(hù)代碼是按字節下載的，數據字節字段最多為250個(gè)數據字節。數據必須是擴展Hex 16字節記錄格式的數據串，而且在傳輸到加載器之前作為上面數據表格的一部分由主機重新編譯。

(6)校驗和：校驗和的計算方法為所有數據的和取余。

3)幀結構封裝的實(shí)現

協(xié)議轉換模塊將收到的每2個(gè)ASCII碼轉化為1個(gè)對應的十六進(jìn)制，并存放于特定的緩存中。當協(xié)議轉換模塊收到回車(chē)換行后就會(huì )開(kāi)始幀結構的封裝工作。按照協(xié)議規定，為數據加入Start ID;幀結構中的No.of Data Bytes的值為Hex文件中數據的個(gè)數加5(其中主要加入了CMD Byte以及4 byte的地址);Datal則是命令Byte可根據協(xié)議要求寫(xiě)入適當的命令，在更新系統時(shí)應使用寫(xiě)命令W(0x57);Data2一Data5為Hex文件中指定的地址;Data x對應Hex文件中的數據部分;Checksum則為0x00減去從Bytel～Byte x 的所有數據的和。從而實(shí)現對數據的封裝。

2.3 模塊更新的實(shí)現

AN806一I2C Download Protocol是一種廣泛使用的ADuC70xxBCPZxxI模塊的下載協(xié)議。依照協(xié)議的具體規定設計和實(shí)現了雙MCU模塊的升級，具體的模塊更新流程如圖4所示。

圖4模塊更新流程

1)運行微轉換器加載器

為了防止I2C意外下載，I2C下載模式進(jìn)人前提是在復位器件串行下載保持低電平、同時(shí)Flash/EE存儲器Oxl4地址單元的內容為0xFFFFFFFF。因此，用戶(hù)代碼必須有一個(gè)內置機制用來(lái)擦除第0頁(yè)(Flash地址0x0到0x200)和復位器件。該機制允許進(jìn)入下載模式對器件重新編譯。在理想情況下，為了能夠在數據重編程時(shí)出現掉電故障或出現其他錯誤時(shí)重新進(jìn)入下載模式，Flash地址單元Oxl4應該最后編程。

在基于MCU的嵌入式系統中，程序的存儲區與數據的存儲區是一致的，有時(shí)只是為了更新程序而又希望可以保留原有的數據，此時(shí)往往選擇只擦除程序部分。因此，在執行擦除命令時(shí)要首先確定是否需要保留數據部分，避免誤操作。

2)啟動(dòng)下載協(xié)議

一旦加載器進(jìn)入下載模式，加載器從機器件地址為0x04，因此，每次向加載器發(fā)送數據，主機必須以字節0x04(I2c寫(xiě)地址)開(kāi)始，每次從加載器讀取命令應答請求以字節0x05(I2C讀地址)開(kāi)始。加載器的第一個(gè)數據包的數據必須為退格符(BS=0x08)以啟動(dòng)該協(xié)議。

在收到退格符后，加載器發(fā)送如下24 byte ID數據包：

15 byte=產(chǎn)品標示符

3 byte=硬件和固件的版本號

4 byte=保留

2 byte=換行和回車(chē)

3)加載器接收數據

為了防止在重新編程過(guò)程中出現的異常故障使得MCU無(wú)法再次進(jìn)入下載模式，所以Flash地址單元0x14應該最后編程。從Hex文件的幀結構中可以發(fā)現0x14在第2行Hex中，也就是說(shuō)第2行Hex文件應該在其他數據傳完之后再寫(xiě)入。由于程序的起始點(diǎn)在第1行，所以Hex文件的第1行和第2行應該放在最后寫(xiě)入。協(xié)議轉換器發(fā)送數據的具體軟件流程如圖5所示。

圖5 協(xié)議轉換器發(fā)送數據的具體軟件流程圖

其中，若加載器為MCU1則協(xié)議轉換器為下載板，即數據的封裝在下載板中完成;若加載器為MCU2則協(xié)議轉換器為MCU2，即數據的封裝在MCU1中完成，此時(shí)下載板只起轉發(fā)的作用。

4)加載器接收遠程執行命令

一旦主機將所有的數據包發(fā)送到加載器，主機可以發(fā)送最后一個(gè)包以指示加載器開(kāi)始執行代碼。具體的軟件流程如圖6所示。

圖6協(xié)議轉換器重啟加載器的軟件流程圖

其中有2種不同的遠程運行方式：軟件復位(h，u，m，l=0x1)和跳轉至用戶(hù)代碼(h，u，m，l=0x0)。一般情況下，會(huì )選擇軟件復位，因為軟件復位可以重置所有外設。然而在串行接口永久接地和地址0x80014被清零的情況下，有必要采用一個(gè)跳轉直接到用戶(hù)代碼。如果采用軟件復位，則最后發(fā)送的數據包的幀結構如表2所示。

表2 軟件復位的幀結構

2.4 實(shí)驗結果

圖7是使用本設計方案升級SFP+雙MCU嵌入式系統的測試結果，測試結果顯示MCU2在更新之前的版本號為v101，升級之后的版本號為v102。這說(shuō)明本設計方案是可行可靠的。

圖7測試結果

3 結束語(yǔ)

如今，大多數光通信依舊使用傳統的基于固定波長(cháng)光模塊的光源，尤其是目前被廣泛使用的10 Gbit/s光模塊都使用的這種固定波長(cháng)激光器，這對光模塊的利用存在極大的局限性，而目前這種缺陷已經(jīng)漸漸地顯露出來(lái)。為了提高模塊的利用率、降低網(wǎng)絡(luò )建設的成本、減小管理的復雜性、提高網(wǎng)絡(luò )的靈活性，SFP+波長(cháng)可調諧的光模塊應運而生。此可調諧光模塊的實(shí)現是基于DBR可調諧半導體激光器實(shí)現的。它可以在整個(gè)C波段，100個(gè)通道上實(shí)現波長(cháng)切換，從而提高了光網(wǎng)絡(luò )的靈活性同時(shí)也降低了網(wǎng)絡(luò )組建的成本、降低了光模塊管理的復雜性。由于SFP+波長(cháng)可調諧光模塊功能的復雜性以及PCBA本身面積的局限性，出現了雙MCU的系統，這樣對于多MCU系統如何實(shí)現系統的升級更新是一個(gè)急需解決的問(wèn)題。本文以AN806 I2C Download Protocol為基礎，實(shí)現了SFP+波長(cháng)可調諧光模塊雙MCU嵌入式系統的升級。