GalileoはST7032iと相性が悪い(2)…とりあえず動いた

前回に続いて Intel Galileo にI2C接続のLCDディスプレイを接続するテスト。
ST7032iがI2C信号線をLレベルに引っ張る力が弱いのではないかという予想、もしそうであれば、I2Cの信号線をプルダウンして、ST7032iが引っ張れるレベルをQuarkのスレッショルドレベルより下げれば動くかもしれない。
ということでやってみた。
結論から先に言うと、非常に不安定ではあるもののとりあえず動作した。
その時の波形が以下。

 

とりあえずSDA信号のみ、可変抵抗を経由してGNDに落とし、抵抗値を変化させて様子を確認した。この波形は正常に動作した時。アドレス（0x3E）の送信の後、次のデータ（0x00）が送信されていることがわかる（SCLが動いている）。
カーソルは、エラーが出なかった時のSDAのHレベルの範囲を示している。このとおり非常に狭い。ちなみに正常に動作した時の抵抗値は約1.3kΩだったが、このとおり正常に動作する範囲が非常に狭く不安定なため、仮に1.3kΩの固定抵抗でプルダウンしただけでは実用的な安定性を得られることはなさそうだ。

ということでGalileoにこのI2C接続のLCDを接続するとなると、うまくドライブできるような回路を挟むか、Galileo上の2.2kΩのプルアップ抵抗をもっと大きな値に変更する必用がありそうだ。

ちなみに動作したところか以下。
 

なお、I2C液晶モジュールは秋月の変換基板を使用しているが、その変換基板上にあるプルアップ抵抗は接続していない。

GalileoはST7032iと相性が悪い？

Galileoに、秋月で売ってるI2C接続のLCDディスプレイ、AQM0802A-RN-GBW を接続してみようと思っているのだが、うまくいかない。
コマンドを書き込もうとすると Failed to write bytes to I2C slave: Remote I/O error というエラーメッセージが出力される。
同時に接続した他のI2Cデバイスとは正常に通信できたので、どうやらこのLCDディスプレイ、もっと細かく言うとその中のコントローラーであるST7032iとの通信が正常にできていないのかもしれない。 ということで波形を確認してみた。その結果がこれ。



ここのデバイスのアドレスは0x3E、画面左側のSDAの波形を見ると確かに0x3E、R/W=0でアドレス自体は正しく発行されている。ってことで各種初期設定関連は問題なさそうだ。

そして問題はその後、SDAが中途半端な電圧になっている。ACK部分がLレベルに引っ張り切れてない。
どうもST7032iはLレベルに引っ張るのが弱いようだ。I2Cバスを1kΩでプルアップするとLレベルに引っ張りきれなくて不安定になってしまうことがあるという事も確認したことがある。
Galileoの回路図を見るとI2Cバスは2.2kΩでプルアップされている。そのくらいだったら大丈夫なんじゃないかと思うのだけど、引っ張りきれないのが原因なのだろうか。
詳細さらに確認中。

Intel Galileo : トレース出力を活用してみる

動かないシールドの原因確認をいろいろ。

ライブラリの途中にprintfとか入れようと思ったが、Galileoの各ソースを見るとトレース出力がいろいろある。これを活用しない手は無いだろう。

トレース出力関連の処理はtrace.h/cに書かれている。出力のレベルはTRACE_LEVEL_ERROR/INFO/DEBUGの3種類、DEBUGが最も情報量が多い。これに設定してみよう。

デフォルトではTRACE_LEVEL_INFOが設定されている。これは hardware/arduino/x86/variants/galileo_fab_d/variant.h の中で設定されている。

#define VARIANT_TRACE_LEVEL TRACE_LEVEL_INFO // default trace level 

これを TRACE_LEVEL_DEBUG に書き換える。

トレース出力は stdout に出力される。デフォルトでは /tmp/log.txt に書き出されるのでこれを tail とかで表示させればいいが、トレース出力だけでなくエラーに関する情報を stderr に書いているところもある。これは /tmp/log_er.txt に書かれる。情報が分散されると見づらいので同一出力先にしたほうが便利。そこで main.c を書き換え、両方とも /dev/console に出力されるようにする。

（前略）

// stdout = freopen("/tmp/log.txt", "w", stdout);

stdout = freopen("/dev/console", "w", stdout);

（中略）

// stderr = freopen("/tmp/log_er.txt", "w", stderr);

stderr = freopen("/dev/console", "w", stderr);

（後略）

これでシリアル出力にトレース出力が表示される。

スケッチでトレース出力をするには、まず MY_TRACE_PREFIX を何か定義する。この文字列がトレース出力の頭に追加される。

#define MY_TRACE_PREFIX "MySketch"

あとは trace_debug, trace_info, trace_errorのいずれかで出力する。

trace_debug(“TEST\n”);

Serial.printとは別に表示でき、便利。

Intel Galileo : 接続順を間違えたらどのように壊れるか

Intel Galileoには、各端子は電源を接続してから接続するように、でないと壊れる可能性があるという注意書きがある。

しかし今までに何度も、USB端子を接続しま電源を切ってしまうという事をやっている。幸い壊れていない。念のため、この、やってはいけない事をやってしまったらどのようなダメージが考えられるのか確認してみた。

まずUSB Client端子。問題になりそうなのがホストからの電源だが、Galileoの電源端子に何も接続されていない時は、このUSB Client端子からの電源はFETで切断されるようになっている。よって問題なさそうだ。次に信号線、これはQuarkに接続されているが、これもEMC対策用の保護ダイオードで電源電圧を越えないようクランプされている。

問題になりそうなのが、電源端子にACアダプターを接続しつつ（DCジャックのスイッチ部を利用しているので、プラグが挿入されているか否かで異なる）、その出力が不安定な場合だ。この場合、上記FETがオンになってしまう可能性も否定できない。そうなるとUSB Client端子からの電源が各デバイスに供給されることになる。電流が多く流れればホスト側の保護回路が機能するかもしれない。

次にRS232端子、MAX3232に接続されているが、これのR-IN入力は±25Vとかなり余裕がある。データシートを見る限り電源電圧を超えてはいけないような記載は無い。これも問題なさそうだ。

Ethernetは詳細を確認していないが、コネクタ内のパルストランスを経由してTIのPhy Layer Transceiverに接続されている。一般的なネットワーク機器にも使う汎用的な部品だろう。まぁ、このようなICを使った一般的なネットワーク機器で「RJ45コネクタを接続したまま電源を切ってはいけない」なんて事は無いから、これも問題無いだろう。

ということで、それなりの保護回路は搭載されているので、電源を接続せずにUSB端子を接続することで即壊してしまうような軟弱な設計ではないという事は言えそうだ。

ただし、もちろんこれは、電源接続無しでUSBを接続しても「壊れない」という事を保証するものではない、という事は書いておく。