ESP8266対応のArduino IDEをビルドしてみた

先に紹介したESP8266対応のArduino IDEですが、GitHubにはなぜかLinuxの32bit版が存在しません。

そこで、ビルドしてみました。
環境は Ubuntu 14.04 LTS 32bit 版、CPUはCeleron847です。

結論から言うと、ビルドするだけなら非常に簡単です。(ビルドするだけなら、ですけどね)
手順は単にドキュメントに書かれているとおりです。

まず、

で、一式持ってきます。ここでダウンロードする量は1GBを超えるので、一体ビルドするのにどんなにかかるんだろう、と不安になります。

でビルドします。1回目は「JDKがない」と言われて失敗してしまいました。
そこで、synapticで「default-jdk」をインストールして、再度、

としてみました。すると、何やらさらに大量にダウンロードしていますので、一晩二晩くらいビルドにかかるんだろうか、と放置して寝ました。

しかし、起きてみると、最後に、

として完了していました。表示を信じるなら10分弱で完了しています。

いざ起動ですが、GitHubには起動方法は書かれていません。
で、ぐぐってみると本家(?)のArduinoのビルド方法の説明が見つかりました。
こちらを参考に、

$ ant run

とすると、少し経って arduino IDE が起動しました。

・・・が、ビルドしようとすると、g++が見つけられないようでエラーになってしまいます。しかし、すでにxtensa用のg++はビルド済みなので、

としてリンクを張ってやるとコンパイルは通るようになりました。・・・が、こんどは esptools ディレクトリがないと言ってエラーになるので、

として、リンクを張りました。・・・が、それでもまだエラーが出ます。

切り分けるため、

として起動してやると、ビルドが通りました。
・・・・が、通常起動ができなくなってしまいました。パーミッション周りでまだいろいろあるようです。

とすると起動はできましたが、シンボリックリンクが消失しているのか、また振り出しに戻ってしまいます。

まあ、ここまでやるんなら、素直にOSを64bit版Linuxにした方がいいような気がします(^^;

esp8266用の環境を構築する(続き)

ESP8266用の環境構築の続きです。

7.MicroPythonをビルドしてみる

ExampleはMakefileが複雑すぎる、ということでESP8266用のMicroPythonをビルドしてみました。

1)ソースコードのダウンロード

gitでダウンロードしてきます。

2)ビルドしてみる

makeしてみます。

ということで、ヘッダファイルが見つからないようで、エラーになってしまいました。

3)原因調査とMakefileの修正

このファイルはSDKの中に含まれているようです。

~/esp-open-sdk ディレクトリの下では、SDKのインストール時に sdk から esp_iot_sdk_v0.9.5 へのシンボリックリンクが張られているので、Makefileの冒頭にあるESP_SDKの定義を以下のとおり修正します。(コメントアウトしたのが修正前の内容)

4)ビルドの続き

ビルドの続きを行います。

無事にビルドができました。

8.esptoolの準備

ESP8266のROM書き換えのためのツールである esptool も ~/esp-open-sdk/esptool の下に準備されます。

ESP8266との接続の方法はこのディレクトリ内の README.md に記述されています。

ということで、ESP8266とUSB-UARTモジュールの間を以下の結線をします。

  • CH-PDをRTSに接続
  • GPIO0をDTRに接続
  • GPIO15をGNDへプルダウン
  • GPIO2を3.3Vへプルアップ

この接続をしておけばesptoolが勝手にESP8266をブートローダモードに移行させてくれるようです。
<esptoolsの参考情報>
https://testpypi.python.org/pypi/esptool/0.1.0

 9.Hack a Dayで発見した記事

Hack a DayでESP8266に書き込む方法が載ってました。

How to Directly Program an Inexpensive ESP8266 WiFi Module

esp8266用の環境を構築する

ESP8266がもうすぐ使えるかもしれない、ということで、早速ビルド環境を構築してみることにしました。

https://github.com/pfalcon/esp-open-sdk

にある esp-open-sdk を使えるようにすることがターゲットになります。

1.Debianのインストール

まあ、Debianは普通にDebian7.8をVMware上でインストールします。
(2回目のインストールはUbuntu14.04LTS上にインストールしました。)

2.ツール類のインストール

環境構築に必要なパッケージ類をインストールします。

3.環境構築

以下の手順で環境構築します。

・・・・とすると、勝手にいろんなものを引っ張ってきてコンパイルしてくれます。マルチコアだからといって、make で -j 2 とか付けたりするとうまく行きません。

4.パスの修正

ホームディレクトリの .profile に以下の内容を追記して、xtensa用のgccをパスに追加します。

一旦ログオフしてログオンしなおしてから、正しくパスが通っているか確認します。

5.アップデートの適用

以下の手順で環境のアップデートを適用します。

※クロスコンパイラを再構築するので、時間がかかります。

6.exampleのコンパイル

以下の手順でコンパイルを試みているが、まだうまく行かない。

コンパイルする対象ディレクトリは sdk 直下に必要な模様。

SDKのMakefileは複雑すぎる(たしかにそんな感じ)ので、書きなおしたほうがいいという話も・・・

R言語で画像データハンドリング(EBImage)

R言語で画像データを取り扱う方法を調べています。
代表的なのはEBImageのようですので、まず試してみました。
とりあえず、

としてインストールします。ルート権限で実行しないとパッケージのアップデートができない、と怒られます。なので、ルート権限で実行します。すると途中、他のパッケージのアップデートをするか聞いてくるので、アップデートしてやります。

途中で「gfortranがない」と文句を言ってくるので、gfortran-4.8とlibgfortran-4.8-devをsynapticでインストールして、再度

としたらとりあえずエラー無しにインストールできたようです。
(あと、imagemagick、libtiff5-devもインストールしておいたほうが良さそうです)

データを読み込んでみます。

まず、小さく切り出したビットマップを読み込もうとしたのですが、GIMPで保存する際に圧縮がかかっているようです。そのために読み込めません。かといって、GIMPで切りだす前の巨大なビットマップを読もうとすると、読むことはできてもその後の処理が32bit版ではメモリ不足を起こすようです。

仕方がないので、小さく切り出した画像を非圧縮のTIFで保存しなおしてみます。

最初の「img <- readImage(“tate.tif”)」で画像を読み込みます。
読み込んだ画像を確認するために「display(img)」で表示させて確認します。
次の「bimg <- img*255」は読み込んだ画像は0〜255の画素値が0〜1に割付け直されるようですので、これを0〜255に割りつけ直すために各画素を255倍します。RGBそれぞれの画素値はimg[,,x]の3番目の添字で選べるようです。
読み込んだ画像は「hist(bimg)」でヒストグラムを取ることができます。この場合、勝手に1枚のグラフにRGBそれぞれの値をプロットしてくれます。

さらにEBImageをつかって画像をハンドリングする例がこちらにありました。そのうち試してみたいと思います。
また、基本的な画像処理(明度、コントラスト、ガンマ、切り出し、2値化、回転、平行移動、反転など)についてはこちらでひと通りの紹介がされています。

でも、直接巨大ビットマップを扱いたいんだよなぁ・・・。

GitHubでUSBのProduct IDを小分けしてるようです

またいつものHack a Dayから。

オリジナルのUSB機器を作るには、USBのベンダIDとプロダクトIDが機器ごとに必要なわけですが、これらを取得するには USB-IF(USB Imprementers Forum)から5000ドルでベンダIDのライセンスを購入する必要があります。ベンダIDを入手すると16ビット分(=65536機種分)のプロダクトIDが手に入りますが、ほとんどの会社はそんなにたくさん使いません。

なので、この余ったIDをオープンソースのハードウェアプロジェクトに提供するようなことをpid.codesというプロジェクトがGitHubのリポジトリを使って行っているようです。(プロジェクトをforkすることでPIDを割り当てるということみたいです。ただ、なんでも割り当てられるわけではなく条件がある。)

USBのベンダIDを取得する際の契約でIDの小分けは禁止されていて、実際にここで小分けされているベンダIDの0x1209(オリジナルはInterBiometricsという会社らしいです)はUSB-IFからライセンスを取り消されてしまっているようですが、かといって、USB-IFはこのベンダIDを他の第三者に割り当てることもできないので、結局は唯一無二のベンダID(とプロダクトID)として存在し続けるということになっているようです。

OSレベルでベンダID 0x1209を拒否する実装でもしない限り、実質的には唯一無二のIDとして大きな支障なく使えてしまう、ということでしょう。Microsoft(ベンダID: 0x045e)もUSB-IFのメンバーのようです(https://www.usb.org/members_landing/directory/ で検索すると出てくる)ので、ひょっとしたらWindowsでは使えなくなる可能性はあるかもしれませんけどね。