JP2001077834A - データ転送方法 - Google Patents

データ転送方法

Info

Publication number
JP2001077834A
JP2001077834A JP2000228625A JP2000228625A JP2001077834A JP 2001077834 A JP2001077834 A JP 2001077834A JP 2000228625 A JP2000228625 A JP 2000228625A JP 2000228625 A JP2000228625 A JP 2000228625A JP 2001077834 A JP2001077834 A JP 2001077834A
Authority
JP
Japan
Prior art keywords
node
transmission
synchronization packet
transmitting
request
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.)
Granted
Application number
JP2000228625A
Other languages
English (en)
Other versions
JP3341758B2 (ja
Inventor
Yasuyuki Sawara
康之 佐原
Hiroyuki Iizuka
飯塚  裕之
Yasunori Kawakami
靖程 川上
Takuya Nishimura
拓也 西村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to JP2000228625A priority Critical patent/JP3341758B2/ja
Publication of JP2001077834A publication Critical patent/JP2001077834A/ja
Application granted granted Critical
Publication of JP3341758B2 publication Critical patent/JP3341758B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Landscapes

  • Small-Scale Networks (AREA)
  • Information Transfer Systems (AREA)

Abstract

(57)【要約】 【課題】 バスを介して、映像信号や音声信号等のリア
ルタイム処理が必要なデータを複数の機器間で同期通信
する際に、不本意な同期通信の中断を防ぐことを目的と
する。 【解決手段】 送信ノードが、1回以上の継続要求を受
信した時点でプロテクト状態となり(ステップ301,
302)、他のノードからの送信停止要求を拒絶し(ス
テップ309)、同期パケットの送信を停止しないよう
にすることができ、また、継続要求を受信した回数、停
止許可を受信した時点でプロテクト解除状態(ステップ
303,304)となる。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は、映像信号や音声信
号等のリアルタイム処理が必要なデータを複数の機器間
で転送する際に用いるデータ転送方法に関するものであ
る。
【0002】
【従来の技術】ディジタル伝送技術の進歩と共に、映像
信号や音声信号(以下AVデータと称する)を共通のデ
ィジタル伝送路(以下バスと称する)を介して伝送する
機器(以下ノードと称する)が開発されつつある。AV
データは処理されるべき速度に同期して送受信される必
要があるため、リアルタイム通信が可能なバスが必要と
なる。バス接続の特徴は、1つのノードが送信したAV
データをバスで接続されている複数のノードで同時に受
信できるということである。
【0003】一方、次世代の高速バスとして IEEE P139
4 シリアルバスが提案されている。IEEE P1394 では、1
25μsec(1サイクル)毎に同期パケットを送受信する
ことによってリアルタイム通信を可能にしている。また
ノードが接続または分離された場合やノードのACコン
セントが抜かれた場合等には、即座にバスリセットを実
行して活線挿抜に対応している。したがって IEEE P139
4 バスを用いることによって、家庭用AV機器に適した
リアルタイムデータの通信(以下同期通信と称する)を
行うことができる。
【0004】
【発明が解決しようとする課題】しかしながら家庭用A
V機器間で同期通信を行うに際して IEEE P1394 シリア
ルバスを用いる場合に上記従来の同期パケットの構成で
は、前記同期パケットを受信したノードにとって、どの
ノードが前記同期パケットを送信したのかを判別するこ
とができないという問題を有していた。
【0005】また上記に示した問題点があるために、ユ
ーザの不用意な操作による同期通信の中断を防ぐ必要が
あるときに、同期パケットを受信している受信ノード
が、同期パケットを送信している送信ノードに対して同
期パケットの送信継続を要求して、送信ノードをプロテ
クト状態にすることができないという問題を有してい
た。
【0006】例えば、A、B、Cの3つのノードが接続
されたシステムにおいて、Aのノードが送信した同期パ
ケットをBのノードが受信して記録している場合に、ユ
ーザが誤ってCのノードに対して同期パケットの送信を
伴う操作を行ったとする。このとき、CのノードがAの
ノードに対して同期パケットの送信を停止するよう要請
し、Aのノードがこの要請に応えれば、Bのノードの記
録動作が妨げられることになる。すなわち、従来のデー
タ転送方法では、送受信に直接関わりのないノードの誤
操作によって、別のノード間の同期パケットの転送が中
断される可能性があるという問題を有していた。
【0007】本発明は上記従来の問題点を解決するもの
で、同期通信を行うに際し、同期パケットを受信したノ
ードが、どのノードがその同期パケットを送信したのか
を瞬時に判別できるようにすることによって、ユーザの
不用意な操作による同期通信の中断を防ぐことができる
ようにすることを目的とする。
【0008】
【課題を解決するための手段】この目的を達成するため
に本発明のデータ転送方法では、同期パケット内に、同
期パケットを送信する送信ノードのノード識別子を付加
した構成とし、複数の受信ノードからの送信継続の要求
に対応するために、送信ノードは、受信ノードから1回
以上の継続要求を受信した段階でプロテクト状態に移行
し、継続要求を受信した回数以上の停止許可を受信した
段階でプロテクト解除状態に移行するという構成を有し
ている。
【0009】
【発明の実施の形態】本発明の第1の発明は、バスを介
して、リアルタイムデータを同期パケットにより転送す
る方法であって、前記同期パケットは、送信ノードを判
別するための識別子として、バスリセット毎に割り当て
られたノード識別子を含み、前記送信ノードは、他のノ
ードからの前記同期パケットの送信継続を依頼する継続
要求を、1回以上受信した段階でプロテクト状態にな
る。
【0010】また、第2の発明は、上記第1の発明に加
え、送信ノードは、他のノードからの継続要求の解除を
依頼する停止許可を、継続要求を受信した回数、受信し
た段階でプロテクト解除状態になる。
【0011】また、第3の発明は、上記第1の発明に加
え、プロテクト状態にある送信ノードは、他のノードか
らの送信停止要求を受信しても、同期パケットの送信を
継続する。
【0012】また、第4の発明は、上記第1の発明に加
え、プロテクト状態にある送信ノードは、バスリセット
が発生したときにはプロテクト解除状態になる。
【0013】また、第5の発明は、上記第4の発明に加
え、送信ノードは、バスリセットからの復旧後直ちに同
期パケットの出力を再開する。
【0014】また、第6の発明は、上記第5の発明に加
え、継続要求を送信したノードは、バスリセットが発生
したときには送信ノードに対して継続要求を送信する。
【0015】また、第7の発明は、上記第2の発明に加
え、プロテクト解除状態にある送信ノードは、他のノー
ドからの送信停止要求を受信した場合には同期パケット
の送信を停止する。
【0016】また、第8の発明は、上記第1の発明に加
え、送信ノードは、通信を介さずに直接データの送信停
止を指示された場合には、プロテクト状態であっても、
その時点でデータの送信を停止する。
【0017】また、第9の発明は、上記第1の発明に加
え、送信ノードは、通信を介さずに直接データの送信継
続を指示された場合には、プロテクト状態に移行する。
【0018】上記のような方法(または構成)により本
発明のデータ転送方法において、受信ノードは、受信し
た同期パケットに含まれる送信ノードのノード識別子を
見るだけで瞬時に同期パケットを送信した送信ノードを
判別することができるので、この送信ノードを判別する
ことによって、受信ノードは、必要に応じて送信ノード
に対して継続要求を送信し、また必要がなくなった時点
で停止許可を送信することができる。送信ノードは、継
続要求を受信する毎にプロテクトカウンタをインクリメ
ントし、停止許可を受信する毎にプロテクトカウンタを
デクリメントする。送信ノードが、プロテクトカウンタ
の値が零でないときには他のノードからの送信停止要求
を拒絶することによって、ユーザの不用意な操作による
同期通信の中断を防ぐことができる。
【0019】以下、本発明の実施の形態について、図面
を用いて説明する。
【0020】本実施の形態では、複数台のビデオテープ
レコーダー(以下VTRと略記する)を IEEE P1394 バ
スで接続してAVデータのダビングを行う場合を例に挙
げて説明する。
【0021】図1は、本実施の形態において同期通信を
行う際に転送される同期パケットのフォーマットであ
る。
【0022】図1において、パケットヘッダ1はIEEE P
1394 で規定されているヘッダであり、チャンネル番号
やパケットに含まれる転送ブロック2のデータ量等の情
報が配置される。転送ブロック2はユーザが任意に転送
したいデータを設定できる領域であり、その同期パケッ
トによって転送されているデータがどのようなデータで
あるのか等を示すデータヘッダ3、および実際に転送さ
れているデータ4から成っている。データヘッダ3は、
その同期パケットを送信した送信ノードを示すノード識
別子5、およびその他のヘッダデータから成っている。
CRC6は転送ブロック2の転送エラー判別用データで
ある。
【0023】IEEE P1394 では、バスリセットが発生す
る毎に、その時点で接続されているノードに対して、自
動的にノード識別子が割り当てられる。このため、同期
パケットを送信する送信ノードは、図1に示したフォー
マットに従って、その時点で割り当てられているノード
識別子をデータヘッダ2に書き込んで、同期パケットの
送信を行う。
【0024】図2に、4台のVTRをバスで接続してA
Vデータのダビングを行う際の接続図を示す。
【0025】図2において7〜10はそれぞれVTRで
あり、VTR7〜10はそれぞれ内蔵しているマイコン
(図示せず)によって動作を管理されている。11〜1
3はVTR7〜10を接続しているケーブルである。こ
のケーブル11〜13の接続を行う毎にバスリセットが
発生して、VTR7〜10にノード識別子が割り当てら
れる。ここでは、VTR7〜10にはそれぞれ0〜3の
ノード識別子が割り当てられているものとする。
【0026】さて、IEEE P1394では125μsec(1サイク
ル)毎にパケットの送受信が行われ、各サイクルの前半
部を同期通信用の優先時間帯に割り当てることができ
る。このため同期通信を行うに際し、有限である優先時
間帯について帯域確保を行う。すなわちどの通信チャン
ネルを利用してどれくらいの時間同期パケットを送信す
るのかを予め決定する必要がある。また、この優先時間
帯の帯域の管理は、バスで接続されているノードの内の
コンフィグレーションマネージャ(以下CFMと称す
る)と呼ばれる特定のノードが行う。
【0027】いま、VTR7で再生したAVデータをV
TR8とVTR9とで記録するダビングを行うものと
し、VTR10が優先時間帯の帯域の管理を行うものと
する。
【0028】以下、本実施の形態のVTRの処理内容
を、そのVTRの役割ごとに説明する。
【0029】ここで、以下の説明に用いるAVデータ以
外のデータ、例えば、受信ノードから送信ノードに対し
て送信する継続要求および停止許可等は、非同期パケッ
トを利用して通信している。
【0030】図3は、本実施の形態においてVTR7が
AVデータを再生し、VTR10に対して同期通信を行
うための帯域の確保を要求して許可を得た後に、実際に
同期パケットを送信している際のVTR7のマイコン処
理内容を示すフローチャートである。
【0031】このとき送信ノードであるVTR7は、図
1に示した同期パケットのフォーマットに従って、割り
当てられているノード識別子「0」をデータヘッダ2に
書き込んで、同期パケットを送信する。
【0032】まずステップ301において、他のノード
から継続要求を受信したかどうかを判断する。継続要求
を受信していればメモリ上に設定した6ビットのカウン
タであるプロテクトカウンタをインクリメントし(ステ
ップ302)、継続要求を受信していなければそのま
ま、ステップ303へ進む。
【0033】ここで、プロテクトカウンタは、同期パケ
ットの送信を開始する直前に「0」にリセットされるカ
ウンタである。このため、例えば本実施の形態において
VTR7が同期パケットの送信を開始した後、VTR8
およびVTR9の2台のVTRから継続要求を受信した
場合には、VTR7のプロテクトカウンタの値は「2」
となる。
【0034】ステップ303では、他のノードから停止
許可を受信したかどうかを判断し、許可されていればプ
ロテクトカウンタをデクリメントし(ステップ30
4)、許可されていなければそのまま、ステップ305
へ進む。
【0035】例えば、本実施の形態においてVTR8お
よびVTR9の2台のVTRからプロテクトを要求され
てVTR7のプロテクトカウンタの値が「2」となって
いる場合には、VTR8およびVTR9の2台ともから
停止許可が送信されるまでは、プロテクトカウンタの値
が「0」にならないことになる。
【0036】ステップ304では、他のノードから停止
許可を受信しても、既にプロテクトカウンタの値が
「0」であれば、プロテクトカウンタのデクリメントは
行わない。
【0037】ステップ305では、バスリセットが発生
したかどうかを判断し、発生した場合にはプロテクトカ
ウンタの値を「0」にリセットして(ステップ306)
ステップ301に戻る。発生していなければステップ3
07に進む。
【0038】バスリセットが発生すると、一時的に同期
パケットの送信は中断するが、VTR7はバスリセット
からの復旧後直ちに同期パケットの出力を再開する。
【0039】バスリセットはケーブルが抜き差しされた
場合や、機器のコンセントが抜けた場合等に発生する。
したがって、バスリセットが発生すると、バスリセット
発生以前に継続要求を送信したノードが停止許可を送信
できなくなっている。この場合、VTR7はプロテクト
状態から復帰できなくなる。このようなことを防ぐため
にバスリセット発生時にはプロテクトカウンタをリセッ
トする。
【0040】ステップ307では、他のノード、例えば
VTR10から同期パケットの送信停止要求を受信した
かどうかを判断し、受信した場合にはプロテクトカウン
タの値が「0」であるかどうかを判断する(ステップ3
08)。
【0041】ここでプロテクトカウンタの値が「0」以
外であればプロテクト状態であると判断して停止要求を
受理せず、送信停止を要求したノードであるVTR10
に対して停止要求拒否を送信し(ステップ309)、ス
テップ301に戻る。
【0042】プロテクトカウンタの値が「0」であれば
プロテクト解除状態であると判断して停止要求を受理
し、同期パケットの送信を停止して(ステップ31
0)、処理を終了する。
【0043】ステップ307で送信停止が要求されてい
ない場合には、通信を介さずに外部から直接送信停止が
要求されたかどうかを判断する(ステップ311)。通
信を介さずに外部から直接送信停止が要求される例とし
ては、VTR7本体の送信停止キーが操作された場合
や、電源スイッチキーが押された場合等が挙げられる。
【0044】さて、ステップ307で通信を介さずに外
部から直接送信停止が要求された場合には、その時点の
プロテクトカウンタの値に関係なく、プロテクトカウン
タを「0」にリセットし(ステップ312)、同期パケ
ットの送信を停止する(ステップ310)。すなわち、
その機器に対してユーザが直接操作した場合には、その
操作を優先させる。
【0045】外部から直接送信停止が要求される例とし
ては、バスに対するデータ出力の可・不可を制御するデ
ジタル出力キーが設けられているVTRにおいて、同期
パケットの送信中にユーザがデジタル出力キーを操作し
て、データ出力を不可にされた場合が挙げられる。
【0046】また、他の例としては、TVチューナーが
付いていないために停止時にはデジタル出力も停止する
仕様となっている再生専用VTRにおいて、停止キーが
押されたことによってVTRが再生状態からが停止状態
になった場合が挙げられる。
【0047】ステップ307において、通信を介さずに
外部から直接送信停止が要求されていない場合には、ス
テップ301に戻って、上記した一連の処理を継続す
る。
【0048】図4は、本実施例においてVTR8および
VTR9が、VTR7から送信されるAVデータの同期
パケットを実際に受信して記録を開始した後のVTR8
およびVTR9のマイコンの処理内容を示すフローチャ
ートである。
【0049】いま、本実施の形態において、例えばVT
R7が再生するAVデータをVTR8およびVTR9で
記録しているダビングの最中にユーザが操作を誤ってV
TR10を再生状態にしてしまったとする。このような
場合、VTR10は同期パケットの出力ができなけれ
ば、VTR7に対して同期パケットの出力を停止してく
れるように送信停止を要求する。
【0050】本実施の形態では、上記の例のような場合
にも、AVデータを記録しているVTR8とVTR9へ
のVTR7からの同期パケットの送信が停止することな
く、ダビングが正しく行われるようにする。すなわち、
VTR8およびVTR9は、VTR7からの同期パケッ
トを受信した時点で、VTR7に対して継続要求を送信
する。
【0051】また、本実施の形態においては、VTR8
とVTR9とは同じ処理をするため、以下ではVTR8
の処理内容についてのみ述べる。
【0052】まずステップ401において、受信した同
期パケットのデータヘッダ2に書かれている、送信ノー
ドであるVTR7のノード識別子「0」を読み込んで、
このノード識別子「0」を持つ送信ノードであるVTR
7に対して継続要求を送信してステップ402に進む。
【0053】ステップ402では、バスリセットが発生
したかどうかを判断し、発生した場合には再度プロテク
トを要求するためにステップ401に戻る。
【0054】バスリセットが発生していない場合にはス
テップ403に進んで、同期パケットの受信が正常に行
われているかどうか、例えばVTR7が送信停止状態に
なっているために同期パケットの受信が中断していない
か等を判断する。
【0055】同期パケットの受信が正常に行われている
場合にはステップ404に進み、正常に行われていない
場合には、その時点で処理を終了する。
【0056】ステップ404では記録終了が指示された
かどうかを判断し、記録終了が指示されていない場合に
は、ステップ402に戻って、記録終了が指示されるま
でバスリセットの監視を行う。
【0057】記録終了が指示された場合には、再度、受
信した同期パケット内のデータヘッダ2に書かれてい
る、送信ノードのノード識別子5を読み込んで、このノ
ード識別子5を持つ送信ノードに対して送信停止許可を
送信して(ステップ405)、処理を終了する。
【0058】以上のように本実施の形態によれば、送信
ノードであるVTR7が割り当てられているノード識別
子を、送信する同期パケットのデータヘッダ2に書き込
んで送信することにより、この同期パケットを受信した
VTR8およびVTR9は、瞬時にVTR7が送信ノー
ドであることを判別できる。
【0059】また、送信ノードであるVTR7は、他の
ノード、例えばVTR8とVTR9から継続要求を受信
した段階でプロテクトカウンタをインクリメントし、停
止許可を受信した段階でプロテクトカウンタをデクリメ
ントし、このプロテクトカウンタの値が「0」以外のと
きにはプロテクト状態であると判断する。送信ノードで
あるVTR7は、プロテクト状態のときに他のノード、
例えばVTR10から送信停止が要求された場合には、
その送信停止要求を拒否して送信を継続する。このよう
にすることによって、例えばVTR7が再生するAVデ
ータをVTR8およびVTR9で記録しているダビング
の最中にユーザが操作を誤ってVTR10を再生状態に
してしまった場合にも、AVデータを記録しているVT
R8とVTR9へのVTR7からの同期パケットの送信
が停止することなく、ダビングが正しく行われるように
できる。
【0060】また、バスリセット発生時にプロテクトカ
ウンタをリセットすることによって、バスリセットが発
生した場合にも、バスリセット発生以前に継続要求を送
信したノードが停止許可を送信できなくなってしまった
ために送信ノードであるVTR7がプロテクト状態から
復帰できなくなることを防ぐことができる。
【0061】なお、上記実施の形態においては、送信ノ
ードに対して継続要求を送出する受信ノードは、送信ノ
ードからの同期パケットを記録するノードでなくても良
い。例えば、いま、テレビモニター(以下、TVと略記
する)とVTRとレーザーディスク(登録商標)プレー
ヤー(以下、LDプレーヤーと略記する)が接続されて
いて、TVにLDプレーヤーの再生画面を映し出してい
るとする。このような場合に、誤ってVTRの再生画面
をTVに映しださないようにするために、ユーザ自身が
受信ノードであるTVをキー操作することによって、送
信ノードであるLDプレーヤーに対して継続要求を送信
しても良い。
【0062】また、上記実施の形態においては、受信ノ
ードからの継続要求を受信したときに、送信ノードがプ
ロテクト状態に移行していたが、通信を介さずに外部か
ら送信継続を指示されることによってプロテクト状態に
移行しても良い。例えば、上述のTVとLDプレーヤー
の例において、送信ノードであるLDプレーヤーにプロ
テクトキーを設けて、このプロテクトキーを操作される
ことによってプロテクト状態に移行しても良い。
【0063】また、上記実施の形態においては、送信ノ
ードがプロテクト状態かプロテクト解除状態であるのか
を判別する手段としてメモリ上に設定したカウンタを用
いていたが、プロテクト状態かプロテクト解除状態であ
るのかを判別できればどのような手段を用いても良い。
例えば、接続できるノードの数だけのビットを持つレジ
スタを用いても判別をすることができる。
【0064】
【発明の効果】以上のように本発明のデータ転送方法
は、バスリセット毎にバスに接続された各ノードに対し
て自動的にノード識別子が割り当てられるバスシステム
を用いてリアルタイム処理が必要なデータを同期パケッ
トに内包して送信するに際し、同期パケット内に、送信
ノードを判別するためのノード識別子を付加して送信す
ることによって、同期パケットを受信した受信ノード
が、受信した同期パケットに含まれる送信ノードのノー
ド識別子を見るだけで瞬時に送信ノードを判別すること
ができるので、受信ノードは、必要に応じて送信ノード
に対して同期パケットの送信継続を依頼する継続要求を
送信し、かつ継続の必要がなくなった時点で継続要求の
解除を依頼する停止許可を送信し、同期パケットの送信
ノードは1回以上の継続要求を受信した段階でプロテク
ト状態となり、継続要求を受信した回数以上の停止許可
を受信した段階でプロテクト解除状態となる。送信ノー
ドは、プロテクト状態では他のノードからの送信停止要
求を拒絶し、同期パケットの送信を停止しない。これに
よって、ユーザの不用意な操作による同期通信の中断を
防ぐことができる。
【0065】すなわち、送受信に直接関わりのないノー
ドの誤操作によって、別のノード間の同期パケットの転
送が中断されることを防ぐことができるという効果が得
られる。特にVTRのダビング等、継続時間が比較的長
い同期通信を行う際に非常に有効である。
【0066】また、プロテクト状態にある送信ノード
が、バスリセット発生時にプロテクト解除状態となるこ
とによって、バスリセット発生以前に継続要求を送信し
たノードが停止許可を送信できなくなってしまったため
に送信ノードがプロテクト状態から復帰できなくなるこ
とを防ぐことができる。
【図面の簡単な説明】
【図1】本発明の実施の形態における同期パケットのフ
ォーマットを示す模式図
【図2】同実施の形態におけるVTRの接続図
【図3】同実施の形態における再生VTRの処理内容を
示すフローチャート
【図4】同実施の形態における記録VTRの処理内容を
示すフローチャート
【符号の説明】
2 転送ブロック 3 データヘッダ 4 転送データ 5 ノード識別子
───────────────────────────────────────────────────── フロントページの続き (72)発明者 川上 靖程 香川県高松市古新町8番地の1 松下寿電 子工業株式会社内 (72)発明者 西村 拓也 大阪府門真市大字門真1006番地 松下電器 産業株式会社内

Claims (18)

    【特許請求の範囲】
  1. 【請求項1】 バスを介して、リアルタイムデータを同
    期パケットにより転送する方法であって、 前記同期パケットは、送信ノードを判別するための識別
    子として、バスリセット毎に割り当てられたノード識別
    子を含み、 前記送信ノードは、他のノードからの前記同期パケット
    の送信継続を依頼する継続要求を、1回以上受信した段
    階でプロテクト状態になることを特徴とするデータ転送
    方法。
  2. 【請求項2】 送信ノードは、他のノードからの継続要
    求の解除を依頼する停止許可を、継続要求を受信した回
    数、受信した段階でプロテクト解除状態になることを特
    徴とする請求項1記載のデータ転送方法。
  3. 【請求項3】 プロテクト状態にある送信ノードは、他
    のノードからの送信停止要求を受信しても、同期パケッ
    トの送信を継続することを特徴とする請求項1記載のデ
    ータ転送方法。
  4. 【請求項4】 プロテクト状態にある送信ノードは、バ
    スリセットが発生したときにはプロテクト解除状態にな
    ることを特徴とする請求項1記載のデータ転送方法。
  5. 【請求項5】 送信ノードは、バスリセットからの復旧
    後直ちに同期パケットの出力を再開することを特徴とす
    る請求項4に記載のデータ転送方法。
  6. 【請求項6】 継続要求を送信したノードは、バスリセ
    ットが発生したときには送信ノードに対して継続要求を
    送信することを特徴とする請求項4記載のデータ転送方
    法。
  7. 【請求項7】 プロテクト解除状態にある送信ノード
    は、他のノードからの送信停止要求を受信した場合には
    同期パケットの送信を停止することを特徴とする請求項
    2記載のデータ転送方法。
  8. 【請求項8】 送信ノードは、通信を介さずに直接デー
    タの送信停止を指示された場合には、プロテクト状態で
    あっても、その時点でデータの送信を停止することを特
    徴とする請求項1記載のデータ転送方法。
  9. 【請求項9】 送信ノードは、通信を介さずに直接デー
    タの送信継続を指示された場合には、プロテクト状態に
    移行することを特徴とする請求項1記載のデータ送信方
    法。
  10. 【請求項10】 バスを介して、リアルタイムデータを
    同期パケットにより転送するシステムであって、 前記同期パケットは、送信ノードを判別するための識別
    子として、バスリセット毎に割り当てられたノード識別
    子を含み、 前記送信ノードは、他のノードからの前記同期パケット
    の送信継続を依頼する継続要求を、1回以上受信した段
    階でプロテクト状態になることを特徴とするバスシステ
    ム。
  11. 【請求項11】 送信ノードは、他のノードからの継続
    要求の解除を依頼する停止許可を、継続要求を受信した
    回数、受信した段階でプロテクト解除状態になることを
    特徴とする請求項10記載のバスシステム。
  12. 【請求項12】 プロテクト状態にある送信ノードは、
    他のノードからの送信停止要求を受信しても、同期パケ
    ットの送信を継続することを特徴とする請求項10記載
    のバスシステム。
  13. 【請求項13】 プロテクト状態にある送信ノードは、
    バスリセットが発生したときにはプロテクト解除状態に
    なることを特徴とする請求項10記載のバスシステム。
  14. 【請求項14】 送信ノードは、バスリセットからの復
    旧後直ちに同期パケットの出力を再開することを特徴と
    する請求項13に記載のバスシステム。
  15. 【請求項15】 継続要求を送信したノードは、バスリ
    セットが発生したときには送信ノードに対して継続要求
    を送信することを特徴とする請求項13記載のバスシス
    テム。
  16. 【請求項16】 プロテクト解除状態にある送信ノード
    は、他のノードからの送信停止要求を受信した場合には
    同期パケットの送信を停止することを特徴とする請求項
    11記載のバスシステム。
  17. 【請求項17】 送信ノードは、通信を介さずに直接デ
    ータの送信停止を指示された場合には、プロテクト状態
    であっても、その時点でデータの送信を停止することを
    特徴とする請求項10記載のバスシステム。
  18. 【請求項18】 送信ノードは、通信を介さずに直接デ
    ータの送信継続を指示された場合には、プロテクト状態
    に移行することを特徴とする請求項10記載のバスシス
    テム。
JP2000228625A 2000-07-28 2000-07-28 データ転送方法 Expired - Lifetime JP3341758B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2000228625A JP3341758B2 (ja) 2000-07-28 2000-07-28 データ転送方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000228625A JP3341758B2 (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
JP2001077834A true JP2001077834A (ja) 2001-03-23
JP3341758B2 JP3341758B2 (ja) 2002-11-05

Family

ID=18721874

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000228625A Expired - Lifetime JP3341758B2 (ja) 2000-07-28 2000-07-28 データ転送方法

Country Status (1)

Country Link
JP (1) JP3341758B2 (ja)

Also Published As

Publication number Publication date
JP3341758B2 (ja) 2002-11-05

Similar Documents

Publication Publication Date Title
EP1085700B1 (en) Data transmission system and method
JP3520572B2 (ja) 入力機器選択方法
US6286071B1 (en) Communication control method, communication system and electronic device used therefor
JP3671738B2 (ja) 伝送管理方法
US7039293B1 (en) Method and electronic equipment for transmitting data to other electronic equipment on a network
JP3291926B2 (ja) 電子機器制御方式
JP2001203727A (ja) 通信方法及び通信装置
JP3348526B2 (ja) オーディオビデオマネージャ機器及びオーディオビデオ機器並びに通信方法
JP3341758B2 (ja) データ転送方法
JP3127704B2 (ja) データ転送方法
JP3358618B2 (ja) データ転送方法
JP3271110B2 (ja) データ通信方法及び電子機器
JPH0818584A (ja) 通信方式及び電子機器
JP3189571B2 (ja) データ処理装置
JPH07327287A (ja) データ伝送装置
JP3560522B2 (ja) Ieee1394上のデータ受信装置における受信方法
JP2003324451A (ja) 信号処理システム、信号出力装置、信号入力装置及び通信制御方法
JP3583811B2 (ja) 入力機器選択方法及び電子機器
JP2001077829A (ja) ネットワークデータ通信装置及びネットワークデータ通信方法
JP2003274329A (ja) Av機器及びその制御方法
JP2002056589A (ja) 情報記録装置
JP2005176251A (ja) データ転送方法、データ転送装置、及び制御プログラム
JP2003134432A (ja) 録画装置、録画方法および録画システム
JP2004135156A (ja) データ通信装置、データ通信方法、記録媒体及びプログラム
JP2002261778A (ja) データ伝送方法およびデータ伝送装置

Legal Events

Date Code Title Description
FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20070823

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080823

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080823

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090823

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090823

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100823

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110823

Year of fee payment: 9

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120823

Year of fee payment: 10

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130823

Year of fee payment: 11

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130823

Year of fee payment: 11

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140823

Year of fee payment: 12

EXPY Cancellation because of completion of term