CN1858748B

CN1858748B - 一种实现在usb从设备端直接访问usb主设备端文件的方法

Info

Publication number: CN1858748B
Application number: CN2006100811312A
Authority: CN
Inventors: 张志�
Original assignee: HUAIJIN COMPUTER SCIENCE AND TECHNOLOGY Co Ltd SHANGHAI
Current assignee: HUAIJIN COMPUTER SCIENCE AND TECHNOLOGY Co Ltd SHANGHAI
Priority date: 2006-05-22
Filing date: 2006-05-22
Publication date: 2011-12-07
Anticipated expiration: 2026-05-22
Also published as: CN1858748A

Abstract

本发明涉及一种实现在USB从设备端直接访问USB主设备端文件的方法，包括以下步骤：在USB从设备端存储器中建立交换缓存区；USB从设备端上层软件把对USB主设备端存储器文件的访问“请求”写在自身存储器的一个“请求”缓存区里；USB主设备读取USB从设备端存储器中“请求”缓存区，并执行“请求”，进行文件复制、移动、删除等操作或把USB主设备端文件块与USB从设备端交换缓存区中缓存块交换；USB从设备端可直接读写访问自身存储器文件或交换缓存区。本发明有益效果：可在USB从设备端直接访问主设备端文件，不需要把几百兆的文件全部复制过来再使用，可访问远大于自身存储器剩余空间的大文件；允许手持播放器以低成本和省电的方式扩展可直接访问外接硬盘。

Description

一种实现在USB从设备端直接访问USB主设备端文件的方法

技术领域

本发明涉及一种数据传输方法，尤其涉及一种利用在USB从设备端的存储器中建立交换缓存区的方式来实现USB从设备对USB主设备直接访问的方法。

背景技术

随着集成电路技术的发展，手持设备体积越来越小巧，功能越来越强大，像智能手机、PMP、PSP等很多设备具有数字音乐，数字视频的多媒体播放功能，其存储介质通常为外插Flash存储卡或内置Flash内存颗粒，由于Flash价格昂贵，其容量都不大，通常在几百兆，然而一部一个小时的影片转成MP4格式就大约就需要400MB左右，其存储器容量相对不足成为矛盾。与之相对应的是硬盘容量虽然大，可以存上百部影片，但是其体积却偏大，不适合与手持设备做成一体，虽然有微硬盘，但容量也相应偏小。举例来说明，同一时期512MB的SD卡的单价大约为三四百人民币，而40GB的笔记本硬盘也只要四百多RMB，其单位容量价格比接近100倍。

解决这个矛盾的一种选择是允许外扩硬盘：平时使用手机、PMP、PSP的时候不用把硬盘那么大的东西拿在手里，其内置Flash卡只存储最常用的数据，如商务文件，音乐，拍照的照片，小游戏等，而将大量喜爱的影片和大文件放在随身包里的移动硬盘里，当有闲暇机会的时候想要欣赏某部电影的时候，再从硬盘中选择该文件导入手持设备的存储器即可。这种方式显然是可以接受的，因为我们经常可以看到有人把手机别在腰上，而随身包里还揣着一块移动硬盘，即使是某一天不带随身包出门，也不影响手机的使用。硬盘的重量在背包里却几乎感觉不到，相对拿在手上而言，不会觉得不方便。问题在于，如何外扩硬盘呢？如果在手持播放器上都使用USB主控制器芯片的话，的确是可以直接支持外接移动硬盘，但是这会增加每一个手机的硬件成本，而并不是每一个人都有在手机上看电影的需求，在成本竞争如此激烈的今天，很多手机厂商和PMP厂商都选择了仅支持USB从控制器，只能做“从设备”，不能直接外接硬盘。

虽然目前大量的智能手机，PMP，PSP可以播放视频，但都是“USB从设备”，不能直接外扩USB移动硬盘。通常只能使用PC来备份或更新其数据。于是市面上出现了针对那些有扩充容量需求的用户而推出的支持双向传输的数码伴侣的产品，这些数码伴侣其实就是普通移动硬盘的增强版，除了可以在PC间倒数据以外，还支持无PC环境下备份数码相机照片、拍照手机照片以及往PMP、PSP上拷贝影片等大文件的用途。这类双向数码伴侣又分为两种，一种是插卡方式的，使用的时候必须把数码相机、PMP、PSP的Flash存储卡拔出，插在数码伴侣上，然后在数码伴侣的小的液晶屏上选择文件，进行拷贝操作，其优点是成本较便宜，问题在于拔插卡比较麻烦；另一种是USB OTG方式的，它没有Flash存储卡插槽，只有一个USB口，当与PC连接的时候数码伴侣做“USB从设备”，当与数码相机、PMP、PSP连接的时候数码伴侣做“USB主设备”，其优点是免却了拔插卡的麻烦，但是在数码伴侣上的小液晶屏上操作起来不方便的缺点仍然存在。

以上两类数码伴侣产品还存在一个共同的致命的弱点在于：他们都是把硬盘中的文件完整拷贝到手持设备上，然后才能在手持设备上使用，这就要求手持设备本身的存储卡的剩余空间必须足够放得下整个大文件，例如要看一部影片大小为400MB，手持播放器上就必须得有大于400MB的剩余空间，很多智能手机很难满足这个要求，即使是总的容量够大，当其内部已经有一些电影而要看下一部电影的时候，很多时候也必须要先删除原来的影片，给后面的影片腾出空间，这都是非常麻烦的事情。当然对用户来说最方便的操作方式还是在手持设备端操作，因为智能手机、PMP、PSP既然做到可以看影片，其屏一定都是真彩的大尺寸的LCD，按键操作起来也非常方便，加上用户已经习惯其操作方式，甚至很多是有触摸屏的，更加方便。目前市面上的手机、PDA、数码相机、PMP等的USB“从设备”一般都只能支持PC或数码伴侣对它们自身存储器的访问，它们无法倒过来直接访问PC或数码伴侣的硬盘存储器，所以发明一种可以实现“USB从设备”对“USB主设备”存储器的“直接访问”方法很有意义。

发明内容

本发明的目的是针对上述所提到的数码伴侣使用不方便的问题，提供一种可实现在“USB从设备”端直接访问“USB主设备”端文件的方法。

实现本发明的技术方案为：一种实现在“USB从设备”端(下面简称“从设备”)直接访问“USB主设备”端(下面简称“主设备”)文件的方法，包括以下步骤：在“从设备”存储器中建立交换缓存区，让操作者在“从设备”端操作；“从设备”端上层软件把其对于“主设备”存储器文件的访问“请求”按一定的协议写在自身存储器的一个“请求”缓存区里(文件或特殊存储扇区)；然后把存储器的控制权交给“主设备”端，“主设备”端读取“从设备”存储器中的这个“请求”缓存区，并执行其“请求”，对于文件管理“请求”进行文件复制、移动、删除等操作，对于文件“读请求”把“主设备”端的文件块复制到“从设备”端交换缓存区中的缓存块，对于文件“写请求”把“从设备”端交换缓存区中的缓存块复制到“主设备”端的文件中；当“从设备”再一次获得其存储器控制权的时候，要访问的文件已经全部或部分在本身的存储器里了，就可以实现对其进行读写访问。

用户在“USB从设备”端进行操作，对“USB主设备”端(或称OTG端)的存储器进行文件访问；“包括但不限于”浏览分区信息、浏览文件名或目录结构、打开文件/目录、读文件、写文件、关闭文件、复制文件/目录、移动文件/目录、删除文件/目录、复制文件的某一部分、或者对主引导区、引导区、FAT表、扇区读写等操作的一种或多种的组合。

本发明只需要在“USB从设备”端存储器中建立交换缓存区，在“USB从设备”端上层应用程序中把对“USB主设备”端文件访问的“请求”以文件或特殊存储块的形式记录在交换缓存区中；在“USB主设备”端解析“从设备”端的“请求”，并执行相应操作。对于“USB主设备”端文件块的访问，是把文件块复制到“USB从设备”端的交换缓存区(文件或特殊存储扇区)中，然后再进行访问。这样USB从设备端对USB主设备端的文件访问全部转化为对自身存储器文件或交换缓存区的访问。

本发明的优点：(1)本发明方法不需要在“主设备”端(数码伴侣端)进行任何操作，而在“从设备”端(智能手机、MP4、PMP、PSP端)就可以“直接访问”“主设备”端文件，非常方便；(2)此外，不需要把几百兆文件全部复制过来再使用，可以要使用哪部分就复制哪部分，即使手持设备存储器总容量小于文件大小或者剩余空间不足，也可以访问大文件，甚至对于处理器速度足够快的设备，可以达到一边播放影片，一边复制影片后续的部分，在整个影片播放过程中间没有停顿，对用户来说与播放自身存储卡中的影片感觉完全一样；(3)本发明的第三个好处是允许手持播放器以低成本和省电的方式扩展可直接访问的外接硬盘：目前有些MP4和PMP为了既不增加硬盘成本又能保持可播放外接硬盘视频的可扩展性，采取了自带USB Host芯片的方式，可是为了省电还要带USB Host2.0High Speed的芯片才行，否则传输过慢，硬盘费电，硬盘瞬间电流可达700mA～1A，一会儿就没电了，但是真正的USB Host2.0OTG芯片的成本大约是USB Device2.0芯片的6～10倍，本发明的方法允许手持播放器端只要用USB Device芯片就可以了，大大降低了手持播放器的硬件成本，而且大缓存的方式也可以让硬盘不用一直保持旋转，以1Mbps码率的视频来说大约1分钟的播放只需要10秒传输时间，让电池使用时间延长5倍以上。

附图说明

图1是本发明实施例的硬件框图；

图2是本发明实施例的软件系统框架与数据流图；

图3是本发明实施例的USB从设备端资源管理器软件流程图；

图4是本发明实施例的USB从设备端以顺序读为主要应用的软件流程图；

图5是本发明实施例的USB从设备端以顺序写为主要应用的软件流程图

图6是本发明实施例的USB主设备端(数码伴侣端)软件流程图。

具体实施方式

下面根据附图和实施例对本发明作进一步详细说明。

如图1所示，表示典型的USB主设备端(数码伴侣端)与诸如手机、PDA、PMP、数码相机等USB从设备的连接方式。数码伴侣工作的时候USB Host/OTGController/MCU将手机/PDA/PMP/数码相机统一识别为一个UMS(USB MassStorage Class)或PTP存储设备，然后将硬盘中的文件与“USB从设备”中的文件相互交换。本发明的方法不需要改动这种硬件结构，而仅仅只是通过让USBHost/OTG Controller/MCU由主要控制者变为从控制者，而让USB从设备端的主功能芯片成为主控者。

如图2所示，表示整个软件系统框图和数据流图，包括USB从设备端建立“硬盘文件缓存系统层”；交换缓存区中细分为配制文件、请求文件、硬盘索引文件、缓存块文件；文件读写示意，文件复制、移动及删除操作示意等。

如图3所示，表示USB从设备端资源管理器软件流程图，首先在“USB从设备”端(手机/PDA/MP4/PMP)实现最基本的数码伴侣功能，也就是要利用这些设备的大屏幕来显示文件、目录、操作菜单等，利用它们方便的按键或触摸屏来进行操作，代替传统的在数码伴侣端小屏幕上操作的方式。所以首先要在“USB从设备”端写一个类似于PC Windows上的资源管理器的软件界面，用于显示硬盘和本地存储器的各文件目录，提供文件浏览、复制、删除、打开等基本操作。这个软件可叫做“硬盘资源管理器”或者“数码伴侣管理器”之类的名字。实现这个“硬盘资源管理器”的关键在于在USB从设备端的存储器中建立一个“请求”文件，把各操作“请求”按照一定的协议写在这个“请求”文件中，然后打开USB连接，等待数码伴侣端按照这个“请求”清单执行，等到检测到数码伴侣端执行完各“请求”之后的“关闭USB连接事件”(Suspend USBBus)，即完成了一次传输。

如图4所示，表示本发明实施例的USB从设备端以顺序读为主要应用的软件流程图。除了“硬盘资源管理器”实现文件管理操作上的方便性以外，另一个最能体现直接访问优势的应用就是直接播放硬盘上的视频文件了，还有MP3音乐播放器，照片浏览器，文字阅读器等的应用虽然没有那么迫切，但是用于文件复制前的预览也是很有用的。以上这些软件的共同特征就是他们主要的操作就是顺序读，或者以顺序读为主要方式，随机读为次要方式，没有写操作。本发明方法利用“USB从设备”端存储器为交换媒介优点一是兼容性好，不用改原来的硬件和底层驱动程序就可以实现，优点二是避免硬盘一直旋转，可以省电，但是反应速度慢，其从操作命令发出到完成的时间需要几秒到几十秒之长，所以要在那么长的读取延时环境下实现视频的连续不间断播放，是需要用比较好的算法来进行大缓存预读。以视频播放为例，一般来说，一个视频文件可能由几个通道组成：一个视频通道、两个音频通道、一个索引区等。刚开始播放器会去打开索引区，然后根据索引区打开各视频音频通道，之后就开始顺序读取各通道数据进行播放，区别在于视频通道读得快，音频通道读得慢。我们要想播放器一旦启动就不用停下来等待读取数据，则必须要根据各通道读取速度进行预读，始终保持要播放的内容已经在本地存储器中。但是，如果我们要仔细分析每一个视频播放器的流程，每一种视频格式的规范，然后把读取文件的提前量写入播放器程序的每一个过程，那工作量就太大了，所以我们只能实现一个智能判断各文件读取速度而做出预读计算的“硬盘文件缓存系统”层。要简单快捷的插入一个“硬盘文件缓存系统”层，最简单的方法就是把所有文件操作函数重定向到该层，然后对于本地文件操作，调用对应的文件操作函数即可，对于硬盘文件操作，进行预读、传输、然后从缓存中读取数据块返回上层应用程序。以C语言视频播放器为例，在所有源文件的头文件最前面插入以下重定向宏定义：

#define fopen bufferSystem_fopen

#define fclose bufferSystem_fclose

#define fread bufferSystem_fread

#define fwrite bufferSystem_fwrite

#definefget bufferSystem_fget

#definefput bufferSystem_fput

#define fseek bufferSystem_fseek

然后重写各文件操作函数，如果是本地文件操作，则调用本地文件操作函数，如果是硬盘文件操作，则采用预读的算法提前从硬盘传输到本地存储器缓存区，从缓存中读取数据块返回上层应用程序，以下是其中两个函数的例子：

FILE*bufferSystem_fopen(const char*file，const char*flags)

{

if(isFilePathLocal(file)=TRUE)

return fopen(file，flags)；

else

{

return hardisk_fopen(file，flags)；//在这里返回一个内部管理文件句柄，并记下该文件句柄，以后凡是使用该句柄的文件读操作都要受预读算法管理。

}

int bufferSystem_fread(unsigned char*buf，int size，int count，FILE*fd)

{

if(isTheFileLocal(fd)＝TRUE)

return fread(buf，size，count，fd)；

else

{

return hardisk_fread(buf，size，count，fd)；//采用预读的算法提前从硬盘传输到本地存储器缓存区，从缓存中读取数据块返回上层应用程序

}

其他函数都是类似的结构，这里不再累述，下面着重分析一下算法核心的部分，就是预读算法。

预读的难点在于预读时间提前量的计算，下面就各相关因素进行分析：

1、总缓存区大小：缓存区开得越大，就能缓存越多的数据，提高缓存命中率(当某一次读取文件数据的时候如果数据已经预读到缓存区了，我们称“缓存命中”，如果文件还在硬盘，需要立即读取，造成应用程序的等待，我们称“缓存未命中”)，还能减少传输次数，减少硬盘启动次数，让系统省电。但是，缓存区也不能无限制开大，因为直接访问的优点之一，就是要在“USB从设备端”存储器空间有限的情况下访问大文件，缓存区占用空间越小，给其他应用留的空间就越多。再说很多数码相机、手机、MP4随机赠送的卡只有16MB或32MB，要想在这些卡上就能使用的话，更要控制缓存区大小，所以我们还是要控制缓存区大小，尽量不要超过16MB。

2、单个缓存块大小/缓存块个数：在总的缓存区大小确定的情况下，单个缓存块个数越少，即单个缓存块越大，传输次数就越少，优点是硬盘启动次数减少，系统省电，但是缺点是不够灵活，当同时有多个通道分别在文件不同位置顺序读写时(例如一个视频通道从文件头开始读，两个音频通道从文件中部开始读)，就会造成缓存频繁切换的抖动，所以必须要有足够多的缓存区。一个均衡的方法是，单个缓存块的大小小一些，但是根据一个通道读取的速度来决定单次传输缓存块的个数，即读得快的通道一次多传几个缓存块，读得慢的通道一次少传几个缓存块。一般来说，视频码率如果是1Mbps的话，1分钟数据量为60s×1Mb/s＝60Mb＝8MB，音频码率如果是64Kbps的话，双通道1分钟数据量为2×60s×64Kb/s＝7.5Mb＝1MB，以1MB为单个缓存块大小的话，音频占一个，视频占8个，1分钟启动一次传输，传输时间大约要10秒。这样的话，开15MB的总缓存区，分为15个1MB的缓存块。实际上还可以根据各手持播放器所支持视频码率的实际情况进行调整。

3、预读的时机：预读的时机是根据实际读取的速度来计算提前量的，比如要1分钟进行一次传输，已知1Mbps的视频通道与两个64Kbps的音频通道，一分钟的数据量分别是8MB和1MB，传输时间10秒，则提前30秒开始传输应该来得及，30秒时剩余未播放数据4.5MB，总缓存区15MB，正好可以空出10MB来给下一分钟放缓存数据。实际上还可以根据各手持播放器所支持视频码率的实际情况进行调整。

4、初次传输与启动时间：预读的一个问题是刚开始播放的时候的第一次传输，没有读取历史速度的依据，甚至连文件头都没有，只有一个文件名和文件大小可以参考，该如何选择初始传输的大小呢？要想尽可能快的开始播放，则要尽可能少的传输，然而如果传输过少，万一遇上是大码流的视频文件，则会发生开始播放以后没多久就停顿，等待第二次传输的完成，这是一个矛盾。幸运的是，一般手持多媒体播放器所能支持的最高码流都是一定的，并不会经常变化，而我们的直接访问技术对播放器也都需要单独开发和调试，并不是一个一般的播放器要支持所有机型，所以可以根据实际硬件性能来调试定制初始的两次传输的大小，只要对最高码率的视频调试出一个在不会造成播放后停顿的最短启动时间，就可以了。一般来说，1MB的缓存块，1MBps的码率，第一次传输一个缓存块，第二次预读5～8个缓存块，以后根据实际读取的速度来计算，是没有问题的。

以下是流程主要部分在各种情况下的走向：

第一次读/立即读/遇突然读取速度变快而读取未命中：1-->2-->4-->5-->6-->7-->8-等待->9-->10-->1

第二次读/正常预读：1-->2-->4-->11-->12-->13-->14-->10-->1

大部分情况下读取命中(数据已在缓存区)：1-->2-->4-->11-->12-->10-->1或1-->2-->4-->11-->10-->1

正常预读完成：1-->2-->3-->4-->11-->12-->10-->1

预读传输过程中遇突然读取速度变快而读取未命中：1-->2-->4-->5-->15-等待->16-->4-->11-->12-->13-->14-->10-->1或发生更惨的情况(上次预读的还不够本次读取，等待两次)：1-->2-->4-->5-->15-等待->16-->4-->5-->6-->7-->8-等待->9-->10-->1

图5是本发明实施例的USB从设备端以顺序写为主要应用的软件流程图。尽管直接访问的大部分应用是以顺序读为主要应用的各种播放器，顺序写也是有其应用面的，例如视频录像机软件，录音机软件等，也可以利用直接访问技术来把长时间录像直接写在数码伴侣硬盘上。这类软件基本上是以顺序写为主要操作。与“预读”相对应的，我们称之为“后写”操作，意即先写在本地存储器缓存区，等积累到一定大小之后，再写到硬盘。同样，后写操作也要靠“硬盘文件缓存系统”层来实现。其核心是后写的时间估计算法。

缓存区大小和分块方法同预读算法。这里分析一下后写的时机：后写时机估计比预读要简单，因为预读的前几次传输既没有计算依据，又要尽可能缩短启动时间，而后写基本上不存在这些问题。可以简单的等缓存区半满的时候，几个通道的写速度都均衡了以后，再开始写。而且一般来说只要总缓存区够大，不会发生堵住等待的情况。最后关闭文件的时候再把剩下缓存块的全部写入硬盘就可以了。

以下是流程主要部分在各种情况下的走向：

写缓存命中(有空缓存区)：1-->2-->4-->6-->7-->8-->10-->1

正常后写：1-->2-->4-->6-->7-->8-->9-->10-->1

正常后写完成：1-->2-->3-->4-->6-->7-->8-->10-->1

遇写速度突然变快而写缓存未命中(无空缓存区)：1-->2-->4-->11-->12-->13-等待->14-->15-->10-->1

后写传输过程中遇写速度突然变快而写缓存未命中：1-->2-->4-->11-->16-等待->17-->4-->6-->7-->8-->9-->10-->1或者发生更惨的情况(上次后写的腾出的空缓存区还不够本次写，等待两次，一般来说不会发生这种情况)：1-->2-->4-->11-->16-等待->17-->4-->11-->12-->13-等待->14-->15-->10-->1

如图6所示，表示数码伴侣端软件流程图。数码伴侣端的任务是执行“USB从设备”端写在“请求”文件中的各命令，跟普通双向OTG数码伴侣的区别仅在于发命令的源不一样，普通双向OTG数码伴侣是由用户在数码伴侣端操作按键，选择菜单的方式发命令，直接访问方式的数码伴侣需要根据“USB从设备”端写在“请求”文件中的命令来执行。

配置文件规范：PC安装软件的时候在手持播放器根目录中写入本配置文件，文件名为“WitDADTM.ini”(Witchain Direct Accessible Digital Tour Mate的缩写)，数码伴侣按照本配置文件进行操作。

配置项	位置	长度	默认值	含义解释
					配置文件标志	0～3	4	PHCF	配置文件标志
配置文件规范版本	4～9	6	V1.00	配置文件规范版本，版本兼容性定义：Va.bcd：a位变化时相互不兼容，只有高版本解释程序中写了低版本规范解释程序或使用转换工具才能解析低版本配制文件；若a位相同，b位变化时，低版本解释程序可解释高版本配置文件，只是一些新增功能无法实现，cd位变化仅为非关键字的标识修改，不影响解析，举例：V1.20t版本的解释程序能解释V1.xxx版本的配置文件，但遇到V2.xxx的配制文件则需要更新解释程序。
					手持播放器工作目录	10～73	64	\witchain\DADTM	手持播放器的存储卡上的工作目录，“请求”文件、存储器文件所在的位置
数码伴侣工作目录	74～137	64	\witchain\DADTM	数码伴侣上的工作目录，临时文件所在位置
					硬盘引导记录文件名	138～191	64	HDIndex.dat	数码伴侣将硬盘主引导记录等内容写入手持播放器该文件，位于手持播放器工作目录下
交换“请求”文件名	192～255	64	OperList.dat	操作列表文件名，位于手持播放器工作目录下
					保留	256～511	256	0	保留用途

硬盘索引文件规范：数码伴侣向手持播放器的存储卡中写入一些表示硬盘中文件目录的索引文件，由两部分组成，一部分是硬盘主引导分区和各分区(或逻辑盘)引导记录，都是512字节，这部分默认情况下位于手持播放器工作目录下叫HDIndex.dat文件。

数据项	位置	长度	默认值	描述
					主引导分区MBR	0～511	512	复制硬盘M BR到该位置，其中包含了硬盘分区信息，分区大小
第一分区DBR	512～1023	512		含第一分区的分区信息，分区大小等，C盘
					第二分区(或逻辑分区)DBR	1024～1535	512	含第二分区的分区信息，分区大小等，D盘
...

另一部分是目录表，从根目录开始，每一个目录作为一个文件，位于手持播放器工作目录下，文件名是首簇号，内容对应硬盘上一个目录表的内容，由手持播放器负责解析这些目录表内容。

“请求”文件规范

数据项	位置	长度	默认值	描述
					“请求”文件标志	0～3	4	PDOL	“请求”文件标志：Portable DiskOperation List的缩写
“请求”文件规范版本号	4～9	6	“V1.00”	配置文件规范版本，版本兼容性定义：Va.bcd：a位变化时相互不兼容，只有高版本解释程序中写了低版本规范解释程序或使用转换工具才能解析低版本配制文件；若a位相同，b位变化时，低版本解释程序可解释高版本配置文件，只是一些新增功能无法实现，cd位变化仅为非关键字的标识修改，不影响解析，举例：V1.20t版本的解释程序能解释V1.xxx版本的配置文件，但遇到V2.xxx的配制文件则需要更新解释程序。
					操作项列表开始偏移		1	32	操作项列表的开始偏移
操作项固定部分长度		2	16
					操作项数目		2
参数表开始偏移		2	128
					保留		15	0
操作1_状态	32(操作项列表开始偏移)	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
					操作1_命令	33	1		操作命令代号，祥见后述
操作1_参数及字串索引	34～47	14		具体定义见命令列表
					操作2_状态	48	1		未执行＝0，执行成功＝1，执行失败＝错误号>1
操作2_命令	49	1		操作命令代号，祥见后述
					操作2_参数及字串索引	50～63	14		具体定义见命令列表
...
					参数字串列表	128(参数表开始偏移)			各字串结尾处填0，连续摆放

命令定义：

1、命令：MBRDPT

代号：0x01

功能：请求硬盘分区信息

参数：

状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
					命令	1	1	0x01	MBRDPT命令
参数保留	2～15	14	0	不用的参数填0

2、命令：ls

功能：请求数码伴侣列硬盘某文件夹下的文件目录

代号：0x10

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x10	ls命令
					字串参数1_偏移	2～3	2		请求被列文件夹路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		请求被列文件夹路径名字串长度
					参数2	5	1	1	请求列目录深度，0为列所有子目录，1～10为列目录深度
参数保留	6～15	10	0	不用的参数填0

3、命令：cp

功能：请求数码伴侣进行复制文件或文件夹操作

代号：0x20

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x20	cp命令
					字串参数1_偏移	2～3	2		源文件或文件夹路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源文件或文件夹路径名字串长度
					字串参数2偏移	5～6	2		目的文件或文件夹路径名字串在参数表中的起始偏移
字串参数2长度	7	1		目的文件或文件夹路径名字串长度
					参数保留	8～15	8	0	不用的参数填0

4、命令：rm

功能：请求数码伴侣进行删除文件或文件夹操作

代号：0x30

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x30	rm命令
					字串参数1_偏移	2～3	2		删除文件或文件夹路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		删除文件或文件夹路径名字串长度
					参数保留	5～15	11	0	不用的参数填0

5、命令：mv

功能：请求数码伴侣进行移动文件或文件夹操作

代号：0x40

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x40	mv命令
					字串参数1_偏移	2～3	2		源文件或文件夹路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源文件或文件夹路径名字串长度
					字串参数2偏移	5～6	2		目的文件或文件夹路径名字串在参数表中的起始偏移
字串参数2长度	7	1		目的文件或文件夹路径名字串长度
					参数保留	8～15	8	0	不用的参数填0

6、命令：partial copy file

功能：请求数码伴侣进行“部分复制”文件操作，生成新文件。

代号：0x50

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x50	Partial copy file命令
					字串参数1_偏移	2～3	2		源文件或文件夹路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源文件或文件夹路径名字串长度
					字串参数2偏移	5～6	2		目的文件或文件夹路径名字串在参数表中的起始偏移
字串参数2_长度	7	1		目的文件或文件夹路径名字串长度
					参数3	8～10	3		部分复制开始簇，0开始编号，簇大小随源文件所在分区
参数4	11～13	3		部分复制簇数目，最小1，簇大小随源文件所在分区
					参数5	14	1		复制速度，0最快速，255最慢
参数保留	15	1	0	不用的参数填0

7、命令：copy file to cache

功能：请求“部分复制”硬盘文件到手持播放器存储器缓存区文件

代号：0x51

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x51	copy file to cache命令
					字串参数1_偏移	2～3	2		源文件路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源文件路径名字串长度
					字串参数2偏移	5～6	2		目的缓存文件路径名字串在参数表中的起始偏移
字串参数2长度	7	1		目的缓存文件路径名字串长度
					参数3	8～10	3		源文件开始复制簇编号，0开始编号，簇大小随源文件所在分区
参数4	11～12	2		源文件复制簇数目，最小为1，簇大小随源文件所在分区，如果两个簇大小不一样，该数目需保证数据块大小在目的分区仍然是整簇，以便前后两次复制文件相连
					参数5	13～14	2		放到目的缓存文件的开始簇编号，0开始编号，簇大小随手持设备存储卡
参数6	15	1	0	复制速度，0最快速，255最慢

8、命令：copy cache to file

功能：请求“部分复制”手持播放器存储器缓存区数据块到硬盘文件

代号：0x52

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x52	copy cache to file命令
					字串参数1_偏移	2～3	2		源缓存文件路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源缓存文件路径名字串长度
					字串参数2偏移	5～6	2		目的文件路径名字串在参数表中的起始偏移
字串参数2长度	7	1		目的文件路径名字串长度
					参数3	8～9	2		源缓存文件开始复制簇编号，0开始编号，簇大小随手持设备存储卡
参数4	10～11	2		源缓存文件复制簇数目，最小为1，簇大小随手持设备存储卡，如果两个簇大小不一样，该数目需保证数据块大小在目的分区仍然是整簇，以便前后两次复制文件相连
					参数5	12～14	3		放到目的文件的开始簇编号，0开始编号，簇大小随硬盘
参数6	15	1	0	复制速度，0最快速，255最慢

9、命令：append cache to file

功能：请求“追加复制”手持播放器存储器缓存区数据块到硬盘文件末尾，用于最后的非整簇数据复制

代号：0x53

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x53	append cachetofile命令
					字串参数1_偏移	2～3	2		源缓存文件路径名字串在参数表中的起始偏移
字串参数1_长度	4	1		源缓存文件路径名字串长度
					字串参数2_偏移	5～6	2		目的文件路径名字串在参数表中的起始偏移
字串参数2_长度	7	1		目的文件路径名字串长度
					参数3	8～9	2		源缓存文件开始复制簇编号，0开始编号，簇大小随手持设备存储卡
参数4	10～11	3		追加数据字节数
					参数5	12	1	0	复制速度，0最快速，255最慢
参数保留	13～15	3	0	不用的参数填0

10、命令：Power Control

功能：控制数码伴侣电源

代号：0x02

参数：

参数项	位置偏移	长度	取值	解释
					状态	0	1	0	未执行＝0，执行成功＝1，执行失败＝错误号>1
命令	1	1	0x02	Power Control命令
					参数1	2	1		1＝省电模式，2＝非省电模式
参数保留	3～15	8	0	不用的参数填0

错误代码：0：未执行；1：执行成功；2：该命令未定义，可能是版本的原因；3：参数越界；4：空间不足；5：源文件不存在；6：目的文件不存在

本发明的实施例中虽然规定一种交换缓存区、“请求”文件、配制文件的协议规范，但该规范仅仅是该发明方法的一个具体实现，在不脱离本发明范围和实质特点的情况下，采用其他任何形式的交换缓存区、“请求”缓冲区(文件或特殊存储扇区)协议规范，都在本发明权利要求的保护范围内。

Claims

1.一种实现在USB从设备端直接访问USB主设备端文件的方法，其特征在于：包括以下步骤：

在USB从设备端存储器中建立交换缓存区；

USB从设备端上层软件把其对于USB主设备端存储器文件的访问“请求”写在自身存储器的一个交换缓存区里；

USB主设备端读取USB从设备端存储器中的这个交换缓存区，并执行其“请求”，进行文件复制、移动或删除操作或把USB主设备端的文件块与USB从设备端交换缓存区中的缓存块进行交换；

USB从设备端直接读写访问自身存储器文件或交换缓存区。

2.如权利要求1所述的实现在USB从设备端直接访问USB主设备端文件的方法，其特征在于：所述USB从设备端对USB主设备端存储器进行文件访问，包括但不限于以下一种或多种操作的组合：浏览分区信息、浏览文件名或目录结构、打开文件/目录、读文件、写文件、关闭文件、复制文件/目录、移动文件/目录、删除文件/目录、复制文件的一部分、或者对主引导区、引导区、FAT表、扇区读写。

3.如权利要求1所述的实现在USB从设备端直接访问USB主设备端文件的方法，其特征在于：在USB从设备端上层软件中把对USB主设备端文件访问的“请求”以文件或特殊存储块的形式记录在自身存储器的交换缓存区中。