pyftdiをテスト

pyftdiを動かしてみました。環境はいつもの LinuxMint19 64bit です。

pyftdiのインストール

まずは、インストールドキュメントをベースに進めます。

$ sudo apt-get install libusb-1.0

引き続き、/etc/udev/rules.d/11-ftdi.rules に udev ルールを追加します。

# /etc/udev/rules.d/11-ftdi.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", GROUP="plugdev", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6011", GROUP="plugdev", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6010", GROUP="plugdev", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6014", GROUP="plugdev", MODE="0666"
SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6015", GROUP="plugdev", MODE="0666"

以下の内容を実行して再認識させます・・・が、再認識したのかどうかよくわからなかったので、USBケーブルを抜き差ししました。

$ sudo udevadm control --reload-rules
$ sudo udevadm trigger

pyftdiを使うため、以下のコマンドを実行します。

$ sudo adduser $USER plugdev

・・・が、すでに、plugdevのメンバーになっている旨、表示されました。

テスト用環境の構築

以下のようにして Python3 の仮想環境を作ります。

$ mkdir ~/python3
$ cd ~/python3
$ sudo apt-get install python3-venv
$ python3 -m venv pyftdi-test
$ cd pyftdi-test
$ source ./bin/activate
(pyftdi-test) $ python -V
Python 3.6.8
(pyftdi-test) $ pip install --upgrade pip
(pyftdi-test) $ pip install pyusb pyserial pyftdi

GPIOテストの実施

テスト用のスクリプトがあったのでダウンロードしてきます。

$ wget https://github.com/eblot/pyftdi/raw/master/pyftdi/tests/gpio.py

107-108行目の以下の部分をコメントアウトします。
(コメントアウトしないと、ここで必ずテストエラーになるような気がするのですが??)

        else:
            self.assertTrue(bool((1 << gp) & mask))

で、

$ python gpio.y

としてテストを実行すると、AD7に接続したLEDが消灯⇒点灯しました。

UM232Hモジュール

PythonでFTDIのチップをUSB経由で制御するpyftdiというモジュールを見かけました。ドキュメントをみると、UARTだけではなく、GPIO、SPI(master)、I2C(master)、JTAG(master)としても動作しそうな感じです。

そこで、随分昔から積みボードになっていたUM232Hというモジュールで動かそうとしたところ、PWRのLEDすら点灯しません。dmesgを見ても、なんのログもでていません。USBケーブルを変えても、PCからRaspberry Piに変えても状況は同じです。これは使い物にならん、と捨てようかと思っていたところ・・・・、資料が見つかりました。(もっと早く見つけろよ^^;)

これをパラパラっと眺めていたところ、

という感じで、TXD/RXD、RTS/CTSの他に何やら配線が・・・しかも、電源っぽいのが・・・必要そうです。

さっそく、この通りに接続してみると、

[  507.979206] usb 1-1.5: new high-speed USB device number 5 using dwc_otg
[  508.112740] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
[  508.112779] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  508.112792] usb 1-1.5: Product: UM232H
[  508.112803] usb 1-1.5: Manufacturer: FTDI
[  508.112814] usb 1-1.5: SerialNumber: FTUBIAT4
[  508.183601] usbcore: registered new interface driver usbserial_generic
[  508.183714] usbserial: USB Serial support registered for generic
[  508.201021] usbcore: registered new interface driver ftdi_sio
[  508.201150] usbserial: USB Serial support registered for FTDI USB Serial Device
[  508.201531] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[  508.201771] usb 1-1.5: Detected FT232H
[  508.203415] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB0

という感じで、無事に検出してくれました。

無事にLEDも点灯しています。

参考:データシート(DS_UM232H

台風19号

BME280+ESP32でAmbientに上げているデータによると、21:24頃の965.6hPaが気圧の底のようです。970hPaを切ったあたりからの風はものすごかった・・・。

その後、急速に気圧は回復してきていますが、雨の被害が大きくなってきているようで心配です。風は収まってきたかと思ったのですが、吹返しの風が吹き始めてきました。

約二日間の気圧変化の推移。

CO2センサをポチってみた

最近、眠気とCO2の濃度に関係があるというのを読んでCO2センサを物色しています。少し前までは少し大きめのセンサでそこそこ値段も張っていたのですが、最近はCCS811というMEMSタイプのセンサがでてきているようで、価格もこなれてきました。

そこで、CCS811について(いつもの)Aliexpressで物色して、ポチってみました。CCS811を搭載した基板は何種類かあるようなのですが、SI7021という湿度センサとBMP280(温湿度+気圧センサのBME280の湿度なしバージョン)を一緒に載せたもの、HD1080という温湿度センサを一緒に搭載したものがあるようです。もちろん、CCS811単品のものが一番安いです。

で、せっかくならCO2(の他にTVOCもCCS811は測定できます)だけではなく、温湿度・気圧も測れれば・・・と思ったのですが、意外に気になるのは温度は自己発熱の影響を受けることです。

で、ドキュメントを調べてみると、CCS811は内部にヒーターを持っているため結構消費電力が大きく、Idle Modeでは0.034mW@Vdd=1.8Vなのですが、1秒に1回測定するモードでは46mW、10秒に1回では7mW、60秒に1回では1.2mWの電力を消費します(Vdd=1.8V時)。

また、ENV_DATAレジスタというのがあり、温度・湿度を設定すると、それに応じて測定値を補正する機能があるようです。(スイッチサイエンスなどのサイトでは、オプションでNTCサーミスタでの温度補正ができるように書いてあるところがありますが、製品変更通知CN25-2017でサポートされない旨、記載されています)

したがって、一緒に搭載されている温湿度センサーは、CCS811の補正用ということだと思われます。補正用の温湿度センサーがない場合には、デフォルト値の25℃50%を前提にして動作するものと思われます。

データシート上の書き方としては「外部の温湿度センサが利用できる場合には補正に利用できる」という表現になっていますので、今回はCCS811が単独で載っているものをポチってみました。

BluePillボードへの書き込みアダプタ

少し前に試してみたSTM32F103C8にArduinoのスケッチを書き込む話ですが、USBだけ使いたいというケースがでてきたため、ヘッダピンを半田付けせずに書き込みができるような治具を作ってみました。

端子との接続はインサーキットテスタ用のテストピンを3Dプリンタで作ったホルダーに挿入して、基板にはんだ付けしたものを使っています。ピンの内部にバネが入っていて、端子が伸縮するので接触性は良好です。

実際に使う際には下の写真のようにランドに押し付けて接触させておいて、USBシリアル基板にUSBケーブルを接続します。しばらく押し付けたままにしておく必要があるのですが、基板を大きくせず(=端子を半田付けせず)に書き込みができるようになりました。

redisを触ってみた

key value型のデータベースとしてよく使われているらしいredisをちょっとだけ触ってみた。

ちょっとだけなので、dockerで動かしてみる。

~/docker$ mkdir redis
~/docker$ cd redis/
~/docker/redis$ docker run --name redis -d -p 6379:6379 redis redis-server --appendonly yes  
~/docker/redis$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
755385f9518d        redis               &quot;docker-entrypoint.s…&quot;   11 seconds ago      Up 8 seconds        0.0.0.0:6379->6379/tcp   redis
~/docker/redis$ docker exec -it redis /bin/sh
# redis-cli
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> set ABCDE 12345
OK
127.0.0.1:6379[1]> get ABCDE
&quot;12345&quot;
127.0.0.1:6379[1]> get CDEFG
(nil)
127.0.0.1:6379[1]> keys *
1) &quot;ABCDE&quot;
127.0.0.1:6379[1]> lpush LST 1
(integer) 1
127.0.0.1:6379[1]> lpush LST 2
(integer) 2
127.0.0.1:6379[1]> lpush LST 3
(integer) 3
127.0.0.1:6379[1]> lpush LST 4
(integer) 4
127.0.0.1:6379[1]> llen LST
(integer) 4
127.0.0.1:6379[1]> lrange LST 0 4
1) &quot;4&quot;
2) &quot;3&quot;
3) &quot;2&quot;
4) &quot;1&quot;
127.0.0.1:6379[1]> 

なるほど、簡単そうだ。

雷センサAS3935

ずいぶん前に秋月で買った雷センサーAS3935を使って、しばらく前に雷センサーロガーを作りました。

仕様としては、CPUにはPIC16F18857を使用、時計ICにRTC8564NBを使用したRTCモジュールに、液晶にI2C接続の液晶モジュールを使用、記録は24LC256のE2PROMに保存するというものになっています。電源は単三電池が3本ですので、持ち歩くにはやや大きいものになっています。電池の持ちとしては約3ヶ月程度くらいと思います。

制作後、最初は作業卓の近くの窓際に置いていたのですが、PCや3Dプリンタなどのノイズをかなり拾うようで、妨害イベントがかなり検知されました。弱い雷もあるにはあったのですが、鉄筋コンクリート造りでは肝心の落雷を検知せずに、ノイズが偽の落雷イベントとなっていると思われるものが少なくありませんでした。そこで、途中から部屋のもう一つの窓際に置いたところ、PCや3Dプリンタなどのノイズの影響は受けなく鳴りました。しかし、この窓も窓の外は2〜3mほど離れて隣の棟が建っており、電波状況としては良くなく、AMラジオも内蔵バーアンテナでは受信できません。(ちなみに、AS3935は雷が発する500kHz近傍のノイズを電波として受信して動作している)

今年は近所で雷が鳴るということもあまり多くなく、以降の動作確認が難しかったのですが、昨日は関東地方でかなり雷が鳴ったようで、自宅近くでもそこそこ雷が鳴りました。

やはり鉄筋コンクリート造の屋内設置で、窓際とはいえ窓の外も鉄筋コンクリート造の建物が建っているという条件はかなり厳しいようで、かなり反応はするものの、検知できる条件は雷の音がすでに聞こえる状況くらいでした。

屋外設置する方法を考えたいところですね。

ESP32 NTP時計にBME280を追加など

前回の記事のESP32 NTP時計にBME280を追加して気圧・温度・湿度を表示するようにしてみました。(台風15号が直撃するらしい、というのがきっかけです^^;)

ついでに、表示した値は1分間に1回、MQTTで自宅内のMQTTブローカに向けてsubscribeするのと、Ambientに送信するようにしました。

また、併せて、昔作ったLPS331APを使用した電池タイプの気圧計に3Dプリンタでケースを作ってみました。

青いほうがESP32+BME280、黒いほうがPIC1823+LPS331APです。LPS331APに比べて、BME280の方が1.5〜2hPaほど高めの値が出るようです。また、BME280の方が圧倒的に値が安定していて安定性では比較になりません。
気温については、置いている場所がルータや無線LANのアクセスポイント、スイッチングハブ、ポータブル温冷庫などが置いてるところの上なので、結構温度は高めに出ています。(温度は湿度にはもちろん影響していますが、気圧には影響はなさそうです)

Ambientに気圧をアップロードしてみた結果は以下のような感じです。

上の画像が送信し始めてしばらくの様子です。台風15号は小型なので、影響が出てくるのが遅いようです。また、このグラフでもBME280は値が安定していることがわかるかと思います。

しかし、接近し始めるとどんどん下がっていっています。

【追伸】夕方頃にはこんな感じになりました。もっとも低かったのは、朝4時38分の977.53hPaのようです。

ちなみに、天気図はこんな感じ。台風15号は小型で強い台風だったので、気圧が急激に下がり、急激に回復したようです。

Windows10 1903でgrubに対応・・・???

Jumper EZbook3 Pro はその後、増設したSSDを交換(32GB⇒240GB)して、Windows10をSSDに移動、標準のeMMCはLinux Mint19を入れ直して使っています。で、eMMCのLinux側からは事故等でWindows10を触ってしまわないように、ブートオプションでSATAを禁止してあります。

で、一昨日、翌日(つまり昨日ですね)のお出かけの前に Jumper Ezbook3 Pro のセキュリティアップデートをかけるために増設したSSD(240GB)に移してあるWindowsを起動したまま放置していたら、更新して〇〇になっていたので、更新して再起動を選択したら・・・1903のインストールを始めやがりました。

そしてこれが悪夢の始まりでした。

1903のインストール完了(かな?)の後の再起動をしたら、Windowsのブートローダがいません

当然、Windowsが起動できるはずもありません。しかたがないので、そのまま持参せずにおでかけ(何のためのノートPCなんだか・・・)しました。

そして、帰宅後に、修復を試み始めたのですが、ブートローダの修復にはWindowsのインストールメディアが必要なことがわかりました。で、1903のインストールイメージを持ってきたら・・・・4.8GBあって、1層のDVDメディアでは容量不足で書き込めません。BD-Rメディアにも書き込めません。

しかたがないので、別のPC上のWindows10でメディア作成ツールでUSB起動のメディアを作成しようとすると、長い長い作成過程のあと、「0x80042405 0xA001B」というエラーで作成ができません。このコードだけ表示するエラー、何が原因かさっぱりわからないので、ものすごく頭にきます。

ネット上にたくさんある、WindowsのHowTo的なページも1903でのメディア作成の方法については肝心な部分が暈してあるものが多く、実際のところはトラブルが多いのではないかという気がします。

悪戦苦闘して、なんとか起動メディアが作成できたのですが、どうも、USBメモリのパーティションテーブルがMBRになっているとダメで、GUIDパーティションテーブルでUSBメモリが初期化されていて、しかもWindows上で領域のフォーマットがされていないとダメな感じがします。(ひょっとしたら、NTFSも条件かもしれない)

しかし、これで起動してもインストール済みのWindows10のアップデートかクリーンインストールかを選択する画面しか出力されず、ブートローダのインストールはできませんでした。

結局、eMMC側のLinuxMint19でSATAを禁止するのをやめました。具体的には、/etc/default/grub に記述してあった、「GRUB_CMDLINE_LINUX_DEFAULT」の起動時オプションの「libata.force=disable」を削除しました。削除後は、

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

として grub を更新して再起動、ここでSATA上のWindowsが見えるようになっているはずなので、再度

$ sudo grub-mkconfig -o /boot/grub/grub.cfg

として grub を更新して grub のエントリーにWindows10を追加させました。

すると、eMMCからの起動時に grub 上でWindowsが起動できるようになりました。実際には更新は完了しておらず、なんどかまた再起動した後に、無事に1903になりました。

結局のところ、grubを検出すると、Windows10の更新プログラムはブートローダをインストールせず(というか消去して)、grubに任せるような挙動になっているのかもしれません。自分はLinuxとWindowsで環境をキッチリ分けたいので、以前のやり方が気に入っていたのですが、今後はダメなのかもしれません。

ちなみに、壁紙が以前より明るくなっているのですが、自分は嫌いです。

ESP32 NTP時計

ESP32モジュールと昔買って余っていたグラフィック液晶でNTPで時刻取得する時計を作ってみました。部屋には電波時計があるのですが、鉄筋コンクリートの構造だと全然時刻合わせができませんでした。今だと電波時計よりも無線LAN+NTPの方が便利かもしれません。ファームウェアはPlatformIOで作ってみました。

今のところは画面は上半分しか使っていませんが、I2Cの端子は空けてあるので、下半分はBME280モジュールを追加して温湿度+気圧を表示するか、ネットワークの状態を監視して状況を表示するか、そのあたりで考えています。あるいは、アナログっぽい表示にするかもしれません。

それにしても昔の液晶モジュールなので、インタフェースがパラレルで配線本数が多くて大変です。あと、GPIO34以降は入力専用であることに気づかず、表示が出なくてハマりました。

ケースはこれから適当に現物合わせで設計して3Dプリンタで出力しようかと思います。