Blog名更新後の初エントリ(久しぶり・・)は、Intel Galileoです。昨年スイッチサイエンスさんに予約して、1月15日に無事届きました。ArduinoとLinuxの共存やIntelの組み込み(IoT)向けプロセッサQuark SoC X1000搭載など、なかなか興味深い製品で、発売即ゲットしてしまいました。
まだ、LチカとLinux環境にちょっと触った程度ですが、気がついたことを書いてみます。
パッケージ構成
本体とACアダプタ(各国対応のプラグ付き)というシンプルな構成。
量産品発売前のレビュー記事(マイナビさんとか)だと、マスコット人形・箱を開けたときのオルゴール・USBケーブル・基板スタンド用アダプタが添付とありましたが、量産版では削除されています。USBケーブルや基板スタンドは手持ち品があるので、Arduino(DIY)の精神としては余計なものは付けないほうが私的には好ましいです。でも、オルゴールは聴いてみたかった・・・ 電源は、5V/2AのACアダプターで(USBからの給電は不可。ボードが壊れると、恐ろしいことがマニュアルに書いてあります)、2Aの手持ち品もあるのですが、こちらは添付の純正品を使っています。

(左側はMFTのIntelブースでもらったポストイット)
ハードウェア構成
Arduinoシールド互換とするために、5V GPIO/PWM, ADCが乗っていますが、Quark SoC X1000の機能は使わず、I2C経由の外付けのチップで対応しています。GPIOはQuarkにも搭載されているようにデータシート上見えますが、敢えて外付けチップ経由になっています。恐らく、5V/PWM対応がQuark内臓のGPIOではできないためと思われますが、GPIOが100KHz動作のI2C経由なので、GPIOのトグル周期は230Hz程度とオリジナルのArduinoより遅そうです(比べた訳ではないですが)。そのため、表示用のLCDも従来の4bitパラレルよりI2Cで直接接続した方が効率がよいかも知れません。
CPUが熱くなるとマイナビさんのレビュー記事にありますが、Linux環境を起動して温度センサーの値を調べてみるとこんな感じ:
□CPU温度の確認
# cat /sys/class/thermal/thermal_zone0/temp
- Quark SoC X1000 : 69℃~72℃程度
- RaspberryPi : 44℃程度
確かに、この手の組み込みチップとしては熱いと思います。マイナビさんのレビューでは、電源のチップ周りが熱くなるという記述もありましたが、自分の固体はCPU以外は殆ど熱くならないので量産版では改善されたのかも。
オンボードに8MB Flashが搭載されており、通常はこのFlashからLinuxをブートしてLinux上でArduinoスケッチを動かします。スケッチ用には、Quark SoCオンチップの512KB SRAMの約半分が割り当てられているみたい。512KB SRAM以外にもLinuxを動かす256MB DDR3 DRAMが搭載されています。
ソフトウェア構成
専用IDEを使ってスケッチを作成します。Macにインストールする際の注意点としてアプリケーションフォルダーにDLしたファイルを置くだけですが、appファイル名にスペースを入れてはいけません。私は、当初Arduino用のIDEと区別したかったため、”Arduino Galileo”とスペースありの名前で登録したのですが、一番最初に行うファームウェアのアップデートでエラーが発生し、はまりました(エラーメッセージでググったところ、Intelのサポートフォーラムで解決策が見つかった次第)。
オンボードのFlashから起動した場合、電源を落とすとスケッチも消えてしまい、再アップロードが必要です(スケッチはSRAMに直接書き込まれる模様)。もう一つの起動方法として、MicroSDカードにIntelが提供しているLinuxイメージを書き込んでブートすることができます。この場合、スケッチはMicroSDカードの/sketch/sketch.elfに書き込まれるため、電源を切っても再投入時自動実行されます。
オンボードFlashからブートした場合、Linuxのコマンド操作を行うためにはピンジャックのシリアルケーブルをPCに接続する必要があるようです。このピンジャック3.3V TTLでなく、RS232C (±12V?)で信号が出ているため、直接FT232等のUSB-シリアル変換に接続できません。自作も面倒なので、スイッチサイエンスさんからアクセサリとして接続ケーブルが発売されるのを待ちます。MicroSDカードからLinuxをブートした場合は、宅内ルーターからDHCP経由で割り当てられたIPアドレスを調べることによってssh経由でLinuxにアクセスできるため(ひとりブログさんの記事を参照)、この方法でLinuxに触っています。
MicroSDからブートした場合、Arduinoのスケッチ(sketch.elf)はLinuxの一プロセスとして実行されているように見えます。(下記ps出力の41行目)
root@clanton:/# ps
PID USER VSZ STAT COMMAND
1 root 796 S init [5]
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [kworker/0:0]
5 root 0 SW< [kworker/0:0H]
6 root 0 SW [kworker/u:0]
7 root 0 SW< [kworker/u:0H]
8 root 0 SW< [cpuset]
9 root 0 SW< [khelper]
10 root 0 SW [kdevtmpfs]
11 root 0 SW< [netns]
12 root 0 SW [kworker/u:1]
119 root 0 SW [bdi-default]
121 root 0 SW< [kblockd]
200 root 0 SW [kworker/0:1]
329 root 0 SW [kswapd0]
384 root 0 SW [fsnotify_mark]
396 root 0 SW< [crypto]
526 root 0 SW< [deferwq]
529 root 0 SW [mmcqd/0]
777 root 0 SW< [kworker/0:1H]
937 root 0 SW< [loop0]
938 root 0 SW [kjournald]
1002 root 0 SW [khubd]
1058 root 0 SW [irq/61-0-0020]
1100 root 0 SW [spi0]
1103 root 0 SW [spi1]
1133 root 0 SW< [cfg80211]
1277 root 1264 S udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i eth0
1297 messageb 1464 S /usr/bin/dbus-daemon --system
1305 root 3256 S /usr/sbin/sshd
1320 root 1264 S /sbin/syslogd -n -O /var/log/messages
1322 root 1260 S /sbin/klogd -n
1326 root 1264 S /sbin/getty 115200 ttyS1
1327 root 1264 S /sbin/getty 38400 tty1
1328 root 768 S /opt/cln/galileo/galileo_sketch_reset -v
1329 root 1856 S {clloader.sh} /bin/sh /etc/init.d/clloader.sh
1443 root 876 S /opt/cln/galileo/clloader --escape --binary --zmodem --di
1452 root 18292 S /sketch/sketch.elf /dev/pts/0 /dev/ttyS0
1455 root 3316 R {sshd} sshd: root@pts/1
1457 root 1944 S -sh
1463 root 1264 R ps
MicroSD用に提供されているLinuxの機能はミニマムです。コマンドファイルは以下のようにBusyBoxを使って小型化されており最小限。gccやパッケージアップデートの機能もありません。そのため、RaspberryPiのようにLinux環境での開発は難しく、当面はArduino環境での開発が主体になりそうです。
root@clanton:/# ls -la /sbin
drwxr-sr-x 2 root root 2048 Sep 30 2013 .
drwxr-xr-x 18 root root 1024 Jan 1 00:57 ..
lrwxrwxrwx 1 root root 12 Sep 30 2013 acpid -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 arp -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 blkid -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 blockdev -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 bootchartd -> /bin/busybox
-rwxr-xr-x 1 root root 12668 Sep 30 2013 bootlogd
lrwxrwxrwx 1 root root 12 Sep 30 2013 depmod -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 fdisk -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 findfs -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 fsck -> /bin/busybox
-rwxr-xr-x 1 root root 3944 Sep 30 2013 fstab-decode
lrwxrwxrwx 1 root root 12 Sep 30 2013 getty -> /bin/busybox
lrwxrwxrwx 1 root root 19 Sep 30 2013 halt -> /sbin/halt.sysvinit
-rwxr-xr-x 1 root root 12168 Sep 30 2013 halt.sysvinit
lrwxrwxrwx 1 root root 12 Sep 30 2013 hwclock -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 ifconfig -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 ifdown -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 ifup -> /bin/busybox
lrwxrwxrwx 1 root root 19 Sep 30 2013 init -> /sbin/init.sysvinit
-rwxr-xr-x 1 root root 31268 Sep 30 2013 init.sysvinit
lrwxrwxrwx 1 root root 12 Sep 30 2013 insmod -> /bin/busybox
-rwxr-xr-x 1 root root 78556 Sep 30 2013 iwconfig
lrwxrwxrwx 1 root root 8 Sep 30 2013 iwgetid -> iwconfig
lrwxrwxrwx 1 root root 8 Sep 30 2013 iwlist -> iwconfig
lrwxrwxrwx 1 root root 8 Sep 30 2013 iwpriv -> iwconfig
lrwxrwxrwx 1 root root 8 Sep 30 2013 iwspy -> iwconfig
-rwxr-xr-x 1 root root 14972 Sep 30 2013 killall5
lrwxrwxrwx 1 root root 12 Sep 30 2013 klogd -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 loadkmap -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 logread -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 losetup -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 lsmod -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 mdev -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 modprobe -> /bin/busybox
-rwxr-xr-x 1 root root 3456 Sep 30 2013 nologin
lrwxrwxrwx 1 root root 12 Sep 30 2013 pivot_root -> /bin/busybox
lrwxrwxrwx 1 root root 23 Sep 30 2013 poweroff -> /sbin/poweroff.sysvinit
lrwxrwxrwx 1 root root 13 Sep 30 2013 poweroff.sysvinit -> halt.sysvinit
lrwxrwxrwx 1 root root 21 Sep 30 2013 reboot -> /sbin/reboot.sysvinit
lrwxrwxrwx 1 root root 13 Sep 30 2013 reboot.sysvinit -> halt.sysvinit
lrwxrwxrwx 1 root root 12 Sep 30 2013 rmmod -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 route -> /bin/busybox
lrwxrwxrwx 1 root root 23 Sep 30 2013 runlevel -> /sbin/runlevel.sysvinit
-rwxr-xr-x 1 root root 3472 Sep 30 2013 runlevel.sysvinit
lrwxrwxrwx 1 root root 12 Sep 30 2013 setconsole -> /bin/busybox
lrwxrwxrwx 1 root root 23 Sep 30 2013 shutdown -> /sbin/shutdown.sysvinit
-rwxr-xr-x 1 root root 18260 Sep 30 2013 shutdown.sysvinit
lrwxrwxrwx 1 root root 12 Sep 30 2013 start-stop-daemon -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 sulogin -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 switch_root -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 sysctl -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 syslogd -> /bin/busybox
lrwxrwxrwx 1 root root 4 Sep 30 2013 telinit -> init
lrwxrwxrwx 1 root root 12 Sep 30 2013 udhcpc -> /bin/busybox
lrwxrwxrwx 1 root root 12 Sep 30 2013 vconfig -> /bin/busybox
lrwxrwxrwx 1 root root 17 Sep 30 2013 vigr -> /sbin/vigr.shadow
lrwxrwxrwx 1 root root 11 Sep 30 2013 vigr.shadow -> vipw.shadow
lrwxrwxrwx 1 root root 17 Sep 30 2013 vipw -> /sbin/vipw.shadow
-rwxr-xr-x 1 root root 39808 Sep 30 2013 vipw.shadow
lrwxrwxrwx 1 root root 12 Sep 30 2013 zcip -> /bin/busybox
CPU発熱の考察
Arduinoのスケッチはloopの部分で無限ループを廻すので、そのためCPU使用率が高いのではないかと思い、調べてみました。Lチカスケッチを動かした状態でtopコマンドを動かすとCPU使用率は以下の通り。全体のCPU使用率が3%で、sketch.elfのCPU使用率は0%です。ですので、スケッチの無限ループによるCPU使用率の高騰はないです。
Mem: 42132K used, 191680K free, 0K shrd, 1868K buff, 27688K cached
CPU: 0% usr 1% sys 0% nic 97% idle 0% io 0% irq 0% sirq
Load average: 0.00 0.02 0.05 2/45 1478
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1478 1464 root R 1268 1% 1% top
1455 1305 root S 3316 1% 1% {sshd} sshd: root@pts/1
200 2 root SW 0 0% 0% [kworker/0:1]
1452 1443 root S 18292 8% 0% /sketch/sketch.elf /dev/pts/0 /dev/ttyS0
1305 1 root S 3256 1% 0% /usr/sbin/sshd
1464 1457 root S 1944 1% 0% bash
1457 1455 root S 1944 1% 0% -sh
1329 1 root S 1856 1% 0% {clloader.sh} /bin/sh /etc/init.d/clloader.
1297 1 messageb S 1464 1% 0% /usr/bin/dbus-daemon --system
1320 1 root S 1264 1% 0% /sbin/syslogd -n -O /var/log/messages
1326 1 root S 1264 1% 0% /sbin/getty 115200 ttyS1
1327 1 root S 1264 1% 0% /sbin/getty 38400 tty1
1277 1 root S 1264 1% 0% udhcpc -R -n -p /var/run/udhcpc.eth0.pid -i
1322 1 root S 1260 1% 0% /sbin/klogd -n
1443 1329 root S 876 0% 0% /opt/cln/galileo/clloader --escape --binary
1 0 root S 796 0% 0% init [5]
1328 1 root S 768 0% 0% /opt/cln/galileo/galileo_sketch_reset -v
937 2 root SW< 0 0% 0% [loop0]
6 2 root SW 0 0% 0% [kworker/u:0]
3 2 root SW 0 0% 0% [ksoftirqd/0]
529 2 root SW 0 0% 0% [mmcqd/0]
777 2 root SW< 0 0% 0% [kworker/0:1H]
10 2 root SW 0 0% 0% [kdevtmpfs]
12 2 root SW 0 0% 0% [kworker/u:1]
938 2 root SW 0 0% 0% [kjournald]
2 0 root SW 0 0% 0% [kthreadd]
5 2 root SW< 0 0% 0% [kworker/0:0H]
119 2 root SW 0 0% 0% [bdi-default]
121 2 root SW< 0 0% 0% [kblockd]
4 2 root SW 0 0% 0% [kworker/0:0]
396 2 root SW< 0 0% 0% [crypto]
じゃあなぜ熱いのかと言うと、パワー・マネジメント機能がちゃんと動いていない、もともと消費電力が高めということかと思います。
Quark SoC X1000のデータシートを見ると、Power Management Stateとして以下をサポートしています:
- S0: Full On
- S3: Suspend to RAM (Standby)
- S4: S4 - Suspend to Disk (Hibernate)
S3以降はCPUが完全に停止してしまうためスケッチ実行中に遷移することはないと思います。ですので、通常S0ステートで動き続ける訳ですが、AtomのようにS0を細分化してS0内に省電力モードを設けるような機能はQuarkにはありません。
Sステート以外に、ACPIアイドルステートして以下があります:
- C0: Active mode, processor executing code
- C1: AutoHALT state
- C2: Stop Grant state
PCのACPIでは、アイドル時OSがHALT命令を発行してCPUをC1ステートに落とすようなことやってませんでしたっけ?だとすると、GalileoのLinuxはACPIが動いておらず、アイドル時もCPUクロック周りがフル回転していることになります。
70℃程度でCPUが壊れることはないと思いますが、消費電力や発熱的には組み込みやIoT向けには今一な感じがします。
参考文献
最近のコメント