昨日、テニススクールに行こうとしたら、車のドア(キーレス・エントリー）が開かない。キーの電池切れだろうと、手動で開けようとするが、なんか開かない。いろいろ頑張ったら、なんとか空いたので、乗り込みエンジンをかけるが、全く反応が無い。バッテリーが上がっているらしい。前日、車幅灯をつけっぱなしにしていた模様。いつもなら、警告音で気が付くのだが、荷物の積み下ろしで聞き逃したみたい。
保険のロードサービスにきてもらい、無事、エンジンがかかった。充電に1時間ほどエンジンをかけっぱなしにしておく必要があるらしい。
2017-06-06(Tue)
バッテリー ... 上がる
2017-06-06(Tue)
テレビで自分の写真を見た
録画していたサイエンスZEROを見たらNHK学生ロボコン直前スペシャルで、森正弘先生がロボコンを思いついた時の話で、学生に乾電池1本で人が乗って動く車のレースをさせることを思いついた、と話されていて、そういうことしたよねぇと思っていたら、レース当日の写真が出て、自分が結構大きく映って驚いた。
いやぁ、懐かしいっすね。森先生のお元気な姿をみられてよかった。
いやぁ、懐かしいっすね。森先生のお元気な姿をみられてよかった。
2017-06-10(Sat)
F-PLUG 再び
2年前に F-PLUGというBluetooth接続の電力計を導入し、部屋のエアコンの電力、周辺温度、湿度等を1分ごとに記録し、Linuxサーバに保存していた。Bluetooth接続をLinuxのrfcommコマンドでttyデバイスに変換し、sunagaeさんのpythonのプログラムでデータを取得している。
ところが、rfcommのプロセスがよく止まる。 そのたびにrfcommを再起動（再実行？）させていたのだが、エアコンの電力消費状況も把握できたので、興味も薄れ、ほっぽらかしにしていた。
だんだん暖かくなり、今年はエアコンも新設したこともあり、興味が復活、ふたたび使いたくなってきた。しかし、rfcommを使うのは止めたい。 pythonを使えば、直接 Bluetooth機器とお話しできるっぽい、
まずは、pyBluezで、bluetoothデバイスのスキャン
[python]
import bluetooth
nearby_devices = bluetooth.discover_devices(lookup_names=True)
print("found %d devces" % len(nearby_devices))
for addr, name in nearby_devices:
print(" %s - %s" % (addr, name))
[/python]
デバイスのアドレス ('B0:99:DE:AD:BE:EF" みたいなやつ）がわかれば、socketで接続できるらしい。
[python]
import socket
addr = "B0:99:DE:AD:BE:EF"
port = 1
sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM,
socket.BTPROTO_RFCOMM)
sock.connect((addr, port))
[/python]
これを使ってpyFplugを改造し、直接データを取得できるようになった。 F-PLUGは 新しい方のエアコンに付け替えた。
可能ならF-PLUGを買い足そうと思ったんだが、調べると販売中止になっている。売れなかったということか。同じbluetooth接続の電力計 ラトックのREX-BTWATTCH1の方は、まだ買えそうだが、通信プロトコルの情報がみつからない。なんとかなるのであれば、他のエアコンや冷蔵庫のデータも取ってみたいところだが、残念だ。
ところが、rfcommのプロセスがよく止まる。 そのたびにrfcommを再起動（再実行？）させていたのだが、エアコンの電力消費状況も把握できたので、興味も薄れ、ほっぽらかしにしていた。
だんだん暖かくなり、今年はエアコンも新設したこともあり、興味が復活、ふたたび使いたくなってきた。しかし、rfcommを使うのは止めたい。 pythonを使えば、直接 Bluetooth機器とお話しできるっぽい、
まずは、pyBluezで、bluetoothデバイスのスキャン
[python]
import bluetooth
nearby_devices = bluetooth.discover_devices(lookup_names=True)
print("found %d devces" % len(nearby_devices))
for addr, name in nearby_devices:
print(" %s - %s" % (addr, name))
[/python]
デバイスのアドレス ('B0:99:DE:AD:BE:EF" みたいなやつ）がわかれば、socketで接続できるらしい。
[python]
import socket
addr = "B0:99:DE:AD:BE:EF"
port = 1
sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM,
socket.BTPROTO_RFCOMM)
sock.connect((addr, port))
[/python]
これを使ってpyFplugを改造し、直接データを取得できるようになった。 F-PLUGは 新しい方のエアコンに付け替えた。
可能ならF-PLUGを買い足そうと思ったんだが、調べると販売中止になっている。売れなかったということか。同じbluetooth接続の電力計 ラトックのREX-BTWATTCH1の方は、まだ買えそうだが、通信プロトコルの情報がみつからない。なんとかなるのであれば、他のエアコンや冷蔵庫のデータも取ってみたいところだが、残念だ。
2017-06-14(Wed)
あまり基板が安かったので
FusionPCBに対抗してだろうが、ElecrowがPCB5枚で$4.9で作れるというので、他の基板のついでに基板を作ってしまう。ものは、ADCに接続してアナログ値で複数のスイッチの状態を読み出すボード。他の装置のデモ用に欲しくて、ユニバーサル基板あたりで作るつもりだったが、$4.9なら費用的にかわらないし、楽に作れるし、断然きれい。で、早速作り、テストプログラムで動作を確認。あまりノイズは乗らず、9個のスイッチの識別は、全く問題が無い。すぐにデモプログラムの作成に入れそうだ。
[gallery link="file" size="thumbnail" ids="11366,11367,11364"]
2017-06-22(Thu)
fusionPCBについて
仕事熱心なfusionPCBさんから、前の記事にコメントがついたので、fusionPCBについての意見を書いてみる。
fusionPCBは、中国の格安PCBサービスの先駆けで、私も使ったことある。5年前に記事も書いた。これとこれ。 品質に問題は無く、価格も安かったのだが、elecrowが始めた基板の色変更無料の魅力が大きすぎてelecrowに移ってしまった。最初の基板は緑色で問題無いが、何種類も基板を作ると色分けできる意味は大きい。
その後も、時々、elecrowだけに頼るのもなんだから、たまにはfusionPCBも試そうと思うのだが、注文のページで送るファイルの種類や設計ルールを確認しようとして、情報が見つけられず、探すのも面倒になりelecrowに頼んでしまう。
改めて、https://fusionpcb.jpとhttps://www.seeedstudio.com/fusion.htmlを見直し、感想を書く。
あと、twitterで報告される基板のトラブルを見てると、基板のE-Test通してないだろう と思われるケースが多々ある。自分がelecrowに作ってもらった基板の中にも、たまにある。elecrowのページを調べると 100% E-Testと書いてある。fusionPCBの方でも探してみたが、E-Testに関する記述が無い。今はE-Testをしないオプションが無いので、記述も無いのだと思うが、値段も極端に安くなったので、もしかしてE-Testを省いているのではないかと不安になる。この点も明記したほうが良いと思う。
追加！ もう1件あった。OPLのページをfirefoxで見ると、javascriptのプログラムが終了しなくて、ブラウザが固まる。なんとかしてほしい。Edgeだと見れるが、かなり重い。
なぜOPLのページを見ているかは秘密。
fusionPCBは、中国の格安PCBサービスの先駆けで、私も使ったことある。5年前に記事も書いた。これとこれ。 品質に問題は無く、価格も安かったのだが、elecrowが始めた基板の色変更無料の魅力が大きすぎてelecrowに移ってしまった。最初の基板は緑色で問題無いが、何種類も基板を作ると色分けできる意味は大きい。
その後も、時々、elecrowだけに頼るのもなんだから、たまにはfusionPCBも試そうと思うのだが、注文のページで送るファイルの種類や設計ルールを確認しようとして、情報が見つけられず、探すのも面倒になりelecrowに頼んでしまう。
改めて、https://fusionpcb.jpとhttps://www.seeedstudio.com/fusion.htmlを見直し、感想を書く。
- seedstudio.comの方は、基板注文のページに"how to generete Gerber files"というリンクが張られ、必要な情報がわかりやすいのは良い。改善されている。
- Eagle用のcamファイルが提供されているのも良い。 DRC(design rule check)用のファイルはどこ？
- fusionpcb.jpのページから飛べる基板注文のページには、"how to generete Gerber files"相当のリンクが無い。
あと、twitterで報告される基板のトラブルを見てると、基板のE-Test通してないだろう と思われるケースが多々ある。自分がelecrowに作ってもらった基板の中にも、たまにある。elecrowのページを調べると 100% E-Testと書いてある。fusionPCBの方でも探してみたが、E-Testに関する記述が無い。今はE-Testをしないオプションが無いので、記述も無いのだと思うが、値段も極端に安くなったので、もしかしてE-Testを省いているのではないかと不安になる。この点も明記したほうが良いと思う。
追加！ もう1件あった。OPLのページをfirefoxで見ると、javascriptのプログラムが終了しなくて、ブラウザが固まる。なんとかしてほしい。Edgeだと見れるが、かなり重い。
なぜOPLのページを見ているかは秘密。
2017-06-24(Sat)
混ぜるな危険、取り扱い注意 武田邦彦
このところ、TBSの加計学園等の倒閣運動報道が酷く、聞くに堪えないので、朝からPCで虎ノ門ニュースを見るようになった。虎ノ門ニュースは、なかなか情報量が多い。他では得られないような情報をいろいろ得られる。
金曜日、武田邦彦、大高未貴の番組を見て、武田氏を見直した。武田氏といえば、他番組では、人の話に突拍子もない意見で反論したり、さらにそれを他の出演者に止められたりで、空気を読めず、極論に近いことを言う人という印象があったのだが、発言を中断されず、全部の話を聞けば、一理も二理もある意見、知見を語っていることがわかった。まるのまま信じはしないが、頭に留めておく価値は十分ある話ばかりである。
金曜日は、次のような話をしていた。植物の葉には、基本的に毒がある。これは、動物に食べられないため。伝統的な日本食では、葉っぱは煮て煮汁は捨て、お浸しなどにする。植物性の油も動物性の油よりも体に害がある。動物性の油をとれば、植物性の油も多少取っても良くなる。人の体が栄養分を取り込む仕組みが環境に対応するのに1万年かかる。食生活を急に変えると必要な栄養が足りず、例えば、免疫細胞が十分に作られなくなる。サラダって健康に良いのか？
植物性の油等が動物性の油なぢょり健康に良くないというのは、どこかの資料を引用して、グラフをしめしていた。この話を、まるごと信じはしないが、面白い視点だと思う。
武田邦彦氏は、話を十分にさせないと、極論を言う、番組進行を邪魔するオジサンに見える。ちゃんと話をさせれば、なかなか面白い。混ぜるな危険、取り扱い注意ということだろう。
地上波で武田邦彦氏が充分話をできる時間を確保することは難しいだろう。虎ノ門ニュースという場を得ていることは両者にとって幸せなことなのだろう。 ことことは他の曜日の出演者にとっても同じなのだろう。
金曜日、武田邦彦、大高未貴の番組を見て、武田氏を見直した。武田氏といえば、他番組では、人の話に突拍子もない意見で反論したり、さらにそれを他の出演者に止められたりで、空気を読めず、極論に近いことを言う人という印象があったのだが、発言を中断されず、全部の話を聞けば、一理も二理もある意見、知見を語っていることがわかった。まるのまま信じはしないが、頭に留めておく価値は十分ある話ばかりである。
金曜日は、次のような話をしていた。植物の葉には、基本的に毒がある。これは、動物に食べられないため。伝統的な日本食では、葉っぱは煮て煮汁は捨て、お浸しなどにする。植物性の油も動物性の油よりも体に害がある。動物性の油をとれば、植物性の油も多少取っても良くなる。人の体が栄養分を取り込む仕組みが環境に対応するのに1万年かかる。食生活を急に変えると必要な栄養が足りず、例えば、免疫細胞が十分に作られなくなる。サラダって健康に良いのか？
植物性の油等が動物性の油なぢょり健康に良くないというのは、どこかの資料を引用して、グラフをしめしていた。この話を、まるごと信じはしないが、面白い視点だと思う。
武田邦彦氏は、話を十分にさせないと、極論を言う、番組進行を邪魔するオジサンに見える。ちゃんと話をさせれば、なかなか面白い。混ぜるな危険、取り扱い注意ということだろう。
地上波で武田邦彦氏が充分話をできる時間を確保することは難しいだろう。虎ノ門ニュースという場を得ていることは両者にとって幸せなことなのだろう。 ことことは他の曜日の出演者にとっても同じなのだろう。
2017-06-25(Sun)
Windows上のエディタ
Windows上でも、ずっとemacsを使ってきたが、ちょっと辛くなってきた。IME制御機能付きのWindows用emacsが手に入らなくなってきたからだ。IME制御機能付きであれば、emacsのキー(デフォルトでCtrl-\, 私はカスタマイずしてCtrl-O)でIMEのOn/Offを切り替えることができるのだが、機能が無いとemacsのキーでは、emacs自身のかな漢字変換機能のOn/Offが行われ、IMEのOn/Offは「半角/全角」キーで行うことになる。日本語を入力しているとモードが混乱して極めて効率が悪い。
そういうわけで、乗り換えられるものはATOMに乗り換えることにした。これまでも Gitのreadme.mdなどのMarkDown形式のファイルの編集には使っていた。 キーバインディングもemacsに似ているし、カスタマイズのできるので、使い方を調べながら、少しづつ慣れて行こうと思う。
VSCodeとかにも興味はあるが、Visual Studio 嫌いなので、抵抗があり、まだ試していない。これも、そのうち試してみよう。
ちなみに、ATOMに移行できないのは、emacsからmakeを呼び出すようなプログラミング環境。ATOMでもmakeを呼び出せるらしいのだが、ちょっと試す気も起きない。今、調べたら ATOMからCygwinを呼び出すとかもあるらしい。
しかし、emacsからATOMって、何年経ってるんだと思う。大学受験で泊まったホテルで共立出版の月刊誌bit(懐かしい)でemacsの記事を読んでいたことを記憶している。30年以上前！? プログラミング言語もCとか長いこと(改訂はあるにせよ、概要は)変わっていないわけだし、TeXの代替プログラムは、まだ出現していない。 プログラムの進歩には意外と時間がかかるようだ。
2017-06-29(Thu)
ESP8266用ILI9341ライブラリの高速化
HSES-LCD24用のILI9341ライブラリとして、Humblesoft_ILI9341を使用している。これは、Adafruit_ILI9341を拡張したもので、Fontxを使った漢字描画機能、scroll機能などが追加されている。 実行速度面では、まったく改善されていない。HSES-LCD24用のデモプログラムを新たに作ろうと思うのだが、描画速度が遅いので、先に高速化を行うことにした。
Adafruit_ILI9341のexamplesにgraphicstestという各種描画機能の実行時間をマイクロ秒単位で表示してくれる。これを使い、実行時間を計測しながら高速化を行った。
最終的な結果の表を以下に示す。塗りつぶし系の描画では7倍前後、あまり高速化できなかったLines等でも1.5倍程度の高速化ができた。 文字の描画も4.68倍高速化されているが、これは若干説明を要する。
今回使用した高速化の手段を以下に示す。
まず、Adafruit_ILI9341にある各種CPU対応のコードを削除し、ESP8266専用のコードにした。
次にLCDのCS信号DC信号の操作をdigitalWrite()ではなく、直接GPOS,GPOCレジスタへの描き込むように変更した。このためIO16はCS,DCに使用できなくなった。CS信号の操作を最小限に減らした。
この改造により，ほとんどの描画コマンドで50%程度高速化された。
ESP8266 ArdinoのSPIクラスのwriteBytes()メソッドを見てわかったのだが、ESP8266のSPIには64byteのFIFOバッファがあり、それを使うと連続してSPIから信号を出力できる。だが単純なFIFOではなく、専用のレジスタに書き込まねばならず若干面倒。SPI.write()で1byte出力したときはFIFOはつかわれない。SPI.write()を連続して呼び出しても、データの出力はとぎれとぎれで、速くはない。
Adafruit_ILI9341では、SPI.write()を使うのみでSPIのFIFOは使用していない。よって、データをまとめて送れるところは、まとめてSPI.writeBytes()で送るとかなりの高速化ができる。ILI9341の描画で、これができるのは fillScreen(),fillRect()等の矩形の塗りつぶし。あとdrawFastHline(),drawFastVline()も高速化できる。
この改造により関連する描画関数を約4倍、後述するクロックの高速化と合わせて約5倍の高速化ができた。実際のプログラムで画面クリアに使用するfillScreen()/fillRect()の高速化ができたのは効果が大きいと思う。
ILI9341のデータシートを調べるとSPIの最大速度（クロックの最大周波数）は10MHzと読める。Adafruit_ILI9341のSPIのクロックの設定は24MH。しかし、問題無く動いていた。調べるとESP8266のSPIクロックは最大80MHz。試しに80MHzでプログラムを動かすと、問題無く動いているように見える。他のプログラムで試した時、80MHzでは書込みミスが発生したので、最終的に40MHzにした。クロックの高速化の影響は、fill系の描画コマンドで大きく、それ以外では僅かしか速くならなかった。
文字の描画は文字毎にフォントデータに従ってdrawPixel()を呼び出すことによって行われる。前景色でのみ描画する場合、SPIの連続書込みによる高速化は難しいが、背景色も塗潰す場合であれば、矩形領域の塗りつぶしとなるので連続書込みで高速化できそうである。最初 Adfruit_GFXクラスのvirtual関数 drawChar()をoverrideして高速化しようとしたが、フォントデータを読み出す方法が無いため諦めた。fontxフォントで背景色も描画する時のみ高速化することにし、Adafruit_GFXクラスのデフォルトのフォントglcdfontと同じフォントをfontxファイルで用意、graphicstestプログラムではtext描画時、fontxを使用し、背景色も描画するようにプログラムを改造した。このことをわかりやすくするためtextの背景色は青色にしてある。
この改造により、5倍近くの高速化が得られた。
改造の効果を実感するため、比較動画を作成した。
前の動作をみると、改造したくなった気持ちがわかってもらえるのではないかと思う。
期待以上の高速化ができたので、あたらしいデモ・プログラム以外にも、いろいろとやってみたいことができた。 ESP8266のSPIで,まとめて送れば高速だが、そうでないと速くないということは覚えておく価値があるだろう。あとILI9341がクロック80MHzでも動作したというのは驚きだ。安全を見て40MHzで使っているが、データシートの記述(動作保証は10MHzまで)は何だったのだろうか。
Adafruit_ILI9341のexamplesにgraphicstestという各種描画機能の実行時間をマイクロ秒単位で表示してくれる。これを使い、実行時間を計測しながら高速化を行った。
最終的な結果の表を以下に示す。塗りつぶし系の描画では7倍前後、あまり高速化できなかったLines等でも1.5倍程度の高速化ができた。 文字の描画も4.68倍高速化されているが、これは若干説明を要する。
今回使用した高速化の手段を以下に示す。
- CS,D/C信号操作の高速化
- SPI大量データ転送の高速化
- クロックの高速化
- 文字描画の高速化
CS,DC信号操作の高速化
まず、Adafruit_ILI9341にある各種CPU対応のコードを削除し、ESP8266専用のコードにした。
次にLCDのCS信号DC信号の操作をdigitalWrite()ではなく、直接GPOS,GPOCレジスタへの描き込むように変更した。このためIO16はCS,DCに使用できなくなった。CS信号の操作を最小限に減らした。
この改造により，ほとんどの描画コマンドで50%程度高速化された。
SPI大量データ転送の高速化
ESP8266 ArdinoのSPIクラスのwriteBytes()メソッドを見てわかったのだが、ESP8266のSPIには64byteのFIFOバッファがあり、それを使うと連続してSPIから信号を出力できる。だが単純なFIFOではなく、専用のレジスタに書き込まねばならず若干面倒。SPI.write()で1byte出力したときはFIFOはつかわれない。SPI.write()を連続して呼び出しても、データの出力はとぎれとぎれで、速くはない。
Adafruit_ILI9341では、SPI.write()を使うのみでSPIのFIFOは使用していない。よって、データをまとめて送れるところは、まとめてSPI.writeBytes()で送るとかなりの高速化ができる。ILI9341の描画で、これができるのは fillScreen(),fillRect()等の矩形の塗りつぶし。あとdrawFastHline(),drawFastVline()も高速化できる。
この改造により関連する描画関数を約4倍、後述するクロックの高速化と合わせて約5倍の高速化ができた。実際のプログラムで画面クリアに使用するfillScreen()/fillRect()の高速化ができたのは効果が大きいと思う。
クロックの高速化
ILI9341のデータシートを調べるとSPIの最大速度（クロックの最大周波数）は10MHzと読める。Adafruit_ILI9341のSPIのクロックの設定は24MH。しかし、問題無く動いていた。調べるとESP8266のSPIクロックは最大80MHz。試しに80MHzでプログラムを動かすと、問題無く動いているように見える。他のプログラムで試した時、80MHzでは書込みミスが発生したので、最終的に40MHzにした。クロックの高速化の影響は、fill系の描画コマンドで大きく、それ以外では僅かしか速くならなかった。
文字描画の高速化
文字の描画は文字毎にフォントデータに従ってdrawPixel()を呼び出すことによって行われる。前景色でのみ描画する場合、SPIの連続書込みによる高速化は難しいが、背景色も塗潰す場合であれば、矩形領域の塗りつぶしとなるので連続書込みで高速化できそうである。最初 Adfruit_GFXクラスのvirtual関数 drawChar()をoverrideして高速化しようとしたが、フォントデータを読み出す方法が無いため諦めた。fontxフォントで背景色も描画する時のみ高速化することにし、Adafruit_GFXクラスのデフォルトのフォントglcdfontと同じフォントをfontxファイルで用意、graphicstestプログラムではtext描画時、fontxを使用し、背景色も描画するようにプログラムを改造した。このことをわかりやすくするためtextの背景色は青色にしてある。
この改造により、5倍近くの高速化が得られた。
改造前後の比較動画
改造の効果を実感するため、比較動画を作成した。
前の動作をみると、改造したくなった気持ちがわかってもらえるのではないかと思う。
さいごに
期待以上の高速化ができたので、あたらしいデモ・プログラム以外にも、いろいろとやってみたいことができた。 ESP8266のSPIで,まとめて送れば高速だが、そうでないと速くないということは覚えておく価値があるだろう。あとILI9341がクロック80MHzでも動作したというのは驚きだ。安全を見て40MHzで使っているが、データシートの記述(動作保証は10MHzまで)は何だったのだろうか。
2017-07-01(Sat)
格安SIMに移行
毎月ソフトバンクに払っている金額が気になり、格安simでどれだけ安くなるか調べたところ、時自分の場合充分安くなることがわかったので、iPhone7を購入しIIJmioに移行した。自分が使っているのがiPhone何なのかわからなくて困る。背面にでも大きく書いてくれればいいのに、とか思う。ちなにに iPhone(初代)⇒iPhone4⇒iPhone5s⇒iPhone7と使ってきた。乗り換えるごとに性能向上で使用感が向上しているが、今回もなかなか快適だ。