ESP32CAMモジュールを買ってみた

コメントする

Amazonで1999円で謎のショップから出品されていた、M5Stack ESP32CAMモジュールを試しに買ってみました。

Amazon | M5Stack ESP32 Camera Module, OV2640 2 Mega Pixels Camera 1632 1232 UXGA, With Type C Port and 3D WiFi Antenna, Mini Camera Board for Arduino, Raspberry Pi 3B/3B+ and Pi 2B B+ IOT DIY | M5Stack | パソコン・周辺機器 通販

一応、正規品はこちらです。

Aliexpress.com： M5Stack Storeより信頼できる ホームオートメーションキット サプライヤからM5Stack公式ESP32カメラモジュール開発ボードov2640カメラタイプ c木立ポート3d無線lanアンテナミニカメラボードを購入します

ケースを開けてみると、中国からボードを買うときのおなじみの袋に入ったモジュールと、両面テープ式のヒートシンクが入っていました。

届いたものは、ケースには一応M5STACKのラベルが貼ってありますが、FCCやTELECに関する表記は一切無く、中国国内用もしくはコピー品なのではないかと思います。
ボード自体はM5Stack Storeで売られているのと同じもののようです。


USB type Cケーブルは付属しませんので、持っていない場合は別途購入の必要があります。

技適は通っていないと思われますが、ちょっと通電してみました。
デモ用のWebカメラアプリが入っており、以下の動作をします。

・ESP32はアクセスポイントモードで動作。SSIDはM5Cam、パスワードは無し。同時1アクセスのみ
・ESP32CAMのアドレスはhttp://192.168.4.1
・上記およびhttp://192.168.4.1/jpg_stream にアクセスするとJPEGファイルのストリーミング
・http://192.168.4.1/jpg は静止画取得
・解像度はVGA

静止画は以下のようなものです。
レンズの画角は28mmか27mm相当かと思います。監視カメラ目的にはちょっと狭いかもしれません。

ストリーミングの場合は、概ね80～140msec / frameくらいの時間がかかりますので、7～8fpsのスピードです。
ただ、ソフトでエンコードしているのか、チップが発熱します。そのためにヒートシンクが付属しているようです。
技適を通す場合はWROVERモジュールのようにチップ部分をケーシングする必要があると思いますが、その状態で長時間ストリーミングで使って大丈夫なのかどうかは気になります。

何か目的があって購入したわけでは無いので、しばらく積みボードになりそうです。

M5Stack FIRE（GO）用psRAM有効ファームウェアが公開

コメントする


M5Stack GO用の新しいファームウェア0.16が公開されていました。このバージョンにはpsRAMバージョンがあります。
GOにはpsRAMは載っていませんので、事実上これがM5Stack FIRE用最新ファームウェアということになるかと思います。

M5GO/firmware/v0.16-psram at master · m5stack/M5GO

早速FIREに入れてみたところ、psRAMが有効になっていました。
領域が2MBしか無いのがちょっと謎ですが。

>>> import micropython
>>> micropython.mem_info()
stack: 752 out of 31744
GC: total: 2049088, used: 33664, free: 2015424
 No. of 1-blocks: 390, 2-blocks: 107, max blk sz: 450, max free sz: 97919
>>>

今後出荷されるFIREではこの0.16-psram版がインストールされてくるのではないかと思います。
以前のFIREに入っていた0.15ではpsRAMが無効になっていました。

M5Stack Fire: psRAMが有効になってない・・・ – 楽しくやろう。

もっとも、このファームウェアはM5CloudでスマホでBlockyという環境がデフォルトなので、それに興味が無ければ以下の記事で紹介したv0.4.0のほうが良いような気もします。

M5Stack FIRE: psRAMはファームウェアを入れ替えたら動きました – 楽しくやろう。

ベアメタルRPi版MicroPythonのI2C.writetoを修正

コメントする

ちょっと間が空きましたが、ベアメタルRaspberry Pi版MicroPythonのメモです。

先日、フォーラムのこちらのやり取りで、I2C.writeto()のrepeated STARTの仕様を私が間違えていたことが判明しましたので、その修正を行いました。

I2Cのrepeated START自体は、以前実装した際にケアしていました。
当時の記事は以下です。

I2Cクラスを追加（RPiベアメタルMicroPython） – 楽しくやろう。

記事中では、writeのあとreadする場合のrepeated STARTについての記載は正しいのですが、writeのあとさらにwriteする場合については間違っています。
具体的には

しかし、中レイヤのAPIでstopパラメータを使えばとすることで同等の処理が行えるはずです。

の部分です。

この「同等の処理」とは1行目の0x40のあとに2行目のbufが連続して送られることを指しているのですが、I2Cの仕様としては、このコードは

・START→スレーブアドレス→0x40→pseudo STOP
・repeated START→スレーブアドレス→bufのデータ

という信号を生成するべきなので、0x40とbufを連続して送ることはできません。

というわけで実装をちょこっと修正しました。

連続してデータをwriteする仕組みについては、現在議論されているPR4020の仕様（I2C.writeto(addr, [cmd, data])という記法を許容。cmdとdataは連続して送信される）を実装する際に役立ちそう（かつ、I2C.writeto_mem()の実装で使用している）なので温存し、新たにi2c_write_start()という関数をi2cドライバに追加しました。

i2c_write_start()は、データ長0xffffのwriteを行う（ただしFIFOには何も書かないまま）関数です。STARTビットを送り、続いてスレーブアドレスを送り、その時点でFIFOが空なら送信データ待ち（STOPは送らない）になります。
また、呼ばれたときに直前のwriteが終了していない場合にはFIFOをリセットすることによってpseudo STOPを送信させます。
ソフトウェア実装I2CにおいてSTARTビットを送信する低レイヤAPIであるstart()に似ていなくもないのですが、Raspberry PiのI2CインタフェースはレジスタにWriteかReadかを設定しないと通信を開始できないので、start()の代用にはなりません。

MicroPythonからは、I2C.writeto()を呼ぶと、
i2c_write_start(addr, stop)　→　i2c_write(addr, buf, len, stop)
の順に実行されます。

直前のI2C.writeto(buf, len, stop)において、stop=FALSEだった場合には、続くI2C.writeto()を実行する際にpseudo STOP + repeated STARTが送信されます。

たとえば

i2c.writeto(60,bytearray([0,1]),False);i2c.writeto(60,bytearray([4]))

を実行すると、以下のような信号が生成されます。

このrepeated STARTの部分を拡大すると以下のようになり、STOPへ移行していないことが分かります。

これで修正はできたのですが、残念ながらSSD1306のドライバが使えなくなってしまいました。
ハードウェアI2CでSSD1306を使うには、0x40の後に送信データをコピーするというメモリ利用効率の悪い方法を使うか、前述のPR4020の新しいAPIを使う必要があります。
PR4020の仕様が固まったらなるべく早期に実装したいと思います。

ところで、嬉しいことに先日Adafruitさんから、このベアメタル版MicroPythonについてtweetされました。

今のところ、ブログのアクセスが増えたりということは無いですが、ちょっとは知名度が上がったかも？