●Galileoファーストインプレッション

既報の通り、Intelは10月3日にGalileoボードを発表すると共に、ソフトウェアやドキュメントの配布を開始した。さて、そのGalileoボード、11月に国内販売計画が発表されたものの、後追いで1月中旬の発売に延期される( インテル-galileo-開発ボード-発売延期のお知らせ )といった騒ぎになっている。

【もっとほかの写真をみる】

この発売延期、実は国内だけの話ではない。実は筆者は、香港のMouser Electronics(www.mouser.com)でGalileoの扱いが始まった10月17日に早速申し込んでおり、その際の推定出荷時期が11月13日だったのが、その後12月2日、12月13日とどんどんずれてゆき、12月17日に一旦出荷時期未定に切り替わった後で、やっと12月24日に出荷された(Photo01)(この原稿を書いている12月26日時点では、江東区まで届いており、現在税関の処理待ちの模様)。10月にオーダーしたものがこれだから、一般に広く流通するにはまだ大分掛かりそうである。


さてそんなGalileoであるが、幸いIntelより評価ボードを借用する事が出来た。とはいえ、つい最近も某社から拝借した開発ボードを2枚も"燃やした"経験があるので、自分のボードが入手できるまでは余り「攻めた」レビューは怖くて出来ない。そんなわけで今回は、とりあえずの感触ということでファーストインプレッションをお届けしたい。


○相変わらず鳴り響くIntelサウンド


さてGalileoボードはこんなパッケージに入って届けられる(Photo02,03)。パッケージの中身はボード本体とACアダプタ、MicroUSBケーブル、Quick Stard Guideとなぜかバニー人形が入っていた(Photo04)。ちなみにパッケージを開けただけでは何も起きないが、ACアダプタなどを取り出すべく中の仕切りを外すとお馴染みIntelサウンドが。仕切りの裏にオルゴールが実装されていた(Photo05)。


さて、ボードそのものは以前の写真と殆ど同じである(Photo06)。裏面はこんな具合。ちなみにACアダプタは3.1A出力のものが付属してきており、微妙に裏面のシールの表記とあっていなかった。ボードサイズは実測で102mm×73mmで結構大きい。比較のために手持ちのArduino UNO/Arduino MEGAと並べたのがこちら(Photo08)で、長さはほぼMEGAと同程度だが、幅は明らかに一回り大きい。もう一つ問題になるのが高さ方向。水平に置くと、Mini PCIeコネクタ(Photo09)及びMini PCIeカードホルダー(Photo10)で高さが保持されている形だが、Mini PCIeコネクタはともかくカードホルダーの方は明らかに強度不足である。Photo04では隠れてしまっているが、28mmのスペーサーと取り付けネジが4対付属しているのは、このコネクタやカードホルダーに力がかからないようにスペーサーで基板を浮かせろ、という意味だと思われる。


あと個人的感想だが、Quark X1000チップがダイむき出しになっており、Shieldの着脱にうっかり何かぶつけただけでダイが削れそうなのは怖い。正直開発キットとして使うには脆弱な気がする。昔のICHの様なプラスチックパッケージにするか、薄いアルミ板でいいからヒートシンク兼用でカバーを用意してほしかったところだ。


●色々癖のあるソフトウェア環境

○色々癖のあるソフトウェア環境


さて、では使う手順である。Galileoの場合、Arduino互換のソフトウェア環境と、それとは別にLinux BSP(Board Support Package)も提供され、どちらでも利用可能となっているが、筆者は当然マイコンボードとしてのGalileoに興味があるので、Arduino互換環境を構築してみた。さて、ソフトウェアであるがIntel Makers Communityから入手できる。筆者の場合はWindows 7の環境なので、"Intel Galileo Arduino SW 1.5.3 on Windows"をダウンロードする。で、これはzipファイルなので展開するのだが、この際に展開先を"C:\"にする必要がある。実際は別の場所でもいいのだが、C:\Program FilesとかC:\Program Files(x86)ではダメである(理由は後述する)。また、同時にGetting Stated Guideも入手しておこう。


次にUSBのドライバのインストールである。手順だが、


1. GalileoボードにACアダプタを接続して電源On(GalileoはUSB Bus Powerでは動作しない。Getting Started Guideによれば「ACアダプタを挿さずにUSBを接続するとボードが壊れる可能性がある」と警告されている)。

2. USBケーブルを、GalileoのUSB Client側コネクタ(Photo06で中央上の左側)に接続し、PCとつなげる。

3. Device ManagerでGadget Serial Driverが出現するのを確認し、これの「ドライバの更新」を行う(Photo11)。

4. Driverの指定で、hardware\arduino\x86\tools を指定する(Photo12)。

5. ドライバが認識されて、正常にCOMデバイスとして登録される(Photo13〜15)


ここまで終わればあとはC:\Arduinoにあるarduino.exeを起動するだけで良い(Photo16)。ところで先ほど説明した"C:\"以外では駄目な理由をちょっと説明したい。とりあえずLチカということでList 1の様なSketchを入力してみる。これを例えばC:\Program Files(x86)の下に置いたArduinoでビルドしようとすると、こんなエラーになる(Photo17)。要するに、Arduino IDEからg++を呼び出すにあたり、ロングファイルネームに対応してないのだ。だから、別にC:\でなくてもロングファイルネームで正しく扱えるディレクトリならばビルドは問題なく可能である。実際 C:\Galileo というディレクトリを作成し、ここにインストールしても問題なくビルドが可能だった。ということでインストールの際には注意されたい。


■ List 1


●プログラムはNativeで実行

○プログラムはNativeで実行


さて、気を取り直して先ほどのList1のLチカを実行。Pin 13とGNDの間にLEDを繋いで動作させてみた。Sketch Sizeは49,046 Bytesで全体の18%(最大262,144Bytes)となる。内部はスクリプトが色々動いているようで、Arduino IDEのステータス欄に色々動作状態が出てくる(Photo18)。


で、肝心の動作は? というと、最初ACを繋いだ状態だとLEDが微妙に点灯しているだけ(Photo19)だが、Sketchをロードするとちゃんと1秒間隔で点滅を繰り返す(Photo20)。で、USBケーブルを抜いても問題なく動作は継続する(Photo21)。問題はここで一度ACアダプタを抜いて、再度ACアダプタを接続した場合。Arduinoの場合だと、SketchはFlash Memoryに格納されるから、電源を入れればPower on bootでFlashからSketchが読み出され、再び勝手に実行を始める。ところがGalileoの場合はPhoto19の状態に戻ってしまうのだ。つまりGalileoのArduino互換モードでは、SketchはFlash MemoryではなくSRAMに格納されるようだ。先にSketchの最大サイズが256KBと書いたが、おそらくSRAMの半分をSystemで、残りをSketchで利用しているのだろう。


このあたりでArduino互換とは言え、使い方にちょっと制約が出てくる気がするが、それはさておきファイルサイズの話。同じSketchをArduino UNO用にビルドすると1,076Bytesである。アーキテクチャが違うとはいえ、何でここまでファイルサイズが違うのか? ということで、ちょっとバイナリを確認してみることにした。


Galileo向けのArduino IDEでは最終的にELFフォーマットでバイナリを生成するようだ。先のPhoto18にもちょっと出てくるが、Galileo用Arduino IDEは自動でユーザーディレクトリの下の方(詳しくはPhoto18を参照)にディレクトリを作り、その中にファイルを生成する(Photo22)。で、この中にある.elfファイルがGalileoにダウンロードされるものの様だ。そこでobjdumpを使って中身をちょっと確認してみた。まずobjdump -xでヘッダ情報を出したのがList 2である。ファイルフォーマットはelf32-i386なので、つまりこのSketchはGalileoでNativeで実行できるようになっていると考えられる。


■ List 2


んではobjdump -dでディスアセンブルするとどうなるか、をリスト全部掲載すると長すぎるので抜粋をList 3に。.initはもうファームウェアの初期化ルーチンを呼んでるだけだし、.pltは処理テーブルがひたすら並んでいるだけである。で、こまごましたものは.textに全部突っ込んであるが、明らかに今回の処理と無関係な関数のディスパッチルーチンまで含まれており、このあたりが無駄に突っ込まれている結果としてファイルサイズはかなり大きくなっていると考えられる(ちなみにobjdumpで -Sオプションをつけてもソースは表示されなかったので、g++でデバッグオプションは付加されていない模様)。


■ List 3


ただし、この結果として性能は猛烈に高い。以前chipKit32を比較したときのSketch(List 4)をそのまま実施してみたところ、


だった(以前Arduino Unoでは約11秒だったので大分遅くなってるのだが、Arduino IDEのバージョンが大分違うので、おそらくこれが影響しているのではないかと思う。ちなみに今回は1.0.5を利用)。これは81億回の足し算を500回繰り返すものだが、性能面では勝負にならないほどGalileoが高速だった。まぁ16MHz駆動の8bit MCUと400MHz駆動のPentium互換CPUで性能が同じでは話にならないので当然ではあるが、とりあえずArduino IDEで記述したSketchは、仮想マシンなどで動くのではない様である。まぁこれはこれで、ループなどでタイミング調整を行っているSketchでは問題が出てくるかもしれないが。


■ List 4


●互換性その他気がついたところ

○互換性その他気がついたところ


さて、一応Lチカが動いたところで、昔のArduino用の自作ShieldやSketchを動かしてみたところ、割といい感じで全滅した。というのは筆者の場合、PCと連携して何かの表示を行うようなSketchを自作するのがメインで、この際にPCとArduinoの間を仮想COMポート経由で通信する仕組みにしているのだが、Galileoだとこれがうまく動かなかった。おそらくはPhoto13に出てくるDCSG Validation Toolsの仕様が、Arduino Unoとかその前のArduino Duemilanoveで搭載されていたUSB-UART用ドライバと異なっているのだろう。プログラム的に見ると、COMポート(筆者の環境で言えばCOM18)をCreateFile()で開く事は出来るのだが、その後でGetCommState()で状態の取得をしようとしてコケている感じである。なので厳密に言えばGalileoの問題というよりはWindows用ドライバの問題なのであるが、そんな訳で手持ちのShieldの確認は今のところ出来ずじまいである。


あともう一つ気がついたのは、恐ろしくGalileoの発熱が多い事。普通、この手のマイコン開発ボードが熱くなる事は無い(というか、ありえない)のだが、Galileoはカイロの代わりになりそうな程度に熱い。まぁACアダプタが5V2A供給で10Wだから、これがフルに消費されているとすれば熱いのも当然ではある。発熱箇所は基板表と裏にある電源レギュレータ周りの部品(Photo06で、Quark X1000のすぐ左にあるやつ。中身はインダクタンス)で、これが表に2つ、裏に1つ搭載されているから熱いのも無理はない。ついでに言えばQuark X1000自体も触れないほど熱くなる。理由はなんとなくわかる、というかGalileoの場合、I/OデバイスをSoC内部で完結させきれず、I2Cなど経由でボード上に実装しているし、他にFlashだDDR3だと部品が色々乗っているから、こうしたもののために電源レギュレータが必要で、これによる発熱が馬鹿にならないのだろう。なるほどUSB Bus Powerでは動作しないのも無理ないし、仮にACアダプタを使わずにUSBを接続すると破壊されても不思議ではない。


なんというか、作りなれていない構造だなぁ、というのが率直な感想である。


○ということで


まずは簡単にファーストインプレッションをお届けした。ちなみに今回はBSPを使ってLinuxをブートする方は一切試していない。また電源Onからの自動Sketch実行も、もしかするとSD Cardを使えば可能かもしれない(マニュアルにそれらしき記述はある)が、これもまだ未テストである。


なんというか、いわゆるMCUベンダーの評価ボードのつもりで使うとあっという間に壊れそうな脆弱さを感じる部分はあるが、とりあえずちゃんと動く事が確認されたのは喜ばしい。USB周りについては、もう一つUARTが実装されているのでこちらを使っての接続とかも今後試してみたいと思う。


(大原雄介)