MAiX M1nを試してみる

秋月で買って積みボードになっていたMAiX M1n nanoを試してみます。秋月に新商品として出ているのを見て、こちらの動画を見て買ってみたものの、そのまま積みボードになっていました。

MaixPy IDEのインストール

こちらのページを見てMaixPy IDEをインストールしますが、まず、readme.txtをみると、

1. Firmware MUST >= 0.4.0_44 !!!!!
   Firmware MUST >= 0.4.0_44 !!!!!
   Firmware MUST >= 0.4.0_44 !!!!!

    Download firmware from here:  
        ------------------------------------------------------------------------------------------------------------
            http://dl.sipeed.com/MAIX/MaixPy/release/
            http://dl.sipeed.com/MAIX/MaixPy/release/master ( auto build from master branch (development commits, may not stable) )
        ------------------------------------------------------------------------------------------------------------

ということで、ファームウェアバージョンは0.4.0_44以上じゃないとダメということです。たぶん、MicroPythonのバージョンだと思うのですが、確認するとv0.5.0でした。なので、そのまま進めます。
で、IDEの方をダウンロードしようとしたところ、いきなりダウンロードで引っかかってしまいました。理由はいまいちわかりませんが、wgetで引っ張ってきたらダウンロードできました。

$ wget http://dl.cdn.sipeed.com/maixpy-ide-linux-x86_64-0.2.5.run
--2020-10-11 23:29:08--  http://dl.cdn.sipeed.com/maixpy-ide-linux-x86_64-0.2.5.run
dl.cdn.sipeed.com (dl.cdn.sipeed.com) をDNSに問いあわせています... 47.89.66.145
dl.cdn.sipeed.com (dl.cdn.sipeed.com)|47.89.66.145|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 85063710 (81M) [application/x-executable]
`maixpy-ide-linux-x86_64-0.2.5.run' に保存中

maixpy-ide-linux-x86_64-0.2.5.run     100%[=======================================================================>]  81.12M  8.30MB/s    in 12s     

2020-10-11 23:29:25 (6.58 MB/s) - `maixpy-ide-linux-x86_64-0.2.5.run' へ保存完了 [85063710/85063710]

$ sha256sum maixpy-ide-linux-x86_64-0.2.5.run 
2641082c56105a7c33b2abc319b3b76fc022601e234b4f6379edd90c62a6a5c2  maixpy-ide-linux-x86_64-0.2.5.run
$ chmod +x maixpy-ide-linux-x86_64-0.2.5.run
$ ./maixpy-ide-linux-x86_64-0.2.5.run 

チェックサムもreadme.txtと一致して問題ないようなので、実行属性をつけてインストーラを実行します。実行すると、MaixPy IDE 設定ウィザードが起動します。(日本語で表示されました)

インストール先ディレクトリの指定、使用許諾への合意、インストールの順に進みます。インストールはすぐに終了します。

メニューに追加されたMaixPy IDEを起動すると、サンプルプログラムを読み込んだ状態になります。

左下にある緑色のチェーンのアイコンをクリックすると、MaixPyと接続するためのシリアルポートを聞いてきますので、ttyUSB0などを適切に指定します。しばらくすると、下の方にファームウェアバージョンなどが表示されて、チェーンのアイコンが赤くなります(クリックすると切断できます)。で、その下の再生ボタンをクリックすると、コードを実行するようで、FPS表示が出ます。

一方で、切断した状態で、「ツール」→「ターミナルを開く」→「新ターミナル」でポートとしてシリアルポートを選択すると、シリアルコンソールが開きます。で、ターミナル側の再生ボタンを押すと、RPELでコードを実行するようです。

冒頭の動画では、シリアルコンソールの右上部分にカメラ画像が表示されるのですが、残念ながら表示されませんでした。ぐぐってみると、PC側のUSBコントローラによって出たり出なかったりがあるようです。USB2.0のオンボードホストでは動作はするけど画像は出ない。USB3.0のHUBの先だとそもそも全く認識しませんでした。

おまけ

いろいろ調べている中で興味深いな、と思ったのが、K210のベンダーであるCanaanについての記事がいろいろあるこちらのページです。

PCに外付けHDDを増設

いま使っているメインのPCにHDDを外付け増設しました。

目的は、新規のLinuxMint環境立ち上げです。

今回はディスクの負荷がかかりそうでSSDにしたかったので、USBメモリ起動ではなく、eSATAの外付けHDD起動にしました。(eSATAなのは使っているマザーボードが古いからです。これでも自宅最速で、Core i5-3570K + 16GBという古さなのでw)

で、すでに内蔵でSSDが2台(Windows用とLinux用)が入っていますが、これらには干渉させたくありません。危険なのはgrub関連です。初期のインストールはディスクなしの別のPCで行うとして、その後のアップデート時が危険です。ですので、起動したら、他のディスクが見えなくなるように工夫します。

1.インストール

インストールUSBを作成して、インストール対象とは異なる別のPC(ターゲットのPCは棚に組み込んでいて、中を開けるのが大変なので)にインストール先のSSDだけを接続して、インストールしました。
この辺は特に変わった手順はないので、問題ありません。
インストール完了後、各アップデートをかけておきます。

2.grub設定

インストール対象とは異なる別のPCに接続したまま、grubの設定を行います。/etc/default/grubを開いて、GRUB_CMDLINE_LINUX_DEFAULTの行を編集します。

GRUB_CMDLINE_LINUX_DEFAULT="libata.force=1:disable,2:disable,6:1.5Gbps"

パラメータを上記のようにしましたが、これらは最終的なターゲットPCに合わせて設定します。
それぞれ番号がついていますが、BIOSでついている番号とは一つずれていました(BIOSは’0’オリジン、Linuxカーネルでは’1’オリジン)。1,2はそれぞれWindowsとLinuxの内蔵SSDで、これらは禁止しておきます。6は今回の外付けSSDでリンク速度を1.5Gbpsに落としておきます。

これで、update-grubをかけます。

3.ターゲットPCで起動

update-grubをかけたらシャットダウンして、SSDをターゲットPCに移動して起動して問題ないことを確認します。

あと、いつもの時計が狂うのを治すために、

~$ timedatectl set-local-rtc true
~$ timedatectl status
               Local time: 土 2020-10-10 13:49:11 JST
           Universal time: 土 2020-10-10 04:49:11 UTC
                 RTC time: 土 2020-10-10 13:49:12    
                Time zone: Asia/Tokyo (JST, +0900)   
System clock synchronized: yes                       
              NTP service: n/a                       
          RTC in local TZ: yes                       

Warning: The system is configured to read the RTC time in the local time zone.
         This mode cannot be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.
~$ 

として、RTC timeをJSTに設定しておきます。

4.余談

Core i5-3570Kなので、だいぶ古いのですが、特に大きな不満はないんです。4コア4スレッドですが、Linuxがメインなので、シングルスレッドがそこそこ出ていればいいかなぁ、と。新しいCPUのベンチマークを見たりもしていますが、シングルスレッドだとそんなに劇的には変わらない。
あ、でも、なにかビルドするときはマルチスレッド性能が高いとうれしいかも。Ryzenで1台組んだら幸せになれるかな?(RyzenとLinuxの相性?ってどうなんだろう?)

CPUPassMark
Single CPU
PassMark
Single Thread
Ryzen 5 36006C12T178532583
Ryzen 3 31004C8T117652441
Core i5-3570K4C4T@3.4GHz49292046
Core i3-32202C4T@3.3GHz21961749
Core i3-21202C4T@3.3GHz19051522
Athlon 5350 APU4C4T@2.05GHz1828710
Core i3-2120T2C4T@2.6GHz14621116
Core2 Quad Q66004C4T@2.4GHz1757953
Core2 Duo E74002C2T@2.8GHz9631083
Ryzenは「今、組むとしたらこの辺のかなぁ?」というもの。Core i3はどれだか忘れちゃったので、それっぽいものを全部載せた。Athlonは普段のWeb検索用。Core2はWindows10をクリーンインストールし直してあって、インストール手順などの確認用。

WebARENAでUbuntuサーバを立てる(5)

WebARENAで運用しているプライベートなサーバ(といっても、今はMQTTで取得したいろんなセンサーの値をグラフ表示しているだけ)ですが、本日、突然、センサーのESP8266/ESP32の各機器がサーバ(MQTT broker)に接続できなくなりました。OLEDディスプレイを持っているものに表示をさせていたので、その旨わかったのですが、他の各機器も全滅しました。Nginx+Flaskで構成している表示系もその時刻でピタッとデータの表示が止まりました(データが来ないのだから当たり前)。

で、どうしようかなー、と思ってWebARENAにログインしてみると、Ubuntu20.04にアップグレードできるよ、という表示が出ていました。どうしよっかなー、と思ったのですが、どうせアップグレードしなくてはならないのだから、ということで、先にアップデートしてしまいました。

$sudo apt-get update
$sudo apt-get upgrade
$sudo reboot
$sudo do-release-upgrade

としても、「アップグレードを全部適用してからやれ」と却下されます。

$ sudo apt-get upgrade
$ sudo apt upgrade
$ sudo do-release-upgrade

として、apt でアップグレードを実行してからだとOKになります。(実際に適用されるものもあります)
apt-get と apt で何が違うのかわかりませんが、とにかく、なんとか Ubuntu 20.02 にアップグレードできました。

・・・が、もちろん、回復はしていません。systemctl で見てみると、Flask 周りが全滅っぽいです。

$ python3 -V
Python 3.8.2

ということで、Python3 のバージョンは3.8系になっていました。pip3は入っているようなので、

$ sudo pip3 install --upgrade pip
$ sudo pip3 install paho-mqtt Flask uwsgi Flask-HTTPAuth

として必要なものをインストールしてから、

$ sudo systemctl restart uwsgi.service
$ sudo systemctl restart bme280.service
$ sudo systemctl restart css811.service
$ sudo systemctl restart mhz19b.service
$ sudo systemctl restart app.service

として関連サービスを再起動します。これで、ESP32を使っているものは復活しました。(これはこれでいまいちわからないところですが、趣味サーバなのでこれ以上の追求はしないことにします)

しかし、ESP8266で動作しているものが復活しません。Arduinoのログで見ると、どうもMQTTで接続する際のfingerprintのチェックでコケているようです。ホストのfingerprintを

$ openssl s_client -connect example.com:8883 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin

として採取し直してやると、確かに違う値になっていました。つまり、サーバ側の公開鍵が変わったことを意味する・・・はずです。で、思い当たることといえば、WiFiClientSecureで使うLet’s Encryptの鍵の更新が起こったのではないか、ということです。そこで、 /var/log/letsencrypt/letsencrypt.logを見てみたところ、

2020-10-02 08:xx:xx,xxx:INFO:certbot.main:Renewing an existing certificate

という行を含む大量のログがあり、確かに証明書の更新がかかっていました。

とりあえず、各ESP8266側のArduinoのソースコードの fingerprint を更新してやると、データが送信できるようになりました。しかし、このままだとまた2ヶ月後くらいに同じ現象が発生します。簡単な対策はfingerprintのチェックをやめることなのですが、MQTT brokerのセキュリティをfingerprintのチェック+ユーザー名/パスワードとしているので、DNSをごまかされるとユーザー名とパスワードがバレてしまいます。大したデータを流しているわけではないのですが、抜かれたユーザー名とパスワードでMQTT brokerに接続されると、あまりよろしくありません。

さて、どうしたものでしょう。

一方で、ESP32の方は、証明書の更新がかかったのに大丈夫なのか?という疑問が残りました。

が、ここでESP32に追加している証明書はルート証明書なので、大丈夫だったのでしょう。しかし、いつか有効期限が来るはずなのですが、どうやったらわかるのだろう??

うーむ。

CCS811で空気品質測定(3)

補正パラメータであるBASELINEレジスタですが、CCS811では電源を切ったら忘れてしまいます。デバッグのために何度か電源OFF/ONを繰り返していると、だんだん収束までの時間は短くなっているようですが、それでも忘れてしまうことには変わりありません。

まあ、連続通電すればいいか、とも思ったのですが、やはり気になって保存するように修正してみました。

“CCS811で空気品質測定(3)” の続きを読む

CCS811で空気品質測定(2)

センサー側は動くようになったので、今度はブラウザで見えるようにしてみます。

1.Flaskのアプリケーションファイルを作成

Blueprintでアプリケーションを分割してあるので、その分割したモジュール作成という形(言い方が適切かはわかりません)になります。今回は似た構成のモジュールをコピーして作ります。

まず、アプリケーションのファイル一式をコピーします。

/var/www/app$ sudo cp -pr bme280 css811

ファイル名を一括変換します。

“CCS811で空気品質測定(2)” の続きを読む

CCS811で空気品質測定(1)

CO2測定のセンサとして、CCS811も買ってあったので、そちらを動かしてみます。CCS811はTVOCという値も測定できるのですが、代わりにCO2の濃度がCO2自体ではなく、eCO2という代替値になります。

CCS811は温度と湿度を補正用のパラメータとして設定してやる必要がありますので、そのためのセンサーも必要になります。湿度まで取るのが大変、という場合には、サーミスタを接続して温度を取得することはできそう。それすらケチりたい、という場合には、温度も湿度も決め打ちで動かすことになります。

今回、CCS811を取り付けた基板は、BME280を搭載可能なオリジナルのESP8266ボード回路図)で、CCS811に必要になるnWAKEとnINTはそれぞれ、GPIO15とGPIO14に割り振ってあります。(まあ、実際のところは追加の2本は必要なかったようで)

で、ソフトウェアの方は、やはりBME280のデータをMQTTで送信するArduino環境のソースを改造して使用します。ただし、CCS811は継続的に動作させないといけないようなので、DeepSleepは使用しません。また、CCS811の方はライブラリとして、AdafruitのCCS811のライブラリを使用させてもらいました。

“CCS811で空気品質測定(1)” の続きを読む

TTGO T-Camera再び(1)

TTGO T-Cameraは今もなお3Dプリンタを監視しています。このときの状態から変わったのは、3Dプリンタ自体にABSで出力するための囲いを作ったこと、そして囲いを作ったら、T-Cameraを支えている柱がPLAでは熱で曲がってきてしまったので、ABSで作り直したことくらいです。そして、ずっとIPアドレスなどの情報をOLEDに表示し続けていたので、(高温下で使ったこともあるでしょうが)すっかり画素が焼けて、画素がまだらになっています。このT-Cameraには、このまま天寿を全うしてもらおうかと思います。

ただ、実はT-Cameraは2台買ってあったので、もう1台あります。こちらはほぼ未使用なので、今度はこちらに18650のリチウムイオン電池をつけて、電池駆動をしてみたいと思います。

“TTGO T-Camera再び(1)” の続きを読む

MH-Z19Bセンサのオートキャリブレーション

作成したCO2センサーですが、値が600ppm以下になってくれません。AutoCalibrationをONにしているので、通電して24時間での最小値を400ppm扱いしてくれるはず・・・と思ったのですが。

・・・と思ったら、やっとキャリブレーションが効いたようです。

これは、コマンドでオートキャリブレーションのON/OFFができるようにした方がいいかもしれない。

ちなみに、左側の天井を突き抜けているのは、部屋を締め切ってエアコンを使った時。センサー自体は5000ppmまでの値を返してきますが、細かい値が見えなくなるので、chart.jsで表示の上限値を2000ppmに制限しています。午後5時前に、部屋の窓を開けたら下がってきました。5時過ぎに部屋のドアも開けて、風通し最大(笑)にしたら、この時の表示で750ppmくらいまで下がりました。7時半くらいに窓の外に出したらさらに下がりました。

・・・・そして、9時前に、ついにオートキャリブレーションが働いて、過去の最小値を400ppmとして扱ってくれるようになりました\(^o^)/

思ったよりもCO2が増えるのは速い

昨晩MH-Z19B CO2センサを使って作成した測定環境ですが、今日は暑いので窓を閉めてエアコンをつけてみました。6畳ないくらいの部屋なのですが・・・

MH-Z19B CO2センサによるCO2測定グラフ

窓を閉めてエアコンの電源を入れたら、30分くらいで2000ppm近くまで急上昇しました。

まだ半日くらいしか経ってないので、ONにしてあるオートキャリブレーションの効果がでてないと思います。(オートキャリブレーションは24時間くらいでその間の最低値を400ppmとみなすように補正がかかっていくらしい。このグラフで600ppmちょっとのあたりがそのあたりなのかも?)

とはいえ、わずか30分くらいで大きく上昇することはわかりました・・・。