摘  要： 目前，嵌入式支付應用開發受到硬件開發板不足、燒片時間長、調試不方便等因素影響，面臨著應用開發周期長的問題。為了解決以上問題，研究了某個嵌入式支付系統，并在Windows環境下開發了該嵌入式支付系統對應的嵌入式支付系統模擬器。所開發的嵌入式支付模擬器基于軟件模擬硬件功能的基本思想，通過Windows現有API對嵌入式支付系統的基礎系統進行模擬；在保持對外接口不變、模擬函數功能的原則下，對驅動程序進行模擬；擴展資源工具，實現中間層的移植；通過配置文件，解決了模擬器適用于不同機型的問題，并且實現了人機交互界面的輸入和輸出；通過動態鏈接庫（Dynamic Link Library，DLL）隔離、宏隔離以及區域隔離，解決Windows相關API隔離。

　　關鍵詞： 嵌入式；模擬器；系統模擬；驅動模擬

0 引言

　　隨著生活水平的提高和社會的發展，人們對電子產品的需求也越來越大，這大大促進了嵌入式系統產業迅速發展壯大。無論是銀行取錢的ATM（Automated Tellermachine，自動取款機），還是通信使用的手機，甚至是日常小朋友玩的智能玩具中的一塊小芯片都離不開嵌入式技術，可以說嵌入式產品已經遍及人們生活的各個方面[1]。嵌入式系統產品各種各樣，不僅在各行各業得到了廣泛的應用，并且對人們的生活和社會的發展產生了重大的影響。隨著消費者對嵌入式產品使用需求的擴大，需要開發者開發出更高性能的軟硬件系統，同時也將導致嵌入式系統的開發學習難度越來越大。嵌入式開發過程中經常會碰到軟硬件協同開發、嵌入式產品硬件資源非常昂貴、涉及軟硬件知識以及開發時間長[5]等問題[2-4]。

　　為了解決以上問題，本文研究和開發了一個在Windows環境下的嵌入式支付系統模擬器，模擬嵌入式支付系統的部分功能，實現在模擬器上進行部分應用程序的開發和調試，并且在應用程序盡可能少地修改甚至不修改的情況下，能夠在嵌入式支付真機上正常地運行起來。

1 嵌入式支付系統模擬器的體系結構

　　1.1 系統體系結構

　　系統的體系結構如圖1所示，可以看出系統包括3個部分：真機輔助工具、人機交互以及模擬器處理。

　　（1）真機輔助工具模塊

　　真機輔助工具是指一些輔助工具的集合，這些工具的目的是加快嵌入式支付應用程序的開發。目前系統擁有資源工具，該工具是一個由MFC開發的WIN32應用程序，它能夠產生嵌入式支付應用程序所需的菜單數據。

　　（2）人機交互模塊

　　主控模塊控制模擬環境。該模塊包含人機交互界面和人機交互處理。

　　人機交互界面：模擬實現嵌入式支付真機的界面，并將模擬器處理模塊處理的結果展現給用戶觀看。

　　人機交互處理：模擬實現嵌入式支付系統的按鍵輸入與LCD輸出功能。

　　（3）模擬器處理模塊

　　模擬器處理模塊實現嵌入式支付系統的模擬，是整個模擬器的核心部分。該模塊又可以分為3層，分別是中間層、系統層以及配置層。

　　1.2 系統運行流程

　　系統的運行流程為：（1）系統啟動主控線程，通過配置信息對象讀取配置文件內容；（2）主控線程根據窗口配置內容繪制人機交互界面，接著根據模擬器相關信息對模擬器環境進行設置并對將要運行的應用DLL加載進來；（3）啟動模擬器線程，將應用跑起來；（4）應用運行，用戶通過人機交互界面輸入數據并將數據傳遞到模擬器線程，模擬器接收用戶的輸入并處理；（5）用戶結束應用，系統結束模擬器線程；（6）系統結束主控線程。

2 嵌入式支付系統模擬器的實現

　　2.1 配置層的實現

　　配置層包括配置信息以及配置信息對象。配置信息是一個數據文件，它的數據框架由模擬器可配置信息組成，具體內容由用戶填充。配置信息對象是一個類，它提供統一的接口給用戶操作配置信息。

　　模擬器系統采用配置信息可以實現兩個功能：機型的可選性和應用的動態加載。因為嵌入式支付系統適用于多種機型，對于不同的機型，它們的差異只是人機交互界面不同、內存大小不同、Flash大小不同以及底層驅動的不一致，所以模擬器系統采用配置文件來動態繪制模擬器人機交互界面、動態申請模擬器內存大小、動態設置模擬器Flash大小以及動態加載模擬器驅動。因此模擬器系統采用配置信息可以實現機型的可選性。對于同一機型的不同應用程序也同樣可以采用配置文件實現動態加載。

　　2.2 基礎系統模擬——“內存池”模擬內存管理

　　內存池技術提供一種內存分配方式，它向系統申請一大塊地址連續的內存，然后根據自己的需求管理這塊內存，如果出現內存塊已經不夠的情況時，繼續申請新的內存。這種做法的優點是能夠降低內存碎片來提高性能。

　　在Windows上模擬嵌入式支付系統的內存管理，理念上與內存池技術非常類似：向Windows系統申請真機內存條同等大小的內存，使用該塊內存模擬嵌入式支付系統的內存管理機制。其與內存池技術有以下兩個不同的地方：（1）如果出現內存塊不足，拋出異常，而不是繼續申請；（2）模擬的目的不是為了減低內存碎片，而是盡可能模擬嵌入式支付系統內存的分配方式。

　　2.3 驅動集模擬

　　2.3.1點陣映射模擬LCD驅動

　　LCD（Liquid Crystal Display，液晶顯示器）作為輸出設備，用戶將要顯示的信息傳送到顯示緩沖區中，然后LCD通過“點燈”的方式將其顯示出來。在PC上也有LCD，是否可以通過PC上的LCD來模擬嵌入式支付真機的LCD？答案是可以的，只需要在PC上模擬嵌入式支付系統的LCD驅動即可。在PC上模擬LCD驅動就是將需要顯示的點陣數據繪制到PC的LCD上，目前WIN32將一個點陣數據顯示到LCD上可以有以下兩種方式：（1）采用DOS下漢字的顯示原理，利用SetPixel函數將點陣數據一個點一個點地畫，這種方式的好處是彩屏的繪制，但是繪制速度慢；（2）直接利用緩沖區的數據創建BMP對象，這種方式可以快速地刷屏，但是只能實現單色繪制[6]。本系統借鑒這兩種方法，采用雙緩沖機制，利用SetPixel函數將點陣數據繪制到一個中間DC（Device Context，設備描述表）中，在一定的條件下將該塊DC繪制到屏幕上。這樣既可以實現彩屏的繪制，繪制速度也可以控制。

　　2.3.2文件模擬Flash驅動

　　Flash是一種存儲芯片，它是嵌入式支付真機重要組成部分。它不僅可以保存用戶的應用信息，也可以保持系統的配置信息[7]。

　　Flash其實是一大塊連續的地址區域，該區域里面的數據是可讀寫、可永久保存的。因為Flash的空間比較大，如果直接用內存去模擬Flash，可能會導致一些配置比較低的PC內存不夠。模擬器系統根據Flash可永久保存特性，采用文件對Flash進行模擬。把文件看成是一大塊連續的地址空間，打開文件后可以獲取該地址空間的首地址，加上偏移地址就可以獲得相應的地址空間。這樣Flash驅動的模擬就變得簡單了，通過WIN32對文件的打開、地址偏移、讀取、寫入、關閉函數來實現Flash驅動的初始化、讀取、寫入和擦除等操作。

　　2.4支付業務支撐模塊的設計與實現

　　支付業務支撐模塊是與支付應用直接相關的模塊，該模塊為支付應用提供銀行卡卡號信息和部分加密算法。支付具體的流程由于不同銀行的支付協議不一致導致各不相同，因此具體的支付處理由應用層程序根據不同的需求實現不同應用，而嵌入式支付系統只提供用戶刷卡的銀行卡信息以及提供常見的幾個加密算法。

　　嵌入式支付系統由于嵌入式資源的限制，并不能包括所有的加密算法。其加解密算法包括des和3des的加解密。該部分內容可以直接移植到模擬器中，不需要進行修改。

　　2.5 中間層的移植

　　在嵌入式支付系統中封裝一個middleware（中間層），該層的內容是對底層信息的封裝，供給應用程序直接使用。目前模擬器系統middleware有GDI子系統、GUI子系統和DB子系統。GDI（Graphics Device Interface，圖形設備接口）對底層LCD驅動進行封裝，提供接口給GUI模塊和應用程序調用。嵌入式支付系統中GDI模塊包括動態繪制區、繪圖、貼圖、文字、光標、滾動條和開機啟動提示。在LCD驅動已經完成模擬的前提下，GDI調用LCD驅動接口完成繪制操作。在模擬器系統中，大部分GDI操作可以直接從嵌入式支付系統中移植，而以下兩部分內容則需要模擬：（1）對char進行位操作實現相應bit位的讀寫、取反實現GDI中bit操作；（2）模擬器系統中采用直接讀取文字的bin文件來模擬文字的點陣信息的查詢操作。

　　2.6 WIN32函數隔離的設計與實現

　　嵌入式支付系統參考WIN32中的UI設計，設計了適合其終端應用的GUI子系統。這樣設計既方便不同產品、項目界面風格的統一，也方便應用對操作界面的開發。但它給嵌入式支付系統帶來便利的同時也給模擬器系統帶來一個問題：嵌入式支付系統GUI函數與WIN32中GUI函數存在大量重名，而且兩者的函數是不可替代的。例如在WIN32的GUI模塊中擁有CreateWindow函數，在嵌入式支付系統中的GUI模塊中也有CreateWindow函數，并且兩者的參數與實現功能不一致。又因為整個嵌入式支付系統采用C語言與匯編語言共同開發，所以模擬器系統需要解決一個大問題：C環境下如何使得重名函數共存，并且使其調用不發生混亂，即在主控系統中調用的是WIN32中的GUI函數，而在模擬器應用程序中調用模擬器GUI函數。如圖2所示，本系統提出利用DLL隔離、宏隔離以及區域隔離3種方式共同處理該問題。

3 實驗結果與分析

　　3.1 實驗環境

　　硬件環境：CPU為Pentium4及以上；內存為1 024 MB及以上；可用硬盤空間為1 024 MB及以上。

　　軟件環境：操作系統為Microsoft Windows 7；開發工具為VS2010；開發語言為C和C++混合編程。

　　3.2 實驗結果分析

　　移植計算器應用（如圖3所示）、菜單應用、萬年歷應用程序到模擬器上進行測試，移植過程沒有進行源代碼的修改，只是將其轉換為DLL，運行結果與嵌入式支付真機上一致。

　　從測試結果可得出以下結論：

　　（1）模擬器的可靠性：實際運行在嵌入式支付真機上的4個應用程序源碼保持不變，只是將其轉換為DLL，通過X86VC編譯器編譯后可以運行在模擬器上，并且其結果與真機上的結果保持一致。通過以上4個應用程序的測試，說明該模擬器是可靠的。

　　（2）模擬器應用開發的優越性：將應用程序移植到模擬器上之后，只需將該DLL配置到應用啟動項中就可以直接運行，期間遇到問題可以直接使用VS2010的調試工具進行調試。因此在模擬器上開發應用程序不需要真機，不需要燒片時間，可以通過VS2010提供的調試工具進行調試，大大加快了應用的開發測試速度。

4 結論

　　本文研究和開發了一個在Windows環境下的嵌入式支付系統模擬器，該模擬器基于功能模擬的基本思想，通過Windows現有API模擬基礎系統，提出了保持對外接口不變、模擬函數功能的原則，實現底層驅動的模擬。通過配置文件，解決了模擬器適用于不同機型的問題。本文還提出同時利用DLL隔離、宏隔離以及區域隔離3種方式，解決了C環境下重名函數共存，并且調用不混亂的問題。

　　參考文獻

　　[1] 李婷．ARM全系統模擬器中I2C模塊的設計與實現[D]．成都：電子科技大學，2012.

　　[2] Zhang Xiuping， Yang Guowu， Zheng Desheng. Component-based model for simulating the MMU coprocessor[C]. 2010 2nd International Conference on Information Engineering and Computer Science（ICIECS），2010，42（8）：1-4.

　　[3] 鄧漫齡．ARM嵌入式Linuz系統的研究與實現[D]．北京：北京郵電大學，2009.

　　[4] 柯化成．嵌入式系統全系統模擬器框架設計與實現[D]．杭州：浙江大學，2006.

　　[5] Wang Ping. Research on the embedded system[J]. Teaching Education Technology and Training，2008（1）：21-22.

　　[6] GRANHAM I. 面對對象方法原理與實踐（英文版第3版）[M].北京：機械工業出版社，2003.

　　[7] 王洋．NAND Flash在嵌入式系統中的仿真與應用[D]．成都：電子科技大學，2011.