基于MAXQ3120微控制器的電表(EM)參考設計

MAXQ3120電表(EM)參考設計構建了一款多功能、多費率電表，它符合世界范圍的全部可用標準。參考設計構成了一款能夠適合各地要求和各種性能要求的電表原型。這篇文檔將指導軟件工程師，通過定制代碼實現一些特殊的需求。

目標讀者

本文檔假定讀者熟悉C語言、MAXQ20微控制器架構以及匯編語言。讀者也需熟知全電子式電表的基理。

工具

電表參考設計采用IAR Embedded Workbench工具進行編譯。為便于將軟件移植到其它開發環境中，除了一種例外情況外，整個軟件避免了與IAR相關的語言特性。這種例外情況位于匯編語言文件中，其中包括了一些對標準匯編偽指令集的特定IAR擴展。這些特定IAR擴展命令，不僅可告知連接器各不同段的分配情況，而且告知調試器有關某些機器資源的變化情況。在其它開發環境下構建工程，可將這些偽指令去除。

高層硬件描述

硬件的核心器件是MAXQ3120微控制器。MAXQ3120幾乎囊括了實現多功能、多費率電表所需要的所有功能，這些功能包括：雙通道、高精度A/D轉換器(ADC)，一個乘法累加器(MAC)，通信端口和一個顯示控制器。完成一個電表設計，僅需要少量的外部元件。

在參考設計中，提供兩個通信通道：一路紅外通道，包含一個可解碼38kHz載波頻率的接收模塊和一個直接由微控制器驅動的紅外LED，一路完全隔離的RS-485通道；用作非易失存儲器的128kb I2C EEPROM；一個可視LED和一路隔離光耦通道，用于指示電表脈沖；一個用于設置網絡地址的按鈕；和一個用于顯示的LCD。

這種硬件構成預示著以下一些應用信息。選擇一個外置I2C EEPROM，意味著系統中必須包含I2C軟件，而不提供硬件I2C主機。電表脈沖硬件意味著軟件必須能夠產生極為精確的脈沖定時。兩路通信端口表明，微控制器有限的資源要被兩路通道所共享。

軟件系統綜述

軟件系統必須同時跟蹤多個進程。首先也是最重要的一點，軟件系統必須監測ADC，計算用電量并報告其它額外信息，這些信息包括RMS電壓和電流、功率因數和峰值功率。這個基本進程非常關鍵，其它任何進程都不能干擾這個最重要的基礎任務。在持續監視用電量的同時，軟件還必須驅動顯示、監視兩路通信端口、監視按鈕以及電力線路上的電源失效事件，完成從外部EEPROM獲取信息的請求，并跟蹤費率時段的變化。

任務管理方式

初始一看，要完成以上多個實時任務，迫切需要某種實時操作系統(RTOS)來進行調度管理和資源分配。但進一步分析后，就會發現不用傳統RTOS的兩個充分理由。

首先，要求即時響應ADC中斷。當ADC有可用的采樣數據時，必須在48μs內提取該采樣數據。并且，當檢測到一個過零點時，電源周期處理程序為了在下一個電源周期之前完成執行操作，必須獨占CPU資源。(電源周期處理程序將占用CPU運算能力的25%到30%。) 盡管RTOS可以滿足這些要求，卻不能最有效地利用資源。

其次，用于保存任務上下文的空間非常有限。大多數RTOS都要給每個任務提供一個完整的虛擬處理器，以在其中執行操作，而這需要保存各個任務的上下文。由于僅有256個16位字RAM可供使用，少量任務就會耗盡存儲器空間。

所以，本參考設計選擇了一個簡單的任務輪。在這種配置方式下，任務會被按順序調用，而每個任務在鎖定事件發生時，都要釋放CPU的控制權。鎖定事件是指所有其它任務都必須等待的事件，它包括：從EEPROM中提取數據，等待一個電源周期或是等待通信通道上的字符。如果當前任務需要等待其它任務完成時才能結束自身任務，這時也會產生一個鎖定事件。在任何鎖定事件中，任務必須存儲它的當前狀態并返回任務輪。這種協作式多任務機制，使得一個處理能力相對低些的控制器就能夠勝任工作。

任務間的通信是通過一組公共數據結構來完成的，這些數據結構要根據一套嚴格的規則才允許被修改。這些數據結構中最重要的部分是消息板，當發生某個事件時，一個任務要設置消息板中的一組數據位以通知另一個任務。例如，假設接收到一個消息并將其正確譯碼，則消息譯碼器任務會告知另一個需要該消息的任務(比如寄存器管理器)已經收到了消息，并要求第二個任務必須執行某些操作。

缺省任務列表

以下是參考設計中采用的缺省任務列表：

DSP：對應每個電源周期，這個程序會計算電力線路的所有參數，并累加本電源周期的用電量。

串口驅動器：檢測兩路通信通道的狀態，并將第一個發出字符的通道置為“活動”通道。在消息檢查器任務確定消息完成或產生超時之前，通道將始終保持活動狀態。

消息檢查器：驗證輸入字符串符合協議規范，并在完整接收消息后通知消息譯碼器。

消息譯碼器：解釋接受到的消息并執行相應的請求操作。

異步事件管理器：執行那些不是按照時間表進行的事件任務，比如峰值檢測和電能累計。

時段表管理器：周期性檢查時鐘，并按照時段表調整費率寄存器的值。
顯示管理器：根據時間和其它事件刷新LCD顯示。

消息格式器：為消息譯碼器解釋的消息準備回復信息。

消息構建器：接收格式化后的消息并加上用于傳輸的消息頭和消息尾。

寄存器管理器：執行讀/寫EEPROM操作。

計時管理器：通告按固定時基啟動的任務。

負載曲線記錄器：被請求時，向EEPROM記入用電量，便于將來報告這些數據。

添加任務

如電表參考設計中所定義，任務是一段單線程代碼，它執行電表要求的某項功能，并快速(通常只有幾毫秒)返回調用函數。然而，大多數任務都需要比這更長的時間才能完成。比如，在任何合理的速率下發送一個消息都需要多個周期。因此，大多數任務都需要一個狀態變量，以便將其分解為數個子任務。

一旦任務編寫完成，你就可以在spintaskwheel.c文件的任務列表中加入該調用。注意，你可以將任務加在執行流程的任何位置，并根據你的需要多次頻繁調用它。你將發現，DSP任務調用非常頻繁，串口驅動器SerialPortDriver任務也被調用了幾次。因為要保持電能測量的完整性，DSP任務不允許被擱置數個周期，同時不允許SerialPortDriver任務錯過輸入字符。

最后，測試你的代碼。任務輪循環時，你的新任務將伴隨其它任務被調用。

全局變量

由于未使用真正意義上的多任務操作系統，也就意味著不會有編程人員所熟知的、真正意義上的消息傳遞、信號量或其它機制。通信是通過上文提到的消息板以及一組全局變量實現的，各個任務必須按照嚴格的規則來設置和讀取這些變量信息。這些全局變量列舉如下：

g_CommSystEMState: 這個變量包括一組通信通道控制位。具體來說，每個通道包括：一個active (活動)位，用于指明某個特定通道處于活動狀態(從而可丟棄到達另一個通道的字符)；一個TBE位，用于使閑置通道做好工作準備；以及一個data loss (數據丟失)位，當閑置通道收到字符而另一通道正忙于通信時，該位被置高。

g_TransmitByte; g_ReceiveByte: 分別保存著下一個要傳送的字節和最新接收到的字節。

g_CommBuffer: 一個50字節數組，包含剛接收到的消息或要發送的消息。注意系統僅有一個通信緩存。它不僅被兩個通信通道所共享，也被發送和接收通道所共享。

g_MeterAddress: 一個包含電表網絡地址的6字節數組。初始化時從EEPROM內讀取該信息，并存放在RAM中。

g_MessageFormatterData; g_DispFormatterData; g_ScheduleManagerData; g_AEMData; g_LCLRegData: 這些寄存器在寄存器管理器和各種任務間傳送數據。例如，一個需要發送的寄存器內容，會被寄存器管理器放入g_MessageFormatterData中。

g_AEMRegisterNeeded; g_DispFormatterRegRequest; g_RequestScheduleManager; g_LCLRegRequest: 這些寄存器里，包含了特定任務需要讀或寫的寄存器。注意，消息譯碼器沒有全局地址寄存器：寄存器管理器可以智能地從消息緩存中找出這個信息。

g_LCDMode: 包含顯示器的模式字節。見下面的顯示定制部分。

g_TariffInEffect: 包含當前有效的費率號碼。這個函數有自己的全局變量，以便每次累計電能時，無需通過多次EEPROM讀操作來確定將采樣值存在什么位置。