開発の記録

今まで紆余曲折ありましたが、ようやくI2CからMQTTまでのパスが通りました。 RTCから「秒」を１秒毎に読んでMQTT brokerに送る動きをYouTubeに紹介しています。

同じく書き込み動作も再確認しました。

I2C-COMのrevisionを3->3.1にした（戻り値を全て2桁の16進数にした）ので再度動作を確認しました。

binary1バイトを16進で表現する際に、00~FFとASCIIコードで2文字要することを明記した。

USB (1) 規格上の上限は5m (2) USB延長ケーブルが市販されている 　これを使えば20m I2C (1) I2Cは元来基板上でいくつものデバイスを芋づる式にぶら下げて使うもので、長さに特に規定があるわけではない（数m延ばせる可能性はあるがirregularな使い方） (2) １対１でいいなら延長ケーブルが市販されている 　これを使うと数十mいけるらしい Ethernet 規格がたくさんあるのでこちらを参照。 100m程度から数10km程度まで幅があり長距離には向いているが、tranceiverやケーブルの価格を考えると多くのセンサーをこれで１対１で繋いでいくのは現実的ではない。 ※センサーを部屋のあちこちに複数個置くようなケースだと有線はあまり現実的とは思えない。２個以上使うのが見えているなら無線化を指向するべきだろう。

前回はNode-REDを使ってCloudMQTTに繋ぎました。 今回はPython3を使って繋いでみました。 オリジナルはここです 。 #                   Nov/27/2018 # # ------------------------------------------------------------------ import  sys from time import sleep import paho.mqtt.client as mqtt # ------------------------------------------------------------------ sys.stderr.write("*** 開始 ***\n") host = 'Server name' port = xxxxx topic = 'topic_1' client = mqtt.Client(protocol=mqtt.MQTTv311) client.username_pw_set('User', 'Password') client.connect(host, port=port, keepalive=60) client.publish(topic, 'Good Afternoon!!') sleep(0.5) client.publish(topic, 'こんにちは') client.disconnect() sys.stderr.write("*** 終了 ***\n") # ------------------------------------------------------------------ ※ host = 'Server name' port = xxxxx client.username_pw_set('User', 'Password') は適宜変更を要します。 以上を実行させると こんな感じに出力されます。 以上

DFRobot社のGravityシリーズ というのがあるようです。センサー素子が載る子基板のコネクタはPH2.0-4pのようです。 Gravity 4Pin IIC/I2C/UART Sensor Cable (10pcs)の仕様は、 "One side is PH2.0-4p connector and the other side is XH2.54 DuPont port. " だそうで、PH2.0-4pは2.0mm pitch、XH2.54は2.54mm pitchです。 PH2.0-4pはGroveとピン配列も違いますね。 各社統一の気配は全く感じられません。

IoT実用化講座10はこちら

非常によく書かれている記事があるのでここを参考にします。 Node-REDにダッシュボードを追加してセンサーデータを可視化する ここまで

MQTT brokerを立てるより外部サービスを使うのが圧倒的に簡単です。ここではCloudMQTTを使いました。 Node-REDをMac上で動かしてMQTT publisherとし、CloudMQTTをbrokerにして、CloudMQTT上でmessageが届くことを確認します。 今日はここまで

前回まででI2Cセンサー出力がUSBポートを経由してPC/Mac/RasPiへ、と言う経路は確立できました。では次はどうするか。 「PC/Mac/RasPiから外部サイトのサービスにどう接続すべきか」だと思います。 ここの間のプロトコルはHTTP(S)かMQTTの二者択一でしょう。更に言うならIoTのジャンルではMQTT一択だと思います。 MQTTに載せるデータ・フォーマットまで標準化したいところですが、話が大きすぎて独りよがりは通用しませんので、当面は「MQTTプロトコルをどう実装するか、テストするか」と言う話に絞りたいと思っています。 ここまで

「動作確認(1)」からの変更です。Wコマンドの返り値を表示するようにしました。これでWコマンドによるエラーが検出できるようになります。

チャンネルはこちらです。

PythonからMbed経由でI2Cセンサーにアクセスするための事前準備です。 macにUSB接続した外部ボード（ここではArduino互換機）に、Pythonから入力した文字をそのままecho backさせました。まずはArduinoのスケッチ。 ＝＝＝ void setup() {   Serial.begin( 9600 ); } void loop() {   if( Serial.available() ){     char c = Serial.read();     Serial.print( c );   } } ＝＝＝ 次にmacで動かすPython ＝＝＝ import serial ser = serial.Serial('/dev/tty.usbserial***',9600,timeout=None) while True:     ch1 = input()     ser.write(bytes(ch1, 'UTF-8'))     ch2 = ser.read()     print(ch2) ＝＝＝ 結果はこんな感じです。 0を入力したらb'0'が出力され、1を入力したらb'1'が、、、の連続です。 ※ボードを変えると"tty.usbserial***"の部分が変わるので注意が必要です。（'18.11.19記す） ＝＝＝ ここまで

Pythonからシリアルポートアクセスするためには、 pySerialというパッケージをインストール します。 $pip3 install pyserial Successfully installed pyserial-3.4 （バージョンは'18/11/12当時） が出ればOKです。 いきなりI2C-COMの基板を繋ぐ前に、PythonからUSBポートに入出力できるか、確認します。 まずUSBポートから"Hello"を連続入力してPythonの画面に出るか？ macのUSBポートにテキストを連続に流し込むArduinoのスケッチ（Mbedにまだ慣れてない） ＝＝＝ char ch1 = 0; void setup() { Serial.begin(9600); } void loop() {     Serial.println("Hello");     delay(1000); } ＝＝＝ mac側で受けるPythonは ＝＝＝ import serial ser = serial.Serial('/dev/tty.usbserial-***',9600,timeout=None) while True:     ch1 = ser.read()     print(ch1) ＝＝＝ 結果は となりました。時間になったのでPython -> USBは明日にします。 ここまで

I2Cを手入力と目視で制御できるようになったので、次はいよいよプログラムからI2Cを制御できるようにします。まずプログラミング言語を決めないといけないのですが、ここではPythonを選びました。なぜPythonなのか？ これから多種多様なI2Cセンサーの動作を記述してどんどん資産が増えていきますから、今後廃れそうな言語は避けたいところです。これから末長く生き延びるだろうことを現時点で予測するのはどんな技術でも難しいことですが、①書店で書籍を多く見かける、②ざっと見たところ言語仕様が初心者でも取っつき易そう（新しく覚えることが比較的少なそうだしデバッグも容易に思えた）、③RasPiのPiはPythonのPiらしい（RasPiを立ち上げた人が意識していたことは間違いない）、等々の理由により選びました。因みにNode-REDにもwebにも使えるJavaScriptが次点でした。 さて、macOSには最初からPython2がインストールされているのですが、ここではPython3を新たにインストールします。これから新しくプログラムを書こうという人が進歩が止まった言語に執着する理由はありませんから。 Pythonのインストーラーはここ にあります。2018.11.12現在macOS用のverionは3.7.1でした。インストールが終わったらターミナルから$python3 -Vでバージョンをチェックします。 次に 使いやすいMicrosoftのテキストエディタをインストール します。Visual Studio Codeの中でPython用のプラグインもインストールしておきます。 ここまで

内容を更新しました。 最新はこちら。 ＝＝＝ 動作確認(1)で確認したのはレジスタリード動作なので、ライト動作も確認しておきます。 （レジスタリード動作の中でもデバイスにはレジスタアドレスを書き込んでいますがdata sheetに記載のあるプロトコルを確認する意味があります） レジスタ03hはRAM_byteで、汎用に読み書きできるようなので、ここに適当なパターン、ここでは5ahとa5hを書いて読み出してみます。 今回は１行１行説明しませんが、"5a"を書いた後、"5a"が読めて、"a5"を書いた後は"a5"が読めていることが確認できました。 ここまで

内容を更新しました。 最新はこちら 。 ＝＝＝ 最初の動作確認として、RTCからreadしました。 レジスタ00h~0Ahまで11バイトを連続で読み出しています。 最初なので１行毎に説明をしますと s <-- start wa2 <-- write a2h（7bitアドレス51hを左1bitシフトしたもの） w00 <-- write 00h（レジスタアドレス0h） p <-- stop（このデバイスはrepeated startではなく一旦stopを出す必要がある） s <-- start wa3 <-- write a3h（7bitアドレス51hを左1bitシフトして右端に1bit=read指定） rk <-- read ack（レジスタアドレス0hを読む） 0 <-- レジスタアドレス0hの返り値が0h rk <-- read ack（レジスタアドレスがauto incrementされているので1hを読む） 0 <-- 同じく1hの返り値が0h rk 0 <-- 2h rk 34 <-- 3h rk 9 <-- 4h（これは「秒」を表す） rk 50 <-- 5h（「分」） rk 19 <-- 6h（「時」） rk 28 <-- 7h（「日」） rk 5 <-- 8h（「曜日」） rk 1 <-- 9h（「月」） rn <-- 最後なのでread nack 0 <-- Ah（「年」） p <-- stop ここまで

コントローラにMbedを使うことにした結果、I2C-COMを＝＝＝以下に示すように簡素化することにしました。今一度、I2C-COMの意義をここで再確認しておくと 「I2Cプロトコルをtext streamにする」 です。 ＝＝＝ I2C-COM仕様　第3.1版 updated 2018.11.30 数値を16進で表現する際、1バイト当たり2文字要することを明記した。 S: start(); P: stop(); Wxx: xx=00~FFで書き込むバイトを表す。返り値はACK=01 or NACK=00 <-- updated Ry: y=K or Nで、K=ACK, N=NACKを表す。返り値は読んだバイトで00~FF ※Wでslave addressを送る際、7bit addressを1bit左シフトして、write mode=0, read mode=1を加える必要があります。 ※いずれも大文字小文字とも有効。 ※S,P,W,R,K,N,0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F以外は区切り記号。区切り記号のとき実行する。いずれ連続リード・ライトを追加する可能性がある。 ※1バイトのbinaryをreadableにするためには00~FFの2文字を使う。text stream上では2文字、つまり2バイトに倍増すると言うことである。<-- updated ＝＝＝ ここまで

I2C name(sda, scl);//初期化 name.frequency(hz); name.start(); name.stop(); int=name.read(bool);//int:受信バイト、bool:false=nack, true=ack（正しいことを実機で確認した） bool=name.write(int);//bool:false=nack, true=ack、int:送信バイト（実機で確認したところ、ack=true=1であった） === 以上だけを使う予定です。後日、スピードが問題になったら連続read/writeを使う可能性はあります。

ここではI2Cファームウェア開発のreferenceとして RTC を使っているのですが、中のPCF85063TPにちょっとクセがあってハマったので備忘録として残しておきます。 ＝＝＝ ReferenceとしているI2Cマスターのライブラリは ここ です。ここでのI2C-COMの開発では、ここに記述のあるstart, stop, read, write、の基本関数だけで記述したいわけですが、 PCF85063TP data sheet のP.26によると、register address setのトランザクションと、後に続くreadトランザクションの間はstopを要します。通常はrepeated startでいいはずなのですが、なぜかstop -> start、になっていました。 これに気づくまで小一時間無駄にしてしまいました。 ＝＝＝ ここまで

ここでは、I2CセンサーをUSBポートからアクセスできるようにするべく開発を進めているわけですが、開発に手こずっているうちに目指している方向を見失うことがないように、この開発の意義をここに書き留めておきます。 ＝＝＝ 1. 目的とする開発成果物のイメージ I2C I/Fのセンサーを、USB経由で可制御・可観測にする（制御可能でかつ情報を受け取れる） 2. 開発の狙い、目的 ・各種センサーのI/FをWindows PC/Mac/マイコンボード(ex. Raspberry Pi)で共通にすることによって、開発成果物（具体的には制御・可視化用のソフト）を相互に移植しやすくする。例えばMacで開発したものをRaspberry Piに持って行くなどが簡単にできるようにする。 ・例えばRaspberry Pi基板にはGPIO等が使える拡張コネクタがあるが使えるケースが限定されている（ケースに穴が開いておらず、また拡張用基板の固定にも困る）。片やUSBポートはどんなケースでも使えるようになっており、センサーを取り付けるにはUSBポートの方がスマートと言える。 ※ここでI2Cの重要な特徴を挙げておきたい。それは転送周波数をゼロつまりプロトコルの途中どこでも止めることができる、いつまでも待たせておくことができる、ことである。この性質により、I2Cを使ったセンサーを遠隔から手入力で操作し表示するのにタイムアウトを気にする必要がない。手入力でデバッグすることができるということでもある。 ＝＝＝ ここまで

前回まででMbed --> Macが開通したので、次の課題はI2C --> Mbedを開通させることです。 ＝＝＝ ゴール：I2CデバイスをアクセスしてMacに表示させる 機材： リアルタイムクロック(RTC) ツール：前回と同じ（Mbed Compiler、CoolTermMac） ソースは以下 ＝＝＝ #include "mbed.h" #include "USBSerial.h" USBSerial   usb(0x1f00, 0x2012, 0x0001, false); I2C i2c(p26, p25);        // sda, scl const int addr8bit = 0x51 << 1; // 8bit I2C address int main(void) {     char regaddr[1];     char readdata[11]; // room for length and 7 databytes     while(1) {         regaddr[0] = 0x00;         i2c.write(addr8bit, regaddr, 1, true);  // select the register, no I2C Stop         i2c.read(addr8bit, readdata, 11);        // read 11 bytes // print the data to the screen         usb.printf("0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\r\n",             regaddr[0] , readdata[1], readdata[2], readdata[3],             readdata[4], readdata[5], readdata[6], readdata[7],             readdata[8], readdata[9], readdata[10] );         wait(

今調べたら４年以上前にmbed（当時は全部小文字）で製品開発していたことがあったのですが、開発環境（自分もWinからMacにしてた）も石（半導体チップのこと）もだいぶ様変わりしていたので戸惑いました。私を含めて新しいハードを使い始めるときは立ち上げの初っ端でつまづく人が多いと思うので、ここに備忘録として残しておきます。 ＝＝＝ 最初のゴールは「Macの画面に、Mbed基板のシリアル出力を出すこと」 ・使った機材： ＬＰＣ１１Ｕ３５マイコンボード 、micro-USBケーブル、Mac ・使ったツール： Mbed Compiler 、 CoolTermMac 手順の要点、つまづいた点など (1) LPC11U35マイコンボードの初期テストをする。SW1とSW2を同時に押しながらUSBケーブルを接続し、SW2から手を離すと"CRP DISABLD"という名前のディスクがデスクトップに現れる。これを開くと中に"firmware.bin"というファイルがあるので削除する（上書きはできない）。説明書にあるテストプログラム"firmware.bin"をダウンロードしてきて書き込む際、ドラグ＆ドロップでは上手くいかず、 $ cp firmware.bin /Volumes/CRP\ DISABLD で書き込む。その後SW2を押すと基板にリセットがかかってLEDが点滅すれば正常に動いている。 (2) Mbedコンパイラに登録する（自分は４年以上前に登録が済んでいた）。 (3) テストしたソースは ここにあるものを使った #include "mbed.h" #include "USBSerial.h" Serial      uart(P0_19, P0_18); USBSerial   usb(0x1f00, 0x2012, 0x0001, false); int main(void) {     while(1) {         uart.printf("I am a UART serial port\r\n");         usb.printf("I am a USB se

最近、mbed --> Mbedに変わったそうです。 それはさておき、昨日からMbedの学習を再開しました。まず手始めに ＬＰＣ１１Ｕ３５ ＱｕｉｃｋＳｔａｒｔ Ｂｏａｒｄ互換ボード の動作テストをしました。 すぐ動くだろうと思っていたのに説明書通りLEDが点滅しない。ネットでいろいろ調べた挙げ句、Macでfirmware.binを書き込む際にはドラッグ＆ドロップではだめで、 $ cp firmware.bin /Volumes/CRP\ DISABLD などとしなければ行けないようです。上記でようやくLEDが点滅し始めました。 （"\"はoption+"¥"で入力する） ここまで

世間には同じようなことを考える人はいらっしゃるようで、先行されている方のサイトにリンクを張っておきます。コマンド体系を見ていただければ分かる通り、当社は真似してませんので念のため。 「LPC810を使ったUART-I2Cブリッジの改良版が出来ました」 ※「リンク張りは禁止」とあったのでリンクを削除しました。ググって見てください。 当社のI2C-COMは、手入力することも可能ですが、最終的にはUnixのスクリプトやプログラム言語から掃き出したコードをinterpretするような使い方を視野に入れています。可読性は落ちますがI2Cプロトコルを理解している人には１対１に対応していて分かりやすいことが第一の目的、と言うところが違いでしょうか。 早く実装して動くところをお見せしないといけないと思っています。

昨日秋葉原をぶらついていて、次のような連想が働きました。 ＝＝＝ (1) 8pin のARM系CPU、LPC810の書籍が目に止まる。今LPC810って手に入るんだろうか？今後I2Cセンサーと一緒に組み込むことを想定すると、I2Cが使える小さくて安いマイコンが気になっていたから。 〜昼を食べながらネット検索 (2) LPC810は見当たらないがLPC812というのはある。これはどうやって開発するんだろうか？mbedで開発できるのか？mbedでI2Cはどうコーディングするんだろうか？ 〜更にネット検索 (3) mbedだとI2C周りの記述はスッキリしそうだ。そう言えばLPCはNXPが開発しているがI2Cは旧フィリップス現NXPが管理してるんだった！ 〜更に更にネット検索 (4) mbedの開発ボードが¥1000以下で売られていることを発見。ショップに行って即購入。 ＝＝＝ と言うわけで、I2C周りの開発はmbedでトライしてみることにしました。さすがmbedはNXPが推進しているだけのことはあって、I2Cの記述方法に目が行き届いています。Arduinoの言語仕様は回路に思い入れが少ない人が設計した気がして仕方がない。（I2Cの動きを過度に隠蔽していてI2Cの動きを見えなくしてしまっている） ここまで

「I2C slave simulatorを作る(2)〜メインloopを作る」のtransaction記述の中で使う順番に、あると便利な関数を列挙しておきます。 ＝＝＝ (1) startを待つとき使うもの byte read_scl(); void wait_sda_fall(); (2) byte readするとき使うもの byte read_sda();//SCL=riseを待ってSDAを取り込む。返り値は1bit void wait_scl_rise();//read_sdaの中で使う (3) ACKを返すとき使うもの void write_sda(byte);//read_scl()でSCL=highのときSDAにデータを載せる (4) 8bit read/writeのとき使うもの(2)(3)で既出 (5) 次のサイクルを判定するとき使うもの（既出） ＝＝＝ 以上をまとめると ＝＝＝ void wait_scl_rise(); void wait_sda_fall(); byte read_scl(); byte read_sda(); void write_sda(byte); ＝＝＝ ここまで

メインloopではtransactionの流れを記述します。ここでtransactionとは、start条件＞slave addressとR/W bit送出＞バイト転送＞・・・＞stopまたはrepeated start条件、のことを指します。 ＝＝＝ (1) startを待つ（SCL=1のとき、SDA=fallになるのを待つ） (2) 7bit slave addressと、1bitのR/~Wを受信する。具体的にはSCL=riseでSDAを取り込む。次のバイト転送の向きを決めるためR/~W bitの状態を覚えておく。 (3) ACKを返す。具体的にはSCL=highのときSDA=0とする。 (4) Wサイクルだったら8bit受信してACKを返す。Rサイクルだったら8bit送信してACK/NACKを待つ。 (5) 次のサイクルが何かを判定する。具体的には、SCL=riseを待つ＞SCL=highの間中SDAが変化しなければ1bit転送が成功したということ。次の7bitの転送は(4)に戻って続ける、SCL=highの間にSDA=riseになったらstop条件なので(1)に戻る、同じくSDA=fallになったらrepeated start条件であり(2)に戻る。 ＝＝＝ 以降、必要な関数をいくつか定義していきます。 ここまで

slave simulatorを作る前に、I2Cプロトコルをもう一度おさらいします。 (1) SCL=highのとき、SDA=fallを検出すると"START condition"と認識する。 (2) SCL=highのとき、SDA=riseを検出すると"STOP condition"と認識する。 (3) SCL=riseのとき、receiver側がSDAの状態を読み取る。 (4) SCL=fallのとき、transmitter側がSDAの次の状態を出し始める。 slaveがreceiverまたはtransmitterのときの動作で書き直すと receiverのとき (3') SCL=riseのとき、SDAの状態を読み取る。 (4') SCL=fallのときは何もしない。 transmitterのとき (3'') SCL=riseのときは何もしない。 (4'') SCL=fallのとき、SDAにデータを載せ始める。 ではreceiver/transmitterはいつ切り替わるのか？ ＝＝＝ ここでは説明の都合で「8bitデータをtransmitterからreceiverに送り、transmitterがACKかNACKを返すまで」を「バイト転送」と定義しておきます。 仕様では「全てのtransactionはSTARTで始まりSTOPで終わる」とありますが、transactionの中身を分解すると 「START、slave address7bit+R/W1bitのバイト転送(1)、バイト転送(2)（の連続）、STOP」 となります。バイト転送(2)の向き、つまりslaveがreceiverなのかtransmitterなのかはその前のR/W bitで決まります。 日本語で説明するとややこしいので後日ソースコードで公開することにします。 ここまで

現状の機器構成は以下のようになっています。 Mac#1 -> Arduino+自作I2C Shield for master -> 自作I2C Shield for slave -> Mac#2 ここでは贅沢にMacを２台使いましたが、PC/MacでUSBポートが２つ使えればそれで構いません。ハードの初期テストは以下のようにやりました。 slave側のスケッチはシリアルプロッタでSCL, SDAを観測しているだけです。 const byte SCL_I = 13;//ピンの定義。SCLは入力固定。 const byte SDA_I = 12;//ピンの定義。 Arduinoの外部ShieldにMOS FETを使った回路を載せて双方向を実現している。スケッチでは入力・出力を分けて記述する。こちらは入力。 const byte SDA_O = 11;// こちらは出力。'0'だとhi-z、'1'だとlowになる。このスケッチでSDAは出力しないので'0'でhi-z、つまりSDAのレベルはmasterに依存する。 byte SCL_V = 0; byte SDA_V = 0; void setup() {   Serial.begin(9600);   pinMode(SCL_I, INPUT);   pinMode(SDA_I, INPUT);   pinMode(SDA_O, OUTPUT);   digitalWrite(SDA_O, 0);// ここではSDAをhi-zにしておく。SDA_Iのレベルはmaster側の出力に依存する。  } void loop() {   SCL_V = digitalRead(SCL_I);   SDA_V = digitalRead(SDA_I);      Serial.print(SCL_V+2);// SDAを0 or 1, SCLを2 or 3の位置に表示するため2を加えている   Serial.print(",");   Serial.print(SDA_V);   Serial.println(""); } ここまで

SCL, SDAをモニタするのに、専用の機材（ロジックアナライザ等）を使う、LEDを光らせる、等がありますが、ここではせっかくI2C slaveをArduinoで作っているのでArduinoの機能を使います。 従来はシリアルモニタでキャラクタコードを出力していたのですが、最近シリアルプロッタと言う便利な機能が追加されたのでこれを使いましょう。以下がサンプルコードです。 byte scl = 0; byte sda = 0; byte b = 0; void setup() {   Serial.begin(9600); } void loop() {   Serial.print(scl+2);//SCLが下なのが一般的のようなので気になる人は変えて下さい   Serial.print(",");   Serial.print(sda);   Serial.println("");      if (b == 00) { scl=0;sda=0;}   else if (b == 64){ scl=1;sda=0;}   else if (b == 128){ scl=0;sda=1;}   else if (b == 192){ scl=1;sda=1;}   b++;      } Arduino IDEのメニューのツール＞シリアルプロッタを選択すると以下のような画面が現れます。 ここまで

ネットワークカメラ（IPカメラとも言う）I/Fの標準規格にONVIF(Open Network Video Interface Forum)と言うのがあるようです。ネットワークカメラとその受像機、レコーダの間の規格です。 これに対して、ネットワーク対応のセンサーの標準規格を策定する団体が見当たりません。まだメーカ各社がそれぞれ独自にやっている感じです。 また、画素数が少ないなど、カメラの規格では重いと思われるセンサー類のインターフェースはどうしたらいいのか？ （MQTTと言うプロトコルの存在は知っていますが、これに載るセンシング情報がどこまで標準化されているのか？当社としてはまだよく把握していない） ここら辺りに当社の存在価値、存在意義を見つけることができます。

SCCB (Serial Camera Control Bus)という、OmniVision社が作ったI2Cのサブセットのカメラ用のインターフェースがあるようです。 製品自体が少ないようで、スピードの問題もあると思うので実際使うかどうかわかりませんが、備忘録として残しておきます。