JP4419082B2 - 通信システム - Google Patents

通信システム Download PDF

Info

Publication number
JP4419082B2
JP4419082B2 JP2005085786A JP2005085786A JP4419082B2 JP 4419082 B2 JP4419082 B2 JP 4419082B2 JP 2005085786 A JP2005085786 A JP 2005085786A JP 2005085786 A JP2005085786 A JP 2005085786A JP 4419082 B2 JP4419082 B2 JP 4419082B2
Authority
JP
Japan
Prior art keywords
data
grandchild
master device
status information
slave
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 - Fee Related
Application number
JP2005085786A
Other languages
English (en)
Other versions
JP2006267569A (ja
Inventor
晴道 堀田
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.)
Yamaha Corp
Original Assignee
Yamaha Corp
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 Yamaha Corp filed Critical Yamaha Corp
Priority to JP2005085786A priority Critical patent/JP4419082B2/ja
Priority to US11/377,126 priority patent/US20060218321A1/en
Publication of JP2006267569A publication Critical patent/JP2006267569A/ja
Priority to US12/487,606 priority patent/US7979609B2/en
Application granted granted Critical
Publication of JP4419082B2 publication Critical patent/JP4419082B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)

Description

本発明は、デジタルミキサ等の制御に用いて好適な通信システムに関する。
従来より、2本の信号線を用いて複数のデバイス間でデータをやりとりするシリアル・バスとして、I2Cバスが知られている。また、このI2Cバスを電子楽器内部のデバイス(例えば鍵盤、パネル操作子、表示器、音源等)間の通信に応用したもの(Eバス)が特許文献1に開示されている。なお、I2Cにおいては、各デバイスに対して「1」〜「127」のアドレスが付与される。従って、原理上は最大「127」のデバイスをI2Cバスに接続することが可能である。
特開2002−251183号公報
しかし、現実的には、I2Cのデバイス数が増加すると、リピータと呼ぶバッファアンプをI2Cバスの随所に介挿する必要がある。従って、デバイス数の多い機器においては、リピータの数が多くなりコストアップを招くという問題があった。特に、デジタルミキサは電子楽器と比較すると、操作子や表示器等の数が多いため、I2Cバス上のデバイス数も多くせざるを得えなかった。
また、I2Cバスに接続される各デバイスには、バスとの接続用のバスインタフェースが必要である。このバスインタフェースから送信先デバイスに対してデータを送信するためには、送信先デバイスのアドレスを指定する機能が必要であり、例えばRS232C等のシリアル通信用のインタフェースと比較すると、構成が複雑であった。
この発明は上述した事情に鑑みてなされたものであり、I2Cバス等の複雑なシリアル・バスに接続するデバイス数を減少させつつ、実質的に多数のデバイス間の通信を実現できる通信システムを提供することを目的としている。
上記課題を解決するため本発明にあっては、下記構成を具備することを特徴とする。なお、括弧内は例示である。
請求項1記載の通信システムにあっては、マスタデバイス(子システム)と、該マスタデバイスに対してシリアルデータを送受信する複数のスレーブデバイス(孫システム)とから成る通信システムにおいて、前記マスタデバイスのデータ出力端(TXD)と、前記複数のスレーブデバイスの各データ入力端(RXD)とをパラレルに接続する第1の接続ライン(211−3)と、前記第1の接続ライン(211−3)とは別体に設けられ前記マスタデバイスのデータ入力端(RXD)と、前記複数のスレーブデバイスの各データ出力端(TXD)とをパラレルに接続する第2の接続ライン(211−2)と、前記マスタデバイスのビジー信号入力端と、前記複数のスレーブデバイスの各ビジー信号出力端とを接続し、接続された全てのスレーブデバイスが非ビジー状態(“1”)にあるときのみ前記マスタデバイスにて非ビジー値(“1”)を示すビジー信号(BUSY)が受信されるビジー信号ライン(211−5)と、前記マスタデバイスに設けられ、一のスレーブデバイスを特定するアドレス情報(430)と、前記マスタデバイスがデータを受信するか送信するかを指定する通信方向フラグ(432)とを含むステータス情報(401,411)を、前記マスタデバイスにて受信されるビジー信号(BUSY)が非ビジー値(“1”)を示すことを条件として、前記第1の接続ラインを介して出力開始するステータス情報送信手段(SP64,SP76)と、前記各スレーブデバイスに設けられ、前記第1の接続ライン(211−3)を介して出力されたステータス情報(401,411)を受信するステータス情報受信手段(266,図16のルーチンの起動)と、前記マスタデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを送信する旨を指定する通信方向フラグ(432)が送信された場合に、前記ステータス情報に続いて前記第1の接続ラインを介して前記一のスレーブデバイス宛のデータを、前記マスタデバイスにて受信されるビジー信号(BUSY)が非ビジー値を示すことを条件に送信開始するマスタ・データ送信手段(SP68)と、前記各スレーブデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを送信する旨を指定する通信方向フラグ(432)が送信された場合に、前記ステータス情報に続いて前記第1の接続ライン(211−3)を介して送信される前記一のスレーブデバイス宛のデータを受信するスレーブ・データ受信手段(SP118)と、前記各スレーブデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを受信する旨を指定する通信方向フラグ(432)が送信され、かつ、前記アドレス情報(430)によって自機が指定されると、前記ステータス情報に続いて前記第2の接続ライン(211−2)を介して前記マスタデバイス宛のデータを送信するスレーブ・データ送信手段(SP126)と、前記マスタデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを受信する旨を指定する通信方向フラグ(432)が送信された場合に、前記ステータス情報に続いて前記第2の接続ライン(211−2)を介して前記マスタデバイス宛に送信されたデータを受信するマスタ・データ受信手段(SP80)と、前記各スレーブデバイスに設けられ、少なくとも、前記ステータス情報受信手段における前記ステータス情報の受信中、前記スレーブ・データ受信手段(SP118)における前記データの受信中、および、前記スレーブ・データ送信手段(SP126)における前記データの送信中であるか否かに応じて、前記ビジー信号ライン(211−5)に当該スレーブデバイスがビジー状態にあるか否かを示すビジー信号を出力するビジー信号出力手段とを有することを特徴とする。
さらに、請求項2記載の構成にあっては、請求項1記載の通信システムにおいて、前記ステータス情報送信手段(SP64,SP76)が出力するステータス情報(401,411)は、該ステータス情報(401,411)が出力される毎に所定の規則で変動する(「1」づつカウントアップされる)エラーチェックコード(434)を含むものであり、前記各スレーブデバイスに設けられ、前記アドレス情報(430)によって自機が指定されたか否かにかかわらず、前記エラーチェックコード(434)が正当か否かを検証するエラーチェックコード検証手段(SP104)をさらに有することを特徴とする。
さらに、請求項3記載の構成にあっては、請求項1または2記載の通信システムにおいて、前記各スレーブデバイスから前記マスタデバイスに対して送信要求信号(TXREQ)を伝送する第3の接続ラインと、前記各スレーブデバイスに設けられ、前記マスタデバイスにデータ送信を行なう必要が生じた際に前記第3の接続ラインを介して前記送信要求信号(TXREQ)を出力する送信要求手段(SP36)と、前記マスタデバイスに設けられ、前記ステータス情報(411)に含めるべきアドレス情報(430)に係るスレーブデバイスとして、前記送信要求信号(TXREQ)を出力した一または複数のスレーブデバイスの中から一のスレーブデバイスを決定するスレーブデバイス決定手段(SP74)とをさらに有することを特徴とする。
このように、マスタデバイス内のステータス情報送信手段が通信方向フラグを含むステータス情報を送信し、しかる後にマスタ・データ送信手段またはスレーブ・データ送信手段のうち一方がデータを送信する構成によれば、データを送信すべきデバイスがマスタデバイスによって特定された後にデータ通信が開始されるため、例えば複数のデバイスが同時にデータ送信を開始してデータが衝突するような事態が未然に防止され、通信の信頼性を高めることができる。さらに、データが衝突した場合の調停処理なども不要になるため、機器のコストダウンを実現することができる。
また、各スレーブデバイスが、自機が通信相手として指定されたか否かにかかわらずエラーチェックコードを検証する構成によれば、データ通信に直接的に関与していないスレーブデバイスにも「チェック装置」としての機能を発揮させることができ、スレーブデバイスが有するリソースを有効に利用して装置全体の信頼性を高めることができる。
さらに、各スレーブデバイスからマスタデバイスに対して第3の接続ラインを介して送信要求信号を出力する構成によれば、他のスレーブデバイスおよびマスタデバイス間の通信を全く妨げることなく、送信要求をマスタデバイスに迅速に通知することができる。
1.実施例のハードウエア構成
1.1.操作パネル100の構成
次に、本発明の一実施例のデジタルミキサの操作パネル100の全体構成を図1を参照し説明する。図において操作パネル100は、セクション101〜104の「4」セクションから構成されている。ここで、セクション101,102は入力チャンネルの音量等を調整するフェーダ等から構成されている。同様に、セクション104は出力チャンネルの音量等を調整するフェーダ等から構成されている。また、セクション103は、これら入出力チャンネルのうち選択された一のチャンネルにおける詳細なパラメータの設定等に用いられる。ここで、各入力チャンネルにおいて音量・音質調節された音声信号は、ステレオバス、MIXバス、CUEバス等のバスに出力される。
ここで、ステレオバスとは、主として客席への放音に使用される音声信号をミキシングするバスであり、MIXバスとは補助的な放音およびレコーディング等の用途に使用されるバスである。また、CUEバスとは、デジタルミキサの操作者等に対するモニタ用の音声信号をミキシングするバスである。そして、各出力チャンネルはこれらバスに対して各々割り当てられており、各バスにてミキシングされた音声信号のレベル等がセクション104において調節され、外部に出力されることになる。
次に、セクション101,103の詳細構成を図2を参照し説明する。まず、セクション101の内部において112−1〜nはセンド・オン/オフスイッチであり、各々対応する入力チャンネルを各MIXバスに出力するか否かを設定する。124−1〜nは電動フェーダであり、各入力チャンネルの音声信号のゲインを設定する。114−1〜nはセンドモードスイッチであり、各入力チャンネルから各MIXバスに出力される音声信号として、電動フェーダ124−1〜nによる音量調節前の信号または音量調節後の信号のうち一方を選択する。116−1〜nはロータリーエンコーダであり、指定されたMIXバスに対するセンドレベル等を設定する。118−1〜nはLED表示器群であり、各入力チャンネルの各種状態をLEDの点灯/消灯状態によって表示する。
120−1〜nはセレクトスイッチであり、セクション103において詳細なパラメータを設定すべきチャンネルを選択する。122−1〜nはオン/オフスイッチであり、各々対応する入力チャンネルをステレオバスおよびMIXバスに出力するか否かを設定する。126−1〜nはCUEスイッチであり、各入力チャンネルの音声信号をCUEバスに出力するか否かを選択する。
ここで、上述した各スイッチ、ロータリーエンコーダおよび電動フェーダの状態は、デジタルミキサ内部の制御システム(図3の回路、詳細は後述する)により、自動的に設定することも可能である。まず、上述した各スイッチはLEDを内蔵したキースイッチであり、対応するパラメータのオン/オフ状態は制御システム内で把握されている。そして、このLEDをオン/オフすることにより、該パラメータのオン/オフ状態が操作者に対して表示されることになる。従って、制御システムの内部にて当該パラメータのオン/オフ状態を変更し、変更結果に応じてLEDをオン/オフすれば、その状態を自動的に設定することができる。
また、各ロータリーエンコーダは、無限回動する形式のものであり、操作者がこれを回動させると、所定の単位角度だけ回動される毎に、ワンショットのパルスが制御システムに出力される。これにより、制御システムにおいては、このパルス数をカウントすることにより、操作前後におけるロータリーエンコーダの回動角度を得ることができる。このロータリーエンコーダに対しては、上述した通り、指定されたMIXバスに対するセンドレベル等のパラメータが割り当てられているから、制御システム内部では当該センドレベルが回動角度に応じて増減される。さらに、各ロータリーエンコーダの周囲には、十数個程度のLEDが環状に配置されており、対応するパラメータの設定値の概算値がこのLEDによって表示される。従って、制御システムの内部にて当該パラメータの値を変更し、変更結果に応じてこれらLEDのオン/オフ状態を設定すれば、該パラメータを自動的に設定することができる。
また、操作者によって電動フェーダが操作されると、その操作位置が検出され、制御システムに通知される。これにより、制御システムにおいては、電動フェーダの操作位置に応じてパラメータ値(主として音声信号のゲイン)が設定される。一方、かかるパラメータの値は、電動フェーダの物理的な操作位置に応じて決定されるため、かかるパラメータ値をパネル上に自動的に再現するために、電動フェーダにはモータ等の駆動機構が設けられている。すなわち、パラメータ値を自動設定する場合には、制御システムの指令に基づいてモータが駆動され、電動フェーダの物理的な操作位置が設定されることになる。
ここで、セクション101の各操作子等はさらに3種類のサブセクション101−A,101−B,101−Cに分割される。なお、「サブセクション」とは、比較的廉価なCPU1個で制御可能な範囲毎にに「セクション」を便宜上分割したものである。まず、サブセクション101−Aは、電動フェーダ124−1〜nによって構成され、サブセクション101−Bはオン/オフスイッチ112−1〜n、センドモードスイッチ114−1〜n、およびロータリーエンコーダ116−1〜nから構成される。さらに、サブセクション101−Cは、LED表示器群118−1〜n、セレクトスイッチ120−1〜n、オン/オフスイッチ122−1〜nおよびCUEスイッチ126−1〜nから構成される。以上、セクション101の構成について詳述したが、セクション102,104もセクション101と同様に構成されており、各々3種類のサブセクション102−A,102−B,102−Cおよびサブセクション104−A,104−B,104−Cに分類される。
次に、セクション103の内部において130はタッチスクリーンであり、ディスプレイと、その表面に配置された透明なタッチパネルとから構成されている。そして、操作者が指先またはライトペン等でタッチパネルを押下すると、その旨およびタッチパネル上の押下位置の座標とが検出される。132−1〜132−6,136−1〜136−14,138−1〜138−15はスイッチであり、セクション103に割り当てられた機能に応じて、各種パラメータのオン/オフ状態等を設定する。134−1〜134−15はロータリーエンコーダであり、例えば上記セレクトスイッチ120−1〜nによって選択された入力チャンネルから各MIXバスへのセンドレベルを調節するために用いられる。上記セクション103の構成のうち、タッチスクリーン130はサブセクション103−Aを構成し、スイッチ132−1〜132−6およびロータリーエンコーダ134−1〜134−15はサブセクション103−Bを構成し、スイッチ136−1〜136−14,138−1〜138−15はサブセクション103−Cを構成する。
1.2.制御システムの全体構成
次に、本実施例のデジタルミキサの制御システムの全体構成を図3を参照し説明する。図おいて220は親システムであり、デジタルミキサ全体の監視および制御を行う。201−A,202−A,203−A,204−Aは子システムであり、各々セクション101〜104に関する監視および制御を統括するとともに、サブセクション101−A,102−A,103−A,104−Aに対する監視および制御を直接的に実行する。201−B,202−B,203−B,204−B,201−C,202−C,203−C,204−Cは孫システムであり、各子システム201−A〜204−Aの制御の下、サブセクション101−B,102−B,103−B,104−B,101−C,102−C,103−C,104−Cを監視および制御する。より具体的には、親システム220はI2Cに準拠するEバスのコネクタを2つ備えたシステム基板であり、各子システムはEバスのコネクタと、双方向シリアル通信を行うSバスのコネクタとを一つずつ備えたシステム基板であり、各孫システムはSバスのコネクタを1つ備えたシステム基板である。216,217はEバスのケーブルであり、親システム220および子システム201−A〜204−AのEバスコネクタに接続され、それらのシステム間で信号を伝送する。211〜214はSバスであり、各子システムと配下の孫システムのSバスコネクタに接続され、それらのシステム間で信号を伝送する。
親システム220の内部において222はEバスI/O部であり、Eバス216,217に対して信号を入出力するとともに、Eバス216,217に対するリピータ機能を有している。224は親システム220の各部を接続するCPUバスである。234は信号処理部であり、デジタル音声信号に対して、イコライジング、ミキシング、レベル調節等の処理を実行する。上述したステレオバス、MIXバス等もこの信号処理部234で実行されるアルゴリズムによって実現されているものである。236は波形I/O部であり、外部から入力される多チャンネルのアナログ信号またはデジタル信号を親システム220の内部形式のデジタル信号に変換し信号処理部234に供給するとともに、信号処理部234から供給されたデジタル信号をアナログ信号または外部形式のデジタル信号に変換し出力する。
226はその他I/O部であり、デジタルミキサを遠隔制御する外部の制御装置等に接続される。228はCPUであり、フラッシュメモリ230に記憶されたプログラム(詳細は後述する)に基づいて、親システム220の各部を制御する。232はRAMであり、CPU228のワークメモリとして使用される。238はディスプレイであり、上述したタッチスクリーン130の一部を成す。
1.3.子システムおよび孫システムの構成
次に、子システムの一般的構成を図4(a)を参照し説明する。図4(a)において242は表示器群であり、各種LED等から構成される。但し、本実施例にあっては、子システムによって直接的に制御されるサブセクション101−A,103−A等において特に表示器群242に該当するものはない。244は操作子群であり、サブセクション101−Aにおいては電動フェーダ124−1〜n、サブセクション103−Aにおいてはタッチスクリーン130を構成するタッチパネルがこれに該当する。246はシリアルI/O部であり、Sバスを介して配下の孫システムとの間で各種信号を入出力する。248はEバスI/O部であり、Eバスを介して親システムとの間で各種信号を入出力する。252はCPUであり、フラッシュメモリ254に格納されたプログラムに基づいて子システム内の各部を制御する。256はRAMであり、CPU252のワークメモリとして使用される。
次に、孫システムの一般的構成を図4(b)を参照し説明する。図4(b)において262は表示器群であり、各種LED(単独のLED、スイッチに内蔵されたLED、ロータリーエンコーダの周囲のLED)等から構成される。264は操作子群であり、各種スイッチおよびロータリーエンコーダ等から構成される。266はシリアルI/O部であり、Sバスを介して対応する子システムとの間で各種信号を入出力する。272はCPUであり、フラッシュメモリ274に格納されたプログラムに基づいて、孫システム内の各部を制御する。276はRAMであり、CPU272のワークメモリとして使用される。
2.実施例の通信プロトコル
2.1.Eバス・プロトコル
2.1.1.物理的構成
次に、親システム220および子システム201−A〜204−A間を接続するEバス216,217のプロトコルを説明する。まず、Eバス216の具体的構成を図5に示す。但し、図5においてはEバス216(I2Cバス)を構成する7本のワイヤーのうち、クロック信号SCLを伝送するSCLライン216aと、データ信号SDAを伝送するSDAライン216bとの2本の信号線のみを図示する。なお、図示していない残り5本の信号線はイニシャルクリアライン1本と、電源ライン4本である。親システム220のEバスI/O部222の内部において371,372はプルアップ用の抵抗器であり、SCLライン216aおよびSDAライン216bを各々所定の電圧Vpにプルアップする。
361,362は電界効果トランジスタ(以下、単にトランジスタという)であり、各ライン216a,216bにオープンドレイン接続されている。ここで、Eバス216にEバスI/O部222「のみ」が接続されていたと仮定すると、トランジスタ361,362がオン状態になるとクロック信号SCLおよびデータ信号SDAは接地レベル付近の値になる。また、トランジスタ361,362がオフ状態になると、各信号SCL,SDAは電圧Vp付近の値になる。ここで、接地レベルと電圧Vpとの中間付近のある値を閾値とし、該閾値未満の電圧を論理値“0”とし、該閾値以上の電圧を論理値“1”とする。351,352はバッファであり、各信号SCL,SDAの論理値を検出する。
従って、EバスI/O部222においては、トランジスタ361,362をオン/オフすることにより、クロック信号SCLおよびデータ信号SDAを各々SCLライン216aおよびSDAライン216bを介して送信することができ、さらに各ライン216a,216b上の信号SCL,SDAをバッファ351,352を介して受信することができる。同様に、子システム201−Aおよび202−Aにおいても、各ライン216a,216bにオープンドレイン接続されたトランジスタ363,364および365,366と、各ライン216a,216bの論理値を検出するバッファ353,354および355,356とが設けられている。各ラインに接続されたトランジスタのうち何れかがオン状態になると当該ライン上の信号は“0”になるから、これらトランジスタは各ライン216a,216b上のワイアード・アンド回路を構成している。以上、Eバス216の構成を説明したが、Eバス217の構成もこれと同様である。そして、Eバス216,217は、EバスI/O部222内のリピータを介して相互に接続されている。
2.1.2.パケット形式
次に、SCLライン216aおよびSDAライン216bにおけるデータ転送時のタイミングチャートを図6に示す。Eバスシステムにおいては、バスが開放状態(“1”)の時のみにデータ転送を開始することができる。Eバスに接続されたデバイス(親システムまたは子システム)のうち、Eバスを介してデータを送信しようとするデバイスにおいては、各信号SCL,SDAの何れもが“1”である旨が確認された後、データ信号SDAとして“0”が出力される。これをスタートビット(Start Bit)という。このスタートビットにより、該デバイスによってEバスにデータが出力されようとしている旨が他のデバイスにおいて検出される。
ここで、Eバスに接続された各デバイス間では「1バイト(8ビット)」単位でデータ信号SDAが送受信される。また、クロック信号SCLはデータ信号SDAの各ビットが安定するタイミングで立ち下がるように、送信元デバイスによって生成される。そして、該「1バイト」のデータ信号SDAの送信が完了したとき、送信元デバイスにおいては確認用の「1ビット」のクロックパルス(ACK)が生成される。このACKが出力されるタイミングにおいては、送信元デバイスはデータ信号SDAとして“1”を出力するが、データを受信する側の送信先デバイスにおいては、正常なデータが受信された場合には、データ信号SDAとして“0”が出力される。これら信号のワイアード・アンドの結果、SDAライン216b上に現れるデータ信号SDAは結局は“0”になるため、送信元デバイスにおいては、送信先デバイスがデータ信号SDAを正常に受信したか否かを確認することができる。
また、各デバイスには、「7ビット」のユニークなアドレスが付与されている。そして、送信元デバイスにおいては、スタートビットが出力された後に、最初に「7ビット」の送信先アドレスと、R/Wビットと称するビットとが出力される。但し、本実施例においては、R/Wビットは常に“0”(Write)である。これに引き続いて、「7ビット」の送信元アドレスと、ダミーの“0”信号とが出力される。以上の「2バイト」によってパケットのヘッダ部370が構成される。これに引き続き、一または複数バイトから成るデータ部380が送信元デバイスから送信される。なお、本実施例においては、データ部380は常に「3バイト」長である。このデータ部380を構成する各バイトを第1データ、第2データ、第3データと呼ぶ。
ここで、本実施例におけるデバイス名およびアドレス名と、I2C規格におけるこれらの名称との関係について説明しておく。まず、本実施例における「送信元アドレス」は、I2C規格では「マスタアドレス」と呼ばれ、「送信元デバイス」は「マスタデバイス」と呼ばれる。また、「送信先アドレス」は「スレーブアドレス」と呼ばれ、「送信先デバイス」は「スレーブデバイス」と呼ばれる。「マスタデバイス」とは通信を開始させるとともにSCLライン216aにクロック信号SCLを出力するデバイスであり、必ずしもデータ部380を送信するデバイスに限られない。
すなわち、上述したR/Wビットが“0”(Write)であれば、マスタデバイスによってデータ部380が出力され、スレーブデバイスはこれを受信することになる。一方、R/Wビットが仮に“1”(Read)であれば、スレーブデバイスによってデータ部380が出力され、マスタデバイスはこれを受信することになる。しかし、本実施例のようなデジタルミキサにおいては、リアルタイム性が要求されるため、一のデバイスAから他のデバイスBに対してデータを送信する必要が生じたとき、デバイスAがマスタデバイスとなってデバイスBに対して直ちにデータ転送を開始する必要がある。このため、本実施例においては、マスタデバイスの出力するR/Wビットは常に“0”(Write)であり、I2C規格における「マスタデバイス」は「送信元デバイス」と同義になり、「スレーブデバイス」は「送信先デバイス」と同義になる。
次に、アービトレーションについて説明する。Eバスシステムにおいては、各デバイスはバスが開放状態(Hレベル)の時のみにデータ送信を開始することができるが、複数のデバイスが送信元デバイスとしてほぼ同時にデータ送信を開始しようとすることがある。この場合は、何れか一のデバイスに対してのみ通信を許可するアービトレーションが行われる。このアービトレーションでは、SDAラインに各デバイスのデータ出力部のトランジスタがワイヤードアンド接続されていることを利用している。具体的に説明すると、データ転送開始した際には、図4に示すようにスタートビットに続いて送信先アドレスがSDAライン216bに送出されるので、データ送信しようとする複数のデバイスにおいてこのSDAラインから受信したアドレスと自機がアドレス指定した送信先アドレスとが1ビットずつ対比される。この場合、同時に複数のデバイスからデータがSDAライン216bに送出された場合には、これらのデータはワイヤードアンドされていることからいずれかのデバイスが“0”を送出した際にSDAラインは“0”に保持されるようになる。
すると、デバイスによっては自機が指定した送信先アドレスの対比するビットが“1”であるのに対して、SDAライン216bから取り込まれたビットが“0”になる。このようにアドレスに不一致が生じた場合は、他のデバイスの優先順位が高いと判断してデータ出力がオフにされる。なお、これらデバイスの出力した送信先アドレスが一致している場合においても、送信元アドレスはデバイス毎に異なるから、必ず一のデバイスを除いた他のデバイスはデータ出力がオフにされることになる。
次に、上記各デバイスのアドレス構成を説明する。上述したように各デバイスのアドレスは「7ビット」から構成されているが、その上位「4ビット」をカテゴリIDといい、デバイスの種類を表す。例えば、親システム220のカテゴリIDを「0001b」(bは2進数)とし、子システムのカテゴリIDを「0010b」とするとよい。また、アドレスの下位「3ビット」をサブアドレスといい、各カテゴリ毎に「000b」〜「111b」の範囲でユニークな番号が付与される。上述したアービトレーションにおいては送信先アドレスの先頭から“0”が長く続くほど、その送信先デバイスへの送信が優先して実行されるから、データを転送する優先順序に応じてカテゴリIDを決定するとよい。
2.1.3.パケット種別
(1)プロトコルの種類
先行技術文献の特開2002−251183号公報に開示されたEバスシステムは元々は電子楽器内部のデバイスの相互接続のために開発されたものであり、電子楽器内部にて各種スイッチ、JOGコントローラ、コンティニュアスコントローラ等の操作状態を入出力するための「標準プロトコル」、MIDI信号を入出力するための「MIDIプロトコル」、および各デバイスに対する初期化処理等のコマンドを送信する「共通プロトコル」が定められている。各デバイスは、ホスト系(本実施例においては親システム220)を除いて、標準プロトコルまたはMIDIプロトコルのうち何れか一方のパケットのみを入出力できるようになっている。
各デバイスが標準プロトコルまたはMIDIプロトコルのうち何れを取り扱うものであるかは、カテゴリIDによって決定される。すなわち、同文献によれば、カテゴリIDが「0101b」であるデバイスに対してMIDIプロトコルが適用される。但し、共通プロトコルのパケットは、各デバイスがカテゴリIDにかかわらず、入出力することが可能である。本実施例においては、特にMIDI信号をEバスを介して伝送することは考慮していないため、適用されるプロトコルは標準プロトコルおよび共通プロトコルの二種類のみになる。すなわち、全てのデバイスは共通プロトコルおよび標準プロトコルのパケットを入出力することになる。
(2)共通プロトコル
次に、共通プロトコルおよび標準プロトコルのパケットの構成を図7を参照し説明する。
まず、Eバスシステムを起動する際、親システム220から各子システム201−A〜204−Aに対して、「C01:Eバススタート」なるパケットが送信される。このパケットにおいては、送信先アドレスは各子システムのアドレスであり、送信元アドレスは親システムのアドレスである。そして、データ部380の第1データは01h(hは16進数)、第2および第3データは00hに設定される。このパケットが受信されると、各子システムにおいては、Eバスに係る入出力処理が準備される。ところで、このEバススタートを送信するにあたっては、「ゼネラルコール」という送信方法を採用することができる。これは、送信先アドレスを「0000000b」とすることにより、他のデバイスに対して一斉にパケットを送信する方法である。この「ゼネラルコール」を用いてEバススタートを送信すると、1回の送信によって全子システムを初期化することができる。
次に、親システム220においては、各子システムに対して、「C02:カテゴリID・サブアドレス・リクエスト」なるパケットが送信される。これは、各子システムに対してカテゴリIDとサブアドレスとを返信するように求めるパケットである。このパケットにおいてもゼネラルコールを用いることができる。なお、親システム220においてはEバス216,217に接続している子システムが元々認識されているため、このパケットは、各子システムが正常に動作しているか否かの確認のために主として用いられる。
次に、各子システムにおいては、このC02:カテゴリID・サブアドレス・リクエストが受信されると、「C03:カテゴリID・サブアドレス・リプライ」なるパケットが親システム220に対して返信される。該パケットにおいて、送信先アドレスは親システム220のアドレスであり、送信元アドレスは当該パケットを送信する子システムのアドレスである。該パケットにおいて第1データは「00h」であり、第2データは該子システムのカテゴリID、第3データは該子システムのサブアドレスである。また、親システム220と子システムとの間でその他の情報、例えばエラー報告などを入出力する場合には、「C04:その他」のパケットが用いられる。該パケットにおいて第1データは「00h」〜「0Fh」の範囲であり、第2および第3データは入出力する情報に応じたパラメータである。
(3)標準プロトコル
(3.1)子システムから親システムへのデータ送信
次に、子システムから親システムに対するデータ送信用のパケットについて説明する。これらのパケットにおいては、送信先アドレスは必ず親システム220であり、送信元アドレスは当該パケットを送信する子システムのアドレスである。まず、子システム(またはその配下の孫システム)において、何れかのスイッチがオフ状態に設定されると、その旨がC11:SW OFFというパケットによって、該子システムから親システム220に通知される。該パケットにおいて、第1データは「6xh」(但し、xは「0h〜Fh」の範囲のポート番号、以下同)であり、第2データは「00h」〜「FFh」の範囲のスイッチ番号である。また、第3データはダミーデータ「00h」である。
同様に、何れかのスイッチがオン状態に設定されると、その旨がC12:SW ONというパケットによって、該子システムから親システム220に通知される。該パケットにおいて、第1データは「7xh」であり、第2データは「00h」〜「FFh」の範囲のスイッチ番号であり、第3データはダミーデータ「00h」である。このように、SW ON/OFFパケットにあっては、ポート番号の種類が最大「16」であって、各ポート毎に最大「256」のスイッチ番号を指定できるため、本実施例においては、各セクション毎に最大「16×256」のスイッチを設けることが可能である。
また、子システム(またはその配下の孫システム)において、何れかのJOGコントローラが操作されると、その旨がC13:JOGコントローラというパケットによって、該子システムから親システム220に通知される。なお、JOGコントローラとは、操作量の相対的な変化量によってパラメータを設定する操作子であり、本実施例のデジタルミキサにおいては、各種ロータリーエンコーダがこれに該当する。C13:JOGコントローラにおいて、第1データは「Cxh」であり、第2データは「00h」〜「FFh」の値によってJOGコントローラの種別を示す。そして、第3データはJOGコントローラの操作量の相対的な変化量を「8ビット」の分解能で示す。これにより、各子システム(またはその配下の孫システム)毎に最大「16×256」のJOGコントローラを設けることができる。
また、子システムにおいて、何れかのコンティニュアスコントローラが操作されると、その旨がC14:コンティニュアスコントローラというパケットによって、該子システムから親システム220に通知される。なお、コンティニュアスコントローラとは、操作量の絶対的な値によってパラメータを設定する操作子であり、その操作量は「16ビット」の分解能を有する。本実施例のデジタルミキサにおいては、電動フェーダがこれに該当する。また、上述したように、サブセクション103−Aにおいてはタッチスクリーン130はライトペンまたは指先による押下のオン/オフ情報と、押下位置とが検出される。このうち、押下のオン/オフ情報は、「スイッチのオン/オフ」であるとみなされる。また、押下位置のX座標およびY座標は各々個別のコンティニュアスコントローラの操作量であるとみなされる。
C14:コンティニュアスコントローラのパケットにおいて、第1データは「Exh」であり、第2データは操作量の上位「8ビット」、第3データは操作量の下位「8ビット」である。なお、本実施例においては、電動フェーダ等のコンティニュアスコントローラは子システムによって直接的に(孫システムを経由することなく)監視および制御される。コンティニュアスコントローラを識別する情報はポート番号のみであるから、本実施例において各子システムには最大「16」のコンティニュアスコントローラを設けることができる。
(3.2)親システムから子システムへのデータ送信
次に、親システムから子システムに対するデータ送信用のパケットについて説明する。これらのパケットにおいては、送信先アドレスは何れかの子システムであり、送信元アドレスは親システム220のアドレスである。まず、子システム(またはその配下の孫システム)に対して、LEDの点灯状態を指定する場合は、その旨がC21:LEDコントロールというパケットによって、親システム220から対応する子システムに通知される。該パケットにおいて、第1データは「6xh」であり、第2データは「00h」〜「FFh」の範囲のグループ番号である。ここで、「グループ」とは、輝度を同時に設定すべき一または複数のLEDの集合の意味である。また、第3データは当該グループに設定される輝度であり、「00h」〜「FFh」の範囲で指定される。ここで「00h」は消灯状態、「FFh」は最大輝度の点灯状態であり、両者の間の値によって中間輝度の点灯状態が表現される。
また、ある一のLEDをあるグループに含める旨を指定する場合には、その旨がC22:LEDグループ設定というパケットによって、親システム220から該子システムに通知される。該パケットにおいて、第1データは「7xh」であり、第2データは「00h」〜「FFh」の範囲のLED番号であり、第3データは「00h」〜「FFh」の範囲のグループ番号である。例えば、子システムがパケットC21:LEDコントロールを受信し、(該子システムまたはその配下の孫システムの)あるグループの輝度が設定されると、そのグループに含まれている全てのLEDは、設定された輝度で点灯ないし消灯する。また、子システムがパケットC22:LEDグループ設定を受信し、あるLEDをあるグループに含める設定が行われると、そのLEDはそのグループに設定されている輝度で点灯ないし消灯する。なお、グループ「00h」の輝度は「00h」(消灯)に固定であり、また、グループ「FFh」の起動は「FFh」(最大輝度)に固定であり、それぞれ変更することはできない。
また、親システム220で実行されたシーンリコール等により、子システム(またはその配下の孫システム)の、何れかのJOGコントローラに係るパラメータ値が変更され、当該パラメータに応じた表示を該子システム等において表示すべき場合には、そのパラメータ値がC23:JOGコントローラというパケットによって、親システム220から該子システムに通知される。本実施例においては、各種ロータリーエンコーダの周囲にはLEDが環状に配置されているから、これらロータリーエンコーダに対応するパラメータの設定値の概算値がこれらLEDの点灯状態によって表示される。C23:JOGコントローラにおいて、第1データは「Cxh」であり、第2データは「00h」〜「FFh」の値によってJOGコントローラの種別を示す。そして、第3データは該JOGコントローラに係るパラメータ値を「8ビット」の分解能で示す。
また、子システムに対して、何れかのコンティニュアスコントローラの操作量を設定すべき場合には、その旨がC24:コンティニュアスコントローラというパケットによって、親システム220から該子システムに通知される。上述したように、本実施例においては、電動フェーダと、タッチスクリーン130のX座標およびY座標とがコンティニュアスコントローラとして扱われるが、このうち親システム220から操作量が設定されるものは電動フェーダのみである。C24:コンティニュアスコントローラのパケットにおいて、第1データは「Exh」であり、第2データは設定すべき操作量の上位「8ビット」、第3データは該操作量の下位「8ビット」である。
2.2.Sバス・プロトコル
2.2.1.物理的構成
次に、子システムおよび配下の孫システム間を接続するSバス211〜214のプロトコルを説明する。まず、先に図3において述べたように子システム201−Aには二の孫システム201−B,201−Cが接続されているが、仮に孫システム201−Bのみが子システム201−Aに対して一対一に接続されていたと仮定した場合のバス構成を図8(a)に示す。図において子システム201−Aが出力する初期化信号/EXTICは、接続ライン211−1を介して、孫システム201−Bにリセット信号/RESETとして供給される。また、孫システム201−Bの出力データ信号TXDは、接続ライン211−2を介して、子システム201−Aに入力データ信号RXDとして供給される。逆に、子システム201−Aの出力データ信号TXDは、接続ライン211−3を介して、孫システム201−Bに入力データ信号RXDとして供給される。
また、接続ライン211−4を介して、子システム201−Aから孫システム201−Bに対してクロック信号CLKが出力される。また、接続ライン211−5,211−6の各々を介して、孫システム201−Bから子システム201−Aに対して、ビジー信号BUSYおよび送信要求信号TXREQが出力供給される。ここで、ビジー信号BUSYは、孫システム201−Bが内部処理等のために子システム201−Aからデータを受け取れる状態にない場合に“0”に設定され、データを受信可能な場合に“1”に設定される。また、送信要求信号TXREQは、孫システム201−Bから子システム201−Aに対して送信すべきデータが発生し、そのデータ送信の許可を子システム201−Aに求める場合に“0”に設定され、それ以外の場合に“1”に設定される。
次に、本実施例の実際の構成のように、子システム201−Aに複数の孫システムが接続される場合の接続状態を図8(b)に示す。なお、本実施例では子システム201−Aに「2台」の孫システムが接続されているが、ここでは説明の便宜上、3台の孫システム201−B,201−C,201−Dが接続される場合の接続状態を示す。一つの子システムに対しては最大「7台」の孫システムを接続することができ、各孫システムには各々にSバス上のユニークなアドレス「000b」〜「110b」が付与される。図8(b)においては、図8(a)に示した全ての接続ライン211−1〜211−6は、全ての孫システム201−B〜201−Dに対してパラレルに接続される。従って、子システム201−Aの出力する初期化信号/EXTIC、出力データ信号TXDおよびクロック信号CLKは、全ての孫システムに対してパラレルに供給されることになる。
また、このように複数の孫システムをパラレルに接続する場合には、孫システムの出力する出力データ信号TXD、ビジー信号BUSYおよび送信要求信号TXREQは、オープンドレイン出力でなければならず、対応する接続ラインをプルアップしておく必要がある。これにより、各孫システムの出力信号のワイヤードアンド結果が子システム201−Aによって受信されることになる。例えば、各孫システムはビジー状態にあるとき“0”のビジー信号を出力し、ビジー状態にないとき“1”のビジー信号を出力する。従って、子システムは、配下の何れかの孫システムがビジー状態のときに“0”のビジー信号BUSYを受信し、配下の全ての孫システムがビジー状態にないとき“1”のビジー信号BUSYを受信する。
2.2.2.パケット形式
次に、子システムおよび孫システム間においては、両者の出力データ信号TXDおよび入力データ信号RXDによってパケットが送受信されることにより、データが伝送される。ここで、伝送されるパケットの形式を図9(a)〜(f)を参照し説明する。何れのパケットも「1バイト」を単位として送受信されるが、図9(a)に示すように子システムから孫システムに送信されるパケットにはメッシュを付して表示し、孫システムから子システムに送信されるパケットは無地にて表示する。
まず、子システムから何れかの孫システムに対してデータを送信する場合には、図9(b)に示す形式の子システム送信パケット400が送受信される。パケット400の内部において401は先頭に設けられるステータスバイトであり、当該パケット400を受信すべき孫システムのアドレス、データの送信方向等がここで指定される。402〜404は第1〜第3データであり、その内容は図7に示したEバスプロトコルの第1〜第3データと同様である。
次に、子システムが何れかの孫システムからデータを受信する場合には、図9(c)に示す子システム受信パケット410が送受信される。パケット410の内部において411は、上記ステータスバイト401と同様のステータスバイトである。412〜414は第1〜第3データであり、その内容は図7に示したEバスプロトコルの第1〜第3データと同様であるが、これらデータはステータスバイト411において指定された孫システムによって送信される。
ところで、ある孫システムから子システムに対してデータ送信が必要になった場合、例えば孫システムが監視および制御する操作子に何らかの操作イベントが発生した場合には、その孫システムにおいては送信要求信号TXREQが“0”に設定される。しかし、子システムに受信される送信要求信号TXREQは配下の全ての孫システムが出力する送信要求信号TXREQのワイヤードアンド結果であるから、子システムは送信要求を発生した孫システムを直ちに特定することができない。そこで、送信要求を発生した孫システムを特定するために、図9(d)に示すアービトレーションパケット420が送受信される。パケット420の内部において421はステータスバイトであり、該パケット420がアービトレーションパケットであることを表示する。422はこれに対するリプライバイトであり、配下の全ての孫システムから送信される。従って、子システムによって受信されるリプライバイト422は、これらのワイヤードアンド結果である。
次に、図9(e)を参照し、ステータスバイト401,411,412の詳細を説明する。ステータスバイト401,411,412の上位「3ビット」はアドレス430を構成する。このアドレス430は、子システム送信パケット400または子システム受信パケット410においては、特定の一の孫システムのアドレス、すなわち「000b」〜「110b」の値である。また、アービトレーションパケット420においては、アドレス430は「111b」に設定される。これは、全ての孫システムに対して同時に通信するためのブロードキャストの意味である。次に、ステータスバイトの上位から第4ビットは通信方向フラグ432であり、ステータスバイトに続く第1〜第3データを子システムが出力する場合は“0”(Write)に設定され、第1〜第3データまたはリプライバイト422を孫システムが出力すべき場合は“1”(Read)に設定される。ステータスバイトの下位「4ビット」はエラーチェックコード434を構成する。これは、子システムが出力する全てのステータスバイト毎に「1」づつカウントアップしたカウント結果の下位「4ビット」の値である。なお、アービトレーションパケットの通信方向フラグ432を“1”(Read)とすれば、アドレス「111b」の逆方向“0”(Write)のパケットを別のコマンドとして用いることができる。
次に、図9(f)を参照し、アービトレーションパケット420内のリプライバイト422として、各孫システムが子システムに送信するデータの詳細を説明する。まず、孫システムが送信要求信号TXREQを出力していない場合には、該孫システムの出力するリプライバイトは「11111111b」である。また、孫システムが“0”の送信要求信号TXREQを出力している場合には、孫システムのアドレスに応じてリプライバイトの内容が異なる。すなわち、図9(f)に示すように、孫システムのアドレスに対応したユニークな特定位置のビットが“0”にされ、その他のビットが“1”に設定されるのである。子システムにおいては、これら孫システムが出力したリプライバイトのワイヤードアンド結果が受信されるため、受信したリプライバイト422の各ビットのうち“0”であるビットを検索すると、送信要求が発生した孫システムが特定できる。例えば、リプライバイト422が「11111010b」であったならば、アドレス「000b」および「010b」の2つの孫システムにおいて送信要求が発生したことがわかる。
2.2.3.パケット送信の具体例
(1)子システムから孫システムへのデータ送信
次に、図10を参照し、子システムから孫システムに対してデータ送信を行う場合の動作を、子システムに「3」台の孫システムを接続した場合を例として説明する。なお、図10〜図12において、DATA1〜3、BUSY1〜3、TXREQ1〜3は、図8(b)における「3」台の孫システム201−B,201−C,201−Dが各々出力するデータ信号、ビジー信号および送信要求信号である。まず、各孫システムにおいては必要に応じて様々な処理が行われているが、これらの処理が終了すると、時刻t1〜t3の期間に各孫システムのビジー信号BUSY1〜3が“1”に立ち上がる。そして、全てのビジー信号BUSY1〜3が立ち上がったタイミングである時刻t3において、子システムに受信されるビジー信号BUSYが“1”になるため、全ての孫システムにおいてステータスバイトの受信が可能になった旨が子システムにおいて認識される。
かかる状態において子システムが特定の孫システムに対してデータ送信すべき場合には、子システムからステータスバイト401の各ビットが順次送信される。また、クロック信号CLKは、各ビットが出力されるタイミングに同期して“0”に立ち下げられる。該ステータスバイトの受信が各孫システムにおいて開始されると、孫システムにおいては、ステータスバイトを受信するとともに該ステータスバイトに対応する処理を実行するために、時刻t5〜t7の期間にビジー信号BUSY1〜3が各々“0”に立ち下げられる。このうち少なくとも一の信号が“0”になると、子システムに受信されるビジー信号BUSYは“0”になる。これにより、子システムにおいては、該ビジー信号BUSYが再び“1”に立ち上がるまで、孫システムに対する送信が待機される。
ここで、各孫システムにおいては、ステータスバイト401内のアドレス430と、自機のアドレスとが比較され、両者の一致/不一致が判定される。図示の例にあっては、孫システム201−Cのみにおいて「一致」と判定され、他の孫システムにおいては「不一致」と判定されたとする。そして、孫システム201−Cにおいては、通信方向フラグ432に応じて、自機が第1〜第3データを出力するのか、子システムの出力する第1〜第3データを自機が受信するのかが判定される。また、各孫システムにおいては、エラーチェックコード434の結果が正当であるか否かも判定される。なお、かかる処理の詳細は後述する。
各孫システムにおいて以上のようなステータスバイト401に対する処理が終了すると、時刻t8〜t10の期間に、各ビジー信号BUSY1〜3が“1”に立ち上げられる。そして、最終的なビジー信号BUSYは、最後の時刻t9において“1”になる。子システムにおいては、ビジー信号BUSYが“1”になったことが確認されると、時刻t11から第1データ402の各ビットが順次出力される。各孫システムにおいては、この第1コマンド402を解釈するために、時刻t12〜t14の期間において、各ビジー信号BUSYが“0”に立ち下がる。トータルのビジー信号BUSYは、最先の時刻t12に“0”に立ち下がる。
ここで、孫システム201−Cの内部においては、この第1データ402は有効なデータとして、その内容に応じた処理が実行される。一方、他の孫システムにおいては、該第1データ402の内容は無視されることになる。そして、各孫システムにおいて、「無視する」との判断、または必要な処理の実行が終了すると、時刻t15〜t17の期間においてビジー信号BUSYが“1”に立ち上がる。以下、同様の処理が第2データ403および第3データ404についての実行され、以上の処理によって子システムから孫システム201−Cに対して、第1〜第3データが送信されたことになる。
(2)孫システムから子システムへのデータ送信
次に、図11,図12を参照し、孫システムから子システムに対してデータ送信を行う場合の動作を説明する。まず、孫システム201−B,201−Dが監視および制御するサブセクションにおいて、例えば何らかの操作子の操作イベントが発生する。そして、孫システム201−B,201−Dにおいて、これらイベントを子システムを介して親システムに送信すべく、送信要求信号TXREQ1,3が図11の時刻t44,t45において“0”に立ち下がったとする。トータルの送信要求信号TXREQは、このうち最先の時刻t44において“0”に立ち下がることになる。
送信要求信号TXREQが“0”になったことが検出されると、子システムにおいては、トータルのビジー信号BUSYが“1”であるか否かが確認され、仮にビジー信号BUSYが“0”であれば“1”になるまで処理が待機する。図示の例では時刻t44の時点でビジー信号BUSYは“1”であるから、その直後の時刻t46において、アービトレーションパケット420のステータスバイト421の出力が開始される。時刻t47〜t49においては、このステータスバイト421を受信および解釈するために、各孫システムのビジー信号BUSY1〜3が次々と“0”に立ち下げられる。
ここで、“0”の送信要求信号TXREQ1,3を出力中の孫システム201−B,201−Dにおいては、ステータスバイト421に対して、「自機が送信要求を出力した」旨を通知するリプライバイトを返信すべきである、と判定される。一方、孫システム201−Cにおいては送信要求が発生していないため、「自機は送信要求を出力していない」旨を通知するリプライバイトを返信すべきである、と判定される。以上のような判定が終了し、リプライバイトを返信する準備が完了すると、各孫システムにおいて、時刻t50〜t52の期間において、ビジー信号BUSY1〜3が各々“1”に立ち上げられる。子システムにおいてはトータルのビジー信号BUSYが“1”になったことが確認されると、時刻t53から、クロック信号CLKの出力が開始される。
各孫システムにおいては、このクロック信号CLKの立ち下がりが検出されると、自機が“0”の送信要求信号TXREQ1〜3を出力中であるか否かと、自機のアドレスとに基づいて、図9(f)に示されたリプライバイト422がの各ビットが順次出力される。このリプライバイト422の各ビットはビット毎にワイヤードアンドされ、その結果が子システムに受信されるから、受信したリプライバイト422のうち“0”であるビットに応じて、“0”の送信要求信号TXREQを出力した孫システムは201−B,201−Dである旨が子システムにおいて認識されることになる。そして、リプライバイトの出力が完了すると、各孫システムのビジー信号BUSY1〜3が時刻t57〜t59の期間において各々“1”に立ち上げられる。
次に図12において、トータルのビジー信号BUSYが“1”である旨が子システムにおいて確認されると、送信要求があった孫システムのうち、何れか一の孫システム(ここでは孫システム201−Bであったとする)に対する子システム受信パケット410のステータスバイト411の各ビットが子システムから順次出力される(時刻t60)。そして、各孫システムにおいては、ステータスバイトを受信するとともに対応する処理を実行するために、時刻t61〜t63の期間にビジー信号BUSY1〜3が各々“0”に立ち下げられる。
ここで、各孫システムにおいては、ステータスバイト401内のアドレス430と、自機のアドレスとが比較され、両者の一致/不一致が判定される。図示の例にあっては、孫システム201−Bにおいて「一致する」と判定され、他の孫システムにおいては「不一致」と判定されたとする。そして、孫システム201−Bにおいては、通信方向フラグ432に応じて、自機が第1〜第3データを出力するのか、子システムの出力する第1〜第3データを自機が受信するのかが判定される。ここでは、自機がデータを送信する“1”(Read)であったとする。各孫システムにおいて以上のようなステータスバイト411に対する処理が終了すると、時刻t64〜t66の期間に、各ビジー信号BUSY1〜3が“1”に立ち上げられる。そして、最終的なビジー信号BUSYは、最後の時刻t65において“1”になる。子システムにおいては、ビジー信号BUSYが“1”になったことが確認されると、時刻t67からクロック信号CLKの出力が開始される。
孫システム201−Bにおいて、このクロック信号CLKの立ち下がりが検出されると、先に送信要求したパケットの第1データ412の内容が該クロック信号CLKに同期して出力される。一方、アドレスが不一致であった他の孫システムにおいては、ダミーデータ(“1”信号)が出力される。これにより、これらのワイヤードアンド結果は、孫システム201−Bの出力した第1データ412の内容と同一になり、該第1データ412が子システムによって受信される。そして、第1データ412またはダミーデータの出力が完了すると、各孫システムのビジー信号BUSY1〜3が時刻t71〜t73の期間において各々“1”に立ち上げられる。以後同様に、子システムにおいて第2データ413および第3データ414に対するクロック信号CLKが順次生成されると、これに同期して孫システム201−Bから第2データ413および第3データ414が順次出力される。
以上により、孫システム201−Bから子システムに対するデータ転送が終了したため、孫システム201−Bの送信要求信号TXREQ1は時刻t88において“1”に立ち上げられる。但し、他の送信要求を行った孫システム201−Dについては未だデータ転送が実行されていないため、その送信要求信号TXREQ3は引き続き“0”に保たれている。これにより、時刻t60〜t88 の期間と同様の処理が、子システムと孫システム201−Dとの間で実行されることになる。
3.実施例の動作
3.1.子システム:親システムからのデータ受信
次に、Eバス216,217を介して子システムが親システムからパケットを受信した場合の動作を説明する。子システムにおいてEバス216,217を介して「5バイト」パケットが受信されると、子システムにおいては図13(a)に示すデータ受信ルーチンが起動される。図において処理がステップSP2に進むと、受信したパケットは共通プロトコルのパケットであるか否かが判定される。ここで「YES」と判定されると、処理はステップSP4に進み、配下の孫システムに対して当該共通プロトコルのパケットのデータ部380が送信される。次に、処理がステップSP6に進むと、受信した共通プロトコルのデータ部380に応じた処理が実行される。すなわち、「C01:Eバススタート」が受信されたのであれば、子システム内部において必要な初期化処理が実行される。また、「C02:カテゴリID・サブアドレス・リクエスト」が受信されたのであれば、「C03:カテゴリID・サブアドレス・リプライ」のパケットが親システム220に返信される。
一方、ステップSP2において「NO」と判定されると、処理はステップSP8に進む。本実施例において、かかる場合には、受信されたパケットは必ず標準プロトコルのパケットである。ステップSP8においては、データ部380内の第1データの内容が確認され、「(a)該パケットは「C24:コンティニュアスコントローラ」である」、「(b)第1データ内のポート番号xが『0h』である」、のうち何れかの条件が満たされているか否かが判定される。本実施例においては、子システムは孫システムを経由することなくコンティニュアスコントローラを直接的に監視および制御することにしている。これは、子システムが直接監視・制御している方が操作に対するレスポンスが良いためである。また、他の操作子等については、子システムが直接的に監視および制御するものに対しては、ポート番号xとして「0h」が割り当てられている。従って、ステップSP8は、受信したパケットが「孫システムを経由することなく子システムが直接的に処理すべきパケットであるか否か」を判定するステップである。なお、コンティニュアスコントローラについても、他の操作子と同様、ポート番号xで子システム、孫システムの振り分けをするようにしてもよい。
ステップSP8において「YES」と判定されると、処理はステップSP10に進み、受信した標準プロトコルのデータ部380に基づいて、これに応じた処理が実行される。例えば、受信したパケットが「C24:コンティニュアスコントローラ」であれば、ポート番号xに対応する電動フェーダの操作量が、第2データおよび第3データによって示される操作量になるまで、該電動フェーダが駆動される。一方、ステップSP8において「NO」と判定されると、処理はステップSP12に進む。子システムにおいては、コンティニュアスコントローラ以外の操作子については、ポート番号xに応じて孫システムに割り当てられている。このため、ステップSP12においては、該ポート番号xに対応する孫システムに対して、Sバスを介してデータ部380が送信される。
ところで、上記ステップSP4およびSP12においては、図15(a)に示す対孫送信サブルーチンが呼び出されることにより、実際の転送処理が実行される。以下、同サブルーチンの内容を説明する。図15(a)において処理がステップSP62に進むと、孫システムに転送すべき第1〜第3データが準備され、所定のレジスタに格納される。次に、処理がステップSP64に進むと、子システム送信パケット400用のステータスバイト401が作成される。該ステータスバイト401において、アドレス430は第1〜第3データを送信すべき孫システムのアドレスであり、通信方向フラグ432は“0”(Write)に設定される。また、エラーチェックコード434は、過去に送信した最後のステータスバイトに用いたエラーチェックコードを「1」だけカウントアップした値に設定される。次に、処理がステップSP66に進むと、作成したステータスバイト401が各孫システムに対して送信され、ステップSP68においては第1〜第3データが順次出力される。
このように、ステップSP4およびSP12(および対孫送信サブルーチン(図15(a)))においては、親システム220から受信したデータ部380(第1〜第3データ)がそのままの形で孫システムに転送される。すなわち、本実施例によれば、予め子システムにおいてデータ変換を行うような処理は全く不要になり、子システムの負荷をきわめて軽減することができるのである。
3.2.孫システム:子システムからのデータ受信
上記対孫送信サブルーチン(図15(a))のステップSP66においては子システムによってステータスバイトが孫システムに送信されたが、該ステータスバイトの受信が完了すると、各孫システムにおいて図16に示すステータスバイト受信イベントルーチンが起動される。図において処理がステップSP104に進むと、エラーチェックコード434が正常であるか否かが確認される。すなわち、今回受信したエラーチェックコード434は、当該Sバスにおいて過去に送信された最後のステータスバイトに用いたエラーチェックコードを「1」だけカウントアップした値に等しいか否かが確認される。ここで「NO」と判定されると、処理はステップSP106に進み、所定のエラー処理が実行された後に本ルーチンの処理が終了する。
一方、エラーチェックコード434が正常であれば、処理はステップSP107に進み、該ステータスバイトはアービトレーションパケットのステータスバイト421であるか否かが判定される。ここで「NO」と判定されると、処理はステップSP108に進み、ステータスバイト内のアドレス430によって自機が指定されたか否かが判定される。ここで「YES」と判定されると、処理はステップSP116に進み、通信方向フラグ432“1”(Read)であるか否かが判定される。ここで「NO」(“0”:Write)と判定されると、処理はステップSP118に進み、第1〜第3データが順次受信される。
なお、ステップSP118の実行時間には所定の「最大時間」が設定されている。この最大時間中に第1〜第3データが全て受信されなかった場合には、その時点で「タイムアウト」としてステップSP118の処理が中断される。次に、処理がステップSP120に進むと、第1〜第3データの内容が正常であるか否かが判定される。なお、上記タイムアウトが発生した場合には、第1〜第3データは常に異常であると判定されることになる。ここで「NO」と判定されると、処理はステップSP122に進み、所定のエラー処理が実行された後に本ルーチンの処理が終了する。一方、ステップSP20において「YES」と判定されると、本ルーチンが正常終了する。
このように、第1〜第3データに係るパケットが正常に受信された後にステータスバイト受信イベントルーチン(図16)が終了すると、当該孫システムにおいては、図13(b)に示すデータ受信ルーチンが引き続いて起動される。図13(b)において処理がステップSP22に進むと、受信したパケットは共通プロトコルのパケットであるか否かが判定される。ここで「YES」と判定されると、処理はステップSP24に進み、受信した共通プロトコルのデータ部380に応じた処理が実行される。例えば、「C01:Eバススタート」が受信されたのであれば、孫システム内部において必要な初期化処理が実行される。なお、「C02:カテゴリID・サブアドレス・リクエスト」などについては、子システムが独自に親システムに対して応答すべきものであるから、孫システムにおいては無視される。
ところで、先に述べたステップSP4(図13(a))においては、子システムによって受信された共通プロトコルのパケットは、その内容にかかわらず孫システムにも転送される。従って、上述したように、孫システムにとって不要なパケットも子システムから転送されることになり、受信した共通プロトコルのパケットを無視するか否かは孫システムにおいて独自に判断されることになる。これにより、親システムと孫システムとの間で送受信される共通プロトコルのパケットを新たに定めたとしても、子システムは単にこれを転送を実行すればよいため、追加された共通プロトコルに関して全く関知する必要がなくなり、設計変更等の作業を簡略化することができる。
一方、ステップSP22において「NO」と判定されると、処理はステップSP26に進む。本実施例において、かかる場合には、受信されたパケットは必ず標準プロトコルのパケットである。ステップSP26においては、受信した標準プロトコルのデータ部380に基づいて、これに応じた処理が実行される。例えば、受信したパケットが「C23:JOGコントローラ」であれば、第1データ内のポート番号xおよび第2データ内の「種別」に対応する一のロータリーエンコーダの周辺LEDの点灯/消灯状態が、第3データによって示された操作量に対応する状態に変更される。
3.3.孫システム:データ送信要求の発生
次に、孫システムにおいて親システムに対して送信すべきデータが発生した場合は、図14(a)に示すデータ発生イベントルーチンが起動される。孫システムが親システムに対して送信すべきデータには、標準プロトコルのパケットによって送信すべきデータと、共通プロトコルのパケットによって送信すべきデータとがある。例えば、該孫システムによって監視および制御されているスイッチ、ロータリーエンコーダ等の操作子が操作されると、その旨は標準プロトコルのパケットによって親システムに通知しなければならない。また、孫システムが当該孫システム自体の異常、または子システムの異常を検出した場合には、その旨を共通プロトコル(C04:その他)によって親システム220に報告しなければならない。
そこで、該データ発生イベントルーチンにおいては、最初のステップSP30において、送信すべきデータは共通プロトコルによって送信すべきものであるか否かが判定される。ここで「YES」と判定されると、処理はステップSP32に進み、エラー内容等を報告するデータが共通プロトコル(C04:その他)のパケットにおける第1〜第3データの形式で作成される。一方、ステップSP30において「NO」と判定されると、操作子等のイベント内容に基づいて、標準プロトコルのパケットの第1〜第3データが作成される。何れの場合も、次に処理がステップSP36に進むと、生成されたパケットを子システムに送信するために、“0”の送信要求信号TXREQが出力され、本ルーチンの処理は終了する。
その後、当該送信要求信号TXREQに応じて、子システムによってアービトレーションパケット420のステータスバイト421が送信される。これに対して、各孫システムにおいては、上述したステータスバイト受信イベントルーチン(図16)が再び起動される。そして、処理がステップSP107に進むと、ここで「YES」と判定され、処理はステップSP109に進む。従って、各孫システムにおいては、自機が送信要求を行っているか否かと、自機のアドレスとに基づいてリプライバイト422が生成され、子システムが生成するクロック信号CLKに同期して該リプライバイト422の内容がSバス上に送信される。
次に、送信要求を行った一または複数の孫システムの中から一の孫システムを指定するステータスバイト411を子システムが送信すると、各孫システムにおいては、該ステータスバイト受信イベントルーチン(図16)が再び起動される。このステータスバイト411内のアドレス430によって受信先として指定された孫システムにおいては、ステップSP104,SP108,SP116を介して処理はステップSP124に進む。ここでは、先のデータ発生イベントルーチン(図14(a))によって準備された第1〜第3データが、送信用のレジスタに格納される。次に、処理がステップSP126に進むと、子システムが発生するクロック信号CLKに同期して、これら第1〜第3データが子システムに対して順次送信される。そして、ステップSP126においては、今回の送信によって子システムに現時点で送信すべきデータが全て送信されたのであれば、該孫システムが送信する送信要求信号TXREQが“1”に設定される。一方、子システムに送信すべきデータが未だ残存している場合には、送信要求信号TXREQは“0”のまま保たれる。
3.4.子システム:親システムへのデータ送信
次に、子システムにおいて親システムに対して送信すべきデータが発生した場合は、図14(b)に示すデータ発生イベントルーチンが起動される。ここで、孫システムの場合と同様に、子システムが親システムに対して送信すべきデータには、標準プロトコルのパケットによって送信すべきデータと、共通プロトコルのパケットによって送信すべきデータとがある。例えば、該子システムによって監視および制御されている電動フェーダが操作されると、その旨は標準プロトコルのパケットによって親システムに通知しなければならない。また、子システムが配下の孫システムの異常を検出した場合、あるいは子システムが該子システム自体の異常を検出した場合には、その旨を共通プロトコル(C04:その他)によって親システム220に報告しなければならない。
そこで、該データ発生イベントルーチンにおいても、最初のステップSP40において、送信すべきデータは共通プロトコルによって送信すべきものであるか否かが判定される。ここで「YES」と判定されると、処理はステップSP42に進み、エラー内容等を報告するデータが共通プロトコル(C04:その他)のパケットにおける第1〜第3データの形式で作成される。一方、ステップSP30において「NO」と判定されると、操作子等のイベント内容に基づいて、標準プロトコルのパケットの第1〜第3データが作成される。何れの場合も、次に処理がステップSP46に進むと、生成された第1〜第3データがEバス上のパケットに変換され親システム220に送信される。
3.5.子システム:孫システムからの送信要求に対する処理
次に、子システムにおいて受信している送信要求信号TXREQが“0”になると、CPU252に対して送信要求割込みが発生し、図15(b)に示す送信要求割込みルーチンが起動される。図において処理がステップSP72に進むと、アービトレーションパケット420のステータスバイト421がSバスを介して配下の孫システムに送信され、これに対して各孫システムが送信したリプライバイトのワイヤードアンド結果であるリプライバイト422が子システムにおいて受信される。
上述したように、このリプライバイト422においては複数の孫システムが“0”を返信することがあるため、次のステップSP74においては、これら送信要求を行った孫システムのうち、子システムに対してデータを送信すべき孫システムが決定される。次に、処理がステップSP76に進むと、子システム受信パケット410のステータスバイト411が生成される。このステータスバイト411において指定されるアドレス430は先にステップSP74において決定された孫システムのアドレスである。また、通信方向フラグ432は“1”(Read)であり、エラーチェックコード434は、過去に送信したエラーチェックコードを「1」だけカウントアップした値に設定される。
次に、処理がステップSP78に進むと、該ステータスバイト411がSバスを介して送信される。次に、処理がステップSP80に進むと、孫システムから送信された第1〜第3データが順次受信される。なお、ステップSP80の実行時間には所定の「最大時間」が設定されている。この最大時間中に第1〜第3データが全て受信されなかった場合には、その時点で「タイムアウト」としてステップSP80の処理が中断される。次に、処理がステップSP82に進むと、第1〜第3データの内容が正常であるか否かが判定される。なお、上記タイムアウトが発生した場合には、第1〜第3データは常に異常であると判定されることになる。
ここで「YES」と判定されると、処理は正常終了する。一方、「NO」と判定されると、処理はステップSP84に進み、所定のエラー処理が実行された後に本ルーチンの処理は異常終了する。そして、送信要求割込みルーチン(図15(b))が正常終了した場合には、図14(c)に示すデータ受信イベントルーチンが起動される。図において処理がステップSP50に進むと、先に受信した第1〜第3データがEバス上のパケットとして親システム220に送信される。
3.6.孫システム:子システムおよび他の孫システムの監視
上述したように、子システムが出力するステータスバイトは、アービトレーションパケット420のものを除けば、特定の一の孫システムを通信相手として指定するものである。従って、通信相手として指定されなかった他の孫システムにおいては、該ステータスバイトに係るパケットを無視しても差し支えない。しかし、本実施例においては、各孫システムは自機が通信相手として指定されなかった場合には、子システムを監視することにより、装置全体としての信頼性を向上させている。ここで、再びステータスバイト受信イベントルーチン(図16)を参照しその詳細を説明する。
まず、上述したように、ステータスバイトが受信されると、ステップSP104においてエラーチェックコード434が正しいか否かがチェックされるが、かかる処理は自機が通信相手として指定されたか否かにかかわらず実行される。次に、通信相手として指定されなかった孫システムにおいては、ステップSP108において「NO」と判定され、処理はステップSP110に進む。ここでは、Sバス上に送出される第1〜第3データが順次受信される。このステップSP110においても、上述したSP118と同様に、最大時間中に第1〜第3データが全て受信されなかった場合には、その時点で「タイムアウト」が発生したと判断されステップSP110の処理が中断される。そして、処理がステップSP112に進むと、該第1〜第3データがが正常であるか否かが確認される。ここで「YES」と判定されると、本ルーチンの処理が正常終了する。一方、タイムアウトが発生した場合など異常である場合は「NO」と判定され、処理はステップSP114に進み、所定のエラー処理が実行された後に処理が異常終了する。
3.7.エラー処理の詳細
ところで、対孫送信サブルーチン(図15(a))のステップSP84、ステータスバイト受信イベントルーチン(図16)のステップSP106,SP114,SP122においては所定のエラー処理が実行される旨を述べたが、ここでエラー処理とは、発生したエラーの詳細を報告するように、共通プロトコルの「C04:その他」に属する第1〜第3データを作成し、これを親システム220に送信する処理である。ここで、子システムが孫システムの異常を検出した場合にその旨を親システムに報告する場合には通信経路上の障害は無いが、孫システムが子システムの異常を検出した場合には問題がある。すなわち、孫システムと親システム220の間には、エラーの詳細を直接的に報告する通信経路が設けられておらず、孫システムは障害を有する子システムを介して親システムにエラーの詳細を報告する共通プロトコルのパケットを送信しなければならないのである。
ここで、子システムに生じている障害の状況次第では、子システムは該パケットを仲介できない可能性もある。しかし、子システムにおいてなんらかの障害が存在したとしても、少なくとも孫システムから親システム220宛に送信されたパケットを仲介する機能が動作していれば、当該パケットを親システムに到達させることができる。これにより、装置に障害が発生した場合に、親システム220においては詳細な障害内容を迅速に把握することができる。さらに、例えば親システムがある子システムの暴走状態を把握することができた場合に、親システムが当該子システムに対してのみ「C01:Eバススタート」を出力して該子システムをリセットしてもよい。これにより、子システムが再び正常に動作する可能性もある。
4.実施例の効果
以上のように、本実施例においては、以下のような効果がある。
(1)孫システムがデータ部380の内容を生成し子システムがヘッダ部370を生成したEバス上のパケットは、子システムが全体を生成したパケットと全く同一の形式で親システム220に送信される。従って、親システム220においては、ある子システムからパケットを受信したとき、そのパケットは子システムが全体を生成したパケットであるのか、孫システムがデータ部380を生成し子システムが仲介したパケットであるのかを区別する必要がない。従って、本実施例によれば、親システム220が直接的に管理すべきEバス上のデバイスをきわめて少なくすることが可能になる。さらに、孫システムのCPU272にはI2C機能を有しない安価なCPUを使用することができるから、制御システム全体のコストダウンを図ることができる。
(2)また、本実施例において子システムと孫システムとの間でパケットの送受信が実行される場合は、必ず子システムが出力するステータスバイト401,411,412によってパケットが開始される。このステータスバイトによれば、これに引き続いて第1〜第3データまたはリプライバイト422を出力するデバイス(子システムまたは孫システム)が一意に特定される。従って、例えば複数のデバイスが同時にデータ送信を開始してSバス上でデータが衝突するような事態が未然に防止される。換言すれば、かかるデータの衝突を考慮することなく子システムのシリアルI/O部246および孫システムのシリアルI/O部266を構成することができ、これらの要素にかかる費用については一層のコストダウンが可能である。
(3)さらに、各孫システムはその上位の子システムとのみ通信するために、孫システムが出力するデータ中に通信の相手先を特定する情報は全く不要である。さらに、Sバスにデータを出力する孫システムは予めステータスバイトにて指定された孫システムに限られるから、孫システムは自機のアドレスすら送信する必要がない。これにより、孫システムのシリアルI/O部266においては、データに送受信アドレスを付加するような動作は全く不要になり、シリアルI/O部266等の一層のコストダウンを実現することができる。
(4)また、本実施例においては、ステータスバイトにおいて通信相手として指定されなかった孫システムにおいても、エラーチェックコード434が正しいか否か判定(SP104〜SP106)されるとともに、Sバス上に現れた第1〜第3データが正常に出力されたか否かも判定される(SP108〜SP114)。これにより、データ通信に直接的に関与していない孫システムも「チェック装置」としての機能を発揮することができるから、孫システムが有するリソースを有効に利用してデジタルミキサ全体の信頼性を高めることができる。また、ステータスバイトにおいて自機が通信相手として指定されなかった孫システムにおいてエラーチェックコード434の推移が把握しておくことにより、次に自機を通信相手として指定したステータスバイトを受信したとき、その中に含まれるエラーチェックコード434が正当なものであるか否かを迅速かつ容易に判定することができる。
(5)さらに、本実施例においては、孫システムにおいてデータ送信の必要性が発生した場合には、パケットが送受信されるデータ線とは別ラインの信号線にて送信要求信号TXREQが子システムに送信される。従って、これらパケットの通信を全く妨げることなく孫システムから子システムに対して、データ送信の必要性を通知することができる。かかる構成は、例えば子システムからポーリングされるのを待って孫システムから子システムにデータ送信の必要性を報告する構成と比較すると、操作子等のイベントが生じたときに、その内容をより迅速に親システムに報告できる点できわめて有利である。
5.変形例
本発明は上述した実施例に限定されるものではなく、例えば以下のように種々の変形が可能である。
(1)上記実施例においては、各孫システム201−B〜201−Dの送信要求信号TXREQ1〜3は接続ライン211−6に供給され、これら送信要求信号TXREQ1〜3のワイヤードアンド結果が送信要求信号TXREQとして子システム201−Aに供給された(図8(a))。しかし、図17に示すように、これら送信要求信号TXREQ1〜3を独立した接続ライン211−11〜13によって子システム201−Aに供給してもよい。かかる構成によれば、子システム201−Aは、接続ライン211−11〜13のうち何れが“0”になったかに基づいて送信要求を行った孫システムを直ちに特定することができる。従って、孫システムから子システムに対してパケットを送信する場合に、アービトレーションパケットの送受信は全く不要になる。
従って、本変形例を採用する場合には、図11に示した信号処理を省略し、図12に示した信号処理を直ちに実行することができる。このように、子システムが各孫システムの送信要求信号TXREQ1〜3をそのまま受信するか、これらのワイヤードアンド結果を受信するかは、子システムに求められる動作速度や許容できる回路規模等に応じて決定するとよい。なお、子システムが何れの方式によって送信要求信号TXREQを受信する場合であっても、孫システム自体の構成は一切変更する必要がない。
(2)また、上記実施例は、EバスおよびSバスシステムをデジタルミキサ内の各デバイス間の通信に用いた例を説明したが、本発明はデジタルミキサ内の通信に限られるものではなく、例えば大型の電子楽器等、複数のCPU等によって装置を制御する各種機器に適用することができる。また、上記実施例においては、EバスおよびSバスを組み合わせてデジタルミキサ内の通信経路を形成したが、より小規模な装置においては、Sバスのみを用いて制御システムを構成してもよいことは言うまでも無い。なお、Sバスのみを用いた制御システムは、制御の全体を統括する「マスタデバイス(実施例における子システム)」と、マスタデバイスの管理の下、制御の一部を分担する「スレーブデバイス(同、孫システム)」との組み合わせによって構成されることになる。
(3) また、上記実施例において、エラーチェックコード434はステータスバイトが出力される毎に「1」づつカウントアップされたが、エラーチェックコードはこれに限定されるものではなく、ステータスバイトが出力される毎に所定の規則で変動する値であって、その規則通りにエラーチェックコードが変動したか否かを各孫システムによって検証できるものであればどのようなものでもよい。
(4)また、上記実施例においては、各システムのCPU228,252,272上で動作するプログラムによって各種処理を実行したが、このプログラムのみをCD−ROM、フレキシブルディスク等の記録媒体に格納して頒布し、あるいは伝送路を通じて頒布することもできる。
本発明の一実施例のデジタルミキサの操作パネル100パネルの平面図である。 操作パネル100内のセクション101,103の平面図である。 一実施例のデジタルミキサの制御システムの全体ブロック図である。 子システムおよび孫システムのブロック図である。 Eバスシステムの要部の回路図である。 Eバスシステムのタイミングチャートである。 Eバスシステムのパケット構成を示す図である。 Sバスシステムの構成例を示すブロック図である。 Sバスシステムのパケット構成を示す図である。 Sバスシステムのタイミングチャートである。 Sバスシステムのタイミングチャートである。 Sバスシステムのタイミングチャートである。 子システムおよび孫システムのデータ受信ルーチンのフローチャートである。 子システムおよび孫システムのデータ発生イベントルーチン、データ受信イベントルーチンのフローチャートである。 子システムの対孫送信サブルーチンおよび送信要求割込みルーチンのフローチャートである。 孫システムのステータスバイト受信イベントルーチンのフローチャートである。 Sバスシステムの構成例の変形例のブロック図である
符号の説明
100:操作パネル、101〜104:セクション、101−A〜101−C,102−A〜102−C,103−A〜103−C,104−A〜104−C:サブセクション、112−1〜n:オン/オフスイッチ、114−1〜n:センドモードスイッチ、116−1〜n:ロータリーエンコーダ、118−1〜n:LED表示器群、120−1〜n:セレクトスイッチ、122−1〜n:オン/オフスイッチ、124−1〜n:電動フェーダ、126−1〜n:CUEスイッチ、130:タッチスクリーン、132−1〜132−6,136−1〜136−14,138−1〜138−15:スイッチ、134−1〜134−15:ロータリーエンコーダ、201−A〜204−A:子システム、201−B,201−C,201−D,202−B,202−C,203−B,203−C,204−B,204−C:孫システム、211〜214:Sバス、211−1〜211−6:接続ライン、211−11〜13:接続ライン、216,217:Eバス、216b:SDAライン、216a:SCLライン、220:親システム、222:EバスI/O部、224:CPUバス、226:その他I/O部、228:CPU、230:フラッシュメモリ、232:RAM、234:信号処理部、236:波形I/O部、238:ディスプレイ、242:表示器群、244:操作子群、246:シリアルI/O部、248:EバスI/O部、252:CPU、254:フラッシュメモリ、256:RAM、262:表示器群、264:操作子群、266:シリアルI/O部、272:CPU、274:フラッシュメモリ、276:RAM、351〜356:バッファ、361〜366:トランジスタ、370:ヘッダ部、371,372:抵抗器、380:データ部、400:子システム送信パケット、401,411,412:ステータスバイト、410:子システム受信パケット、420:アービトレーションパケット、421:ステータスバイト、422:リプライバイト、430:アドレス、432:通信方向フラグ、434:エラーチェックコード。

Claims (3)

  1. マスタデバイスと、該マスタデバイスに対してシリアルデータを送受信する複数のスレーブデバイスとから成る通信システムにおいて、
    前記マスタデバイスのデータ出力端と、前記複数のスレーブデバイスの各データ入力端とをパラレルに接続する第1の接続ラインと、
    前記第1の接続ラインとは別体に設けられ前記マスタデバイスのデータ入力端と、前記複数のスレーブデバイスの各データ出力端とをパラレルに接続する第2の接続ラインと、
    前記マスタデバイスのビジー信号入力端と、前記複数のスレーブデバイスの各ビジー信号出力端とを接続し、接続された全てのスレーブデバイスが非ビジー状態にあるときのみ前記マスタデバイスにて非ビジー値を示すビジー信号が受信されるビジー信号ラインと、
    前記マスタデバイスに設けられ、一のスレーブデバイスを特定するアドレス情報と、前記マスタデバイスがデータを受信するか送信するかを指定する通信方向フラグとを含むステータス情報を、前記マスタデバイスにて受信されるビジー信号が非ビジー値を示すことを条件として、前記第1の接続ラインを介して出力開始するステータス情報送信手段と、
    前記各スレーブデバイスに設けられ、前記第1の接続ラインを介して出力されたステータス情報を受信するステータス情報受信手段と、
    前記マスタデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを送信する旨を指定する通信方向フラグが送信された場合に、前記ステータス情報に続いて前記第1の接続ラインを介して前記一のスレーブデバイス宛のデータを、前記マスタデバイスにて受信されるビジー信号が非ビジー値を示すことを条件に送信開始するマスタ・データ送信手段と、
    前記各スレーブデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを送信する旨を指定する通信方向フラグが送信された場合に、前記ステータス情報に続いて前記第1の接続ラインを介して送信される前記一のスレーブデバイス宛のデータを受信するスレーブ・データ受信手段と、
    前記各スレーブデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを受信する旨を指定する通信方向フラグが送信され、かつ、前記アドレス情報によって自機が指定されると、前記ステータス情報に続いて前記第2の接続ラインを介して前記マスタデバイス宛のデータを送信するスレーブ・データ送信手段と
    前記マスタデバイスに設けられ、前記ステータス情報送信手段によって前記マスタデバイスがデータを受信する旨を指定する通信方向フラグが送信された場合に、前記ステータス情報に続いて前記第2の接続ラインを介して前記マスタデバイス宛に送信されたデータを受信するマスタ・データ受信手段と、
    前記各スレーブデバイスに設けられ、少なくとも、前記ステータス情報受信手段における前記ステータス情報の受信中、前記スレーブ・データ受信手段における前記データの受信中、および、前記スレーブ・データ送信手段における前記データの送信中であるか否かに応じて、前記ビジー信号ラインに当該スレーブデバイスがビジー状態にあるか否かを示すビジー信号を出力するビジー信号出力手段と
    を有することを特徴とする通信システム。
  2. 前記ステータス情報送信手段が出力するステータス情報は、該ステータス情報が出力される毎に所定の規則で変動するエラーチェックコードを含むものであり、
    前記各スレーブデバイスに設けられ、前記アドレス情報によって自機が指定されたか否かにかかわらず、前記エラーチェックコードが正当か否かを検証するエラーチェックコード検証手段
    をさらに有することを特徴とする請求項1記載の通信システム。
  3. 前記各スレーブデバイスから前記マスタデバイスに対して送信要求信号を伝送する第3の接続ラインと、
    前記各スレーブデバイスに設けられ、前記マスタデバイスにデータ送信を行なう必要が生じた際に前記第3の接続ラインを介して前記送信要求信号を出力する送信要求手段と、
    前記マスタデバイスに設けられ、前記ステータス情報に含めるべきアドレス情報に係るスレーブデバイスとして、前記送信要求信号を出力した一または複数のスレーブデバイスの中から一のスレーブデバイスを決定するスレーブデバイス決定手段と
    をさらに有することを特徴とする請求項1または2記載の通信システム。
JP2005085786A 2005-03-24 2005-03-24 通信システム Expired - Fee Related JP4419082B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2005085786A JP4419082B2 (ja) 2005-03-24 2005-03-24 通信システム
US11/377,126 US20060218321A1 (en) 2005-03-24 2006-03-15 Control system and communication system for digital mixer
US12/487,606 US7979609B2 (en) 2005-03-24 2009-06-18 Control system and communication system for digital mixer

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005085786A JP4419082B2 (ja) 2005-03-24 2005-03-24 通信システム

Publications (2)

Publication Number Publication Date
JP2006267569A JP2006267569A (ja) 2006-10-05
JP4419082B2 true JP4419082B2 (ja) 2010-02-24

Family

ID=37203624

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005085786A Expired - Fee Related JP4419082B2 (ja) 2005-03-24 2005-03-24 通信システム

Country Status (1)

Country Link
JP (1) JP4419082B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020036130A (ja) * 2018-08-28 2020-03-05 帝人株式会社 通信システム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2020036130A (ja) * 2018-08-28 2020-03-05 帝人株式会社 通信システム
WO2020044583A1 (ja) * 2018-08-28 2020-03-05 帝人株式会社 通信システム

Also Published As

Publication number Publication date
JP2006267569A (ja) 2006-10-05

Similar Documents

Publication Publication Date Title
US7979609B2 (en) Control system and communication system for digital mixer
US7774511B2 (en) Addressing multiple devices on a shared bus
CA2894567C (en) Systems and methods for exchanging usb information with selected remote devices
JP5814474B2 (ja) 通信システムを駆動する方法
US20090144471A1 (en) Serial bus device with address assignment by master device
JP2017500631A (ja) 複数のスレーブデバイス識別子を有するカメラ制御スレーブデバイス
JP4193806B2 (ja) 制御システム
KR20050004062A (ko) 버스 연결을 통한 랜덤 액세스를 위한 방법 및 데이터 구조
US20230053564A1 (en) Processing system, related integrated circuit, device and method
JP4419082B2 (ja) 通信システム
EP4138343B1 (en) Processing system, related integrated circuit, device and method
WO2011114383A1 (ja) 情報処理装置及び情報処理装置のデバイス情報収集処理方法
US7391788B2 (en) Method and system for a three conductor transceiver bus
TWI285321B (en) Method and apparatus for acknowledging data transfer, intercommunication enabling system, and article of manufacture comprising a machine-accessible medium having content to provide instructions
EP1966942B1 (en) Flow control mechanisms on synchronous serial tdma bus
US20050152388A1 (en) Communication network system, and ID allocating method and ID setting method for communication network system
US11947478B2 (en) Methods for identifying target slave address for serial communication interface
JP5109597B2 (ja) データ転送装置及び半導体試験装置
US20090282177A1 (en) Apparatus and method for signal transmission in embedded system
EP1018819A2 (en) Data transmission control apparatus and data transmission method
KR101469078B1 (ko) 하나의 유에스비 단자를 이용한 복수의 내장 보드의 펌웨어 업그레이드 방법 및 시스템
CN117539806B (zh) 多点通信系统
US20050157328A1 (en) Apparatus for transmitting print data using multiple virtual connections and a method thereof
CN1288332A (zh) 电子设备
US8307145B2 (en) Method and system for connecting multiple IDE devices to a USB apparatus using a single USB-to-IDE adapter

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090522

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090717

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20091105

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20091118

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

Free format text: PAYMENT UNTIL: 20121211

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20131211

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees