JP3598922B2

JP3598922B2 - Data transfer control device, information storage medium, and electronic device

Info

Publication number: JP3598922B2
Application number: JP36110299A
Authority: JP
Inventors: 浩輔松永; 裕之金井; 信一郎藤田
Original assignee: Seiko Epson Corp
Current assignee: Seiko Epson Corp
Priority date: 1999-12-20
Filing date: 1999-12-20
Publication date: 2004-12-08
Anticipated expiration: 2019-12-20
Also published as: JP2001177536A

Description

【０００１】
【発明の属する技術分野】
本発明は、データ転送制御装置、情報記憶媒体及び電子機器に関し、特に、バスに接続される複数のノード間でＩＥＥＥ１３９４などの規格に準じたデータ転送を行うためのデータ転送制御装置、情報記憶媒体及び電子機器に関する。
【０００２】
【背景技術及び発明が解決しようとする課題】
近年、ＩＥＥＥ１３９４と呼ばれるインターフェース規格が脚光を浴びている。このＩＥＥＥ１３９４は、次世代のマルチメディアにも対応可能な高速シリアルバスインターフェースを規格化したものである。このＩＥＥＥ１３９４によれば、動画像などのリアルタイム性が要求されるデータも扱うことができる。また、ＩＥＥＥ１３９４のバスには、プリンタ、スキャナ、ＣＤ−ＲＷドライブ、ハードディスクドライブなどのコンピュータの周辺機器のみならず、ビデオカメラ、ＶＴＲ、ＴＶなどの家庭用電化製品も接続できる。このため、電子機器のデジタル化を飛躍的に促進できるものとして期待されている。
【０００３】
さて、このＩＥＥＥ１３９４においては、バスに電子機器が新たに接続されたり、バスから電子機器が取り外されたりして、バスに接続されるノードが増減すると、いわゆるバスリセットが発生する。そしてバスリセットが発生するとノードのトポロジ情報がクリアされ、その後、トポロジ情報が自動的に再設定される。即ち、バスリセットの発生後、ツリー識別（ルートノードの決定）、自己識別が行われ、その後、アイソクロナスリソースマネージャ等の管理ノードが決定される。そして通常のパケット転送が再開される。
【０００４】
このようにＩＥＥＥ１３９４では、バスリセット後にトポロジ情報が自動的に再設定されるため、いわゆるホット状態でのケーブルの抜き差し（ホットプラグ）が可能となる。このため、一般ユーザは、ＶＴＲなどの通常の家庭用電化製品と同じように、電子機器へのケーブルの抜き差を自由にできるようになり、いわゆるホームネットワークシステムの普及に役立つことができる。
【０００５】
しかしながら、ＩＥＥＥ１３９４のバスに接続されたプリンタやスキャナなどのデバイスにおいて、このバスリセットの発生が要因となって以下のような問題が生じることが判明した。
【０００６】
即ち、ＩＥＥＥ１３９４のバス上で印刷データの転送中にバスリセットが発生すると、パーソナルコンピュータなどのイニシエータは、印刷データの転送を最初から再度やり直す。従って、ターゲットであるプリンタに対して、印刷データの一部分だけが二重に送られてしまい、二重印刷などの誤印刷の問題が生じる。
【０００７】
また、スキャナでは、一旦ヘッドが動き出すと、ヘッドを元に戻して再度同じデータを取得することはできない。従って、バスリセットの発生後、イニシエータがデータ転送を最初から再度やり直そうとしても、データ転送を継続することができないという問題がある。
【０００８】
なお、バスリセットの発生により生じる不具合を解決する従来技術として、例えば特開平１１−１９４９０２号公報に開示されるものがある。この従来技術では、バスリセットが発生すると、データ処理をホールドし、ネットワーク構成が再構築された後にデータ処理を再開する。
【０００９】
しかしながら、この従来技術では、バスリセット発生後に転送データを単に再送するだけであり、再送される転送データがバスリセット発生前の転送データの続きか否かの判断については行っていない。従って、この従来技術によっては二重印刷の問題を解決できない。
【００１０】
本発明は、以上のような技術的課題に鑑みてなされたものであり、その目的とするところは、ノードのトポロジ情報をクリアするリセットが発生した場合に生じる不具合を解消できるデータ転送制御装置、情報記憶媒体及び電子機器を提供することにある。
【００１１】
【課題を解決するための手段】
上記課題を解決するために本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、相手ノードとの間で転送される転送データの先頭アドレスである第１のアドレスを記憶するアドレス記憶手段と、ノードのトポロジ情報をクリアするリセットが発生した場合に、前記アドレス記憶手段により記憶された前記第１のアドレスと、該リセットの発生後の転送データの先頭アドレスである第２のアドレスとを比較するアドレス比較手段と、前記第１、第２のアドレスが同一である場合には、リセット発生時点のデータ転送の続きからデータ転送を再開する再開手段とを含むことを特徴とする。
【００１２】
本発明によれば、転送データの先頭アドレスである第１のアドレスが記憶される。そして、ノードのトポロジ情報をクリアするリセットが発生した場合に、記憶された第１のアドレスと、リセットの発生後の転送データの先頭アドレスである第２のアドレスが比較される。そして、これらの第１、第２のアドレスが同一である場合には、リセット発生時点の続きから（例えばリセット発生時点で転送を完了したデータの次のデータから）、データ転送が再開されるようになる。
【００１３】
一方、第１、第２のアドレスが同一でない場合には、例えば、リセット発生後の転送データは新たな転送データであるとして処理されるようになる。
【００１４】
従って本発明によれば、相手ノードが、リセット発生後にリセット発生前と同一の転送データを送ってきた場合には、リセット発生時点の続きからデータ転送を再開できるようになる。従って、例えばデータ転送制御装置の上層のデバイスにデータが重複して転送されてしまい、上層のデバイスが誤動作するなどの問題を解消できる。
【００１５】
また本発明は、前記アドレス記憶手段が、転送データがページテーブルを用いて転送される場合において、ページテーブルの中の先頭セグメントに格納されるアドレスを前記第１のアドレスとして、ページテーブルの記憶領域とは別の領域に記憶しておくことを特徴とする。このようにすれば、ページテーブル記憶領域へのデータの上書きにより転送データの先頭アドレスである第１のアドレスが消失してしまうという不具合を防止できる。
【００１６】
また本発明は、ノードのトポロジ情報をクリアするリセットの発生前に相手ノードから転送されてきたデータ転送オペレーション要求のための第１のコマンドパケットの内容と、該リセットの発生後に相手ノードから転送されてきたデータ転送オペレーション要求のための第２のコマンドパケットの内容とを、前記第１、第２のアドレスの比較処理に先立って比較するコマンド比較手段を含むことを特徴とする。このようにすれば、例えば、第１、第２のコマンドパケットの内容が同一である場合に、第１、第２のアドレスの比較処理を行わなくて済むようになり、処理負荷の軽減化を図れる。
【００１７】
また本発明は、前記第１、第２のコマンドパケットが、コマンドパケットを識別するための識別情報を含み、前記コマンド比較手段が、前記第１、第２のアドレスの比較処理に先立って、第１のコマンドパケットに含まれる第１の識別情報と、第２のコマンドパケットに含まれる第２の識別情報とを比較することを特徴とする。このようにすれば、リセット発生時点の続きからデータ転送を再開するか否かを、コマンドパケットが含む識別情報に基づいて判断できるようになり、処理の簡素化を図れる。
【００１８】
また本発明は、データ転送完了のステータスを相手ノードに転送したが、ノードのトポロジ情報をクリアするリセットの発生が要因となって相手ノードからアクノリッジメントが返って来なかった場合に、データ転送不可状態に状態遷移することを特徴とする。このように、相手ノードからアクノリッジメントが返って来なかった場合には、相手ノードがステータスを受け取ったか否かが不明となる。従って、このような場合にリセット発生時点の続きからデータ転送を開始してしまうと、誤ったデータ転送が行われてしまう可能性がある。本発明によれば、ノードのトポロジ情報をクリアするリセットが要因となって相手ノードからアクノリッジメントが返って来なかった場合には、データ転送不可状態に状態遷移するため、このような誤ったデータ転送が行われる事態を防止できる。
【００１９】
また本発明は、バスに接続される複数のノード間でのデータ転送のためのデータ転送制御装置であって、相手ノードから転送されてくるデータ転送オペレーション要求のためのコマンドパケットが、コマンドパケットを識別するための識別情報を含む場合に、ノードのトポロジ情報をクリアするリセットの発生前に転送されてきた第１のコマンドパケットが含む第１の識別情報と、該リセットの発生後に転送されてきた第２のコマンドパケットが含む第２の識別情報とを比較するコマンド比較手段と、前記第１、第２の識別情報が同一である場合には、リセット発生時点のデータ転送の続きからデータ転送を再開する再開手段とを含むことを特徴とする。
【００２０】
本発明によれば、第１、第２の識別情報が同一である場合には、リセット発生時点の続きからデータ転送が再開されるようになる。一方、第１、第２のアドレスが同一でない場合には、例えば、リセット発生後の転送データは新たな転送データであるとして処理されるようになる。従って、データ転送制御装置の上層のデバイスにデータが重複して転送されてしまい、上層のデバイスが誤動作するなどの問題を解消できる。
【００２１】
また本発明は、データ転送完了のステータスを相手ノードに転送したが、ノードのトポロジ情報をクリアするリセットの発生が要因となって相手ノードからアクノリッジメントが返って来なかった場合に、相手ノードがデータ転送完了のステータスを受け取ったか否かを、コマンドパケットが含む識別情報に基づいて判断することを特徴とする。このようにすれば、相手ノードからステータスのアクノリッジメントが返って来なかった場合に、データ転送制御装置を、データ転送不可状態に状態遷移させなくても済むようになる。
【００２２】
なお本発明では、前記リセットが、ＩＥＥＥ１３９４の規格において定義されるバスリセットであることが望ましい。
【００２３】
また本発明は、上記のいずれかのデータ転送制御装置との間でのデータ転送を制御するためのプログラムを含む情報記憶媒体であって、ノードのトポロジ情報をクリアするリセットがデータ転送中に発生した場合には、該リセットの発生前の転送データの先頭アドレスである第１のアドレスと該リセットの発生後の転送データの先頭アドレスである第２のアドレスとが同一になるようにデータ転送オペレーション要求のためのコマンドパケットを作成し、データ転送制御装置に転送要求するためのプログラムを含むことを特徴とする。このようにすれば、データ転送制御装置は、第１、第２のアドレスが同一である場合には、リセット発生前と同一の転送データであると判断でき、第１、第２のアドレスが同一でない場合には、リセット発生前とは異なる転送データであると判断できる。これにより、誤ったデータ転送が行われる事態を防止できる。
【００２４】
また本発明は、上記のいずれかのデータ転送制御装置との間でのデータ転送を制御するためのプログラムを含む情報記憶媒体であって、データ転送オペレーション要求のためのコマンドパケットの所与のフィールドにコマンドパケットを識別するための識別情報を書き込み、識別情報が書き込まれたコマンドパケットをデータ転送制御装置に転送要求するためのプログラムを含むことを特徴とする。このようにすれば、データ転送制御装置は、第１、第２の識別情報が同一である場合には、リセット発生前と同一の転送データであると判断でき、第１、第２の識別情報が同一でない場合には、リセット発生前とは異なる転送データであると判断できる。これにより、誤ったデータ転送が行われる事態を防止できる。
【００２５】
また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードから受信したデータに所与の処理を施す装置と、処理が施されたデータを出力又は記憶するための装置とを含むことを特徴とする。また本発明に係る電子機器は、上記のいずれかのデータ転送制御装置と、前記データ転送制御装置及びバスを介して相手ノードに送信するデータに所与の処理を施す装置と、処理が施されるデータを取り込むための装置とを含むことを特徴とする。
【００２６】
本発明によれば、ノードのトポロジー情報をクリアするリセットの発生によりシステムに不具合が生じる事態を防止でき、電子機器が誤動作するのを防止できる。またデータ転送の高速化を図れ、電子機器の低コスト化、電子機器の処理の高速化なども図ることができる。
【００２７】
【発明の実施の形態】
以下、本発明の好適な実施形態について図面を用いて詳細に説明する。
【００２８】
１．ＩＥＥＥ１３９４
まず、ＩＥＥＥ１３９４について簡単に説明する。
【００２９】
１．１概要
ＩＥＥＥ１３９４（ＩＥＥＥ１３９４−１９９５、Ｐ１３９４．ａ）では１００〜４００Ｍｂｐｓの高速なデータ転送が可能となっている（Ｐ１３９４．ｂでは８００〜３２００Ｍｂｐｓ）。また、転送速度が異なるノードをバスに接続することも許される。
【００３０】
各ノードはツリー状に接続されており、１つのバスに最大で６３個のノードが接続可能になっている。なお、バスブリッジを利用すれば約６４０００個のノードを接続することも可能である。
【００３１】
ＩＥＥＥ１３９４では、パケットの転送方式として非同期転送とアイソクロナス転送が用意されている。ここで非同期転送は、信頼性が要求されるデータの転送に好適な転送方式であり、アイソクロナス転送は、リアルタイム性が要求される動画像や音声などのデータの転送に好適な転送方式である。
【００３２】
１．２層構造
ＩＥＥＥ１３９４の層構造（プロトコル構成）を図１に示す。
【００３３】
ＩＥＥＥ１３９４のプロトコルは、トランザクション層、リンク層、物理層により構成される。また、シリアルバスマネージメントは、トランザクション層、リンク層、物理層をモニターしたり制御したりするものであり、ノードの制御やバスのリソース管理のための種々の機能を提供する。
【００３４】
トランザクション層は、上位層にトランザクション単位のインターフェース（サービス）を提供し、下層のリンク層が提供するインターフェースを通して、リードトランザクション、ライトトランザクション、ロックトランザクション等のトランザクションを実施する。
【００３５】
ここで、リードトランザクションでは、応答ノードから要求ノードにデータが転送される。一方、ライトトランザクションでは、要求ノードから応答ノードにデータが転送される。またロックトランザクションでは、要求ノードから応答ノードにデータが転送され、応答ノードがそのデータに処理を施して要求ノードに返信する。
【００３６】
リンク層は、アドレッシング、データチェック、パケット送受信のためのデータフレーミング、アイソクロナス転送のためのサイクル制御などを提供する。
【００３７】
物理層は、リンク層により使用されるロジカルシンボルの電気信号への変換や、バスの調停や、バスの物理的インターフェースを提供する。
【００３８】
１．３ＳＢＰ−２
さて、図２に示すように、ＩＥＥＥ１３９４のトランザクション層の一部の機能を含む上位のプロトコルとして、ＳＢＰ−２（ＳｅｒｉａｌＢｕｓＰｒｏｔｏｃｏｌ−２）と呼ばれるプロトコルが提案されている。
【００３９】
ここでＳＢＰ−２は、ＳＣＳＩのコマンドセットをＩＥＥＥ１３９４のプロトコル上で利用可能にするために提案されたものである。このＳＢＰ−２を用いれば、既存のＳＣＳＩ規格の電子機器で使用されていたＳＣＳＩのコマンドセットに最小限の変更を加えて、ＩＥＥＥ１３９４規格の電子機器に使用できるようになる。従って、電子機器の設計や開発を容易化できる。また、ＳＣＳＩのコマンドだけではなく、デバイス固有のコマンドもカプセル化して利用できるため、非常に汎用性が高い。
【００４０】
図３に示すようにＳＢＰ−２では、まず、イニシエータ（例えばパーソナルコンピュータ）により作成されたログインＯＲＢ（ＯｐｅｒａｔｉｏｎＲｅｑｕｅｓｔＢｌｏｃｋ）を用いてログイン処理が行われる（ステップＴ１）。次に、ダミーＯＲＢを用いてフェッチエージェントの初期化が行われる（ステップＴ２）。そして、コマンドブロックＯＲＢ（ノーマルコマンドＯＲＢ）を用いてコマンド処理が行われ（ステップＴ３）、最後に、ログアウトＯＲＢを用いてログアウト処理が行われる（ステップＴ４）。
【００４１】
ここで、ステップＴ３のコマンド処理においては、図４のＡ１に示すように、イニシエータがライト要求パケットを転送して（ライト要求トランザクションを発行して）、ターゲットのドアベルレジスタをリングする。すると、Ａ２に示すように、ターゲットがリード要求パケットを転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータが作成したＯＲＢ（コマンドブロックＯＲＢ）が、ターゲットのデータバッファにフェッチされる。そして、ターゲットは、フェッチされたＯＲＢに含まれるコマンドを解析する。
【００４２】
そして、ＯＲＢに含まれるコマンドがＳＣＳＩのライトコマンドであった場合には、Ａ３に示すように、ターゲットがリード要求パケットをイニシエータに転送し、イニシエータが対応するリード応答パケットを返す。これにより、イニシエータのデータバッファに格納されているデータがターゲットに転送される。そして、例えばターゲットがプリンタであった場合には、転送されたデータがプリンタエンジンにより印刷される。
【００４３】
一方、ＯＲＢに含まれるコマンドがＳＣＳＩのリードコマンドであった場合には、図５のＢ１に示すように、ターゲットは、一連のライト要求パケットをイニシエータに転送する。これにより、例えばターゲットがスキャナであった場合には、スキャナエンジンにより取得されたスキャンデータが、イニシエータのデータバッファに転送されることになる。
【００４４】
このＳＢＰ−２によれば、ターゲットは、自身が都合の良いときに要求パケットを転送して（トランザクションを発行して）、データを送受信できる。従って、イニシエータとターゲットが同期して動く必要がなくなるため、データ転送効率を高めることができる。
【００４５】
なお、ＩＥＥＥ１３９４の上位プロトコルとしては、ＳＢＰ−２以外にも、ＦＣＰ（ＦｕｎｃｔｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ）と呼ばれるプロトコルなども提案されている。
【００４６】
さて、ターゲット、イニシエータ間でデータ転送を行う場合、図６（Ａ）のようにイニシエータ（相手ノード）のデータバッファ（記憶手段）にページテーブルが存在する場合と、存在しない場合がある。
【００４７】
そして、ページテーブルが存在する場合には、図６（Ｂ）に示すように、イニシエータが作成したＯＲＢの中には、そのページテーブルのアドレスやエレメント数が含まれる。そして、転送データのアドレス（読み出しアドレス、書き込みアドレス）は、このページテーブルを用いて間接アドレス指定される。
【００４８】
一方、ページテーブルが存在しない場合には、図６（Ｃ）に示すように、ＯＲＢの中にアドレスとデータ長が含まれ、転送データのアドレスが直接アドレス指定される。
【００４９】
１．４バスリセット
ＩＥＥＥ１３９４では、電源が投入されたり、途中でデバイスの抜き差しが発生すると、バスリセットが発生する。即ち、各ノードは、ポートの電圧変化を監視している。そして、バスに新たなノードが接続されるなどしてポートの電圧に変化が生じると、この変化を検知したノードは、バス上の他のノードに対して、バスリセットが発生したことを知らせる。また、各ノードの物理層は、バスリセットが発生したことをリンク層に伝える。
【００５０】
そして、このようにバスリセットが発生すると、ノードＩＤなどのトポロジ情報がクリアされる。そして、その後、トポロジー情報が自動的に再設定される。即ち、バスリセット後、ツリー識別、自己識別が行われる。その後、アイソクロナスリソースマネージャ、サイクルマスタ、バスマネージャ等の管理ノードが決定される。そして、通常のパケット転送が再開される。
【００５１】
このようにＩＥＥＥ１３９４では、バスリセット後にトポロジ情報が自動的に再設定されるため、電子機器のケーブルを自由に抜き差しできるようになり、いわゆるホットプラグを実現できる。
【００５２】
なお、トランザクションの途中でバスリセットが発生した場合には、そのトランザクションはキャンセルされる。そして、キャンセルされたトランザクションを発行した要求ノードは、トポロジー情報が再設定された後に、要求パケットを再度転送する。また、応答ノードは、バスリセットによりキャンセルされたトランザクションの応答パケットを要求ノードに返送してはならない。
【００５３】
２．全体構成
次に、本実施形態のデータ転送制御装置の全体構成例について図７を用いて説明する。なお、以下では、イニシエータとの間でデータ転送を行うターゲットがプリンタである場合について例にとり説明するが、本発明はこれに限定されない。
【００５４】
本実施形態のデータ転送制御装置１０は、ＰＨＹデバイス１２（物理層のデバイス）、リンクデバイス１４（リンク層のデバイス）、ＣＰＵ１６（中央処理ユニット）、データバッファ１８（記憶手段）、ファームウェア２０（プロセッサ）を含む。なお、ＰＨＹデバイス１２、リンクデバイス１４、ＣＰＵ１６、データバッファ１８は、任意の構成要素であり、本実施形態のデータ転送制御装置１０は、これらの構成要素を全て含む必要はない。
【００５５】
ＰＨＹデバイス１２は、図１の物理層のプロトコルをハードウェアにより実現するための回路であり、リンクデバイス１４により使用されるロジカルシンボルを電気信号に変換する機能を有する。
【００５６】
リンクデバイス１４は、図１のリンク層のプロトコルやトランザクション層のプロトコルの一部をハードウェアにより実現するための回路であり、ノード間でのパケット転送のための各種サービスを提供する。
【００５７】
ＣＰＵ１６は、装置全体の制御やデータ転送の制御を行うものである。
【００５８】
データバッファ１８は、転送データ（パケット）を一時的に格納するバッファであり、ＳＲＡＭ、ＳＤＲＡＭ、或いはＤＲＡＭなどのハードウェアにより構成される。なお、本実施形態では、データバッファ１８は、ランダムアクセス可能なパケット記憶手段として機能する。
【００５９】
ファームウェア２０は、ＣＰＵ１６上で動作する種々の処理ルーチン（処理モジュール）を含むプログラムであり、トランザクション層のプロトコルは、このファームウェア２０と、ハードウェアであるＣＰＵ１６等により実現される。
【００６０】
なお、イニシエータであるパーソナルコンピュータ１００が含むデバイスドライバ１０２は、周辺機器を管理制御するための種々の処理ルーチンを含むプログラムである。このプログラムは、情報記憶媒体１１０（ＦＤ、ＣＤ−ＲＯＭ、ＤＶＤ、ＲＯＭ）を利用してパーソナルコンピュータ１００にインストールされる。
【００６１】
ここで、デバイスドライバ１０２のプログラムは、ホストシステムが有する情報記憶媒体（ハードディスク、磁気テープ等）からインターネットなどのネットワークを介してダウンロードし、パーソナルコンピュータ１００にインストールするようにしてもよい。このようなホストシステムが有する情報記憶媒体の使用も本発明の範囲内に含まれる。
【００６２】
ファームウェア２０（Ｆ／Ｗ）は、コミュニケーション部３０（ＣＯＭ）、マネージメント部４０（ＭＮＧ）、プリントタスク部５０（ＰＲＴ）、フェッチ部６０（ＦＣＨ）を含む。
【００６３】
ここで、コミュニケーション部３０は、リンクデバイス１４などのハードウェアとの間のインターフェースとして機能する処理モジュールである。
【００６４】
マネージメント部４０（マネージメントエージェント）は、ログイン、リコネクト、ログアウト、リセット等の管理を行う処理モジュールである。例えばイニシエータがターゲットにログインを要求した場合には、まず、このマネージメント部４０が、このログイン要求を受け付けることになる。
【００６５】
プリントタスク部５０は、後段のアプリケーション層（上層）であるプリンタエンジンとの間のデータ転送処理を行う処理モジュールである。
【００６６】
フェッチ部６０（フェッチエージェント、コマンドブロックエージェント）は、コマンドブロックＯＲＢが含むコマンドを実行するための処理モジュールである。フェッチ部６０は、単一の要求しか扱うことができないマネージメント部４０と異なり、イニシエータからの要求により自身がフェッチしたＯＲＢのリンクリストも扱うことができる。
【００６７】
フェッチ部６０は、判断部６２、コマンド記憶部６４、コマンド比較部６６、アドレス記憶部６８、アドレス比較部７０、データ転送再開部７２を含む。
【００６８】
ここで判断部６２は、イニシエータ（相手ノード）との間で印刷データを転送するデータ転送期間中に、バスリセット（広義には、ノードのトポロジ情報をクリアするリセット）が発生したか否かを判断する処理を行う。
【００６９】
コマンド記憶部６４は、バスリセットの発生前にイニシエータから転送されてきたＯＲＢ（コマンドブロックＯＲＢ。広義には、データ転送オペレーション要求のためのコマンドパケット）の内容を、バスリセットが発生した時点やリコネクトが成功した時点などで記憶するための処理を行う。
【００７０】
コマンド比較部６６は、バスリセットの発生前にイニシエータから転送されてきたＯＲＢ（コマンドブロックＯＲＢ）の内容（コマンド記憶部６４により記憶された内容）と、バスリセットの発生後にイニシエータから転送されてきたＯＲＢの内容とを比較する処理を行う。
【００７１】
アドレス記憶部６８は、イニシエータとの間で転送される転送データ（印刷データ）の先頭アドレス（第１のアドレス）を記憶するための処理を行う。
【００７２】
アドレス比較部７０は、バスリセットが発生した場合に、アドレス記憶部６８により記憶された先頭アドレス（第１のアドレス）と、バスリセット発生後の転送データの先頭アドレス（第２のアドレス）とを比較する処理を行う。
【００７３】
データ転送再開部７２は、バスリセット発生前と発生後とで、転送データの先頭アドレスが一致した場合や、ＯＲＢ（コマンドブロックＯＲＢ）の内容が一致した場合に、バスリセット発生時点のデータ転送の続き（バスリセット発生時点で転送したデータの次のデータ）からデータ転送を再開する処理を行う。
【００７４】
３．処理の概要
次に、本実施形態の処理の概要について説明する。
【００７５】
図８は、ターゲット側（ファームウェア）の処理の概要について示すフローチャートである。
【００７６】
イニシエータから印刷要求があると、ターゲットは、イニシエータのデータバッファからＯＲＢをリードする（ステップＳ１）。そして、ページテーブルが存在する場合には、ＯＲＢに含まれるページテーブルアドレス（図６（Ｂ）参照）に基づいて、イニシエータのデータバッファからページテーブルをリードする（ステップＳ２）。次に、リードしたページテーブルに基づいてイニシエータのデータバッファから印刷データをリードする（ステップＳ３）。そして、ページテーブルにより指定される印刷データを全てリードすると、ステータスをライトして、データ転送が成功したか否かなどのステータスをイニシエータに伝える（ステップＳ４）。以上の処理を、全ての印刷データが転送されるまで繰り返す（ステップＳ５）。
【００７７】
そして本実施形態では、印刷データの転送中（データ転送期間）にバスリセットが発生すると、リコネクト後の最初の印刷要求時に以下の処理を行う。
【００７８】
即ち、まず、バスリセット前のＯＲＢの内容や印刷データの先頭アドレスと、バスリセット後のＯＲＢの内容や印刷データの先頭アドレスとが同一か否かを判断する（ステップＳ６）。そして、同一であると判断した場合には、バスリセット発生時点の続きからデータ転送を再開する（ステップＳ７）。一方、同一でないと判断した場合には、バスリセット後のＯＲＢを新規のＯＲＢとして最初から処理する（ステップＳ８）。
【００７９】
図９は、イニシエータ側（デバイスドライバ）の処理の概要について示すフローチャートである。
【００８０】
アプリケーションプログラムからの印刷ジョブが発生すると、イニシエータは、印刷のためのＯＲＢやページテーブルを作成し、データバッファに書き込む（ステップＳ１０）。次に、作成したＯＲＢをリードするようにターゲットに対して指示する（ステップＳ１１。図４のＡ１参照）。
【００８１】
次に、バスリセットが発生したか否かを判断し（ステップＳ１２）、発生しなかった場合には、ステータスがターゲットから送られてきたか否かを判断する（ステップＳ１３）。そして、送られてきた場合には、全ての印刷データが転送されたか否かを判断し（ステップＳ１４）、転送されていない場合には、ステップＳ１０に戻り、転送された場合には印刷ジョブを終了する。
【００８２】
そして本実施形態では、ステップＳ１２でバスリセットが発生したと判断されると、イニシエータが、ＯＲＢ、ページテーブルを再作成し（ステップＳ１５）、再作成したＯＲＢをリードするようにターゲットに対して指示する（ステップＳ１１）。この場合にイニシエータ（デバイスドライバ）は、バスリセット発生前のＯＲＢの内容や印刷データの先頭アドレスと、バスリセット発生後のＯＲＢの内容や印刷データの先頭アドレスとが同一になるように、ＯＲＢを再作成する。
【００８３】
４．本実施形態の特徴
さて、印刷データの転送中にバスリセットが発生すると、以下のような問題が生じることが判明した。
【００８４】
例えば図１０（Ａ）に示すように、Ｃ１に示す位置（アドレス）までデータを転送したところで、バスリセットが発生したとする。この場合には、バスリセット発生時点で処理中であったトランザクションは全てキャンセルされる。従って、バスリセット前に印刷データの転送を要求していたイニシエータは、図１０（Ｂ）に示すように、バスリセット後に印刷のためのＯＲＢを再度作成して、印刷データの転送を最初からやり直すようにターゲットに指示する。このため、図１０（Ｂ）のＣ２に示す位置からデータ転送が再開されてしまい、印刷データの一部分だけが二重に送られてしまう。この結果、図１０（Ｃ）に示すような二重印刷の問題が発生する。
【００８５】
このような問題を解決するために、本実施形態では、以下に説明するような手法を採用している。
【００８６】
即ち本実施形態では、図１１に示すように、バスリセット前のＯＲＢのページテーブルにより指定される転送データの先頭アドレス（バスアドレス）ＡＤ１を記憶しておく。
【００８７】
そして、バスリセットが発生した場合には、記憶しておいた先頭アドレスＡＤ１と、バスリセット後のＯＲＢのページテーブルにより指定される転送データの先頭アドレスＡＤ２とを比較する（図８のステップＳ６参照）。
【００８８】
そして、ＡＤ１とＡＤ２が同一の場合には、バスリセット前の転送データとバスリセット後の転送データは同一であると判断し、Ｄ１に示すように、バスリセット発生時点のデータ転送の続きからデータ転送を再開する（図８のステップＳ７参照）。即ち、バスリセット発生時点で既に転送を完了していたデータの次のデータからデータ転送を再開する。
【００８９】
一方、ＡＤ１とＡＤ２が同一でない場合には、バスリセット後の転送データは全く新規の転送データであると判断し、最初から処理する（図８のステップＳ８参照）。
【００９０】
このようにすることで、図１１のＤ２に示す部分の転送データが、図１０（Ｂ）の場合と異なり、二重転送されないようになる。従って、図１０（Ｃ）に示すような誤印刷が生じなくなる。また二重転送を避けることができるため、転送時間も短縮できる。
【００９１】
本実施形態は、バスリセットが発生しても、イニシエータのデータバッファ上での転送データの先頭アドレスについては変更されない点に着目したことに特徴がある。
【００９２】
即ち、バスリセットが発生すると、イニシエータがＯＲＢやページテーブルを再度作成するため、ページテーブルの構成等については変更されてしまう可能性がある。
【００９３】
これに対して、転送データの先頭アドレス（転送データの位置）は、アプリケーションプログラムなどが決めるものであるため、バスリセットが発生しても先頭アドレスが変わることはない。
【００９４】
本実施形態は、この点に着目し、転送データの先頭アドレスがバスリセット前とバスリセット後で同一ならば、同じ転送データが送られてきたと判断している。
【００９５】
例えば、本実施形態と異なる手法として、先頭アドレスの比較処理を行わずに、常に、バスリセット発生時点の続きからデータ転送を再開するという手法も考えられる。
【００９６】
しかしながら、この手法によると、例えば、バスリセット後にイニシエータが印刷データの転送処理をキャンセルし、バスリセット前と全く異なるＯＲＢを作成した場合にも、図１１のＤ１からデータ転送が再開されてしまうという不具合が生じる。
【００９７】
これに対して本実施形態では、転送データの先頭アドレスがバスリセットの前後で同一の場合には、図１１のＤ１からデータ転送が再開するが、同一でない場合には、全く新規のＯＲＢとして処理されるため、上記のような不具合が生じない。
【００９８】
さて、本実施形態では、転送データがページテーブルを用いて転送される場合には、具体的には次のようにして転送データの先頭アドレスの比較処理を行っている。
【００９９】
即ち図１２に示すように、まず、バスリセット前のＯＲＢのページテーブルの中の先頭セグメントＳＥＧ１に格納されている先頭アドレスＡＤ１を、ページテーブル記憶領域（ターゲットのデータバッファ上の領域）とは別の領域に記憶しておく。そして、この記憶されたＡＤ１と、バスリセット後のＯＲＢのページテーブルの中の先頭セグメントＳＥＧ１に格納される先頭アドレスＡＤ２とを比較する。
【０１００】
ページテーブルが例えば１２８個のセグメントを有する場合を考える。この場合に、１２８個の全てのセグメントをイニシエータから一度にリードし、ターゲットのデータバッファ上のページテーブル記憶領域に記憶すると、ページテーブルの記憶に必要な記憶容量が不要に増加してしまう。
【０１０１】
そこで本実施形態では、ページテーブルのセグメントを例えば８個ずつリードし、これらの８個のセグメントをターゲットのデータバッファ上のページテーブル記憶領域に書き込む。このようにすることで、ページテーブル記憶領域の使用記憶領域を節約できる。
【０１０２】
しかしながら、このようにすると、例えば最初の８個のセグメントをリードしてページテーブル記憶領域に書き込んだ後、次の８個のセグメントをリードしてページテーブル記憶領域に上書きすると、最初の８個のセグメントの情報が消えてしまい、ページテーブルの先頭セグメントＳＥＧ１に格納されている先頭アドレスＡＤ１も消えてしまうという不具合が生じる。
【０１０３】
本実施形態によれば、ページテーブルの先頭セグメントＳＥＧ１に格納されている先頭アドレスＡＤ１は、ページテーブル記憶領域とは別の領域に記憶される。従って、上記のような不具合が発生するのを防止できると共に、ページテーブル記憶領域の使用記憶容量も節約できるようになる。
【０１０４】
また本実施形態では、バスリセット前のＯＲＢ（コマンドブロックＯＲＢ）の内容とバスリセット後のＯＲＢの内容とを、先頭アドレスＡＤ１、ＡＤ２の比較処理に先立って比較するようにしている。
【０１０５】
即ち図１３に示すように、バスリセットの発生後、イニシエータがリコネクトに成功し、新たなＯＲＢを作成して転送要求してきた場合に、まず、バスリセット前のＯＲＢの内容とバスリセット後のＯＲＢの内容を比較する。そして、ＯＲＢの内容が同一の時に、初めて、バスリセット前のＯＲＢにより特定される先頭アドレスＡＤ１とバスリセット後のＯＲＢにより特定される先頭アドレスＡＤ２が同一か否かを比較する。
【０１０６】
例えば、イニシエータのパーソナルコンピュータで動作するＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）が第１のＯＳである場合には、後述するようにＯＲＢが順序番号などの識別情報を含む場合がある。従って、ＯＲＢの内容を比較すれば、バスリセット後のＯＲＢによる転送データが、バスリセット前のＯＲＢによる転送データの続きか否かを容易に判断できる。そして、ＯＲＢの内容を先に比較し、ＯＲＢの内容が同一でないと判断した場合には、先頭アドレスの比較処理を省略できるため、処理負荷を軽くできる。
【０１０７】
一方、イニシエータのＯＳが第２のＯＳである場合には、ＯＲＢが順序番号などの識別情報を含まない。従って、この場合には、先頭アドレスＡＤ１、ＡＤ２を比較することで、バスリセット後の転送データがバスリセット前の続きか否かを確実に判断できるようになる。
【０１０８】
また本実施形態のように、ＯＲＢの内容比較と先頭アドレスの比較とを両方行うことにより、ファームウェアは、イニシエータのＯＳが第１のＯＳか第２のＯＳかを意識する必要が無くなる。即ち、イニシエータのＯＳが第１のＯＳであっても第２のＯＳであっても、同一構成のファームウェアで処理できるようになり、ファームウェアの開発期間の短縮化や、デバッグ作業の容易化を図れる。
【０１０９】
なお本実施形態では、ＯＲＢの内容比較の際に識別情報以外にも種々の情報を比較している。例えば図１４に示すように、本実施形態では、コマンドブロックＯＲＢが含むページテーブル存在フラグＰや、データサイズや、コマンドブロック（コマンドセット）フィールドの中のオペレーションコード（印刷コマンド、リードコマンドなどを区別するコード）やデータ長を比較している。このような情報を比較することで、バスリセット前後のＯＲＢが同一か否かを簡素な処理で確実に判断できるようになる。
【０１１０】
さて、イニシエータのパーソナルコンピュータで動作するＯＳが、第１のＯＳである場合（或いは第２のＯＳの最新バージョンである場合）には、ＯＲＢが、ＯＲＢ同士を識別するための順序番号などの識別情報を含む。即ち、イニシエータのデバイスドライバが、ＯＲＢの所与のフィールドにＯＲＢの識別情報を書き込む。
【０１１１】
このような場合には、図１５に示すように、バスリセット前のＯＲＢが含む識別情報とバスリセット後のＯＲＢが含む識別情報とを比較する。そして、これらの識別情報が同一である場合には、図１５のＥ１に示すように、リセット発生時点の続きからデータ転送を再開するようにする。一方、同一でない場合には、バスリセット後のＯＲＢは新規のＯＲＢであるとして処理を行う。
【０１１２】
このようにすることで、バスリセット（リコネクト）後の転送データが、バスリセット前の続きか否かを、簡素な処理で判断できるようになる。そして、印刷データが二重転送されるのを避けることができるため、二重印刷などの誤印刷が生じるのを防止できると共に転送時間も短縮化できる。
【０１１３】
なお、ＯＲＢを識別するための識別情報としては、ＯＲＢの順序番号以外にも種々の情報を考えることができる。例えば、ＯＲＢが転送しようとしているデータのデータアドレスなどを識別情報として用いてもよい。即ち、ターゲットがハードディスクドライブである場合には、データのセクタアドレスなどをＯＲＢの識別情報として用いることができる。
【０１１４】
さて、バスリセットの発生時期は全くの任意である。従って、例えば図１６に示すように、ターゲットがデータ転送完了のステータスをイニシエータに転送したが、バスリセットの発生が要因となってイニシエーターからＡＣＫ（ＡＣＫコンプリート）が返って来ず、ＡＣＫミッシングになる場合がある。
【０１１５】
このような場合には、バスリセットの発生が要因となってイニシエータがステータスを受け取れず、ＡＣＫミッシングになったという第１のケースと、イニシエータはステータスを受け取り、ＡＣＫを返したが、バスリセットの発生が要因となってＡＣＫミッシングになったという第２のケースが考えられる。
【０１１６】
そして、上記第１のケースでは、イニシエータはデータ転送が不成功であったと考え、バスリセット後に同一のＯＲＢを再度作成するという第１の処理を行う。一方、上記第２のケースでは、イニシエータはデータ転送が成功したと考え、バスリセット後に次のＯＲＢを作成するという第２の処理を行う。
【０１１７】
ところが、ターゲットにはＡＣＫミッシングであったという情報しか伝わらないため、ターゲットは、イニシエータが上記第１、第２の処理のいずれを行ったのかを知ることができない。従ってこのような場合にバスリセット発生時点の続きからデータ転送を開始してしまうと、誤ったデータ転送が行われてしまう可能性がある。
【０１１８】
そこで本実施形態では図１６に示すように、バスリセットの発生が要因となってイニシエータからアクノリッジメントが返って来なかった場合には、デッド状態（データ転送不可状態）に遷移する。このようにすることで、誤ったデータ転送が行われる事態を防止できる。
【０１１９】
なお、図１５で説明した識別情報をＯＲＢに常に含ませるようにすれば、イニシエータが上記第１、第２の処理のいずれを行ったかを（イニシエータがデータ転送完了のステータスを受け取ったか否かを）、図１７に示すように、ＯＲＢが含む識別情報を比較することで判断できるようになる。
【０１２０】
即ち、バスリセット前のＯＲＢの識別情報とバスリセット後のＯＲＢの識別情報が同一である場合には、イニシエータが上記第１の処理を行ったと判断でき、同一でない場合には、上記第２の処理を行ったと判断できる。従って、ターゲットは、デッド状態に遷移することなく、バスリセット発生時点の続きからデータ転送を再開できるようになる。
【０１２１】
５．詳細な処理例
次に本実施形態の詳細な処理例について図１８〜図２２のフローチャートを用いて説明する。
【０１２２】
図１８〜図２０は、バスリセット発生時（リコネクト時）の処理の詳細例を示すフローチャートである。
【０１２３】
バスリセットが発生すると、ターゲットは、まず、イニシエータがログインしているか否かを判断し（ステップＳ２０）、ログインしている場合にはＩＥＥＥ１３９４のバス上の全ての転送処理（トランザクション）をキャンセルする（ステップＳ２１）。一方、ログインしていない場合には、バスリセットが発生しても特別な処理は不要であるため、何もしない（ステップＳ２２）。
【０１２４】
次に、既にバスリセット処理に入っているか否かを判断する（ステップＳ２３）。これにより、バスリセットが複数回発生した場合にそれに対応するバスリセット処理が無用に複数回繰り返される事態を防止できる。
【０１２５】
次に、バスリセット発生時点のＡＣＫ（アクノリッジメント）の状態を記憶しておく（ステップＳ２４）。これにより、その後に発生するトランザクション（例えばリコネクトのトランザクション）により、バスリセット直後のＡＣＫの内容が消されてしまう事態を防止できる。
【０１２６】
次に、ＩＥＥＥ１３９４のバス上で転送済みのデータのサイズ（バイト数）を記憶する（ステップＳ２５）。即ち、バスリセット発生時点において処理中であったセグメントの中での転送済みのデータのサイズを記憶する。そして、ステップＳ２３の判断のために、バスリセット処理中であることを示すフラグをオンにする（ステップＳ２６）。即ち、このフラグがオンになると、その後に、バスリセットが発生しても、ステップＳ２４〜Ｓ２６の処理は行われない。
【０１２７】
次に、イニシエータからのリコネクト待ちになり（ステップＳ２７）、イニシエータによりリコネクトされたか否かを判断する（ステップＳ２８）。そして、リコネクトされなかった場合には、ログインＯＲＢのリコネクトフィールドで指定されたリコネクトタイムアウト時間が経過したか否かを判断する（ステップＳ２９）。そして、経過した場合には、継続フラグ（データ転送が継続して再開される可能性があることを示すフラグ）をオフにして（ステップＳ３０）、ログアウト状態に状態遷移する（ステップＳ３１）。
【０１２８】
一方、リコネクトタイムアウト時間内にリコネクトされた場合には、リコネクトしてきたイニシエータが、バスリセット前にログインしていたイニシエータか否かを判断し（ステップＳ３２）、バスリセット前と異なるイニシエータであった場合には、そのイニシエータのリコネクトを拒否し、リコネクト待ちに戻る。
【０１２９】
バスリセット前と同じイニシエータがログインしてきた場合には、印刷のためのコマンドブロックＯＲＢ（印刷コマンドを含むＯＲＢ）を、バスリセット発生時点において処理中だったか否かを判断する（図１９のステップＳ３３）。そして、処理中でなかった場合には、継続フラグをオフにして（ステップＳ３６）、アイドル状態に状態遷移する（ステップＳ３７）。
【０１３０】
一方、印刷のためのコマンドブロックＯＲＢを処理中であった場合には、ステータスのライト中（ステータスをライトしてからＡＣＫが返ってくるまでの期間）にバスリセットが発生したか否かを判断する（ステップＳ３４）。そして、ステータスのライト中にバスリセットが発生した場合には、図１８のステップＳ２４で記憶したＡＣＫの情報に基づいて、ＡＣＫコンプリートか否かを判断する（ステップＳ３５）。
【０１３１】
そして、ＡＣＫコンプリートの場合には、継続フラグをオフにして（ステップＳ３６）、アイドル状態に状態遷移する（ステップＳ３７）。一方、ＡＣＫコンプリートでない場合には、ＡＣＫミッシングか否かを判断する（ステップＳ３８）。そして、ＡＣＫミッシングでなければ何もせず（ステップＳ３９）、ＡＣＫミッシングの場合には、継続フラグをオフにして（ステップＳ４０）、図１６で説明したようにデッド状態（データ転送不可状態）に状態遷移する（ステップＳ４１）。
【０１３２】
ステップＳ３４でバスリセットの発生がステータスのライト中でないと判断された場合には、処理中のＯＲＢの転送（印刷）データを１バイトでも後段のプリンタエンジンに転送したか否かを判断する（ステップＳ４２）。そして、１バイトも転送していなかった場合には継続フラグをオフにし（ステップＳ４３）、アイドル状態に状態遷移する（ステップＳ４９）。
【０１３３】
一方、１バイトでもプリンタエンジンに転送していた場合には、ＯＲＢの内容（データサイズ、ページテーブル存在フラグＰ、コマンドブロック）や、バスリセット発生時点までに転送できたデータのサイズを記憶する（ステップＳ４４）。
このデータのサイズは、バスリセット発生時点で後段のプリンタエンジンに既に転送したデータのバイト数と、バスリセット発生時点でＩＥＥＥ１３９４のバス上でのデータ転送は既に完了し、後段のプリンタエンジンに転送中又はこれから転送する予定のデータのバイト数の合計に相当する。即ち、例えば、プリンタで既に印刷したデータのバイト数と、プリンタで現在印刷中又はこれから印刷予定のデータのバイト数の合計に相当する。
【０１３４】
次に、ページテーブルが存在するか否かを判断し（ステップＳ４５）、存在しない場合には、ＯＲＢのデータスクリプタの内容を記憶する（ステップＳ４６）。即ち、ページテーブルが存在しない場合には、直接アドレス指定の場合の転送データのアドレス及びデータ長が記憶される（図６（Ｃ）参照）。
【０１３５】
一方、ページテーブルが存在する場合には、ページテーブルの先頭セグメントの内容（アドレス、データ長）と、バスリセット発生時点で処理中だったセグメントの内容（アドレス、データ長）及びセグメント番号を記憶する（ステップＳ４７）。そして、継続フラグをオンにして（ステップＳ４８）、アイドル状態に状態遷移する（ステップＳ４９）。
【０１３６】
図２１、図２２は、通常時の処理の詳細例を示すフローチャートである。
【０１３７】
まず、イニシエータからＯＲＢのリードを指示されたか否か（ドアベルレジスタがリングされたか否か）を判断し（ステップＳ５１）、指示されなかった場合にはアイドル状態にとどまる（ステップＳ５０）。一方、指示された場合には、イニシエータが作成したＯＲＢをイニシエータからリードする（ステップＳ５２）。そして、ＯＲＢが含むページテーブル存在フラグＰに基づいて、ページテーブルが存在するか否かを判断する（ステップＳ５３）。そして、ページテーブルが存在する場合には、ページテーブルのセグメントを例えば８セグメントずつリードする（ステップＳ５４）。
【０１３８】
次に、ＯＲＢのコマンドブロックにあるオペレーションコードに基づいて、リードしたＯＲＢが印刷のためのコマンドブロックＯＲＢか否かを判断する（ステップＳ５５）。そして、印刷のためのコマンドブロックＯＲＢであった場合には、ステップＳ５４でリードした８セグメントが、ページテーブルの最初の８セグメント（先頭セグメントを含む８セグメント）か否かを判断し（ステップＳ５６）、最初の８セグメントであった場合には、図２２に示すコマンド・アドレス比較処理に移行する（ステップＳ５７）。
【０１３９】
ステップＳ５５で印刷のためのコマンドブロックＯＲＢではないと判断された場合、ステップＳ５６で最初の８セグメントでないと判断された場合、及び、ステップＳ５７のコマンド・アドレス比較処理が終了した場合には、データのリード／ライトを行う（ステップＳ５８）。そして、１セグメント分のデータ、８セグメント分のデータをリード／ライトするまで繰り返す（ステップＳ５９、Ｓ６０）。
【０１４０】
次に、ページテーブルの全てのセグメントをリード／ライトしたか否かを判断し（ステップＳ６１）、全てのセグメントをリード／ライトしていない場合には、ページテーブルの次の８セグメントをリードする（ステップＳ５４）。一方、ページテーブルの全てのセグメントをリードした場合には、イニシエータに対してステータスをライトする（ステップＳ６２）。そして、印刷物の印刷のための全てのＯＲＢをリードしたか否かを判断し（ステップＳ６３）、次のＯＲＢがある場合にはステップＳ５２に戻り、次のＯＲＢが無い場合にはアイドル状態に状態遷移する（ステップＳ５０）。
【０１４１】
ステップＳ５３でページテーブルが存在しないと判断した場合には、リードしたＯＲＢが印刷のためのコマンドブロックＯＲＢか否かを判断する（ステップＳ６４）。そして、印刷のためのコマンドブロックＯＲＢであった場合には、図２２に示すコマンド・アドレス比較処理に移行する（ステップＳ６５）。
【０１４２】
一方、印刷のためのコマンドブロックＯＲＢではないと判断された場合、及び、コマンド・アドレス比較処理が終了した場合には、データをリード／ライトし（ステップＳ６６）、全てのデータをリード／ライトするまで繰り返す（ステップＳ６７）。そして、全てのデータをリード／ライトした場合には、ステップＳ６２に移行し、イニシエータに対してステータスをライトする。
【０１４３】
図２２のコマンド・アドレス比較処理においては、まず、継続フラグがオンか否かを判断する（ステップＳ７０）。この継続フラグは、図２０のステップＳ４８においてオンにされるフラグである。そして、継続フラグがオフの場合にはステップＳ７６に移行して、図１２で説明したように転送データの先頭アドレス（ページテーブルの先頭セグメントのアドレス）を記憶し、コマンド・アドレス比較処理を終了する。
【０１４４】
継続フラグがオンの場合には、図１３、図１４で説明したように、リードしたＯＲＢの内容がバスリセット前のＯＲＢの内容と同一か否かを判断する（ステップＳ７１）。この場合に、比較対象となるバスリセット前のＯＲＢの内容は、図２０のステップＳ４４において記憶されている。また、図１３で説明したように本実施形態では、アドレス比較（ステップＳ７２）に先立って、ＯＲＢの内容比較（ステップＳ７１）を行っている。
【０１４５】
ＯＲＢの内容がバスリセット前と同一であった場合には、図１１で説明したように、転送データの先頭アドレスがバスリセット前と同一か否かを判断する（ステップＳ７２）。そして、同一の場合には、データ転送の設定をバスリセット発生前の状態に戻す（ステップＳ７３）。即ち、図２０のステップＳ４４で記憶したバスリセット発生時点までの転送済みデータサイズや、ステップＳ４７で記憶したセグメントの内容やセグメント番号などに基づいて、図１１のＤ１に示す位置（バスリセット発生時点の続き）からデータ転送を再開できるように、データ転送の設定をバスリセット前の状態に戻す。そして、継続フラグをオフに戻す（ステップＳ７４）。この場合、バスリセット前に既に転送を完了していたデータが消失しないように、ターゲットのデータバッファ上のデータをクリアしないようにする。
【０１４６】
なお、ステップＳ７４の後に、ステップＳ７６のように転送データの先頭アドレスを記憶しておかないのは、バスリセット発生時点の続きからデータ転送を再開する場合には、バスリセット発生前に記憶しておいた先頭アドレスがそのまま使えるからである。
【０１４７】
ステップＳ７１でＯＲＢの内容がバスリセット前と同一でないと判断した場合、或いはステップＳ７２で先頭アドレスがバスリセット前と同一でないと判断した場合には、データ転送の再開処理を行わず、継続フラグをオフに戻すと共に転送データの先頭アドレスを記憶しておく（ステップＳ７５、Ｓ７６）、即ち、この場合には、リードしたＯＲＢを全くの新規のＯＲＢとして処理することになる。
【０１４８】
なお、ステップＳ７５の場合には、リードしたＯＲＢを最初から処理することになるため、ステップＳ７４と異なり、ターゲットのデータバッファのデータをクリアする。
【０１４９】
６．電子機器
次に、本実施形態のデータ転送制御装置を含む電子機器の例について説明する。
【０１５０】
例えば図２３（Ａ）に電子機器の１つであるプリンタの内部ブロック図を示し、図２４（Ａ）にその外観図を示す。ＣＰＵ（マイクロコンピュータ）５１０はシステム全体の制御などを行う。操作部５１１はプリンタをユーザが操作するためのものである。ＲＯＭ５１６には、制御プログラム、フォントなどが格納され、ＲＡＭ５１８はＣＰＵ５１０のワーク領域として機能する。表示パネル５１９はプリンタの動作状態をユーザに知らせるためのものである。
【０１５１】
ＰＨＹデバイス５０２、データ転送制御装置５００を介して、パーソナルコンピュータなどの相手ノードから送られてきた印字データは、バス５０４を介して印字処理部（プリンタエンジン）５１２に直接送られる。そして、印字データは、印字処理部５１２にて所与の処理が施され、プリントヘッダなどからなる印字部（データを出力するための装置）５１４により紙に印字されて出力される。
【０１５２】
図２３（Ｂ）に電子機器の１つであるスキャナの内部ブロック図を示し、図２４（Ｂ）にその外観図を示す。ＣＰＵ５２０はシステム全体の制御などを行う。操作部５２１はスキャナをユーザが操作するためのものである。ＲＯＭ５２６には制御プログラムなどが格納され、ＲＡＭ５２８はＣＰＵ５２０のワーク領域として機能する。
【０１５３】
光源、光電変換器などからなる画像読み取り部（データを取り込むための装置）５２２により原稿の画像が読み取られ、読み取られた画像のデータは画像処理部（スキャナエンジン）５２４により処理される。そして、処理後の画像データがバス５０５を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、この画像データにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１５４】
図２３（Ｃ）に電子機器の１つであるＣＤ−ＲＷドライブの内部ブロック図を示し、図２４（Ｃ）にその外観図を示す。ＣＰＵ５３０はシステム全体の制御などを行う。操作部５３１はＣＤ−ＲＷをユーザが操作するためのものである。ＲＯＭ５３６には制御プログラムなどが格納され、ＲＡＭ５３８はＣＰＵ５３０のワーク領域として機能する。
【０１５５】
レーザ、モータ、光学系などからなる読み取り＆書き込み部（データを取り込むための装置又はデータを記憶するための装置）５３３によりＣＤ−ＲＷ５３２から読み取られたデータは、信号処理部５３４に入力され、エラー訂正処理などの所与の信号処理が施される。そして、信号処理が施されたデータが、バス５０６を介してデータ転送制御装置５００に直接送られる。データ転送制御装置５００は、このデータにヘッダなどを付加することでパケットを生成し、ＰＨＹデバイス５０２を介してパーソナルコンピュータなどの相手ノードに送信する。
【０１５６】
一方、ＰＨＹデバイス５０２、データ転送制御装置５００を介して、相手ノードから送られてきたデータは、バス５０６を介して信号処理部５３４に直接送られる。そして、信号処理部５３４によりこのデータに所与の信号処理が施され、読み取り＆書き込み部５３３によりＣＤ−ＲＷ５３２に記憶される。
【０１５７】
なお、図２３（Ａ）、（Ｂ）、（Ｃ）において、ＣＰＵ５１０、５２０、５３０の他に、データ転送制御装置５００でのデータ転送制御のためのＣＰＵを別に設けるようにしてもよい。
【０１５８】
また、図２３（Ａ）、（Ｂ）、（Ｃ）ではＲＡＭ５０１（データバッファに相当）がデータ転送制御装置５００の外部に設けられているが、ＲＡＭ５０１をデータ転送制御装置５００に内蔵させてもよい。
【０１５９】
本実施形態のデータ転送制御装置を電子機器に用いれば、バスに新たな電子機器が接続されてバスリセットが発生した場合にも、バスリセットを原因とする不具合の発生が防止される。これにより、電子機器の誤動作を防止できる。
【０１６０】
また本実施形態のデータ転送制御装置を電子機器に用いれば、高速なデータ転送が可能になる。従って、ユーザがパーソナルコンピュータなどによりプリントアウトの指示を行った場合に、少ないタイムラグで印字が完了するようになる。また、スキャナへの画像取り込みの指示の後に、少ないタイムラグで読み取り画像をユーザは見ることができるようになる。また、ＣＤ−ＲＷからのデータの読み取りや、ＣＤ−ＲＷへのデータの書き込みを高速に行うことができるようになる。
【０１６１】
また本実施形態のデータ転送制御装置を電子機器に用いることで、ＣＰＵ上で動作するファームウェアの処理負担が軽減され、安価なＣＰＵや低速のバスを用いることが可能になる。更に、データ転送制御装置の低コスト化、小規模化を図れるため、電子機器の低コスト化、小規模化も図れるようになる。
【０１６２】
なお本実施形態のデータ転送制御装置を適用できる電子機器としては、上記以外にも例えば、種々の光ディスクドライブ（ＣＤ−ＲＯＭ、ＤＶＤ）、光磁気ディスクドライブ（ＭＯ）、ハードディスクドライブ、ＴＶ、ＶＴＲ、ビデオカメラ、オーディオ機器、電話機、プロジェクタ、パーソナルコンピュータ、電子手帳、ワードプロセッサなど種々のものを考えることができる。
【０１６３】
なお、本発明は本実施形態に限定されず、本発明の要旨の範囲内で種々の変形実施が可能である。
【０１６４】
例えば、本発明のデータ転送制御装置の構成は、図７に示す構成が特に望ましいが、これに限定されるものではない。
【０１６５】
また、先頭アドレスの比較手法、コマンドの比較手法、データ転送の再開の手法も、本実施形態で説明した手法が特に望ましいが、これに限定されるものではない。
【０１６６】
また、本発明はＩＥＥＥ１３９４におけるバスリセットに特に有用だが、これ以外にも、少なくともノードのトポロジー情報をクリアするようなリセットであれば適用できる。
【０１６７】
また、本発明は、ＩＥＥＥ１３９４規格でのデータ転送に適用されることが特に望ましいが、これに限定されるものではない。例えばＩＥＥＥ１３９４と同様の思想に基づく規格やＩＥＥＥ１３９４を発展させた規格におけるデータ転送にも本発明は適用できる。
【図面の簡単な説明】
【図１】ＩＥＥＥ１３９４の層構造について示す図である。
【図２】ＳＢＰ−２について説明するための図である。
【図３】ＳＢＰ−２のデータ転送処理の概略について説明するための図である。
【図４】データをイニシエータからターゲットに転送する場合のコマンド処理について説明するための図である。
【図５】データをターゲットからイニシエータに転送する場合のコマンド処理について説明するための図である。
【図６】図６（Ａ）、（Ｂ）、（Ｃ）は、ページテーブルについて説明するための図である。
【図７】本実施形態のデータ転送制御装置の構成例を示す図である。
【図８】ターゲット側（ファームウェア）の処理の概要を示すフローチャートである。
【図９】イニシエータ側（デバイスドライバ）の処理の概要を示すフローチャートである。
【図１０】図１０（Ａ）、（Ｂ）、（Ｃ）は、二重印刷の問題について説明するための図である。
【図１１】転送データの先頭アドレスの比較結果に基づいてデータ転送を継続して再開する手法について説明するための図である。
【図１２】転送データの先頭アドレスの比較手法について説明するための図である。
【図１３】アドレス比較に先立ってコマンド比較を行う手法について説明するための図である。
【図１４】ＯＲＢの内容比較について説明するための図である。
【図１５】ＯＲＢの識別情報の比較結果に基づいてデータ転送を継続して再開する手法について説明するための図である。
【図１６】ステータスのライト中にバスリセットが発生し、ＡＣＫミッシングとなった場合に、デッド状態に移行する手法について説明するための図である。
【図１７】ステータスのライト中にバスリセットが発生し、ＡＣＫミッシングとなった場合に、イニシエータがステータスを受け取ったか否かをＯＲＢが含む識別情報に基づいて判断する手法について説明するための図である。
【図１８】バスリセット発生時（リコネクト時）の本実施形態の詳細な処理例について示すフローチャートである。
【図１９】バスリセット発生時（リコネクト時）の本実施形態の詳細な処理例について示すフローチャートである。
【図２０】バスリセット発生時（リコネクト時）の本実施形態の詳細な処理例について示すフローチャートである。
【図２１】通常時の本実施形態の詳細な処理例について示すフローチャートである。
【図２２】通常時の本実施形態の詳細な処理例について示すフローチャートである。
【図２３】図２３（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の内部ブロック図の例である。
【図２４】図２４（Ａ）、（Ｂ）、（Ｃ）は、種々の電子機器の外観図の例である。
【符号の説明】
１０データ転送制御装置
１２ＰＨＹデバイス
１４リンクデバイス
１６ＣＰＵ
１８データバッファ
２０ファームウェア（Ｆ／Ｗ）
３０コミュニケーション部（ＣＯＭ）
４０マネージメント部（ＭＮＧ）
５０プリントタスク部（ＰＲＴ）
６０フェッチ部（ＦＣＨ）
６２判断部
６４コマンド記憶部
６６コマンド比較部
６８アドレス記憶部
７０アドレス比較部
７２データ転送再開部
１００パーソナルコンピュータ
１０２デバイスドライバ
１０４データバッファ
１１０情報記憶媒体[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a data transfer control device, an information storage medium, and an electronic device, and more particularly, to a data transfer control device and an information storage medium for performing data transfer according to a standard such as IEEE 1394 between a plurality of nodes connected to a bus. And electronic equipment.
[0002]
BACKGROUND ART AND PROBLEMS TO BE SOLVED BY THE INVENTION
In recent years, an interface standard called IEEE 1394 has been spotlighted. This IEEE 1394 standardizes a high-speed serial bus interface that can support next-generation multimedia. According to the IEEE 1394, it is possible to handle data requiring real-time properties such as moving images. In addition, not only computer peripherals such as printers, scanners, CD-RW drives, and hard disk drives, but also home appliances such as video cameras, VTRs, and TVs can be connected to the IEEE 1394 bus. For this reason, it is expected that digitalization of electronic devices can be drastically promoted.
[0003]
In the IEEE 1394, when an electronic device is newly connected to the bus or the electronic device is removed from the bus, and the number of nodes connected to the bus increases or decreases, a so-called bus reset occurs. When a bus reset occurs, the topology information of the node is cleared, and thereafter, the topology information is automatically reset. That is, after the occurrence of the bus reset, tree identification (determination of a root node) and self-identification are performed, and thereafter, a management node such as an isochronous resource manager is determined. Then, the normal packet transfer is restarted.
[0004]
As described above, in the IEEE 1394, the topology information is automatically reset after the bus reset, so that it is possible to insert and remove a cable (hot plug) in a so-called hot state. For this reason, the general user can freely connect and disconnect the cable to the electronic device as in the case of ordinary home appliances such as a VTR, and this can be useful for the spread of a so-called home network system.
[0005]
However, it has been found that in a device such as a printer or a scanner connected to the IEEE 1394 bus, the following problem occurs due to the occurrence of the bus reset.
[0006]
That is, if a bus reset occurs during transfer of print data on the IEEE 1394 bus, an initiator such as a personal computer restarts transfer of print data from the beginning. Therefore, only a part of the print data is sent twice to the target printer, causing a problem of erroneous printing such as double printing.
[0007]
Further, in the scanner, once the head starts moving, the head cannot be returned to the original position and the same data cannot be obtained again. Therefore, after the bus reset occurs, there is a problem that the data transfer cannot be continued even if the initiator attempts to restart the data transfer from the beginning.
[0008]
As a conventional technique for solving the problem caused by the occurrence of the bus reset, there is a technique disclosed in, for example, JP-A-11-194902. In this conventional technique, when a bus reset occurs, data processing is held, and data processing is resumed after the network configuration is reconstructed.
[0009]
However, in this conventional technique, transfer data is simply retransmitted after a bus reset occurs, and it is not determined whether the retransmitted transfer data is a continuation of the transfer data before the bus reset has occurred. Therefore, this conventional technique cannot solve the problem of double printing.
[0010]
The present invention has been made in view of the above technical problems, and an object of the present invention is to provide a data transfer control device that can solve a problem that occurs when a reset that clears topology information of a node occurs. An object of the present invention is to provide an information storage medium and an electronic device.
[0011]
[Means for Solving the Problems]
In order to solve the above-mentioned problem, the present invention is a data transfer control device for transferring data between a plurality of nodes connected to a bus. Address storage means for storing a certain first address, the first address stored by the address storage means when a reset for clearing the topology information of the node occurs, and transfer data after the occurrence of the reset Address comparing means for comparing the first address with the second address, and restart means for restarting the data transfer from the continuation of the data transfer at the time of occurrence of the reset when the first and second addresses are the same. And characterized in that:
[0012]
According to the present invention, the first address which is the head address of the transfer data is stored. Then, when a reset for clearing the topology information of the node occurs, the stored first address is compared with the second address which is the head address of the transfer data after the occurrence of the reset. When the first and second addresses are the same, the data transfer is restarted from the continuation of the reset occurrence point (for example, from the data next to the data whose transfer has been completed at the reset occurrence point). become.
[0013]
On the other hand, when the first and second addresses are not the same, for example, the transfer data after the occurrence of the reset is processed as new transfer data.
[0014]
Therefore, according to the present invention, when the partner node has transmitted the same transfer data as before the occurrence of the reset after the occurrence of the reset, the data transfer can be resumed from the continuation of the time of the occurrence of the reset. Therefore, for example, it is possible to solve a problem that data is redundantly transferred to a device in an upper layer of the data transfer control device and a device in an upper layer malfunctions.
[0015]
Further, according to the present invention, when the transfer data is transferred using a page table, the address storage means sets an address stored in a first segment in the page table as the first address and stores the page table storage area. It is characterized in that it is stored in an area different from the above. In this way, it is possible to prevent the first address, which is the head address of the transfer data, from being lost due to overwriting of data in the page table storage area.
[0016]
Further, according to the present invention, the contents of the first command packet for the data transfer operation request transferred from the partner node before the occurrence of the reset for clearing the topology information of the node, and the contents of the first command packet transferred from the partner node after the occurrence of the reset, Command comparison means for comparing the contents of the second command packet for the data transfer operation request received before the first and second address comparison processing. By doing so, for example, when the contents of the first and second command packets are the same, it is not necessary to perform the comparison processing of the first and second addresses, and the processing load can be reduced. I can do it.
[0017]
Further, according to the present invention, the first and second command packets include identification information for identifying the command packet, and the command comparing means performs a first and second address comparison before comparing the first and second addresses. The first identification information included in one command packet is compared with the second identification information included in a second command packet. This makes it possible to determine whether or not to resume data transfer from the continuation of the point of occurrence of the reset, based on the identification information included in the command packet, thereby simplifying the processing.
[0018]
Also, according to the present invention, the status of data transfer completion is transferred to the partner node. However, if an acknowledgment is not returned from the partner node due to the occurrence of a reset that clears the topology information of the node, data transfer is disabled. A state transition is made to a state. As described above, when the acknowledgment is not returned from the partner node, it is unknown whether or not the partner node has received the status. Therefore, in such a case, if the data transfer is started from the continuation of the reset, the erroneous data transfer may be performed. According to the present invention, if an acknowledgment is not returned from the partner node due to a reset that clears the topology information of the node, the state transition to the data transfer disabled state is made, The situation in which the transfer is performed can be prevented.
[0019]
The present invention is also a data transfer control device for data transfer between a plurality of nodes connected to a bus, wherein a command packet for a data transfer operation request transferred from a partner node is a command packet. When the identification information for identification is included, the first identification information included in the first command packet transmitted before the occurrence of the reset for clearing the topology information of the node, and the first identification information transmitted after the occurrence of the reset A command comparing means for comparing with the second identification information included in the second command packet; and when the first and second identification information are the same, the data transfer is performed from the continuation of the data transfer at the time of occurrence of the reset. Resuming means for resuming.
[0020]
According to the present invention, when the first and second identification information are the same, the data transfer is restarted from the continuation of the reset occurrence point. On the other hand, when the first and second addresses are not the same, for example, the transfer data after the occurrence of the reset is processed as new transfer data. Therefore, it is possible to solve a problem that data is redundantly transferred to a device in an upper layer of the data transfer control device and a device in an upper layer malfunctions.
[0021]
In addition, according to the present invention, the status of data transfer completion is transferred to the partner node, but if an acknowledgment is not returned from the partner node due to the occurrence of a reset that clears the topology information of the node, the partner node returns It is characterized in that whether or not a data transfer completion status is received is determined based on identification information included in the command packet. In this case, when the status acknowledgment is not returned from the partner node, the state of the data transfer control device does not need to be changed to the data transfer disabled state.
[0022]
In the present invention, it is desirable that the reset is a bus reset defined in the IEEE 1394 standard.
[0023]
According to another aspect of the present invention, there is provided an information storage medium including a program for controlling data transfer with any one of the above data transfer control devices, wherein a reset for clearing topology information of the node occurs during the data transfer. In this case, the data transfer operation is performed so that the first address which is the head address of the transfer data before the occurrence of the reset is the same as the second address which is the head address of the transfer data after the occurrence of the reset. It includes a program for creating a command packet for a request and requesting the data transfer control device to transfer the command packet. With this configuration, when the first and second addresses are the same, the data transfer control device can determine that the transfer data is the same as before the occurrence of the reset, and the first and second addresses are the same. If not, it can be determined that the transfer data is different from that before the reset occurred. This can prevent a situation in which erroneous data transfer is performed.
[0024]
According to the present invention, there is also provided an information storage medium including a program for controlling data transfer to or from any of the above data transfer control devices, wherein a given field of a command packet for a data transfer operation request is provided. And a program for writing identification information for identifying the command packet to the data transfer control device and requesting the data transfer control device to transfer the command packet in which the identification information is written. With this configuration, when the first and second identification information are the same, the data transfer control device can determine that the transfer data is the same as before the occurrence of the reset, and the first and second identification information Are not the same, it can be determined that the transfer data is different from before the occurrence of the reset. This can prevent a situation in which erroneous data transfer is performed.
[0025]
Further, an electronic apparatus according to the present invention includes any one of the data transfer control devices described above, a device that performs given processing on data received from a partner node via the data transfer control device and a bus, and And a device for outputting or storing the data. Further, an electronic apparatus according to the present invention includes any one of the above-described data transfer control devices, a device for performing a given process on data to be transmitted to a partner node via the data transfer control device and a bus, and a process. And a device for capturing data.
[0026]
According to the present invention, it is possible to prevent a situation in which a failure occurs in a system due to occurrence of a reset for clearing topology information of a node, and prevent a malfunction of an electronic device. Further, the speed of data transfer can be increased, the cost of the electronic device can be reduced, and the processing speed of the electronic device can be increased.
[0027]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings.
[0028]
1. IEEE 1394
First, IEEE 1394 will be briefly described.
[0029]
1.1 Overview
In IEEE 1394 (IEEE 1394-1995, P1394.a), high-speed data transfer of 100 to 400 Mbps is possible (800 to 3200 Mbps in P1394.b). It is also allowed to connect nodes having different transfer speeds to the bus.
[0030]
Each node is connected in a tree shape, and a maximum of 63 nodes can be connected to one bus. If a bus bridge is used, about 64000 nodes can be connected.
[0031]
In IEEE 1394, asynchronous transfer and isochronous transfer are prepared as packet transfer methods. Here, the asynchronous transfer is a transfer method suitable for data transfer requiring reliability, and the isochronous transfer is a transfer method suitable for transfer of data such as moving images and voices requiring real-time characteristics.
[0032]
1.2 Layer structure
FIG. 1 shows the layer structure (protocol configuration) of IEEE1394.
[0033]
The IEEE 1394 protocol includes a transaction layer, a link layer, and a physical layer. The serial bus management monitors and controls the transaction layer, link layer, and physical layer, and provides various functions for controlling nodes and managing bus resources.
[0034]
The transaction layer provides an interface (service) in transaction units to an upper layer, and executes transactions such as a read transaction, a write transaction, and a lock transaction through an interface provided by a lower link layer.
[0035]
Here, in the read transaction, data is transferred from the response node to the request node. On the other hand, in a write transaction, data is transferred from a request node to a response node. In a lock transaction, data is transferred from a request node to a response node, and the response node processes the data and returns it to the request node.
[0036]
The link layer provides addressing, data check, data framing for packet transmission / reception, cycle control for isochronous transfer, and the like.
[0037]
The physical layer provides the conversion of logical symbols used by the link layer to electrical signals, bus arbitration, and physical bus interfaces.
[0038]
1.3 SBP-2
As shown in FIG. 2, a protocol called SBP-2 (Serial Bus Protocol-2) has been proposed as a higher-level protocol including a part of the function of the transaction layer of IEEE1394.
[0039]
Here, SBP-2 has been proposed to make the SCSI command set available on the IEEE 1394 protocol. If this SBP-2 is used, the SCSI command set that has been used in the existing SCSI standard electronic device can be minimally changed and used in the IEEE 1394 standard electronic device. Therefore, the design and development of the electronic device can be facilitated. Since not only SCSI commands but also device-specific commands can be encapsulated and used, the versatility is very high.
[0040]
As shown in FIG. 3, in SBP-2, first, a login process is performed using a login ORB (Operation Request Block) created by an initiator (for example, a personal computer) (step T1). Next, the fetch agent is initialized using the dummy ORB (step T2). Then, command processing is performed using the command block ORB (normal command ORB) (step T3), and finally, logout processing is performed using the logout ORB (step T4).
[0041]
Here, in the command processing of step T3, as shown by A1 in FIG. 4, the initiator transfers the write request packet (issues a write request transaction) and rings the doorbell register of the target. Then, as indicated by A2, the target transfers the read request packet, and the initiator returns a corresponding read response packet. As a result, the ORB (command block ORB) created by the initiator is fetched into the target data buffer. Then, the target analyzes the command included in the fetched ORB.
[0042]
If the command included in the ORB is a SCSI write command, the target transfers the read request packet to the initiator, and the initiator returns a corresponding read response packet, as indicated by A3. Thereby, the data stored in the data buffer of the initiator is transferred to the target. Then, for example, when the target is a printer, the transferred data is printed by the printer engine.
[0043]
On the other hand, if the command included in the ORB is a SCSI read command, the target transfers a series of write request packets to the initiator, as indicated by B1 in FIG. Thereby, for example, when the target is a scanner, the scan data acquired by the scanner engine is transferred to the data buffer of the initiator.
[0044]
According to this SBP-2, the target can transfer a request packet (issue a transaction) and transmit and receive data when it is convenient. Therefore, since the initiator and the target do not need to move in synchronization, the data transfer efficiency can be improved.
[0045]
In addition to SBP-2, a protocol called FCP (Function Control Protocol) has been proposed as an upper protocol of IEEE1394.
[0046]
When data is transferred between a target and an initiator, there is a case where a page table exists in a data buffer (storage means) of an initiator (a partner node) as shown in FIG.
[0047]
When a page table exists, as shown in FIG. 6B, the address and the number of elements of the page table are included in the ORB created by the initiator. The address (read address, write address) of the transfer data is specified indirectly using this page table.
[0048]
On the other hand, when the page table does not exist, as shown in FIG. 6C, the address and the data length are included in the ORB, and the address of the transfer data is directly specified.
[0049]
1.4 Bus reset
In IEEE 1394, a bus reset occurs when power is turned on or when a device is inserted or removed halfway. That is, each node monitors a voltage change of the port. Then, when a change occurs in the port voltage due to a connection of a new node to the bus or the like, the node that has detected the change notifies other nodes on the bus that a bus reset has occurred. The physical layer of each node informs the link layer that a bus reset has occurred.
[0050]
When such a bus reset occurs, topology information such as a node ID is cleared. After that, the topology information is automatically reset. That is, after the bus reset, tree identification and self-identification are performed. Thereafter, management nodes such as an isochronous resource manager, a cycle master, and a bus manager are determined. Then, the normal packet transfer is restarted.
[0051]
As described above, in the IEEE 1394, topology information is automatically reset after a bus reset, so that a cable of an electronic device can be freely connected and disconnected, and a so-called hot plug can be realized.
[0052]
If a bus reset occurs during a transaction, the transaction is canceled. Then, the request node that has issued the canceled transaction transfers the request packet again after the topology information is reset. The response node must not return a response packet of the transaction canceled by the bus reset to the request node.
[0053]
2. overall structure
Next, an example of the overall configuration of the data transfer control device of the present embodiment will be described with reference to FIG. In the following, a case will be described as an example where the target that performs data transfer with the initiator is a printer, but the present invention is not limited to this.
[0054]
The data transfer control device 10 of the present embodiment includes a PHY device 12 (physical layer device), a link device 14 (link layer device), a CPU 16 (central processing unit), a data buffer 18 (storage means), a firmware 20 (processor )including. The PHY device 12, the link device 14, the CPU 16, and the data buffer 18 are optional components, and the data transfer control device 10 of the present embodiment does not need to include all of these components.
[0055]
The PHY device 12 is a circuit for realizing the physical layer protocol of FIG. 1 by hardware, and has a function of converting a logical symbol used by the link device 14 into an electric signal.
[0056]
The link device 14 is a circuit for implementing a part of the protocol of the link layer and the protocol of the transaction layer in FIG. 1 by hardware, and provides various services for packet transfer between nodes.
[0057]
The CPU 16 controls the entire apparatus and controls data transfer.
[0058]
The data buffer 18 is a buffer for temporarily storing transfer data (packets), and is configured by hardware such as an SRAM, an SDRAM, or a DRAM. Note that, in the present embodiment, the data buffer 18 functions as a packet storage unit that can be randomly accessed.
[0059]
The firmware 20 is a program including various processing routines (processing modules) operating on the CPU 16, and a protocol of a transaction layer is realized by the firmware 20 and the hardware such as the CPU 16.
[0060]
The device driver 102 included in the personal computer 100 as an initiator is a program including various processing routines for managing and controlling peripheral devices. This program is installed in the personal computer 100 using the information storage medium 110 (FD, CD-ROM, DVD, ROM).
[0061]
Here, the program of the device driver 102 may be downloaded from an information storage medium (hard disk, magnetic tape, or the like) of the host system via a network such as the Internet, and installed in the personal computer 100. Use of the information storage medium of such a host system is also included in the scope of the present invention.
[0062]
The firmware 20 (F / W) includes a communication unit 30 (COM), a management unit 40 (MNG), a print task unit 50 (PRT), and a fetch unit 60 (FCH).
[0063]
Here, the communication unit 30 is a processing module that functions as an interface with hardware such as the link device 14.
[0064]
The management unit 40 (management agent) is a processing module that manages login, reconnect, logout, reset, and the like. For example, when the initiator requests the target to log in, the management unit 40 first receives the login request.
[0065]
The print task unit 50 is a processing module that performs a data transfer process with a printer engine, which is a subsequent application layer (upper layer).
[0066]
The fetch unit 60 (fetch agent, command block agent) is a processing module for executing a command included in the command block ORB. Unlike the management unit 40, which can handle only a single request, the fetch unit 60 can also handle a linked list of ORBs fetched by itself in response to a request from the initiator.
[0067]
The fetch unit 60 includes a determination unit 62, a command storage unit 64, a command comparison unit 66, an address storage unit 68, an address comparison unit 70, and a data transfer restart unit 72.
[0068]
Here, the determination unit 62 determines whether or not a bus reset (in a broad sense, a reset for clearing the topology information of the node) has occurred during the data transfer period for transferring the print data with the initiator (the partner node). Perform a process to determine.
[0069]
The command storage unit 64 stores the contents of the ORB (command block ORB; command packet for a data transfer operation request) transferred from the initiator before the occurrence of the bus reset, at the time when the bus reset occurs and at the time of reconnect. A process for storing the information is performed at a time when the operation is successful.
[0070]
The command comparison unit 66 has the contents of the ORB (command block ORB) transferred from the initiator before the occurrence of the bus reset (the contents stored by the command storage unit 64) and transferred from the initiator after the occurrence of the bus reset. A process for comparing the contents of the ORB is performed.
[0071]
The address storage unit 68 performs a process for storing a start address (first address) of transfer data (print data) transferred to and from the initiator.
[0072]
When a bus reset occurs, the address comparing unit 70 compares the start address (first address) stored in the address storage unit 68 with the start address (second address) of the transfer data after the bus reset occurs. Perform comparison processing.
[0073]
The data transfer resuming unit 72 performs the data transfer at the time of the occurrence of the bus reset when the start address of the transfer data matches before and after the occurrence of the bus reset or when the contents of the ORB (command block ORB) match. A process of restarting data transfer from the continuation (the data next to the data transferred at the time of occurrence of the bus reset) is performed.
[0074]
3. Overview of processing
Next, an outline of the processing of the present embodiment will be described.
[0075]
FIG. 8 is a flowchart showing an outline of processing on the target side (firmware).
[0076]
When there is a print request from the initiator, the target reads the ORB from the data buffer of the initiator (step S1). If the page table exists, the page table is read from the data buffer of the initiator based on the page table address (see FIG. 6B) included in the ORB (step S2). Next, print data is read from the data buffer of the initiator based on the read page table (step S3). When all the print data specified by the page table is read, the status is written, and the status such as whether or not the data transfer is successful is transmitted to the initiator (step S4). The above processing is repeated until all the print data is transferred (step S5).
[0077]
In this embodiment, when a bus reset occurs during transfer of print data (data transfer period), the following processing is performed at the time of the first print request after reconnection.
[0078]
That is, first, it is determined whether or not the contents of the ORB and the head address of the print data before the bus reset are the same as the contents of the ORB and the head address of the print data after the bus reset (step S6). If it is determined that they are the same, the data transfer is restarted from the continuation of the time when the bus reset occurred (step S7). On the other hand, if it is determined that they are not the same, the ORB after the bus reset is processed from the beginning as a new ORB (step S8).
[0079]
FIG. 9 is a flowchart showing an outline of processing on the initiator side (device driver).
[0080]
When a print job is generated from the application program, the initiator creates an ORB or a page table for printing and writes the created ORB or page table in the data buffer (step S10). Next, the target is instructed to read the created ORB (step S11; see A1 in FIG. 4).
[0081]
Next, it is determined whether or not a bus reset has occurred (step S12). If not, it is determined whether or not a status has been sent from the target (step S13). Then, if sent, it is determined whether or not all the print data has been transferred (step S14). If not, the process returns to step S10. finish.
[0082]
In this embodiment, when it is determined in step S12 that a bus reset has occurred, the initiator re-creates the ORB and the page table (step S15), and instructs the target to read the re-created ORB. (Step S11). In this case, the initiator (device driver) sets the ORB so that the contents of the ORB and the start address of the print data before the occurrence of the bus reset are the same as the contents of the ORB and the start address of the print data after the occurrence of the bus reset. Recreate.
[0083]
4. Features of this embodiment
By the way, it has been found that when a bus reset occurs during transfer of print data, the following problem occurs.
[0084]
For example, as shown in FIG. 10A, suppose that a bus reset occurs when data is transferred to the position (address) indicated by C1. In this case, all transactions being processed at the time of the occurrence of the bus reset are all canceled. Therefore, the initiator that has requested the transfer of the print data before the bus reset creates an ORB for printing again after the bus reset and restarts the transfer of the print data from the beginning, as shown in FIG. To target. Therefore, the data transfer is restarted from the position indicated by C2 in FIG. 10B, and only a part of the print data is sent twice. As a result, a problem of double printing as shown in FIG. 10C occurs.
[0085]
In order to solve such a problem, the present embodiment employs a method described below.
[0086]
That is, in the present embodiment, as shown in FIG. 11, the head address (bus address) AD1 of the transfer data specified by the page table of the ORB before the bus reset is stored.
[0087]
When a bus reset occurs, the stored start address AD1 is compared with the start address AD2 of the transfer data specified by the page table of the ORB after the bus reset (see step S6 in FIG. 8). ).
[0088]
If AD1 and AD2 are the same, it is determined that the transfer data before the bus reset and the transfer data after the bus reset are the same, and as indicated by D1, the data transfer starts from the continuation of the data transfer when the bus reset occurs. The transfer is restarted (see step S7 in FIG. 8). That is, the data transfer is restarted from the data next to the data that has already been transferred when the bus reset occurs.
[0089]
On the other hand, if AD1 and AD2 are not the same, it is determined that the transfer data after the bus reset is completely new transfer data, and processing is performed from the beginning (see step S8 in FIG. 8).
[0090]
By doing so, the transfer data of the portion indicated by D2 in FIG. 11 is not double-transferred, unlike the case of FIG. 10B. Therefore, erroneous printing as shown in FIG. 10C does not occur. Further, since double transfer can be avoided, the transfer time can be reduced.
[0091]
The present embodiment is characterized in that even if a bus reset occurs, the head address of the transfer data on the data buffer of the initiator is not changed.
[0092]
That is, when a bus reset occurs, the initiator recreates the ORB and the page table, and thus the configuration of the page table may be changed.
[0093]
On the other hand, since the start address of the transfer data (the position of the transfer data) is determined by the application program or the like, the start address does not change even if a bus reset occurs.
[0094]
The present embodiment pays attention to this point, and determines that the same transfer data has been sent if the start address of the transfer data is the same before the bus reset and after the bus reset.
[0095]
For example, as a method different from this embodiment, a method in which data transfer is always restarted from the continuation of the bus reset occurrence point without performing the comparison process of the head address can be considered.
[0096]
However, according to this method, for example, even if the initiator cancels the print data transfer process after the bus reset and creates an ORB completely different from that before the bus reset, the data transfer is restarted from D1 in FIG. Failure occurs.
[0097]
On the other hand, in the present embodiment, if the head address of the transfer data is the same before and after the bus reset, the data transfer is restarted from D1 in FIG. 11, but if not, it is processed as a completely new ORB. Therefore, the above-described problem does not occur.
[0098]
In the present embodiment, when the transfer data is transferred using the page table, specifically, the comparison processing of the start address of the transfer data is performed as follows.
[0099]
That is, as shown in FIG. 12, first, the start address AD1 stored in the start segment SEG1 in the page table of the ORB before the bus reset is different from the page table storage area (the area on the target data buffer). Area. Then, the stored AD1 is compared with the head address AD2 stored in the head segment SEG1 in the page table of the ORB after the bus reset.
[0100]
Consider the case where the page table has, for example, 128 segments. In this case, if all 128 segments are read at once from the initiator and stored in the page table storage area on the target data buffer, the storage capacity required to store the page table increases unnecessarily.
[0101]
Therefore, in the present embodiment, the segments of the page table are read, for example, by eight, and these eight segments are written in the page table storage area on the target data buffer. By doing so, the used storage area of the page table storage area can be saved.
[0102]
However, in this case, for example, when the first eight segments are read and written in the page table storage area, and then the next eight segments are read and overwritten in the page table storage area, the first eight segments are read. There is a problem that the segment information is lost and the head address AD1 stored in the head segment SEG1 of the page table is also lost.
[0103]
According to the present embodiment, the head address AD1 stored in the head segment SEG1 of the page table is stored in an area different from the page table storage area. Therefore, it is possible to prevent the above-described inconvenience from occurring, and to save the used storage capacity of the page table storage area.
[0104]
In the present embodiment, the contents of the ORB (command block ORB) before the bus reset and the contents of the ORB after the bus reset are compared before the comparison processing of the head addresses AD1 and AD2.
[0105]
That is, as shown in FIG. 13, when the initiator succeeds in the reconnection after the bus reset occurs and creates a new ORB and requests transfer, first, the contents of the ORB before the bus reset and the ORB after the bus reset are performed. Compare the contents of Then, when the contents of the ORB are the same, it is compared for the first time whether or not the head address AD1 specified by the ORB before the bus reset is the same as the head address AD2 specified by the ORB after the bus reset.
[0106]
For example, when the OS (Operating System) that operates on the initiator personal computer is the first OS, the ORB may include identification information such as a sequence number as described later. Therefore, by comparing the contents of the ORB, it can be easily determined whether or not the transfer data by the ORB after the bus reset is the continuation of the transfer data by the ORB before the bus reset. Then, the contents of the ORB are compared first, and if it is determined that the contents of the ORB are not the same, the comparison processing of the head address can be omitted, so that the processing load can be reduced.
[0107]
On the other hand, when the OS of the initiator is the second OS, the ORB does not include identification information such as a sequence number. Therefore, in this case, by comparing the start addresses AD1 and AD2, it is possible to reliably determine whether or not the transfer data after the bus reset is continued after the bus reset.
[0108]
Further, as in the present embodiment, by performing both the comparison of the contents of the ORB and the comparison of the start address, the firmware does not need to be aware of whether the OS of the initiator is the first OS or the second OS. That is, regardless of whether the OS of the initiator is the first OS or the second OS, processing can be performed by the firmware having the same configuration, and the development period of the firmware can be shortened and the debugging work can be facilitated. .
[0109]
In this embodiment, various information other than the identification information is compared when comparing the contents of the ORB. For example, as shown in FIG. 14, in the present embodiment, the page table presence flag P included in the command block ORB, the data size, and the operation code (print command, read command, etc.) in the command block (command set) field are distinguished. Code) and data length. By comparing such information, it is possible to reliably determine whether or not the ORB before and after the bus reset is the same by a simple process.
[0110]
By the way, when the OS operating on the initiator's personal computer is the first OS (or the latest version of the second OS), the ORB identifies the sequence number and the like for identifying the ORBs. Contains information. That is, the device driver of the initiator writes the identification information of the ORB in a given field of the ORB.
[0111]
In such a case, as shown in FIG. 15, the identification information included in the ORB before the bus reset is compared with the identification information included in the ORB after the bus reset. When these pieces of identification information are the same, the data transfer is restarted from the continuation of the reset point, as shown at E1 in FIG. On the other hand, if they are not the same, the ORB after the bus reset is processed as a new ORB.
[0112]
By doing so, it is possible to determine by simple processing whether or not the transfer data after the bus reset (reconnect) is continued after the bus reset. Further, since it is possible to avoid double transfer of print data, it is possible to prevent erroneous printing such as double printing from occurring, and to shorten transfer time.
[0113]
As the identification information for identifying the ORB, various information other than the ORB sequence number can be considered. For example, a data address of data to be transferred by the ORB may be used as identification information. That is, when the target is a hard disk drive, a data sector address or the like can be used as ORB identification information.
[0114]
The timing of the occurrence of the bus reset is completely arbitrary. Therefore, for example, as shown in FIG. 16, the target has transferred the data transfer completion status to the initiator, but due to the occurrence of the bus reset, ACK (ACK complete) is not returned from the initiator, and May be.
[0115]
In such a case, the first case in which the initiator did not receive the status due to the occurrence of the bus reset and the ACK was missed, and the initiator received the status and returned the ACK, but the bus reset occurred. A second case in which the occurrence is a cause of ACK missing is considered.
[0116]
Then, in the first case, the initiator considers that the data transfer was unsuccessful, and performs the first process of creating the same ORB again after the bus reset. On the other hand, in the second case, the initiator considers that the data transfer has succeeded, and performs the second process of creating the next ORB after the bus reset.
[0117]
However, since only information that ACK has been missed is transmitted to the target, the target cannot know which of the first and second processes has been performed by the initiator. Therefore, in such a case, if data transfer is started from the continuation of the bus reset point, erroneous data transfer may be performed.
[0118]
Thus, in the present embodiment, as shown in FIG. 16, if an acknowledgment is not returned from the initiator due to the occurrence of a bus reset, the state transits to a dead state (data transfer disabled state). By doing so, a situation in which erroneous data transfer is performed can be prevented.
[0119]
If the identification information described with reference to FIG. 15 is always included in the ORB, it is determined whether the initiator has performed the first processing or the second processing (whether the initiator has received the data transfer completion status or not). 17), as shown in FIG. 17, the determination can be made by comparing the identification information included in the ORB.
[0120]
That is, when the identification information of the ORB before the bus reset is the same as the identification information of the ORB after the bus reset, it can be determined that the initiator has performed the first process. It can be determined that the processing has been performed. Therefore, the target can resume the data transfer from the continuation of the bus reset occurrence point without transition to the dead state.
[0121]
5. Detailed processing example
Next, a detailed processing example of the present embodiment will be described with reference to the flowcharts of FIGS.
[0122]
18 to 20 are flowcharts showing a detailed example of a process when a bus reset occurs (at the time of reconnect).
[0123]
When a bus reset occurs, the target first determines whether or not the initiator has logged in (step S20). If the initiator has logged in, the target cancels all transfer processing (transactions) on the IEEE 1394 bus (step S20). Step S21). On the other hand, if the user has not logged in, no special processing is required even if a bus reset occurs, so nothing is performed (step S22).
[0124]
Next, it is determined whether or not the bus reset processing has already been started (step S23). Thereby, when a bus reset occurs a plurality of times, it is possible to prevent a situation where the bus reset processing corresponding to the bus reset is unnecessarily repeated a plurality of times.
[0125]
Next, the state of ACK (acknowledgement) at the time of occurrence of the bus reset is stored (step S24). As a result, it is possible to prevent a situation in which the contents of the ACK immediately after the bus reset are erased by a subsequent transaction (for example, a reconnect transaction).
[0126]
Next, the size (the number of bytes) of the data transferred on the IEEE 1394 bus is stored (step S25). That is, the size of the transferred data in the segment being processed when the bus reset occurs is stored. Then, for the determination in step S23, a flag indicating that the bus reset process is being performed is turned on (step S26). That is, when this flag is turned on, even if a bus reset occurs thereafter, the processing of steps S24 to S26 is not performed.
[0127]
Next, it waits for a connection from the initiator (step S27), and determines whether or not the connection has been made by the initiator (step S28). If the reconnection has not been performed, it is determined whether or not the reconnect timeout time specified in the reconnect field of the login ORB has elapsed (step S29). When the time has elapsed, the continuation flag (a flag indicating that data transfer may be continued and restarted) is turned off (step S30), and the state transitions to the logout state (step S31).
[0128]
On the other hand, when the reconnection is performed within the reconnect timeout period, it is determined whether or not the initiator that has reconnected is the initiator that has logged in before the bus reset (step S32). Rejects the initiator's reconnect and returns to the reconnect wait.
[0129]
When the same initiator as before the bus reset has logged in, it is determined whether or not the command block ORB for printing (the ORB including the print command) was being processed at the time of the occurrence of the bus reset (step S33 in FIG. 19). ). If the processing is not being performed, the continuation flag is turned off (step S36), and the state transitions to the idle state (step S37).
[0130]
On the other hand, if the command block ORB for printing is being processed, it is determined whether or not a bus reset has occurred while the status is being written (the period from when the status is written until the ACK is returned). (Step S34). If a bus reset occurs while the status is being written, it is determined whether or not the ACK is complete based on the ACK information stored in step S24 of FIG. 18 (step S35).
[0131]
Then, in the case of ACK complete, the continuation flag is turned off (step S36), and the state transits to the idle state (step S37). On the other hand, if it is not ACK complete, it is determined whether or not ACK is missing (step S38). If it is not ACK missing, nothing is performed (step S39). If it is ACK missing, the continuation flag is turned off (step S40), and the dead state (data transfer disabled state) as described with reference to FIG. Transition is made (step S41).
[0132]
If it is determined in step S34 that the occurrence of the bus reset is not during the writing of the status, it is determined whether or not even one byte of the transfer (print) data of the ORB being processed has been transferred to the subsequent printer engine (step S34). S42). If no byte has been transferred, the continuation flag is turned off (step S43), and the state transitions to the idle state (step S49).
[0133]
On the other hand, if even one byte has been transferred to the printer engine, the contents of the ORB (data size, page table presence flag P, command block) and the size of the data transferred until the bus reset occurs are stored ( Step S44).
The size of this data is determined by the number of bytes of data that has already been transferred to the subsequent printer engine at the time of the bus reset, and the data transfer on the IEEE 1394 bus has already been completed at the time of the bus reset, and is being transferred to the subsequent printer engine. Or it corresponds to the total number of bytes of data to be transferred from now on. That is, for example, it corresponds to the sum of the number of bytes of data already printed by the printer and the number of bytes of data currently being printed by the printer or to be printed.
[0134]
Next, it is determined whether or not a page table exists (step S45). If not, the contents of the ORB data scripter are stored (step S46). That is, when the page table does not exist, the address and data length of the transfer data in the case of direct address designation are stored (see FIG. 6C).
[0135]
On the other hand, if the page table exists, the contents (address, data length) of the first segment of the page table, the contents (address, data length) of the segment being processed at the time of the occurrence of the bus reset, and the segment number are stored. (Step S47). Then, the continuation flag is turned on (step S48), and the state transitions to the idle state (step S49).
[0136]
FIGS. 21 and 22 are flowcharts showing a detailed example of the normal processing.
[0137]
First, it is determined whether or not the initiator has instructed to read the ORB (whether or not the doorbell register has been ringed) (step S51). If not, the idle state is maintained (step S50). On the other hand, when instructed, the ORB created by the initiator is read from the initiator (step S52). Then, it is determined whether or not a page table exists based on the page table presence flag P included in the ORB (step S53). If there is a page table, the segments of the page table are read, for example, by eight segments (step S54).
[0138]
Next, based on the operation code in the ORB command block, it is determined whether or not the read ORB is the command block ORB for printing (step S55). If it is a command block ORB for printing, it is determined whether the eight segments read in step S54 are the first eight segments (eight segments including the head segment) of the page table (step S56). If it is the first eight segments, the process proceeds to the command / address comparison process shown in FIG. 22 (step S57).
[0139]
If it is determined in step S55 that the command block is not a command block ORB for printing, if it is determined in step S56 that it is not the first eight segments, and if the command / address comparison processing in step S57 is completed, the data Is performed (step S58). The process is repeated until data for one segment and data for eight segments are read / written (steps S59 and S60).
[0140]
Next, it is determined whether or not all segments of the page table have been read / written (step S61). If not all segments have been read / written, the next eight segments of the page table are read (step S61). Step S54). On the other hand, if all the segments of the page table have been read, the status is written to the initiator (step S62). Then, it is determined whether or not all the ORBs for printing the printed material have been read (step S63). If there is the next ORB, the process returns to step S52. If there is no next ORB, the state is set to the idle state. Transition is made (step S50).
[0141]
If it is determined in step S53 that the page table does not exist, it is determined whether the read ORB is a command block ORB for printing (step S64). If it is the command block ORB for printing, the process proceeds to the command / address comparison process shown in FIG. 22 (step S65).
[0142]
On the other hand, when it is determined that the command block is not the command block ORB for printing, and when the command / address comparison processing is completed, data is read / written (step S66), and all data is read / written. Repeat until (Step S67). If all the data has been read / written, the process proceeds to step S62, and the status is written to the initiator.
[0143]
In the command / address comparison processing of FIG. 22, first, it is determined whether or not the continuation flag is on (step S70). This continuation flag is a flag that is turned on in step S48 of FIG. If the continuation flag is off, the process proceeds to step S76, where the head address of the transfer data (the address of the head segment of the page table) is stored as described in FIG. 12, and the command / address comparison processing ends. .
[0144]
If the continuation flag is ON, as described with reference to FIGS. 13 and 14, it is determined whether or not the contents of the read ORB are the same as the contents of the ORB before the bus reset (step S71). In this case, the contents of the ORB before the bus reset to be compared are stored in step S44 in FIG. As described with reference to FIG. 13, in the present embodiment, prior to the address comparison (step S72), the contents of the ORB are compared (step S71).
[0145]
If the contents of the ORB are the same as before the bus reset, it is determined whether or not the head address of the transfer data is the same as before the bus reset as described with reference to FIG. 11 (step S72). If they are the same, the data transfer setting is returned to the state before the occurrence of the bus reset (step S73). In other words, based on the transferred data size up to the bus reset occurrence point stored in step S44 of FIG. 20, the contents of the segment and the segment number stored in step S47, etc., the position indicated by D1 in FIG. The data transfer setting is returned to the state before the bus reset so that the data transfer can be resumed from (continuation). Then, the continuation flag is turned off (step S74). In this case, the data in the target data buffer is not cleared so that the data that has already been transferred before the bus reset is not lost.
[0146]
It should be noted that the reason why the head address of the transfer data is not stored after step S74 as in step S76 is that the data is stored before the bus reset occurs when the data transfer is restarted from the continuation of the bus reset. This is because the head address set can be used as it is.
[0147]
If it is determined in step S71 that the contents of the ORB are not the same as before the bus reset, or if it is determined in step S72 that the head address is not the same as before the bus reset, the data transfer restart process is not performed and the continuation flag is set. The data is returned to off and the head address of the transfer data is stored (steps S75 and S76). That is, in this case, the read ORB is processed as a completely new ORB.
[0148]
In the case of step S75, since the read ORB is processed from the beginning, unlike step S74, the data in the target data buffer is cleared.
[0149]
6. Electronics
Next, an example of an electronic device including the data transfer control device of the present embodiment will be described.
[0150]
For example, FIG. 23A shows an internal block diagram of a printer which is one of the electronic devices, and FIG. 24A shows an external view thereof. A CPU (microcomputer) 510 controls the entire system. The operation unit 511 is for the user to operate the printer. The ROM 516 stores control programs, fonts, and the like, and the RAM 518 functions as a work area for the CPU 510. The display panel 519 is for notifying the user of the operation state of the printer.
[0151]
Print data sent from a partner node such as a personal computer via the PHY device 502 and the data transfer control device 500 is sent directly to the print processing unit (printer engine) 512 via the bus 504. The print data is subjected to given processing in a print processing unit 512, and is printed and output on paper by a print unit (device for outputting data) 514 including a print header and the like.
[0152]
FIG. 23B shows an internal block diagram of a scanner which is one of the electronic devices, and FIG. 24B shows an external view thereof. The CPU 520 controls the entire system. The operation unit 521 is for the user to operate the scanner. The ROM 526 stores a control program and the like, and the RAM 528 functions as a work area of the CPU 520.
[0153]
An image of a document is read by an image reading unit (device for capturing data) 522 including a light source, a photoelectric converter, and the like, and data of the read image is processed by an image processing unit (scanner engine) 524. Then, the processed image data is sent directly to the data transfer control device 500 via the bus 505. The data transfer control device 500 generates a packet by adding a header or the like to the image data, and transmits the packet to a partner node such as a personal computer via the PHY device 502.
[0154]
FIG. 23C shows an internal block diagram of a CD-RW drive which is one of the electronic devices, and FIG. 24C shows an external view thereof. The CPU 530 controls the entire system. The operation unit 531 is for the user to operate the CD-RW. The ROM 536 stores a control program and the like, and the RAM 538 functions as a work area of the CPU 530.
[0155]
Data read from the CD-RW 532 by a read / write unit (device for taking in data or storing data) 533 including a laser, a motor, an optical system, etc. is input to a signal processing unit 534, and an error is generated. Given signal processing such as correction processing is performed. Then, the signal-processed data is sent directly to the data transfer control device 500 via the bus 506. The data transfer control device 500 generates a packet by adding a header or the like to this data, and transmits the packet to a partner node such as a personal computer via the PHY device 502.
[0156]
On the other hand, data sent from the partner node via the PHY device 502 and the data transfer control device 500 is sent directly to the signal processing unit 534 via the bus 506. The data is subjected to given signal processing by the signal processing unit 534, and is stored in the CD-RW 532 by the reading and writing unit 533.
[0157]
23A, 23B, and 23C, a CPU for controlling data transfer in the data transfer control device 500 may be separately provided in addition to the CPUs 510, 520, and 530.
[0158]
Although the RAM 501 (corresponding to a data buffer) is provided outside the data transfer control device 500 in FIGS. 23A, 23B, and 23C, the RAM 501 may be built in the data transfer control device 500. Good.
[0159]
When the data transfer control device according to the present embodiment is used for an electronic device, even when a new electronic device is connected to the bus and a bus reset occurs, the occurrence of a failure due to the bus reset is prevented. Thereby, malfunction of the electronic device can be prevented.
[0160]
If the data transfer control device of the present embodiment is used in an electronic device, high-speed data transfer becomes possible. Therefore, when the user gives a printout instruction using a personal computer or the like, printing is completed with a small time lag. Further, after the instruction to take in the image to the scanner, the user can view the read image with a small time lag. Further, it becomes possible to read data from the CD-RW and write data to the CD-RW at high speed.
[0161]
Further, by using the data transfer control device of the present embodiment in an electronic device, the processing load of firmware operating on the CPU is reduced, and an inexpensive CPU and a low-speed bus can be used. Further, since the cost and the size of the data transfer control device can be reduced, the cost and the size of the electronic device can be reduced.
[0162]
Electronic devices to which the data transfer control device of the present embodiment can be applied include, in addition to the above, various types of optical disk drives (CD-ROM, DVD), magneto-optical disk drives (MO), hard disk drives, TVs, VTRs, and the like. Various things such as a video camera, an audio device, a telephone, a projector, a personal computer, an electronic organizer, and a word processor can be considered.
[0163]
The present invention is not limited to the present embodiment, and various modifications can be made within the scope of the present invention.
[0164]
For example, the configuration of the data transfer control device of the present invention is particularly preferably the configuration shown in FIG. 7, but is not limited thereto.
[0165]
Also, the method described in the present embodiment is particularly preferable as the method of comparing the start address, the method of comparing commands, and the method of resuming data transfer, but is not limited thereto.
[0166]
The present invention is particularly useful for bus reset in IEEE 1394, but may be applied to any other reset that clears at least the topology information of the node.
[0167]
The present invention is particularly preferably applied to data transfer in the IEEE 1394 standard, but is not limited thereto. For example, the present invention can be applied to data transfer based on a standard based on the same concept as IEEE 1394 or a standard developed from IEEE 1394.
[Brief description of the drawings]
FIG. 1 is a diagram showing a layer structure of IEEE1394.
FIG. 2 is a diagram for explaining SBP-2.
FIG. 3 is a diagram for explaining an outline of a data transfer process of SBP-2;
FIG. 4 is a diagram for describing command processing when data is transferred from an initiator to a target.
FIG. 5 is a diagram illustrating command processing when data is transferred from a target to an initiator.
FIGS. 6A, 6B, and 6C are diagrams for explaining a page table; FIG.
FIG. 7 is a diagram illustrating a configuration example of a data transfer control device according to the present embodiment.
FIG. 8 is a flowchart illustrating an outline of processing on a target side (firmware).
FIG. 9 is a flowchart illustrating an outline of processing on an initiator side (device driver).
FIGS. 10A, 10B, and 10C are diagrams for explaining the problem of double printing.
FIG. 11 is a diagram for explaining a method of continuing and resuming data transfer based on a comparison result of a start address of transfer data.
FIG. 12 is a diagram for explaining a method of comparing the start addresses of transfer data.
FIG. 13 is a diagram for explaining a method of performing command comparison prior to address comparison.
FIG. 14 is a diagram for explaining a content comparison of ORBs;
FIG. 15 is a diagram for explaining a method of continuing and resuming data transfer based on a comparison result of ORB identification information.
FIG. 16 is a diagram for describing a method of shifting to a dead state when a bus reset occurs during status writing and ACK missing occurs.
FIG. 17 is a diagram for explaining a method of determining whether or not an initiator has received a status based on identification information included in an ORB when a bus reset occurs during status writing and ACK missing occurs. is there.
FIG. 18 is a flowchart illustrating a detailed processing example of the present embodiment when a bus reset occurs (at the time of reconnection).
FIG. 19 is a flowchart illustrating a detailed processing example of the present embodiment when a bus reset occurs (at the time of reconnection).
FIG. 20 is a flowchart illustrating a detailed processing example of the present embodiment when a bus reset occurs (at the time of reconnect).
FIG. 21 is a flowchart illustrating a detailed process example of the present embodiment in a normal state.
FIG. 22 is a flowchart illustrating a detailed processing example of the present embodiment in a normal state.
FIGS. 23A, 23B, and 23C are examples of internal block diagrams of various electronic devices.
FIGS. 24A, 24B, and 24C are examples of external views of various electronic devices.
[Explanation of symbols]
10 Data transfer control device
12 PHY device
14 Link device
16 CPU
18 Data buffer
20 Firmware (F / W)
30 Communication Department (COM)
40 Management Department (MNG)
50 Print Task Unit (PRT)
60 Fetch unit (FCH)
62 Judgment unit
64 Command storage unit
66 Command Comparison Unit
68 Address storage unit
70 Address comparison unit
72 Data transfer restart section
100 personal computer
102 Device Driver
104 Data buffer
110 Information storage medium

Claims

A data transfer control device for data transfer between a partner node connected to the bus and the own node ,
Address storage means for storing a first address which is a head address of transfer data transferred to a partner node connected via a bus ;
When a reset that clears the topology information of the node and interrupts the data transfer occurs, the first address stored by the address storage unit and the second address that is the head address of the transfer data after the reset occurs. Address comparing means for comparing the address with the address;
The first, when the second address are the same, viewed contains a resuming unit that resumes the interrupted data transfer by a reset from the continuation of the data transfer of the reset generation time,
The address storage means,
In the case where transfer data is transferred using a page table, an address stored in the first segment of the page table is stored as the first address in an area different from the storage area of the page table. Data transfer control device.

In claim 1 ,
The contents of the first command packet for the data transfer operation request transferred from the partner node before the occurrence of the reset for clearing the topology information of the node, and the data transfer operation transferred from the partner node after the occurrence of the reset A data transfer control device comprising command comparison means for comparing the contents of a second command packet for a request with the first and second addresses before the comparison processing.

In claim 2 ,
The first and second command packets include identification information for identifying the command packet,
The command comparison means,
Prior to the comparison processing of the first and second addresses, the first identification information included in the first command packet is compared with the second identification information included in the second command packet. Data transfer control device.

In any one of claims 1 to 3 ,
When the status of data transfer completion is transferred to the partner node, but no acknowledgment is returned from the partner node due to the occurrence of a reset that clears the topology information of the node, the state transits to the data transfer disabled state. A data transfer control device, characterized in that:

In any one of claims 1 to 4 ,
The data transfer control device according to claim 1, wherein the reset is a bus reset defined in the IEEE 1394 standard.

A data transfer control device for data transfer between a partner node connected to the bus and the own node ,
If the command packet for a data transfer operation request transferred from the partner node connected via the bus contains identification information for identifying the command packet, clear the node topology information and interrupt the data transfer A command for comparing the first identification information included in the first command packet transferred before the occurrence of the reset to be performed with the second identification information included in the second command packet transferred after the occurrence of the reset Means of comparison;
The first, when the second identification information are the same, resume the interrupted data transfer by a reset from the continuation of the data transfer of the reset generation time, the first, the second identification information is identical A restart means that does not perform the data transfer restart processing if there is no data transfer ;
A data transfer control device comprising:

In claim 6 ,
When the status of data transfer completion is transferred to the partner node, but the acknowledgment is not returned from the partner node due to a reset that clears the node's topology information, the partner node returns the data transfer completion status. A data transfer control device, which determines whether or not a data packet has been received based on identification information included in a command packet.

In claim 6 or 7 ,
The data transfer control device according to claim 1, wherein the reset is a bus reset defined in the IEEE 1394 standard.

A computer-readable information storage medium storing a program for controlling data transfer with the data transfer control device according to claim 1 ,
When the reset for clearing the topology information of the node occurs during the data transfer, the first address which is the start address of the transfer data before the reset occurs and the start address of the transfer data after the reset occurs. An information storage medium comprising: a program for generating a command packet for a data transfer operation request so that the second address is the same as that of the second address, and causing a computer to function as a unit for requesting a transfer to a data transfer control device.

A computer-readable information storage medium storing a program for controlling data transfer with the data transfer control device according to claim 6 ,
The identification information for identifying the command packet is written in a given field of the command packet for the data transfer operation request, and the computer functions as a means for requesting the data transfer control device to transfer the command packet in which the identification information is written. An information storage medium containing a program.

A data transfer control device according to any one of claims 1 to 8 ,
A device for performing a given process on data received from the partner node via the data transfer control device and a bus,
An apparatus for outputting or storing the processed data.

A data transfer control device according to any one of claims 1 to 8 ,
An apparatus for performing a given process on data to be transferred to a partner node via the data transfer control device and a bus,
An electronic device comprising: a device for capturing data to be processed.