手机、智能卡和利用智能卡控制手机的外围设备的方法 【技术领域】
本发明涉及移动通信终端，尤其是一种手机、智能卡和利用智能卡控制手机的外围设备的方法。
背景技术
在目前的手机中广泛使用智能卡并将其用于控制手机的外围设备，例如下一代大容量SIM(NGMS)卡。其特点包括：手机端拥有独立的CPU及外部设备；智能卡端也有拥有独立的CPU；一部分应用程序在智能卡端，手机端通过Web的方式访问智能卡端的服务器并执行；运行在智能卡端的一些应用程序需要访问并控制手机端的外部设备。图1是现有技术的手机和智能卡的一种示例的配置示意图，其中的智能卡是UICC(通用集成芯片)卡，其中设置有网络服务器(web server)、应用程序、Java虚拟机以及通讯协议；其中的手机端设置有应用程序、浏览器核和通讯协议(OS/FS，7816，USB)，并采用TPAK平台。
在目前比较普遍的智能卡解决方案中，一般的特点是将智能卡作为网络服务器(Web Server)，同时将一些应用程序也在放在智能卡端；在系统运行时，手机端通过Web的方式访问智能卡上的服务器，并运行一些对应的应用程序。这样做的好处是可以把某些运算交给智能卡的CPU进行，从而提高整体系统的性能。但这种情况下，想把某些应用，如音频(Audio)相关应用放到智能卡上的话，需要解决应用程序跟底层设备驱动的关系。现有方法一般是通过手机端的应用程序访问手机的底层驱动，这样做的缺点主要有两方面：一是整个控制流程较长，响应时间过长；二是还需要在手机端运行对应的应用程序，不利于系统性能的提升。例如，图2示出采用NGMS卡控制手机的外围设备的控制流程。NGMS卡上的应用程序在控制手机的外围设备时，首先由卡中的应用程序确定控制操作，将操作通过TCP/IP传送给手机中对应的应用程序；再由手机中的应用程序分析接收到的操作，然后调用对应的底层驱动接口，以控制外围设备执行相应的操作。图2中横跨手机和智能卡的弯曲曲线表示控制流程的路径，可以看出在控制流程中需要经过手机端的应用程序。
图3描述现有技术中采用智能卡来打开手机的音频设备(Audio设备/dev/dsp)的控制流程。该控制流程包括：
(1)NGMS应用程序确定当前操作为打开操作(open)，目标为“/dev/dsp”；(2)将此操作通过TCP/IP传送给手机(Handset)中对应的应用程序；(3)Handset应用程序分析接收到的操作，然后调用对应的底层驱动接口：打开接口，即Open(“dev/dsp”)；(4)Audio驱动执行Open()操作，并返回操作是否成功的结果；(5)Handset应用程序将接收到的执行结果发送给NGMS应用程序；(6)NGMS应用程序接收到执行结果。到此，打开(Open)操作结束，方可以继续运行。
此控制流程的缺点是：需要在手机端重复实现对应的应用程序，再由此应用程序去调用底层设备驱动；对不同的外围设备而言，都需要定义其NGMS及Handset端的应用程序间的接口；智能卡及手机二者之间联系太过紧密，一旦其中之一有所变化，则需要将对应的部分全部改变；其控制流程相对较长，系统响应时间不理想。
【发明内容】
为解决现有技术中存在的上述问题，本发明提出了一种手机、智能卡和通过智能卡直接控制手机的外围设备地通用方法。根据本发明的实施例，可以简化控制流程，提高系统的响应时间，并有利于系统性能的提高
本发明提供一种可插接智能卡的手机，其中，该智能卡存储有关于外围设备的应用程序并设置有用于与该手机进行通讯的第二通讯模块，该手机包括：
若干个外围设备；
卡接口，用于插接该智能卡；
第一通讯模块，用于与该智能卡的第二通讯模块进行通讯，以及提供统一的外围设备的底层驱动接口，以便该第一通讯模块提供的底层驱动接口由该第二通讯模块映射到该智能卡，并将映射的底层驱动接口提供给该智能卡的应用程序使用；其中，当该智能卡中的应用程序调用该第二通讯模块提供的外围设备的驱动接口时，该第一通讯模块接收由该第二通讯模块发送的接口调用，并将接收的接口调用映射到实际的外围设备的驱动接口，以便使该外围设备执行接口调用操作。
根据本发明的实施例，该外围设备将执行该接口调用操作的执行结果返回给该第一通讯模块；该第一通讯模块将该执行结果发送给该第二通讯模块，以便该第二通讯模块将该执行结果返回给该智能卡中的应用程序。
该手机可以采用Linux平台。
根据本发明的实施例，该第一通讯模块提供的统一的外围设备的底层驱动接口包括用于外围设备的打开接口、写接口、读接口、I/O控制接口和关闭接口。
根据本发明的实施例，在该第一通讯模块中，所述的打开接口、写接口、读接口、I/O控制接口和关闭接口按照外围设备的类型调用其对应的驱动接口。
根据本发明的实施例，在外围设备请求将数据发送给应用程序的情况下，该第一通讯模块处理相应的中断请求，缓存来自外部设备的数据，并将数据发送给该智能卡。
本发明提供一种用于手机的智能卡，其中，该手机包括若干个外围设备、用于插接智能卡的卡接口以及用于与该智能卡进行通讯的第一通讯模块，该第一通讯模块提供统一的外围设备的底层驱动接口；该智能卡存储有关于外围设备的应用程序，并包括：
第二通讯模块，用于与该手机进行通讯，以及将该第一通讯模块提供的底层驱动接口映射到该智能卡，并将映射的底层驱动接口提供给该智能卡中的应用程序使用；其中，当由该智能卡中的应用程序调用该第二通讯模块提供的外围设备的驱动接口时，该第二通讯模块将接口调用发送到该第一通讯模块，以便该第一通讯模块将接收的接口调用映射到实际的外围设备的驱动接口以及使该外围设备执行接口调用操作。
本发明又提供一种利用智能卡控制手机的外围设备的方法，该智能卡插入到手机的卡接口，其中，在该手机中的设备驱动与上层应用程序之间设置第一通讯模块，该第一通讯模块用于与该智能卡进行通讯，以及提供统一的外围设备的底层驱动接口；在该智能卡中的应用程序的下层设置第二通讯模块，该第二通讯模块用于与该手机进行通讯，以及将第一通讯模块提供的底层驱动接口映射到智能卡，并将映射的底层驱动接口提供给智能卡的上层应用程序使用；
该方法包括：
由智能卡中的上层应用程序调用该第二通讯模块提供的外围设备的驱动接口；由该第二通讯模块将接口调用发送到该第一通讯模块；该第一通讯模块将接收的接口调用映射到实际的外围设备的驱动接口；以及该外围设备执行接口调用操作。
【附图说明】
图1是现有技术的手机和智能卡的一种示例的配置示意图；
图2示出现有技术中采用NGMS卡控制手机的外围设备的控制流程；
图3是现有技术中采用智能卡来打开手机的音频设备的控制流程图；
图4是根据本发明实施例的手机和智能卡的结构方框图；
图5示出根据本发明实施例的采用NGMS卡控制手机的外围设备的控制流程；
图6是根据本发明实施例的采用智能卡来打开手机的音频设备的控制流程图；以及
图7是根据本发明实施例的采用智能卡控制手机的音频模块的流程图。
【具体实施方式】
图4是根据本发明实施例的手机和智能卡的结构方框图。其中，智能卡可以插入到手机中的卡接口。手机的外围设备例如包括音频模块、视频模块、摄像头等。
图5示出根据本发明实施例的采用NGMS卡控制手机的外围设备的控制流程。在该实施例和以下其它实施例中，是以Linux平台的手机及智能卡系统为例，但本发明不仅限于采用Linux平台的手机，同时可以应用到采用其他平台的手机。如图5所示，左侧的手机设置有应用程序、驱动套接模块、TCP/IP协议、设备驱动以及外围设备；右侧的智能卡设置有应用程序、驱动套接模块和TCP/IP协议。图5中横跨手机和智能卡的弯曲曲线表示控制流程的路径。可以看出在控制流程中不需要经过手机端的应用程序。
如图5所示，在手机端，在设备驱动及上层应用程序之间增加一个驱动套接模块(也称为DriverWrap模块，或简称为DriverWrap)，其主要功能是作为通讯模块进行通讯，以及通过调用底层设备驱动程序为上层提供统一的调用接口，起到了一个套接的作用。在手机端的驱动套接模块的主要功能如下：
(1)提供统一的底层驱动接口。以Linux系统为例，Linux底层设备驱动一般都提供open()，write()，read()，ioctl()，close()这几个基本功能，分别用于外围设备的打开、写、读、输入输出控制以及关闭；其余一些特殊设备的特殊功能，如mmap()(将文件映射到内存)，release()(释放资源)等，都可以通过ioctl()来实现，故在Linux系统中，DriverWrap层提供的统一驱动接口即可定义为open()，write()，read()，ioctl()，close()。
(2)接口的实现。在DriverWrap中，统一的接口open()，write()，read()，ioctl()，close()将会按照具体的设备调用其对应的驱动接口，同时返回对应的返回值。
(3)中断处理。针对底层设备有数据需要主动发送给上层应用程序的情况，DriverWrap需要处理相应的中断请求，缓存取自设备的数据，然后主动发送给智能卡端。
(4)将异步操作转为同步操作。在DriverWrap中人为地将异步操作转为同步操作，以减少同智能卡端应用程序的交互复杂性。
(5)通讯，即用于与智能卡进行通讯。同智能卡端的DriverWrap模块基于TCP/IP的通讯功能。
在智能卡端，在应用程序之下也增加一个DriverWrop模块，其主要功能如下：
(1)将手机端DriverWrap的统一接口映射到智能卡端。
(2)将映射过来的统一接口提供给智能卡上层应用程序使用。
(3)通讯，即用于与手机进行通讯。同手机端的DriverWrap模块基于TCP/IP的通讯功能。
在手机端和智能卡端的驱动套接模块作为通讯模块，可以被实现为硬件、软件或其组合。
图6是根据本发明实施例的采用智能卡来打开手机的音频设备的控制流程图，其中以打开Audio设备/dev/dsp为例说明本发明实施例的方法的控制流程。该控制流程的说明如下：
(1)NGMS应用程序调用DriverWrap提供的接口：Open(“/dev/dsp”)；
(2)NGMS端的DriverWrap将接口调用Open(“/dev/dsp”)发送到Handset端的DriverWrap；
(3)Handset端的DriverWrap将接收到的Open()映射到实际Audio驱动的Open()接口；
(4)Audio驱动执行Open()操作并返回执行结果；
(5)Handset端的DriverWrap将执行结果发送给NGMS端，并由NGMS端的DriverWrap返回给NGMS的应用程序。
该控制流程的优点如下：
(1)DriverWrap封装并提供统一的接口，由此减少Handset与NGMS端的关联；
(2)DriverWrap的统一接口将使其通用性大大增加，对NGMS应用程序而言，已不再关心手机(Handset)端底层的实现，其只需要满足DriverWrap的接口即可.
(3)相对现有的实施方式，本发明实施例的控制流程较简单，从而可以提高系统响应的时间。
图7是根据本发明实施例的采用智能卡控制手机的音频模块的流程图，其中以播放音乐及调节音量为例，从整体上说明智能卡控制手机音频模块的一个示例流程。该控制流程说明如下：
(1)智能卡调用open()接口打开音频设备，如“/dev/dsp”；open()接口通过DriverWrap模块打开手机端实际的外围设备；
(2)智能卡通过write()接口将要播放的音乐数据传输给音频设备；write()接口通过DriverWrap模块将音乐数据传输给手机端实际的外围设备；
(3)在播放的过程中，智能卡调用ioctl()接口调节音量；ioctl()接口通过DriverWrap模块控制手机端实际外围设备的音量大小；
(4)播放完成后，智能卡调用close()接口关闭打开的设备；close()接口通过DriverWrap模块关闭手机端实际的外围设备。
在此流程中，每一步的具体流程都可参考图6示出的用于打开Audio设备/dev/dsp的实例。
对比现有技术及本发明的上述实施例，可以看出本发明的有益效果主要在以下两个方面：
(1)通用性及独立性。
-此方法与手机和智能卡两端的平台无关；
-统一的调用接口使Handset与NGMS可以相互独立。
通用性及独立性的好处在于：使用此方法的智能卡，如果要被某手机支持，该手机只需要按要求实现DriverWrap即可满足智能卡对手机外围设备的控制；而如果不采用这种方法，则手机端将需要参考智能卡端的详细设计才能满足这二者的交互。同时，采用DriverWrap以后，手机端的操作系统与智能卡端的操作系统不需要完全一样也可以达到控制的效果。从这一点上来看，本发明有利于智能卡的推广及应用。
(2)系统性能的改善。
根据本发明实施例的采用智能卡控制外围设备，其控制流程简化，提高系统的响应时间，有利于系统性能的提高。