(57)【要約】【課題】ＵＳＢストレージデバイスとの間で複数回にわたるデータ伝送を繰り返しても、ＵＳＢホスト装置の処理能力がＵＳＢストレージデバイスに対する処理ばかりに専有されてしまうのを回避可能なＵＳＢホスト装置の提供。【解決手段】ＵＳＢホスト装置は、先頭セクタをＴ、リード／ライトセクタ数をｎとして（Ｓ５０１）、セクタＴからｍセクタのリード／ライトを行うためのＳＣＳＩコマンドを発行する（Ｓ５０７）。そして、Ｔ＋ｍを新たにＴとし、ｎ−ｍを新たにｎとし（Ｓ５０９）、リード／ライト可能な最大セクタ数ｍの値に比例する長さの待機時間だけＷＡＩＴする（Ｓ５１１）。これにより、Ｓ５０７でのデータ転送量に応じた長さの待機時間だけ、Ｓ５１１では待機状態となり、その間にＣＰＵ１１は他の処理を実行することができる。【選択図】図６
2012073663.tif 000002
【特許請求の範囲】
【請求項１】
ＵＳＢ（Universal Serial Bus）デバイスと通信可能で、ＵＳＢストレージデバイスに対するリード又はライトを行う際には、ＳＣＳＩ（Small Computer System Interface）ドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置であって、
前記ＵＳＢストレージドライバは、
前記ＵＳＢストレージデバイスに対し、複数回にわたってＳＣＳＩコマンドを発行して、各ＳＣＳＩコマンドに対応するリード又はライトを行う際に、先に発行されたＳＣＳＩコマンドに対応するリード又はライトが完了した後、次のＳＣＳＩコマンドを発行する前に、前記先に発行されたＳＣＳＩコマンド内のパラメータで指定されたデータのサイズに応じて待機時間を決定するとともに、当該待機時間分のウェイト制御を実行するウェイト制御手段
を備えることを特徴とするＵＳＢホスト装置。
【請求項２】
前記ＵＳＢストレージドライバは、
前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、
前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読取対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、
前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、
前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、
前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段と
を備え、
前記ウェイト制御手段は、前記ＳＣＳＩコマンド発行手段により、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行する際に、前記ウェイト制御を実行する
ことを特徴とする請求項１に記載のＵＳＢホスト装置。
【請求項３】
前記ＵＳＢストレージドライバは、
前記ＵＳＢストレージデバイスへ書込対象データを書き込む際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、
前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された書込対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記書込対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスへ書き込むため、前記分割後の各データそれぞれを書込対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、
前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、
前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、前記ＵＳＢストレージデバイスから返される応答を、順次取得する応答取得手段と、
前記応答取得手段によって順次取得される前記応答をすべて取得したら、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンドに対する応答を返す応答発行手段と
を備え、
前記ウェイト制御手段は、前記ＳＣＳＩコマンド発行手段により、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行する際に、前記ウェイト制御を実行する
ことを特徴とする請求項１に記載のＵＳＢホスト装置。
【請求項４】
前記データバッファに格納可能なデータのサイズに関する情報を、複数の異なる前記ＵＳＢホストコントローラそれぞれに対応づけて記憶するＵＳＢホストコントローラ情報記憶手段
を備え、
前記ＳＣＳＩコマンド生成手段は、前記ＵＳＢホストコントローラ情報記憶手段に記憶された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定する
ことを特徴とする請求項２又は請求項３に記載のＵＳＢホスト装置。
【請求項５】
前記ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に関する情報を取得するデバイス数情報取得手段
を備え、
前記ＳＣＳＩコマンド生成手段は、前記デバイス数情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定する
ことを特徴とする請求項２〜請求項４のいずれか一項に記載のＵＳＢホスト装置。
【請求項６】
ＵＳＢデバイスと通信可能で、ＵＳＢストレージデバイスに対するリード又はライトを行う際には、ＳＣＳＩドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置において、前記ＵＳＢホスト装置が備えるコンピュータを前記ＵＳＢストレージドライバとして機能させるためのプログラムであって、
前記コンピュータを、
前記ＵＳＢストレージドライバが、前記ＵＳＢストレージデバイスに対し、複数回にわたってＳＣＳＩコマンドを発行して、各ＳＣＳＩコマンドに対応するリード又はライトを行う際に、先に発行されたＳＣＳＩコマンドに対応するリード又はライトが完了した後、次のＳＣＳＩコマンドを発行する前に、前記先に発行されたＳＣＳＩコマンド内のパラメータで指定されたデータのサイズに応じて待機時間を決定するとともに、当該待機時間分のウェイト制御を実行するウェイト制御手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＵＳＢ（Universal Serial Bus）規格に準拠した方式で、ＵＳＢストレージデバイスとの通信を行うＵＳＢホスト装置と、ＵＳＢホスト装置が備えるコンピュータをＵＳＢストレージドライバとして機能させるためのプログラムに関する。
【背景技術】
【０００２】
ＵＳＢホスト装置は、ＵＳＢストレージデバイスをＳＣＳＩ（Small Computer System Interface）デバイスとして認識し、ＵＳＢストレージデバイスへのアクセスを行う際には、ＵＳＢホスト装置内においてＳＣＳＩコマンドが発行される。そして、そのＳＣＳＩコマンドがＵＳＢストレージドライバ（ＵＳＢマスストレージクラスドライバ）に渡される（例えば、特許文献１：段落［００２７］参照。）。
【０００３】
ＵＳＢストレージドライバは、渡されたＳＣＳＩコマンドに対しＵＳＢ用のヘッダを付加してから、そのＳＣＳＩコマンドをＵＳＢプロトコルスタックに渡し、ＳＣＳＩコマンドはＵＳＢプロトコルスタック経由でＵＳＢストレージデバイスへと伝送される。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−１７１５３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで、ＵＳＢストレージデバイスに対するデータのリード又はライトが複数回にわたって繰り返される場合、ＵＳＢストレージドライバからは、ＵＳＢストレージデバイスに対し複数回分のＳＣＳＩコマンドが伝送される。
【０００６】
その際、データリードであれば、ＵＳＢホスト装置側からＵＳＢストレージデバイス側へ複数回にわたってリード対象となったデータが伝送される。また、データライトであれば、ＵＳＢストレージデバイス側からＵＳＢホスト装置側へ複数回にわたってライト対象となったデータが伝送される。
【０００７】
しかし、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合、上記のような複数回にわたるデータ伝送を繰り返していると、ＵＳＢホスト装置側のデータ処理能力の大半が、ＵＳＢストレージデバイスとの間のデータ伝送に割かれる状況となる。
【０００８】
そのため、そのような状況に陥った際、ＵＳＢホスト装置において、他のＵＳＢデバイスとの通信やＵＳＢデバイスとの通信以外の処理などが並行して実行されていると、それらの処理が適切に実行されず、処理の遅延やデータの消失を招くことがあった。
【０００９】
本発明は、上記問題を解決するためになされたものであり、その目的は、ＵＳＢストレージデバイスとの間で複数回にわたるデータ伝送を繰り返しても、ＵＳＢホスト装置の処理能力がＵＳＢストレージデバイスに対する処理ばかりに専有されてしまうのを回避可能なＵＳＢホスト装置と、そのようなＵＳＢホスト装置が備えるコンピュータをＵＳＢストレージドライバとして機能させるためのプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
以下、本発明において採用した構成について説明する。
請求項１に記載のＵＳＢホスト装置は、ＵＳＢデバイスと通信可能で、ＵＳＢストレージデバイスに対するリード又はライトを行う際には、ＳＣＳＩドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置であって、前記ＵＳＢストレージドライバは、前記ＵＳＢストレージデバイスに対し、複数回にわたってＳＣＳＩコマンドを発行して、各ＳＣＳＩコマンドに対応するリード又はライトを行う際に、先に発行されたＳＣＳＩコマンドに対応するリード又はライトが完了した後、次のＳＣＳＩコマンドを発行する前に、前記先に発行されたＳＣＳＩコマンド内のパラメータで指定されたデータのサイズに応じて待機時間を決定するとともに、当該待機時間分のウェイト制御を実行するウェイト制御手段を備えることを特徴とする。
【００１１】
このように構成されたＵＳＢホスト装置によれば、先に発行されたＳＣＳＩコマンドによってリード又はライトが行われたデータのサイズに応じて待機時間が決定されて、その待機時間分のウェイト制御が実行される。
【００１２】
そのため、リード又はライト対象となったデータサイズが大きい場合には、ＵＳＢストレージドライバが、ＵＳＢホスト装置の処理能力を相応に専有することになるものの、その場合には、相応に長時間のウェイト制御が実行される。したがって、ウェイト制御が実行されている間には、ＵＳＢホスト装置の処理能力を、他の処理に割り当てることができる。
【００１３】
一方、リード又はライト対象となったデータサイズが小さい場合には、相応に短時間のウェイト制御しか実行されない。したがって、ＵＳＢストレージドライバが、ＵＳＢホスト装置の処理能力をそれほど専有していないにもかかわらず、ＵＳＢストレージドライバの実行する処理が遅延させられることはない。
【００１４】
よって、以上のような制御を行えば、ＵＳＢホスト装置の処理能力が、過剰にＵＳＢストレージドライバに専有されてしまうこと、及びＵＳＢストレージドライバの実行する処理が過剰に遅延させられてしまうこと、双方を両立させて未然に防止することができる。
【００１５】
請求項２に記載のＵＳＢホスト装置は、請求項１に記載のＵＳＢホスト装置において、前記ＵＳＢストレージドライバは、前記ＵＳＢストレージデバイスから読取対象データを読み取る際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された読取対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記読取対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスから読み取るため、前記分割後の各データそれぞれを読取対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、各ＳＣＳＩコマンドに対する応答として前記ＵＳＢストレージデバイスから転送されて前記データバッファに格納されるデータを、前記データバッファから順次取得するデータ取得手段と、前記データ取得手段によって順次取得される前記分割後の各データをすべて取得したら、それら分割後の各データを一括して、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンドに対する応答として前記ＳＣＳＩドライバへと転送するデータ転送手段とを備え、前記ウェイト制御手段は、前記ＳＣＳＩコマンド発行手段により、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行する際に、前記ウェイト制御を実行することを特徴とする。
【００１６】
このように構成されたＵＳＢホスト装置によれば、ＵＳＢストレージデバイスに対し大量のデータリードを要求するＳＣＳＩリードコマンドがＵＳＢホスト装置内において発行されたとしても、ＵＳＢストレージドライバからＵＳＢストレージデバイスに対しては、大量のデータリードを要求するＳＣＳＩリードコマンドが発行されなくなる。したがって、安全に利用可能なデータバッファの容量を上回るデータがＵＳＢストレージデバイスから転送されてくるのを、未然に防ぐことができる。
【００１７】
また、分割された各ＳＣＳＩコマンドを発行するタイミングについては、ＵＳＢホスト装置側の処理能力に応じた都合のよいタイミングとすることができる。したがって、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスから転送されてくるデータを適切に受信することができる。
【００１８】
しかも、いくつかのＳＣＳＩコマンドそれぞれを、ＵＳＢストレージデバイスに対して順次発行する際には、上述のウェイト制御を実行する。したがって、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、その処理能力がＵＳＢストレージデバイスに対する処理ばかりに専有されてしまうのを、未然に防ぐことができる。
【００１９】
請求項３に記載のＵＳＢホスト装置は、請求項１に記載のＵＳＢホスト装置において、前記ＵＳＢストレージドライバは、前記ＵＳＢストレージデバイスへ書込対象データを書き込む際に前記ＳＣＳＩドライバから発行されるＳＣＳＩコマンドを取得するＳＣＳＩコマンド取得手段と、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンド内のパラメータで指定された書込対象データのサイズが、前記ＵＳＢホストコントローラが備えるデータバッファに格納可能なサイズよりも大きい場合に、前記書込対象データをいくつかのデータに分割することで、分割後の各データのサイズを前記データバッファに格納可能なサイズとした上で、前記分割後の各データを前記ＵＳＢストレージデバイスへ書き込むため、前記分割後の各データそれぞれを書込対象として指定するパラメータが設定されたいくつかのＳＣＳＩコマンドを生成するＳＣＳＩコマンド生成手段と、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行するＳＣＳＩコマンド発行手段と、前記ＳＣＳＩコマンド発行手段によって前記いくつかのＳＣＳＩコマンドそれぞれを発行するごとに、前記ＵＳＢストレージデバイスから返される応答を、順次取得する応答取得手段と、前記応答取得手段によって順次取得される前記応答をすべて取得したら、前記ＳＣＳＩコマンド取得手段によって取得された前記ＳＣＳＩコマンドに対する応答を返す応答発行手段とを備え、前記ウェイト制御手段は、前記ＳＣＳＩコマンド発行手段により、前記ＳＣＳＩコマンド生成手段によって生成される前記いくつかのＳＣＳＩコマンドそれぞれを、前記ＵＳＢストレージデバイスに対して順次発行する際に、前記ウェイト制御を実行することを特徴とする。
【００２０】
このように構成されたＵＳＢホスト装置によれば、ＵＳＢストレージデバイスに対し大量のデータライトを要求するＳＣＳＩライトコマンドがＵＳＢホスト装置内において発行されたとしても、ＵＳＢストレージドライバからＵＳＢストレージデバイスに対しては、大量のデータライトを要求するＳＣＳＩライトコマンドが発行されなくなる。したがって、安全に利用可能なデータバッファの容量を上回るデータをＵＳＢストレージデバイスへ転送してしまうのを、未然に防ぐことができる。
【００２１】
また、分割された各ＳＣＳＩコマンドを発行するタイミングについては、ＵＳＢホスト装置側の処理能力に応じた都合のよいタイミングとすることができる。したがって、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、ＵＳＢストレージデバイスへ転送するデータを適切に送信することができる。
【００２２】
しかも、いくつかのＳＣＳＩコマンドそれぞれを、ＵＳＢストレージデバイスに対して順次発行する際には、上述のウェイト制御を実行する。したがって、ＵＳＢホスト装置側のデータ処理能力に十分な余力がない場合でも、その処理能力がＵＳＢストレージデバイスに対する処理ばかりに専有されてしまうのを、未然に防ぐことができる。
【００２３】
請求項４に記載のＵＳＢホスト装置は、請求項２又は請求項３に記載のＵＳＢホスト装置において、前記データバッファに格納可能なデータのサイズに関する情報を、複数の異なる前記ＵＳＢホストコントローラそれぞれに対応づけて記憶するＵＳＢホストコントローラ情報記憶手段を備え、前記ＳＣＳＩコマンド生成手段は、前記ＵＳＢホストコントローラ情報記憶手段に記憶された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定することを特徴とする。
【００２４】
このように構成されたＵＳＢホスト装置によれば、複数の異なるＵＳＢホストコントローラそれぞれで、データバッファに格納可能なデータのサイズが異なっていても、それに応じて読取対象データがより適切な分割数に分割されることになる。
【００２５】
したがって、比較的大きなデータバッファを備えるＵＳＢホストコントローラであるにもかかわらず、データの分割数が過剰に多くなるようなことはない。また、比較的小さなデータバッファを備えるＵＳＢホストコントローラであるにもかかわらず、データの分割数が過剰に少なくなるようなこともない。
【００２６】
請求項５に記載のＵＳＢホスト装置は、請求項２〜請求項４のいずれか一項に記載のＵＳＢホスト装置において、前記ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に関する情報を取得するデバイス数情報取得手段を備え、前記ＳＣＳＩコマンド生成手段は、前記デバイス数情報取得手段によって取得された情報に基づいて、前記データバッファに格納可能なデータのサイズを決定することを特徴とする。
【００２７】
このように構成されたＵＳＢホスト装置によれば、ＵＳＢホストコントローラの制御下に存在するＵＳＢデバイスの数に基づいて、データバッファに格納可能なデータのサイズが決定される。
【００２８】
したがって、同じＵＳＢホストコントローラの制御下で、様々なＵＳＢデバイスがそれぞれデータバッファを利用している場合でも、そのようなＵＳＢデバイスの数を動的に把握できる。そして、そのＵＳＢデバイス数に応じてリード／ライトの対象となるデータをより適切な分割数に分割することができる。
【００２９】
請求項６に記載のプログラムは、ＵＳＢデバイスと通信可能で、ＵＳＢストレージデバイスに対するリード又はライトを行う際には、ＳＣＳＩドライバ、ＵＳＢストレージドライバ、及びＵＳＢホストコントローラが協働して前記ＵＳＢストレージデバイスに対する制御を行うＵＳＢホスト装置において、前記ＵＳＢホスト装置が備えるコンピュータを前記ＵＳＢストレージドライバとして機能させるためのプログラムであって、前記コンピュータを、前記ＵＳＢストレージドライバが、前記ＵＳＢストレージデバイスに対し、複数回にわたってＳＣＳＩコマンドを発行して、各ＳＣＳＩコマンドに対応するリード又はライトを行う際に、先に発行されたＳＣＳＩコマンドに対応するリード又はライトが完了した後、次のＳＣＳＩコマンドを発行する前に、前記先に発行されたＳＣＳＩコマンド内のパラメータで指定されたデータのサイズに応じて待機時間を決定するとともに、当該待機時間分のウェイト制御を実行するウェイト制御手段として機能させることを特徴とする。
【００３０】
このように構成されたプログラムによれば、ＵＳＢホスト装置が備えるコンピュータを上述した通りのＵＳＢストレージドライバとして機能させ、これにより、このＵＳＢホスト装置では、請求項１に記載した通りの各手段が機能することになる。
【００３１】
したがって、このようなＵＳＢホスト装置であれば、処理能力が過剰にＵＳＢストレージドライバに専有されてしまうこと、及びＵＳＢストレージドライバの実行する処理が過剰に遅延させられてしまうこと、双方を両立させて未然に防止することができる。
【００３２】
なお、請求項６に記載のプログラムは、ＵＳＢホスト装置が備えるコンピュータを、さらに請求項２〜請求項５のいずれか一項に記載の各手段として機能させるプログラムとして構成されていてもよいことはもちろんである。
【図面の簡単な説明】
【００３３】
【図１】ＵＳＢホスト装置を中心に構成されたシステムを示すブロック図。
【図２】ＵＳＢホスト装置内のデータ伝送経路を示すブロック図。
【図３】ＳＣＳＩコマンド処理のフローチャート。
【図４】安全セクタ数取得処理のフローチャート。
【図５】（ａ）はＵＳＢデバイス接続検出処理のフローチャート、（ｂ）はＵＳＢデバイス切断検出処理のフローチャート。
【図６】リード／ライトコマンド分割処理のフローチャート。
【発明を実施するための形態】
【００３４】
次に、本発明の実施形態について一例を挙げて説明する。
［装置の構成］
図１に示すＵＳＢホスト装置１は、制御部２、補助記憶部３、ＵＳＢインターフェース４、その他の入出力インターフェース５などを備えている。ＵＳＢインターフェース４には、ＵＳＢハブ６を介して、ＵＳＢストレージデバイス７やＵＳＢハンドセット８が接続されている。その他の入出力インターフェース５は、具体的には、ＬＡＮインターフェース、ディスプレイインターフェース、キーボードインターフェース等である。これら各インターフェースには、各インターフェースに対応したその他のデバイス類９（ＬＡＮ、ディスプレイ、キーボードなど）が接続されている。
【００３５】
制御部２は、周知のＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３などを備えてなるマイクロコンピュータによって構成されている。また、補助記憶部３は、ハードディスク装置や不揮発性メモリなどのストレージデバイスによって構成されている。
【００３６】
補助記憶部３には、ディスクデバイスドライバ１５、ＵＳＢホストコントローラドライバ１６、ＵＳＢマスストレージクラスドライバ１７、及びＵＳＢハンドセットドライバ１８に対応するプログラムが格納されている。
【００３７】
これらのプログラムは、ＵＳＢホスト装置１の起動時に、補助記憶部３から制御部２が備えるＲＡＭ１３にロードされ、以降、ＣＰＵ１１がＲＡＭ１３上のプログラムに基づく処理を実行する。これにより、ＵＳＢホスト装置１では、ディスクデバイスドライバ１５、ＵＳＢホストコントローラドライバ１６、ＵＳＢマスストレージクラスドライバ１７、及びＵＳＢハンドセットドライバ１８が機能する状態になる。
【００３８】
ＵＳＢインターフェース４は、ＵＳＢホストコントローラ１９を中心に構成されている。このＵＳＢホストコントローラ１９は、ＰＣＩバスインターフェース、アービター、ＯＨＣＩ（Open Host Controller Interface）ホストコントローラ、ＥＨＣＩ（Enhanced Host Controller Interface）ホストコントローラ、ルートハブ、ＵＳＢ物理層などが１チップ上に集積されたハードウェアである。
【００３９】
さらに、ＵＳＢホスト装置１では、図２に示すように、ＵＳＢプロトコルスタック２１などのソフトウェアが機能している。そして、このＵＳＢプロトコルスタック２１経由で、ＵＳＢマスストレージクラスドライバ１７やＵＳＢハンドセットドライバ１８などのＵＳＢ系ドライバが、ＵＳＢデバイスへのアクセスを行う仕組みになっている。
【００４０】
これらＵＳＢマスストレージクラスドライバ１７、ＵＳＢハンドセットドライバ１８、ＵＳＢホストコントローラ１９、及びＵＳＢプロトコルスタック２１は、それぞれがデータ格納用のバッファ１７Ａ，１８Ａ，１９Ａ，２１Ａを備えている。
【００４１】
ここで、ＵＳＢホスト装置１内でアプリケーションソフトウェアが機能し、その処理の中でＵＳＢストレージデバイス７に対するデータのリード又はライトが行われる場合、ＵＳＢマスストレージクラスドライバ１７には、リード要求又はライト要求が伝達される。
【００４２】
このリード要求又はライト要求は、ＵＳＢホスト装置１のＯＳ（Operating System）が備えるファイルシステム経由で、アプリケーションソフトウェアから伝達されるものである。
【００４３】
ファイルシステムは、アプリケーションソフトウェアの発行するリード要求又はライト要求を、セクタ単位でＵＳＢストレージデバイス７にアクセスするためのＳＣＳＩコマンドに変換する。そして、そのＳＣＳＩコマンドをＵＳＢマスストレージクラスドライバ１７に伝達する。
【００４４】
このＳＣＳＩコマンドを受けたＵＳＢマスストレージクラスドライバ１７は、ＳＣＳＩコマンドをＵＳＢプロトコルに準拠した方式で送信するため、必要な情報をＳＣＳＩコマンドに付加した上で、そのＳＣＳＩコマンドをＵＳＢプロトコルスタック２１に渡す。なお、本実施形態においては、ＳＣＳＩコマンドを解析して、必要があればＳＣＳＩコマンドの分割を行うが、その詳細については後述する。
【００４５】
ＵＳＢプロトコルスタック２１に渡されたＳＣＳＩコマンドは、ＵＳＢホストコントローラ１９経由でＵＳＢストレージデバイス７へと伝送される。その結果、このＳＣＳＩコマンドを受けたＵＳＢストレージデバイス７とＵＳＢホスト装置１との間で、リード要求又はライト要求に対応するデータが転送されることになる。
【００４６】
［ＵＳＢストレージデバイスに対するリード／ライト処理］
次に、ファイルシステム側のＳＣＳＩドライバから発行されるＳＣＳＩコマンドがＵＳＢマスストレージクラスドライバ１７に伝達されたときに、ＵＳＢマスストレージクラスドライバ１７が実行する処理について、図３〜図６のフローチャートに基づいて説明する。
【００４７】
この処理を開始すると、ＵＳＢマスストレージクラスドライバ１７としての処理を実行するＣＰＵ１１（以下、単にＣＰＵ１１と称する。）は、まず、ＵＳＢマスストレージクラスドライバ１７に伝達されたＳＣＳＩコマンドが、ＳＣＳＩリード／ライトコマンドか否かを判断する（Ｓ１０１）。
【００４８】
ここで、ＳＣＳＩリードコマンド又はＳＣＳＩライトコマンドのいずれかであった場合（Ｓ１０１：はい）、ＣＰＵ１１は、１コマンド当たりの最大セクタ数を仮決定する（Ｓ１０３）。本実施形態の場合、仮決定される最大セクタ数としては固定値＝１６が用いられ、Ｓ１０３では固定値＝１６が変数ｍに代入される。
【００４９】
そして、ＣＰＵ１１は、１コマンド当たりの安全セクタ数を取得する処理を実行する（Ｓ１０５）。このＳ１０５の具体的な処理内容は、様々なものを考え得るが、本実施形態では、図４に示すような処理を実行する。
【００５０】
すなわち、図４に示す処理を開始すると、ＣＰＵ１１は、まず、「ＵＳＢストレージデバイス７が接続されているＵＳＢホストコントローラ１９」のドライバ（ＵＳＢホストコントローラドライバ１６）からプラグアンドプレイＩＤを取得する（Ｓ２０１）。Ｓ２０１で取得するプラグアンドプレイＩＤは、ＵＳＢホストコントローラ１９の製造者及び形式を一意に特定可能な識別子である。
【００５１】
続いて、ＣＰＵ１１は、取得したプラグアンドプレイＩＤをテーブルから検索する（Ｓ２０３）。ＵＳＢホスト装置１には、Ｓ２０１で取得する可能性のあるプラグアンドプレイＩＤと、そのプラグアンドプレイＩＤに対応するＵＳＢホストコントローラのパケットバッファ数との対応関係が、あらかじめテーブル化されて記憶されている（下記表１参照。）。Ｓ２０３では、Ｓ２０１で取得したプラグアンドプレイＩＤを、表１に示すようなテーブル内からサーチする。
【００５２】
【表１】
2012073663.tif 000003
そして、ＣＰＵ１１は、テーブル上にＵＳＢホストコントローラ１９の情報が見つかった否かを判断し（Ｓ２０５）、見つかった場合には（Ｓ２０５：はい）、テーブルから取得した値（Ｑ）を以降の演算で使用する（Ｓ２０７）。
【００５３】
一方、Ｓ２０５において、テーブル上からＵＳＢホストコントローラ１９の情報が見つからなかった場合（Ｓ２０５：いいえ）、ＣＰＵ１１は、デフォルト値を以降の演算で使用する。このデフォルト値は、利用される可能性のあるＵＳＢホストコントローラのうち、性能が比較的低いものを想定してあらかじめ取り決められている値であり、例えば、Ｑ＝３２などの固定値が使用される。
【００５４】
続いて、ＣＰＵ１１は、「ＵＳＢストレージデバイスが接続されているＵＳＢホストコントローラ」に接続されているＵＳＢデバイス数を、変数Ｐに代入する（Ｓ２１１）。そして、変数Ｐ，Ｑの値に基づいて、Ｑ÷（Ｐ＋１）の演算結果を変数ｋに代入する（Ｓ２１３）。なお、Ｓ２１３において、変数ｋが０となるときは、変数ｋの値を１に補正する。そして、この変数ｋの値をリターン値として上位手段（図４に示す処理を呼び出した処理手段）へと返し、図４に示す処理を終了する。
【００５５】
このようにして安全セクタ数ｋを決定すれば、例えば、ＵＳＢデバイス数が１のときは、全パケットバッファの１／２がひとつのＵＳＢストレージデバイスに利用される。また、ＵＳＢデバイス数が２のときは、全パケットバッファの１／３がひとつのＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が３のときは、全パケットバッファの１／４がひとつのＵＳＢストレージデバイスに利用される。つまり、ＵＳＢデバイス数Ｐに応じて、全パケットバッファの１／（Ｐ＋１）が、Ｐ個のＵＳＢデバイスのうちの、各ＵＳＢストレージデバイスに利用されることになる。
【００５６】
したがって、この場合、仮に全ＵＳＢデバイスがＵＳＢストレージデバイスであっても、ＵＳＢデバイス数が１のときは、全パケットバッファの１／２が全ＵＳＢストレージデバイスに利用される。また、ＵＳＢデバイス数が２のときは、全パケットバッファの２／３が全ＵＳＢストレージデバイスに利用され、ＵＳＢデバイス数が３のときは、全パケットバッファの３／４が全ＵＳＢストレージデバイスに利用される。
【００５７】
よって、ＵＳＢストレージデバイス数Ｐのときにも、全パケットバッファは、１／（Ｐ＋１）の割合で、各ＵＳＢストレージデバイスに利用されることになるので、いくらか余裕が残る状態でバッファが利用されることになる。
【００５８】
ちなみに、Ｓ２１１で変数Ｐに代入されるＵＳＢデバイス数は、ＵＳＢデバイスの接続・切断に応じて、図５（ａ）及び同図（ｂ）に示すような処理により、動的に変更される値である。
【００５９】
すなわち、プラグアンドプレイ機能により、ＵＳＢデバイスの接続が検出された場合には、図５（ａ）に示す処理が実行され、この場合、ＣＰＵ１１は、接続を検出したＵＳＢデバイスが接続しているＵＳＢホストアダプタのＵＳＢデバイス数をカウントアップし（Ｓ３０１）、以下、通常のＵＳＢデバイス接続処理を実行する（Ｓ３０３）。なお、Ｓ３０３で行われる処理の詳細は、ＵＳＢデバイスにおける一般的な処理に過ぎないので、ここでの説明は省略する。
【００６０】
また、プラグアンドプレイ機能により、ＵＳＢデバイスの切断が検出された場合には、図５（ｂ）に示す処理が実行され、この場合、ＣＰＵ１１は、切断を検出したＵＳＢデバイスが接続していたＵＳＢホストアダプタのＵＳＢデバイス数をカウントダウンし（Ｓ４０１）、以下、通常のＵＳＢデバイス切断処理を実行する（Ｓ４０３）。なお、Ｓ４０３で行われる処理の詳細も、ＵＳＢデバイスにおける一般的な処理に過ぎないので、ここでの説明は省略する。
【００６１】
さて、図４に示す処理を終了すると図３に示すＳ１０５を終えたことになるので、続いて、ＣＰＵ１１は、Ｓ１０３で仮決定した最大セクタ数ｍが安全か否か（すなわち、安全セクタ数ｋ以下か否か）を判断する（Ｓ１０７）。
【００６２】
ここで、仮決定した最大セクタ数ｍが危険（すなわち、安全セクタ数ｋより大）である場合（Ｓ１０７：いいえ）、ＣＰＵ１１は、安全セクタ数ｋを変数ｍに代入することにより、最大セクタ数ｍを補正して（Ｓ１０９）、Ｓ１１１へと進む。一方、仮決定した最大セクタ数ｍが安全（すなわち、安全セクタ数ｋ以下）である場合（Ｓ１０７：はい）、ＣＰＵ１１は、Ｓ１０９を実行することなく、Ｓ１１１へと進む。
【００６３】
そして、このようにして最大セクタ数ｍが確定したら、ＣＰＵ１１は、リード／ライトのセクタ数が最大セクタ数ｍを超えているか否かを判断する（Ｓ１１１）。ここで、リード／ライトのセクタ数が最大セクタ数ｍを超えていれば（Ｓ１１１：超えている）、そのままリード／ライトコマンドを発行すると、最大セクタ数ｍを超えるデータがＵＳＢストレージデバイス７との間で転送されるおそれがある。そこで、ＣＰＵ１１は、ＳＣＳＩリード／ライトコマンドの分割を実行する（Ｓ１１３）。
【００６４】
このＳ１１３は、詳しくは図６に示すような処理となる。すなわち、この処理を開始すると、ＣＰＵ１１は、まず、リード／ライトの開始位置となる先頭セクタ番号を変数Ｔに代入し、リード／ライトセクタ数を変数ｎに代入する（Ｓ５０１）。
【００６５】
そして、ＣＰＵ１１は、変数ｎ，ｍについて、ｎ≦ｍか否かを判断する（Ｓ５０３）。ここで、Ｓ１１１ではｎ＞ｍが成立したからこそ図６に示す処理に移行しているので、少なくとも初回はｎ≦ｍではないと判断されることになる（Ｓ５０３：いいえ）。この場合、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｍセクタのリード／ライトを行うためのＳＣＳＩコマンドを発行する（Ｓ５０７）。
【００６６】
すなわち、Ｓ５０７では、基となったＳＣＳＩコマンド（図３に示す処理を開始する契機となったＳＣＳＩコマンド）で要求されたセクタ数ｎではなく、Ｓ１０３〜Ｓ１０９を経て確定した最大セクタ数ｍのリード／ライトを行うＳＣＳＩコマンドを発行する。
【００６７】
なお、Ｓ５０７で発行するＳＣＳＩリードコマンドは、ＵＳＢプロトコルスタック２１経由でＵＳＢストレージデバイス７にＳＣＳＩコマンドを伝達するためのコマンドである。より具体的には、最大セクタ数ｍのＳＣＳＩリードコマンドに対し、ＵＳＢ規格に準拠したヘッダを付加したものである。
【００６８】
このようなＳＣＳＩコマンドにより、ＵＳＢストレージデバイス７にＳＣＳＩコマンドが伝達されると、ＵＳＢストレージデバイス７との間で最大セクタ数ｍのデータ転送が行われる。その際、転送されるデータは、ＵＳＢホストコントローラ１９のバッファ１９Ａなどを経由して転送されるが、そのデータ量は最大セクタ数ｍに抑えられることになるので、バッファ１９Ａなどの容量不足に起因してデータの損失が起こることはない。
【００６９】
さて、Ｓ５０７を終えたら、ＣＰＵ１１は、変数Ｔ，ｍの値に基づき、Ｔ＋ｍの演算結果を新たに変数Ｔに代入し、変数ｎ，ｍの値に基づき、ｎ−ｍの演算結果を新たに変数ｎに代入する（Ｓ５０９）。
【００７０】
そして、変数ｍの値に比例する長さの待機時間だけＷＡＩＴする（Ｓ５１１）。具体的には、Ｓ５１１では、変数ｍとあらかじめ取り決められた固定値とを乗算して積を求め、その値相当の待機時間が経過するまではＷＡＩＴ状態となるように、ウェイト制御を実行する。これにより、Ｓ５０７でのデータ転送量に応じた長さの待機時間だけ、Ｓ５１１で待機状態となり、その間にＣＰＵ１１は他の処理を実行することができる。
【００７１】
その後、待機時間が経過したら、Ｓ５０３へと戻る。以降、Ｓ５０３においてｎ≦ｍではないと判断される間は、Ｓ５０３〜Ｓ５１１を繰り返し、ＵＳＢストレージデバイス７との間で最大セクタ数ｍのデータ転送が繰り返されることになる。
【００７２】
そして、Ｓ５０３において、ｎ≦ｍであると判断された場合（Ｓ５０３：はい）、ＣＰＵ１１は、ＵＳＢプロトコルに準拠した方式にて、セクタＴからｎセクタのリード／ライトを行うためのＳＣＳＩコマンドを発行する（Ｓ５１３）。これにより、ＵＳＢストレージデバイス７との間でセクタ数ｎのデータが転送され、その結果、所期のセクタ数分のデータ転送が完了し、図６に示す処理を終了する。図６に示す処理を終了すると、図３に示すＳ１１３を終えることになるので、図３に示す処理全体を終了する。
【００７３】
なお、図３に示す処理のうち、Ｓ１０１において、ＳＣＳＩリード／ライトコマンドではないと判断された場合（Ｓ１０１：いいえ）、上記のようなリード／ライトコマンドの分割処理は不要となる。また、Ｓ１１１において、リード／ライトのセクタ数が最大セクタ数を超えていないと判断されたら（Ｓ１１１：超えていない）、上記のようなリード／ライトコマンドの分割処理は不要となる。
【００７４】
したがって、これらの場合、ＣＰＵ１１は、従来通りのＳＣＳＩコマンド処理を実行し（Ｓ１１５）、図３に示す処理を終了する。ちなみに、従来通りのＳＣＳＩコマンド処理とは、ＳＣＳＩコマンドに対し、ＵＳＢ規格に準拠したヘッダを付加して、そのＳＣＳＩコマンドを発行する処理のことである。このような処理により、ＵＳＢプロトコルスタック２１経由でＵＳＢストレージデバイス７にＳＣＳＩコマンドが伝達されることになる。
【００７５】
［効果］
以上説明したように、上記ＵＳＢホスト装置１によれば、Ｓ５０７，Ｓ５１３の各ステップが到来するたびにＳＣＳＩコマンドを発行するものの、その際に、バッファ１９Ａ内で使用可能な容量を上回るデータがＵＳＢストレージデバイス７との間で転送されることはない。
【００７６】
しかも、分割されたデータを複数回にわたって転送する際には、Ｓ５０７でのデータ転送量に応じた長さの待機時間だけ、Ｓ５１１で待機状態となる。したがって、データ転送量が多い場合ほど、より長時間にわたって待機状態となり、待機状態となっている間に、ＣＰＵ１１は他の処理を実行することができる。
【００７７】
すなわち、リード又はライト対象となったデータサイズが大きい場合には、ＵＳＢストレージデバイス７との通信で、ＵＳＢホスト装置１（ＣＰＵ１１）の処理能力を相応に専有することになるものの、その場合には、相応に長時間のウェイト制御が実行される。したがって、ウェイト制御が実行されている間には、ＵＳＢホスト装置１の処理能力を、他の処理に割り当てることができる。
【００７８】
一方、リード又はライト対象となったデータサイズが小さい場合には、相応に短時間のウェイト制御しか実行されない。したがって、ＵＳＢストレージデバイス７との通信で、ＵＳＢホスト装置１の処理能力をそれほど専有していないにもかかわらず、ＵＳＢストレージデバイス７に対する処理が遅延させられることはない。
【００７９】
よって、以上のような処理を行えば、ＵＳＢホスト装置１の処理能力が、過剰にＵＳＢマスストレージクラスドライバ１７に専有されてしまうこと、及びＵＳＢマスストレージクラスドライバ１７の実行する処理が過剰に遅延させられてしまうこと、双方を両立させて未然に防止することができる。
【００８０】
ちなみに、仮にＵＳＢホスト装置１側のデータ処理能力に十分な余力があるとすれば、上述のようなウェイト制御を行わなくても済むが、その場合は、ＣＰＵ１１に高度な処理能力が要求されることになる。そのため、その分だけＵＳＢホスト装置１を高性能化する必要があり、ＵＳＢホスト装置１にかかるコストが増大することになる。
【００８１】
この点、上記実施形態のような構成を採用すれば、ＣＰＵ１１に高度な処理能力は要求されないので、ＵＳＢホスト装置１を過度に高性能にしなくても済み、ＵＳＢホスト装置１にかかるコストを低減することができる。
【００８２】
しかも、このような機能を実現するに当たって、バッファ１９Ａ内で使用可能な容量を上回るような大量のデータのリード／ライトを要求するＳＣＳＩコマンドがＵＳＢホスト装置１内において発行されること自体は許容しているので、アプリケーションソフトウェアの改修は不要である。
【００８３】
また、ＵＳＢプロトコルスタック２１についても、何ら変更を加える必要はないので、すでに信頼性が高く、高度な処理を行っているＵＳＢプロトコルスタック２１について、不用意な改修を加えなくても済み、ＵＳＢホスト装置１の信頼性をいたずらに低下させてしまうことがない。
【００８４】
加えて、ＵＳＢプロトコルスタック２１でデータ転送を制限すると、ＵＳＢ音声デバイスなどのデータ転送で問題が生じる可能性があるが、上記実施形態であれば、そのような問題もない。
【００８５】
より詳しくは、ＵＳＢプロトコルスタック２１は、上記のようなＵＳＢストレージデバイス７の他、ＵＳＢハンドセット８のような音声デバイスにも利用されるソフトウェアである。
【００８６】
この種のＵＳＢ音声デバイスの場合、データ処理が間に合わなければ、一部の音声データを破棄して、後から到来する新しいデータの受け取りを優先することで、多少の音飛びが発生してもリアルタイム性が損なわれないようにしている。
【００８７】
そのため、ＣＰＵ１１の処理性能が低い状態にある場合に、ＵＳＢプロトコルスタック２１でデータ転送を制限すると、データ損失を防止できるとしても、新しいデータの受け取りで遅れが生じ、リアルタイム性が損なわれてしまうという問題が起こる。
【００８８】
この点、上記実施形態では、ＵＳＢプロトコルスタック２１の構成を変えることなく対処しているので、ＵＳＢハンドセット８のような音声デバイスに対し、悪影響を及ぼしてしまうおそれがない。
【００８９】
［変形例等］
以上、本発明の実施形態について説明したが、本発明は上記の具体的な一実施形態に限定されず、この他にも種々の形態で実施することができる。
【００９０】
例えば、上記実施形態では、大量のデータを複数に分割して複数回にわたってデータ転送を行う際に、１回のデータの転送を行うたびにウェイト制御を行っていたが、２回以上のデータ転送を行うたびにウェイト制御を行ってもよい。すなわち、データ転送を何回行うごとにウェイト制御を入れるかは、ＵＳＢホスト装置１（ＣＰＵ１１）の処理性能を考慮して任意に決めればよい。
【００９１】
また、上記実施形態では、ひとつのＳＣＳＩコマンドをＵＳＢマスストレージクラスドライバ１７において複数のＳＣＳＩコマンドに分割して発行する際に、上記ウェイト制御を行う事例を示したが、複数のＳＣＳＩコマンドがＵＳＢマスストレージクラスドライバ１７に繰り返し渡される場合に、上記のようなウェイト制御を実行してもよい。
【符号の説明】
【００９２】
１・・・ＵＳＢホスト装置、２・・・制御部、３・・・補助記憶部、４・・・ＵＳＢインターフェース、５・・・その他の入出力インターフェース、６・・・ＵＳＢハブ、７・・・ＵＳＢストレージデバイス、８・・・ＵＳＢハンドセット、９・・・その他のデバイス類、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１５・・・ディスクデバイスドライバ、１６・・・ＵＳＢホストコントローラドライバ、１７・・・ＵＳＢマスストレージクラスドライバ、１８・・・ＵＳＢハンドセットドライバ、１９・・・ＵＳＢホストコントローラ、２１・・・ＵＳＢプロトコルスタック、１７Ａ，１８Ａ，１９Ａ，２１Ａ・・・バッファ。
【図１】
2012073663.tif 000004
【図２】
2012073663.tif 000005
【図３】
2012073663.tif 000006
【図４】
2012073663.tif 000007
【図５】
2012073663.tif 000008
【図６】
2012073663.tif 000009