I2Cバスに接続されているスレーブデバイスの自動検出

Question

• 前提・実現したいこと

Arduinoの、1つのI2Cバスに
複数のスレーブデバイスを接続しようとしています。

実現したいこととしては、I2Cのバスに接続されているスレーブデバイスの素性をマスター側で自動的に検出し、
スレーブデバイスに合わせて動的に通信フォーマットを変更することです。

Arduinoの2つのI2Cバス、I2Cバス1・I2Cバス2を使用するものとし、
I2Cバス1に、スレーブデバイスA・スレーブデバイスB・スレーブデバイスC・スレーブデバイスD
I2Cバス2に、スレーブデバイスE・スレーブデバイスF・スレーブデバイスG・スレーブデバイスH
がつながる場合と、
I2Cバス1に、スレーブデバイスE・スレーブデバイスB・スレーブデバイスC・スレーブデバイスD
I2Cバス2に、スレーブデバイスA・スレーブデバイスF・スレーブデバイスG・スレーブデバイスH
がつながる場合があります。

スレーブデバイスA～Hは、すべて仕様の全く異なるスレーブデバイスですが、
スレーブデバイスA・スレーブデバイスEのスレーブアドレスが重複しており、
アドレス重複は回避できないものとします(重複回避方法があることは知っていますが、それができない前提です)。

• 発生している問題・エラーメッセージ

すぐに思いつくのは、
【方法1】

1. I2Cバスに、アドレス0～127までのスレーブに対してスタートコンディションを送信する。
2. ACK応答のあったアドレスのスレーブデバイスが接続されていると判断する。
3. マスターでアドレスからスレーブデバイスの素性を判断する
4. つながっているスレーブデバイスに合わせた通信フォーマットで、スレーブデバイスと通信を行う

のようなものですが、
スレーブデバイスA・スレーブデバイスEのような
スレーブアドレスが全く同じ、通信フォーマットの異なるセンサーがつながる場合があるため
この方法は使えません。

また、スレーブアドレスとスレーブデバイスの素性を対応づける方法だと
スレーブアドレスが同じ、素性の異なるスレーブデバイスが存在してはならないため
112種類のスレーブデバイスしか接続候補になることができず、拡張性に問題があります。

• 自分で調べたことや試したこと

【方法1】で、つながっているスレーブデバイスのアドレスを特定することで、
スレーブデバイスA・スレーブデバイスEのどちらかがつながっていることまでは特定できます。

ここからさらに、スレーブデバイスA・スレーブデバイスEと実際に通信を試みて、
ACK応答があったデバイスが実際につながっていると判断する方法を考えています。

ただし、スレーブデバイスA・スレーブデバイスEの通信フォーマットが異なることが
前提条件となります。

まだ考えている段階で、これから設計・実装をしていこうと考えているのですが、
私の考えている案は、現実的でしょうか？
一般的には、このような問題はどうやって解決されているのでしょうか？

ご助言いただければ、幸いです。
宜しくお願い致します。

Answer 1

とても単純に考えれば、Aをつなぐときは検出用のダミーデバイスIも必ずバスにつなぐ、EをつなぐときはJをつなぐ(あるいはIを接続しない)、でしょうか。

そもそも論として、「なんでそんな面倒なことをしなきゃいけないのか」と思います。起動毎に構成が変わったりして、それが管理不可能なのでしょうか。

機内バスであるI2Cで、アドレスが128しか用意されていないのはどういう意味だと思いますか? Plag&Playを謳うUSB等とは違うのですから、I2Cでユニバーサルな自動検出なんて簡単に破綻する機構になるのは必定でしょう。本当にそういう機構が必要なら、物理層はI2Cでもいいですけれどその上にP&Pを実現するような論理層を構築する必要があるでしょう。(ホットプラグまでは考えていないですよね?)

112種類のスレーブデバイスしか接続候補になることができず、拡張性に問題があります。

では、世の中の全てのI2Cデバイスのデータベースとドライバを持たせようというのですか? でも、どんなに頑張っても「未知のデバイス」が繋がれる可能性はなくなりません。

「やってみたいだけ」「どこまでできるかの挑戦」というならその旨宣言してください。考え方を変えますから。

Comments

[A-Hayashi]

>とても単純に考えれば、Aをつなぐときは検出用のダミーデバイスIも必ずバスにつなぐ、
>EをつなぐときはJをつなぐ(あるいはIを接続しない)、でしょうか。

その方法は思いつきませんでした。

>そもそも論として、「なんでそんな面倒なことをしなきゃいけないのか」と思います。
>起動毎に構成が変わったりして、それが管理不可能なのでしょうか。

起動毎に構成が変わり、構成が変わるたびにソフトを書き換えるのではなく、
同一のソフトで、構成違いに対応したいと考えています。

>機内バスであるI2Cで、アドレスが128しか用意されていないのはどういう意味だと思いますか?
>Plag&Playを謳うUSB等とは違うのですから、I2Cでユニバーサルな自動検出なんて簡単に破綻する機構になるのは必定でしょう。

アドレスが128個しかないのは、あらかじめ接続されるスレーブデバイスが決まり切っている場合のみが
想定されているということでしょうか。

>本当にそういう機構が必要なら、物理層はI2Cでもいいですけれどその上にP&Pを実現するような論理層を
>構築する必要があるでしょう。(ホットプラグまでは考えていないですよね?)
まさに私がやろうとしていたことは、P&Pですね。
ホットプラグまでは考えていません。

既製品のスレーブデバイスを使用するのは諦め、スレーブデバイスのソフトも同時に開発し、
P&Pを実現するような機能をあらかじめ組み込んでおくしかなさそうですね。

>では、世の中の全てのI2Cデバイスのデータベースとドライバを持たせようというのですか?
>でも、どんなに頑張っても「未知のデバイス」が繋がれる可能性はなくなりません。

未知のデバイスに対応する必要はありません。
既知の同一スレーブアドレスの、通信フォーマットが異なるセンサに
対応したいと考えています。

>「やってみたいだけ」「どこまでできるかの挑戦」というならその旨宣言してください。考え方を変えますから。

いろいろなスレーブデバイスが様々な組み合わせで
繋ぎ変えられるような場合に、ソフトを変更せずにどこまでできるかの挑戦です。

[thkana]

> 接続されるスレーブデバイスが決まり切っている場合のみが想定されているということでしょうか。
I2Cの出自は(まだブラウン管の時代の)テレビのマイコン周りの機内バスです。I2Cの仕様書( https://www.nxp.com/docs/ja/user-guide/UM10204.pdf )をみるならば、「IC 間制御を行う シンプルな 2 線式双方向バス」とあります。あくまで「IC間」。繋がるデバイスをダイナミックに変更しようなんていう考えはなさそうに思います。

> 既製品のスレーブデバイスを使用するのは諦め、スレーブデバイスのソフトも同時に開発し、
> P&Pを実現するような機能をあらかじめ組み込んでおくしかなさそうですね。
そこまでする覚悟があるのならなんとでもなるでしょう。今でも一部のレジスタにIDを載せているものはありますが、そんな感じで統一的にIDや対応が必要な個別パラメータを返すアドレスを決めておけばそれなりにいろいろできるでしょう。
(それをI2Cと呼ぶかどうかはちょっと別の議論ですね。)

Answer 2

何を問題視しているのかわかりません。
通信フォーマットが異なるなら、どちらと通信しているか判別できるような通信内容は容易に考えられるでしょう。
正しくない内容を送るとデバイスが使用不可能になるなら別ですが、そのようなことは考えづらいです。

Comments

[A-Hayashi]

ikadzuchi様

回答ありがとうございます。

* 私の考えている方法が、現実的な解決方法なのか？
* 私が気づいていない、うまくいかないようなケースがないか？
* より良い、解決方法がないのか？

ここらへんの助言がいただきたくて、投稿しました。

「何を問題視しているのかわかりません。」
ということは、ikadzuchi様にとっては当然できるだろうということですね。

ありがとうございました。

Answer 3

スレーブデバイスが同じものがつながるのであれば、区別できません。
不可能です

＃そりゃ双方のデバイスのコマンド体系をそれ前提にして定義してるってなら不可能ではないだろうけど

Comments

[A-Hayashi]

y_waiwai様

おっしゃるように、
スレーブアドレスが同じで、スレーブデバイスの仕様が同じものを区別するのは不可能だと思います。
そういう場合は、どのI2Cバスに接続されているかで区別するしかないと思います。

スレーブアドレスが同一の、異なる仕様のスレーブデバイスがつながる場合は、
スレーブデバイスの通信フォーマットの違いから、
つながっているスレーブデバイスを特定することができるのでは？
と考えたのですが、難しいでしょうか

[y_waiwai]

それができると思うなら、他人に聞くんじゃなくて自分でやってみては。

そもそも、I2Cと言う通信方式はそんな多数のデバイスをつなげるようなもんじゃありません
基板内だけの限定した接続形式と考えましょう

[A-Hayashi]

回答ありがとうございます。

大量のデバイスを同時に接続するのではなく、
接続される候補・組み合わせが多くある場合を考えています。

一度、自分で試してみることにします。