(57)【要約】【課題】  IEEE1394ベースのモーションネットワークでは、定周期性、同期性を得るため通信帯域の確保されたisochronous通信を応用しているが、そのために他のネットワークのように伝送エラー時に再送でリカバリーすることができないという課題があった。そこでIEEE1394の複数isochronousチャネルで同一データを冗長化して伝送させ伝送品質の信頼性を向上させながら、かつそのための処理負荷を軽減できるようにする。【解決手段】  IEEE1394 LINK層と上位アプリケーション間に送受信用バッファをおき、送受信バッファとLINK内の送受信FIFO間で冗長化を図りながらデータを受け渡す処理をLINKにて行わせる。【選択図】図１
2006186781.tif 000002
【特許請求の範囲】
【請求項１】
マスタと１台以上複数のスレーブとが、IEEE1394ネットワークで接続され、前記マスタと各スレーブ間におけるデータの送受信を、一定の伝送周期で、isochronous通信によって行うIEEE1394ベースモーションネットワークの伝送エラーリカバリー方法において、
一伝送周期において同一データを同一送信先へ複数のisochronousチャネルを使って送信し、前記一伝送周期において前記同一データを前記複数のisochronousチャネルを使って受信することを特徴とするIEEE1394ベースモーションネットワークの伝送エラーリカバリー方法。
【請求項２】
前記一伝送周期における同一データの同一送信先への前記複数のisochronousチャネルを使っての送信が、isochronousチャネル番号を決定し、isochronous送信FIFOに送信パケットをセットし、トランスミッタに送信を指示するステップを複数回繰り返すことを特徴とする請求項１に記載のIEEE1394ベースモーションネットワークの伝送エラーリカバリー方法。
【請求項３】
前記一伝送周期における同一データの前記複数のisochronousチャネルを使っての受信が、isochronous受信FIFOから受信データを読み出し、伝送エラーをチェックし、伝送エラーが無ければ前記受信データを受信したisochronousチャネルに対応した受信バッファに上書きするステップを複数回繰り返すことを特徴とする請求項１に記載のIEEE1394ベースモーションネットワークの伝送エラーリカバリー方法。
【請求項４】
マスタと１台以上複数のスレーブとが、IEEE1394ネットワークで接続され、前記マスタと各スレーブ間におけるデータの送受信を、一定の伝送周期で、isochronous通信によって行うIEEE1394ベースモーションネットワークのLINKチップにおいて、
複数の送信バッファ、複数の受信バッファ、iso送信処理部、iso受信処理部、isoTXFIFO、isoRXFIFO、トランスミッタ、レシーバから構成されることを特徴とするIEEE1394ベースモーションネットワークのLINKチップ。
【請求項５】
前記iso送信処理部が、isochronousチャネル番号を決定し、前記isoTXFIFOに送信パケットをセットし、前記トランスミッタに送信を指示するステップを繰り返し実行することを特徴とする請求項４に記載のIEEE1394ベースモーションネットワークのLINKチップ。
【請求項６】
前記iso受信処理部が、isoRXFIFOから受信データを読み出し、伝送エラーをチェックし、伝送エラーが無ければ前記受信データを受信したisochronousチャネルに対応した受信バッファに上書きするステップを繰り返し実行することを特徴とする請求項４に記載のIEEE1394ベースモーションネットワークのLINKチップ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、IEEE1394ベースモーションネットワークでの伝送エラーのリカバリー方法およびその伝送エラーリカバリーの方法を実装したLINKチップに関する。  
【背景技術】
【０００２】
一般にモーションネットワークに求められる技術要件としては、高速性に加え、定周期性、軸間同期性が必要とされるため、従来はベンダー独自の通信技術を用いて実現してきた。しかし伝送速度高速化の進展の早さから、近年IEEE1394やイーサネット(登録商標)など汎用の通信技術を利用してモーションネットワークを実現しようとする動きがある。中でもIEEE1394のisochronous通信を応用したモーションネットワークの場合、100Mbpsを超える高速性に加え、125μsの定周期性をLINK層でサポートしているなどの理由から、モーションネットワークとして期待されている。しかしIEEE1394やUSBがサポートしているisochronous通信は、固定した伝送サイクル内で一定の通信帯域の確保が行われるが、その反面で送達確認など伝送エラー時の保証がなされていないので、なんらかの工夫が求められている。
【０００３】
一般的に伝送エラーをリカバリーする手段としては、「再送」が挙げられる（例えば特許文献１参照）。しかしIEEE1394のisochronous通信は、ブロードキャスト通信のため送達確認手段がなく、そのプロトコル自体では再送をサポートしていない。このため通常は上位プロトコルにて送達確認を行い、抜けてしまったパケットから再送を行う方法がある（例えば特許文献２参照）。
【０００４】
isochronous通信にて伝送エラーのリカバリーを行う他のやり方として、USBの場合ではあるがisochronous通信受信用エンドポイントを複数取り、同一パケットデータを別々のパケットで送信させて、一方がエラーの場合には他方のデータを取り出して処理するという方法が採られているものもある（例えば特許文献３）。
【０００５】
図6は典型的なIEEE1394通信ノードの主要な機能ブロックを示している。図6において、1はモーションシステム中のマスタであり、2i（i=0、1、・・・ｎ）はスレーブであるが、いずれも対応する上位アプリケーション層10、20iの違いを除き、機能ブロックとしては同じである。40はIEEE1394  PHY層（PHY）、30はIEEE1394 LINK層（LINK）、11はasynchronousトランザクション制御部である。LINK30は、トランスミッタ37、レシーバ38、isochronous送信FIFO（isoTXFIFO）35、isochronous受信FIFO（isoRXFIFO）36、asynchronous送信用FIFO35´、asynchronous受信用FIFO 36´、isochronousサイクルを管理するサイクル制御部39、IEEE1394のバス状態を管理するシリアルバス管理部39´から構成されている。isoRXFIFO36は受信したisochronousパケットをその通信isochronousチャネル番号によらず順次格納していくので、どのスレーブ2iからのRSPパケットであるかの判別は、isoRXFIFO36から受信データを読み出した後にマスタアプリケーション層10で判断して各処理にまわさなければならない。
【０００６】
図7は、前記図6に示したマスタ1とスレーブ2iによって構成されるモーションシステムにおいてIEEE1394ベースモーションネットワークを経由して授受される指令データ(CMD)50ｉと応答データ（RSP）60iに関するタイムチャート例を示している。isochronousサイクルはIEEE1394規格で定義されたサイクルマスタの送信するサイクルスタートパケットで始まり、次いでマスタから各スレーブ2iに対しそれぞれCMD50iが送信される。各スレーブ2iからはそれぞれRSP60iが送信される。この一連のCMD50i、RSP60iの授受は一定の周期で繰り返されるが、その周期はisochronousサイクルの125μｓに同期してその整数倍の周期で行われるものとする。この場合に例えばスレーブ20（ST#0）から送信されたRSP600が伝送エラーとなり、マスタ１で受信エラーまたはデータ未受信を検出したとしても、送信側のスレーブ20(ST#0)ではこれを検出できないので、そのサイクルではデータを受け取れないままとなる。
【０００７】
一方図８は、特許文献３に記載の別の従来例である。図中101のホストコンピュータと102の印字制御部がUSBで接続され、ホストコンピュータ101から送られてくる印字データを受信して印刷処理を行うようになっている。印字制御部102中の106  USBインタフェース部には107制御回路、108送信用エンドポイントの他に、109、110としてisochronous受信用エンドポイント１、エンドポイント２を持ち、それぞれに受信用FIFOを内蔵している。ホストコンピュータ101は印字データを複数回の送信データパケットに分割してisochronous通信でデータを送信するが、その際同一のデータパケットを２つのエンドポイント109、110に向けて送信するため、印字制御部102の制御回路107では、エンドポイント２  110に対するデータ受信があった場合、受信FIFOへの格納は行うものの、その直前にエンドポイント１  109にて正常にデータ受信していれば、エンドポイント１  109の受信FIFOからDMA回路１  111を使ってRAM  105に受信データを転送するだけで、エンドポイント２  110の受信FIFOのデータはRAMに転送しないように動作するとしている。また、直前にエンドポイント１  109で受信エラーが検出されていた場合は、エンドポイント２  110の受信FIFOに格納されている受信データをDMA回路２  112を使ってRAM  105に転送するように動作するとしている。いずれにしてもRAM  105に転送されなかった受信データ、または受信エラーとなったデータの処理については、明記されていないが、エンドポイント毎にFIFOを持っていることから、該当の受信FIFOをフラッシュするよう動作しているものと推測することができる。
【０００８】
このように、従来のIEEE1394ベースモーションネットワークでは、エラーが発生してもisochronous通信を利用しているため再送を行うことができないでいた。唯一IEEE1394ではなくUSBのネットワークの場合には複数のエンドポイント（受信FIFO）それぞれに同一データを送信することで、伝送エラーのリカバリーが図られていた。
【特許文献１】特開2004-23130号公報（第8頁、図4）
【特許文献２】特開2000-341252号公報（第11頁  図1、第13頁  図9）
【特許文献３】特開2003-345541号公報（第4頁  図1、第5頁、図3）
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来の上位プロトコルで送達確認と再送を行う方法は、もともとプリンタや動画伝送用の上位プロトコル処理であり、送信側、受信側で十分なストリーミングデータのバッファリングを行って実現している。このため伝送エラー、パケット抜けの認識から再送までの遅延時間が大きくなる。モーションネットワークの場合には所定のサイクル内でリカバリーまで完了させなければならないので、こうした上位プロトコルによる再送は適用できない。
【００１０】
また同一データを複数パケットで送信する方法については、そもそもUSBであるから実施が容易である。つまりUSBの通信制御用チップの場合、一般にエンドポイントごとにFIFOを持っており、読み出す必要がなければデータ受信済みFIFOであってもフラッシュして内容を消去することができるものが一般的である。このためいずれかひとつの受信エンドポイントでデータを正常に受信していれば他のFIFOから受信データを読み出す必要はなく、特許文献３に記載の処理が容易に実現できる。
【００１１】
これに対しIEE1394 LINKチップの場合には、isochronousチャネル（USBのエンドポイントに対応）毎に別々の受信FIFOを持っておらず、isochronous受信用として共有で１つの受信FIFOを持つケースが一般的である。
したがって同一内容の複数パケットを別々のisochronousチャネルで受信した場合、すべての受信データをいったんFIFOから別のバッファに読み出してしまわなければならない。
【００１２】
したがってUSBに関する公知例の発明をIEEE1394に適用するには送信処理、受信処理双方の処理負荷とバッファ容量がパケット冗長化に比例して増大するという問題が発生する。一方でUSBをモーションネットワークに適用することに関しては、HUBの必要なツリー状のトポロジーやケーブル長の制約（max 5m）、125μsあたり最大３トランザクションしかisochronous通信できないこと等制約が多いので、モーションネットワークとして不適当である。
【００１３】
本発明はこのような問題点に鑑みてなされたものであり、IEEE1394の複数チャネルで同一データを冗長化して伝送させ伝送品質の信頼性を向上させながら、かつ上位アプリケーションの処理負荷を増大させない手段を提供することを目的とする。
【課題を解決するための手段】
【００１４】
上記問題を解決するため、本発明は、次のようにしたのである。
請求項１に記載の発明は、マスタと１台以上複数のスレーブとが、IEEE1394ネットワークで接続され、前記マスタと各スレーブ間におけるデータの送受信を、一定の伝送周期で、isochronous通信によって行うIEEE1394ベースモーションネットワークの伝送エラーリカバリー方法において、
一伝送周期において同一データを同一送信先へ複数のisochronousチャネルを使って送信し、前記一伝送周期において前記同一データを前記複数のisochronousチャネルを使って受信することを特徴とするものである。
【００１５】
また、請求項２に記載の発明は、前記一伝送周期における同一データの同一送信先への前記複数のisochronousチャネルを使っての送信が、isochronousチャネル番号を決定し、isochronous送信FIFOに送信パケットをセットし、トランスミッタに送信を指示するステップを複数回繰り返すことを特徴とするものである。
【００１６】
また、請求項３に記載の発明は、前記一伝送周期における同一データの前記複数のisochronousチャネルを使っての受信が、isochronous受信FIFOから受信データを読み出し、伝送エラーをチェックし、伝送エラーが無ければ前記受信データを受信したisochronousチャネルに対応した受信バッファに上書きするステップを複数回繰り返すことを特徴とするものである。
【００１７】
そして請求項４〜６に記載の発明では、請求項１〜３に記載の発明をIEEE1394 LINKチップとして実現することを特徴としたものである。
【発明の効果】
【００１８】
請求項１に記載の発明によると、同一の指令データまたは応答データを一伝送周期内に複数パケット送信することができ、そのうちのいずれかに伝送エラーが発生しても他のパケットによってリカバリーすることができる。
【００１９】
また、請求項２に記載の発明によると、isochronous送信FIFOへの複数回のデータ転送はiso送信処理部にて行われるので、送信すべき指令データまたは応答データを上位マスタ／スレーブアプリケーション層が書き込む際には、何回冗長な送信が行われるかにかかわらず１つの送信バッファに書き込めばよく、上位アプリケーション層の処理は従来の伝送エラーリカバリーなしのものと共通化することができる。また、冗長な送信のために、無駄に送信データをコピーする必要もなく、送信バッファの容量も増大させる必要がない。
【００２０】
また、請求項３に記載の発明によると、isochronous受信FIFOからの複数回のパケットの読出しはiso受信処理部で行われ、同一スレーブから受信した正常な応答データや同一スレーブ宛てに受信した正常な指令データは、同一受信バッファ上で上書きされるため、これを受信するマスタ／スレーブアプリケーション層では冗長なデータの受信を意識する必要がなく、処理を従来の伝送エラーリカバリーなしのものと共通化させることができる。また受信バッファの容量も増大させる必要がない。
【００２１】
そして、請求項４〜６に記載の発明によると、前記複数回の冗長送信を行うiso送信処理部や冗長送信された複数データをひとつの受信バッファに集約するiso受信処理部がIEEE1394LINチップ内で実行されるため、上位のマスタ／スレーブアプリケーション層の処理負荷を増大させることがなく、容易に前記請求項１、請求項２、請求項３の方法を実現することができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の方法の具体的実施例について、図に基づいて説明する。
【実施例１】
【００２３】
図１は、本発明の方法を実施するマスタ機器１、スレーブ機器2i（i=0、1、・・・、n）の内部ブロック構成を示す機能ブロック図である。図において10はモーションシステムのマスタアプリケーション層、20iはスレーブアプリケーション層であり、その下位層にあたるIEEE1394  LINK層30（以下LINKと称す）とPHY層40（以下PHYと称す）はマスタ、スレーブによらず共通の構造となっている。またLINK30の内部は、さらに詳細化され31i  は送信バッファ、32iは受信バッファ、33はiso送信処理部、34はiso受信処理部、35はisochroous送信FIFO（以下isoTXFIFOと称す）、36はisochronous受信FIFO（以下isoRXFIFOと称す）、37はトランスミッタ、38はレシーバである。なお、従来技術として述べた図6の中で本件発明に直接関わらないasynchronous関係の機能ブロックなどは省略した。
【００２４】
そしてマスタアプリケーション層10から各スレーブ2iに送信される指令データはスレーブ2iそれぞれに対応した送信バッファ31iに書き込まれる。iso送信処理部は所定のisochronousパケット送信タイミングになると、送信バッファ31iから順次データを読み出して、isochronousヘッダつきでisoTXFIFO35に送信データを書き込む。IsoTXFIFO35に書き込まれた送信データはトランスミッタ37によってPHY40に渡され、IEEE1394ネットワーク（図示していない）に送信される。
【００２５】
このデータを受信したスレーブ2iはPHY40で受信した後レシーバ38によって受信すべきisochronousチャネルのフィルタリングの後、isoRXFIFO36に取り込まれてCRCのチェックがかけられ、この間受信異常、CRC異常があれば、受信ステータスとして所定のステータスレジスタ（図示していない）などによって異常検出を上位アプリケーション層に伝えることができるように動作する。IsoRXFIFO36に転送された受信データはiso受信処理部34にて受信したisochronousチャネルに対応する受信バッファに書き込まれる。
スレーブアプリケーション層はこうして受信した指令データを受信すると、マスタからの指令データ送信とはまったく逆の流れで応答データの送信を行い、その応答データは最終的にマスタアプリケーション層で受信される。
【００２６】
図２は前記構成のモーションシステムにおいて、各スレーブ2iにそれぞれ2回ずつ指令データを送信し、各スレーブ2iからマスタへ2回ずつ応答データを送信する様子を示したデータフロー図である。50iは先に送信される指令データ（CMDと称す）、70iは再度送信される指令データ（RCMDと称す）であり、60iは先に送信される応答データ（RSPと称す）、80iは再度送信される応答データ（RRSPと称す）である。
【００２７】
図３は前記図１、図２のシステムにおいて１アイソクロナスサイクル（125μｓ）中にやりとりされるCMD50i、RCMD70i、RSP60i、RRSP80iのタイミングチャートである。この図を用いて本発明の方法を順を追って説明する。
【００２８】
isochronousサイクルはIEEE1394規格で定義されたサイクルマスタの送信するサイクルスタートパケットで始まり、次いでマスタから各スレーブ2iに対しそれぞれCMD50iが送信される。全スレーブ2iに対するCMD50i送信が完了すると、さらにマスタから再送信のRCMD5iが送信される。これに引き続き各スレーブ2iからはそれぞれRSP60iと再送信のRRSP80iが続けて送信される。この一連のCMD50i、RCMD50i、RSP60i、RRSP80iの送受信授受は一定の周期で繰り返されるが、その周期はisochronousサイクルの125μｓに同期してその整数倍の周期で行われる。この場合例えばスレーブ20（ST#0）から送信されたRSP600が伝送エラーとなり、マスタ１で受信エラーまたはデータ未受信を検出したとしても、送信側のスレーブ20(ST#0)ではRRSP800を再送信しているので、マスタではスレーブ20(ST#0)からの応答データを正常に受信できることになる。
【実施例２】
【００２９】
図４はiso送信処理部33で実行されるiso送信処理のフローチャートである。はじめにS1000-S1007間のループで送信バッファ31iから読み出した指令データまたは応答データをCMD50iまたはRSP60iとして送信し、次いでS1008−S1015間のループで再度送信バッファ31iから指令データまたは応答データを読出してRCMD70iまたはRRSP80iとして送信する。
【００３０】
第1の処理ループ内では、まずS1001にて送信バッファから読み出す送信データ（指令データまたは応答データ）のバイト数を取得する。この値は上位アプリケーション層から送信データの書込みと同時に送信バッファ上、または送信指示用に設けられた所定のレジスタ（図示していない）に書き込まれるものとする。次にS1002にて送信を行うisochronousチャネル番号を決定する。本実施例においては送信バッファ31iに対応させ、CMD送信であればチャネル#i、RSP送信であればチャネル#i+32、また第2の処理ループの場合RCMD送信であればチャネル#i+16、RRSP送信であればチャネル#i+48というようにあらかじめ決められた値を使うこととしているが、送信バイト数の書込みと同様に上位アプリケーションから送信バッファ上、または送信指示用に設けられた所定のレジスタに書き込んで受け渡してもよい。次にS1003にてこれら送信バイト数、送信チャネル番号を使い、送信パケットのheader部91、92とheader_CRC93を演算してisoTXFIFO35にセットする。次にS1004にて送信バッファ31iのデータを送信パケットのdata_field94としてisoTXFIFO35に書込み、S1005にてdata_CRC95をisoTXFIFO35に書き込む。最後にS1006でトランスミッタ37に送信を指示する。
【００３１】
第2の処理ループでも同様の処理を繰り返しRCMD70iまたはRRSP80iをisoTXFIFOにセットしトランスミッタ37に送信を指示する。
【実施例３】
【００３２】
図５はiso受信処理部34で実行されるiso受信処理のフローチャートである。本フローはisochronousサイクルスタートで始まり、まずS1100にて全受信バッファに関する受信ステータスの表示フィールドまたは所定のレジスタ（図示していない）の値をクリア（未受信状態）しておく。次にS1101にてisoRXFIFO36をチェックし受信データを待つ。受信データが入って来たら、次にS1102にて受信ステータスと受信バイト数、受信チャネルを読出し、S1103にて受信エラーでなければS1104にて受信チャネルから格納先受信バッファ32iを求め、S1105にて受信ステータス、受信バイト数を受信バッファ上または所定のレジスタ（図示していない）に書込み、S1106にて受信データを受信バッファ32iに書き込む。この一連の受信処理がS1107にてisochronousサイクルが終了を判断するまで、繰り返し実行される。
【実施例４】
【００３３】
最後に、実施例１〜３で述べた本発明の伝送エラーリカバリー方法を実装したLINKチップについて説明する。その構成は、図１のLINK30の構成と同じであるが、各構成要素の送信バッファ31i、iso送信処理部33、isoTXFIFO35、トランスミッタ37、受信バッファ32i、iso受信処理部34、isoRXFIFO36、レシーバ38がLINKチップに内蔵されるものである。
【００３４】
このように、指令データ（CMD）や応答データ（RSP）を一伝送周期に複数回送信させることにより、伝送帯域はそれによって狭められる代わりに、伝送エラーが発生しても他のisochronousパケットにてリカバリーできているので、伝送の信頼性を高めることができる。
【００３５】
第2の実施例のように、送信バッファ31iを経由して上位アプリケーション層10、20iとiso送信処理部33がインタフェースし、複数の送信パケットを生成してisoTXFIFO35にデータセットする処理はiso送信処理部33が行うので、上位アプリケーション層10、20iは冗長送信を行わない場合と同様に送信データを送信バッファにセットすればよく処理を共通化できる。
【００３６】
第3の実施例のように、受信バッファ32iを経由して上位アプリケーション層10、20iとiso受信処理部34がインタフェースし、同一データを複数の受信パケットとしてisoRXFIFO36から読み出し対応する受信バッファに上書きする処理はiso受信処理部34が行うので、上位アプリケーション層10、20iは冗長送信を行わない場合と同様に受信データを受信バッファから読み出せばよく処理を共通化できる。
【００３７】
第4の実施例のように、上記iso送信処理部33、iso受信処理部34等をIEEE1394のLINKチップで行うため、上位アプリケーション層10、20iは冗長送信、冗長受信の処理を行う必要がなく処理負荷を増大させることがない。
【産業上の利用可能性】
【００３８】
１つの送信データを複数のIEEE1394isochronousチャネルで送信するという手順をとるため再送よりバスの伝送効率は落ちるが処理が単純であり、IEEE1394に限らず一般的に信頼性の求められるネットワークの再送処理に代えて適用することもできる。
【図面の簡単な説明】
【００３９】
【図１】本発明の方法を適用するマスタ／スレーブ機器の機能ブロック図
【図２】本発明の方法の処理手順を示すデータフロー図
【図３】本発明のデータの送信タイミングを示すタイミングチャート
【図４】本発明の第２の方法の処理手順を示すフローチャート
【図５】本発明の第３の方法の処理手順を示すフローチャート
【図６】従来の方法を適用したマスタ／スレーブ機器の機能ブロック図
【図７】従来の方法の処理手順を示すデータフロー図
【図８】他の従来の方法を示す機能ブロック図
【符号の説明】
【００４０】
１  マスタ機器
２i  スレーブ機器
１０  マスタ側アプリケーション層
１１  asynchronous通信のトランザクション制御部
２０ｉ  スレーブ側アプリケーション層
３０  IEEE1394 LINK層
３１ｉ  送信バッファ
３２ｉ  受信バッファ
３３  iso送信処理部（isochronous通信の送信処理部）
３４  iso受信処理部（isochronous通信の受信処理部）
３５  isoTXFIFO（isochronous通信の送信FIFO）
３５´  asyncTXFIFO（asynchronous通信の送信FIFO）
３６  isoRXFIFO（isochronous通信の受信FIFO）
３６´  asyncRXFIFO（asynchronous通信の受信FIFO）
３７  トランスミッタ
３８  レシーバ
３９  サイクル制御部
３９´  シリアルバス管理部
４０  IEEE1394 PHY層
５０ｉ  指令データ
６０i  応答データ
７０ｉ  再送信された指令データ
８０i  再送信された応答データ
９０  isochronousパケットフォーマット
９１  isochronousパケットヘッダ部のdata_lengthフィールド
９２  isochronousパケットヘッダ部のchannelフィールド
９３  isochronousパケットヘッダ部のheader_CRC
９４  isochronousパケットのdata_Field
９５  isochronousパケットのdata_CRC
１０１  従来例におけるホストコンピュータ
１０２  従来例における印字制御部
１０３  従来例における印字制御部のCPU
１０４  従来例における印字制御部のROM
１０５  従来例における印字制御部のRAM
１０６  従来例における印字制御部のUSBインタフェース部
１０７  従来例におけるUSBインタフェース部の制御回路
１０８  従来例におけるUSBインタフェース部の送信用エンドポイント
１０９  従来例におけるUSBインタフェース部の受信用エンドポイント１
１１０  従来例におけるUSBインタフェース部の受信用エンドポイント２
１１１  従来例におけるUSBインタフェース部の受信用DMA１
１１２  従来例におけるUSBインタフェース部の受信用DMA２
【図１】
2006186781.tif 000003
【図２】
2006186781.tif 000004
【図３】
2006186781.tif 000005
【図４】
2006186781.tif 000006
【図５】
2006186781.tif 000007
【図６】
2006186781.tif 000008
【図７】
2006186781.tif 000009
【図８】
2006186781.tif 000010