IoT何をいまさら(102) ESP-EYE, ESP-IDFでWiFiスキャン

Joseph Halfmoon

ATSAMマイコン関係がこちらへ移動したので、「跡地」にESP-EYEをESP-IDF環境で「やっつけよう」という試みが越してまいりました。AIとか、カメラとかまずは置いておいて、ESP32なんだからWiFiで通信できるところから出発すべきだろう、と。ESP-IDF、資料有りすぎ、読むのが辛いです。イケないけれども伝統の試行錯誤法でアプローチ?

※「IoT何をいまさら」投稿順Indexはこちら

冒頭のアイキャッチ画像に2つ並んでおりますのが、

    • 上:ESP32 DEVKIT-C
    • 下:ESP-EYE

であります。WiFiとBluetoothが使えるお手頃なSoCということで世界中に広まっているEspressif社のESP32を搭載したボードです。上のDEVKIT-Cは定番の開発ボード、下の ESP-EYEは、こちらで取り上げておるのですが、AIoT(AIとIoTの融合を標榜したものか?)を旗印にした、DEVKIT-Cにカメラとマイクを取り付けて、手足(外部端子)を取り外したようなボードです。

ESP-EYEは、顔認識などができるESP-WHOというライブラリ群をもっているので、これを使ってAIカメラ・アプリへ行くという方向性です。とは言え、ESP-WHOを「駆使する」ためには ESP-IDF というSDK的なものを使いこなすのが前提となります。

今までもESP32にはさんざんお世話になっておるのですが、MicroPythonであったり、Arduino環境であったり、お手軽で過ごしてきたので、ESP-IDFに切り替えるのにどうしたものかと考えておりました。最初からESP-WHOへ行くと、Lチカみたいな当たり前のことすらどうして良いか。そこでDEVKIT-CターゲットでESP-IDF使ってLチカしてみましたが、プロジェクトのコンフィギュレーションツール自体が項目多すぎて良く分かりません。そこで

ESP-EYEをターゲットに、ESP32 DEVKIT-Cで普通にやるようなサンプルプログラムをビルドしながら、だんだん慣れようね。

ということで練習をはじめましたです。今回はESP32ならWiFi使えて、ナンボのもんじゃい、ということで、ESP-EYEに WiFi アクセスポイントのSCANをやらせてみたいと思います(といってサンプル・プログラムをビルドして走らせるだけだけれども。)

今回使用したサンプルプログラムは、ESP-IDFをインストールしてあれば以下にあります。

ESP-IDFのインストールフォルダ/examples/wifi/scan/

後で、いろいろ改造して機能強化する予定なので、scan を start という名にリネームして作業しています(関連の CMakeLists.txt の修正の必要あり。)

idf.py menuconfig

ESP-IDFで何が分からないかといって、今のところこの menuconfig が一番です。CUIながらカーソルキーなどで設定できるメニューシステムなのですが、項目多すぎて、何をどうして良いやら目が回ります。立ち上げたTopメニューがこちら。

MENU_CONFIG_TOPここを出発点に、ツリー構造に構成された深いコンフィギュレーションの森が広がっています。

今回はフツーのESP-IDFに付属のサンプルプロジェクトのCONFIGと、ESP-WHOに付属のサンプルプロジェクトのCONFIGを比較しながらその設定を探っていきたいと思います。やはりESP-WHOのターゲットは仕様が上なので標準的な設定とは違う感じです。

その前に1か所、これを修正しないとビルドが通らない件の設定が以下に。階層構造で言うと、以下の場所です。

Component config >> mbedTLS >> Certificate Bundle >> Default certificate bundle options >>

STD_mbedTLS私の環境のデフォルトでは、”Use the full default certificate bundle” にチェックが入っていました。しかし、そのままだとビルドの最後の方で落ちます。2番目の “Use only the most common certificates from the default bundles” にチェック入れるとビルドできます。

Component configは、設定項目多すぎて、上記以外は良く見てないです。おいおい(って何時だ?)

さて、それ以外のメニューで標準的なサンプルとESP-WHOのサンプルで異なったいたのが以下です。Serial Flashのコンフィギュレーション部分です。

標準では以下のようでした。

STD_SerialFlash
標準では、DIO(2線でインタフェース)、40MHz、サイズは2MBと控え目です。しかし、ESP-WHO用のサンプルでは以下のようになってました。

ESP_WHO_SerialFlashQIO(4線でインタフェース)、80MHz、サイズは4MBです。ビット幅と周波数が倍なので、速度的には4倍。やはりAI向けのESP-WHOターゲット機のスペックは上になってました。

ESP-EYEは16MBも搭載している筈なのですが、とりあえずESP-WHOのサンプル用の4M設定でやってみることにしました。

設定後、実際に走らせたときのLOGが以下に。あれれ、間違えてる。QIO設定してないじゃん。DIOのままだ。ま、でも「小さい分には動く(みたい)」なので動作はOKでした。でも次回は修正してみないと。

I (36) boot.esp32: SPI Speed : 80MHz
I (41) boot.esp32: SPI Mode : DIO
I (45) boot.esp32: SPI Flash Size : 4MB

次に差があるのを見つけたのは、Bootloaderのコンフィギュレーション部です。まず標準的な環境では以下でした。
STD_Bootloader
ところが、ESP-WHO対応環境では、”Use custom SPI Flash WP Pin when…”というメニューがあり、その下に ”(7) Custom SPI Flash WP Pin” という表示も見えます。WPってライト・プロテクト?なんだかよく分かりませぬ。メニューそのものが存在しないので、今回はパス(そんなんでいいのか。)ESP_WHO_Bootloader

ビルドして実行

エイヤーの気合だけでビルドしてみます。ビルド、通りました。最後の方は以下のようです。Build
ESP-EYEへのアップロードも成功。

さっそくESP-EYEに仮想シリアル端末を接続すれば、景気よく?大量のLOGが出力されてきます。末尾付近を見ると、アクセスポイント6台を検出しているみたい(当方設置のAPだけでなく、ご近所も含む。)

検出しているところがこちらです。

SCAN_RESULT2
まあ、ESP-EYEでWiFiのアクセスポイントをSCANできることは確かめられたね。

次回は、ESP-EYEから当方設置のAPに接続して通信をしてみる、と。まずは各種マイコンのサーバー機として動作しているRaspberry Pi 3とちゃんと握れるようにするのが基本だな。何か認識するのはその後ということで。

IoT何をいまさら(101) ATSAMD51、ICM、ハッシュ計算をする専用DMAC へ戻る

IoT何をいまさら(103) ESP-EYE、ESP-IDFでWiFi AP接続 へ進む