Gaileoはどこへ行く？

Galileoが国内で出回ってから2ヶ月ほど経った。
Galileoを使い始めてから書き始めたこのBlogも読んでくれた方が予想以上におられるようで嬉しい。
しかし、発表時、そして流通してからはそれなりに話題になったものの、その後はいまひとつという感じが否めない。実際自分も、もしGalileoがこのままであればその面白みはそれほどのものではない…と感じている。
誰もが思っているだろう事を書いてみようか。

今のGalileoの欠点は、I/Oの重さ（遅さ）、Linuxの貧弱さにあると思う。

I/O（GPIO）に関しては、その遅さは使い方次第では致命的とも言えるだろう。I2C経由（しかも100kHz）だからすごく遅い。GPIOをこのような構成にしたのはArduino互換にこだわったという事かもしれないが、Arduinoのシールドがそのまま使えない物が多いようでは意味が無い。少なくともGPIOについては純正Arduinoに勝る点は無く、それ以外のメリットが無い限りGalileoを使う意味が無い。
「それ以外のメリット」は何か。

純正Arduinoと大きく異なる点として、Linuxベースであり、スケッチがプロセスのひとつとして動くという事があるだろう。とすればLinux上で動作させる他のプロセスとの連携で、普通のArduinoには出来ないことができそうだ。例えばEthernet関連は普通のArduinoでも使えないことは無いが複雑な処理をさせるのは苦手だ。その苦手な部分をLinux上の別のプロセスで分担できれば…と、誰もが思うだろう。

ところがGalileoが公式にリリースしているLinuxは貧弱だ。opkgコマンドが用意されているものの、デフォルトでリポジトリが何も登録されておらず、何かパッケージをインストールしようと思っても簡単にはできない。この点ではYUNのほうがずっとマシだ。
もちろん公式リリース以外のLinuxを入れるという事もできる。それはそれでひとつの楽しみであはあろうが、それ自体が目的という感じがする。
現時点でIntelからはソフト等のアップデートは無い。IntelがGalileoの今後をどう考えているのかわからない。ハードを改善する事は難しいだろうから、せめてLinux部分で簡単な拡張性を持たせ、Arduinoでは難しかった事がArduinoのような簡単さでできるようにしてもらいたいものである。


ちなみに僕は… Arduino用の自作シールドを接続し、I2C接続の液晶ディスプレイがそのままでは接続できない事がわかり、だったらI2C信号を一旦別のデバイスで受けるような仕組みを作ってみようか…と考えた。ちょうどトラ技でLPC810の特集が組まれ、それに興味を持ってしまい、だったらこれで作ってみようか…と考えた。ってことで、LPCXpressoでLPC800シリーズをいろいろいじっているところである。

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を接続しても「壊れない」という事を保証するものではない、という事は書いておく。