JPH06253371A

JPH06253371A - 通信方法

Info

Publication number: JPH06253371A
Application number: JP5336090A
Authority: JP
Inventors: Shigeo Tanaka; 繁雄田中; Hiroshi Yamazaki; 洋山崎; Noriko Kotabe; 典子小田部; Koichi Sugiyama; 宏一杉山; Makoto Sato; 真佐藤; Akira Katsuyama; 明勝山; Yoshio Osakabe; 義雄刑部; Yasuo Kusagaya; 康夫草ヶ谷
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1992-12-28
Filing date: 1993-12-28
Publication date: 1994-09-09

Abstract

(57)【要約】（修正有）【目的】処理を簡単にし、通信速度を高める。【構成】マスタ機器からスレーブ機器への１つのコマ
ンド／データが１つのパケットで終了する。１つのコマ
ンド／データは、アンロックモードで送信される。コマ
ンドを受信したスレーブ機器は、マスター送信モードで
ステータスを返す。但し、データを受信したときは返事
を返さない。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、ＡＶ（オーディオ／ビ
デオ）システムに用いて、好適な通信方法に関する。

【０００２】

【従来の技術】従来の通信方法は、基本的に、図１７に
示すように行われている。すなわち、マスター機器から
スレーブ機器に対してコマンド（ＣＭＤ）を送り、その
後、そのコマンドに対応する処理が行われているか否か
の問い合わせ（ＲＥＱＵＥＳＴ）が行われる。従って、
相手機器（スレーブ機器）の処理が終了しないと、いつ
までも問い合わせを続けなければならないため、バス上
に多くのデータが伝送され、バスが混雑する原因となっ
ていた。また、マスター機器およびスレーブ機器には、
それぞれ、元々必要なマスター送信バッファおよびスレ
ーブ受信バッファに加えて、マスター受信（ＧＥＴ−Ａ
ＮＳ）用バッファおよびスレーブ送信用バッファが必要
であった。

【０００３】図１８は、相手機器の状態を問い合わせる
だけの従来の通信方法の例を示し、図１９は、相手機器
にコマンド（ＣＭＤ＝命令）を送り、コマンドの結果を
問い合わせる従来の通信方法の例を示す。これらの図に
示されているように、あるコマンドを送るのに、パケッ
ト（フレーム）の送信順序は一定でないため、通信処理
用マイクロコンピュータのプログラムは、種々の態様に
対して柔軟に対処できなければならず、処理数が多く、
プログラムの作成作業も困難であった。

【０００４】図２０は、従来のＤ２Ｂ仕様における種々
の通信態様を示す。この図に示されているように、ＲＥ
ＱＵＥＳＴ（問い合わせ＝質問）およびＧＥＴ−ＡＮＳ
（質問の答読み取り）のために、相手にコマンド（命
令）を送り、命令の結果を問い合わせる場合（図２０
（ｂ））には、５パケット必要とし、相手に問い合わせ
を行い、ＯＫならばコマンドを送る場合（図２０
（ａ））には、７パケットを必要としている。各パケッ
トは、「送るべきデータ」のほかに、「モード」、「相
手機器アドレス」、「送信してきた機器のアドレス」、
「送信パケットの種類」を含むため、多くのパケットの
通信は、通信速度を低下させる問題がある。

【０００５】また、図２０の従来の通信方法では、”Ｅ
ＮＤ”コマンドパケットで相手機器（スレーブ機器）の
ロックを解除するので、１パケット余計に必要としてい
た。この”ＥＮＤ”コマンドを構成する１バイト送るに
は、アドレス等パケットの頭の部分のデータも必要なの
で、結局、４７ビット送らなければならなかった。な
お、ロックとは、マスター機器から送られてきたロック
通信データパケットにより、そのマスター機器以外の機
器からの命令パケットを受け付けなくすることをいう。
ロックを解除するには、ロックした相手（マスター機
器）からアンロック通信データを受信する必要がある。
アンロック状態になれば、どの機器からもデータを受信
できるようになる。

【０００６】従来、コマンド（ＣＭＤ）は、複数のパケ
ットで構成されており、受信側は、最初のパケット受信
によりロックされ、最後のパケット受信によりアンロッ
クされるが、アンロック用のパケットが送られてこなけ
れば、ロック状態が継続し、他の機器からの受信を行え
なくなってしまう。そこで、従来は、受信側は、ロック
モードのパケットを受信したら、ロックタイマーをスタ
ートさせ、アンロック用パケットが送られてこなくて
も、一定時間後にアンロックモードにしている。このよ
うに、従来は、アンロックにするためのタイマーが必要
であった。

【０００７】

【発明が解決しようとする課題】本発明の第１の目的
は、処理が簡単で、通信速度を高めることができる通信
方法を提供することにある。

【０００８】本発明の第２の目的は、受信側に問い合わ
せを行わなくても、受信側の状態を正しく把握できる通
信方法を提供することにある。

【０００９】本発明の第３の目的は、受信側がコマンド
のためのアンロック用タイマーを備える必要のない通信
方法を提供することにある。

【００１０】本発明の第４の目的は、データ送信の場合
に、受信側がすべてのパケットに対してロックタイマー
を働かせる必要がない通信方法を提供することにある。

【００１１】

【課題を解決するための手段】請求項１に記載の通信方
法は、バスを介して通信を行う通信方法であって、１つ
のコマンドを１つのパケットで送信することを特徴とす
る。

【００１２】請求項２に記載の通信方法は、コマンド受
信後、所定時間内に処理が終了しなくても、送信側に経
過報告を行うことを特徴とする。

【００１３】請求項３に記載の通信方法は、コマンドを
常にアンロックモードで送信することを特徴とする。

【００１４】請求項４に記載の通信方法は、データ送信
の場合、最初のパケットから最後から１つ前のパケット
までロックモードで送信し、最後のパケットはアンロッ
クモードで送信することを特徴とする。

【００１５】

【作用】請求項１の構成の通信方法においては、１つの
コマンドが１つのパケットで送信される。従って、コマ
ンドの処理が簡単で、通信速度を高めることができる

【００１６】請求項２の構成の通信方法においては、コ
マンド受信後、所定時間内に処理が終了しなくても、送
信側に経過報告が行われる。従って、受信側に問い合わ
せを行わなくても、受信側の状態を正しく把握できる。

【００１７】請求項３の構成の通信方法においては、コ
マンドが常にアンロックモードで送信される。従って、
受信側は、コマンドのためのアンロック用タイマーを備
える必要がなくなる。

【００１８】請求項４の構成の通信方法においては、デ
ータ送信の場合、最初のパケットから最後から１つ前の
パケットまでロックモードで送信され、最後のパケット
はアンロックモードで送信される。従って、データ送信
の場合に、受信側がすべてのパケットに対してロックタ
イマーを働かせる必要がなくなる。

【００１９】

【実施例】図１は、本発明の通信方法の適用対象である
ＡＶシステムの一例の構成を示す。操作釦１を操作する
と、インターフェース３を介してＣＰＵ４に所定のコマ
ンドを入力することができる。また、同様に、コマンダ
１２を操作すると、コマンダ１２から赤外線が出射さ
れ、受信部２によりこの赤外線が受光される。その結
果、受信部２よりインターフェース３を介して、やは
り、ＣＰＵ４に対して所定のコマンドを入力することが
できる。

【００２０】ＣＰＵ４は、入力されたコマンドを処理し
て、例えば、チューナ１６に対する選局命令を出力した
り、後述のＤ２Ｂ通信処理ＣＰＵ９に対して内部バス２
０を介してコマンドを出力する（なお、ＣＰＵ４とチュ
ーナ１６との間も内部バス２０で接続されているが、簡
単のために図示は省略してある）。ＲＯＭ５は、ＣＰＵ
４が動作する上において必要なプログラムを記憶してい
る。ＲＡＭ６は、ＣＰＵ４の処理の結果得られたデータ
等を記憶する。不揮発性メモリ７は、電源オフ後も記憶
しておく必要のあるデータ、例えば、他のＡＶ機器（第
１ＶＴＲ（ビデオテープレコーダ）３０、第２ＶＴＲ４
０およびＬＤＰ（レーザディスクプレーヤ）５０）との
接続状態等を記憶する。クロックタイマ８は、計時動作
を常に行っており、時刻情報を発生している。

【００２１】ＣＰＵ４、ＲＯＭ５、ＲＡＭ６およびクロ
ックタイマ８は、テレビジョン受像機用メインマイクロ
コンピュータを構成する。

【００２２】Ｄ２Ｂ通信処理ＣＰＵ９は、内部バス２０
を介してＣＰＵ４に接続されており、かつＤ２Ｂ通信処
理ＩＣ１０およびＤ２ＢバスすなわちＤ２Ｂ制御線２１
を介して第１ＶＴＲ３０、第２ＶＴＲ４０、およびＬＤ
Ｐ５０等の他のＡＶ機器とシリアルに接続され、データ
およびコマンドの送受を行う。なお、Ｄ２Ｂ通信処理Ｃ
ＰＵ９用のＲＯＭおよびＲＡＭも設けられているが、図
示は省略してある。

【００２３】ＣＰＵ９は、バッファ群１５に接続されて
おり、データを受信すると、バッファ群１５のうち受信
データに対応したバッファに記憶する。すなわち、ＣＰ
Ｕ９は、ヘッダ（ヘッダは送信先／送信元情報であるル
ート情報を含む）を受信すると、ヘッダバッファに記憶
し、コマンド（ＣＭＤ）を受信すると、コマンドバッフ
ァに記憶し、ＯＳＤ（オンスクリーンデータ）データを
受信すると、ＯＳＤデータバッファに記憶し、リクエス
ト（ＲＥＱ）を受信すると、リクエストバッファに記憶
する。また、ＣＰＵ９は、リクエストに対する返事をリ
クエスト返事用バッファに記憶する。なお、バッファ群
１５は、ＣＰＵ９用のＲＡＭを兼用することもできる。

【００２４】第１ＶＴＲ３０は、ＡＶ信号線３１を介し
て切換器１８の端子Ｔ１に接続され、切換器１８との間
でビデオ信号およびオーディオ信号の送受ができるよう
になっている。第２ＶＴＲ４０は、ＡＶ信号線４１を介
して切換器１８の端子Ｔ２に接続され、切換器１８との
間でビデオ信号およびオーディオ信号の送受ができるよ
うになっている。ＬＤＰ５０は、ＡＶ信号線５１を介し
て切換器１８の端子Ｔ３に接続され、切換器１８との間
でビデオ信号およびオーディオ信号の送受ができるよう
になっている。

【００２５】切換器１８から出力されるビデオ信号およ
びオーディオ信号は、ＣＰＵ６または９によって選択さ
れようになっている。

【００２６】ＣＲＴ（陰極線管）１３は、切換器１８か
ら出力されるビデオ信号が示す画像を表示する。また、
メッセージ表示回路１４は、ＣＰＵ９から内部バス２０
を介して送られてくるＯＳＤデータを、メッセージとし
て、ＣＲＴ１３の所定領域に表示する。また、切換器１
８から出力されるオーディオ信号は、図示しないスピー
カによって再生される。

【００２７】図１の操作釦１、受信部２、インターフェ
ース３、ＣＰＵ４、ＲＯＭ５、ＲＡＭ６、不揮発性メモ
リ７、クロックタイマ８、Ｄ２Ｂ通信処理ＣＰＵ９、Ｄ
２Ｂ通信処理ＩＣ１０、ＣＲＴ１３、メッセージ表示回
路１４、チューナ１６、切換器１８およびスピーカ（図
示せず）は、ＡＶセンターすなわちテレビジョン受像機
１００を構成する。

【００２８】第１ＶＴＲ３０、第２ＶＴＲ４０およびＬ
ＤＰ５０も、ＡＶセンター１００のＤ２Ｂ通信処理ＣＰ
Ｕ９およびバッファ群１５にそれぞれ対応するＤ２Ｂ通
信処理ＣＰＵおよびバッファ群を備えており、Ｄ２Ｂ制
御線２１を介して、ヘッダ、コマンド、リクエスト、お
よびＯＳＤデータ等を送受する。

【００２９】後述のマスター機器は、ＡＶセンター１０
０、第１ＶＴＲ３０、第２ＶＴＲ４０およびＬＤＰ５０
のいずれかであり、スレーブ機器も、ＡＶセンター１０
０、第１ＶＴＲ３０、第２ＶＴＲ４０およびＬＤＰ５０
のいずれか（マスター機器以外の機器）である。

【００３０】図２は、図１のＤ２Ｂバス２１上を伝送さ
れる通信パケットデータの一例を示す。図２中、マスタ
ーアドレスビットは、送信側の機器アドレスを示し、ス
レーブアドレスビットは、受信側の機器アドレスを示
し、アクノーリッジビットは、受信側から送信側に送る
各バイト毎のアクノーリッジ（ＡＣＫ）信号／ノットア
クノーリッジ（ＮＡＫ）信号であり、コントロールビッ
トは、パケットの種類およびロック／アンロックの指定
を行う。モード１の場合、最大テキストデータは、３２
バイトである。

【００３１】図３は、本発明のコマンド送信の一実施例
を示す図である。この例では、マスター機器からスレー
ブ機器への１つのコマンド／データが１つのパケットで
終了する。１つのコマンド／データは、アンロックモー
ドで送信される。コマンドを受信したスレーブ機器は、
マスター送信モードでステータスを返す。但し、データ
を受信したときは、返事を返さない。

【００３２】図４は、本発明のデータ送信の一実施例を
示す図である。例えばＯＳＤデータや透過データ等のデ
ータを複数パケット（フレーム）で送信するには、ま
ず、マスター機器は、最初のパケットで、送信相手（ス
レーブ機器）の通信デバイスが他の機器からの信号を受
信できないようにロックをかける。具体的には、アンロ
ックモードでのデータ転送の場合に”Ｆ”Ｈであるコン
トロールビットの値を”Ｂ”Ｈで伝送する。そして、複
数パケットの最後のパケットのコントロールビットの値
を”Ｆ”Ｈにして、アンロックにする。受信側がロック
されたままアンロックモードのパケットが送信されてこ
ないときの不都合を回避するために、例えばロックされ
た後、１ｓ（１秒）間、受信パケットがない場合、アン
ロックにするロックタイマーを用意し、このロックタイ
マーをロックモードのパケットを受信した時点でスター
トさせるとよい。

【００３３】図５は、本発明の状態問い合わせコマンド
に対するステータス返事の一実施例を示す図である。こ
の例では、マスター機器からスレーブ機器に問い合わせ
コマンドを送り、このコマンドを受けたスレーブ機器は
マスター送信でステータスを返す。

【００３４】図６は、本発明のステータス自動発信の一
実施例を示す図である。例えば、図１のＶＴＲ３０およ
び４０ならびにＬＤＰ５０は、これらの機器の状態が変
化したらその内容をＡＶセンター１００に報告すること
により、ＡＶセンター１００は、余計な問い合わせ処理
を行わなくてもよくなる。従って、バス２１に無駄な伝
送信号が流れなくなるので、通信効率が向上する。

【００３５】図７は、本発明の同報通信におけるステー
タス自動発信の一実施例を示す図である。図８は、本発
明の同報通信の一実施例を示す図である。２つ以上の機
器が時間的に正確な処理が必要な場合、基準となる機器
から同報通信機能を使用して時間情報等を送信するとよ
い。これにより、例えば、正確に同期がとれたフィーチ
ャー実行が可能となる。なお、同報通信以外の通信は、
１対１通信なので、受信側が必ずビットレベルのアクノ
ーリッジ信号（ＡＣＫ）／ノットアクノーリッジ信号
（ＮＡＫ）を送るが、同報通信では、ビットレベルのＡ
ＣＫ／ＮＡＫの送信は、ＡＶセンター１００のみが行
う。そして、ＡＣＫ／ＮＡＫの送信タイミングでは、Ａ
Ｖセンター１００以外の機器は、「１」でも「０」でも
なく、オープンの状態にする必要がある。このため、同
報通信時、スレーブ機器からバイト毎のＮＡＫを受けた
ときには、それから例えば２５ｍｓ以上経過後、マスタ
ー送信をおこなって、バイト毎のＡＣＫは出さないよう
にスレーブ機器にたいしてアンロックモードでコマンド
を送るとよい。このコマンドは、最大３回まで送信す
る。

【００３６】図９は、本発明の通信方法におけるワンタ
ッチプレイ時の通信データの流れの一例を示す図であ
る。ＶＴＲは、プレイ釦が押されたとき、プレイ実行
後、ＴＶすなわちＡＶセンターにＴＶ内接続コマンドを
送り、ＴＶは内部接続処理が完了すると、ＶＴＲに完了
報告する。その後、ＶＴＲは、ＯＳＤ表示コマンド／Ｏ
ＳＤデータをＴＶに送信し、ＴＶは、ＯＳＤ表示処理
後、ＶＴＲに処理完了報告を行う。

【００３７】図１０は、本発明の通信方法における正常
終了の場合の通信データの流れの一例を示す図である。
マスター機器からコマンドを受信したスレーブ機器は、
内部処理終了後、マスター機器に正常終了報告を行う
が、例えば１００ｍｓ以内に終了しない場合には、コマ
ンド受信後、１００ｍｓ経過したとき、マスター機器
に”ビジー”を返し、その後、２５ｍｓ以内に終了した
場合には、上記”ビジー”を返した後、”処理完了”の
返事を送る。上記”ビジー”を返した後、１ｓ以内に処
理が終了しないときには、１ｓ毎に”処理中／ビジー”
の返事を返す。このように、スレーブ機器がコマンド受
信後、所定時間内に処理が終了しなくても、送信側に経
過報告を行うことにより、マスター機器は、スレーブ機
器に問い合わせを行わなくても、スレーブ機器の状態を
正しく把握できる。なお、１００ｍｓ，２５ｍｓおよび
１ｓは、単なる一例であって必要に応じて種々の値をと
ることができる。

【００３８】図１１は、本発明の通信方法においてパケ
ットが正しく送信または受信できなかった場合の通信デ
ータの流れの一例を示す図である。この例は、マスター
機器がスレーブ機器からバイト毎にＡＣＫ／ＮＡＫを受
けるようになっている場合において、１パケット中にマ
スター機器がＮＡＫを受けた例である。スレーブ機器
は、ＮＡＫを送信したとき、すなわち受信エラーのとき
には処理を行わず、マスター機器はＮＡＫを受信したと
き、すなわち送信エラーのときには、２５ｍｓ経過後、
再びコマンドを送信する。

【００３９】図１２は、本発明の通信方法における送信
エラーの場合の通信データの流れの一例を示す図であ
る。コマンドを送信した機器は、所定時間（例えば１０
０ｍｓ）以内に相手機器から返事を受信しないときに
は、例えば最大３回までコマンドを再送する。相手機器
から返事が来ない原因としては、相手機器が当該機器に
返事を送ったが受信エラーのために受信できない場合、
相手機器が故障で返事を送れない場合、および受信した
返事が意味不明の場合等がある。

【００４０】図１３は、本発明の通信方法においてロッ
クモードの複数データパケット（フレーム）を受信した
後に、アンロックモードの最後のデータパケットを受信
したとき（正常）と、受信しないとき（異常）の処理の
一例を示す図である。アンロックモードの最後のデータ
パケットを受信しなかった場合には、ロックタイマーを
スタートさせ、例えば１０００ｍｓ経過後に、アンロッ
クモードにする。

【００４１】なお、この実施例においては、データパケ
ット受信後、返事を送信するようにしているが、この返
事を省略することも可能である。

【００４２】図１４は、本発明の通信方法においてパケ
ットを正しく受信できたが正常に終了できなかったとき
の処理例を示す図である。図１４（ａ）は、スレーブ機
器がコマンドを受信したが、そのコマンドに対応する処
理を行うことができなかった例である。図１４（ｂ）
は、スレーブ機器がコマンドを受信したが、そのコマン
ドに対応する機能がなかった例である。図１４（ｃ）
は、スレーブ機器がコマンドを受信したが、所定時間以
内に処理が完了しなかった例である。

【００４３】図１５は、本発明の通信方法における受信
処理の一例を示すフローチャートである。まず、パケッ
トを受信すると、図１のＤ２Ｂ通信処理ＣＰＵ９は、返
事タイマー（例えば、設定時間１００ｍｓ）をスタート
させる（ステップＳ１）。次に、ＣＰＵ９は、受信パケ
ットがコマンドかデータか判断し（ステップＳ２）、コ
マンドならば命令処理を行うべきか、または、問い合わ
せ処理を行うべきかを判断し（ステップＳ３）、命令処
理の場合には、処理内容を分析し、必要な処理を実行し
（ステップＳ４）、終了したら”終了”返事を送信する
（ステップＳ５）。問い合わせ処理の場合には、処理内
容を分析し、必要な処理を実行し（ステップＳ６）、終
了したら、”ステータス”を送信する（ステップＳ
７）。

【００４４】また、受信パケットがコマンドでない場
合、データであるか否か判定し（ステップＳ８）、デー
タであれば、データフレームに対応する処理を実行し
（ステップＳ９）、データでもなければ、その他、所定
の処理を実行する（ステップＳ１０）。

【００４５】図１６は、本発明の通信方法におけるタイ
マー割り込み処理の一例を示すフローチャートである。
ＣＰＵ９は、返事タイマーの時間を検出し（ステップＳ
１１）、設定時間が経過していたら（ステップＳ１２の
ＹＥＳ）、”ビジー”返事を送信する。

【００４６】なお、上記実施例は、ＡＶシステムに関す
るものであるが、本発明はこれに限定されず、ホームバ
スを使用したデータ伝送、モデムを使用した公衆回線経
由のデータ伝送、パソコン通信、ならびにパソコン−Ａ
Ｖ機器間通信等にも適用できる。

【００４７】また、上記実施例は、機器間のバスプロト
コルに関するものであるが、本発明は、機器内部のブロ
ックモジュール間の通信にも応用できる。

【００４８】また、車、電車、船舶、および飛行機内の
機器間通信にも適用できる。

【００４９】

【発明の効果】請求項１の通信方法によれば、１つのコ
マンドを１つのパケットで送信するようにしたので、コ
マンドの処理が簡単で、通信速度を高めることができる

【００５０】請求項２の通信方法によれば、コマンド受
信後、所定時間内に処理が終了しなくても、送信側に経
過報告を行うようにしたので、受信側に問い合わせを行
わなくても、受信側の状態を正しく把握できる。

【００５１】請求項３の通信方法によれば、コマンドを
常にアンロックモードで送信するようにしたので、受信
側は、コマンドのためのアンロック用タイマーを備える
必要がなくなる。

【００５２】請求項４の通信方法によれば、データ送信
の場合、最初のパケットから最後から１つ前のパケット
までロックモードで送信し、最後のパケットはアンロッ
クモードで送信するようにしたので、データ送信の場合
に、受信側がすべてのパケットに対してロックタイマー
を働かせる必要がなくなる。

【図面の簡単な説明】

【図１】本発明の通信方法が適用されるＡＶシステムの
一例の構成を示すブロック図である。

【図２】図１のＤ２Ｂバス２１上を伝送される通信パケ
ットデータの一例を示す図である。

【図３】本発明のコマンド送信の一実施例を示す図であ
る。

【図４】本発明のデータ送信の一実施例を示す図であ
る。

【図５】本発明の状態問い合わせコマンドに対するステ
ータス返事の一実施例を示す図である。

【図６】本発明のステータス自動発信の一実施例を示す
図である。

【図７】本発明の同報通信におけるステータス自動発信
の一実施例を示す図である。

【図８】本発明の同報通信の一実施例を示す図である。

【図９】本発明の通信方法におけるワンタッチプレイ時
の通信データの流れの一例を示す図である。

【図１０】本発明の通信方法における正常終了の場合の
通信データの流れの一例を示す図である。

【図１１】本発明の通信方法においてパケットが正しく
送信または受信できなかった場合の通信データの流れの
一例を示す図である。

【図１２】本発明の通信方法における送信エラーの場合
の通信データの流れの一例を示す図である。

【図１３】本発明の通信方法においてロックモードの複
数データパケット（フレーム）を受信した後に、アンロ
ックモードの最後のデータパケットを受信したとき（正
常）と、受信しないときの（異常）の処理の一例を示す
図である。

【図１４】本発明の通信方法においてパケットを正しく
受信できたが正常に終了できなかったときの処理例を示
す図である。

【図１５】本発明の通信方法における受信処理の一例を
示すフローチャートである。

【図１６】本発明の通信方法におけるタイマー割り込み
処理の一例を示すフローチャートである。

【図１７】マスター機器からスレーブ機器に対してコマ
ンド（ＣＭＤ）を送り、その後、問い合わせを行う従来
の通信方法の例を示す図である。

【図１８】相手機器の状態を問い合わせるだけの従来の
通信方法の例を示す図である。

【図１９】相手機器に命令を送り、命令の結果を問い合
わせる従来の通信方法の例を示す図である。

【図２０】従来のＤ２Ｂ仕様における種々の通信態様を
示す図である。

【符号の説明】

９Ｄ２Ｂ通信処理ＣＰＵ１３ＣＲＴ１４メッセージ表示回路１５バッファ群１８切換器２１Ｄ２Ｂバス３０第１ＶＴＲ４０第２ＶＴＲ５０ＬＤＰ

───────────────────────────────────────────────────── フロントページの続き (72)発明者杉山宏一東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者佐藤真東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者勝山明東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者刑部義雄東京都品川区北品川６丁目７番35号ソニー株式会社内 (72)発明者草ヶ谷康夫東京都品川区北品川６丁目７番35号ソニー株式会社内

Claims

【特許請求の範囲】

【請求項１】バスを介して通信を行う通信方法におい
て、１つのコマンドを１つのパケットで送信することを特徴
とする通信方法。
【請求項２】前記コマンド受信後、所定時間内に処理
が終了しなくても、送信側に経過報告を行うことを特徴
とする請求項１記載の通信方法。
【請求項３】前記コマンドを常にアンロックモードで
送信することを特徴とする請求項１記載の通信方法。
【請求項４】データ送信の場合、最初のパケットから
最後から１つ前のパケットまでロックモードで送信し、
最後のパケットはアンロックモードで送信することを特
徴とする請求項１記載の通信方法。