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

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

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

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

圖1 升級系統的整體架構

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

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

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

2 雙MCU嵌入式系統升級的實現

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

2.1 串口數據收集實現

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

2.2 數據封裝的實現

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

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

圖2 Hex文件的幀結構

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

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

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

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

0：數據記錄。

l：記錄文件結束。

2：擴展地址記錄。

3：開始段地址記錄。

4：擴展線性地址記錄。

5：開始線性地址記錄。

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

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

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

圖3發送數據的幀結構

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

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

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

表1 命令功能

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

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

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

3)幀結構封裝的實現

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

2.3 模塊更新的實現

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

圖4模塊更新流程

1)運行微轉換器加載器

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

在理想情況下，為了能夠在數據重編程時出現掉電故障或出現其他錯誤時重新進入下載模式，Flash地址單元Oxl4應該最后編程。

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

2)啟動下載協議

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

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

15 byte=產品標示符

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

4 byte=保留

2 byte=換行和回車

3)加載器接收數據

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

圖5 協議轉換器發送數據的具體軟件流程圖

其中，若加載器為MCU1則協議轉換器為下載板，即數據的封裝在下載板中完成；若加載器為MCU2則協議轉換器為MCU2，即數據的封裝在MCU1中完成，此時下載板只起轉發的作用。

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

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

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

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

表2 軟件復位的幀結構

2.4 實驗結果

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

圖7測試結果

3 結束語

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