JP2012073663A - Usb host device and program - Google Patents

Abstract

Provided is a USB host device capable of avoiding that the processing capability of the USB host device is exclusively used only for processing the USB storage device even if data transmission to and from the USB storage device is repeated a plurality of times.
A USB host device issues a SCSI command to read / write m sectors from sector T, where T is the first sector and n is the number of read / write sectors (S501). Then, T + m is newly set as T, nm is newly set as n (S509), and WAIT is performed for a waiting time having a length proportional to the value of the maximum number of sectors m that can be read / written (S511). As a result, only the standby time corresponding to the data transfer amount in S507 is in the standby state in S511, during which the CPU 11 can execute other processes.
[Selection] Figure 6

Description

  The present invention relates to a USB host device that communicates with a USB storage device by a method compliant with the USB (Universal Serial Bus) standard, and a program for causing a computer included in the USB host device to function as a USB storage driver.

  The USB host device recognizes the USB storage device as a SCSI (Small Computer System Interface) device, and when accessing the USB storage device, a SCSI command is issued in the USB host device. Then, the SCSI command is passed to a USB storage driver (USB mass storage class driver) (see, for example, Patent Document 1: Paragraph [0027]).

  The USB storage driver adds a USB header to the passed SCSI command, and then passes the SCSI command to the USB protocol stack, which is transmitted to the USB storage device via the USB protocol stack.

JP 2004-171536 A

  By the way, when data reading or writing with respect to a USB storage device is repeated a plurality of times, a SCSI command for a plurality of times is transmitted from the USB storage driver to the USB storage device.

  At this time, if it is a data read, the data to be read is transmitted from the USB host device side to the USB storage device side a plurality of times. In the case of data write, data to be written is transmitted from the USB storage device side to the USB host device side multiple times.

  However, if the data processing capability on the USB host device side is not sufficient, if the data transmission is repeated multiple times as described above, most of the data processing capability on the USB host device side is It becomes a situation that is devoted to data transmission between.

  Therefore, when such a situation occurs, if processing other than communication with another USB device or communication with the USB device is executed in parallel in the USB host device, those processing are executed appropriately. In other words, processing delays and data loss may occur.

  The present invention has been made to solve the above-described problem, and the object of the present invention is to process the USB host device with the processing capability of the USB storage device even when data transmission is repeated multiple times with the USB storage device. Another object is to provide a USB host device that can avoid being exclusively used, and a program for causing a computer included in such a USB host device to function as a USB storage driver.

Hereinafter, the configuration employed in the present invention will be described.
The USB host device according to claim 1 is communicable with a USB device, and when reading or writing to a USB storage device, a SCSI driver, a USB storage driver, and a USB host controller cooperate to form the USB storage device. A USB host device that controls a device, wherein the USB storage driver issues a SCSI command to the USB storage device a plurality of times, and performs a read or write corresponding to each SCSI command. After the completion of the read or write corresponding to the SCSI command issued at the time, and before issuing the next SCSI command, the waiting time according to the data size specified by the parameter in the SCSI command issued earlier. And determine Characterized in that it comprises a weight control means for executing a wait time of the wait control.

  According to the USB host device configured as described above, the standby time is determined according to the size of data read or written by the previously issued SCSI command, and wait control for the standby time is executed. Is done.

  For this reason, when the data size to be read or written is large, the USB storage driver will occupy the processing capability of the USB host device accordingly, but in that case, the wait control is correspondingly long. Is executed. Therefore, while the wait control is being executed, the processing capability of the USB host device can be assigned to another process.

  On the other hand, when the data size to be read or written is small, only a short time wait control is executed. Therefore, although the USB storage driver does not occupy the processing capability of the USB host device so much, the processing executed by the USB storage driver is not delayed.

  Therefore, if the above control is performed, the processing capability of the USB host device is excessively dedicated to the USB storage driver, and the processing executed by the USB storage driver is excessively delayed. Can be prevented in advance.

  The USB host device according to claim 2 is the USB host device according to claim 1, wherein the USB storage driver issues a SCSI command issued from the SCSI driver when reading data to be read from the USB storage device. The size of the data to be read specified by the SCSI command acquisition means to be acquired and the parameter in the SCSI command acquired by the SCSI command acquisition means is larger than the size that can be stored in the data buffer of the USB host controller In this case, the data to be read is divided into several pieces of data so that the size of each piece of divided data can be stored in the data buffer, and each piece of the divided data is stored in the USB storage device. To read from SCSI command generation means for generating several SCSI commands in which parameters for specifying each subsequent data as a reading target are set, and each of the several SCSI commands generated by the SCSI command generation means, SCSI command issuing means for sequentially issuing to the storage device, and each time the several SCSI commands are issued by the SCSI command issuing means, the data buffer is transferred from the USB storage device as a response to each SCSI command. Data acquisition means for sequentially acquiring the data stored in the data buffer, and when all the divided data sequentially acquired by the data acquisition means are acquired, the divided data are collectively Data transfer means for transferring to the SCSI driver as a response to the SCSI command acquired by the SCSI command acquisition means, the wait control means by the SCSI command generation means by the SCSI command generation means. The wait control is executed when each of the generated SCSI commands is sequentially issued to the USB storage device.

  According to the USB host device configured as described above, even if a SCSI read command for requesting a large amount of data read to the USB storage device is issued in the USB host device, the USB storage driver sends the USB storage device to the USB storage device. Does not issue a SCSI read command requesting a large amount of data read. Therefore, it is possible to prevent data exceeding the capacity of the data buffer that can be safely used from being transferred from the USB storage device.

  Further, the timing of issuing each divided SCSI command can be set to a convenient timing according to the processing capability on the USB host device side. Therefore, even when there is not enough remaining data processing capability on the USB host device side, data transferred from the USB storage device can be properly received.

  Moreover, the above-described wait control is executed when each of the SCSI commands is sequentially issued to the USB storage device. Therefore, even when the data processing capability on the USB host device side does not have sufficient capacity, it is possible to prevent the processing capability from being exclusively used for processing the USB storage device.

  The USB host device according to claim 3 is the USB host device according to claim 1, wherein the USB storage driver issues a SCSI command issued from the SCSI driver when writing write target data to the USB storage device. The size of the write target data specified by the parameter in the SCSI command acquired by the SCSI command acquisition unit acquired by the SCSI command acquisition unit is larger than the size that can be stored in the data buffer included in the USB host controller. If the data to be written is divided into several pieces of data, the size of each divided data is set to a size that can be stored in the data buffer. After writing to write to USB storage device SCSI command generation means for generating a number of SCSI commands in which parameters for designating each data as a writing target are set, and each of the number of SCSI commands generated by the SCSI command generation means for the USB storage A SCSI command issuing means for issuing sequentially to the device, and a response acquisition means for sequentially acquiring responses returned from the USB storage device each time the SCSI command issuing means issues each of the SCSI commands. Response acquisition means for returning a response to the SCSI command acquired by the SCSI command acquisition means when all the responses sequentially acquired by the response acquisition means are acquired, the wait control means comprising the SCS The command issuing unit, each said SCSI command said several SCSI command generated by the generating means, when successively issued to the USB storage device, and executes the weight control.

  According to the USB host device configured as described above, even if a SCSI write command for requesting a large amount of data write to the USB storage device is issued in the USB host device, the USB storage driver sends the USB storage device to the USB storage device. Does not issue a SCSI write command requesting a large amount of data write. Therefore, it is possible to prevent data exceeding the capacity of the data buffer that can be safely used from being transferred to the USB storage device.

  Further, the timing of issuing each divided SCSI command can be set to a convenient timing according to the processing capability on the USB host device side. Therefore, even when there is not enough remaining data processing capability on the USB host device side, the data to be transferred to the USB storage device can be appropriately transmitted.

  Moreover, the above-described wait control is executed when each of the SCSI commands is sequentially issued to the USB storage device. Therefore, even when the data processing capability on the USB host device side does not have sufficient capacity, it is possible to prevent the processing capability from being exclusively used for processing the USB storage device.

  4. The USB host device according to claim 4, wherein in the USB host device according to claim 2 or 3, information relating to the size of data that can be stored in the data buffer corresponds to each of a plurality of different USB host controllers. A USB host controller information storage unit for storing the data, and the SCSI command generation unit determines the size of data that can be stored in the data buffer based on the information stored in the USB host controller information storage unit; It is characterized by.

  According to the USB host device configured in this way, even if the size of data that can be stored in the data buffer is different in each of a plurality of different USB host controllers, the data to be read is divided into a more appropriate number of divisions accordingly. Will be divided.

  Therefore, although the USB host controller has a relatively large data buffer, the number of data divisions does not increase excessively. Even though the USB host controller has a relatively small data buffer, the number of data divisions does not become excessively small.

  The USB host device according to claim 5 acquires information relating to the number of USB devices existing under the control of the USB host controller in the USB host device according to any one of claims 2 to 4. Device number information acquisition means is provided, and the SCSI command generation means determines the size of data that can be stored in the data buffer based on the information acquired by the device number information acquisition means.

  According to the USB host device configured as described above, the size of data that can be stored in the data buffer is determined based on the number of USB devices existing under the control of the USB host controller.

  Therefore, even when various USB devices use data buffers under the control of the same USB host controller, the number of such USB devices can be dynamically grasped. Then, the data to be read / written can be divided into more appropriate division numbers according to the number of USB devices.

  The program according to claim 6 can communicate with a USB device, and when reading or writing to a USB storage device, a SCSI driver, a USB storage driver, and a USB host controller cooperate with each other to the USB storage device. A USB host device that performs control, a program for causing a computer included in the USB host device to function as the USB storage driver, wherein the USB storage driver is connected to the USB storage device a plurality of times. When issuing a SCSI command and performing a read or write corresponding to each SCSI command, after the read or write corresponding to the previously issued SCSI command is completed, the next SCSI command is Before executing, the standby time is determined according to the size of the data specified by the parameter in the previously issued SCSI command, and functions as weight control means for executing the wait control for the standby time. It is characterized by.

  According to the program configured as described above, the computer included in the USB host device is caused to function as the USB storage driver as described above. Thus, in the USB host device, each unit described in claim 1 functions. Will do.

  Therefore, with such a USB host device, both the processing capability is excessively dedicated to the USB storage driver and the processing executed by the USB storage driver is excessively delayed. It can be prevented in advance.

  The program according to claim 6 may be configured as a program that causes a computer included in the USB host device to further function as each means according to any one of claims 2 to 5. Of course.

The block diagram which shows the system comprised focusing on the USB host apparatus. The block diagram which shows the data transmission path | route in a USB host device. The flowchart of a SCSI command process. The flowchart of a safe sector number acquisition process. (A) is a flowchart of a USB device connection detection process, (b) is a flowchart of a USB device disconnection detection process. The flowchart of a read / write command division process.

Next, an embodiment of the present invention will be described with an example.
[Device configuration]
The USB host device 1 shown in FIG. 1 includes a control unit 2, an auxiliary storage unit 3, a USB interface 4, and other input / output interfaces 5. A USB storage device 7 and a USB handset 8 are connected to the USB interface 4 via a USB hub 6. The other input / output interface 5 is specifically a LAN interface, a display interface, a keyboard interface, or the like. Each of these interfaces is connected to other devices 9 (LAN, display, keyboard, etc.) corresponding to each interface.

  The control unit 2 is configured by a microcomputer including a well-known CPU 11, ROM 12, RAM 13, and the like. The auxiliary storage unit 3 is configured by a storage device such as a hard disk device or a nonvolatile memory.

  The auxiliary storage unit 3 stores programs corresponding to the disk device driver 15, USB host controller driver 16, USB mass storage class driver 17, and USB handset driver 18.

  These programs are loaded from the auxiliary storage unit 3 to the RAM 13 included in the control unit 2 when the USB host device 1 is started up, and thereafter the CPU 11 executes processing based on the programs on the RAM 13. As a result, in the USB host device 1, the disk device driver 15, the USB host controller driver 16, the USB mass storage class driver 17, and the USB handset driver 18 function.

  The USB interface 4 is configured around a USB host controller 19. The USB host controller 19 is a hardware in which a PCI bus interface, an arbiter, an OHCI (Open Host Controller Interface) host controller, an EHCI (Enhanced Host Controller Interface) host controller, a root hub, a USB physical layer, and the like are integrated on one chip. is there.

  Furthermore, in the USB host device 1, software such as the USB protocol stack 21 functions as shown in FIG. A USB system driver such as the USB mass storage class driver 17 and the USB handset driver 18 accesses the USB device via the USB protocol stack 21.

  Each of the USB mass storage class driver 17, USB handset driver 18, USB host controller 19, and USB protocol stack 21 includes buffers 17A, 18A, 19A, and 21A for storing data.

  Here, when the application software functions in the USB host device 1 and data is read or written to the USB storage device 7 in the process, the USB mass storage class driver 17 receives a read request or write request. Communicated.

  This read request or write request is transmitted from the application software via a file system provided in the OS (Operating System) of the USB host device 1.

  The file system converts the read request or write request issued by the application software into a SCSI command for accessing the USB storage device 7 in units of sectors. Then, the SCSI command is transmitted to the USB mass storage class driver 17.

  Upon receiving this SCSI command, the USB mass storage class driver 17 transmits the SCSI command in a method conforming to the USB protocol, and therefore adds the necessary information to the SCSI command and then passes the SCSI command to the USB protocol stack 21. . In this embodiment, the SCSI command is analyzed, and if necessary, the SCSI command is divided. Details thereof will be described later.

  The SCSI command passed to the USB protocol stack 21 is transmitted to the USB storage device 7 via the USB host controller 19. As a result, data corresponding to the read request or write request is transferred between the USB storage device 7 that has received this SCSI command and the USB host device 1.

[Read / write processing for USB storage devices]
Next, processing executed by the USB mass storage class driver 17 when a SCSI command issued from the SCSI driver on the file system side is transmitted to the USB mass storage class driver 17 is based on the flowcharts of FIGS. I will explain.

  When this process is started, the CPU 11 (hereinafter simply referred to as CPU 11) that executes the process as the USB mass storage class driver 17 first receives the SCSI command transmitted to the USB mass storage class driver 17 as the SCSI read / write. It is determined whether the command is received (S101).

  If the command is either a SCSI read command or a SCSI write command (S101: Yes), the CPU 11 provisionally determines the maximum number of sectors per command (S103). In the present embodiment, a fixed value = 16 is used as the maximum number of sectors to be provisionally determined. In S103, the fixed value = 16 is substituted into the variable m.

  Then, the CPU 11 executes a process for acquiring the number of safe sectors per command (S105). Various specific processing contents of S105 can be considered, but in the present embodiment, the processing shown in FIG. 4 is executed.

  That is, when the processing shown in FIG. 4 is started, the CPU 11 first acquires the plug and play ID from the driver (USB host controller driver 16) of the “USB host controller 19 to which the USB storage device 7 is connected” (S201). ). The plug-and-play ID acquired in S201 is an identifier that can uniquely identify the manufacturer and type of the USB host controller 19.

  Subsequently, the CPU 11 searches the obtained plug and play ID from the table (S203). In the USB host device 1, the correspondence between the plug-and-play ID that may be acquired in step S <b> 201 and the number of USB host controller packet buffers corresponding to the plug-and-play ID is tabulated in advance and stored. (See Table 1 below.) In S203, the plug and play ID acquired in S201 is searched from the table as shown in Table 1.

そして、ＣＰＵ１１は、テーブル上にＵＳＢホストコントローラ１９の情報が見つかった否かを判断し（Ｓ２０５）、見つかった場合には（Ｓ２０５：はい）、テーブルから取得した値（Ｑ）を以降の演算で使用する（Ｓ２０７）。

Then, the CPU 11 determines whether or not the information of the USB host controller 19 is found on the table (S205). If it is found (S205: Yes), the value (Q) obtained from the table is calculated by the following calculation. Used (S207).

  On the other hand, if the information of the USB host controller 19 is not found on the table in S205 (S205: No), the CPU 11 uses the default value in the subsequent calculations. This default value is a value determined in advance assuming a relatively low performance among USB host controllers that may be used. For example, a fixed value such as Q = 32 is used. .

  Subsequently, the CPU 11 substitutes the variable P for the number of USB devices connected to the “USB host controller to which the USB storage device is connected” (S211). Based on the values of the variables P and Q, the calculation result of Q / (P + 1) is substituted into the variable k (S213). In S213, when the variable k becomes 0, the value of the variable k is corrected to 1. Then, the value of this variable k is returned as a return value to the higher-level means (processing means that called the processing shown in FIG. 4), and the processing shown in FIG. 4 is terminated.

  If the number of safe sectors k is determined in this way, for example, when the number of USB devices is 1, 1/2 of all packet buffers are used for one USB storage device. When the number of USB devices is 2, 1/3 of all packet buffers are used for one USB storage device, and when the number of USB devices is 3, 1/4 of all packet buffers is one USB storage device. Used for That is, according to the number of USB devices P, 1 / (P + 1) of all packet buffers is used for each USB storage device among the P USB devices.

  Therefore, in this case, even if all USB devices are USB storage devices, if the number of USB devices is 1, 1/2 of all packet buffers are used for all USB storage devices. When the number of USB devices is 2, 2/3 of all packet buffers are used for all USB storage devices, and when the number of USB devices is 3, 3/4 of all packet buffers are used for all USB storage devices. Is done.

  Therefore, even when the number of USB storage devices is P, all packet buffers are used for each USB storage device at a rate of 1 / (P + 1), so the buffers are used in a state where some margin remains. It will be.

  Incidentally, the number of USB devices assigned to the variable P in S211 is a value that is dynamically changed by the processes shown in FIGS. 5A and 5B according to the connection / disconnection of the USB device. It is.

  That is, when the connection of the USB device is detected by the plug and play function, the processing shown in FIG. 5A is executed. In this case, the CPU 11 connects the USB device to which the USB device that has detected the connection is connected. The number of USB devices of the host adapter is counted up (S301), and then normal USB device connection processing is executed (S303). Note that the details of the processing performed in S303 are only general processing in the USB device, and thus description thereof is omitted here.

  If disconnection of the USB device is detected by the plug and play function, the process shown in FIG. 5B is executed. In this case, the CPU 11 connects the USB to which the USB device that detected disconnection is connected. The number of USB devices of the host adapter is counted down (S401), and then normal USB device disconnection processing is executed (S403). Note that the details of the processing performed in S403 are only general processing in the USB device, and thus description thereof is omitted here.

  When the process shown in FIG. 4 is finished, S105 shown in FIG. 3 is finished. Subsequently, the CPU 11 determines whether the maximum sector number m provisionally determined in S103 is safe (that is, the safe sector number k). Whether or not) is determined (S107).

  Here, when the temporarily determined maximum sector number m is dangerous (that is, larger than the safe sector number k) (S107: No), the CPU 11 substitutes the safe sector number k into the variable m to thereby determine the maximum sector number. m is corrected (S109), and the process proceeds to S111. On the other hand, when the tentatively determined maximum sector number m is safe (that is, safe sector number k or less) (S107: Yes), the CPU 11 proceeds to S111 without executing S109.

  When the maximum sector number m is determined in this way, the CPU 11 determines whether or not the read / write sector number exceeds the maximum sector number m (S111). Here, if the read / write sector count exceeds the maximum sector count m (S111: exceeds), when the read / write command is issued as it is, data exceeding the maximum sector count m is transferred to the USB storage device 7. May be transferred between. Therefore, the CPU 11 executes SCSI read / write command division (S113).

  This S113 is a process as shown in detail in FIG. That is, when this process is started, the CPU 11 first substitutes the leading sector number, which is the read / write start position, into the variable T, and substitutes the read / write sector number into the variable n (S501).

  Then, the CPU 11 determines whether or not n ≦ m for the variables n and m (S503). Here, since n> m is established in S111, the process proceeds to the process shown in FIG. 6, and therefore it is determined that at least the first time does not satisfy n ≦ m (S503: No). In this case, the CPU 11 issues a SCSI command for reading / writing m sectors from the sector T by a method compliant with the USB protocol (S507).

  That is, in S507, the read of the maximum number of sectors m determined through S103 to S109, not the number of sectors n requested by the basic SCSI command (the SCSI command that triggered the processing shown in FIG. 3). / Issue a SCSI command to write.

  The SCSI read command issued in S507 is a command for transmitting the SCSI command to the USB storage device 7 via the USB protocol stack 21. More specifically, a header conforming to the USB standard is added to the SCSI read command having the maximum number of sectors m.

  When the SCSI command is transmitted to the USB storage device 7 by such a SCSI command, data transfer of the maximum number of sectors m to the USB storage device 7 is performed. At that time, the transferred data is transferred via the buffer 19A of the USB host controller 19 or the like, but the amount of data is limited to the maximum number of sectors m, which is caused by insufficient capacity of the buffer 19A or the like. Data loss will not occur.

  After completing S507, the CPU 11 newly substitutes the calculation result of T + m into the variable T based on the values of the variables T and m, and newly calculates the calculation result of n−m based on the values of the variables n and m. Substitute in variable n (S509).

  Then, WAIT is performed for a waiting time having a length proportional to the value of the variable m (S511). Specifically, in S511, the product is obtained by multiplying the variable m by a predetermined fixed value, and weight control is executed so that the WAIT state is maintained until a waiting time corresponding to the value elapses. As a result, the standby state is set in S511 for the waiting time having a length corresponding to the data transfer amount in S507, and the CPU 11 can execute other processes during that period.

  Thereafter, when the standby time has elapsed, the process returns to S503. Thereafter, while it is determined in S503 that n ≦ m is not satisfied, S503 to S511 are repeated, and data transfer with the maximum number of sectors m to the USB storage device 7 is repeated.

  If it is determined in step S503 that n ≦ m is satisfied (S503: Yes), the CPU 11 issues a SCSI command for reading / writing n sectors from the sector T using a method compliant with the USB protocol. (S513). As a result, the data of the sector number n is transferred to and from the USB storage device 7, and as a result, the data transfer for the desired number of sectors is completed, and the processing shown in FIG. When the process shown in FIG. 6 ends, S113 shown in FIG. 3 ends, and thus the entire process shown in FIG. 3 ends.

  In the processing shown in FIG. 3, when it is determined in S101 that the command is not a SCSI read / write command (S101: No), the read / write command division processing as described above becomes unnecessary. If it is determined in S111 that the number of read / write sectors does not exceed the maximum number of sectors (S111: not exceeded), the read / write command division processing as described above becomes unnecessary.

  Therefore, in these cases, the CPU 11 executes the conventional SCSI command processing (S115) and ends the processing shown in FIG. Incidentally, the conventional SCSI command processing is processing for adding a header conforming to the USB standard to a SCSI command and issuing the SCSI command. By such processing, the SCSI command is transmitted to the USB storage device 7 via the USB protocol stack 21.

[effect]
As described above, according to the USB host device 1, although the SCSI command is issued every time the steps S507 and S513 arrive, data exceeding the capacity available in the buffer 19A is transferred to the USB 19 at that time. There is no transfer with the storage device 7.

  In addition, when the divided data is transferred a plurality of times, the standby state is set in S511 for the waiting time having a length corresponding to the data transfer amount in S507. Therefore, the larger the data transfer amount, the longer the standby state, and the CPU 11 can execute other processes while in the standby state.

  That is, when the data size to be read or written is large, the processing capacity of the USB host device 1 (CPU 11) is exclusively occupied by communication with the USB storage device 7, but in that case Accordingly, long-time weight control is executed accordingly. Therefore, while the wait control is being executed, the processing capability of the USB host device 1 can be assigned to another process.

  On the other hand, when the data size to be read or written is small, only a short time wait control is executed. Accordingly, the communication with the USB storage device 7 does not delay processing for the USB storage device 7 even though the processing capability of the USB host device 1 is not so exclusive.

  Therefore, if the processing as described above is performed, the processing capability of the USB host device 1 is excessively occupied by the USB mass storage class driver 17 and the processing executed by the USB mass storage class driver 17 is excessively delayed. It is possible to prevent both of them and the both.

  Incidentally, if there is sufficient capacity in the data processing capacity on the USB host device 1 side, it is not necessary to perform the wait control as described above, but in that case, the CPU 11 is required to have a high level of processing capacity. It will be. Therefore, it is necessary to improve the performance of the USB host device 1 by that amount, and the cost for the USB host device 1 increases.

  In this regard, if the configuration as in the above embodiment is adopted, the CPU 11 is not required to have a high level of processing capability, so the USB host device 1 does not have to be overly high performance, and the cost of the USB host device 1 is reduced can do.

  In addition, in order to realize such a function, it is allowed that a SCSI command for requesting reading / writing of a large amount of data exceeding the usable capacity in the buffer 19A is issued in the USB host device 1 itself. Therefore, it is not necessary to modify the application software.

  Also, since there is no need to make any changes to the USB protocol stack 21, the USB protocol stack 21 that is already highly reliable and performing advanced processing need not be inadvertently modified. The reliability of the device 1 is not unnecessarily lowered.

  In addition, if data transfer is restricted by the USB protocol stack 21, there may be a problem in data transfer of a USB audio device or the like, but there is no such problem in the above embodiment.

  More specifically, the USB protocol stack 21 is software used not only for the USB storage device 7 as described above but also for an audio device such as the USB handset 8.

  In the case of this type of USB audio device, if the data processing is not in time, a part of the audio data is discarded, and priority is given to receiving new data that arrives later, so that even if some sound skipping occurs, real time We are trying not to impair the sex.

  Therefore, if the data transfer is restricted by the USB protocol stack 21 when the processing performance of the CPU 11 is low, even if data loss can be prevented, a delay occurs in receiving new data, and real-time performance is impaired. Problems arise.

  In this regard, in the above-described embodiment, since the measures are taken without changing the configuration of the USB protocol stack 21, there is no possibility of adversely affecting an audio device such as the USB handset 8.

[Modifications, etc.]
As mentioned above, although embodiment of this invention was described, this invention is not limited to said specific one Embodiment, In addition, it can implement with a various form.

  For example, in the above-described embodiment, when a large amount of data is divided into a plurality of pieces and data transfer is performed a plurality of times, the wait control is performed each time one data transfer is performed. Wait control may be performed each time. That is, how many times data transfer is performed may be arbitrarily determined in consideration of the processing performance of the USB host device 1 (CPU 11).

  In the above-described embodiment, an example in which the above-described wait control is performed when one SCSI command is divided into a plurality of SCSI commands and issued by the USB mass storage class driver 17 has been described. When the data is repeatedly passed to the storage class driver 17, the wait control as described above may be executed.

  DESCRIPTION OF SYMBOLS 1 ... USB host device, 2 ... Control part, 3 ... Auxiliary storage part, 4 ... USB interface, 5 ... Other input / output interfaces, 6 ... USB hub, 7 ... USB storage device, 8 ... USB handset, 9 ... other devices, 11 ... CPU, 12 ... ROM, 13 ... RAM, 15 ... disk device driver, 16 ... USB host controller driver, 17 ... USB mass storage class driver, 18 ... USB handset driver, 19 ... USB host controller, 21 ... USB protocol stack, 17A, 18A, 19A, 21A ... buffer.

Claims (6)

When communicating with a USB (Universal Serial Bus) device and performing reading or writing to a USB storage device, a SCSI (Small Computer System Interface) driver, a USB storage driver, and a USB host controller cooperate to provide the USB storage. A USB host device that controls the device,
The USB storage driver
When the SCSI command is issued to the USB storage device a plurality of times and the read or write corresponding to each SCSI command is performed, the read or write corresponding to the previously issued SCSI command is completed. Before issuing the SCSI command, wait time is determined according to the data size specified by the parameter in the previously issued SCSI command, and weight control means for executing wait control for the wait time A USB host device comprising: The USB storage driver
SCSI command acquisition means for acquiring a SCSI command issued from the SCSI driver when reading data to be read from the USB storage device;
When the size of the read target data specified by the parameter in the SCSI command acquired by the SCSI command acquisition means is larger than the size that can be stored in the data buffer included in the USB host controller, the read target data is By dividing the data into several pieces of data, the size of each divided data is set to a size that can be stored in the data buffer, and each divided data is read from the USB storage device. SCSI command generating means for generating several SCSI commands in which parameters for specifying each data as a reading target are set;
SCSI command issuing means for sequentially issuing each of the several SCSI commands generated by the SCSI command generating means to the USB storage device;
Each time the SCSI commands are issued by the SCSI command issuing means, data transferred from the USB storage device and stored in the data buffer as a response to each SCSI command is sequentially acquired from the data buffer. Data acquisition means;
When all the divided data sequentially obtained by the data obtaining means are obtained, the divided data are collectively sent to the SCSI driver as a response to the SCSI command obtained by the SCSI command obtaining means. And a data transfer means for transferring,
The wait control unit executes the wait control when the SCSI command issuing unit sequentially issues each of the several SCSI commands generated by the SCSI command generating unit to the USB storage device. The USB host device according to claim 1. The USB storage driver
SCSI command acquisition means for acquiring a SCSI command issued from the SCSI driver when writing target data to the USB storage device;
When the size of the write target data specified by the parameter in the SCSI command acquired by the SCSI command acquisition means is larger than the size that can be stored in the data buffer included in the USB host controller, the write target The data is divided into several pieces of data so that the size of each divided data can be stored in the data buffer and the divided data is written to the USB storage device. SCSI command generation means for generating several SCSI commands in which parameters for designating each subsequent data as a writing target are set;
SCSI command issuing means for sequentially issuing each of the several SCSI commands generated by the SCSI command generating means to the USB storage device;
Response acquisition means for sequentially acquiring responses returned from the USB storage device each time the SCSI command issuance means issues each of the several SCSI commands.
Response issuing means for returning a response to the SCSI command acquired by the SCSI command acquiring means when all the responses sequentially acquired by the response acquiring means are acquired,
The wait control unit executes the wait control when the SCSI command issuing unit sequentially issues each of the several SCSI commands generated by the SCSI command generating unit to the USB storage device. The USB host device according to claim 1. USB host controller information storage means for storing information on the size of data that can be stored in the data buffer in association with each of a plurality of different USB host controllers,
The said SCSI command production | generation means determines the size of the data which can be stored in the said data buffer based on the information memorize | stored in the said USB host controller information storage means. The Claim 2 or Claim 3 characterized by the above-mentioned. USB host device. Device number information acquisition means for acquiring information related to the number of USB devices existing under the control of the USB host controller;
The SCSI command generation unit determines the size of data that can be stored in the data buffer based on the information acquired by the device number information acquisition unit. The USB host device according to one item. In a USB host device that is communicable with a USB device and performs control on the USB storage device in cooperation with a SCSI driver, a USB storage driver, and a USB host controller when reading or writing to the USB storage device. A program for causing a computer included in a USB host device to function as the USB storage driver,
The computer,
When the USB storage driver issues a SCSI command to the USB storage device a plurality of times and performs read or write corresponding to each SCSI command, the read or write corresponding to the previously issued SCSI command After completing the above, before issuing the next SCSI command, the waiting time is determined according to the data size specified by the parameter in the previously issued SCSI command, and the wait control for the waiting time is performed. A program characterized by functioning as a weight control means for executing.

Images