SFP+波長可調(diào)諧光模塊雙MCU嵌入式系統(tǒng)實現(xiàn)方案

本文基于ADuC7023a的硬件平臺和Keil4的軟件平臺，設(shè)計了一種SFP+雙MCU光收發(fā)模塊嵌入式系統(tǒng)升級的方案，并具體實現(xiàn)了SFP+波長可調(diào)諧光模塊雙MCU系統(tǒng)的更新。這對雙MCU的光模塊的升級具有一定的實用價值，并對今后出現(xiàn)的多MCU嵌入式系統(tǒng)的升級具有一定的參考意義。

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

1 雙MCU的嵌入式系統(tǒng)升級的整體設(shè)計

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

圖1 升級系統(tǒng)的整體架構(gòu)

1)通信協(xié)議上位機：主要通過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作為光模塊的主機，MCU2作為從機。當(dāng)給MCU2下載程序時，MCU1將接收到的數(shù)據(jù)封裝為滿足AN806_I2C Download Protocol for ADulC70xxBCPZxxI Models下載協(xié)議的幀結(jié)構(gòu)，并按照此協(xié)議的要求更新MCU2；否則，MCU1執(zhí)行自身的程序，控制整個模塊的正常運行。

2 雙MCU嵌入式系統(tǒng)升級的實現(xiàn)

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

2.1 串口數(shù)據(jù)收集實現(xiàn)

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

2.2 數(shù)據(jù)封裝的實現(xiàn)

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

1)Hex文件的幀結(jié)構(gòu)如圖2所示。

圖2 Hex文件的幀結(jié)構(gòu)

(1)起始符：固定為“：”用于記錄一幀數(shù)據(jù)的開始。

(2)數(shù)據(jù)字節(jié)數(shù)：后面的2個字符表明記錄的長度。一般情況為0x10，表明這一幀中傳送的有效數(shù)據(jù)位16 byte。

(3)地址位：4個字符表明調(diào)入的起始地址。

(4)數(shù)據(jù)類型：2個字符表明記錄的類型。以下為具體的字符對應(yīng)的不同的數(shù)據(jù)類型：

0：數(shù)據(jù)記錄。

l：記錄文件結(jié)束。

2：擴展地址記錄。

3：開始段地址記錄。

4：擴展線性地址記錄。

5：開始線性地址記錄。

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

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

2)下載協(xié)議規(guī)定的數(shù)據(jù)幀結(jié)構(gòu)如圖3所示。

圖3發(fā)送數(shù)據(jù)的幀結(jié)構(gòu)

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

(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)：該地址字段包含一個32位地址h，u，m，l，其中h中包含最高有效位(MSB)，l中包含最低有效位(LSB)。

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

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

3)幀結(jié)構(gòu)封裝的實現(xiàn)

協(xié)議轉(zhuǎn)換模塊將收到的每2個ASCII碼轉(zhuǎn)化為1個對應(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ù)的個數(shù)加5(其中主要加入了CMD Byte以及4 byte的地址)；Datal則是命令Byte可根據(jù)協(xié)議要求寫入適當(dāng)?shù)拿?，在更新系統(tǒng)時應(yīng)使用寫命令W(0x57)；Data2一Data5為Hex文件中指定的地址；Data x對應(yīng)Hex文件中的數(shù)據(jù)部分；Checksum則為0x00減去從Bytel～Byte x 的所有數(shù)據(jù)的和。從而實現(xiàn)對數(shù)據(jù)的封裝。

2.3 模塊更新的實現(xiàn)

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

圖4模塊更新流程

1)運行微轉(zhuǎn)換器加載器

為了防止I2C意外下載，I2C下載模式進(jìn)人前提是在復(fù)位器件串行下載保持低電平、同時Flash/EE存儲器Oxl4地址單元的內(nèi)容為0xFFFFFFFF。因此，用戶代碼必須有一個內(nèi)置機制用來擦除第0頁(Flash地址0x0到0x200)和復(fù)位器件。該機制允許進(jìn)入下載模式對器件重新編譯。

在理想情況下，為了能夠在數(shù)據(jù)重編程時出現(xiàn)掉電故障或出現(xiàn)其他錯誤時重新進(jìn)入下載模式，F(xiàn)lash地址單元Oxl4應(yīng)該最后編程。

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

2)啟動下載協(xié)議

一旦加載器進(jìn)入下載模式，加載器從機器件地址為0x04，因此，每次向加載器發(fā)送數(shù)據(jù)，主機必須以字節(jié)0x04(I2c寫地址)開始，每次從加載器讀取命令應(yīng)答請求以字節(jié)0x05(I2C讀地址)開始。加載器的第一個數(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ù)傳完之后再寫入。由于程序的起始點在第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中完成，此時下載板只起轉(zhuǎn)發(fā)的作用。

4)加載器接收遠(yuǎn)程執(zhí)行命令

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

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

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

表2 軟件復(fù)位的幀結(jié)構(gòu)

2.4 實驗結(jié)果

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

圖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)運而生。此可調(diào)諧光模塊的實現(xiàn)是基于DBR可調(diào)諧半導(dǎo)體激光器實現(xiàn)的。它可以在整個C波段，100個通道上實現(xiàn)波長切換，從而提高了光網(wǎng)絡(luò)的靈活性同時也降低了網(wǎng)絡(luò)組建的成本、降低了光模塊管理的復(fù)雜性。由于SFP+波長可調(diào)諧光模塊功能的復(fù)雜性以及PCBA本身面積的局限性，出現(xiàn)了雙MCU的系統(tǒng)，這樣對于多MCU系統(tǒng)如何實現(xiàn)系統(tǒng)的升級更新是一個急需解決的問題。本文以AN806 I2C Download Protocol為基礎(chǔ)，實現(xiàn)了SFP+波長可調(diào)諧光模塊雙MCU嵌入式系統(tǒng)的升級。