ArduinoのWiFiシールド(CC3000)でWiFiのセットアップ

ArduinoWiFiが使える、かつTELEC取得済みのCC3000 WiFiシールドを入手したので、セットアップしてみました。

まずはハンダ付け

スイッチサイエンスから購入したのですが、ブツがビニールに入ってるだけで特に説明書らしきものはありません。Arduinoシールドとはいえ、ピンソケットも付属していないので、一緒にピンソケットも購入しておいたほうがいいでしょう。

このようなWiFiシールドだとさらに重ねる可能性があるので、ピンソケットをこのようにハンダ付けしておきます。なおこのシールドはSPIを使用していますので、重ねる場合は注意して下さい。

f:id:tomo_watanabe:20140510204418p:plain

WiFiのセットアップ

WiFiのセットアップはsparkfunのページのCC3000 Hookup Guideを見ながら行えば問題ありません。

CC3000のライブラリのダウンロード

ライブラリのコードはGithubにありますが、リポジトリのmasterをココからzipファイルで落としてきて展開した方が楽です。落として展開したフォルダを「SFE_CC3000_Library-master」→「SFE_CC3000_Library」のようにちょっと修正して、ライブラリフォルダの中に放り込みます。Macだと~/Documents/Arduino/librariesになると思います。

WebClientで動作確認

ライブラリにファイルを置いたら、ArduinoIDEを起動します。動作確認はArduino Uno R3で行いました。

f:id:tomo_watanabe:20140510210119p:plain

ファイル→スケッチの例→SFE_CC3000_Library→WebClientでサンプルスケッチをオープンします(※Macの場合)

// Constants
char ap_ssid[] = "SSID";                  // SSID of network
char ap_password[] = "PASSWORD";          // Password of network
unsigned int ap_security = WLAN_SEC_WPA2; // Security of network
unsigned int timeout = 30000;             // Milliseconds
char server[] = "www.example.com";        // Remote host site

SSIDとPASSWORDの部分を、接続したいSSID名とパスワードに変更するだけです。serverは接続確認を行う先のURLです。このスケッチは起動時にクライアントのIPアドレスを設定して、"http://www.example.com/index.html"をGETで取ってくるようになっています。書き換えたらArduinoに書き込みます。書き込みが終ったらシリアルモニタを起動します。この時通信速度は115200に設定します。

正常にIPアドレスを取得し、www.example.comからデータを取得できると下記のようにGETで取得したログが流れます。

f:id:tomo_watanabe:20140510210750p:plain

このスケッチをベースにスケッチを書けば通常のEthernetと同じように使えるようになります。

SmartConfigを使ったセットアップ

このCC3000のウリは、スマートフォンSSIDとパスワードを設定できることのようなので、そちらも試してみます。

ファイル→スケッチの例→SFE_CC3000_Library→SmartConfigでサンプルスケッチをオープンします(※Macの場合)

ここでスマートフォンアプリを用意しておきます。iOS版とAndroid版があるのですが、iOS版はiTunesからダウンロードできるのに対し、Android版はなぜかTIにアカウントを登録してapkを自分でインストールする必要があります。今回はapkインストールするのが面倒だったので、iOS版でセットアップしましたが基本的には同じようです。

iPhone

  • SSID : 接続するアクセスポイント
  • Password : パスワード
  • Key : オプションなので特に設定する必要はありません

ここまで設定を入力したら、Aeduinoにスケッチを書き込んでシリアルモニタを起動します。Arduinoが起動すると"Starting SmartConfig"とメッセージが出たら、スマートフォンの"start"ボタンをタップします。成功すると、下記のようにsparkfunのサイトにpingを打って動作確認してくれます。

f:id:tomo_watanabe:20140510212737p:plain

うまく設定ができない(Arduinoタイムアウトする)と下記のようになります。スマートフォンのアプリの"start"のタイミングに気をつけてください

f:id:tomo_watanabe:20140510212928p:plain

FastConnect

SmartConfigでの設定は、毎回起動時にSSIDの設定しなければならず面倒ですが、実は一度SmartConfigでSSIDとパスワードを設定しておけば、CC3000内部に記憶されるので、このFastConnetが利用できるようになります。(電源を外しても記憶しているようなので、内部Flashに記憶しているのかな)

ファイル→スケッチの例→SFE_CC3000_Library→FastConnetでサンプルスケッチをオープンします(※Macの場合)

SmartConfigで設定済みなら、何の問題もなく下記のように動作するはずです。

f:id:tomo_watanabe:20140510213758p:plain

このSmartConfigは結構便利ですね。

netatmo ウェザーステーションを買ってAPIを叩いてみる

netatmo ウェザーステーションとは

netatmoウェザーステーション

公式HP ※公式のJPは死んでるっぽいので、USサイト

その名の通り気象情報をセンサーで取得するデバイスです。基本構成は2つのセンサーデバイスで、大きいほうが室内用、小さいほうが屋外用となっています。電源は室内用はUSBから、屋外用は単4電池2本で駆動します。それぞれのセンサーから取得できるデータは以下になります。屋外用のセンサーというのは実はありそうで無いので、ベランダなどに設置しておくと今の屋外気温が取得できるので面白いです。

  • 室内用

    • 気温
    • 湿度
    • 気圧
    • CO2
    • 騒音
  • 屋外用

    • 気温
    • 湿度

これを設置してユーザ登録してログインすると、PCではこんな画面でデータを見ることができます。

※地図の部分はボカしています

f:id:tomo_watanabe:20140501213157p:plain

ちなみに、全世界の今の気温もGoogleMap上でみることができます。クリック

また、iPhoneアプリAndroidアプリもあります。Androidではウィジェットに設定できるのでこれは便利!です。

f:id:tomo_watanabe:20140501214917p:plain

IFTTTと連携

このデータを元にIFTTTを使って連携しようと考えました。例えばこんな感じのレシピを作れます。

f:id:tomo_watanabe:20140501213757p:plain

これは「湿度が10%を切ったら、Tweetする」ということになります。とはいえ、本当にやりたかったのは「毎朝8時に、今の屋外の気温をTweetする」のようなことがしたかったのでこれはイマイチです。IFTTTではnetatmoウェザーステーションはトリガーにしか使えない、かつこの場合、3つの事象が含まれるのでIFTTTでは実現できません。

netatmoのAPIを利用

というわけで、netatmo APIを利用して作ることにしました。ここにアクセスして、「MY APPLICATIONS」を登録することでAPIを叩くことができるようになります。

APIの取得の仕方等はNetatmo ウェザーステーションを買ってみたので Node.js でいじってみたを参照して下さい。

今回はVPSを使わず、手元にあったRaspberry Piを使用して、下記のような構成を作ってみました。

結果

これはこれで簡単にできるので、もう少し色々連携させたくなってきました\(^o^)/ Raspberry Pi上でMQTTのブローカーを導入して、周辺デバイスと連携とか

Mosquitto(MQTT)を動かしてみた

MQTTとは

MQTT(MQ Telemetry Transport : MQはMessage Queuing?)というプロトコルで、TCP/IP層で動作するWebSocketっぽいもの(ザックリ)。詳しくはそこはかとなく書くよん。を見てもらった方が分かりやすいです。簡単に言えば、M2Mでの使用を考えた軽量なメッセージプロトコルという感じです。Mosquittoはブローカの実装で使用します。

2013年のカンファレンスでは、2011年当時の「Beluga」(現Facebook Messenger)に使われているという発表があったようです

MQTTのブローカとクライアントの動作確認の構成

今回下記のような構成でMQTTの動作確認を行いました。

  • ブローカ(サーバ):Mosquitto
  • クライアント:Paho Python版クライアント

f:id:tomo_watanabe:20140418232239p:plain

Mosquittoにsub.pyで接続し、pub.pyによってpublishされるとsub.py側に出力されることを確認します。

Mosquitto(ブローカ)のインストール

パッケージからインストール

Ubuntuでは基本的にはパッケージインストールができるので

$ sudo apt-get install mosquitto

以上でインストールと起動まで完了します。停止・再起動はserviceコマンドで行えます。

ソースからコンパイルする場合

開発環境のインストール

$ sudo apt-get install gcc make g++ libssl-dev libc-ares-dev

Mosquittoのダウンロードページからソースを落として展開し、makeしてインストールします。

$ wget http://mosquitto.org/files/source/mosquitto-1.3.1.tar.gz
$ tar -xvzf http://mosquitto.org/files/source/mosquitto-1.3.1.tar.gz
$ cd mosquitto-1.3.1
$ make
$ sudo make install

環境設定ファイルを設定します。

$ sudo cp /etc/mosquitto/mosquitto.conf.example /etc/mosquitto/mosquitto.conf

デフォルトでMQTTは1883ポートを使用します。必要に応じてサーバのポートを開放します。

起動します。

※引数なしの起動方法では前述のconfファイルは使われず、デフォルトで起動します。-cオプションでファイルを指定する必要がありますが、何も修正していなければ動作はデフォルトとなります。

$ mosquitto
1397719018: mosquitto version 1.3.1 (build date 2014-04-17 15:13:13+0900) starting
1397719018: Using default config.
1397719018: Opening ipv4 listen socket on port 1883.
1397719018: Opening ipv6 listen socket on port 1883.

この場合、サーバがIPv4/6両対応なので、ポートそれぞれでリッスンしている状態になります。

PahoクライアントでPub/Subを実行する

Pahoの下の方に各言語用のダウンロードリンクがありますので、そこからcloneしてきて利用するのがいいのと思います。今回はPythonクライアントのexampleを少し修正してsub.pyとpub.pyを作成しました。

paho MQTT pythonライブラリのインストール

$ sudo pip install paho-mqtt

sub.pyの実行

詳しい解説は後回しにしてまずは実行してみましょう。まずは待ち受けのsub.pyを実行しておきます。

コードはsub.pyにあります。

起動して、ブローカサーバに接続するとこのようなメッセージになります。

$ python sub.py
rc: 0
Subscribed: 1 (0,)

ブローカサーバへの接続が失敗した場合こんなメッセージが出ます。

Traceback (most recent call last):
  File "sub.py", line 60, in <module>
    mqttc.connect("HOST", 1883, 60)
  File "/Library/Python/2.7/site-packages/paho/mqtt/client.py", line 588, in connect
    return self.reconnect()
  File "/Library/Python/2.7/site-packages/paho/mqtt/client.py", line 710, in reconnect
    self._sock = socket.create_connection((self._host, self._port), source_address=(self._bind_address, 0))
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py", line 571, in create_connection
    raise err
socket.error: [Errno 61] Connection refused

接続に成功していればブローカサーバ(Mosquitto)の方では以下のようなメッセージが表示されているはずです

1397719236: New connection from 2001:3e0:0:*:*:*:*on port 1883.
1397719236: New client connected from 2001:3e0:0:*:*:*:* as paho/E917914937EA634F0F (c1, k60).

一部"*"でマスクしています。

pub.pyの実行

次にpub.pyを実行して、メッセージを送信します。

コードはpub.pyにあります。

コンソールをもう一つ開いてpub.pyを実行すると直ぐに終了します。

$ python pub.py
1

sub.pyの出力の方を見てみると、1行メッセージが追加されていると思います。

rc: 0
Subscribed: 1 (0,)
message 0 Hello MQTT!

pub.pyを実行することにより、subscribeしていたsub.pyの方にメッセージ送信が行われたことがわかります。

解説

sub.pyの方から見ていきます。(以下抜粋)

# メッセージを受信した時に呼ばれる。
def on_message(mqttc, obj, msg):
    print(msg.topic+" "+str(msg.qos)+" "+str(msg.payload))

# 接続先のブローカを設定する
mqttc.connect("HOST NAME", 1883, 60)
# "message"というtopicをsubscribeする
mqttc.subscribe("message", 0)

sub.pyは起動すると"message"というtopicが来るまで待機状態になります。pub.pyを実行して。メッセージを受信すると、topicとqosとpayloadを表示します。今の場合は

  • topic : message
  • qos: 0
  • payload : Hello MQTT!

pub.pyの方はこれだけですね。

publish.single("message", "Hello MQTT!", hostname="HOST NAME")

"message"というtopicに"Hello MQTT!"を送信しています。qosは省略されていますが、デフォルトが0になっています。今回は簡単にするためにtopcを"message"としましたが、これを"$SYS/#"のようにワイルドカードで指定したり、"paho/test/single"のようにすることもできます。この指定の仕方はMQTTの仕様のようで、これを利用して各々のM2M機器がsubscribeする対象を設定できるようになっています。

まとめ

MQTTを実動作させるテストを行いました。MQTTの実装はLinuxMacだけでなく、mbedやArduinoAndroidなどにもありますし、様々な言語での実装もあります。またNode.jsでWebSocketと組み合わせてブラウザへの出力もできます(この辺は後日)僕はこのM2M用途としてのMQTTはよく知らなかったのですが、実際使用してみると結構いろいろなことが出来そうな気がします。プロトコルはシンプルだし、QoSの概念が導入されているのも面白い点です。

スキーとGoProとウェアラブルの関係を考える

初めての趣味でのエントリになります。

今シーズンは週末に冬山に行くことが多いです。スタッドレス買ったので勿体無いというのもありますが。一昨年にGoPro Hero2(今はHero3)を買ってからスキーの時に持参して撮影をしてみたりしてるので公開してみようと思います。

GoProのアタッチメントはヘッドストラップでこんな感じ

f:id:tomo_watanabe:20131230091507j:plain

まずは動画を公開。場所はオグナほたかスキー場のゲレンデトップから第6ペアリフト沿いのコースを滑ってます。1本目は割りとゆっくりめでウェーデルンで速度を調整しています。2本目は同じ小回りですが、こちらはずらさずカービングターンでスピードを殺さずに滑っています。違いがわかるでしょうか?

ウェーデルンで滑走

カービングで滑走

撮影した斜面を下から見るとこんな感じ。最大斜度は約20度ちょっとくらい

f:id:tomo_watanabe:20140201100208j:plain

GoProとは

GoProは今は「アクションカメラ」というジャンルを確立した「デジタルカメラの派生」で、JVC・ケンウッドソニーが対抗機種を投入して盛り上がっています。GoProの成功に関してはこちらの記事アクション・カメラの代名詞「GoPro」誕生秘話が創業者へのインタビュー映像で明らかに

個人的にGoProの登場時に凄いなと思ったのは

  • LCDレスなどの従来のデジカメにあった機能レスの割り切り
  • 広角でかつ、映像自体がかなり綺麗に取れる
  • 天候に左右されないレンズ性能とハレーションの少なさ(逆光でも白飛びしない)
  • 各シーンに合わせたアタッチメント

購入してから性能的には満足していますが、一方でいくつか不満点もあります(ただしHero2に限る)

  • 電池持ちが悪い。8GBのSD差しても意味ない...(´・ω:;.:...
  • ボタンの反応がわかりづらい。音がするものの、もうちょっとなんとかならんの・・・
  • 手ぶれ補正が欲しい(スキー動画揺れすぎ)

ウェアラブルデバイス

自分が思うにGoProは「ウェアラブルデバイス」です。スポーツという制限化の中で、身に付けることによって従来撮れなかった映像を撮れるのです。スキーの場合は両手が塞がっているので、こういう場合に非常に便利です。

ウェアラブルに必要な要素として

  • 必然性
  • ファッション性

だと思いますが、GoProは「スポーツという制限化での必然性」があります。この例はGoogle Glassが遠隔手術に使われたり(Google Glassで手術をライブ中継、教育効果に期待:米大学病院)、Kinectが手術の病巣カルテをジェスチャーで操作する(Opect)どちらも必然性があって、制限化での活用が非常に有効です。またどちらも一般の人にとっての日常ではなく、非日常な利用です(Google Glassの発表の時は飛行機からパラシュートで飛び降りてくるというアクションカメラ的デモであって、実はなんの日常的な必然性は無い...)

一方で我々がウェアラブルとして身につけているものは

  • 眼鏡
  • 腕時計
  • 指輪・ネックレス
  • 帽子・手袋

どれも今は必然性よりもファッション性が重要視されている製品です。眼鏡は目が悪い人にとっては必然ですが、ファッション性が重視されてますし、腕時計は昔は正確な時間を知ると言う意味で必然性がありましたが、今はファッション性の方が高いですね。指輪は元来、魔除けや魔力を身につけるといった必然性から生まれたもののようです。帽子・手袋は防寒の必然性もありますがファッション性もあります。

ウェアラブルデバイス百花繚乱の昨今ですが、ウェアラブルは「必然性」ありき、後「ファッション化」するのものではないのでしょうか?今のところ「日常の必然性」を具現化したウェアラブルデバイスは難しいのでは?と考えています。自分としては「非日常シーンでの必然性」を具現化した「面白いウェアラブルデバイス」が出てくることを期待しています。

Node.js + Socket.IO + pm2でデーモン化とクラスタリング

Socket.IOをpm2でクラスタリングするには、ちょっと工夫が必要だったのでメモ

forever

Node.jsのデーモン化といえばforeverです。しかしクラスタリングしようとすると、Node.jsのコードをクラスタリング対応で書かないといけないのでやや面倒だったりします。今回、foreverよりも高機能なpm2を使ってクラスタリングを試してみました。

pm2

pm2はforeverと同じようにNode.jsをデーモン化するツールですが、モニタ機能やクラスタリング機能などかなり高機能になっています。

pm2のインストール

pm2はグローバルでインストールします。

$ npm install -g pm2

対応するNode.jsのバージョンは古いと動かないかもしれません。今回はv0.10.20(on Mac)で動作確認しました。動かすNode.jsアプリはこちらのSocket.IOのサンプルアプリです。このコードだとSocket.IOのバージョンが古いようなので、一旦npm uninstall socket.ioして、再度npm install socket.ioで再インストールしました。

pm2を使ってクラスタリング

$ pm2 start app.js -i max

として起動するとプロセスがCPUコア数分だけ起動し、クラスタリングされます。簡単ですね。起動リストを表示させるには

$ pm2 list

f:id:tomo_watanabe:20140131120059p:plain

プロセスが4つ起動されているのがわかります。この時にブラウザでアクセスして確認します。

f:id:tomo_watanabe:20140131120326p:plain

片方がxhr-pollingになってたりしますね。これリロードするとwebsocketになったり、xhr-pollingになったりなんとも不安定になります。

ログを表示するには

$ pm2 logs

f:id:tomo_watanabe:20140131120712p:plain

ところどころに警告がでています。

warn  - client not handshaken client should reconnect

調べてみるとSocket.IOの接続に起因するものでSocket.IO or WebSocket を AmazonELB でバランスする検証にありました。

つまり、 Socket.IO は接続確立までに 2 回リクエストを投げるということです。 そしてこの最初の要求と、 WS の接続要求は、「同じインスタンス」にアクセスする必要があります。 二つの接続がバランスされて別々のサーバに行くと、ハンドシェイクがエラーになり、リトライが発生します。 たまたま二回同じサーバにいけば、接続が確立できるので、バランスするサーバが増えるほど成功確率が減 り、確立までの時間が長くなります。

redisの導入

解決策としてredisをセッションキーストアとして利用する、ということのようです。今更だけどSocket.ioについてまとめてみる

redisのPub/Subを利用して、各プロセス間でセッション共有をするということです。

このサイトの記事のとおりなのですが、ひと通りメモ

redisのインストールと起動

$ brew install redis
$ redis-server /usr/local/etc/redis.conf &
[1] 3234
$ [3234] 31 Jan 11:29:03.112 * Max number of open files set to 10032
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 2.8.1 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in stand alone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 3234
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

[3234] 31 Jan 11:29:03.113 # Server started, Redis version 2.8.1
[3234] 31 Jan 11:29:03.113 * The server is now ready to accept connections on port 6379

redisのpub/sub機能

redisにはpublisher/subscriberという機能があって、いずれかのプロセスが受けた通知をredisに設定することで、他のプロセスに通知を行い共有できるということです。この機能を使うことでクラスタリングされたプロセス間でセッションの共有を行えます。

サーバアプリの書き換え

app.jsを以下のように書き換えます

var app = express()
    , server = http.createServer(app)
    , redis = require('socket.io/lib/stores/redis')  // socket.ioにredisがある
    , redisConf = { host: '127.0.0.1', port: 6379 }
    , io = require('socket.io').listen(server);

// storeタイプをredisに変更
io.set('store', new redis({
    redisPub: redisConf,
    redisSub: redisConf,
    redisClient: redisConf
}));

pm2でクラスタリング

再びpm2でクラスタリングを試してみます。

$ pm2 start app.js -i max

この時のアクセスログを見ると警告が無くなり、かつ正常にクラスタリングされているようです\(^o^)/

f:id:tomo_watanabe:20140131120626p:plain

モバイル版ChromeのSPDYプロキシはIPv6に対応

モバイル版のChrome正式にSPDYに対応しました。

たまたま実験してて気づいてたのですが、SPDYプロキシはIPv6に対応しているようです。

実験

グローバルなIPv6が振られているMac上でサーバアプリを起動して、IPv6でアクセスできるようにします。今回はNode.jsを使ったサーバアプリを起動しておきます。また、アクセスしてきたIPアドレスをログで表示できるようにしておきます。

IPv6でアクセスできるようにするには、Node.jsでlistenを下記のように書いておきます。

server.listen(3000, '::');

PC版Chromeでアクセス

IPv6指定でアクセスすると、このように接続されます。これはまあ普通です。

f:id:tomo_watanabe:20140120125629p:plain

Node.jsのログでIPアドレスを確認してみます。同じマシンからアクセスしてるので同じIPv6アドレスです。

f:id:tomo_watanabe:20140120130136p:plain

AndroidChromeでアクセス

AndroidChromeでSPDYをON(帯域幅の管理→データ使用量を節約)でアクセスしてみます。

f:id:tomo_watanabe:20140120130720p:plain

同じようにアクセスできました。この時のアクセスログを見てみると

f:id:tomo_watanabe:20140120130845p:plain

謎のIPv6アドレスからアクセスが来ていますね。これを調べてみます。

f:id:tomo_watanabe:20140120162437p:plain

どう見てもGoogleさんです。本当にry

ちなみにSPDYをOFF(データ使用量を節約しない)に設定すると

f:id:tomo_watanabe:20140120131721p:plain

このようにアドレス解決できません(今まではこうだった)

追試

IPv6アクセスの確認サイトである「The KAME project」にアクセスしてみます。 このサイトのIPv6アドレスは「2001:200:dff:fff1:216:3eff:feb1:44d7」です。

モバイル版ChromeでSPDY ONで「http://www.kame.net/」へアクセス(IPv4)と「http://[2001:200:dff:fff1:216:3eff:feb1:44d7]」(IPv6)へそれぞれアクセスしてみてください

亀が泳いでいればIPv6でアクセスしていることになります。IPv6アドレスでアクセスした場合には亀が泳いでいるのが確認できると思います。

f:id:tomo_watanabe:20140120133300p:plain

まとめ

Android端末で僕が契約しているdocomo XiのLTEでは端末にはIPv6は割り当てられず、IPv4アドレスしか振られません。なので普通にURLを入れるとIPv4でのアクセスになります。しかしIPv6アドレスを直打ちすることで、SPDYプロキシがIPv6へのアクセスを可能にしていることがわかりました。

ただし、PCからのアクセスだとWebScoketで接続できますが、SPDY経由だとxhr-pollingになるのでWebSocketのプロキシには対応していないようです...

追記:httpsアクセスはSPDYプロキシは通ってないようですね(まぁそうか)

Intel Galileoはじめの一歩

やっとIntel Galileoが来たので、とりあえず最初にやっておくことひと通り

f:id:tomo_watanabe:20140119182300j:plain

ファームウェアのアップデート

まずはファームウェアのアップデートをやっておかないとならないのですが、いきなりここでハマりました。3回くらいファームのアップロードをやってやっと成功。やり方がまずかったかもしれませんが、シリアルポートがハングアップすることがありました。

アップデートはなぜかGalileo用のArduino IDEから行います。まずはここからマシン環境にあったIntel Galileo Arduinoを落としてインストールします。いわゆる通常のArduino IDEは使用できないので注意です。Macの場合はドライバは必要ないようです。

起動したら設定を行う

Macの場合、どうやらここで「tty.XXX」ではなく、「cu.XXX」を選択しないとダメなようです。僕は最初「tty.XXX」を指定してやったらハングアップしました(^_^;)

f:id:tomo_watanabe:20140119181238p:plain

f:id:tomo_watanabe:20140119181248p:plain

さてファームウェアのアップデートを行います。ヘルプから「Firmware Update」を選択します。

f:id:tomo_watanabe:20140119181506p:plain

こんな感じで警告がでます。ACアダプタをちゃんと挿しておきましょう。

f:id:tomo_watanabe:20140119181610p:plain

OKを押すとファームウェアのアップデートが開始されます。

f:id:tomo_watanabe:20140119181712p:plain

途中5分くらい掛かるよ。というメッセージに変わり、終了すると終了メッセージが出ます(スクショ忘れ)ちなみに実際には5分以上掛かっていました。かつ、アクセスランプの点滅等が無いので、ほぼ進行状況が掴めないという優しくない仕様・・・

(僕は最初tty.XXXを選択していたためか、ここで10分ほど放置した結果、ハングアップしてると判断して電源引っこ抜きました・・・)

Lチカで動作確認

ファームウェアのアップデートが完了したら、サンプルのLチカを実行してみます。Arduinoのメニューから「Blink」を選択して、ビルド・ダウンロードするだけです。

f:id:tomo_watanabe:20140119182605p:plain

手前のグリーンのLEDがチカチカと点滅すればOKです

f:id:tomo_watanabe:20140119182451j:plain

まとめ

まずはここまでやっておけば、あとはArduinoで何かすれば普通にできそうです。とはいえ、ただのArduino互換で使うには勿体無いというか、これ一応Quarkの開発ボードなので、メインはLinux動かしてなにかやる方だと思いますが。しかしこのQuarkチップは熱持ちすぎですね。触ると数秒で手を離すレベルです。これではCES2014で発表したIntel Edisonは熱とか大丈夫なんでしょうか?この発熱だととてもIoT用のチップとしては使えない気が・・・(´ε`;)ウーン…

とりあえず次は手元にあるArduinoシールド動かしてみるかな...