R&D daily

恒例の外仕事。
外気温３４℃はまあいいとして、宿の部屋の気温２０℃というのは何とかならんものか。
長袖装備は欠かせない。

------

移動時間が長いので、考え事を色々と。

ちょっと必要に駆られてI2C。

I2Cを使う時は、バスリカバリを実装しないと、一発のノイズが原因でバスが止まったままになってしまうこともある。

とりあえず一定時間ACKが帰らないのをソフトウエアで監視して、ペリフェラルごとリセットを掛けるようにしているのだが。

なんだか、ちょっと強引な感は否めない。スマートな解決策は無いかな。

最近はNXP純正のI2Cバス規格の日本語データシートまであるようだ。

http://www.nxp.com/documents/user_manual/UM10204_JA.pdf

つれづれと眺めてみても、バスストール時のリカバリについては特に言及してないようだ。
そもそもバスクロックストレッチのタイムアウトも無いようなので、やはり規格としてはバスストールの概念も無いのか。

スレーブが応答しなくなったら、ハードウエアリセットをかけるか、電源の再投入を試みろとか、怖いことが書いてある．．．

要するに、I2Cを使うなら、それくらいのことは想定しろと。
ソフトウエアから、電源の再投入ができるようにするには．．．
うーむ。

------

各モジュールはオープンドレインでドライブしているので、万が一、一部電源が落ちてしまった場合でも、全体には波及しない、ってことなのか。

I2Cを別のボード間で使う場合は、ブリッジで切り離せるようにしておいて、
http://www.ti.com/lit/ds/symlink/pca9515a.pdf
障害時は、切り離して復旧するのが良いのかな。

ちょっと使うには良いけど、本格的に使うには色々あるよなあ。
ハードウエアは大げさだけど、CANなんかのほうがやりやすいかな。

上手く動いているときは、どの通信規格を使っても大差ないけど、異常時の動作がちゃんと規定されているもののほうが、安心して使える。