WiFiモジュールESP32で画像付きサーバーの開発に成功

　前回までのブログは、失敗続きで暗かった。この年(もう70才を数年越えた)で、無謀にもみんながやっていないI2Cのクロックストレッチをソフトで実現しようとして、ハードウエアの基礎知識不足を見事にさらけだし、あえなく撤退した。

　しかし、今度の記事は胸を張って明るく報告できる。今流行りのWiFiモジュールESP8266の兄貴分ESP-WROOM-32（以下ESP32）で、画像付きのウェブサーバーの開発に挑み、このほど動かすことが出来たのだ。

　ESP8266ではフラッシュの部分をファイルシステムにするSPIFFSがArduinoIDEで用意されていたので、これを利用して画像データファイルをホームページに表示することが出来た。ただ、ESP8266では性能的に一杯一杯で、わずか12KB程度のjpegファイルの表示に、ひといき（0.5秒くらいか）時間がかかり実用的とは言えない。

　ESP32は、ESP8266に比べると、CPU数が1から2、クロックも1.5倍(160->240Mhz)と性能が一段と強化されている（他にもBlueToothなど機能も豊富になった）。こいつなら少しは実用的な画像を背景にしたホーム画面や、イラストで作ったボタンが使えるかもしれない。
（ここが詳しい）

　ところが、ESP32のArduinoIDEの環境では、今のところSPIFFSが動いていないようなのだ。（このブログ参照）しかし、ウエブ情報を集めていくと、製造元(espressif社)の提供する開発環境、ESP-IDFや、他のプロジェクト(Rua-RTOS)で、フラッシュファイルシステムを作ったという話が出てくる。

　うまく動いているらしいが、リンク先が海外で、いまひとつ確実なことがわからない。でもここまできたらESP-IDFを導入して画像が出るところまで動かし、ESP8266との差を確かめたくなった。

　以下は、ESP－IDFの環境整備から、画像表示に成功するまでのESP32開発記録である。実は終盤になって画像を表示させるのにSPIFFSより遥かに簡単な方法が見つかるという、どんでん返しがあったのだが、詳しくは本文で。

ESP-IDF開発環境の導入から始める(9/2/2017)
　ESP-IDFとはArduinoIDEとは別の開発環境である。製造元の正式環境だが、make主体のCUIの世界で、WindowsにLinuxの環境を作るなど、準備に手間がかかり、今まで敬遠してきた。しかし目標である画像の出るサーバー画面の実現のためには避けて通れなくなった。

　気分を新たにして、開発環境を準備する。ハードウエアはArduinoの時と同じ秋月で売られている純正ブレークアウト基板DevkitCを使う。こいつは横幅が広いので普通のブレッドボードに差すとジャンパーが出せなくなるが、ここはミニブレッドボード2枚を並べてしのぐ。

　ESP-IDFのインストールは紹介するサイトが今や山ほどある（以前は少なかったが）。戸惑うことはない。むしろ沢山ありすぎて何を選べば良いのか迷うほどだ。まあ、余りこだわることはない。こことか、このあたりを参考にインストールを始めた。

　最初のmingw（Win上のLinux環境）のインストールファイルが500MB近くもあり、サーバーの線が細くてダウンロードに1時間近くかかったのが問題だったくらいで、インストールそのものは、意外にも順調だった。ここでも「ねむいさん」のブログにお世話になる。彼（彼女？）は何と去年のうちに環境をインストールしテストまでされていた。

　mingw上に自分のホームディレクトリを作り、開発環境は出来上がったが、沢山のサイトを拾い読みしていたために、ホームディレクトリの位置がさまざまで、esp-idf(開発環境本体)のディレクトリパスが中々通らない。何とか、ごまかし、ごまかし（mingwなので、サブディレクトリ区切りがバックスラッシュ\と、/が混在してややこしい）、makeが通るようにする。

　やっと動き出して、中味のファイルや、サンプルコードを覗く。ここはC++でもなく、純然たるCの世界だった。STM32で少しかじったFreeRTOSがメインのOSのようで、何か久しぶりに旧友に会ったような気分でなつかしい。

　ただ、MakeFileのあたりの情報隠蔽がかなり深い。実際のMakefileの中身が全く表に出て来ないので何をやっているのかわからない。ソースがメインプログラムしかないのも不思議である。わからないことだらけだが、とりあえず先に進む。

LチカとHelloWorldは簡単に動いた(9/3/2017)
　以前の記事のとおり、ESP32はArduinoの環境で既に動かし、LEDをウェブから制御できるサーバーまで作った。それでもESP-IDFの環境に慣れるため、サンプルソースにLチカ(blink)と、hello　worldのソースがあったので、これらを使って練習することにした。

　ホームディレクトリに、サンプルソースの一式（AVRで言うプロジェクトのようなものか）をコピーし、make menuconfigで、シリアルラインの定義をしたあと、makeに入る。延々とビルドが始まった。

　ふーむ、Lチカくらいで、何か、すべてのリソース（IPV6からBluetooth、SSLまで）をビルドしているようだけど、どう言うことなんだろう。まあ、何十分もかかるわけでもないので待つしかないが、何か無駄のような。

　Lチカは、指示通り、make menuconfigでIOピンの位置を修正する。前に使ったLEDをGPIOに設置し、makeに入る。幸いNO Errorのようだ。続いて、make flashでファームに焼く。これもエラーは出ない。すると、めでたくLEDが1秒近い間隔で点滅し始めた。よーし、動いた。

　次は、Hello　worldである。もうひとつ手順が増える。make flashのあと、make monitorでコンソールにUSBコンソールのCOM3仮想ターミナルを立ち上げる。やたらとメッセージが多いが、無事、コンソールにHello World!の文字が10行づつ繰り返された。これも問題ない。

SPIFFSのgithubを見つける(9/6/2017)
　次は、HTTPサーバーだが、その前にこれまで見つけてあるSPIFFSプロジェクトを入れることにした。目星をつけたいくつかのサイトを調べているうち、英文だが、外国人（イタリア？）の英語なので、とても理解しやすいサイトを見つけてある。

　以前に見つけたところとは別のサイトだが、esp-idfの環境で、SPIFFSが出来たという報告である。沢山の感謝とお礼のレスポンス付きだ。これは間違いなく動いているようだ。喜び勇んでダウンロードする。

　順調に進むかと思われたが、そう簡単に問屋は許さなかった。今度も、ディレクトリパスが難しい。make menuconfigそのものが通らない。いくつかの関門を潜り抜け、menuconfigまで行ったが、今度は本番のmakeでビルドエラーが出る。残念！

　何かおかしい。インストールした場所が悪いのか。githubなので、clone先が所定のところにないと、正しく動かないようだ。余り深入りは避け、次の日、出勤した事務所のPCで最初からインストールしてみた。これが不思議、makeが通ったのである。

SPIFFS動作成功(9/8/2017)
　帰宅して、もう一度やり直す。やった。makeが通る。make flashで実際にファーム焼き込み。これもうまく行った。原因はやっぱりgitを展開するディレクトリの位置だったようだ。いやあ気難しい。

　まあ、あまりこれにこだわっていても仕方がない。先に進もう。それにしても単なるフラッシュだけの操作なのだけど、LチカとHelloWorldと同じように、延々とすべてのライブラリのコンパイルが続く。

　testSPIFFS.cのソースコードをあらためて精読する。mainで各種の関数をテストし、それをコンソールに出力している。そんなに複雑ではない。これだけで動くようだ。何はともあれmake monitorでコンソールを動かしてみた。

　やった、それらしい出力が次から次に出力される。ディレクトリを増やしたり(mkdir)、ファイル一覧(ls)なども出来る。うむ、うまく動いているようだ。フラッシュファイルにアップロードする方法がまだわからないが、テスト環境には、フラッシュに入れたファイルイメージが残されており、何らかの方法でアップロードは出来るようだ。

　ここまで進むと先は見えてきた。ESP-IDFのサンプルソースにはHTTPサーバーのソースがあるので、このSPIFFSを、サーバーに合体させれば動く見通しがついた。どちらを母体にするか迷ったが、構造の複雑なサーバーのソースコードにSPIFFSの要素を組み込んでいく。その前に、HTTPサーバーを動かしておかないといけない。しかし、これが意外と難渋したのである。

やっとホームページが出せた。サンプルソースでは動かない(9/18/2017)
　サンプルがあるので、簡単にHTTPサーバーは動くかと思ったが、これがなかなかいうことを聞かない。いくつかあるHTTPサーバーのソースの一つをビルドしたが、ホームページ(index.html)を出すようなところが見当たらない（http_request_server）。

　やっていることは、どこからかのソケットを受けてそれをSTDOUT(コンソール)に表示するだけである。これはサーバーではないよね。クライアントがやることだ。少なくともesp-idfのサンプルソースesp-idf/examples/protocols/http_requestと、https_requestにあるソースには、リクエストしかなく、これでは動かない。

　困ったときはgoogle先生である。esp-idf http_server などのキーワードで検索を続けると、別のそれらしいソースコードが見つかった。ドイツの電子工作ショップのサイトで、ソースだけで説明記事に戻れないが、コードを読む限りでは、クライアントのリクエストに対してindex.htmlを返す部分がある。もうひとつタスクが必要のようだ(netconn_server)。

　半信半疑ながら、このソースに取り替えて、再度ビルドしてみる。よーし、OK!　簡単なindex.htmlが表示された。良かった。でも、なぜ本家のサンプルには、本来のHTTPサーバーの雛形がないのだろう。謎である。次はいよいよhtmlファイルのフラッシュファイル化に進む。

HTTPサーバーの解析に夢中になる(9/16/2017)
　フラッシュファイルを入れるため、サーバーのソースを読みふける。おおー、段々全体が見えてきた。嬉しい。いや勉強になる。これまで近づこうとしてなかなか機会のなかったソケットプログラムだ。lwipとか、nghttpとか、新しいプロトコルを知る。

　電子工作ではなくて、ウェブプログラミングで遊んでいる。この世界も複雑で奥が深い。HTTPサーバーの教科書が少ない。事務所の帰りにいつもの秋葉原書泉で参考書を探すが、自分が知りたい基礎の部分を解説したものはなかなか見つけられない。

　このesp-idfの開発環境にも大分慣れてきたが、それににしても、このフルビルドは何とかならないか。延々と必要もないモジュール群をコンパイルしていく。一旦コンポーネント(ライブラリ)が出来ると、あとは少し早くなるが、それまでは大変だ（まあ、モジュールを選択するのも大変なので、こういうやり方もあるか）。

　文字列の連結、文字列のサーチなどArduinoIDFにはあった機能をせっせと開発する。コーディングとしては楽しかったが、これらはすべてCの標準関数(string.h)にあることがわかって、お蔵入りした。完全な無駄足である。

SPIFFSでテキストファイルの送出は成功した(9/22/2017)
　画像表示は、読み込みのとき大きなバッファースペースが必要なので、まずは文字ベースでindex.htmlに埋め込む方法をテストする。これが結構難しい。どうも思ったようにhtmlに展開してくれない。

　それより問題なのは、nett_conn_serverというFreeRTOSのタスク上でSPIFFSを動かすとstack overflowでプログラムが落ちるのである。menuconfigなどでスタックサイズを広げるが改善されない。これもウェブで調べて解決方法が見つかった。タスクを起こす関数に、スタックサイズを指定するパラメーターがあったのだ。

　 これを通常の3倍(6144バイト)まで広げてやっとstack overflowは止まった。しかし、それでもindex.htmlに思ったような文字列が出てこない。何回か試行錯誤するうち、重大な誤りをみつけた。

　文字列の長さを得るのに、sizeofを使っていたのだが、ポインターを使った文字列では、これがアドレスを収容するエリア（ここでは4バイト）になってしまうことに、だいぶ後になってから気づくというお粗末である。

　しかも、関数の引数にすると呼ばれた先では、strlenでも文字数が正しく得られない。それやこれやで苦闘の結果、何とか出せたのだが、<object src=XXXXX />のタグでは、スクロールバーのようなものが出てしまう。目的は画像ファイルなので、道草を食いたくないのだが、テキストファイルの表示だけで四苦八苦である。

何と、もっと良い方法を見つけた。バイナリの埋め込み(9/24/2017)
　色々とウェブをさ迷ううち、SPIFFSではない、もっと楽な画像ファイルの表示方法があることを偶然つきとめた。いや情報は浴びるように摂っていれば良いことがあるという言葉どおりの快挙である。

　esp-idf esp32 webserverなどのキーワードで、調べているうち、スマホのきれいな画像のボタンでLEDをウェブから制御しているページを見つけた。

　ボタンがきれいなイラスト画像(pngファイル)である。へえー、サーバーでどこかのクラウドサーバーにリンクして画像を持ってきているのだろうかと、思っていたら、どうもそうではない。　mainと同列にある、component.mkファイルにCOMPONET_EMBED_FILES:=でファイル名を定義すると、これをbinary dataとしてフラッシュに埋め込んでくれるというのだ。

　これはすごい。以前、AVRでやったことのある、フラッシュにバイナリーデータを埋め込むobjcopyと同じ手法である。埋め込んだ後、エントリーポイントを取得すれば、プログラムのなかでこのバイナリーデータを使うことが出来る。

　まだSPIFFSではjpegファイルまで進んでいないが、ファイルを読み込まなくても、外部参照だけでデータをとりこめる。しかもバッファーの長さを気にする必要もない（コンスタントデータなのでバッファーの長さは気にしないで良い）。

　これは試してみるしかない。早速、サイトの情報を頼りに、見よう見まねで、適当なjpegファイルをとりだし（SPIFFSスタックの中にあった画像）、component.mkファイルに設定し、ビルドしてみた。おーし、何のエラーも出ずビルドは終わった。

　次はmake flashである。いつもより少し時間がかかるが無事終了した。jpegファイル40KB分だけ遅くなっているか。さあ、make monitorでサーバーを立ち上げる。

　おおー、やった。画像がホームページに出た。しかも早い！一瞬だ。嬉しくて何度もディスプレイの前でガッツポーズをする。ホームページそのものは、画像とテストメッセージ一行の何も意味もないページだが、このあとには無限の可能性が待っている。

SPIFFSでも画像ファイルの送出に成功。そう遅くにもならない(9/25/2017)
　勢いに乗って、SPIFFSでも画像が送れるかやってみる。このnetconn_serverというしかけが良く見えないので、バッファーサイズをどれくらいまで広げられるかわからない。これが、画像ファイルの読み込みを遅らせていた理由だが、もうそんなことは言っていられない。適当なサイズ(4KB)でneconn_write()を繰り返し発行することにする。

　恐らく、バイナリ埋め込みに比べれば遅くで使い物にならないかもしれないが、まずはやってみる。動かしてみた。おやあ、またstack overflowで止まる。祈る気持ちでスタックサイズを2048の3倍からさらに4倍の、8192まで上げて再度動かしてみる。

　よーし、動いた。そんなに遅くならない。esp-idfについているデバッグ用のメッセージにms単位のタイムスタンプがあるので、これで測ってみると、同じ画像で、埋め込みで平均62msが、SPIFFSだと108msだ。ブロックサイズを広げればもう少し早くなるかもしれない。

　とにかく、ESP32の画像付きサーバーの開発はこれで一段落した。胸を張ってブログに報告できる。

以下に、サーバーのソース一式をONE DRIVEで公開します。ディレクトリごとzipファイルにしたので、これをesp-idfのホームディレクトリに展開し、mainの直上のディレクトリでビルドすれば、バイナリデータを埋め込んでくれます。ソースには2種類のやりかたがコメントとして残っているので、適当に選んでください。WiFiの設定はmake menuconfigで行います。

ここをクリックしてONEDRIVEに行く

RaspberryPi 3の電源事情好転せず。ESP32に手を出す

　RaspberryPi 3(以下Raspi3)による監視カメラはほぼ完成したが、恐れていた通り実際の観測には重い腰が上がらなくなった。現役時代の習い性だろう（若い時はそうではなかったので、一種の職業後遺症）。こういうプロジェクトを計画なしに始めることに強い抵抗があるのだ。

　どんな仕事でも一旦始めると、それを中止する大義名分が見つからない限り止められなくなる習慣が出来ている。途中でやめることに強い罪悪感を覚える。作業を始める前に具体的な目的と目標を決めておくのが決まりになっている。

　これまでに何度か気楽に始めてそれが止められず、といって順調に事は進まず、その葛藤で、へとへとになってしまったことがある。とまあ、出来ない屁理屈をこねているが、実はそれよりもっと深刻なことがある。Raspi3そのものの動作がまだ安定しない。

　USBセルフパワーHUBと電源のACアダプターを共通にすると大量にHUBの方から電力を供給してしまう問題は、特定のHUBの逆流と結論付けたのだが、念のため単独でテストしたところマスター側には電圧がかかってこないし（LEDが点かない）、このHUBを分解して中身を確認しても、しっかりVBUS側にはSBD(ショットキーバリヤーダイオード)が入っていたりする。

　別のHUBに交換し、ケーブルを吟味した結果、定常的な電源容量不足は一時的に稲妻の警告がでるものの、相当な負荷をかけても（カメラと自前ブラウザーなど）、ほとんど落ちることはなくなった。しかし、今度は、本体そのものが電源を入れてもブートしなくなるというトラブルが発生し始めた。

　必ず起きるということではなく、何度か電源を入れ直したり、HDDにつながるセルフパワーHUBの電源を別にしたり、あとからUSBを接続したりすると正常にシステムが立ち上がるので、それほど神経質になることはないのだが、安心して運用テストに入れるレベルにない。

UARTの字化けはあっさり解決。ボーレートがおかしかっただけ(4/17/2017)
　Tiny13を使ったRaspi電源制御装置も、最初、電圧低下でRaspi3では不安定だったのだが、ケーブルやHUBを交換しているうちに安定して作動するようになっている。この制御装置は、電流量のモニターが出来るので、このまま使いたい、しかし肝心のUARTシリアル出力が盛大な字化けをしているのが気になる。

　で、これを先に直すことにした。久しぶりにオシロを動かして、ボーレートを調べる。明らかに9600bpsのボーレートより遅い（1ビット10.4μsのはずが12μs近く）。ネット情報によれば、Teratermはボーレートが設定画面で自由に変更できるというのでオシロのタイミングに合わせてボーレートを下げてみたが（9600 -> 9000近辺）、不思議なことに全く改善されなかった。

　どうも他の原因が考えられる。自作のソフトUARTのソースコードをじっくり見直した。すると送信期間はボーレートを守るため割り込み禁止（cli();）にしているところを、ストップビットを出した直後、解除（sei()）してしまっているのを発見した。　

　ふーむこれか。もしここで割り込みが入ってしまうと、規定よりストップビットが長くなって字化けする。ただ、シリアル出力は、500msに一回の電流測定のときだけで、かかる時間は、9600bpsで30 字だしてもせいぜい3ms（1文字10ビットで1ms）だ。他と被ることはないはずだ。

　しかし、さらにコードを調べていくと、待ち時間をループでなく8ビットタイマーで作っていることがわかった。それもその割り込みは1ms単位だ。もしかしたら、ペンディングになっていたタイマー割り込みがここで入ってUARTと被るのかもしれない。

　ロジアナでも持ち出して測れば一発で原因がわかると思うが、何しろTiny13は8ピンでプローブに使えるピンが一本も残っていない。面倒なので、ボーレートの調整と、この修正(割り込み解除をひとつずらしただけ)を一緒に直してテストしてみた。

　ピンポーン！見事に字化けはひとつもなくなった。やっぱり被っていたのか。念のため、割り込み解除のステートメントを元に戻してみた。何と、何と。それでも字化けは解消している。被ってはいなかったのだ。

　単なるボーレートの修正だけで直ってしまった。通信ソフトのTeratermのボーレート変更では治らなかったのに何故だ？心残りではあるが、余りこればっかりやっているわけにもいかない。先に進もう。

10インチのHDMIモニターを入れてRaspi環境が改善(4/18/2017)
　現在のRaspi3のOSはJessieで、HDMIコンソールからブートするようになっている。今まではPCのHDMIモニターを共用にしてディスプレイのSWで切り替えていたのだが、電源のトラブルシューティングで頻繁に再起動をする状況ではどうも具合が悪い。　

　例の7インチIGZOパネルをこのときとばかりに使いたいのだが、1920x1080の解像度では、動画を見るのならともかく、コンソールは猛烈に字が小さくなりデバッグなどはとても出来ない。フォントを拡大するコマンドは入れたが、実用性に欠ける。迷った挙句、適当なHDMIディスプレイを別個に買うことにした。

　ウェブで調べてみる。沢山ある。10インチ近辺のモニターは、車載用のTVモニターの需要があるらしい。爆安店で探せば数千円で買えるかもしれないが、買いに行く時間が惜しい。通販でも1万円近くだせばスピーカーまでついた本格的なHDMIモニターが買える。アマゾンで注文する。良い時代になったものだ。

　ほどなく品物が届いた。タッチパネル式のスイッチ、リモコンまでついて立派なものである(1024X600)。動かしてみる。おおお、少し小さいがコンソールを見るには十分だ。これで格段にRaspiの開発環境は整備された。いちいちPCのディスプレイをスイッチで切り替えなくて済む。

　専用のディスプレイが出来たので、Raspi3そのものの整備が楽しくなった。Raspi3はBluetoothもあるし、NOOBSのデスクトップには、既にいくつものブラウザーが動くようになっている。電源問題が先に進まないので、つい色々なことに目移りしてしまう。

　前にも書いたが、Raspi3の性能は大したもので、ウェブサーフィンも殆どストレスを感じない。居間で使っているASUSの古いネットブック（CPUはAtom）より早いかもしれない。感心なことにデスクトップにはBluetoothのドライバーまでインストール済みだ。

秋葉原で久しぶりの買い物。秋月の最大ACアダプターなど(4/21/2017)
　暫くご無沙汰だった秋葉原に仕事の帰り立ち寄り、秋月電子でいくつか部品を買ってきた。これからの電子工作プロジェクトの候補である。現状が迷走しているので、何らかの起爆剤になることを期待している。

・LTC1799
オシレーターチップ。電波時計の電波（JJY　40/60khz）をこれで発生させ、ESP8266などで、ネットのNTP(Network Time Protocol)で得た時刻を標準電波形式にスイッチングする。要するに電波時計リピーター（別経路のリピーターだが）を作ろうというものである。

ウェブサーフィンをしているときに、これを使い、ESP8266のArduinoIDEで作っている記事を見つけた。電波の届かないところでも電波時計が使える。面白そうなのでとりあえずICだけを調達する。

・ソリッドステートリレー (シャープ 8A 250V)
AC機器をリモートで入り切りするために在庫がなくなったので補充した。これまでのESP8266が遊んでいるので、これにウェブサーバーを立てて、ブラウザーからの指示でAC機器を制御する。典型的なIOTの第一歩である。WiFiモジュールは、新しいESP32も買ってあるが、この程度の制御にはもったいないので別の用途を考えることにする。

・4Aの定電圧5V ACアダプター
　Raspi電源制御の切り札、秋月電子内の最大容量の5Vアダプターである。自前で強力な5V安定電源を作る前に、本当に電源容量だけの問題かこれで確かめようというもの。

・ブレッドボード用DIP基板のついたUSBコネクター　　　　
　Raspi電源問題解明で何らかの回路をUSBバスに付加してテストするため。ブレッドボードでハンドリングできるDIPピンのついたUSB　Aタイプコネクター。ブレッドボードそのものは接触不良のかたまりみたいなものだが、何とか藁をも掴む思いである。　　　　　　　　　　

４AアダプターでもRaspi電源事情は改善せず。好い加減あきてきた(4/22/2017)
　当研究所には、5V定電圧ACアダプターなら山ほど揃っている。秋月で買った3Aと2.5Aのものを始め、例のUSBセルフパワーHUBの2.6Aや、2.1Aなど、数えてみたら5つもあった。

　今さら、さらに買い足す必要もないのだが、何となく意地になって４AのACアダプターを思い切って買ってみた（といっても￥900）。帰宅して、とるものもとりあえずまずこのアダプターの実験をする。しかし、残念ながらRaspiの電力環境は好転しなかった。これまでのACアダプターと殆ど変わりはない。

　相変わらず稲妻マークは出るし、時々最初のブートが効かない問題は依然としてなくならない。USBプラグを抜き差しすると変化があるので、アダプターの容量の問題ではなくこのあたりの接触不良の疑いも出てきた。

　ウェブで「電源　ロードレギュレーション向上」などのキーワードで、関連情報を探すが、出てくるのはプロ向けのおおがかりな回路設計の話ばかりで、アマチュアが手軽に試せるようなことは何も見つからない。

　本当は、自前で高性能の3端子レギュレーターなどでACから5Vにする定電圧装置を作るべきなのだろうが、このあたりは、素人なのでとっかかりがなく、もどかしい。

　解決の方向が見えない。ブートを失敗するのは、電源投入時の瞬間的な電圧降下であろうとあたりはつけているが、確認するにも現象が固定化されない（どのACアダプターでも起きる。長時間OFF後はほぼ必ず発生。一旦成功すると、そおあとは失敗しない）。具体的な手段が見つからない。段々飽きてきた。

Raspi3のオーディオ環境整備にはまっている(4/30/2017)　
　そういうこともあるが、このところはRaspi3の環境整備にはまっている。専用のディスプレイでデスクトップ環境が格段に使いやすくなったこともある。

　Raspiのオーディオは無印のころから、これまで全く手を出していない。Raspiのオーディオも結構人気のようである。まずはオーディオ関係を整備することにする。

　Raspi3にはアナログ（単なるステレオジャック）と、HDMI出力、それに情報によれば、入出力ピンにI2Sが出ているということだ。この10インチディスプレイはスピーカーがついているのでHDMIからの音が出るはずだ。

　とりあえずRaspi3のデスクトップのメニューバーにオーディオ選択のダイアログがあったので、これをHDMIにしてみる。ブラウザーで適当な音源を選び音を出す。簡単に音が出た。小さなスピーカーなので音質はお世辞にも良いとは言えない。「音も出ます」程度の音である。

　次は、アナログである。内蔵DACは11ビットというのでこれも音質は期待できない。ヘッドフォンを取り出しジャックにつなぐ。おやあ、シーッと量子化ノイズが耳ざわりだ。11ビットならもうちょっと良いはずだが。

　音を出してみる。小さいスピーカーに比べれば、音はましだが、やはりノイズが気になる。ウェブで評判を調べる。うーむ、このアナログの評価は散々だ。

RaspiAudioの音質不良はrpi-updateで少し改善。Bluetoothも(4/28/2017)
　ウェブをさまよい歩くうち、Raspiのアナログ音の出力は、ここのサイトによるとファームウエアがバグっていてサンプリングビットが1ビット少なく10ビットになっているという情報を得た。（オリジナルはここ）

　ここには、バグの修正版のダウンロードサイトも紹介されている。2012年の古いパッチのようだが、正規のupdateにはなっていない。現在の最新バージョンには反映されていないようだ。ふーむ、恐らく何か別の不具合があってのことかもしれない。

　まあ、ものは試しである。一式をダウンロードして、インストールしたあと、ファームウエアの書き直し、rpi-updateをかける。エラーもなく順調にrpi-updateは終わった。

　音を出してみる。うーん、少しは良くなったか。確かに少しノイズが少なくなったが、音は驚くほど良くなったとは言えない。まあ11ビットDACは、二昔前のPCのサウンドカード程度なのでこれ以上の向上は無理のようだ。

　Raspiオーディオで検索をかけると沢山ヒットする。いわゆるハイレゾオーディオの中継基地として安上がりなのが人気なのだろう（この手のオーディオ機器は信じられないほど高価）が、当研究所は今のところハイレゾ再生には行かないことにしている。

　というので、次はBlueToothでの音の再生にチャレンジした。キーボードは動いたが手持ちのBluetoothヘッドフォン(サンワのMM－BTSH30)は、認識はするものの、音がすぐ切れる。ブラウザーや、デスクトップのScratchという教育ソフトの猫の音もでないので、BlueToothの問題だと放置していたのだが、あるとき、コンソールから、

aplay /usr/share/sounds/alsa/Front_Center.wav

というコマンドを入れたら、何と、Bluetoothでの音の再生に成功した。だとすると、ウェブに沢山情報のあるとおり、bluetoothのオーディオパッケージBluezと、これまでのLinuxのオーディオALSAとの衝突がどこかで起きている可能性が高い。

　Raspi内のどれかのオーディオパッケージをインストールし直せば、うまく行くのかも知れないが、問題は深そうで簡単に行く話ではない。ウェブでは調べた限りでは、こういう話題がヒットしない。解決策が見つかる可能性は低い。これも少々あきてきた。

ESP32-WROOM-32のテストに着手する(5/4/2017)
　というので、このあいだ買ったままになっていたESP-WROOM-32(以降ESP32)を試してみることにした。このESP32はWiFiモジュールESP-WROOM-2（以降ESP8266）のグレードアップ版である。

　中華製のWiFiモジュールには信じられないほど安価なのが多いが、日本の電波機器の技術適合証明、いわゆる技適をとっていないのが殆どである。しかし、ESP32はいち早く技適をとり、秋月からはPCへのUSB-UARTまで装備したブレークアウトボード(￥1480)も売り出された。単体の値段もESP8266と殆ど変わらない(￥550 と￥700)。

　これまでのESP8266の弱点、CPUが遅い、I/Oピンが少ない、SRAMの量が今一つという不満を一気に解消しており、これはお買い得と、少し前、予定もないのに単体と、ブレークアウトボードをひとつづつ買ってしまってある。

　以前ESP8266で画像付きのサーバーを作ったことがあるが、画像を出すだけ一息の時間が必要で、簡単なGPIOの操作ならまだしも、ちょっと手の込んだ遠隔制御には使えそうになかった。それがこのESP32ではだいぶ使えそうである。

　その割には日本ではまだブレークしていないようだ。技適はついているし、秋月などでもオリジナル（Espressif）社のブレークアウト基板を廉価で出しているに不思議だ。調べてみて何となく理由がわかった。

　どうもESP8266ほど周辺のソフト開発環境が進んでいないようだ。ESP32の開発元、Espressif社が、Arduinoではない独自の開発環境　ESP-IDEというのを作ったようだが、そのあたりの情報が不足している。一本道ではなく、いくつもの開発環境があるというのは、初心者にとってはかえって弊害になる。

　検索をかければ、ウェブには山ほど紹介記事が出てくるのだが、どれも今までのものと何か違和感がある。一例をあげれば、ここなどは、懇切丁寧な記事の大部分は、トリッキーな空中配線や、ブレッドボード上の配線法なので、読み流しているうち、急に複雑なウェブサーバーの紹介になってびっくりする。　

　ここのサイトは、詳細なESP32の情報が掲載されている。でも、ここの情報だけで、初心者がESP32を動かすことは難しいだろう。膨大な情報があるが、多すぎて、恐らくどこかで折れたら（書かれている通りに動かないなど）最後、手も足も出なくなるだろう。

　この違和感は、これらサイトの筆者の責任ではない。明らかに電子工作のやりかたがArduinoなどをきっかけに大きく変わってきたからではないだろうか。要するにハードやソフトウエアの複雑さが比較にならないほど大きくなって、全貌を簡単に把握できなくなっているのだ。

　結論から言えば、素人が手を出しにくい。WiFiによるスマホとの連携ひとつをとっても、その実現は膨大な技術の蓄積で可能になっている。本当の初心者なら電子工作はもっと少ない要素でできている8ビットのPICやAVRで経験を積む方が結局早道なのではないか。

　悪態をついてばかりいても先には進めない。とりあえずは開発環境から整備を始めることにする。何しろ沢山サイトはあるが、ちょっと目を通しただけではなかなかわからない。当研究所には、ESP8266を開発したArduinoIDEがある。当然この環境と一緒にしたいのだが、このあたりの解説が少ないのである。

ESP32のWiFiサーバーまであっさり動く(5/10/2017)
　このサイトを参考に、既存のArduinoIDEに、ESP32関係のパッケージをインストールする。ここを見つけるまでは、殆どのサイトが新規にArduinoIDEをインストールするところから始まっているので苦労した。要するに既にArduinoIDEがあるのなら、所定のディレクトリーにダウンロードしたパッケージを解凍して入れるだけで良い。IDEを再始動すれば、すんなりESP32関係がロードされる。

　ハードの方はいたって簡単だ。ブレークアウトボードなら、追加する配線は殆どない。LEDと制限抵抗を適当なGPIOピンにつなぐだけである。電源はとりあえずUSBから貰う。ここも電源問題が大変なようだが、まあ、実験レベルなのでこのまま行く。

　ArduinoのLチカのコードをコピペし、ビルドする。何事もなく、終了した。次は、ファームへの書き込みである。おお、無事に書き込みが始まったようだ。心なしかESP8266より速いような気がするが、これは、ファーム焼きこみのシリアルの速度が921600bpsとべらぼうに早いためで、本体が早いわけではないようだ。

　ファームの書き込み終了のメッセージと同時に、LEDが点滅し始めた。あっけなくLチカ成功である。ブレークアウトボードのおかげで、前の手製のESP8266開発キットに比べると、動作モードをタクトスイッチで切り替える必要がない（勝手にボードでGPIOピンを切り替えてくれる）。

　勢いに乗って、WiFiサーバーまで動かしてみることにする。ESP32のライブラリーにある、SinpleWebServerのソースを読み込み、このサイトを参考に、Lチカで使ったLEDをブラウザーからスイッチするコードに組み替える。

　これもビルド、ファーム書き込みともNO ERRORで終わった。立ち上げる（といっても何もしないで良い）。恐る恐る、PCに戻り、ESP32のIPアドレスを調べ（まだ固定化していない）、該当のIPアドレスでアクセスする。

　やった。小さなメッセージだが、サーバーからの画面が出た。必要な所はクリック可能な色に変わっている。ONのところをクリックする。おめでとうございます。LEDが点いた。とりあえずESP32はウェブサーバーまであっけなく動くことが確認された。

　これから、ESP8266とどの程度高性能なのか調べていくことになるが、紙数も増えてきたので、このあたりで記事を区切ることにする。