嵌入式支付系统模拟器 嵌入式 模拟器

摘 要： 目前，嵌入式支付应用开发受到硬件开发板不足、烧片时间长、调试不方便等因素影响，面临着应用开发周期长的问题。为了解决以上问题，研究了某个嵌入式支付系统，并在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.