(祝)ESP8266モジュールの技適証明

最近、忙しくてESP-8266関連(だけじゃなくてプライベート一般も)に手を出せていないのですが、ESP-8266モジュールで技的マークが写ってる写真が出てたよ、というご報告をTDRKさんからいただきましたので紹介します。

ESP-8266はリンクを維持したまま消費電力を1mA以下にできるよ、というツイートとともに写真が写っています。

画像なしで引用しているのですが、下記の技適マーク入りのモジュールの写真が付いています。(直リンクしてますので、見えなくなるかも)

結局、シールドケースにWiFiのマークやCEマーキング、FCCのID、Espressifのロゴと共に技適の番号が直接入るようですね。

TDRKさんに教えていただいたこちらのリンクでは、ESP-WROOM-02というモジュール名称が記載されています。FCC、CEに加え、はっきりTELECと書いてあります。(中国のSRRCも記載があります)
このモジュールに関してはFCCやCEなども初出なのでしょうか、先のTwitterにはすでにFCCに関する質問のTweetも出ています。

AliExpressやTaobaoで手に入るようなことが書いてありますが、今の時点ではAliExpressではすべてEspressifのロゴのみのシールドケースの写真になってます。価格は数量によりますが$4~5位。ショップが掲示している写真は更新されるのでしょうかね。更新すれば日本からの注文が増えるとなれば、中国人は(良くも悪くも)商売上手なので更新すると思いますが・・・。
中身は変わらないんでしょうが、マークの有り無しは電波法上重要ですから。

さて、マーク入りのモジュールが手に入るようになれば、あんなことやこんなことができるようになりそうです。
・・・が、まずは時間が欲しいところ・・・。

9ドルのLinuxボード・・・C.H.I.P.

またまたHack a Dayからです。といっても、元ネタはKICKSTARTERです。

Raspberry Piの$35(モデルAは$25)でも十分驚いたのですが、今度は$9で1GHzのCPU(All Winner A13・・・ちょっとまえの中華タブレットでよく見かけたものですね)と512MBのRAM、4GBのストレージに加えてUSBホスト、WiFiとBluetoothがついたボードが登場するようです。アダプタを介してHDMIやVGAの出力も可能。まあ、Raspberry Piの登場からすでに3年以上が経っているわけで、冷静に見ればそんなにびっくりする話ではないかもしれません。

AllWinner A13はこちらによればCortex-A8の1コアなので、ちょっとデスクトップを動かすには厳しいのではないかと思います。

OSはCHIP OSという名称ですが、KICKSTARTERに掲載されているその他の写真ではLXDEの画面になっています。ブラウザが動いている写真が掲載されていますし、LibreOfficeやScratchも動くようです。AllWinner用のLinuxカーネル+XとARM版Lubuntuの組み合わせに近いものなのかもしれません。

このボードならフルスペックのPythonが動くと思う(aptが動かないとハードル高いですが)ので、簡単にプログラミングできるIoTデバイスとして遊べる対象になりそうです。

目標5万ドルがゴールですが、まだ1ヶ月近くを残してすでに70万ドル以上のpledgeを得ていて、みるみる増えていってます。思わず自分もポチりそうになったのですが、出荷が年末から2016年年明けとだいぶ先の話なのと日本への送料が$20かかるのでやめました。(FAQを読むと海外出荷の送料を下げる動きは取っているようですが・・・)

Raspberry Piのような世界を作れるかどうかが生き残りのポイントだと思いますが、どうなるでしょうね。生き残れば日本国内でも入手できるようになるでしょうから、その時に入手したいと思います。

<参考>

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

先に紹介した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用の環境を構築する(続き)

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に書き込む方法が載ってました。

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.ツール類のインストール

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

$ 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)

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

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

2月前半の技適証明の公示

ESP8266の開発がArduino IDEでできるようになったというすごいビッグニュースがでたところで気になるのが、日本でESP8266を使うためには避けて通れない技適の行方です。

この記事で書いたように、2月13日にEspressifの中の人が「#ESP8266 has passed the Japanese TELEC certification!」とツイートしています。

・・・で、時々総務省のWebサイトにある技術適合証明等の公示をみていたのですが、さっき見てみたら、2月前半分の公示がでていました(なんで週末に出るんだろ?)。で、テレコムエンジニアリングセンター(TELEC)の2月前半分を見てみると、ずらずらっとたくさん技適認証を受けた機器が並んでいます。この中で電波形式G1D(多分合ってると思うんだけど)で検索して、周波数が2400MHz帯しか出さないものを見ていくと、

  • 三菱電機 AR-0HT6-PANEL2-2 001WWDB3008282~
    3008331 2/12
  • 株式会社日放電子 F400470091 001WWCA3018338~
    3018349 2/9
  • LG Electronics Inc. LG-W100 001-A03356  2/4
  • パナソニック株式会社 CN-GP757VD  001-A05291  2/13

しかありません。(技術基準適合証明を受けた者の氏名又は名称、特定無線設備の型式又は名称、技術基準適合証明番号、技術基準適合証明をした年月日の順です)

三菱電機やLGやパナソニックが他社のモジュールの認証を取るということは考えにくいので、この中で怪しいのは2番目の日放電子さんかな、と思います。ちょうど技適の証明番号も12個ということで、ESP-01〜ESP-12のモジュールの種類の数とも一致しています。そこで、総務省の技術基準適合証明等を受けた機器の検索のページで検索してみました・・・が、特に追加の情報はありませんでした。

さて、実際どうなることやら・・・。技適の問題がクリアになってくれればヒットまちがいなしなんですけどねぇ・・・。あるいは、この日放電子さんというところから日本向けは販売されるんでしょうか・・・?(最悪なのは、他3社のどこかが自家組込み用にTELEC取りました〜、というパターンですが・・・)

ヤキモキさせてくれますね・・。

#ESP-01ってシールドケースが無いから技適が通らない気もするけど・・・シールドケースで密閉されてなくてもワンチップだからハードウェア改造で何かできる気もしないし、どうなんだろ?

【すごい】ESP8266がArduino IDEでサポートされる

いつものように、Hack a Dayの記事から。

タイトル(「ARDUINO IDE SUPPORT FOR THE ESP8266」)だけ見ると、ESP8266をEthernet Shieldとして使えるようになったのかな、と思ってしまうところですが、そんな当たり前の話じゃありません

『ArduinoでESP8266がサポートされた』のではなく、『Arduino IDEでESP8266がサポートされた』のです。言い換えると、ESP8266単体で動かすIoTアプリケーションの開発がArduino IDEでできるようになったということなのです。(github上のサンプルプログラムにはIoTのプロトコルであるMQTTのサンプルも載っています)

ESP8266の内部のXtensaプロセッサをArduino IDEがサポートするようになり、ESP8266モジュールだけでArduinoのpinMode(),digitalRead(),digitalWrite(),analogRead()が使える上に、WiFi機能をEthernet Shieldと同様に使えるようです。一方で、PWMはESP8266自体がハードウェアリソースを1chしか持っていないので制約があり、SPIとI2Cはまだ動作しないようです。

すでに github から Linux(64bit)、Windows、OS X用のArduinoコンパチのIDEがダウンロードできるようになっていて、サポートしている機能の範囲も同じところに書かれています。(Linux版をダウンロードしてみたら70MB以上ありました・・・)

ESP8266の書き換えは、Hack a Dayのこちらの記事にあるような簡単な回路でできるようです。

IDEの安定性次第のところはあるかもしれませんが、安定して使えるようになればこれは間違いなく大ブレイクすると思います。これで無線や電子工作に詳しくない人でもArduinoでマイコン制御機器を作ってみるのと大して変わらない感覚で、ESP8266を使ったIoT機器を作ってみるということが可能になるのですから。

おそらく、Espressif社はWiFiを使ったIoT機器用のチップとしては数量でNo.1になっていくのではないでしょうか。(ちょうど、BluetoothでCSR社が占めているような立ち位置になるんじゃないかと予想します)

いまさらH8-300開発環境を構築してみたけど・・・

いまさらですが、余っているH8/3664ボードを何かに使おうと思って、開発環境を調査してみました。

1.環境

VMware上の Lubuntu14.04.2をターゲットにします。
OSをインストールしたら、build-essentialパッケージをインストールした後、VMware-Toolsをインストールします。

2.Cコンパイラ

いまさらアセンブラもないので、Cコンパイラを探します。
synapticでh8を検索すると、binutils-h8300-hmsとgcc-h8300-hmsが見つかります。これらをインストールします。これらをインストール後、バージョンを確認すると以下のようになっていました。

~$ h8300-hitachi-coff-gcc -v
Reading specs from /usr/lib/gcc/h8300-hitachi-coff/3.4.6/specs
Configured with: ../configure coff
Thread model: single
gcc version 3.4.6
~$

3.書き込みツール

昔、三岩さんが作られたものと思われるツールが sourceforge にあがっていましたのでコンパイルしてみます。説明では先頭の4行を環境に合わせて修正してからコンパイル、と書いてありましたが、はじめからLinuxのみが#defineされていました。

~$ mkdir H8tools
~$ cd H8tools/
~/H8tools$ wget mes.sourceforge.jp/h8/h8write.c
--2015-xx-xx xx:xx:xx--  http://mes.sourceforge.jp/h8/h8write.c
mes.sourceforge.jp (mes.sourceforge.jp) をDNSに問いあわせています... 202.221.179.22
mes.sourceforge.jp (mes.sourceforge.jp)|202.221.179.22|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 70666 (69K) 
`h8write.c' に保存中

100%[======================================>] 70,666       128KB/s   時間 0.5s 

2015-xx-xx xx:xx:xx (128 KB/s) - `h8write.c' へ保存完了 [70666/70666]

~/H8tools$ gcc h8write.c -o h8write
h8write.c: In function ‘error_print’:
h8write.c:732:4: warning: format not a string literal and no format arguments [-Wformat-security]
    fprintf(stderr,message[error_code]);
    ^
h8write.c:733:4: warning: format not a string literal and no format arguments [-Wformat-security]
    if ( s_message != NULL ) fprintf(stderr,s_message);
    ^
h8write.c:737:4: warning: format not a string literal and no format arguments [-Wformat-security]
    fprintf(stderr,message[error_code]);
    ^
h8write.c:738:4: warning: format not a string literal and no format arguments [-Wformat-security]
    if ( s_message != NULL ) fprintf(stderr,s_message);
    ^
h8write.c:742:4: warning: format not a string literal and no format arguments [-Wformat-security]
    fprintf(stderr,message[error_code]);
    ^
h8write.c:743:4: warning: format not a string literal and no format arguments [-Wformat-security]
    if ( s_message != NULL ) fprintf(stderr,s_message);
    ^
~/H8tools$

Warningがたくさん出ましたが、実行ファイルは生成されました。

4.コンパイルテスト

Strawberry LinuxのWebサイトからLED点滅サンプルを持ってきてコンパイルしてみました。

$ wget strawberry-linux.com/h8/h8led-0.1-20020706.tar.gz
$ tar xvfz h8led-0.1-20020706.tar.gz
$ cd h8led
$ make clean
$ make

・・・が、-lc がないと言って怒られます。探してみると、どこにもH8用のlibc.aがありません。これは libc.a がないことを意味していますので、newlibをインストールすることにしました。

5.newlibのインストール

組み込み用のlibcであるnewlibをコンパイルします。
その前に、まずgitからインストールです。

~$ mkdir newlib
~$ cd newlib/
~/newlib$ sudo apt-get install git
~/newlib$

さらに、newlibのソースを取ってきます。

~/newlib$ git clone git://sourceware.org/git/newlib-cygwin.git

このままコンパイルすると、「makeinfoがない」といって怒られますので、synapticでtexinfoパッケージをインストールして、別のターミナルを新規に開いてから configureスクリプトを走らせて、make、make install します。

~/newlib/newlib-cygwin$ ./configure --target h8300-hitachi-coff
~/newlib/newlib-cygwin$ make
~/newlib/newlib-cygwin$ sudo make install

libc.a、libg.a、libm.a が /usr/local/h8300-hitachi-coff/lib の下にインストールされました。

6.改めてコンパイルテスト

よくみると、さらにはMakefileでライブラリパスが設定されていなかったので、これを修正してみたのですが、今度は互換性のないlibc.aをスキップしました、となってしまいました。

~/H8sample/h8led$ make
h8300-hms-gcc -O -mh -g -mrelax -mint32 -DH8_3664 -T h8-3664.x -L /usr/local/h8300-hitachi-coff/lib -nostdlib 3664crt0.S  led.o -o h8led.exe  -lc -lgcc
/usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/bin/ld: 互換性のないを /usr/local/h8300-hitachi-coff/lib/libc.a スキップしました (-lc を探索している時)
/usr/lib/gcc/h8300-hitachi-coff/3.4.6/../../../../h8300-hitachi-coff/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
make: *** [h8led.exe] エラー 1

確か、gccのクロスコンパイラをビルドするときにはライブラリ(libcなど)なしで一度コンパイラをビルドしてライブラリをビルド、その後再度コンパイラをビルドし直す手順になっていたかと思うのですが、そのへんがちゃんと行われていないのかもしれません。(ググってもnewlibのバイナリがなく、ソースからビルドするしかなさそうだ、という時点で嫌な予感はしたんですけどね)

7.まとめ

・・・うーむ。ぐぐってみると、同じ問題がはるか昔に出ていたようです。
https://bugs.launchpad.net/ubuntu/+source/gcc-h8300-hms/+bug/342667
ここを見る限り、リポジトリにあってSynapticでインストールできても結局メンテナンスされてなくて使い物にならないようで、そのままずーっと放置されているようですね。

コンパイラごとソースからビルドすれば動く組み合わせもあるかもしれませんが、そこまでして動かす元気はありません。今でも秋月ではH8/300のボードを売ってますが、みなさんどうやって使ってるのでしょう?(メンテナンス目的?教材用?)
いまでもcygwin + gcc2.95.3ベースの環境をCD-Rで売ってるようですが、いまさらのような気がします。

H8は比較的電子工作用途に受け入れられた数少ない日本製マイコンですが、この状況ではとても使う気にはなれません。かといって、いまさらR8Cとか78Kとかってのもないでしょうから、素直に諦めるほうが良さそうです。

さて、余ってしまったボード、どうしよう・・・。