(57)【要約】【課題】  複数のマスターデバイスが一つの共通バスを共有する場合、これらのマスターデバイスからの共通バス使用要求が競合すると、どのマスターデバイスにバス使用権を与えるか調停を行う必要がある。【解決手段】  マスターデバイス１Ａと、マスターデバイス２Ａ、及び、それぞれのマスターデバイスが自身のバス使用権獲得か否かの判定に用いるIDを生成するID生成器１０において、バス使用終了時には、他のマスターデバイスへバス使用権を遷移させるために、BusReq７の立ち上がり状態を生成し、ID１１を変化させることで、ID１１と同じＩＤを有する他のマスターデバイスがバス使用権を得る。【選択図】  図１
2011060157.tif 000002
【特許請求の範囲】
【請求項１】
各々シリアル通信を行う複数のマスターデバイスと、
前記複数のマスターデバイスと接続されるバス調停回路と、
前記複数のマスターデバイスそれぞれが出力するバス使用権リクエスト信号をワイヤード・オアにするための複数のドライバと、で構成され、
前記複数のドライバそれぞれでワイヤード・オアされた前記バス使用権リクエスト信号が、前記バス調停回路と前記複数のマスターデバイスに入力され、
前記バス調停回路は、前記入力されるバス使用権リクエスト信号に基づいて調停信号を生成し、
前記バス調停回路が生成する調停信号が前記複数のマスターデバイスに入力されることを特徴とするバス調停装置。
【請求項２】
請求項１に記載されたバス調停装置において、
前記マスターデバイスは入力された前記バス使用権リクエスト信号を観測し、
前記バス使用権リクエスト信号がネゲート状態であれば、前記マスターデバイスはバス使用権リクエスト信号をアサートし、
前記マスターデバイスは入力された調停信号を観測し、
前記調停信号が前記マスターデバイスの識別番号と同一の場合にバスを使用し、
前記マスターデバイスが前記バスを使用後、前記バス使用権リクエスト信号をネゲート状態にすることを特徴とするバス調停装置。
【請求項３】
請求項２に記載されたバス調停装置において、
前記バス調停回路は、バス使用権リクエスト信号がアサート状態からネゲート状態に変化する場合に前記調停信号を変化させることを特徴とするバス調停装置。
【請求項４】
請求項１に記載されたバス調停装置において、
前記マスターデバイスは入力されたバス使用権リクエスト信号を観測し、
前記バス使用権リクエスト信号がネゲート状態であれば、前記マスターデバイスは前記バス使用権リクエスト信号をアサートし、
前記マスターデバイスは入力された調停信号を観測し、
前記調停信号が前記マスターデバイスの識別番号と同一の場合、バスを使用し、
前記調停信号が前記マスターデバイスの識別番号と異なっている場合、前記識別番号と同じになるまで、前記バス使用権リクエスト信号をネゲート状態からアサート状態に変化させ、前記識別番号と同じになればバスを使用し、
前記マスターデバイスが前記バスを使用後、前記バス使用権リクエスト信号をネゲート状態にすることを特徴とするバス調停装置。
【請求項５】
各々シリアル通信を行う複数のマスターデバイスと、
前記複数のマスターデバイスと接続されるバス調停回路と、
前記複数のマスターデバイスそれぞれが出力するバス使用権リクエスト信号をワイヤード・オアにするための複数のドライバと、で構成され、
前記複数のドライバそれぞれでワイヤード・オアされた前記バス使用権リクエスト信号が、前記バス調停回路と前記複数のマスターデバイスに入力され、
前記バス調停回路は、前記入力されるバス使用権リクエスト信号に基づいて調停信号を生成し、前記バス調停回路が生成する調停信号が前記複数のマスターデバイスに入力され、
前記複数のマスターデバイスの内、第一のマスターデバイスから、前記第一のマスターデバイス以外の第二のマスターデバイスに対し、バスを優先的に使用するためのバス優先信号が出力されることを特徴とするバス調停装置。
【請求項６】
請求項５に記載されたバス調停装置において、
第一のマスターデバイスは入力されたバス使用権リクエスト信号を観測し、
前記バス使用権リクエスト信号がネゲート状態であれば、前記第一のマスターデバイスは前記バス使用権リクエスト信号をアサートし、
第一のマスターデバイスは入力された調停信号を観測し、
前記調停信号が第一のマスターデバイスの識別番号と同一の場合、前記バスを使用し、
前記調停信号が第一のマスターデバイスの前記識別番号と異なっている場合、前記第二のマスターデバイスに対し、前記バス優先信号を発生し、
前記第二のマスターデバイスは、前記バス優先信号を受けると、前記バスの使用を途中で中断し、前記バス使用権リクエスト信号をアサート状態からネゲート状態に変化させ、
前記第一のマスターデバイスは、入力された前記バス使用権リクエスト信号を観測し、前記バス使用権リクエスト信号がネゲート状態であれば、前記バス使用権リクエスト信号をアサートした後、前記バスを使用し、
前記第一のマスターデバイスが前記バスを使用後、前記バス使用権リクエスト信号をネゲート状態にすることを特徴とするバス調停装置。
【請求項７】
請求項５に記載されたバス調停装置において、
前記調停信号をリセットするリセット信号が前記バス調停回路に入力されると、
前記バス調停回路は、前記第一のマスターデバイスの識別番号と同じ番号である調停信号を出力することを特徴とするバス調停装置。
【請求項８】
請求項５に記載されたバス調停装置において、
前記第一のマスターデバイスの識別番号と同じ番号を優先識別番号として格納するレジスタが、前記バス調停回路に接続され、
前記バス調停回路の調停信号を前記レジスタに格納される前記優先識別番号にするロード信号が前記バス調停回路に入力されると、
前記バス調停回路は、前記第一のマスターデバイスの識別番号と同じ番号である調停信号を出力することを特徴とするバス調停装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、シリアルバスのバス権獲得における調停に関するものである。
【背景技術】
【０００２】
一般に、複数のバスマスター（マルチマスター）が一つの共通バスを共有する場合、これらのバスマスターからの共通バス使用要求が競合すると、どのバスマスターにバス使用権を与えるか調停（バスのアービトレーション）を行う必要がある。このため、バス調停回路を設けアービトレーションを実施する場合が多い。ところが、バス調停方式を用いたアービトレーションでは、バス優先権の低いバスマスターがバス使用権の獲得が困難になる場合が多い。この解決方法として、特定のバスマスターからのバス要求に対して、一定の制約を与えるバス調停回路を用いる方式（例えば、特許文献１）、あるいは、バスマスターの個数分、バス調停回路を設け、それぞれのバス調停回路がバス優先権を管理する方式（例えば、特許文献２）が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００６−２５９８４２号公報
【特許文献２】特開平８-１２３７５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１にて開示されたバス調停回路方式では、後から特定のバスマスターの優先順位のみ変更できない。また、特許文献２にて開示されたバス調停回路方式では、バス調停回路規模が大きく、安価に且つ短期間に開発することが困難である等、課題が多い。
【０００５】
バス優先権の低いバスマスターがバス使用権の獲得が困難になるという課題を解決するため、重要な役割を担っているのがバス調停回路(アービタ)であるが、どのような形であれ、ほぼ必ず、バスマスターとは別に、特に外部回路として、バス調停回路(アービタ)が存在することになる。このバス調停回路(アービタ)は、マルチマスターを前提に設計されたバスに対しての付属回路として捉えられることが多い。
【０００６】
ここで、マルチマスターを前提に設計されたバスというのは、往々にして、データ線が複数あるバスであることが多い。一方、このバスに対して、データ線が1本ないしは2本程度で、デバイス(機器)間の通信を行うものが、シリアル通信である。本発明は、このシリアル通信を行うマスターデバイスを対象とする。このシリアル通信には、既に確立された規格として、下記に示すような規格があるが、これらは、必ずしも、マルチマスターを前提として設計されているわけではない。
【０００７】
RS-232C（ANSI/TIA/EIA-232-F-1997）などは、送信ライン/受信ラインが独立しており、かつ、１対１の接続を前提としたシリアル通信である。また、バスとして接続できるSPI（フリースケールセミコンダクタ社が提唱する４線式シリアルインターフェース方式）やMicroWire（登録商標、ナショナルセミコンダクター社が提唱する４線式シリアルインターフェース方式）は、基本的にシングルマスターを前提とするシリアル通信である。
【０００８】
このような既存のマルチマスターをサポートしないシリアル通信を用いて、バスを構築する際には、他のマルチマスターをサポートするバスと同様に、まず、どのマスターがバスの使用権を得られるのかを決める必要がある。
【０００９】
即ち、マスターとなるそれぞれのデバイスがバス使用要求を出し、その要求を受け付け、内部で優先順位などに基づいたバス許可を行うアービタ(調停回路)が必要となる。
【課題を解決するための手段】
【００１０】
本発明は、各々シリアル通信を行う複数のマスターデバイスと、前記複数のマスターデバイスと接続されるバス調停回路とで構成され、前記複数のマスターデバイスのバス使用権リクエスト信号がワイヤード・オアにて接続され、前記ワイヤード・オアにて接続されたバス使用権リクエスト信号が前記バス調整回路と前記複数のマスターデバイスに接続され、前記バス調停回路が生成する調停信号が前記複数のマスターデバイスに接続されることを特徴とするバス調停装置とすることで、上記課題を解決する。
【００１１】
更に、本発明は、本バス調停装置において、マスターデバイスは入力された前記バス使用権リクエスト信号を観測し、前記バス使用権リクエスト信号がネゲート状態であれば、前記マスターデバイスはバス使用権リクエスト信号をアサートし、次に、前記マスターデバイスは入力された前記バス調停回路が生成する調停信号を観測し、前記調停信号が前記マスターデバイスの識別番号と同一の場合バスを使用し、次に、前記マスターデバイスがバスを使用後、バス使用権リクエスト信号をネゲート状態にすることを特徴とするバス調停装置とすることで、上記課題を解決する。
【００１２】
バス接続可能なシリアル通信において、バスの使用権獲得を、外部回路からの許可信号なく、自身で獲得するようにし、かつ、このバス使用権獲得が特定のバスの仕様に依存することのないシステムを提案する。
【００１３】
また、シリアル通信において、送受信するデータの処理にソフトウェアが介在することに注目し、各マスターデバイス毎にユニークなIDを持たせ、そのIDと、前述のバス調停回路でもあるID生成器が生成するバス使用権獲得ID(前記調停信号でもある)が一致した場合に、そのバス使用権獲得を判定する部分に、ソフトウェアを割り当てることとする。
【００１４】
また、バス使用権獲得IDはラウンドロビン方式とするが、このバス使用権獲得IDの変更を各マスターデバイスが自身で変更する方式とする。
【発明の効果】
【００１５】
バス接続できる既存のシングルマスター対応のシリアル通信I/Fを用いるため、シリアル通信I/Fそのものに手を加えずに、マルチマスター化ができる。
【００１６】
また、既に確立されたシリアル通信を用いるため、新規開発の必要がなく、その分開発期間が短くて済み、新規開発の場合と比べ、コストも下げることができる。
【図面の簡単な説明】
【００１７】
【図１】この発明に係るシステムの一実施例の概略構成図である。
【図２】図１の実施例のタイミングチャート例である。
【図３】図１の実施例のソフトウェアのフローチャート例である。
【図４】図１の実施例の各バスマスターの待ち時間を減らす工夫をしたときのソフトウェアのフローチャート例である。
【図５】第２の実施例のマスターデバイスの構成例である。
【図６】各バスマスターの待ち時間を減らす工夫をしたときの一実施例の概略構成図である。
【図７】各バスマスターの待ち時間を減らす工夫をしたときの一実施例の概略構成図である。
【図８】各バスマスターの待ち時間を減らす工夫をしたときの一実施例の概略構成図である。
【図９】各バスマスターの待ち時間を減らす工夫をしたときの一実施例の概略構成図である図６〜８までを組み合わせた図である。
【図１０】図７の概略構成図の、ID初期化信号を用いた場合のタイミングチャート例である。
【発明を実施するための形態】
【実施例１】
【００１８】
図１には、この発明に係るシステムの第一の実施例の概略構成図が示されている。この実施例では、バス使用権獲得の判定基準となるID1を割り当てられたマスターデバイス１Ａと、同じくID2が割り当てられたマスターデバイス２Ａ、及び、それぞれのマスターデバイスが自身のバス使用権獲得か否かの判定に用いる、IDを生成するID生成器１０が主な構成デバイスとなる。尚、本構成図におけるID生成器１０は、簡素化のため、単純なアップカウンタとしている。
【００１９】
ID生成器１０は、ID１１（それぞれのマスターデバイスがバス使用権を獲得したか否かを判定するための調停信号）を生成するが、アップカウンタのため、CK端子に入力される信号BusReq７の立ち上がりの度に、ID１１は変化することになる。また、CLR端子に入力されるリセット信号９により、ID１１はALL0に初期化される。
【００２０】
BusReq７は、各マスターデバイスのリクエスト信号をワイヤードORするために、オープンドレイン(オープンコレクタ)のデバイスの出力信号であるが、ID生成器１０のCK端子に入力する信号でもあるため、デフォルトの信号状態を作り出すために、プルアップ抵抗８が接続されている。
【００２１】
尚、BusReq７は、マスターデバイスがバスを使用している限りはアクティブ状態(BusReq７=Low)を保持する。これは、マスターデバイスのバス使用の終了時には、他のマスターデバイスへバス使用権を遷移させるために、BusReq７の立ち上がり状態を生成し、ID１１を  変化させるためである。
【００２２】
このオープンドレイン(オープンコレクタ)のデバイスであるドライバ５とドライバ６は、それぞれ、マスターデバイス１Ａとマスターデバイス２Ａのバスリクエストを最終的にID生成器１０のCK端子となるBusReq７に変換するものであるため、電源投入直後のBusReq７の状態をプルアップ抵抗８による状態にするために、入力側に、それぞれ、プルダウン抵抗３、及び、プルダウン抵抗４が接続されている。
【００２３】
ドライバ５に入力するReq１２は、マスターデバイス１Ａのバス使用権リクエスト信号であり、ドライバ６に入力するReq１３は、マスターデバイス２Ａのバス使用権リクエスト信号である。尚、バス使用権リクエスト信号を出力するマスターデバイスの出力端子の電源投入直後の状態は、BusReq７のデフォルトの状態をHighにするためにLow出力かHi-Zとなる。
【００２４】
最後に、マスターデバイス１Ａとマスターデバイス２Ａについてであるが、上述のようにそれぞれにIDが付与されており、このIDとID生成器１０が出力するID１１を比較し、同一であれば、バス使用権獲得と判断する。但し、その際は、それぞれのバス使用権リクエスト信号をアクティブ＝BusReq７がLowとなった場合であるため、BusReq７もそれぞれのマスターデバイスが観測できるように入力信号として取り入れている。
【００２５】
この構成において、マスターデバイス２Ａがバス使用権獲得するまでを、図２のタイミングチャートを使用して説明する。尚、他のマスターデバイスは新規のバス使用権リクエストを行わないものとして説明する。
【００２６】
タイミング１４は、ID=0ｘFを持つ、本構成例に図示されていないマスターデバイスがバス使用権を獲得しており、バスを使用している状態である。
【００２７】
マスターデバイス２Ａは、BusReq７=Lowであり、かつ、ID１１が自身のIDである0x1ではない0xFであるために、他のマスターデバイスがバスを使用中と判断し、バスの使用不可のため、自身のバス使用権リクエスト信号であるReq１３=Highとしない状態である。
【００２８】
タイミング１５は、ID=0xFを持つマスターデバイスが、バスの使用を終了した時点から始まる。この場合、BusReq７の立ち上がりが発生するため、ID１１は、0xFから0x0へと変化している。
【００２９】
BusReq７=Highのため、他のマスターデバイスはバスを使用していないため、マスターデバイス２Ａは、自身のバス使用権リクエスト信号であるReq１３=Highとし、バスの使用をリクエストし、結果、BusReq７=Lowとなる。
【００３０】
しかしながら、ID１１を確認すると、マスターデバイス２ＡのIDとは違うため、この時点でバスを使用できるマスターデバイスはIDに0x0を持つもののみのため、バス使用権の獲得はできないと判定し、Req１３=Lowとなり、バス使用権リクエストを取り下げることになる。
【００３１】
また、タイミング１４と同様に、このReq１３=Lowにより、BusReq７の立ち上がりが発生し、ID１１は、0x0から0x1へと変化する。
【００３２】
タイミング１６は、マスターデバイス２Ａのバス使用権リクエスト取り下げによるID１１が0x1に変化した状態から始まる。
【００３３】
タイミング１５と同様に、BusReq７=Highであり、他のマスターデバイスはバスを使用していない。このため、マスターデバイス２Ａは、自身のバス使用権リクエストであるReq１３=Highとする。これにより、BusReq７はLowとなる。
【００３４】
このとき、ID１１は、マスターデバイス２Ａと同一のため、マスターデバイス２Ａは、バス使用権が自身にあると判定でき、バスを使用することができる。各信号はこの状態で、マスターデバイス２Ａはバスを使用し、使用終了後、自身のバス使用権リクエストReq１３=Lowとする。このとき、タイミング１５と同様に、BusReq７の立ち上がりが発生し、ID１１は次にバス使用権を獲得できるマスターデバイスのIDに遷移する。
【００３５】
図２のタイミングチャートの説明でもわかるように、図１の第一の実施例の場合、バス使用権獲得の成否はマスターデバイス自身が判定でき、かつ、次にバスを使用することができるマスターデバイスのIDさえも個々のマスターデバイスが遷移させることになる。また、一旦バス使用権を獲得した後は、ID１１が自身のIDと同一になるまでは、バス使用権を獲得できないことになる。
【００３６】
図１の第一の実施例、及び、図２のタイミングチャートにおける各マスターデバイスがバス使用権を獲得し、バス使用終了後、バスを開放するまでのソフトウェアのフローチャートの一例を図３に示す。但し、本フローチャートの一例では、無限ループとなる箇所があるが、これはもちろんソフトウェア的に好ましい状態ではない。従って、全体から見た場合のソフトウェアとしては、適切な実装が望ましいが、本実施例では、バス使用権獲得からバス開放までの部分に限っての説明とする。
【００３７】
以下、図２と図３を対比させながら説明を行う。
【００３８】
各マスターデバイスがバスを使用する必要が発生した場合(フロー３１１)、まず、BusReq７を観測し、当該信号がLowであれば、他のいずれかのマスターデバイスがバス使用権をリクエスト中、もしくは、バス使用中と判定し、バス使用権リクエストを行わない(フロー３１２)。この状態をBusReq７=Highとなるまで行う(フロー３１３)。この状態は、図２中のタイミング１４のときのフローであり、図３中ではフロー３１０となる。
【００３９】
フロー３１２の判定の結果、BusReq７=Highならば、自身のバス使用権リクエストをHighとする(フロー３２１)。その後、ID１１と自身のIDを比べ(フロー３２２)、ID１１が自身のIDと同一でないならば(フロー３２３)、バス使用権リクエスト=Lowとし(フロー３２４)、BusReq７を観測に戻る(フロー３２５)。この状態は、図２中のタイミング１５のときのフローであり、図３中ではフロー３２０の部分となる。
【００４０】
フロー３２２で、ID１１を判定した結果、自身のIDと同一ならば、バス使用権を獲得したとみなし、バスの使用を開始する(フロー３３１)。
【００４１】
バスの使用終了後(フロー３３２)、自身のバス使用権リクエストをLowとし(フロー３２４)、BusReq７の観測に戻る(フロー３１０)。ここまでが、図２中のタイミング１６のときのフローであり、図３中ではフロー３３０である。
【００４２】
以上の説明が、第一の実施例の基本的な構成例、それに基づいたタイミングチャート、及び、フローの説明である。
【実施例２】
【００４３】
次に、第二の実施例を説明する。第一の実施例において、バスを使用したいマスターデバイスは、常にID１１が自身のIDと同じになるまで待たなくてはならない。そこで、ID１１をマスターデバイス自身で遷移させられることを利用し、自身のIDに近づけていく実施例を図４を用いて示す。
【００４４】
即ち、現在のID１１は、いつでも取得できるため、ID１１と自身のIDの差がどのくらい離れているかは簡単に判断できるが、この判断で、一定以上の差があると判定された場合、空リクエストを行うのである。この空リクエストにより、ID１１の遷移を進めることができ、バス使用権を得るまでの待ち時間を減らすことができる。以上の説明が、第二の実施例である。
【００４５】
第二の実施例を示す図４のフローでは、第一の実施例である図１におけるマスターデバイス１Ａを用いたときのソフトウェア的な実施例を説明しているが、もちろん、この動作をハードウェアとして置き換えることも可能であり、そのハードウェアを用いたソフトウェアを作成することも可能である。この第二の実施例をハードウェア的に実現するマスターデバイスの構成例を図５に示す。
【００４６】
マスターデバイス１Ｂは、図１におけるマスターデバイス１Ａとほぼ同等であるが、第二の実施例を実現する機能を有する点に相違がある。ID１１、マスターデバイス別に付与されたID(図５の場合、ID1=0)、BusReq７がマスターデバイス１Ｂ内の中央処理装置であるＣＰＵ １Ｂ−５に接続されているのは、第二の実施例をソフトウェア的に実現する（ＩＤ差検出信号ＩＢ−４を出力する）ためであり、その他の部分はハードウェア的に実現するための回路である。
【００４７】
マスターデバイス１Ｂ内のID差検出回路１Ｂ−１は、自身のIDと現在のID１１との差が、予め設定された許容ID差以上であるならば、同じくマスターデバイス１Ｂ内に内蔵されたリクエスト生成器１Ｂ−３へＩＤ差検出信号１Ｂ−２を出力する。これにより、リクエスト生成器１Ｂ−３はＩＤ差検出信号１Ｂ−２がアクティブの間、Req１２により、空リクエストを出し続けることができる。これにより、ソフトウェアによる空リクエストを行うのと同等の機能をハードウェアで実装できることになる。もちろん、ハードウェアによる自発的な空リクエストを行わず、ＣＰＵ １Ｂ−５がＩＤ差検出信号１Ｂ−２を監視するというハードウェアの支援を受けたソフトウェアの動作とすることも可能である。
【００４８】
このように、第二の実施例では、通常のアービタを用いる場合と異なり、バス使用権のリクエストからバス使用権の取得、バス使用を自身で完結できるが故に行える方法であり、自身の優先順位を自身で上げていく方法である。
【実施例３】
【００４９】
図４におけるフローは、図１の構成例の状態で、各マスターデバイス間で公平に自身の優先順位を上げる方法であった。一方、ハード的な構成に手を加えることで、特定のマスターデバイスに対して、優先順位を上げることにより、バス使用権を得るまでの待ち時間を減らすこともできる。これを第三の実施例とし、図６〜９の構成例２を用いて説明する。この図では、3通りの方法を図示しており、以下の記述では、それらを別個の方法（第三の実施例A，第三の実施例B，第三の実施例C）として記述しているが、それぞれを組み合わせて使用することも可能である。
【００５０】
図６で示す第三の実施例Aは、バス使用の最優先デバイスをマスターデバイス２Ｃとした時、このマスターデバイス２Ｃに対し、優先信号１７を与えることである。この優先信号１７は、他のマスターデバイスに接続されており、この信号がアクティブになると、他のマスターデバイスはバス使用権リクエスト中であっても、そのリクエストを取り下げることとする。
【００５１】
全マスターデバイスのバス使用権リクエストが取り下げられたかどうかは、BusReq７=Highとなっていることで確認できるため、この状態で、バスを使用することができるが、このとき、通常の手順通りにReq１３=Lowとしてもよいし、図４のフローのように、空リクエストにより、ID１１を正規のIDに遷移させてもよいし、正規の手順を省き、BusReq７=Highとなった直後から、バスを使用してもよい。
【００５２】
尚、優先信号１７がアクティブの間は、他のマスターデバイスはバス使用権のリクエストを行わないようにするが、この状態だと、マスターデバイス２Ｃがバス使用権を獲得し続けることも可能なため、システム的に不具合が生じる可能性がある場合は、優先信号１７を使用するマスターデバイスは、優先信号１７を使用した際のバスの使用の上限値を定める方法をとってもよい。
【００５３】
図７で示す第三の実施例Bは、ID１１がID生成器１０のCLR端子に入力される信号により初期化されることに着目した方法であり、最優先デバイスのIDをID１１が初期化された値と同じにする方法である。
【００５４】
ID１１が初期化された値と同じIDを持つマスターデバイスは、図示されてはいないが、最終的にID生成器１０のCLR端子に接続されるID初期化信号１８となる最優先デバイス初期化要求信号が付加され、最優先デバイスとなることができる。 
最優先デバイス初期化要求信号によりID初期化信号１８がアクティブになると、ID１１は初期化され続けることになり、例え、他のマスターデバイスのバス使用権リクエストにより、CK端子の信号に立ち上がりが見られても、ID１１は遷移することはない。そのため、ID初期化信号１８が付加されたマスターデバイスは、通常のバス使用権を獲得するフローの前後に、ID初期化信号１８をアクティブ・インアクティブにするという手順を追加するだけである。
【００５５】
このときのタイミングチャートが図１０に示してある。この図では、他のマスターデバイスがバス使用権のリクエスト中、または、バス使用中の状態(BusReq７=Low)の時に、最優先デバイス初期化要求信号がアクティブになったところから始まっている。
【００５６】
BusReq７=Highとなると、最優先デバイス初期化信号がアクティブになっていることから、ID初期化信号１８もアクティブになる。そのため、ID１１が初期化されることになる。このID１１を確認した最優先デバイス初期化要求信号が付加されたマスターデバイスは、通常通り、バス使用権リクエストをHighにし、BusReq７=Lowとして、バスを使用することになる。
【００５７】
通常は、バス使用権のリクエストを行ってからIDを確認する手順となるが、ID初期化信号１８を用いる場合は、逆の手順となり、ID１１が初期化されたこと、つまり、自身のIDと同一となったことを予め確認して、リクエストを行い、バスを使用することになる。
バス使用後の処理は、通常時とほぼ同一であるが、唯一、バス使用終了前に最優先デバイス初期化信号をインアクティブにする、つまり、ID初期化信号１８がインアクティブになる点に相違がある。
【００５８】
図８で示す第三の実施例Cは、ID生成器１０に接続されているレジスタに格納される優先ID２０をID１１にロードする機能を用いた方法である。IDロード信号１９は、優先ID２０をID１１にロードし、ID１１を強制的に最優先デバイスのIDと同じにすることができる。この方法は、ID初期化信号１８を用いた場合と同等であるが、唯一の違いは、ID１１の初期化が一義的に決まるものとは違い、優先ID２０に任意の値を定めることができることである。
【００５９】
いずれの優先順位を上げる方法でも、他者、例えば、アービタなどにより、優先順位がつけられる方法ではなく、バス使用権のリクエストを行うマスターデバイス自身が、自力で優先順位を上げる方法となる。
【００６０】
尚、図９で示す構成例は、第三の実施例すべてを組み合わせた場合の構成例である。
【００６１】
図６〜８の場合、一つのマスターデバイスへ対しての最優先デバイスという位置づけの付与ということであったが、図９の場合、複数のマスターデバイスへ優先順位を付与することができる。しかしながら、それぞれの方法で優先デバイスを付与されたマスターデバイスの内、全てが最優先デバイスとなるわけではない。
【００６２】
例えば、優先デバイスといえども、ID１１が自身のIDと同一になったことを確認後、バスを使用できるなどの一定のルールを決めた場合、ID生成器１０が単純なロード機能付きカウンタであると、CLR端子に入力されるID初期化信号１８を付与されたマスターデバイスが最優先デバイスとなることができる。次に優先順位が高いマスターデバイスは、IDロード信号１９を付与されたマスターデバイスであり、最後が優先信号１７を付与されたマスターデバイスとなる。
【００６３】
逆に、ID生成器１０の特性を利用すると、優先信号１７を付与されたマスターデバイスの優先順位を上げることもできる。それは、例えば、優先信号１７をID初期化信号１８やIDロード信号１９と共用することである。優先信号１７をID初期化信号１８と同一とすると、他のマスターデバイスへ最優先マスターデバイスがバス使用権のリクエストを知らしめると同時に、ID１１を自身のIDへと遷移させることも可能である。
【００６４】
また、優先信号１７とIDロード信号１９が付加されたマスターデバイスと、IDロード信号１９のみが付加されたマスターデバイスがあった場合、優先信号１７で他のマスターデバイスのバス使用権のリクエストを取りやめさせることにより、IDロード信号１９による優先順位が同一であっても、優先信号１７が付加されたマスターデバイスの方が優先順位を高くすることもできる。但し、この場合、それぞれのマスターデバイスのIDが同一のため、通常のフローでバス使用権のリクエストは行わないなどのルールが必要である。
【００６５】
このように、図９のように、優先デバイスとなるための手段を組み合わせることで、複数のマスターデバイスにいろいろな優先順位を付与することが可能である。
【産業上の利用可能性】
【００６６】
本発明のバス調停装置及びバス調停方法を活用することで、シリアル通信等の複数のマスターデバイスが共通のシリアルバス利用する方式を効率よく安価に実現できる。特に、産業用途向け組込み装置間の通信システムに利用可能である。
【符号の説明】
【００６７】
１Ａ  第一の実施例におけるマスターデバイス
２Ａ  第一の実施例におけるマスターデバイス
１Ｂ  第二の実施例におけるマスターデバイス
１Ｃ  第三の実施例におけるマスターデバイス
２Ｃ  第三の実施例におけるマスターデバイス
３  プルダウン抵抗
４  プルダウン抵抗
５  ドライバ
６  ドライバ
７  BusReq信号
８  プルアップ抵抗
９  ID生成器へのリセット信号
１０  ID生成器
１１  バス使用権を示すID
１２  各マスターデバイスのバスリクエスト信号
１３  各マスターデバイスのバスリクエスト信号
１４  あるマスターデバイスがバスを使用しているときの信号状態
１５  バス使用権獲得できなかった場合の信号状態
１６  バス使用権獲得できた場合の信号状態
１７  バス使用権優先信号
１８  バス使用権優先信号(ID初期化信号)
１９  バス使用権優先信号(IDロード信号)
２０  バス使用権優先ID
【図１】
2011060157.tif 000003
【図２】
2011060157.tif 000004
【図３】
2011060157.tif 000005
【図４】
2011060157.tif 000006
【図５】
2011060157.tif 000007
【図６】
2011060157.tif 000008
【図７】
2011060157.tif 000009
【図８】
2011060157.tif 000010
【図９】
2011060157.tif 000011
【図１０】
2011060157.tif 000012