趣味の電子工作などの記録。時にLinuxへ行ったり、ガジェットに浮気したりするので、なかなかまとまらない。
RSS icon
  • ESP8266対応のArduino IDEをビルドしてみた

    投稿日 2015年 4月 12日 コメントはありません

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

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

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

    まず、

    $ git clone https://github.com/esp8266/Arduino.git

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

    $ cd Arduino/build
    $ and dist

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

    $ ant dist

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

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

    linux-dist:
     [echo] 
     [echo] =======================================================
     [echo] Arduino for Linux was built. Grab the archive from
     [echo] 
     [echo] linux/arduino-1.6.1-linux32.tar.xz
     [echo] =======================================================
     [echo]
    linux32-dist:
    BUILD SUCCESSFUL
    Total time: 9 minutes 29 seconds
    $

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

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

    $ ant run

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

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

    $ ln -s /home/xxx/esp-open-sdk/xtensa-lx106-elf /home/xxx/Arduino/build/linux/work/hardware/tools/esp8266/.

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

    $ ln -s /home/xxx/esp-open-sdk/esptool /home/xxx/Arduino/build/linux/work/hardware/tools/esp8266/.

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

    Cannot run program "/home/xxx/Arduino/build/linux/work/hardware/tools/esp8266/esptool": error=13, 許可がありません

    切り分けるため、

    $ sudo ant run

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

    $ ant clean
    $ ant run

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

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


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

    投稿日 2015年 4月 10日 コメントはありません

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

    7.MicroPythonをビルドしてみる

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

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

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

    ~$ git clone https://github.com/micropython/micropython
    Cloning into 'micropython'...
    remote: Counting objects: 26530, done.
    remote: Compressing objects: 100% (341/341), done.
    remote: Total 26530 (delta 165), reused 0 (delta 0), pack-reused 26185
    Receiving objects: 100% (26530/26530), 17.02 MiB | 1.85 MiB/s, done.
    Resolving deltas: 100% (18858/18858), done.
    Checking connectivity... done.
    ~$

    2)ビルドしてみる

    makeしてみます。

    ~$ cd micropython/
    ~/micropython$ ls
    ACKNOWLEDGEMENTS bare-arm esp8266 logo stmhal unix
    CODECONVENTIONS.md cc3200 examples minimal teensy unix-cpy
    LICENSE docs extmod py tests windows
    README.md drivers lib qemu-arm tools
    ~/micropython$ cd esp8266/
    ~/micropython/esp8266$ make
    Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
    mkdir -p build/genhdr
    CPP ../py/qstrdefs.h
    makeqstrdata ../py/qstrdefs.h qstrdefsport.h 
    Generating build/genhdr/py-version.h
    mkdir -p build/lib/mp-readline
    mkdir -p build/py
    mkdir -p build/py/../extmod
    mkdir -p build/stmhal
    CC ../py/mpstate.c
    CC ../py/nlrx86.S
       :
       :
    CC ../py/../extmod/moduhashlib.c
    CC ../py/../extmod/modubinascii.c
    CC strtoll.c
    CC main.c
    CC esp_mphal.c
    esp_mphal.c:28:21: fatal error: ets_sys.h: No such file or directory
     #include "ets_sys.h"
                         ^
    compilation terminated.
    make: *** [build/esp_mphal.o] エラー 1
    ~/micropython/esp8266$

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

    3)原因調査とMakefileの修正

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

    ~$ find . -name "ets_sys.h" -print
    ./esp-open-sdk/esp_iot_sdk_v0.9.5/include/ets_sys.h

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

    #ESP_SDK = $(shell $(CC) -print-sysroot)/usr
    ESP_SDK = /home/xxx/esp-open-sdk/sdk

    4)ビルドの続き

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

    ~/micropython/esp8266$ make
    Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
    Generating build/genhdr/py-version.h
    CC esp_mphal.c
    CC gccollect.c
    CC uart.c
    CC modpyb.c
    CC modpybpin.c
    CC modesp.c
    AS gchelper.s
    CC ../stmhal/printf.c
    CC ../stmhal/string0.c
    CC ../stmhal/pyexec.c
    CC ../stmhal/pybstdio.c
    CC ../lib/mp-readline/readline.c
    LINK build/firmware.elf
     text data bss dec hex filename
     283992 1456 48664 334112 51920 build/firmware.elf
    Create build/firmware-combined.bin
    ('flash ', 48288)
    ('padding ', 17248)
    ('irom0text', 237208)
    ('total ', 302744)
    ~/micropython/esp8266$

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

    8.esptoolの準備

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

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

    ## Protocol
    If GPIO0 and GPIO15 is pulled down and GPIO2 is pulled high when the module leaves reset, then the bootloader will enter the UART download mode. The ROM auto-bauds, that is, it will automagically detect which baud rate you are using. esptool defaults to 115200.
    esptool uses the RTS and DTR modem status lines to automatically enter the bootloader.
    Connect RTS to CH_PD (which is used as active-low reset) and DTR to GPIO0.
    

    ということで、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に書き込む方法が載ってました。

    http://hackaday.com/2015/03/18/how-to-directly-program-an-inexpensive-esp8266-wifi-module/


  • esp8266用の環境を構築する

    投稿日 2015年 4月 8日 1つのコメント

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

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

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

    1.Debianのインストール

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

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

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

    $ sudo apt-get install make autoconf automake libtool gcc g++ gperf &nbsp;flex bison texinfo gawk ncurses-dev libexpat-dev python sed git
    
    

    3.環境構築

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

    $ git clone https://github.com/pfalcon/esp-open-sdk
    $ cd esp-open-sdk
    $ make STANDALONE=n
    
    

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

    4.パスの修正

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

    # add esp8266 tools to PATH
    PATH="$HOME/esp-open-sdk/xtensa-lx106-elf/bin:$PATH"
    
    

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

    ~$ xtensa-lx106-elf-gcc -v 
    Using built-in specs. COLLECT_GCC=xtensa-lx106-elf-gcc COLLECT_LTO_WRAPPER=/home/xxx/esp-open-sdk/xtensa-lx106-elf/libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper Target: xtensa-lx106-elf Configured with: /home/xxx/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=xtensa-lx106-elf --prefix=/home/xxx/esp-open-sdk/xtensa-lx106-elf --with-local-prefix=/home/xxx/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --disable-libmudflap --with-sysroot=/home/xxx/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit --with-gmp=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpfr=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpc=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-isl=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-cloog=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-libelf=/home/xxx/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --enable-lto --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c,c++ Thread model: single gcc version 4.8.2 (crosstool-NG 1.20.0) 
    ~$

    5.アップデートの適用

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

    $ cd ~/esp-open-sdk
    $ make clean
    rm -rf esp_iot_sdk_v0.9.5
    rm -f sdk
    rm -f .sdk_patch_0.9.5
    make -C crosstool-NG clean MAKELEVEL=0
    make: ディレクトリ `/home/xxx/esp-open-sdk/crosstool-NG' に入ります
     RM 'ct-ng'
     RM 'scripts/crosstool-NG.sh'
     RM 'scripts/saveSample.sh'
     RM 'scripts/showTuple.sh'
     RM 'paths'
     RM 'config/configure.in'
     RM 'kconfig'
     RM 'docs/ct-ng.1'
     RM 'docs/ct-ng.1.gz'
    make: ディレクトリ `/home/xxx/esp-open-sdk/crosstool-NG' から出ます
    rm -rf /home/xxx/esp-open-sdk/xtensa-lx106-elf
    $ git pull
    Already up-to-date.
    $ git submodule update --init --recursive
    Submodule 'crosstool-NG' () registered for path 'crosstool-NG'
    Submodule 'esptool' () registered for path 'esptool'
    Submodule 'lx106-hal' () registered for path 'lx106-hal'
    $ make STANDALONE=n
    
    

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

    6.exampleのコンパイル

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

    $ cd ~/esp-open-sdk/sdk
    $ mv example/IoT_Demo .
    $ cd IoT_Demo
    $ make COMPILE=gcc
    
    

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

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


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

    投稿日 2015年 4月 5日 コメントはありません

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

    $ sudo R
    > source("http://bioconductor.org/biocLite.R")
    > biocLite("EBImage")

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

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

    > biocLite("EBImage")

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

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

    > install.packages("tiff")
    > install.packages("png")
    > install.packages("jpeg")
    > install.packages("bmp")
    > library(EBImage)
    > library(bmp)
    > setwd("/home/xxx/R")
    > img <- read.bmp("small.bmp")
     以下にエラー read.bmp("small.bmp") : 
      Do not know how to handle compressed BMP
    > img <- read.bmp("large.bmp")
    > hist(img)
     エラー:  サイズ 795.6 Mb のベクトルを割り当てることができません 
    > plot(img)
     エラー:  サイズ 1.6 Gb のベクトルを割り当てることができません 
    >

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

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

    > img <- readImage("tate.tif")
    > display(img)
    > bimg <- img*255
    > bimg[,,1]
    Image
      colormode: Color 
      storage.mode: double 
      dim: 210 210 
      nb.total.frames: 1 
      nb.render.frames: 1 
    
    imageData(object)[1:5,1:6]:
         [,1] [,2] [,3] [,4] [,5] [,6]
    [1,]  106  104  101  100   96   93
    [2,]  138  139  143  140  135  137
    [3,]  110  106  112  121  114  111
    [4,]   52   50   52   54   54   49
    [5,]   47   47   45   44   42   48
    
    > bimg[,,2]
    Image
      colormode: Color 
      storage.mode: double 
      dim: 210 210 
      nb.total.frames: 1 
      nb.render.frames: 1 
    
    imageData(object)[1:5,1:6]:
         [,1] [,2] [,3] [,4] [,5] [,6]
    [1,]   88   91   93   96   88   89
    [2,]  134  138  136  139  136  133
    [3,]  121  111  115  114  115  118
    [4,]   61   59   57   57   61   63
    [5,]   50   48   43   46   51   44
    
    > bimg[,,3]
    Image
      colormode: Color 
      storage.mode: double 
      dim: 210 210 
      nb.total.frames: 1 
      nb.render.frames: 1 
    
    imageData(object)[1:5,1:6]:
         [,1] [,2] [,3] [,4] [,5] [,6]
    [1,]   98  102  107  112  108  104
    [2,]  141  143  147  145  143  145
    [3,]  122  119  114  111  109  114
    [4,]   53   51   52   51   51   49
    [5,]   41   41   37   42   46   45
    
    > hist(bimg)
    >

    最初の「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を小分けしてるようです

    投稿日 2015年 4月 4日 コメントはありません

    またいつもの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では使えなくなる可能性はあるかもしれませんけどね。