JP3358618B2 - データ転送方法 - Google Patents
データ転送方法Info
- Publication number
- JP3358618B2 JP3358618B2 JP2000228626A JP2000228626A JP3358618B2 JP 3358618 B2 JP3358618 B2 JP 3358618B2 JP 2000228626 A JP2000228626 A JP 2000228626A JP 2000228626 A JP2000228626 A JP 2000228626A JP 3358618 B2 JP3358618 B2 JP 3358618B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- transmission
- synchronization packet
- packet
- vtr
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Landscapes
- Information Transfer Systems (AREA)
- Television Signal Processing For Recording (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】本発明は、映像信号や音声信
号等のリアルタイム処理が必要なデータを複数の機器間
で転送する際に用いるデータ転送方法に関するものであ
る。
号等のリアルタイム処理が必要なデータを複数の機器間
で転送する際に用いるデータ転送方法に関するものであ
る。
【０００２】
【従来の技術】ディジタル伝送技術の進歩と共に、映像
信号や音声信号（以下ＡＶデータと称する）を共通のデ
ィジタル伝送路（以下バスと称する）を介して伝送する
機器（以下ノードと称する）が開発されつつある。ＡＶ
データは処理されるべき速度に同期して送受信される必
要があるため、リアルタイム通信が可能なバスが必要と
なる。バス接続の特徴は、１つのノードが送信したＡＶ
データをバスで接続されている複数のノードで同時に受
信できるということである。
信号や音声信号（以下ＡＶデータと称する）を共通のデ
ィジタル伝送路（以下バスと称する）を介して伝送する
機器（以下ノードと称する）が開発されつつある。ＡＶ
データは処理されるべき速度に同期して送受信される必
要があるため、リアルタイム通信が可能なバスが必要と
なる。バス接続の特徴は、１つのノードが送信したＡＶ
データをバスで接続されている複数のノードで同時に受
信できるということである。
【０００３】一方、次世代の高速バスとして IEEE P139
4 シリアルバスが提案されている。IEEE P1394 では、1
25μsec（１サイクル）毎に同期パケットを送受信する
ことによってリアルタイム通信を可能にしている。また
ノードが接続または分離された場合やノードのＡＣコン
セントが抜かれた場合等には、即座にバスリセットを実
行して活線挿抜に対応している。したがって IEEE P139
4 バスを用いることによって、家庭用ＡＶ機器に適した
リアルタイムデータの通信（以下同期通信と称する）を
行うことができる。
4 シリアルバスが提案されている。IEEE P1394 では、1
25μsec（１サイクル）毎に同期パケットを送受信する
ことによってリアルタイム通信を可能にしている。また
ノードが接続または分離された場合やノードのＡＣコン
セントが抜かれた場合等には、即座にバスリセットを実
行して活線挿抜に対応している。したがって IEEE P139
4 バスを用いることによって、家庭用ＡＶ機器に適した
リアルタイムデータの通信（以下同期通信と称する）を
行うことができる。
【０００４】
【発明が解決しようとする課題】しかしながら家庭用Ａ
Ｖ機器間で同期通信を行うに際して IEEE P1394 シリア
ルバスを用いる場合に上記従来の同期パケットの構成で
は、前記同期パケットを受信したノードにとって、どの
ノードが前記同期パケットを送信したのかを判別するこ
とができないという問題を有していた。
Ｖ機器間で同期通信を行うに際して IEEE P1394 シリア
ルバスを用いる場合に上記従来の同期パケットの構成で
は、前記同期パケットを受信したノードにとって、どの
ノードが前記同期パケットを送信したのかを判別するこ
とができないという問題を有していた。
【０００５】また上記に示した問題点があるために、ユ
ーザの不用意な操作による同期通信の中断を防ぐ必要が
あるときに、同期パケットを受信している受信ノード
が、同期パケットを送信している送信ノードに対して同
期パケットの送信継続を要求して、送信ノードをプロテ
クト状態にすることができないという問題を有してい
た。
ーザの不用意な操作による同期通信の中断を防ぐ必要が
あるときに、同期パケットを受信している受信ノード
が、同期パケットを送信している送信ノードに対して同
期パケットの送信継続を要求して、送信ノードをプロテ
クト状態にすることができないという問題を有してい
た。
【０００６】例えば、Ａ、Ｂ、Ｃの３つのノードが接続
されたシステムにおいて、Ａのノードが送信した同期パ
ケットをＢのノードが受信して記録している場合に、ユ
ーザが誤ってＣのノードに対して同期パケットの送信を
伴う操作を行ったとする。このとき、ＣのノードがＡの
ノードに対して同期パケットの送信を停止するよう要請
し、Ａのノードがこの要請に応えれば、Ｂのノードの記
録動作が妨げられることになる。すなわち、従来のデー
タ転送方法では、送受信に直接関わりのないノードの誤
操作によって、別のノード間の同期パケットの転送が中
断される可能性があるという問題を有していた。
されたシステムにおいて、Ａのノードが送信した同期パ
ケットをＢのノードが受信して記録している場合に、ユ
ーザが誤ってＣのノードに対して同期パケットの送信を
伴う操作を行ったとする。このとき、ＣのノードがＡの
ノードに対して同期パケットの送信を停止するよう要請
し、Ａのノードがこの要請に応えれば、Ｂのノードの記
録動作が妨げられることになる。すなわち、従来のデー
タ転送方法では、送受信に直接関わりのないノードの誤
操作によって、別のノード間の同期パケットの転送が中
断される可能性があるという問題を有していた。
【０００７】本発明は上記従来の問題点を解決するもの
で、同期通信を行うに際し、同期パケットを受信したノ
ードが、どのノードがその同期パケットを送信したのか
を瞬時に判別できるようにすることによって、ユーザの
不用意な操作による同期通信の中断を防ぐことができる
ようにすることを目的とする。
で、同期通信を行うに際し、同期パケットを受信したノ
ードが、どのノードがその同期パケットを送信したのか
を瞬時に判別できるようにすることによって、ユーザの
不用意な操作による同期通信の中断を防ぐことができる
ようにすることを目的とする。
【０００８】
【課題を解決するための手段】この目的を達成するため
に本発明のデータ転送方法では、同期パケット内に、同
期パケットを送信する送信ノードのノード識別子を付加
した構成とし、複数の受信ノードからの送信継続の要求
に対応するために、送信ノードは、受信ノードから１回
以上の継続要求を受信した段階でプロテクト状態に移行
し、継続要求を受信した回数以上の停止許可を受信した
段階でプロテクト解除状態に移行するという構成を有し
ている。
に本発明のデータ転送方法では、同期パケット内に、同
期パケットを送信する送信ノードのノード識別子を付加
した構成とし、複数の受信ノードからの送信継続の要求
に対応するために、送信ノードは、受信ノードから１回
以上の継続要求を受信した段階でプロテクト状態に移行
し、継続要求を受信した回数以上の停止許可を受信した
段階でプロテクト解除状態に移行するという構成を有し
ている。
【０００９】
【発明の実施の形態】本発明の第１の発明は、バスを介
して、リアルタイムデータを同期パケットにより転送す
る方法であって、受信ノードは、送信ノードを判別する
ための識別子として、バスリセット毎に割り当てられた
ノード識別子を含む前記同期パケットから送信ノードを
判別し、前記送信ノードに前記同期パケットの送信継続
を依頼する継続要求を送信する。
して、リアルタイムデータを同期パケットにより転送す
る方法であって、受信ノードは、送信ノードを判別する
ための識別子として、バスリセット毎に割り当てられた
ノード識別子を含む前記同期パケットから送信ノードを
判別し、前記送信ノードに前記同期パケットの送信継続
を依頼する継続要求を送信する。
【００１０】また、本発明の第２の発明は、バスを介し
て、リアルタイムデータを同期パケットにより転送する
方法であって、送信ノードを判別するための識別子とし
て、バスリセット毎に割り当てられたノード識別子を含
む前記同期パケットの受信に際し、前記同期パケットの
送信継続を依頼する継続要求を、前記リアルタイムデー
タの記録を開始した後、前記送信ノードに送信し、前記
同期パケットの送信要求の解除を依頼する停止許可を、
前記リアルタイムデータの記録が終了した場合に、前記
送信ノードに送信する。
て、リアルタイムデータを同期パケットにより転送する
方法であって、送信ノードを判別するための識別子とし
て、バスリセット毎に割り当てられたノード識別子を含
む前記同期パケットの受信に際し、前記同期パケットの
送信継続を依頼する継続要求を、前記リアルタイムデー
タの記録を開始した後、前記送信ノードに送信し、前記
同期パケットの送信要求の解除を依頼する停止許可を、
前記リアルタイムデータの記録が終了した場合に、前記
送信ノードに送信する。
【００１１】上記のような方法（または構成）により本
発明のデータ転送方法において、受信ノードは、受信し
た同期パケットに含まれる送信ノードのノード識別子を
見るだけで瞬時に同期パケットを送信した送信ノードを
判別することができるので、この送信ノードを判別する
ことによって、受信ノードは、必要に応じて送信ノード
に対して継続要求を送信し、また必要がなくなった時点
で停止許可を送信することができる。送信ノードは、継
続要求を受信する毎にプロテクトカウンタをインクリメ
ントし、停止許可を受信する毎にプロテクトカウンタを
デクリメントする。送信ノードが、プロテクトカウンタ
の値が零でないときには他のノードからの送信停止要求
を拒絶することによって、ユーザの不用意な操作による
同期通信の中断を防ぐことができる。
発明のデータ転送方法において、受信ノードは、受信し
た同期パケットに含まれる送信ノードのノード識別子を
見るだけで瞬時に同期パケットを送信した送信ノードを
判別することができるので、この送信ノードを判別する
ことによって、受信ノードは、必要に応じて送信ノード
に対して継続要求を送信し、また必要がなくなった時点
で停止許可を送信することができる。送信ノードは、継
続要求を受信する毎にプロテクトカウンタをインクリメ
ントし、停止許可を受信する毎にプロテクトカウンタを
デクリメントする。送信ノードが、プロテクトカウンタ
の値が零でないときには他のノードからの送信停止要求
を拒絶することによって、ユーザの不用意な操作による
同期通信の中断を防ぐことができる。
【００１２】以下、本発明の実施の形態について、図面
を用いて説明する。
を用いて説明する。
【００１３】本実施の形態では、複数台のビデオテープ
レコーダー（以下ＶＴＲと略記する）を IEEE P1394 バ
スで接続してＡＶデータのダビングを行う場合を例に挙
げて説明する。
レコーダー（以下ＶＴＲと略記する）を IEEE P1394 バ
スで接続してＡＶデータのダビングを行う場合を例に挙
げて説明する。
【００１４】図１は、本実施の形態において同期通信を
行う際に転送される同期パケットのフォーマットであ
る。
行う際に転送される同期パケットのフォーマットであ
る。
【００１５】図１において、パケットヘッダ１はIEEE P
1394 で規定されているヘッダであり、チャンネル番号
やパケットに含まれる転送ブロック２のデータ量等の情
報が配置される。転送ブロック２はユーザが任意に転送
したいデータを設定できる領域であり、その同期パケッ
トによって転送されているデータがどのようなデータで
あるのか等を示すデータヘッダ３、および実際に転送さ
れているデータ４から成っている。データヘッダ３は、
その同期パケットを送信した送信ノードを示すノード識
別子５、およびその他のヘッダデータから成っている。
ＣＲＣ６は転送ブロック２の転送エラー判別用データで
ある。
1394 で規定されているヘッダであり、チャンネル番号
やパケットに含まれる転送ブロック２のデータ量等の情
報が配置される。転送ブロック２はユーザが任意に転送
したいデータを設定できる領域であり、その同期パケッ
トによって転送されているデータがどのようなデータで
あるのか等を示すデータヘッダ３、および実際に転送さ
れているデータ４から成っている。データヘッダ３は、
その同期パケットを送信した送信ノードを示すノード識
別子５、およびその他のヘッダデータから成っている。
ＣＲＣ６は転送ブロック２の転送エラー判別用データで
ある。
【００１６】IEEE P1394 では、バスリセットが発生す
る毎に、その時点で接続されているノードに対して、自
動的にノード識別子が割り当てられる。このため、同期
パケットを送信する送信ノードは、図１に示したフォー
マットに従って、その時点で割り当てられているノード
識別子をデータヘッダ２に書き込んで、同期パケットの
送信を行う。
る毎に、その時点で接続されているノードに対して、自
動的にノード識別子が割り当てられる。このため、同期
パケットを送信する送信ノードは、図１に示したフォー
マットに従って、その時点で割り当てられているノード
識別子をデータヘッダ２に書き込んで、同期パケットの
送信を行う。
【００１７】図２に、４台のＶＴＲをバスで接続してＡ
Ｖデータのダビングを行う際の接続図を示す。
Ｖデータのダビングを行う際の接続図を示す。
【００１８】図２において７〜１０はそれぞれＶＴＲで
あり、ＶＴＲ７〜１０はそれぞれ内蔵しているマイコン
（図示せず）によって動作を管理されている。１１〜１
３はＶＴＲ７〜１０を接続しているケーブルである。こ
のケーブル１１〜１３の接続を行う毎にバスリセットが
発生して、ＶＴＲ７〜１０にノード識別子が割り当てら
れる。ここでは、ＶＴＲ７〜１０にはそれぞれ０〜３の
ノード識別子が割り当てられているものとする。
あり、ＶＴＲ７〜１０はそれぞれ内蔵しているマイコン
（図示せず）によって動作を管理されている。１１〜１
３はＶＴＲ７〜１０を接続しているケーブルである。こ
のケーブル１１〜１３の接続を行う毎にバスリセットが
発生して、ＶＴＲ７〜１０にノード識別子が割り当てら
れる。ここでは、ＶＴＲ７〜１０にはそれぞれ０〜３の
ノード識別子が割り当てられているものとする。
【００１９】さて、IEEE P1394では125μsec（１サイク
ル）毎にパケットの送受信が行われ、各サイクルの前半
部を同期通信用の優先時間帯に割り当てることができ
る。このため同期通信を行うに際し、有限である優先時
間帯について帯域確保を行う。すなわちどの通信チャン
ネルを利用してどれくらいの時間同期パケットを送信す
るのかを予め決定する必要がある。また、この優先時間
帯の帯域の管理は、バスで接続されているノードの内の
コンフィグレーションマネージャ（以下ＣＦＭと称す
る）と呼ばれる特定のノードが行う。
ル）毎にパケットの送受信が行われ、各サイクルの前半
部を同期通信用の優先時間帯に割り当てることができ
る。このため同期通信を行うに際し、有限である優先時
間帯について帯域確保を行う。すなわちどの通信チャン
ネルを利用してどれくらいの時間同期パケットを送信す
るのかを予め決定する必要がある。また、この優先時間
帯の帯域の管理は、バスで接続されているノードの内の
コンフィグレーションマネージャ（以下ＣＦＭと称す
る）と呼ばれる特定のノードが行う。
【００２０】いま、ＶＴＲ７で再生したＡＶデータをＶ
ＴＲ８とＶＴＲ９とで記録するダビングを行うものと
し、ＶＴＲ１０が優先時間帯の帯域の管理を行うものと
する。
ＴＲ８とＶＴＲ９とで記録するダビングを行うものと
し、ＶＴＲ１０が優先時間帯の帯域の管理を行うものと
する。
【００２１】以下、本実施の形態のＶＴＲの処理内容
を、そのＶＴＲの役割ごとに説明する。
を、そのＶＴＲの役割ごとに説明する。
【００２２】ここで、以下の説明に用いるＡＶデータ以
外のデータ、例えば、受信ノードから送信ノードに対し
て送信する継続要求および停止許可等は、非同期パケッ
トを利用して通信している。
外のデータ、例えば、受信ノードから送信ノードに対し
て送信する継続要求および停止許可等は、非同期パケッ
トを利用して通信している。
【００２３】図３は、本実施の形態においてＶＴＲ７が
ＡＶデータを再生し、ＶＴＲ１０に対して同期通信を行
うための帯域の確保を要求して許可を得た後に、実際に
同期パケットを送信している際のＶＴＲ７のマイコン処
理内容を示すフローチャートである。
ＡＶデータを再生し、ＶＴＲ１０に対して同期通信を行
うための帯域の確保を要求して許可を得た後に、実際に
同期パケットを送信している際のＶＴＲ７のマイコン処
理内容を示すフローチャートである。
【００２４】このとき送信ノードであるＶＴＲ７は、図
１に示した同期パケットのフォーマットに従って、割り
当てられているノード識別子「０」をデータヘッダ２に
書き込んで、同期パケットを送信する。
１に示した同期パケットのフォーマットに従って、割り
当てられているノード識別子「０」をデータヘッダ２に
書き込んで、同期パケットを送信する。
【００２５】まずステップ３０１において、他のノード
から継続要求を受信したかどうかを判断する。継続要求
を受信していればメモリ上に設定した６ビットのカウン
タであるプロテクトカウンタをインクリメントし（ステ
ップ３０２）、継続要求を受信していなければそのま
ま、ステップ３０３へ進む。
から継続要求を受信したかどうかを判断する。継続要求
を受信していればメモリ上に設定した６ビットのカウン
タであるプロテクトカウンタをインクリメントし（ステ
ップ３０２）、継続要求を受信していなければそのま
ま、ステップ３０３へ進む。
【００２６】ここで、プロテクトカウンタは、同期パケ
ットの送信を開始する直前に「０」にリセットされるカ
ウンタである。このため、例えば本実施の形態において
ＶＴＲ７が同期パケットの送信を開始した後、ＶＴＲ８
およびＶＴＲ９の２台のＶＴＲから継続要求を受信した
場合には、ＶＴＲ７のプロテクトカウンタの値は「２」
となる。
ットの送信を開始する直前に「０」にリセットされるカ
ウンタである。このため、例えば本実施の形態において
ＶＴＲ７が同期パケットの送信を開始した後、ＶＴＲ８
およびＶＴＲ９の２台のＶＴＲから継続要求を受信した
場合には、ＶＴＲ７のプロテクトカウンタの値は「２」
となる。
【００２７】ステップ３０３では、他のノードから停止
許可を受信したかどうかを判断し、許可されていればプ
ロテクトカウンタをデクリメントし（ステップ３０
４）、許可されていなければそのまま、ステップ３０５
へ進む。
許可を受信したかどうかを判断し、許可されていればプ
ロテクトカウンタをデクリメントし（ステップ３０
４）、許可されていなければそのまま、ステップ３０５
へ進む。
【００２８】例えば、本実施の形態においてＶＴＲ８お
よびＶＴＲ９の２台のＶＴＲからプロテクトを要求され
てＶＴＲ７のプロテクトカウンタの値が「２」となって
いる場合には、ＶＴＲ８およびＶＴＲ９の２台ともから
停止許可が送信されるまでは、プロテクトカウンタの値
が「０」にならないことになる。
よびＶＴＲ９の２台のＶＴＲからプロテクトを要求され
てＶＴＲ７のプロテクトカウンタの値が「２」となって
いる場合には、ＶＴＲ８およびＶＴＲ９の２台ともから
停止許可が送信されるまでは、プロテクトカウンタの値
が「０」にならないことになる。
【００２９】ステップ３０４では、他のノードから停止
許可を受信しても、既にプロテクトカウンタの値が
「０」であれば、プロテクトカウンタのデクリメントは
行わない。
許可を受信しても、既にプロテクトカウンタの値が
「０」であれば、プロテクトカウンタのデクリメントは
行わない。
【００３０】ステップ３０５では、バスリセットが発生
したかどうかを判断し、発生した場合にはプロテクトカ
ウンタの値を「０」にリセットして（ステップ３０６）
ステップ３０１に戻る。発生していなければステップ３
０７に進む。
したかどうかを判断し、発生した場合にはプロテクトカ
ウンタの値を「０」にリセットして（ステップ３０６）
ステップ３０１に戻る。発生していなければステップ３
０７に進む。
【００３１】バスリセットが発生すると、一時的に同期
パケットの送信は中断するが、ＶＴＲ７はバスリセット
からの復旧後直ちに同期パケットの出力を再開する。
パケットの送信は中断するが、ＶＴＲ７はバスリセット
からの復旧後直ちに同期パケットの出力を再開する。
【００３２】バスリセットはケーブルが抜き差しされた
場合や、機器のコンセントが抜けた場合等に発生する。
したがって、バスリセットが発生すると、バスリセット
発生以前に継続要求を送信したノードが停止許可を送信
できなくなっている。この場合、ＶＴＲ７はプロテクト
状態から復帰できなくなる。このようなことを防ぐため
にバスリセット発生時にはプロテクトカウンタをリセッ
トする。
場合や、機器のコンセントが抜けた場合等に発生する。
したがって、バスリセットが発生すると、バスリセット
発生以前に継続要求を送信したノードが停止許可を送信
できなくなっている。この場合、ＶＴＲ７はプロテクト
状態から復帰できなくなる。このようなことを防ぐため
にバスリセット発生時にはプロテクトカウンタをリセッ
トする。
【００３３】ステップ３０７では、他のノード、例えば
ＶＴＲ１０から同期パケットの送信停止要求を受信した
かどうかを判断し、受信した場合にはプロテクトカウン
タの値が「０」であるかどうかを判断する（ステップ３
０８）。
ＶＴＲ１０から同期パケットの送信停止要求を受信した
かどうかを判断し、受信した場合にはプロテクトカウン
タの値が「０」であるかどうかを判断する（ステップ３
０８）。
【００３４】ここでプロテクトカウンタの値が「０」以
外であればプロテクト状態であると判断して停止要求を
受理せず、送信停止を要求したノードであるＶＴＲ１０
に対して停止要求拒否を送信し（ステップ３０９）、ス
テップ３０１に戻る。
外であればプロテクト状態であると判断して停止要求を
受理せず、送信停止を要求したノードであるＶＴＲ１０
に対して停止要求拒否を送信し（ステップ３０９）、ス
テップ３０１に戻る。
【００３５】プロテクトカウンタの値が「０」であれば
プロテクト解除状態であると判断して停止要求を受理
し、同期パケットの送信を停止して（ステップ３１
０）、処理を終了する。
プロテクト解除状態であると判断して停止要求を受理
し、同期パケットの送信を停止して（ステップ３１
０）、処理を終了する。
【００３６】ステップ３０７で送信停止が要求されてい
ない場合には、通信を介さずに外部から直接送信停止が
要求されたかどうかを判断する（ステップ３１１）。通
信を介さずに外部から直接送信停止が要求される例とし
ては、ＶＴＲ７本体の送信停止キーが操作された場合
や、電源スイッチキーが押された場合等が挙げられる。
ない場合には、通信を介さずに外部から直接送信停止が
要求されたかどうかを判断する（ステップ３１１）。通
信を介さずに外部から直接送信停止が要求される例とし
ては、ＶＴＲ７本体の送信停止キーが操作された場合
や、電源スイッチキーが押された場合等が挙げられる。
【００３７】さて、ステップ３０７で通信を介さずに外
部から直接送信停止が要求された場合には、その時点の
プロテクトカウンタの値に関係なく、プロテクトカウン
タを「０」にリセットし（ステップ３１２）、同期パケ
ットの送信を停止する（ステップ３１０）。すなわち、
その機器に対してユーザが直接操作した場合には、その
操作を優先させる。
部から直接送信停止が要求された場合には、その時点の
プロテクトカウンタの値に関係なく、プロテクトカウン
タを「０」にリセットし（ステップ３１２）、同期パケ
ットの送信を停止する（ステップ３１０）。すなわち、
その機器に対してユーザが直接操作した場合には、その
操作を優先させる。
【００３８】外部から直接送信停止が要求される例とし
ては、バスに対するデータ出力の可・不可を制御するデ
ジタル出力キーが設けられているＶＴＲにおいて、同期
パケットの送信中にユーザがデジタル出力キーを操作し
て、データ出力を不可にされた場合が挙げられる。
ては、バスに対するデータ出力の可・不可を制御するデ
ジタル出力キーが設けられているＶＴＲにおいて、同期
パケットの送信中にユーザがデジタル出力キーを操作し
て、データ出力を不可にされた場合が挙げられる。
【００３９】また、他の例としては、ＴＶチューナーが
付いていないために停止時にはデジタル出力も停止する
仕様となっている再生専用ＶＴＲにおいて、停止キーが
押されたことによってＶＴＲが再生状態からが停止状態
になった場合が挙げられる。
付いていないために停止時にはデジタル出力も停止する
仕様となっている再生専用ＶＴＲにおいて、停止キーが
押されたことによってＶＴＲが再生状態からが停止状態
になった場合が挙げられる。
【００４０】ステップ３０７において、通信を介さずに
外部から直接送信停止が要求されていない場合には、ス
テップ３０１に戻って、上記した一連の処理を継続す
る。
外部から直接送信停止が要求されていない場合には、ス
テップ３０１に戻って、上記した一連の処理を継続す
る。
【００４１】図４は、本実施例においてＶＴＲ８および
ＶＴＲ９が、ＶＴＲ７から送信されるＡＶデータの同期
パケットを実際に受信して記録を開始した後のＶＴＲ８
およびＶＴＲ９のマイコンの処理内容を示すフローチャ
ートである。
ＶＴＲ９が、ＶＴＲ７から送信されるＡＶデータの同期
パケットを実際に受信して記録を開始した後のＶＴＲ８
およびＶＴＲ９のマイコンの処理内容を示すフローチャ
ートである。
【００４２】いま、本実施の形態において、例えばＶＴ
Ｒ７が再生するＡＶデータをＶＴＲ８およびＶＴＲ９で
記録しているダビングの最中にユーザが操作を誤ってＶ
ＴＲ１０を再生状態にしてしまったとする。このような
場合、ＶＴＲ１０は同期パケットの出力ができなけれ
ば、ＶＴＲ７に対して同期パケットの出力を停止してく
れるように送信停止を要求する。
Ｒ７が再生するＡＶデータをＶＴＲ８およびＶＴＲ９で
記録しているダビングの最中にユーザが操作を誤ってＶ
ＴＲ１０を再生状態にしてしまったとする。このような
場合、ＶＴＲ１０は同期パケットの出力ができなけれ
ば、ＶＴＲ７に対して同期パケットの出力を停止してく
れるように送信停止を要求する。
【００４３】本実施の形態では、上記の例のような場合
にも、ＡＶデータを記録しているＶＴＲ８とＶＴＲ９へ
のＶＴＲ７からの同期パケットの送信が停止することな
く、ダビングが正しく行われるようにする。すなわち、
ＶＴＲ８およびＶＴＲ９は、ＶＴＲ７からの同期パケッ
トを受信した時点で、ＶＴＲ７に対して継続要求を送信
する。
にも、ＡＶデータを記録しているＶＴＲ８とＶＴＲ９へ
のＶＴＲ７からの同期パケットの送信が停止することな
く、ダビングが正しく行われるようにする。すなわち、
ＶＴＲ８およびＶＴＲ９は、ＶＴＲ７からの同期パケッ
トを受信した時点で、ＶＴＲ７に対して継続要求を送信
する。
【００４４】また、本実施の形態においては、ＶＴＲ８
とＶＴＲ９とは同じ処理をするため、以下ではＶＴＲ８
の処理内容についてのみ述べる。
とＶＴＲ９とは同じ処理をするため、以下ではＶＴＲ８
の処理内容についてのみ述べる。
【００４５】まずステップ４０１において、受信した同
期パケットのデータヘッダ２に書かれている、送信ノー
ドであるＶＴＲ７のノード識別子「０」を読み込んで、
このノード識別子「０」を持つ送信ノードであるＶＴＲ
７に対して継続要求を送信してステップ４０２に進む。
期パケットのデータヘッダ２に書かれている、送信ノー
ドであるＶＴＲ７のノード識別子「０」を読み込んで、
このノード識別子「０」を持つ送信ノードであるＶＴＲ
７に対して継続要求を送信してステップ４０２に進む。
【００４６】ステップ４０２では、バスリセットが発生
したかどうかを判断し、発生した場合には再度プロテク
トを要求するためにステップ４０１に戻る。
したかどうかを判断し、発生した場合には再度プロテク
トを要求するためにステップ４０１に戻る。
【００４７】バスリセットが発生していない場合にはス
テップ４０３に進んで、同期パケットの受信が正常に行
われているかどうか、例えばＶＴＲ７が送信停止状態に
なっているために同期パケットの受信が中断していない
か等を判断する。
テップ４０３に進んで、同期パケットの受信が正常に行
われているかどうか、例えばＶＴＲ７が送信停止状態に
なっているために同期パケットの受信が中断していない
か等を判断する。
【００４８】同期パケットの受信が正常に行われている
場合にはステップ４０４に進み、正常に行われていない
場合には、その時点で処理を終了する。
場合にはステップ４０４に進み、正常に行われていない
場合には、その時点で処理を終了する。
【００４９】ステップ４０４では記録終了が指示された
かどうかを判断し、記録終了が指示されていない場合に
は、ステップ４０２に戻って、記録終了が指示されるま
でバスリセットの監視を行う。
かどうかを判断し、記録終了が指示されていない場合に
は、ステップ４０２に戻って、記録終了が指示されるま
でバスリセットの監視を行う。
【００５０】記録終了が指示された場合には、再度、受
信した同期パケット内のデータヘッダ２に書かれてい
る、送信ノードのノード識別子５を読み込んで、このノ
ード識別子５を持つ送信ノードに対して送信停止許可を
送信して（ステップ４０５）、処理を終了する。
信した同期パケット内のデータヘッダ２に書かれてい
る、送信ノードのノード識別子５を読み込んで、このノ
ード識別子５を持つ送信ノードに対して送信停止許可を
送信して（ステップ４０５）、処理を終了する。
【００５１】以上のように本実施の形態によれば、送信
ノードであるＶＴＲ７が割り当てられているノード識別
子を、送信する同期パケットのデータヘッダ２に書き込
んで送信することにより、この同期パケットを受信した
ＶＴＲ８およびＶＴＲ９は、瞬時にＶＴＲ７が送信ノー
ドであることを判別できる。
ノードであるＶＴＲ７が割り当てられているノード識別
子を、送信する同期パケットのデータヘッダ２に書き込
んで送信することにより、この同期パケットを受信した
ＶＴＲ８およびＶＴＲ９は、瞬時にＶＴＲ７が送信ノー
ドであることを判別できる。
【００５２】また、送信ノードであるＶＴＲ７は、他の
ノード、例えばＶＴＲ８とＶＴＲ９から継続要求を受信
した段階でプロテクトカウンタをインクリメントし、停
止許可を受信した段階でプロテクトカウンタをデクリメ
ントし、このプロテクトカウンタの値が「０」以外のと
きにはプロテクト状態であると判断する。送信ノードで
あるＶＴＲ７は、プロテクト状態のときに他のノード、
例えばＶＴＲ１０から送信停止が要求された場合には、
その送信停止要求を拒否して送信を継続する。このよう
にすることによって、例えばＶＴＲ７が再生するＡＶデ
ータをＶＴＲ８およびＶＴＲ９で記録しているダビング
の最中にユーザが操作を誤ってＶＴＲ１０を再生状態に
してしまった場合にも、ＡＶデータを記録しているＶＴ
Ｒ８とＶＴＲ９へのＶＴＲ７からの同期パケットの送信
が停止することなく、ダビングが正しく行われるように
できる。
ノード、例えばＶＴＲ８とＶＴＲ９から継続要求を受信
した段階でプロテクトカウンタをインクリメントし、停
止許可を受信した段階でプロテクトカウンタをデクリメ
ントし、このプロテクトカウンタの値が「０」以外のと
きにはプロテクト状態であると判断する。送信ノードで
あるＶＴＲ７は、プロテクト状態のときに他のノード、
例えばＶＴＲ１０から送信停止が要求された場合には、
その送信停止要求を拒否して送信を継続する。このよう
にすることによって、例えばＶＴＲ７が再生するＡＶデ
ータをＶＴＲ８およびＶＴＲ９で記録しているダビング
の最中にユーザが操作を誤ってＶＴＲ１０を再生状態に
してしまった場合にも、ＡＶデータを記録しているＶＴ
Ｒ８とＶＴＲ９へのＶＴＲ７からの同期パケットの送信
が停止することなく、ダビングが正しく行われるように
できる。
【００５３】また、バスリセット発生時にプロテクトカ
ウンタをリセットすることによって、バスリセットが発
生した場合にも、バスリセット発生以前に継続要求を送
信したノードが停止許可を送信できなくなってしまった
ために送信ノードであるＶＴＲ７がプロテクト状態から
復帰できなくなることを防ぐことができる。
ウンタをリセットすることによって、バスリセットが発
生した場合にも、バスリセット発生以前に継続要求を送
信したノードが停止許可を送信できなくなってしまった
ために送信ノードであるＶＴＲ７がプロテクト状態から
復帰できなくなることを防ぐことができる。
【００５４】なお、上記実施の形態においては、送信ノ
ードに対して継続要求を送出する受信ノードは、送信ノ
ードからの同期パケットを記録するノードでなくても良
い。例えば、いま、テレビモニター（以下、ＴＶと略記
する）とＶＴＲとレーザーディスク（登録商標）プレー
ヤー（以下、ＬＤプレーヤーと略記する）が接続されて
いて、ＴＶにＬＤプレーヤーの再生画面を映し出してい
るとする。このような場合に、誤ってＶＴＲの再生画面
をＴＶに映しださないようにするために、ユーザ自身が
受信ノードであるＴＶをキー操作することによって、送
信ノードであるＬＤプレーヤーに対して継続要求を送信
しても良い。
ードに対して継続要求を送出する受信ノードは、送信ノ
ードからの同期パケットを記録するノードでなくても良
い。例えば、いま、テレビモニター（以下、ＴＶと略記
する）とＶＴＲとレーザーディスク（登録商標）プレー
ヤー（以下、ＬＤプレーヤーと略記する）が接続されて
いて、ＴＶにＬＤプレーヤーの再生画面を映し出してい
るとする。このような場合に、誤ってＶＴＲの再生画面
をＴＶに映しださないようにするために、ユーザ自身が
受信ノードであるＴＶをキー操作することによって、送
信ノードであるＬＤプレーヤーに対して継続要求を送信
しても良い。
【００５５】また、上記実施の形態においては、受信ノ
ードからの継続要求を受信したときに、送信ノードがプ
ロテクト状態に移行していたが、通信を介さずに外部か
ら送信継続を指示されることによってプロテクト状態に
移行しても良い。例えば、上述のＴＶとＬＤプレーヤー
の例において、送信ノードであるＬＤプレーヤーにプロ
テクトキーを設けて、このプロテクトキーを操作される
ことによってプロテクト状態に移行しても良い。
ードからの継続要求を受信したときに、送信ノードがプ
ロテクト状態に移行していたが、通信を介さずに外部か
ら送信継続を指示されることによってプロテクト状態に
移行しても良い。例えば、上述のＴＶとＬＤプレーヤー
の例において、送信ノードであるＬＤプレーヤーにプロ
テクトキーを設けて、このプロテクトキーを操作される
ことによってプロテクト状態に移行しても良い。
【００５６】また、上記実施の形態においては、送信ノ
ードがプロテクト状態かプロテクト解除状態であるのか
を判別する手段としてメモリ上に設定したカウンタを用
いていたが、プロテクト状態かプロテクト解除状態であ
るのかを判別できればどのような手段を用いても良い。
例えば、接続できるノードの数だけのビットを持つレジ
スタを用いても判別をすることができる。
ードがプロテクト状態かプロテクト解除状態であるのか
を判別する手段としてメモリ上に設定したカウンタを用
いていたが、プロテクト状態かプロテクト解除状態であ
るのかを判別できればどのような手段を用いても良い。
例えば、接続できるノードの数だけのビットを持つレジ
スタを用いても判別をすることができる。
【００５７】
【発明の効果】以上のように本発明のデータ転送方法
は、バスリセット毎にバスに接続された各ノードに対し
て自動的にノード識別子が割り当てられるバスシステム
を用いてリアルタイム処理が必要なデータを同期パケッ
トに内包して送信するに際し、同期パケット内に、送信
ノードを判別するためのノード識別子を付加して送信す
ることによって、同期パケットを受信した受信ノード
が、受信した同期パケットに含まれる送信ノードのノー
ド識別子を見るだけで瞬時に送信ノードを判別すること
ができるので、受信ノードは、必要に応じて送信ノード
に対して同期パケットの送信継続を依頼する継続要求を
送信し、かつ継続の必要がなくなった時点で継続要求の
解除を依頼する停止許可を送信し、同期パケットの送信
ノードは１回以上の継続要求を受信した段階でプロテク
ト状態となり、継続要求を受信した回数以上の停止許可
を受信した段階でプロテクト解除状態となる。送信ノー
ドは、プロテクト状態では他のノードからの送信停止要
求を拒絶し、同期パケットの送信を停止しない。これに
よって、ユーザの不用意な操作による同期通信の中断を
防ぐことができる。
は、バスリセット毎にバスに接続された各ノードに対し
て自動的にノード識別子が割り当てられるバスシステム
を用いてリアルタイム処理が必要なデータを同期パケッ
トに内包して送信するに際し、同期パケット内に、送信
ノードを判別するためのノード識別子を付加して送信す
ることによって、同期パケットを受信した受信ノード
が、受信した同期パケットに含まれる送信ノードのノー
ド識別子を見るだけで瞬時に送信ノードを判別すること
ができるので、受信ノードは、必要に応じて送信ノード
に対して同期パケットの送信継続を依頼する継続要求を
送信し、かつ継続の必要がなくなった時点で継続要求の
解除を依頼する停止許可を送信し、同期パケットの送信
ノードは１回以上の継続要求を受信した段階でプロテク
ト状態となり、継続要求を受信した回数以上の停止許可
を受信した段階でプロテクト解除状態となる。送信ノー
ドは、プロテクト状態では他のノードからの送信停止要
求を拒絶し、同期パケットの送信を停止しない。これに
よって、ユーザの不用意な操作による同期通信の中断を
防ぐことができる。
【００５８】すなわち、送受信に直接関わりのないノー
ドの誤操作によって、別のノード間の同期パケットの転
送が中断されることを防ぐことができるという効果が得
られる。特にＶＴＲのダビング等、継続時間が比較的長
い同期通信を行う際に非常に有効である。
ドの誤操作によって、別のノード間の同期パケットの転
送が中断されることを防ぐことができるという効果が得
られる。特にＶＴＲのダビング等、継続時間が比較的長
い同期通信を行う際に非常に有効である。
【００５９】また、プロテクト状態にある送信ノード
が、バスリセット発生時にプロテクト解除状態となるこ
とによって、バスリセット発生以前に継続要求を送信し
たノードが停止許可を送信できなくなってしまったため
に送信ノードがプロテクト状態から復帰できなくなるこ
とを防ぐことができる。
が、バスリセット発生時にプロテクト解除状態となるこ
とによって、バスリセット発生以前に継続要求を送信し
たノードが停止許可を送信できなくなってしまったため
に送信ノードがプロテクト状態から復帰できなくなるこ
とを防ぐことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態における同期パケットのフ
ォーマットを示す模式図
ォーマットを示す模式図
【図２】同実施の形態におけるＶＴＲの接続図
【図３】同実施の形態における再生ＶＴＲの処理内容を
示すフローチャート
示すフローチャート
【図４】同実施の形態における記録ＶＴＲの処理内容を
示すフローチャート
示すフローチャート
２ 転送ブロック ３ データヘッダ ４ 転送データ ５ ノード識別子
フロントページの続き (72)発明者 西村 拓也 大阪府門真市大字門真1006番地 松下電 器産業株式会社内 (56)参考文献 特開 平７−162968（ＪＰ，Ａ) 特開2001−77834（ＪＰ，Ａ) 特開 平６−29992（ＪＰ，Ａ) 特開 平７−193616（ＪＰ，Ａ) 特許3127704（ＪＰ，Ｂ２) Ｍｉｃｈａｅｌ Ｔｅｅｎｅｒ，Ａ ＢＵＳ ＯＮ Ａ ＤＩＥＴ−ＴＨＥ ＳＥＲＩＡＬ ＢＵＳ ＡＬＴＥＲＮＡ ＴＩＶＥ，ＩＥＥＥ ＣＯＭＰＣ ＯＮ ＳＰＲＩＮＧ，米国，ＩＥＥＥ ＣＯ ＭＰＵＴＥＲ ＳＯＣＩＥＴＹ ＩＮＴ ＥＲＮＡＴＩＯＮＡＬ ＣＯＮＦＥＲＥ ＮＣＥ，1992年２月，ＰＡＧＥ316−321 (58)調査した分野(Int.Cl.7，ＤＢ名) H04L 12/28 G06F 13/00 357
Claims (6)
- 【請求項１】 バスを介して、リアルタイムデータを同
期パケットにより転送する方法であって、 受信ノードは、送信ノードを判別するための識別子とし
て、バスリセット毎に割り当てられたノード識別子を含
む前記同期パケットから送信ノードを判別し、 前記送信ノードに前記同期パケットの送信継続を依頼す
る継続要求を送信することを特徴とするデータ転送方
法。 - 【請求項２】 継続要求は、非同期パケットにより送信
することを特徴とする請求項１記載のデータ転送方法。 - 【請求項３】 バスを介して、リアルタイムデータを同
期パケットにより転送する方法であって、 送信ノードを判別するための識別子として、バスリセッ
ト毎に割り当てられたノード識別子を含む前記同期パケ
ットの受信に際し、 前記同期パケットの送信継続を依頼する継続要求を、前
記リアルタイムデータの記録を開始した後、前記送信ノ
ードに送信し、 前記同期パケットの送信要求の解除を依頼する停止許可
を、前記リアルタイムデータの記録が終了した場合に、
前記送信ノードに送信することを特徴とするデータ送信
方法。 - 【請求項４】 バスを介して、リアルタイムデータを同
期パケットにより転送するノードであって、 送信ノードを判別するための識別子として、バスリセッ
ト毎に割り当てられたノード識別子を含む前記同期パケ
ットから送信ノードを判別し、 前記送信ノードに前記同期パケットの送信継続を依頼す
る継続要求を送信することを特徴とする受信ノード。 - 【請求項５】 継続要求は、非同期パケットにより送信
することを特徴とする請求項４記載の受信ノード。 - 【請求項６】 バスを介して、リアルタイムデータを同
期パケットにより転送するノードであって、 送信ノードを判別するための識別子として、バスリセッ
ト毎に割り当てられたノード識別子を含む前記同期パケ
ットの受信に際し、 前記同期パケットの送信継続を依頼する継続要求を、前
記リアルタイムデータの記録を開始した後、前記送信ノ
ードに送信し、 前記同期パケットの送信要求の解除を依頼する停止許可
を、前記リアルタイムデータの記録が終了した場合に、
前記送信ノードに送信することを特徴とする受信ノー
ド。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000228626A JP3358618B2 (ja) | 2000-07-28 | 2000-07-28 | データ転送方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000228626A JP3358618B2 (ja) | 2000-07-28 | 2000-07-28 | データ転送方法 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06038243A Division JP3127704B2 (ja) | 1994-03-09 | 1994-03-09 | データ転送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001086189A JP2001086189A (ja) | 2001-03-30 |
| JP3358618B2 true JP3358618B2 (ja) | 2002-12-24 |
Family
ID=18721875
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000228626A Expired - Lifetime JP3358618B2 (ja) | 2000-07-28 | 2000-07-28 | データ転送方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3358618B2 (ja) |
-
2000
- 2000-07-28 JP JP2000228626A patent/JP3358618B2/ja not_active Expired - Lifetime
Non-Patent Citations (1)
| Title |
|---|
| Ｍｉｃｈａｅｌ Ｔｅｅｎｅｒ，Ａ ＢＵＳ ＯＮ Ａ ＤＩＥＴ−ＴＨＥ ＳＥＲＩＡＬ ＢＵＳ ＡＬＴＥＲＮＡＴＩＶＥ，ＩＥＥＥ ＣＯＭＰＣ ＯＮ ＳＰＲＩＮＧ，米国，ＩＥＥＥ ＣＯＭＰＵＴＥＲ ＳＯＣＩＥＴＹ ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＣＯＮＦＥＲＥＮＣＥ，１９９２年２月，ＰＡＧＥ３１６−３２１ |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001086189A (ja) | 2001-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1085700B1 (en) | Data transmission system and method | |
| JP3520572B2 (ja) | 入力機器選択方法 | |
| KR100403109B1 (ko) | 데이터 통신 방법 및 전자기기 | |
| US7873059B2 (en) | Gateway device | |
| JP3994360B2 (ja) | 情報処理装置、情報処理方法、および記録媒体 | |
| US7130945B2 (en) | Controlling method for transmitting reserve commands from a controller to target devices | |
| US6286071B1 (en) | Communication control method, communication system and electronic device used therefor | |
| JP3291926B2 (ja) | 電子機器制御方式 | |
| JP2001203727A (ja) | 通信方法及び通信装置 | |
| JP3348526B2 (ja) | オーディオビデオマネージャ機器及びオーディオビデオ機器並びに通信方法 | |
| JP3358618B2 (ja) | データ転送方法 | |
| JP3127704B2 (ja) | データ転送方法 | |
| JP3341758B2 (ja) | データ転送方法 | |
| JPH08293878A (ja) | 電子機器及び通信制御方法 | |
| EP1061692A2 (en) | Controlling device, communication system and controlling method | |
| JPH0818584A (ja) | 通信方式及び電子機器 | |
| JP3189571B2 (ja) | データ処理装置 | |
| JP3478285B2 (ja) | データ通信方法及び電子機器 | |
| JP2003324451A (ja) | 信号処理システム、信号出力装置、信号入力装置及び通信制御方法 | |
| JP3627726B2 (ja) | 電子機器 | |
| JP3583811B2 (ja) | 入力機器選択方法及び電子機器 | |
| JP3664050B2 (ja) | 接続復旧装置 | |
| JP2001077829A (ja) | ネットワークデータ通信装置及びネットワークデータ通信方法 | |
| JP2001175592A (ja) | Ｉｅｅｅ１３９４上のデータ受信装置における受信方法 | |
| JP2003274329A (ja) | Ａｖ機器及びその制御方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081011 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091011 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091011 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101011 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111011 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121011 Year of fee payment: 10 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131011 Year of fee payment: 11 |
|
| EXPY | Cancellation because of completion of term |