摘要：目前嵌入式支付应用的开发受到硬件开发板不足、刻录时间长、调试不方便等因素的影响，面临应用开发周期长的问题。为了解决上述问题，研究了嵌入式支付系统，并在Windows环境下开发了与嵌入式支付系统相对应的嵌入式支付系统模拟器。基于软件模拟硬件功能的基本思想，开发的嵌入式支付模拟器通过现有的Windows API模拟嵌入式支付系统的基本系统。在保持外部接口不变和模拟功能的原则下模拟驱动程序；拓展资源工具，实现中间层移植；通过配置文件，解决了模拟器适用于不同型号的问题，实现了人机交互界面的输入输出。通过动态链接库隔离、宏隔离和区域隔离，解决了Windows相关API的隔离问题。
0简介
随着生活水平的提高和社会的发展，人们对电子产品的需求越来越大，这极大地推动了嵌入式系统行业的快速发展。无论是银行用来取钱的ATM(Automated Tellermachine)，还是用来通讯的手机，甚至是孩子日常玩的智能玩具中的小芯片，嵌入式技术都是不可或缺的。可以说，嵌入式产品已经遍布人们的生活[1]。嵌入式系统产品种类繁多，不仅广泛应用于各行各业，而且对人们的生活和社会发展产生了重大影响。随着消费者对嵌入式产品需求的扩大，要求开发者开发更高性能的软硬件系统，这也将使嵌入式系统的开发和学习变得越来越困难。在嵌入式开发过程中，我们经常会遇到一些问题[2-4]，比如软硬件协同开发，嵌入式产品硬件资源昂贵，软硬件知识贫乏，开发时间长[5]。
为了解决上述问题，本文研究开发了一个Windows环境下的嵌入式支付系统模拟器，模拟嵌入式支付系统的部分功能，在模拟器上实现部分应用程序的开发和调试，尽可能少修改或不修改就能在嵌入式支付真机上正常运行。
1嵌入式支付系统模拟器的体系结构
1.1系统架构
系统的架构如图1所示。可以看出，该系统由实机辅助工具、人机交互和模拟器处理三部分组成。
(1)实机辅助工具模块
实机辅助工具是指辅助工具的集合，其目的是加快嵌入式支付应用的发展。目前系统有一个资源工具，是MFC开发的WIN32应用，可以生成嵌入式支付应用需要的菜单数据。
(2)人机交互模块
主控制模块控制模拟环境。该模块包括人机交互界面和人机交互处理。
人机交互界面：模拟嵌入式真实支付机的界面，将模拟器处理模块处理的结果展示给用户。
人机交互处理：模拟嵌入式支付系统的按键输入和LCD输出功能。
(3)模拟器处理模块
模拟器处理模块实现了嵌入式支付系统的模拟，是整个模拟器的核心部分。该模块可分为三层，即中间层、系统层和配置层。
1.2系统操作流程
系统的运行过程如下：(1)系统启动主控线程，通过配置信息对象读取配置文件的内容；(2)主控线程根据窗口配置内容绘制人机交互界面，然后根据模拟器的相关信息设置模拟器环境，加载待运行的应用DLL(3)启动模拟器线程运行应用程序；(4)应用运行：用户通过人机交互界面输入数据并传输给模拟器线程，模拟器接收用户的输入并进行处理；(5)用户结束应用，系统结束模拟器线程；(6)系统结束主线程。
基于嵌入式支付系统模拟器的实现
配置层包括配置信息和配置信息对象。配置信息是一个数据文件，其数据框由模拟器的可配置信息组成，具体内容由用户填写。配置信息对象是一个为用户操作配置信息提供统一接口的类。
模拟器使用配置信息实现两个功能：可选模型和应用程序的动态加载。由于嵌入式支付系统适用于多种模型，对于不同的模型，它们的区别只是人机界面不同、内存大小不同、Flash大小不同、底层驱动不一致，因此模拟器系统使用配置文件动态绘制模拟器人机界面、动态申请模拟器内存大小、动态设置模拟器Flash大小、动态加载模拟器驱动。因此，模拟器系统可以使用配置信息来实现可选模型。配置文件还可以用于动态加载同一模型的不同应用程序。
2.2基本系统模拟——“内存池”模拟内存管理
内存池技术提供了一种内存分配方法，它向系统申请一个连续地址的大内存块，然后根据自己的需要管理这个内存，如果没有足够的内存块，就继续申请新的内存。这种方法的优点是可以减少内存碎片以提高性能。
在Windows上模拟嵌入式支付系统内存管理的思路与内存池技术的思路非常相似：应用到Windows系统中，获取与真实记忆棒大小相同的内存，并利用这个内存来模拟嵌入式支付系统的内存管理机制。内存池技术有两个区别：(1)如果内存块不足，抛出异常而不是继续应用；(2)模拟的目的不是减少内存碎片，而是尽可能模拟嵌入式支付系统的内存分配。
2.3驱动程序集模拟
2.3.1点阵映射模拟液晶驱动器
液晶显示器
示器）作为输出设备，用户将要显示的信息传送到显示缓冲区中，然后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）模拟器系统中采用直接读取文字的skdss文件来模拟文字的点阵信息的查询操作。
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] ssddg．ARM全系统模拟器中I2C模块的设计与实现[D]．成都：电子科技大学，2012.
[2] Zhang Xiuping， lyxmt 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] yldws．ARM嵌入式Linuz系统的研究与实现[D]．北京：北京邮电大学，2009.
[4] wydxt．嵌入式系统全系统模拟器框架设计与实现[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] axdbl．NAND Flash在嵌入式系统中的仿真与应用[D]．成都：电子科技大学，2011.