2017年6月29日 (木)

超音波方式の人感センサーI2C化と新しいオシロ

 PCの横で超音波距離センサーHC-SR04がブレッドボード上に残されたままになっている。他の電子部品に比べると特徴的な形をしているので何かと目立つ。ブログを調べてみたら、このセンサーにはまっていたのはもう2年も前のことで(2015/7/28)、そのあいだ放置したままということになる。Dsc01163

 ブログによると、このあとこの距離計測センサーをI2Cでつなごうとして、AVRの8ピンプロセッサーTiny85を使ってソフトのI2Cスレーブライブラリーを苦労して開発した。ソースコードをブログに上げたのは良かったのだが、そのあとは力が抜けてそのままになっている。

 このセンサーはアナログで動作電圧は5V、距離をパルス時間幅で返してくる。Edisonやesp8266などの3.3Vベースの32ビットプロセッサーとは電圧が違うし、それよりもプロセッサーにOSが入っていたりWiFiなどの割り込みが起きると、こうしたアナログのパルス幅の正確な時間は測れない。 

 そういうことでI2C化を始めたのだが、工作は全然別の方向に迷走したままになっている。そういえば、秋月で異電圧間のI2CをつなぐICも買ってあったのに部品箱の不良在庫になっている。Raspi3の電源問題も一段落したので、このあたりを次のテーマにすることにした。

 HC-SR04のブレークアウト基板(Vccは3V)をつくる。I2CスレーブのTiny85と3.3->5Vコンバーターをつけ、外部へは3.3V入力とGND、それにI2CのSDA、SCLの4本のケーブルをつけて、32ビット機器に簡単に接続できるようにする。

 親機はEdisonはもはや重いので、esp8266あたりを想定する。アプリケーションは、人が近づいたら反応する人感センサーにしようと思う。現在の階段のセンサーは焦電型で結構、反応が微妙で調整が難しい。距離測定の超音波なら、扉を開けるだけで反応するはずだ。

これまでの工作の再現だけで2日を要した(6/19/2017)
 裸になっていたSR04とTiny85を取り出して、ミニブレッドボードに移し替え、ブレークアウト基板のテストベンチをつくる。これまでのブログ記事を参考に(もうこれなしでは生きていけない)、もういちど配線をし直す。Tiny861の親機の方はまだブレッドボード上に生き残っていた。Dsc01157

 UARTを2つつないで意気揚々とテストに入った。しかし動かない。親機は動いたようだが、子機のTiny85は UARTにWelcomeメッセージは出るが、反応が全くない。親機からコマンドを送っても「そんな機械はない」と門前払いだ。

 接続を確かめる。プルアップ抵抗が隣のピンに入っているのを見つけた。最近は目が悪くなって良く間違える。さあ、どうだ。駄目だ。依然として動かない。しようがない。オシロを取り出す。なにー、ちゃんとI2Cの波形が見えるではないか。それでも動かないとはどういうことだ。

 暫く大騒ぎしていたが、落ち着いて配線を見直し、間違いを見つけた。要するにジャンパーコードの接続ミスだった。SDAとSCLが逆さまになっている。Tiny85と親機のTiny861の間のピンが揃っているかだけに気をとられ、ピンそのものが逆だったというお粗末である。情けない。Ws000022

 つまらない配線ミスで時間をとられたが、完動した。次はこのSR04のブレークアウト基板のソフト仕様である。どの程度の独立性を持たせるかで、基板ハードの仕様に影響が出る。何から何まで、例えば、音速の補正をコマンドで修正できるようにしておけば、ファーム書き換えのISPピンソケットはいらないかもしれない。しかしそれも面倒だ。

 実装するDC-DCコンバーターを何にするかも迷うところだ。部品箱を久しぶりに整理すると、5コ以上のDC-DCコンバーター基板が出てきた。1V以下でLEDをつけるやつ(これは今回は使えない)やら、表面実装にこだわったFP6291のもの(2つもある)、昔のHT7750など、自作品だけで沢山ある。

急にオシロが欲しくなって衝動的に発注(6/21/2017)
そのうち、オシロで半分つぶれかかったI2Cの波形(これで良くデータが通ると感心)を見ていて、突然、これまで我慢していたオシロに対する物欲が沸き起こった。 波形がお粗末なのはオシロのせいではないが、この物欲というやつは、「ときめき」と同じでどうも理由が明確ではない。Dsc01155

 数年前こちらに良くコメントを寄せてくれる、ばんとさんにオシロを勧めたとき、自分も新しいオシロが欲しくなった。このときは、使う機会が少ないときだったので、やっとのことで我慢した記憶がある。

 当研究所がオシロを買ったのは、もう9年も前の話である。帯域60MhzのOWON製(PDS6062T)で、当時は10万円近くした(¥79,800)。買ったときは、清水の舞台から飛び降りる気分だとブログにはある。

 オシロの効果は抜群で、PCMプレーヤーのバッファーオーバーランを一発で発見したり大活躍をしたこともあるが、単純なトリガーしか選べないことや、蓄積データ量が少ないので大したことは調べられず次第に使われることが少なくなった。

 まあアナログ工作は殆どやらないので、それほど大きな不満はない。ちょっと複雑になればロジアナを引っ張り出せば良い。 オシロは今度の工作のように、動きを確認するだけに使われていた。必要性を強く感じることはなかったのである。

 このあと、低価格帯のオシロは、さらに安くなって中華のオシロは帯域100Mhzが3万円台になった(ばんとさんに勧めたころ)。中華製も評判は悪くなさそうだったが、強いニーズがなかったことがあって、オシロ熱はそれほど高くならず、その後は余り調査していない。

 あらためて調べてみると驚いた。さらに低価格化が進んでいる。少し前までは高級オシロにしかなかったフォスファー機能(アナログオシロのように繰り返し波形を色分けしてくれる)のついたものが、10万以下で手に入る。

 調べている間に、狙いをつけたのが、SiglentというシンセンのメーカーのSDS1202X-Eというオシロである。帯域が200MHz、メモリが14 Megaポイント。フォスファー付きで、この-EというサフィックスはUART、I2C、SPIなどのレコードの解析もできるシリアルデコーダーが付いているバージョンである。Ws000023

 ひところなら確実に100万以上はした商品ランクである。価格が悩ましい。日本で買えば(アマゾンとか楽天)10万近くするのだが、Alibabaなどの中華サイトでは、$380、何と4万円そこそこで売っている。にわかには信じられない安さだ。

 今これがないと進めないようなプロジェクトはないが、欲しいという欲望に勝てなくなった。しかも5万円以下で、これまで想像もしていなかった高性能のオシロが手に入るのだ。ここ数年は、余り電子工作に金をかけていない。少しくらいは良いだろう。

 中華サイトの買い物はリスクが大きいが、日本のサイトの半額以下というのは強烈な魅力だ。何しろ所長は「破格の安値」というのに弱いのである。ウェブサイトの珍妙な日本語の広告画面を何度も見ては迷っていたが、抵抗できず、ついポチってしまった。相手は、AliExpressである。

DCDCコンバーターの電源でSR04が動かない(6/24/2017)
 注文はしたけれど、到着まで10日はかかりそうなので、SR04のブレークアウト基板制作を続けた。次の課題はDC-DCコンバーターのテストである。

 久しぶりに秋葉原で買い物をした。自作のDC-DCコンバーターは、殆どが9 V以上の昇圧コンバーターで、5Vに上げるコンバーターにするため、秋月電子で面実装の半固定抵抗を入手するためである。

 面実装の基板の修正はとても難しい。例の低温ハンダで部品をはずすのは簡単だが、この自作のDC-DCコンバーター基板(FP6291)は、最初のバージョンではんだ付けに大苦労した版だ(ブログ参照)。半固定の抵抗器を取り替えるだけに数時間かかった。

 何とかして取り換えた。電源を入れる。おやあ、無負荷では5Vになるが、LEDだけつけても3V近くまで下がる。オシロで見るとパルスだらけの出力で明らかにおかしい。実体顕微鏡で配線を子細にチェックする。Dsc01162

 すると、分圧抵抗のグランド側のハンダブリッジでつないだところが見事に切れているのを発見した。やれやれ、以前もこの現象に悩まされたことを思い出す。他のところで熱を加えているときにブリッジが解消されてしまうのである。

 これを直して無事、負荷をかけてもちゃんと5Vが出るようになった。300mA以上流してもOK。勇躍、SR04の電源に組み込む。SR04は無事動いた。

不愉快にも市販のDCDCコンバーターは完動(6/25/2017)
 ところが、何故か、センサーの計測距離が不正確になってしまった。どれだけ遠くを指しても、出てくる距離が30cm以上にならないのである。電圧は5Vのままで、オシロで見る限り波形も正常だ。理由はわからない。DC-DCコンバーターのパルス周波数と、超音波センサーのパルス(40khz)とが近いからだろうか。

 スペックによるとFP6291のPWMパルス周波数は、1Mhzと高いのでその影響はないはずだが、おかしなことには間違いない。修正の手間を考えると、もうひとつの自作のDCDCコンバーター(同一のFP6291)をさらに試す気力はもう残っていない。

 昔作ったHT7750もだめだった。距離はもう少しFP6291のより伸びるが、1m以上にはいかない。だいたいこいつはオシロで見ても、脈流でこういう電源には向いていない。本来の工作と違う脇道でこういうトラブルは、気分が滅入る。折角I2Cのレベルシフターまで入れて不良在庫を少し消化したというのに。

 しかし、少々のことではへこたれない当研究所の所長である。手持ちの市販(ストロベリーリナックス)のDC-DCコンバーター基板(LM2735)の予備があるのを思い出し、これを部品箱から探し出して実験してみた。

 何と悔しいことに、このコンバーターでは全く問題なく超音波センサーが動くのである。えー、なぜだろう。何故、自作のコンバーターでは動かないのだろう。不愉快なことだがこれが現実だ。Lm2735

 だいたいDCDCコンバーターをつくるのが目的ではなかった。へそ曲がりでは負けない所長だが、さすがに今度は、これ以上、これにかかわるのはやめることにした。全くの時間の無駄だ。

 だいたいこのストロベリーのコンバーター基板も予備品でこれまで部品箱の肥やしになっていたパーツである。ここで役に立っただけでも良しとせねばなるまい。ブレークアウト基板を早く作って人感センサーを作ろう。

新しいオシロ来たー(6/27/2017)
 オシロを注文したあと、注文先からは「入金は確認しました」や、「商品を配送しました」という意外にこまめなメールが届いていたが、思ったより早く、注文していたオシロが届いた(Siglent SDS1202X-E)。Dsc01158

 入金して2日で出荷の知らせがあり、到着は5日後である。たいしたものだ。初めての中華サイトでの買い物でどきどきしていたのだが、とりあえず一安心である。メールが届いていたので大丈夫とは思っていたが、やはり数万円台の買い物では緊張する。

 噂では、大陸からの荷物はべこべこになっている(荷扱いが極端に悪い)はずなのだが、結構、荷姿は崩れていない。ただし、段ボールを開けると、正式の梱包の段ボール箱が現れた。やはり二重になっていた。しっかりした間仕切りの発泡スチロールで機械は中央に浮いている。Dsc01159

 取り出す。現状の8インチに比べれば今度のオシロは7インチでやはり心持ち小さい。心がはやるので前と同じように居間で梱包を解き、プローブの校正をする。画面はかなり高解像度だ。

 我慢が出来ず、早速地下の工作ルームに持ち込んで現在のI2Cなどの波形を観測する。沢山機能はあるが、まだ使いこなせないので、これまで計測したものだけの再現である。

 おおー、測定範囲が広い。これまでのオシロは少しでも長い間観測しようと思っても、すぐに切れてしまい、全体をつかめない(こういうときはすぐロジアナに切り替え)のだが、今度は違う。何しろ記録量がこれまでの2倍以上あるのだ。(6M->14Mpt/s)。Dsc01161

 距離センサーのテスト機で、I2cをスタートさせ実際のアナログの応答トリガーがかえってくるところまでが一目で見られる。これはありがたい。画面が小さくなったことを感じさせない性能向上である。以前より価格は半分で性能はざっと3倍(帯域60Mhz ->200Mhz)。時代の進歩を実感する。

 フォスファー機能とか、シリアルのデコーダーとか盛りだくさんの機能があるのだが、とりあえずは満足である。追い追い調べていくことにしよう。久しぶりに自作のシグナルジェネレーターなどを埃をはらって登場させ色々テストする予定だ。Dsc01160

| | コメント (0) | トラックバック (0)

2017年6月12日 (月)

RaspberryPi3の電源問題はOSの不具合だった

 しつこいことでは誰にも負けない当研究所の所長が、やっとのことでRaspberryPi3(以降Raspi3)が立ち上がらない問題を解決することができた。

 研究所の工作テーマはESP32に移っていたが、定点カメラを目指したRaspi3の初期ブートが失敗するトラブルは解決されていない。パワーオンリセットが効かないのである。USB機器をはずして立ち上げると大体うまく行くが、USBをつないだまま(もちろんセルフパワーHUBで電源供給済み)だと、ほぼ立ち上がらない。Dsc01131_1 質(たち)の悪いことに、一旦、ブートに成功すると暫くは問題なく動く。しかし半日おいておくと、立ち上がらなくなる。一番先に疑われたのは電源である。いくつかのアダプターを買ってきたり、ケーブルを吟味したり、HUBを換えたりしたが、はっきりとした改善は見られない。

 オシロを使って立ち上がりの電圧の波形を何とかとることができた。立ち上がらない時と、正常に動いた時の双方の波形がとれた。しかしどちらも似たような波形だ。確かに0.5msくらいのところで大電流が流れたらしいディップがあるが、正常に立ち上がる時も同じようなものだ。電源が原因ではないような気がする。Dsc01133_1

もう一台RaspberryPi3を買う(5/24/2017)
 次に疑うべきは、Raspiのハードそのものである。以前、Edisonで本体がおかしくなって熱暴走したこともある。もしかしたらハードがやられているのかもしれない。今、Raspi3は一台しかないので確認はできない。これはもう一台買うしかないか。

 予備ということにして(使うあてがないのがつらい)Raspi3をアマゾンで発注する。ケースとヒートシンク付きで¥5980と安かったのでつい手が出た。数日で届く。便利な時代になったものだ。

 まずは、この新しいRaspiの動作確認である。システムディスクの16GBのSDカードを用意し、NOOBS一式をダウンロードする。OSのバージョンは2.1.0から2.4.0に上がっていた。 

 ふーむ、zipファイルが200MB以上増えている。どんどん進化しているようだ。インストールは順調に進みトラブルなくOSは展開された。電源を入れる。全く問題ない。順調に立ち上がる。少なくとも電源ではない。電源不足を示す画面の稲妻マークも全く表示されない。快調だ。

Dsc01137 やっぱり最初のRaspi3が原因だったのか。いや、まだ、カメラをつないでいない。しかもOSが違う。今のOS(2.4.0)はまだ裸の状態で、これからSAMBAや、動体検知motion、日本語入力、固定IPアドレス化などを加えていかないとトラブルの起きた状況にならない。

 加えた変更のうち、初期化のトラブルに関係しそうな要素は、何といってもカメラモジュールの接続だ。ハードの初期化でループしてしまえばブートは先に行かない。まずトラブルの起きた元のRaspi3にこの2.4.0の新しいシステムディスクを差し替えて動かしてみる。

結局、OSを最新版にして落着(5/28/2017)
 やっぱり何の問題もなく立ち上がった。いやいや、まだカメラモジュールをenableにしていない。raspi-configでカメラモジュールをenableにして立ち上げ直す。よーし、素直にブートが始まった。Raspi本体が悪くないことは確実だ。

 最後の確認である。カメラの動作確認だ。motionはまだ入れていないので、raspistillなどの専用コマンドをあせる手でコンソールに入力する。おめでとうございます。ランプがついて写真がとれた。間違いなくOSの問題である。

 これでトラブルの原因がはっきりした。2.1.0でのカメラモジュールの接続はブートの時にハングすることがあるのだ。このあと、元の2.1.0のOSに戻し、再現を確認した後、raspi-configでカメラをdisableにすると、カメラをつけていてもトラブルが解消することを確かめた。

 このハングが何の原因で起きるのかはわからない。少なくともインストール直後は起きていなかったから、カメラモジュールだけの問題ではなさそうである。このあと入れたアプリと何らかの競合が起きた可能性が高い。

 何が原因にせよ、少なくとも2.4.0で電源トラブルは解消した。というので、2.4.0にこれまでのアプリをインストールし直せば問題は解決する。せっせとNOOBS2.4.0の新しいバージョンにこれまでのアプリをインストールし始めた。

 SAMBAサーバーや、Motion動体検知パッケージ、日本語入力など、入れるたびに初期化の状況を確かめる。2.4.0では最終的にmotionを動かしても全く問題は起きなかった。

 やれやれ、長い道のりだったが、ここ暫く当研究所を悩ませたブートの不調は、OSの更新で解決することになった。もっと早く、カメラをdisableにしてテストしておけば、もう一台Raspi3を買わずにすんだのだが、まあ、これは結果論だろう。

今度はSAMBAドライブが不調(5/29/2017)
 そうこうするうちにまたトラブル発生である。SAMBAのディスクにしていた昔のLet'sNoteの2.5インチIDEドライブがおかしなことになった。立ち上がり時に、$LogFile is not clean. mount in Windows....のエラーが出て、書き込みが出来なくなった。Windowsでマウントし直しエラーをリセットせよとのことである。

 ファイルの中身は普通に見ることができる。SAMBAを通すとWindowsからも正常に見えるが、書き込みはこちらからもできない。それではというので、Win10の方にUSB経由で直接持ち込んで、エクスプローラーで見たら、何とドライブは認識したが「この場所にファイルはありません」という完全拒否である。

 Windowsに昔からあるディスク管理ユーティリティで調べる。コントロールパネルの奥にあるこのユーティリティ(このネストの深さは何だ。このソフトはサードパーティ製で、MSとしては何としてもいじらせたくないらしい)でドライブを見ると、ちゃんと正常にディスクは見える。  
 しかし、ディスクの形式がRAW(生とでも訳すか)となっているのが気になる。このRAWをキーワードにウェブを検索すると、おお、良かった。沢山解決法があるようだ。要するに、何らかのタイミングでドライブのブートレコードのディスクの種類を規定するコードが誤って変更されるとこういう状態になるらしい。

Windowsのフリーソフトで解決(6/1/2017)
解決法の中から、まず、TestDiskを選ぶ。このユーティリティは、LinuxやWindowsでも動くフリーソフトで一番評判が良さそうなソフトだ。早速ダウンロードした。ガイドするサイトも沢山ある。簡単に治りそうに見えたが、これが結構難しい。

 やれることが沢山ありすぎて迷うのだ。日本語化されていないのはともかく、何がおかしくなっているのかわからないので下手にいじることができない。このあたりは、一瞬の動作で、すべてのファイルを失う危険がある。良く納得してからでないと作業は出来ない。

 要するに、「今、自分が何をやっているかを理解していないときは手を出してはいけない」というやつである。この「RAW」という文言が何を意味するのか具体的にわからないからである。迷った挙句、他にも方法がありそうなのでこのユーティリティの作業を諦めた。ウェブで検索を続ける。

 その結果、昔、所長も使ったことのある商用ソフトAcronisの無償試用ソフト(Acronis Disk Director)が良さそうなので、これで修復することにした。サイトに行き、慎重に無償版をダウンロードする。こういうソフトのページには、宣伝用の全く違うソフトのダウンロードボタンが隠れていることが多いので気を付けないといけない。Ws000008

 何とか目的のソフトをダウンロードして、早速試してみた。このサイトが親切だ。
画面がわかりやすい。ガイドに従って、未初期化をRAWと読み替え作業を進める。順調に処理が進んで、そう時間もかからず完了した。RAWはNTFSに変わる。

 念のため、Windowsを再起動する。よーし、正常なドライブに戻った。書き込めるか。中に入っているテキストファイルを呼び出し文字を書き込んで保存する。良いぞ、問題なく変更された。このディスクの中に入っているファイルで失って困るものはないが、正常に戻ったことが嬉しい。

 SAMBAにつなぎなおし、read/write可能なことを確かめる。昔、知人にPCで何をするでもないのに環境整備だけに異常に熱心な人がいた。自分も今度の入れ込みぶりはこの系統かなと苦笑いする。今のところSAMBAで使っているのはmotionの記録ファイルだけである。

ACアダプターの負荷特性を調べると驚くべきことが(6/2/2017)
 Raspiの電源問題の後日談である。Raspi3の立ち上がりの不安定さを解消するため、めたらやたらDC5Vの安定化電源ACアダプターを買い込んだことは前回までにご紹介してある。それが、落ち着いて数えたら、容量が2A以上のものだけで6個もあった(購入4ケ、故障した無線ルーターなどからの流用品2ケ)。 

 容量とは言うが、本当にこれだけの電流を取り出せるのか確かめたことはない。前にも書いたように、必ずしも容量の大きいアダプターが安定してRaspiを動かせていたわけではない。彼らの実力がどの程度なのか、ちょっと本格的に調べてみたくなってきた。

 良く言う電源のレギュレーションとは過渡特性のことを指すが、それ以前の静的な負荷特性は余り問題にしない。しかし過渡特性は、この静的な負荷特性が基本になるもので、これが低いようでは問題にならないはずなのだが、余り話題にならないのはなぜだろう。調べてみよう。

Dsc01135 こういうときのために、セメント抵抗を何種類かそろえてある。スライダックのような本格的なものはないが、物理の実験よろしく直列並列を駆使すれば、5Vなら0.1Aきざみで数Aくらいまで測れるくらいの種類は持っている(50、20、10、2Ω)。

 ブレッドボードにこのあいだ買ったUSBコネクター電流計や、ACアダプタージャックを取り付け、少しづつ測り始めた。データが揃ってくると驚くべき事実が明らかになってきた。おおげさな話かもしれないが、こうしたACアダプターは全然定電圧電源ではないのである。

結構、ケーブルの損失があるのだ(6/5/2017)
 どのACアダプターでも、1A少々の電流でもかなりの電圧降下がある。負荷によって出力電圧が変わらないのが定電圧だと思うのだが、サイトのいう定電圧回路の一般的なロードレギュレーションの上限±0.2%どころではない。平気で数%も落ちてしまう。

 4A容量のアダプターといえども1A流して(正確には0.9A)、0.3Vも下がり4.7Vになってしまうのはどうみてもおかしい。これで定電圧アダプターと称するのはいかがなものか。

 確かに、5Vフルスケールでグラフを描いてみれば、0.3Vの低下というのははごくわずかだが、0.5Vフルスケールにしてみると直線的に電圧が低下していく。

 汎用的なアダプターと違い、無線ルーター、USBハブなどの付属のアダプターは無負荷のときはあきらかに5V以上で、使われる範囲で5Vを維持するようになっている。これなんか一種の詐欺だ。

Dsc01138  グラフを描きながら、悪態をついていたが、少し冷静になって考えてみると、わけがわかってきた。流れる電流が1A近くなるとケーブルの長さが効いてきて負荷端では電圧降下が避けられないのだ。 

サイトで調べてみると、銅線の直流抵抗は意外に大きい。#24(アダプターで使われる一般的な太さ)の撚り銅線(錫メッキ)で1mあたり、0.09Ω(1kmで89Ω)。ということは、1A流せば、たった1mのケーブルで、0.1V近く下がってしまうのだ(往復換算)。

 大抵のアダプターのDC側のケーブルは2m近い。一生懸命、アダプターを取り替え、セメント抵抗をつけたりはずしたりしてグラフを作ったが、あまり意味がないことがわかった。手持ちの沢山のACアダプターの記録を詳しく公開するつもりだったが、誤解を招きそうなのでやめておく。

 この測定結果は、これまでのRaspiでのテストの状況と良く符合する。アダプターではなく、DC側のケーブルの長さや太さが大きく影響している。一番成績の良かったのは、例の秋月での長さ10cmの電源ケーブルが一番トラブルが少なかった。

 負荷端での電圧降下を少なくするのは、太いケーブルにするか短くするかが一番で、ケーブルの長さにかかわらず一定にするには、負荷端から電圧測定線(リモートセンシング)を引き出すような大掛かりな装置が必要だということも分かった。今回は良い勉強をさせてもらった。

| | コメント (4) | トラックバック (0)

2017年5月19日 (金)

RaspberryPi 3の電源事情好転せず。ESP32に手を出す

 RaspberryPi 3(以下Raspi3)による監視カメラはほぼ完成したが、恐れていた通り実際の観測には重い腰が上がらなくなった。現役時代の習い性だろう(若い時はそうではなかったので、一種の職業後遺症)。こういうプロジェクトを計画なしに始めることに強い抵抗があるのだ。

 どんな仕事でも一旦始めると、それを中止する大義名分が見つからない限り止められなくなる習慣が出来ている。途中でやめることに強い罪悪感を覚える。作業を始める前に具体的な目的と目標を決めておくのが決まりになっている。

 これまでに何度か気楽に始めてそれが止められず、といって順調に事は進まず、その葛藤で、へとへとになってしまったことがある。とまあ、出来ない屁理屈をこねているが、実はそれよりもっと深刻なことがある。Raspi3そのものの動作がまだ安定しない。

 USBセルフパワーHUBと電源のACアダプターを共通にすると大量にHUBの方から電力を供給してしまう問題は、特定のHUBの逆流と結論付けたのだが、念のため単独でテストしたところマスター側には電圧がかかってこないし(LEDが点かない)、このHUBを分解して中身を確認しても、しっかりVBUS側にはSBD(ショットキーバリヤーダイオード)が入っていたりする。

 別のHUBに交換し、ケーブルを吟味した結果、定常的な電源容量不足は一時的に稲妻の警告がでるものの、相当な負荷をかけても(カメラと自前ブラウザーなど)、ほとんど落ちることはなくなった。しかし、今度は、本体そのものが電源を入れてもブートしなくなるというトラブルが発生し始めた。Dsc01110

 必ず起きるということではなく、何度か電源を入れ直したり、HDDにつながるセルフパワーHUBの電源を別にしたり、あとからUSBを接続したりすると正常にシステムが立ち上がるので、それほど神経質になることはないのだが、安心して運用テストに入れるレベルにない。

UARTの字化けはあっさり解決。ボーレートがおかしかっただけ(4/17/2017)
 
Tiny13を使ったRaspi電源制御装置も、最初、電圧低下でRaspi3では不安定だったのだが、ケーブルやHUBを交換しているうちに安定して作動するようになっている。この制御装置は、電流量のモニターが出来るので、このまま使いたい、しかし肝心のUARTシリアル出力が盛大な字化けをしているのが気になる。Dsc01111

 で、これを先に直すことにした。久しぶりにオシロを動かして、ボーレートを調べる。明らかに9600bpsのボーレートより遅い(1ビット10.4μsのはずが12μs近く)。ネット情報によれば、Teratermはボーレートが設定画面で自由に変更できるというのでオシロのタイミングに合わせてボーレートを下げてみたが(9600 -> 9000近辺)、不思議なことに全く改善されなかった。

 どうも他の原因が考えられる。自作のソフトUARTのソースコードをじっくり見直した。すると送信期間はボーレートを守るため割り込み禁止(cli();)にしているところを、ストップビットを出した直後、解除(sei())してしまっているのを発見した。 

 ふーむこれか。もしここで割り込みが入ってしまうと、規定よりストップビットが長くなって字化けする。ただ、シリアル出力は、500msに一回の電流測定のときだけで、かかる時間は、9600bpsで30 字だしてもせいぜい3ms(1文字10ビットで1ms)だ。他と被ることはないはずだ。

 しかし、さらにコードを調べていくと、待ち時間をループでなく8ビットタイマーで作っていることがわかった。それもその割り込みは1ms単位だ。もしかしたら、ペンディングになっていたタイマー割り込みがここで入ってUARTと被るのかもしれない。

 ロジアナでも持ち出して測れば一発で原因がわかると思うが、何しろTiny13は8ピンでプローブに使えるピンが一本も残っていない。面倒なので、ボーレートの調整と、この修正(割り込み解除をひとつずらしただけ)を一緒に直してテストしてみた。Ws000019

 ピンポーン!見事に字化けはひとつもなくなった。やっぱり被っていたのか。念のため、割り込み解除のステートメントを元に戻してみた。何と、何と。それでも字化けは解消している。被ってはいなかったのだ。

 単なるボーレートの修正だけで直ってしまった。通信ソフトのTeratermのボーレート変更では治らなかったのに何故だ?心残りではあるが、余りこればっかりやっているわけにもいかない。先に進もう。

10インチのHDMIモニターを入れてRaspi環境が改善(4/18/2017)

 現在のRaspi3のOSはJessieで、HDMIコンソールからブートするようになっている。今まではPCのHDMIモニターを共用にしてディスプレイのSWで切り替えていたのだが、電源のトラブルシューティングで頻繁に再起動をする状況ではどうも具合が悪い。 

 例の7インチIGZOパネルをこのときとばかりに使いたいのだが、1920x1080の解像度では、動画を見るのならともかく、コンソールは猛烈に字が小さくなりデバッグなどはとても出来ない。フォントを拡大するコマンドは入れたが、実用性に欠ける。迷った挙句、適当なHDMIディスプレイを別個に買うことにした。Dsc01115

 ウェブで調べてみる。沢山ある。10インチ近辺のモニターは、車載用のTVモニターの需要があるらしい。爆安店で探せば数千円で買えるかもしれないが、買いに行く時間が惜しい。通販でも1万円近くだせばスピーカーまでついた本格的なHDMIモニターが買える。アマゾンで注文する。良い時代になったものだ。

 ほどなく品物が届いた。タッチパネル式のスイッチ、リモコンまでついて立派なものである(1024X600)。動かしてみる。おおお、少し小さいがコンソールを見るには十分だ。これで格段にRaspiの開発環境は整備された。いちいちPCのディスプレイをスイッチで切り替えなくて済む。Dsc01116

 専用のディスプレイが出来たので、Raspi3そのものの整備が楽しくなった。Raspi3はBluetoothもあるし、NOOBSのデスクトップには、既にいくつものブラウザーが動くようになっている。電源問題が先に進まないので、つい色々なことに目移りしてしまう。

 前にも書いたが、Raspi3の性能は大したもので、ウェブサーフィンも殆どストレスを感じない。居間で使っているASUSの古いネットブック(CPUはAtom)より早いかもしれない。感心なことにデスクトップにはBluetoothのドライバーまでインストール済みだ。

秋葉原で久しぶりの買い物。秋月の最大ACアダプターなど(4/21/2017)
 暫くご無沙汰だった秋葉原に仕事の帰り立ち寄り、秋月電子でいくつか部品を買ってきた。これからの電子工作プロジェクトの候補である。現状が迷走しているので、何らかの起爆剤になることを期待している。

・LTC1799
オシレーターチップ。電波時計の電波(JJY 40/60khz)をこれで発生させ、ESP8266などで、ネットのNTP(Network Time Protocol)で得た時刻を標準電波形式にスイッチングする。要するに電波時計リピーター(別経路のリピーターだが)を作ろうというものである。

ウェブサーフィンをしているときに、これを使い、ESP8266のArduinoIDEで作っている記事を見つけた。電波の届かないところでも電波時計が使える。面白そうなのでとりあえずICだけを調達する。Dsc01129

・ソリッドステートリレー (シャープ 8A 250V)
AC機器をリモートで入り切りするために在庫がなくなったので補充した。これまでのESP8266が遊んでいるので、これにウェブサーバーを立てて、ブラウザーからの指示でAC機器を制御する。典型的なIOTの第一歩である。WiFiモジュールは、新しいESP32も買ってあるが、この程度の制御にはもったいないので別の用途を考えることにする。

・4Aの定電圧5V ACアダプター
 Raspi電源制御の切り札、秋月電子内の最大容量の5Vアダプターである。自前で強力な5V安定電源を作る前に、本当に電源容量だけの問題かこれで確かめようというもの。

・ブレッドボード用DIP基板のついたUSBコネクター    
 Raspi電源問題解明で何らかの回路をUSBバスに付加してテストするため。ブレッドボードでハンドリングできるDIPピンのついたUSB Aタイプコネクター。ブレッドボードそのものは接触不良のかたまりみたいなものだが、何とか藁をも掴む思いである。          

4AアダプターでもRaspi電源事情は改善せず。好い加減あきてきた(4/22/2017)
 当研究所には、5V定電圧ACアダプターなら山ほど揃っている。秋月で買った3Aと2.5Aのものを始め、例のUSBセルフパワーHUBの2.6Aや、2.1Aなど、数えてみたら5つもあった。

 今さら、さらに買い足す必要もないのだが、何となく意地になって4AのACアダプターを思い切って買ってみた(といっても¥900)。帰宅して、とるものもとりあえずまずこのアダプターの実験をする。しかし、残念ながらRaspiの電力環境は好転しなかった。これまでのACアダプターと殆ど変わりはない。

 相変わらず稲妻マークは出るし、時々最初のブートが効かない問題は依然としてなくならない。USBプラグを抜き差しすると変化があるので、アダプターの容量の問題ではなくこのあたりの接触不良の疑いも出てきた。

 ウェブで「電源 ロードレギュレーション向上」などのキーワードで、関連情報を探すが、出てくるのはプロ向けのおおがかりな回路設計の話ばかりで、アマチュアが手軽に試せるようなことは何も見つからない。

 本当は、自前で高性能の3端子レギュレーターなどでACから5Vにする定電圧装置を作るべきなのだろうが、このあたりは、素人なのでとっかかりがなく、もどかしい。

 解決の方向が見えない。ブートを失敗するのは、電源投入時の瞬間的な電圧降下であろうとあたりはつけているが、確認するにも現象が固定化されない(どのACアダプターでも起きる。長時間OFF後はほぼ必ず発生。一旦成功すると、そおあとは失敗しない)。具体的な手段が見つからない。段々飽きてきた。

Raspi3のオーディオ環境整備にはまっている(4/30/2017) 
 そういうこともあるが、このところはRaspi3の環境整備にはまっている。専用のディスプレイでデスクトップ環境が格段に使いやすくなったこともある。

 Raspiのオーディオは無印のころから、これまで全く手を出していない。Raspiのオーディオも結構人気のようである。まずはオーディオ関係を整備することにする。

 Raspi3にはアナログ(単なるステレオジャック)と、HDMI出力、それに情報によれば、入出力ピンにI2Sが出ているということだ。この10インチディスプレイはスピーカーがついているのでHDMIからの音が出るはずだ。Dsc01128

 とりあえずRaspi3のデスクトップのメニューバーにオーディオ選択のダイアログがあったので、これをHDMIにしてみる。ブラウザーで適当な音源を選び音を出す。簡単に音が出た。小さなスピーカーなので音質はお世辞にも良いとは言えない。「音も出ます」程度の音である。

 次は、アナログである。内蔵DACは11ビットというのでこれも音質は期待できない。ヘッドフォンを取り出しジャックにつなぐ。おやあ、シーッと量子化ノイズが耳ざわりだ。11ビットならもうちょっと良いはずだが。

 音を出してみる。小さいスピーカーに比べれば、音はましだが、やはりノイズが気になる。ウェブで評判を調べる。うーむ、このアナログの評価は散々だ。

RaspiAudioの音質不良はrpi-updateで少し改善。Bluetoothも(4/28/2017)
 ウェブをさまよい歩くうち、Raspiのアナログ音の出力は、ここのサイトによるとファームウエアがバグっていてサンプリングビットが1ビット少なく10ビットになっているという情報を得た。(オリジナルはここ

 ここには、バグの修正版のダウンロードサイトも紹介されている。2012年の古いパッチのようだが、正規のupdateにはなっていない。現在の最新バージョンには反映されていないようだ。ふーむ、恐らく何か別の不具合があってのことかもしれない。

 まあ、ものは試しである。一式をダウンロードして、インストールしたあと、ファームウエアの書き直し、rpi-updateをかける。エラーもなく順調にrpi-updateは終わった。

 音を出してみる。うーん、少しは良くなったか。確かに少しノイズが少なくなったが、音は驚くほど良くなったとは言えない。まあ11ビットDACは、二昔前のPCのサウンドカード程度なのでこれ以上の向上は無理のようだ。

 Raspiオーディオで検索をかけると沢山ヒットする。いわゆるハイレゾオーディオの中継基地として安上がりなのが人気なのだろう(この手のオーディオ機器は信じられないほど高価)が、当研究所は今のところハイレゾ再生には行かないことにしている。

 というので、次はBlueToothでの音の再生にチャレンジした。キーボードは動いたが手持ちのBluetoothヘッドフォン(サンワのMM-BTSH30)は、認識はするものの、音がすぐ切れる。ブラウザーや、デスクトップのScratchという教育ソフトの猫の音もでないので、BlueToothの問題だと放置していたのだが、あるとき、コンソールから、

aplay /usr/share/sounds/alsa/Front_Center.wav

というコマンドを入れたら、何と、Bluetoothでの音の再生に成功した。だとすると、ウェブに沢山情報のあるとおり、bluetoothのオーディオパッケージBluezと、これまでのLinuxのオーディオALSAとの衝突がどこかで起きている可能性が高い。

 Raspi内のどれかのオーディオパッケージをインストールし直せば、うまく行くのかも知れないが、問題は深そうで簡単に行く話ではない。ウェブでは調べた限りでは、こういう話題がヒットしない。解決策が見つかる可能性は低い。これも少々あきてきた。

ESP32-WROOM-32のテストに着手する(5/4/2017)
 というので、このあいだ買ったままになっていたESP-WROOM-32(以降ESP32)を試してみることにした。このESP32はWiFiモジュールESP-WROOM-2(以降ESP8266)のグレードアップ版である。Dsc01127

 中華製のWiFiモジュールには信じられないほど安価なのが多いが、日本の電波機器の技術適合証明、いわゆる技適をとっていないのが殆どである。しかし、ESP32はいち早く技適をとり、秋月からはPCへのUSB-UARTまで装備したブレークアウトボード(¥1480)も売り出された。単体の値段もESP8266と殆ど変わらない(¥550 と¥700)。

 これまでのESP8266の弱点、CPUが遅い、I/Oピンが少ない、SRAMの量が今一つという不満を一気に解消しており、これはお買い得と、少し前、予定もないのに単体と、ブレークアウトボードをひとつづつ買ってしまってある。

 以前ESP8266で画像付きのサーバーを作ったことがあるが、画像を出すだけ一息の時間が必要で、簡単なGPIOの操作ならまだしも、ちょっと手の込んだ遠隔制御には使えそうになかった。それがこのESP32ではだいぶ使えそうである。

 その割には日本ではまだブレークしていないようだ。技適はついているし、秋月などでもオリジナル(Espressif)社のブレークアウト基板を廉価で出しているに不思議だ。調べてみて何となく理由がわかった。

 どうもESP8266ほど周辺のソフト開発環境が進んでいないようだ。ESP32の開発元、Espressif社が、Arduinoではない独自の開発環境 ESP-IDEというのを作ったようだが、そのあたりの情報が不足している。一本道ではなく、いくつもの開発環境があるというのは、初心者にとってはかえって弊害になる。

 検索をかければ、ウェブには山ほど紹介記事が出てくるのだが、どれも今までのものと何か違和感がある。一例をあげれば、ここなどは、懇切丁寧な記事の大部分は、トリッキーな空中配線や、ブレッドボード上の配線法なので、読み流しているうち、急に複雑なウェブサーバーの紹介になってびっくりする。 

 ここのサイトは、詳細なESP32の情報が掲載されている。でも、ここの情報だけで、初心者がESP32を動かすことは難しいだろう。膨大な情報があるが、多すぎて、恐らくどこかで折れたら(書かれている通りに動かないなど)最後、手も足も出なくなるだろう。

 この違和感は、これらサイトの筆者の責任ではない。明らかに電子工作のやりかたがArduinoなどをきっかけに大きく変わってきたからではないだろうか。要するにハードやソフトウエアの複雑さが比較にならないほど大きくなって、全貌を簡単に把握できなくなっているのだ。

 結論から言えば、素人が手を出しにくい。WiFiによるスマホとの連携ひとつをとっても、その実現は膨大な技術の蓄積で可能になっている。本当の初心者なら電子工作はもっと少ない要素でできている8ビットのPICやAVRで経験を積む方が結局早道なのではないか。

 悪態をついてばかりいても先には進めない。とりあえずは開発環境から整備を始めることにする。何しろ沢山サイトはあるが、ちょっと目を通しただけではなかなかわからない。当研究所には、ESP8266を開発したArduinoIDEがある。当然この環境と一緒にしたいのだが、このあたりの解説が少ないのである。

ESP32のWiFiサーバーまであっさり動く(5/10/2017)
 このサイトを参考に、既存のArduinoIDEに、ESP32関係のパッケージをインストールする。ここを見つけるまでは、殆どのサイトが新規にArduinoIDEをインストールするところから始まっているので苦労した。要するに既にArduinoIDEがあるのなら、所定のディレクトリーにダウンロードしたパッケージを解凍して入れるだけで良い。IDEを再始動すれば、すんなりESP32関係がロードされる。

 ハードの方はいたって簡単だ。ブレークアウトボードなら、追加する配線は殆どない。LEDと制限抵抗を適当なGPIOピンにつなぐだけである。電源はとりあえずUSBから貰う。ここも電源問題が大変なようだが、まあ、実験レベルなのでこのまま行く。

 ArduinoのLチカのコードをコピペし、ビルドする。何事もなく、終了した。次は、ファームへの書き込みである。おお、無事に書き込みが始まったようだ。心なしかESP8266より速いような気がするが、これは、ファーム焼きこみのシリアルの速度が921600bpsとべらぼうに早いためで、本体が早いわけではないようだ。

 ファームの書き込み終了のメッセージと同時に、LEDが点滅し始めた。あっけなくLチカ成功である。ブレークアウトボードのおかげで、前の手製のESP8266開発キットに比べると、動作モードをタクトスイッチで切り替える必要がない(勝手にボードでGPIOピンを切り替えてくれる)。

 勢いに乗って、WiFiサーバーまで動かしてみることにする。ESP32のライブラリーにある、SinpleWebServerのソースを読み込み、このサイトを参考に、Lチカで使ったLEDをブラウザーからスイッチするコードに組み替える。

 これもビルド、ファーム書き込みともNO ERRORで終わった。立ち上げる(といっても何もしないで良い)。恐る恐る、PCに戻り、ESP32のIPアドレスを調べ(まだ固定化していない)、該当のIPアドレスでアクセスする。Ws000020

 やった。小さなメッセージだが、サーバーからの画面が出た。必要な所はクリック可能な色に変わっている。ONのところをクリックする。おめでとうございます。LEDが点いた。とりあえずESP32はウェブサーバーまであっけなく動くことが確認された。

 これから、ESP8266とどの程度高性能なのか調べていくことになるが、紙数も増えてきたので、このあたりで記事を区切ることにする。

| | コメント (4) | トラックバック (0)

2017年4月16日 (日)

motionの動体検知はRaspi3の電源が安定しない

フィールドテストの開始(3/25/2017)
 適当なパラメーター(前記事参照)を設定して、いよいよmotionによる自宅前の道路の動体検知の監視を始めた。道に面したサンルームのブラインドにカメラのレンズが通るだけのの隙間をわずかに開けて、そこに三脚に固定したカメラを設置する。外から見ると、ブラインドに隙間が空いて何か不自然だけれど、実験なのでとりあえずはこのままに。

Dsc01104 RaspiはWiFiにしたので引き回すケーブルは電源ケーブルだけで良い。設置は楽になった。HDDは三脚の下に置いた菓子折りの空き箱にHUBと一緒に載せる。電源スイッチを入れてその場を離れる。地下の工作室に戻ってPCからSSHを開き、motionを起動する。

 よーし、これでmotionは、ストリーム画像を送りながら、動きがあった時だけ、動画(aviファイル)と静止画(jpegファイル)をSAMBAサーバーの所定のフォルダーに画像を残していくはずである。念のため、PCのブラウザーでストリーミングを確認する。うむ画像が出た。102017032517352505 小一時間、カメラをサンルームに置き、データを収集した。ファイル数200ばかり。容量にして80MBくらいが溜まった。これくらいなら一日放置しても大した量にはならないか。

 データの中身をチェックする。自動車は監視対象ではないが、動体検知するのは車のときが殆どである。カメラの位置は進行に対して90°なので自転車の追尾は結構難しい。この場所からでは流れ映像しか撮れない。

 歩行者は問題なさそうだ。動体検知画素数1000程度で十分捕捉している。それでもタバコを人家の庭にポイ捨てする不届き者の人相を完全に把握するのは難しそうだ。 Ws000017

 ファイルは動体検知をしたセッション単位にひとつづつ数が増えていく。現在は、イベント番号(検知セッションの中での連番)というのがファイル名の先頭に来るので、ソートがうまくいかない。ファイル名を工夫しないといけない。

監視カメラの仕様がなかなか決まらない(3/28/2017)
 フィールドテストは始まったが、本格的な運用に入るまでに解決しなければならないことがブラインドの不自然な隙間だけでなく、まだ沢山ある。

 現在、撮影は室内から窓ガラス越しにやっているが、本当は外に置きたいところだ。しかし、外に置くとなると、カメラの防水、防風、防塵などの対策がただちに大ごとになる。レンズを近づけてガラスの影響を少なくする場所があれば良いのだが、今のところ都合の良さそうな所は見つからない。

 また、三脚にカメラを固定し、付属物を横に置いているが、これももう少し工夫したい。掃除はしにくいし、機動的な移動はできない。それに、まだ猫に気づかれていないが、HDDは僅かだが音を出す。長時間放置した場合の音に敏感な猫の対策も考えておかないといけない。

 さらにカメラの運転仕様が悩ましい。吸い殻を捨てる不届き者の特定を当面の目標にしているから、長時間の監視が求められる。人通りの少ない早朝か深夜が考えられるので、もしかしたら赤外線カメラにする必要があるかもしれない。自動的な時間制御もあった方が良い。

 出来上がった映像のチェックがこれまた大変である。motionを使っているので、歩行者、自転車が通過するときだけの映像になっているはずだが、映像をチェックするPC側のビュワーの機能だけでなく、現在のファイル名を今よりもうすこし合理的なものにしたい。

 先述したように、現在のmotionの録画したファイル名の先頭は、ひとつの動き検知のなかの複数の動きの番号(イベントNo)で、ソートするときとても不便である(ここの1や2は余り意味をなさない)。これはmotion.confのファイル名設定で換えられそうだが。Dsc01110_

 世の中の監視カメラの整理はどうやっているのだろうか。やっぱりしらみつぶしに映像を見ていくしか能がないのか。悩ましい所である。

電源制御装置を入れるだけで電圧降下の警報マークが出る(3/29/2017)
 フィールドテストをしながら、Raspiを安定して動かす電源の検討をしている。Raspbianのデスクトップには、電力不足になると画面右上に警報の稲妻型のロゴが出る(4.65V以下)ことを知り、これで、たくさんあるこれまでのACアダプターの性能比較が楽になった。

 ブート時はCPUにロードがかかり手持ちのすべてのアダプターで一部に稲妻が出る。結構敏感である。しかも必ずしも容量の大きい(流せる最大電流)アダプターの方が安定しているとは言えない。秋月の5V 3Aより、セルフパワーHUBについていた容量表示が2.6Aの方が何故か稲妻の出方が少なかったりする。ただ、少々稲妻が出てもすぐRaspiがダウンするわけではない。

 電源ケーブルとして使っているUSBケーブルでも大きな違いがある。太いケーブルの方が相対的には良いが、これとて余り長いと細い短いケーブルに負ける。秋月電子のRaspi専門の商品棚にあった長さわずか10センチくらいのUSBケーブル(タイプA->マイクロB)がやはり最強だ。

 先だって作った自慢のRaspiの自動電源制御装置(スイッチ押下で電源が入り、シャットダウンで小電流になると電源OFF)は、レギュレーションを間違いなく悪化させる。これを経由させると稲妻が出る頻度が高くなり、システムが不安定になってしまうことがある。

 この電源制御装置は0.22Ωのシャント抵抗で電流を計測している。500mA流れても、0.1Vの低下にしかならないので影響は少ないはずだが、どうしてなのだろう。

 以前買った、USBソケット内にLCD電流計を入れたやつはもっと良くない。入れただけで電圧が下がり、正常に立ち上がらない。表示は4.7V以上だが、恐らく瞬間的な大電流のとき表示以上の電圧降下があるのだと思われる。Dsc01113

 オシロでこの瞬間的な電圧降下を測定したいと思うが、トリガーをどうかけて良いのかわからない。入力をACにして、高感度にし、トリガーをnormalやsingleにしてみるが、全く引っかからない。

 こうした瞬間的な降下を回避したいのだが、どうもうまく行かない。下手なインダクターは無用の直流の電圧降下があるし、コンデンサーも大容量のものが既に付いている。これ以上の追加は突入電流が心配だ。

 どうも、Raspiの電源コネクターになっているマイクロUSBのソケットを疑いたくなってきた。2A以上の電流が流れるというのに、あの接点の小ささは気になる。あまり結果は期待できないが、これも例のやり方に替えて試してみることにする。

電源をGPIOピン経由にしても改善せず(4/1/2017)

 それは、以前の無印Raspiで愛用していた、GPIOピン配列に一緒に設定されているVccピンに直接5Vを供給する方法である。無印RaspiはUSBからのパワー供給は、ポリスイッチが間に挟まっており、こいつが悪さをして電源が安定しなかった。

 このポリスイッチを無効にすることで安定化したのだが、最も簡便なのはそのあとにピンに出ているVccピンに電源を供給してしまうことである。ポリスイッチが有効に動くのは、raspi基板内でショートなどで電流が流れることで、それは通常考えられない。これがなくても余り問題にならないという判断である。

 今度のRaspi3は、電源供給用に特化したUSBマイクロソケットがついており、その先の配線はRaspi2までと変わることはない。しかし、マイクロUSBのような小さな接点で、2Aを越す電流を安定的に送れるとは思えない。不安定さの要因のひとつになっているのではないか。

 そこで、前の無印Raspi同様、GPIOピンのVccに電源を供給し、いくつかの同じテスト(ブラウザー2本立ち上げ、motion動作、自分でストリーム受信など)をやってみた。残念ながら、マイクロUSBからの給電に比べ大きく改善されることはなかった。

電源制御装置で奇妙なトラブルにはまる (4/3/2017)
 問題なさそうなケーブルやACアダプターを選んで、何とか自作の電源制御装置を入れても安定して電源が供給されるようになった。

 ただ、SAMBAサーバーに使っている2.5インチHDDの電源供給(USBから給電)は、ただでさえ逼迫しているRaspi3の電源事情を考えて、当初から、セルフパワーのHUBを追加している。しかし、これでは、監視カメラを動かすのに2台のACアダプターが必要になり、取り回しが悪い。

 そこでせめて、ひとつだけのACアダプターでRaspi本体と、HDDをドライブするセルフパワーのHUBの電源にしようとした。ただ、セルフパワーHUBのACアダプターの受け口は、当研究所標準の2.1ミリジャック(秋月電子の標準と同じ)と違うので少々の加工が必要である。

 ところがこのテストをしているうち、妙な挙動に悩まされることになった。電源制御装置にACアダプター端子を追加し(単に入力をパラにしただけ)テストした時のことである。ブートしてRaspiのデスクトップ画面が順調に立ち上がった途端、電源制御のリレーが動いて切れてしまった。

 はじめは過電流が流れてRaspiがリセットしたのかと思ったのだが、勿論そんな状況ではなく、正確にリレーが働いて電源を切っており、症状は再現する。つまり、これはRaspiの消費電流量がシャットダウン時とみなされるまで低下していることを意味する。これはおかしい。Raspiは電源が切れるまで、ブートメッセージを始め、正常な動きをしている。Dsc01109

なんとUSBセルフパワーHUBが犯人(4/5/2017)
 こういう状況を放置しておけないのが所長の習性である。何が原因なのだろう。突き止めるまでは先に進めなくなった。幸いこのTiny13の電源制御装置は、裏蓋を開けるだけでデバッグ用のUARTにアクセスできる。字化けが何故か多いが(未解明)、そのときの消費電流と測定カウント、インターバルなどを表示する。

 このUARTをつないでスタート時からの電流量をモニターして驚くべきことが分かった。何と、このHUBのときは、Raspiには通常の1/3の電流しか流れていない。Raspiは普通、立ち上がりの時はかなり電流が流れるが、デスクトップが出てしまえばRaspiは200mA前後に落ち着く。これが通常の1/3だとシャットダウン時に想定している最高電流80mAを下回る。で、制御装置はシャットダウンと判定したのだ。 Dsc01111

 しかし、電流量が減ったのが全く理解できない。ブートは通常通り行われており、問題はない。するとHUBの電源を共通のACアダプターからとっていることが、これまで違ったところなので、これが原因であることは明らかである。しかし、理屈が合わない。USBコネクターから電源が供給される?そんな馬鹿な。

 試しにHUBを取り替えて別のHUBにしてみた。ははは、この問題は全く解消した。本当だ。セルフパワーのUSB-HUBの中には、スレーブからでもマスターのUSBパワーの電源を戻してやることがあるのだ。

体制は整ったが、突然、工作意欲がなくなる(4/14/2017)
 妙な現象は、手持ちのセルフパワーHUBの特性であることがわかった。症状の出ない別のHUBに切り替え、Raspiの監視カメラの電源整備はとりあえず一段落である。

 三脚の上にカメラ付きのRaspi3を置き、そこから電源用と、HDD接続用のUSBケーブルを2本出す。三脚の下にHDDとセルフパワーHUBを配置し、そこからACアダプターへの電源ケーブルを引くというレイアウトである。Dsc01108

 これをサンルームに持ち込み、テスト開始と意気込んだところに、珍しく風邪を引いた。これがかなり酷く、熱は微熱なのだが咳が止まらないうえ、声がしゃがれて出なくなった。こんなに喉をやられたことは記憶にない。無精して医者に行くタイミングを逃し、家人からあきれられた。

 そんなことで、突然工作意欲が湧かなくなった。電源制御装置のモニターのUARTの字化けを直そうと、久しぶりにAtmelStudioを立ち上げたりしているのだが、次の一歩が出ない。実はこのあいだネットで評判になっているESP8266の発展版、ESP32も買ってきてあるのだが、これも手が付かない。

 これまでにやった工作らしい工作は、傘の骨の修理(東急ハンズで修理用パーツをゲット)。DVDレコーダーリモコンの修理(これはカラ割には成功したが赤外線LED点灯せず。アマゾンで買い直し)。このあいだてこずったRaspiのBlueToothのテスト(キーボードは簡単につながったが、タイムアウトがあって使いにくい)、と脈絡のないことばかりである。

 まあ、これは意欲が戻るのを待つしかない。ブログもこのままではまずいので、とりあえず、中身はないが、これまでの報告ということで。

| | コメント (2) | トラックバック (0)

2017年3月25日 (土)

RaspberryPiのmotion動体検知の実用化に向けて

 このところRaspberryPi(以下Raspi)にはまっている。これを電子工作というのにはちょっと抵抗があるが、システム開発と言うのも何か大げさだ。まあ、Raspiは簡単にI/Oピンをいじれるマシンなので電子工作と言っても間違いではないだろう。

 巷(ちまた)には、Raspiに関する情報は溢れかえっている。しかし実用的な工作まで解説しているサイトは意外に少ない。あっても、詳しいのは導入までの工程で、そのあとの作業について解説しているところが少ないのだ。

 監視カメラに使うといっても、電源や、設置場所、耐天候対策、映像データの蓄積・管理など、検討すべき項目は数多い。この分野も既に専門家による大きな市場ができているので、素人が立ち入る場所がなくなっている。アマチュアがちょっと手軽にやってみるときの情報が少ないのは仕方がないのかもしれない。

 それに、アマチュアは作って動くところまでが楽しみで、動いてしまうと急激に興味が薄れるものだ(かく言う所長もその傾向を否定できない)。しかも、応用の方向は個人によって千差万別なので、参考にならないことが多い。このあたりは自分なりに開拓していくしかないのだろう。Dsc01068

 それはともかく、やっとmotionで想定した通りの動体検知システムが動き始めた。この監視カメラの運用までは、まだやることが沢山あるが、とりあえず一段落したのでブログに報告する。例によって時系列でまとめてあるので、話題が飛び飛びになることはご勘弁願いたい。

サブネット越しの名前解決(3/8/2017)
 直前の記事は、Raspi3をWiFiでつなぎ、SAMBAサーバーを動かすところまでだった。WiFiそのものは何事もなく動き、映像ストリーミングも快調に流れるのだが、SAMBAがなぜか通らない。撮りためるmotionの映像データは、何もしないとすべてRaspi3のSDカードに収容されるので、SDカードの耐久性が心配で、別のメディアを用意しておきたい。

 SAMBAにしておけば、リモートから監視映像を確認することもできるので一石二鳥だ。というので、SAMBAにこだわっているのだが、有線なら通るSAMBAが無線のWiFiではつながらないのである。

 WiFiルーターはブリッジで使っている(はずな)ので、同一のサブネットだと思うのだが、どうもSAMBAサーバーでは別のネットになるらしく、WindowsがRaspiを見つけられない。

 調べてみると、ウェブでは既知の問題点らしく、色々なところで解決法が紹介されている。要約すると以下のようになる。

(1)直接、PCでSAMBAサーバーのIPアドレスを指定してリモートドライブを定義する。WiFi越しでも通る(はずだ)。

(2)PC側のhostsファイルにサーバー名とIPアドレスを登録する。Windowsにもhostsファイルがあるとは知らなかった。しかし、これがとんでもないところにある。C:\Windows\system32\drivers\etcという深いパスの下にある。

(3)PC側のlmhostsファイルにサーバー名を登録する。これが正道なのだろう。lmhostとは、NetBIOSというWindowsのネットワークサービスの名前解決法である。このファイルも、hostsファイルと同じディレクトリにある。

 それぞれ試してみた。(1)は問題なく動いた。但し、固定アドレスをいちいち打ち込むのは運用上うまくない。他をあたってみた。(2)は、最初このファイルを変更することが出来なかった。さらに調べて、管理者権限が必要とわかり、エディター(Terapad)を管理者権限で実行させて変更に成功した。これも問題なくPCはサーバーを見つけてくれた。

 (3)も(2)と同じやりかたで、ホスト名とIPアドレスのセットを登録すると、WiFiでもSAMBAが動くようになった。一番、もっともらしい(3)にする。

Raspi3不調。OS入れ直し(3/9/2017)
 Raspi3の新機能のうち、まだ試していない機能がある。Bluetoothである。ただ、現在は、Bluetoothは、シリアルコンソールのUARTとぶつかるということで、停止している。実際に、ウェブにあるBluetooth関連のコマンドはエラーで戻って先に進まない。

 しかし、情報によれば、シリアルコンソールは、RaspiのBIOSにあたるconfig.txtに、クロックを固定する core_freq=250という設定だけで正常に戻るというのである。しかもBluetoothも動くという。

 今、Bluetoothを使う必要はないのだが、この方法が果たして有効なのかを確認するためBluetoothを動かしてみた。確かに、Bluetoothのセットアップコマンドは有効になり、Bluetoothが動き始めたような感じになった。

 ところが、Bluetoothのディバイスを持ち出して動作を試そうとしている間に、何故かRaspiそのものが正常にブートしなくなったのである。延々とエラーメッセージを吐き出すだけでブートが終わらない。ログインプロンプトまで行かないので何もできない。

 これまで加えたUART関連の変更(config.txtはPCから操作できる)を少しづつ元に戻してみるが、現象は変わらない。一番最初まで戻ったが、同じ状態である。恐らく何らかのBluetoothの設定ファイルが作られてしまい元に戻らないのだろう。設定ファイルをいじろうにもシステムが立ち上がらないので手の施しようがない。暫し途方に暮れる。

 余計なことをして、全く先に進めなくなってしまった。こういうときの一番の解決法は、OSを作り直すことだ。あれこれ悩んでいるくらいなら最初からシステムSDカードを作り直す方が手っ取り早い。Noobs

 手元に16GBのSDカードが見つかった(安売りショップで余りの安さに衝動買い)ので、今度はここに本格的なRaspbianをインストールしなおすことにする。ウェブを改めて調べる。どうも以前と様子が違ってOSのインストール方法が変わったようだ。

NOOBSって何だ?(3/10/2017)
 RasPiも例によって横道からつまみ食いをして動かしてきたので、最近の動向が良く見えていない。このNOOBSというやつが良くわからない。ウェブをさらにさまよい、これが複数のOSを選択インストールできる最新の方法であることがわかった。

 以前やっていたOSのカーネルをイメージファイルで、そっくりコピーする方式はどこへ行ったのだろう。ちょっと探したところでは見つけることが出来なかった。で、このNOOBS方式(ノービス、初心者向けということか)を試してみることにする。

 どうもこいつは、HDMIケーブルを使った画像デスクトップを要求するようだ。Raspiのデスクトップは、この前のSharpの7インチIGZOパネルを用意していたが、これが新しいOSで動くためには、またあのconfig.txtに修正を加える必要がある。面倒なので、PCのディスプレイと共用にする。

 太いPC用のHDMIケーブルを接続し、SDカードに展開したファイル群に起動をかける。よーし、画面にそれらしい起動画面があらわれた。ここではおなじみのRaspbianを選ぶ。他の選択肢にも興味をそそられたが他のは情報が圧倒的に少ないので選択の余地はない。

 Windowsと同じようなビルド画面が延々と続き、数十分でセットアップは終了した。そうか段々こいつもWindowsに似てきたな。キーボードとマウスをUSBハブにつけ準備を整える。順調にデスクトップが立ち上がる。ウェブブラウザーは既に日本語化されていた。20170324234018_1920x1080_scrot

 それにしてもあらためてRaspi3の速さを実感する。1920x1080の画面がスムーズに動く。ネットサーフィンも全くストレスなしに楽しめる。Linuxで動かす分にはもう十分な実用性があるように思えた。

新しいOSはデスクトップからでしか動かない?(3/13/2017)  
 デスクトップからの立ち上げには成功した。ところがシリアルから立ち上がるコンソールが動かないのである。SSHは動くが、シリアルは無反応である。シリアルはハードに直結しているので、ネットがおかしくなったり、デスクトップがおかしくなった時の緊急時のために動かしておきたい。

 ウェブを探していたら、何と、Raspi3からはシリアルはオプションで通常はdisableだという。(ここがとても参考になった。)

 あわてて、デスクトップの仮想ターミナルで、raspi-configを入力し、シリアルをenableにしようとした。なんと、そこにはシリアルを有効にする項目がないのである。ありゃー、これはどういうことなのだ?

 気を落ち着けて、ウェブの説明を最初から読み直す。なになに、デスクトップの「設定」メニューにはシリアルのenable/disableボタンがあるではないか。画面から「設定」を選び、最初のconfig.txtの部分を開く。ほんとだ。ちゃんとある。

 これをenableにして、rebootをかける。おおー、コンソールにブートメッセージが戻ってきた。やれやれ、これで一安心である。それにしても、以前のイメージファイルからのOSは何だったのか。

Raspi3は少しづつ元に戻る。マウントの制作(3/15/2017)
 OSを入れ直して、さらにWiFi化や、SAMBAサーバー、motionのインストールなど原状復帰の作業を進める。そのかたわら、定点監視カメラの本格的な実装に向けた工作も始めた。

 まず、ヨドバシでカメラ用の安い三脚(¥4000)を手に入れ、マウント台をアクリル板から自作する。マウントへのRaspiの固定は当初は輪ゴムで良いだろう。本格的にはいずれ別の方法を考える。Dsc01067

 久しぶりのアクリル工作である。楽しい。アクリル板からRaspiを載せる10X8(cm)の台座と、固定用の1/4インチボルト(これは万国共通のようである)を埋め込む2枚のホルダーを切り出す。以前、USBカメラを固定するのに使った方式と全く同じやり方である。

 これを2液混合のエポキシ系接着剤で接合した。乾燥のため一日放置し、これで丈夫になっただろうと実際に三脚に付けてみた。これが何と、少し力をかけただけでポロッと簡単にはがれてしまった。

 えー、エポキシ系ってアクリルにはつかないのか。前のUSBカメラのときは問題なかったのに。あわててGoogle先生にお伺いを立てる。接着面があまり滑らかだと接着力が落ちるらしい。そういえば前のUSBカメラの表面は梨地だった。

 そこでアクリル板の接合面を紙やすり(#200以下)で表面が曇るまでこすり、念のため別の新しい2液混合の接着剤にしてやり直してみた。今度も一日乾燥させる。試してみた。うむ、今度は大丈夫なようだ。 Dsc01071

 ついでに、近くのDIY店で、滑り止めのゴムシート(厚さ1ミリ、商品名エラストマーシート)を買ってきて、台座に合わせて貼り付ける。これは強力だった。輪ゴム程度の固定でしっかりカメラは固定された。よし、これで定点カメラの固定は万全になった(屋内専用)。

カメラモジュールのパイロットLEDの明度を下げる(3/17/2017)
 定点カメラにするためには直しておきたいところがある。カメラモジュール正面のLEDだ。動き出すと赤く光るのでわかりやすいが、カメラの正面に煌々と赤い光が点くのはまるで威嚇しているようにみえてまずい。

 このLEDをソフト的に消すことはできる。設定ファイルのconfig.txtで、disable_camera_led=1とすれば消えるが、カメラが動いているかどうかの確認が出来なくなるのも困る。

 そこで、LEDの位置を変えようとカメラモジュール基板を色々調べる。カメラチップのピンがビアを通して正面に出ている。これを利用して裏に移すことを考えたが、裏面にはスペースが余りない。しかもこれはかなりな手間だ。 Raspiled

 で、結論はLEDの制限抵抗を増やして暗くすることにした。基板についている抵抗は220オームである。どれくらいの抵抗が良いのか、適当な赤LEDをブレッドボードに差して(同色なら似たような特性と仮定)試してみる。

 10Kオームくらいでも結構明るく輝く。100Kではさすがに暗すぎる。久しぶりに例の低温ハンダを持ち出す。LEDのところに広がらないよう細心の注意を払ってハンダをつける。よーし、簡単に抵抗ははずれた。低温ハンダをハンダ吸い取り線で入念に除去する。

 部品箱の中から昆虫採集のように残してあったチップ抵抗のコレクションから10KΩを探し出し、交換する。パターンは1005だったが、手持ちの1608でも実装可能だった。交換作業は30分もかからなかった。

 試してみる。うん、10Kでも明るすぎるくらいだが、これくらいなら目立たないで良い。いや、くだらない作業だったが、何かとても充実した気持ちになった。

本格的なmotionの設定。画像はとれたが管理が大変(3/22/2017)
 準備が進んできたので、いよいよ、motionの監視用のソフト仕様の検討に入る。motion.confの膨大な設定パラメーターを、我慢して最初から読みはじめる。

 バージョンに新旧があるようで少し混乱するが、読み込んでみるとそう難しい構造ではなかった。大きく分けると静止画(動きを確認したところでのスナップショット)と、その前後の動画の2種類をアクションごとに保存していくようだ。Motion1 Motion2

 沢山のパラメーターがある(動きを検知する前の画像の処理とか、動かなくなってからの動画の記録をどこで止めるとか)。

 管理的には、スナップショットの静止画と、動画は別々のフォルダーに残しておきたいが、これはどうも無理なようだ。

 記録を始める動きの範囲の大小は、実際に動かして見て決めるしかないだろう。ファイルの置き場所は、SAMBAのHDDに指定する。とりあえず、以下のようなパラメーターで監視を始めることにする(変更したところのみ)。

width 640     (320)      Raspi3ならこれくらい画像を大きくしても十分見られる
height 480    (240)
framerate 12  (2)          あまり大きくすると時間遅れが大きくなるようだ
netcam_keepalive on (off)       HTTP/1.1を使ってストリーミングの性能向上
threshold 3000 (1500)             これはとりあえず。これでも結構敏感に反応する
pre_capture  1    (0)                      検知する前の画像も記録する。
event_gap    5    (60)                     検知したあと、不感となる時間(秒数)
max_movie_time 10  (0)                 動画記録の最大時間(秒数) 0は制限なし
output_captures best (on)        検知した一連の画像のうち最大変化量の静止画を残す
output_debug_pictures on (off)   静止画を検知するときの2値化した画像で残す ffmpeg_output_movies  on (off)    検知した時の動画を記録する
locate_motion_mode    on (off)     検知した画像の部分を4角で囲む
target_dir /SAMBAファイルのパス (/var/lib/motion)記録データの保存場所
stream_motion   on  (off)            ストリーム配信をする
stream_maxrate  20  (1)          ストリーム映像のフレームレート
stream_localhost off     (on)        ストリーム配信を自分以外にもする
webcontrol_localhost off   (on)  各種パラメーターの設定を自分以外でも変更可能

 以上の設定で、工作ルームでのテストでは、手を振ったり、動いたりすれば確実に画像が記録されるのを確認した。これが実際の道路を移して所定の画像がとれるのかはわからない。

Dsc01070  このあとは三脚をサンルームの道路に面した場所に置き、観測を開始することにする。さて、どんな映像がとれるか、久しぶりにわくわくする気分である。このあたりで今回の記事は一区切り。次回をお楽しみに。

| | コメント (0) | トラックバック (0)

2017年3月 6日 (月)

やっぱりRaspberryPi3は早い

 RaspberryPi(以下Raspi)の定点カメラのハードとOS周りの整備は完成した。次はアプリである。定点カメラの細かい仕様は、まだ決まっていない。とりあえずは、通行中の人や車をチェックする(家の前で何が起きているか監視する)ぐらいのことを考えておく。厳密なものではない。

無印Raspiは遅い。motionはすんなり動いたがカクカク(2/3/2017)

 満を持して無印Raspi(初代のRaspberryPi B)に、motionパッケージをインストールする。Raspi3は電力消費が大きいので、無印の方で動くなら動かしたい。無印RaspiのOSはこのあいだ更新した。アプリを入れる前にapt-get updateと、upgradeをかける。

 うーむ、何かエラーが起きているようだ。updateが進まない。エラーメッセージは「サイトが見つからない」と怒っている。えー何故だ。apt-getを中止して、pingをかける。何だ何だ、ネットワークが外へ出ていっていない。

 そう言えば、RaspiのIPアドレスを固定にするため。staticアドレスに変えた。設定ファイルを確かめる。DNSはちゃんと定義してある。何で行かない? 面倒なので、DHCPに戻す。問題なく外部へpingが通り、apt-get updateは無事終わった。upgradeに入る。これがまたえらく時間がかかる。小一時間かかった。件のmotionの方は何のことはない数分でインストールされた。

 このあと、IPアドレス設定ファイル(/etc/dhcpcd.conf)の中を見るともなく見ていて、とんでもないミスを発見した。DNSを定義する設定行domain-name-servers=XXX.... が、server=になっていた。Linuxは無口で、こういう誤りは教えてくれない。

 motionの設定でもまた少しまごついた。最初の設定値(デフォルト)ではサーバー外へのストリーミングを許さないのだ。ウェブ上の情報と、実際のパラメーターの名前が微妙に違うので結構混乱する。それにしてもこの設定量の多さには辟易する。ここの記事が親切だ。

 エディター(nanoこいつは便利だ)の検索機能(ctl+W)を使って目的のパラメーターを探し出した。stream_localhost off (ウェブ上ではwebcam_localhostになっている) これを直せば、すぐに画像が表示された。

 しかし、遅い! 前はもう少し早かったような気がするが、640ドットはお話にならないくらい遅い。320x240の画面でもカクカクして見にくい。景色を見るだけならともかく監視には使えない。シリアルコンソールには、motionが残しているファイル名が延々と出ているので、無駄な設定をしている可能性はある。うーむ、無印Raspiでこのまま行くか、Raspi3に上げるか迷うところだ。

mjpg-streamerは早かった(2/6/2017)
 motionは動体検知の機能がついているので動きが重い。320x240の画像のストリーミングでも2~4fps(フレーム/秒)がせいぜいだ。動きを検知するたびにデータフォルダーにaviファイルを大量に残しているようなので余計遅くなっているようだ。

Mjpgstreamer  これを止めようと、あれこれ設定をいじったが、うまくいかない。これからの目的(路上の不審者の究明)には、このソフトがうってつけなのだが、なかなか手ごわい。motionの仕組みそのものを理解していないので、どう止めるのか行き当たりばったりである。一番無駄な方法だ。

 motionばかりにこだわっていても先に進まない。で、以前使ったもう一つのストリーミングソフトmjpg-streamer(これにapache2とでライブカメラにした)を導入することにした。動体検知はできないがライブカメラとして使える。motionより早いはずだ。

 このアプリは、ソースコードからである。この前は、ダウンロードに手間がかかり、コンパイルエラーが出たりして大騒ぎだったが、今回はスムーズにインストールされた。バージョンが上がったのかも知れない。

 早速試してみる。おおお、こいつは早い。無印Raspiでも640x480の画像が滑らかにでる。Raspi3ならもっと早いだろう。motionのように動体検知は出来ないが、ストリーミングだけならこれで十分だ。

Raspi3に切り替える。シリアルコンソールが字化け(2/14/2017)

 Raspiのカメラモジュールは当初の目的(定点カメラ)をほぼ実現した。ただ、2つの無印Raspiには既にお役目がある。ひとつはSAMBAサーバー、もうひとつはパンチルトが出来る外部ライブカメラのメインマシンである(いずれも最近は使っていないけれど)。

 Raspi3は現在具体的な用途が決まっていない。こちらに移した方が合理的である。それに無印では遅かったmotionも早くなって、最終目的の動体検知が実用になるかもしれない。 折角、無印Raspiで動いているのを改めてRaspi3に移すのも二重手間だが、どれくらい早くなるのかも試してみたかったので移し替えることにした。

Dsc00976 まずは、Raspi3のケースに、カメラを固定する工作を加えなければいけない。Raspi3のケースを手に取っているうち閃いた。カメラの固定は、無印の時はケースについている段差(というより縁)を利用している。これをRaspi3の時も使えば良い。そう、縁のかわりをアクリルの細い棒で再現するのだ。

 早速、アクリル棒を切り出し、瞬間接着剤で固定する。差してみる。おお、うまくはまった。ちょっとテーバーが付いているので(勝手にできたのだが)、ピッタリだ。よーし、良いぞ。こんなささいなことでも、何かとても幸せな気分になれる。次はソフトだ。

 当研究所のRaspi3は、去年の6月に買ったので、OSはJessieで、例のカメラモジュールのディバイスファイル化は済んでいる。7インチのIGZO液晶パネルを動かすため、日本語化までやったがアプリは全く入れていない。久しぶりに火を入れることにする。シリアルコンソールをつなぎ電源をON。

Dsc00977

 おやあ、シリアルが字化けだ。前はどうした。あ、前は、HDMIケーブルでデスクトップ画面を出していたのでこれを使っていない。あわててシリアルの接続ピンを確認する。間違っていない。そりゃそうだ、化けた文字がでているのだからハードがおかしいのではない。

 こういうときは、Google先生に聞くのが一番だ。調べてみるとすぐに原因が明らかになった。Raspi3では、そのままだとシリアルコンソールがまともに動かないとある。入出力ピンが新しく入ったBluetoothのUARTと共用になったためらしい。

 これはあとの話だが、SAMBAのインストールをしたらまたおかしくなった。この解決は、ここ(http://akkagi.info/20161004_web/)に詳しい。要はmdline.txtの中を変えれば良い(と言ってもconsoleの順番を変えただけ)。これでやっとシリアルコンソールは安定した。

Raspi3にもSAMBAサーバー(2/19/2017)

 ついでに、このRaspi3にもSAMBAを入れる。SAMBAはすんなりインストールされたのだが、WindowsからSAMBAディスクが見えない。Raspi側の状況は問題ないのに。なぜだ。

 居間で使っているWinXPのネットブックではいつもどおりディスクが見えるので、これはこのWindows10の問題である。これもWebに情報を求める。うーむ、SAMBAの認証がえらく面倒くさくなったようだ。

 まず、Raspi側でSAMBAサーバーにsmbpasswdにユーザーIDとパスワードを定義し、Windows側ではネットワーク資格情報なる登録がいるようだ。この前までは、何もしなくてもすんなり読み書きができたのになぜだろう。

 SAMBAの設定パラメーターも、motionに負けず劣らず膨大な量なので、ことは簡単ではない。いくつかのウェブ情報を頼りに、せっせと設定を入れ込む。うまく行くときと行かないときがあって混乱する。

 リモートディスクの設定方法が複数あるのが混乱のもとだ。このユーザーIDというのはWindowsのなのかLinuxなのか、SAMBA固有なのか良くわからない。うまく行くとユーザーIDの入力は求められないが、求められたときは、正しい(と思われる)IDを入れてもはじかれる。

 何度もやっているうち、何とか安定してディスクがつながるようになった。Windowsは「ネットワークドライブの割り当て」から始めるのが確実なようだ。しかし、この「割り当て」のアイコンを出すのが結構難しい。Windowsのエクスプローラー(ファイラー)も機能が肥大してしまっている。

Raspi3のmotionは早かった(2/21/2017)

 まあ寄り道ばかりしていても仕方がない。本来の目的に移ろう。motionのインストールだ。これは問題なくインストールされ、定義ファイルの修正も何度目かなので順調に終わった。カメラモジュールが動くことは、raspistillなどの専用のコマンドで確認してある。

 Raspi3のOSは、Jessieなのでカメラモジュールは既にディバイスファイル(/dev/video0)になっている。motionは何もしないで動くはずだ。動作させる。赤いLEDが点灯し動き始めた。しかし、ストリーミングは始まらない。

 コンソールには何か延々とバックアップの画像ファイルを残していくメッセージが出るだけだ。えーなんで。何も変えていないよ。設定ファイルがおかしいのか、もういちど確認する。いや無印のときと変わっていない。

 OSもアプリも全く同じだ。それなのになぜRaspi3では動かない。設定ファイルを何度も確認するが、変わったところはない。暫く途方に暮れる。仕方がない、派手に出ているmotionの起動直後のメッセージを地道にひとつひとつ調べていくことにした。

 すると、コマンドを入れた直後のメッセージで、motionの設定ファイル/etc/motion/motion.confがないというメッセージが見つかった。ええー、そんな馬鹿な。さっきエディターで編集したばかりだ。何故だ? ああー、もしかすると motionに設定ファイルを読む権限がない? つまりmotionをsudoをつけずに動かしているからか。

 そのとおりだった。sudoを付けて動かすと問題なくストリーミングが始まった。しかしそれにしても、今までsudoをつけていたっけ?motionの設定ファイルmotion.confの属性がおかしい。オーナーがrootになっているのはともかく、他ユーザーに読めないようになっている(パーミッション600)。

 これではsudoがないと動かないはずだ。以前は一般ユーザーでも動いていたように思う。まあ、それはともかく、chmodで属性を644に替え、一般ユーザーで見えるようにする。動かしてみる。うむ、正常に立ち上がった。

 ストリーミングはどうだ。焦る手でPCのブラウザーを開く。出た。おおお、こいつは早い。無印に比べたら雲泥の差だ。640x480でも軽く20FPSくらいはいっていそうな滑らかさだ。さすがRaspi3だ。遅延は少し(0.5秒程度か)あるが、監視には全く問題がない。

 これはRaspi3で決まりだな。電源は元から電池にするつもりはないのであまり障害ではない。ACアダプターに大きいのが必要なだけだ。

自宅前の定点カメラのテスト順調。夕方でも鮮明(2/25/2017)
 いよいよフィールドテストに入る。自宅前の道路に面したサンルームの一角に3脚を据え付けカメラ付きのRaspi3を固定する。電源を入れ、LANケーブルを延長して(早くWiFiにしよう)接続する。動作中を示すカメラの前の赤LEDが眩しく、道行く人は不審に思うかもしれないが、これはいずれ消せる。

Raspi3_motion  ネットブックを持ち出し、ストリーミング映像を確認する。うん、良く映っている。窓ガラス越しだが、視認性は高い。解像度も問題ない。車の通行も飛ばないで映っている。いやあ、これは簡単だ。定点カメラとしての実用性は十分だ。

 日が暮れてきた。人間の目ではかなり暗いが、映像ではまだ十分な明るさだ。これでmotionの動体検知の機能を稼働させ、画像ファイルをSAMBAに入れて、遠隔地からその画像を確認するという手順が可能になった。

 カメラの固定がまだ仮りの状態なのと、引き回すのに有線LANではなく、WiFiにすることが課題に残っているが、今回のプロジェクトは何とか想定通りに進みそうである。

無線LANでもmotionは快調に動いたが。SAMBAが不調(2/28/2017)
 最後の仕掛けに挑戦する。Raspi3から実装されたWiFiである。定点カメラの移動の際、有線LANではなく無線(Wifi)にできればとても楽だ。セキュリティの問題はあるが、どうせ家の中から撮った外の景色が外に漏れたとしても大した問題ではない。

 Raspi3の無線LANの設定は多数のウェブサイトに紹介記事があり、インストールに不安はない。適当なサイトを選んで設定を進める。ただ最近の改定で、設定方法がかわり(dhcpの指定ファイルが一元化された)、設定方法が複数あるようで少し混乱する。

 LANケーブルがなければカメラの移動は大変楽になる。電源ケーブルさえ気にしていればいいからだ。motionの結果は、ストリーミングを利用して他のサーバーに送ったり、SAMBAディスクに記録して離れたところから眺めたりできる。

 WiFiの設定は、簡単にできた。ifconfigでIPアドレスを確認する。ここも、固定アドレスにする。メインPCからSSHでRaspi3にログオンする。よーし、入った。次はいよいよ動画ストリーミングだ。

 おお、何の問題なく画像が出た。動きは有線のときと全く遜色ない円滑さである。いやいや、これは楽だ。今後、Raspi3を移動体に載せて動画中継をすることも可能になる(電源が大変だけど)。

 勢いに乗って、SAMBAサーバーが動くか確認する。しかし、Wifi経由では、SAMBAがつながらなかった。確かに、有線LANと無線LAN2つに経路が出来たとき、経路を選ぶ設定パラメーターはSAMBAにはない。何か別の理由があるようだ。

 調べ始めると、意外に根の深い問題であることがわかった。そのうち確定申告の期限が迫ってきて、電子工作に時間がかけられなくなった。このあたりで記事をまとめて、話の続きは次回に報告するとしよう。

| | コメント (0) | トラックバック (0)

2017年2月 1日 (水)

RaspberryPiのカメラモジュールで定点カメラの野望

 今年もみなさまに新年のご挨拶をする前に、1月も終わりになってしまいました。昨年同様、正月早々、家族が酷い風邪にやられました。だいたい年末のお節料理の準備で精魂つきはてるようです。

 そんなことで初詣にも行けない散々な状況でしたが、本人だけは5日に学生時代の仲間と珍しく正月七福神詣でをすませ、とりあえず年神さまには義理をはたしました。

Dsc00830 その話はあとでするとして、電子工作の方は相変わらず低調です。というのも昨年来のPCのビデオボードのトラブルが解決せず、これにこだわって万事が進みません。MPU6050の次のテーマとして、滞留在庫の整理を兼ね、RaspberryPiの組み込みカメラモジュールの動作テストをするつもりでしたが、具体的な目的が決まるまで迷走が続きました。

 昨年予定していた忘年会が色々な都合で持ち越しになり、このところ連続して新年会があったことも進まない原因のひとつです。それでも何とか、試行錯誤でアクリル板のカメラマウントをでっちあげ、想定した定点カメラが形になってきたのでブログに上げることにします。以下の報告は備忘録を兼ねているので時系列でわかりにくくすみません(2/1/2017記)。

ビデオカードの不具合に悩まされる(12/29/2016)
 暮れも押し迫ってきたが、電子工作は思わぬ展開で先に進まない。ジャイロセンサーMPU6050の3Dライブラリーのために替えたビデオボードのせいで、メインのPCが頻々とフリーズを繰り返し、安心してPC作業が出来なくなってしまったのだ。

 症状は、ワープロぐらいでは起きないが、動画を見たり、ゲームをしたりすると、画像が途切れエラーメッセージが出る。そのあと復帰することが多いが、時にはフリーズしたり、システムがリセットしたりする。このPCは電子工作専用ではなく、汎用的に使っているので何とかしなければならない。

 出てくるエラーメッセージは「ビデオドライバーの応答がないので、システムをリセットする」というもので、例によってこのキーワードでネットを検索すると、膨大な量の記事がヒットする。Win7時代からの古い問題のようである。何らかの原因で、GPU(ビデオボードのCPU)の応答が遅いと、OSがそのアプリの実行を止めてしまうというものだ。

 少なくとも、元々の内蔵ビデオインターフェース(Intel)では起きていない。ウエブにある症例では、NVIDIA系のボードが圧倒的に多いが、AMDのRADEON系で全く起きないわけでもないという。ワープロや簡単なウェブサーフィンくらいでは起きないが、グラフィック画面で(ゲームのトランプのカードの移動だけでも)大体おかしくなる。

 年賀状も書き終えて、少し暇になったので、色々な対策を片っ端から試してみた。まず、デフォルトで2秒というレジストリーのパラメーターのタイムアウトの時間を、レジストリエディターで5秒に延長する。これでエラーの様子が少し変わったが、頻度はかえって多くなったような気がする。

 次が、ビデオドライバーの更新である。ビデオカードに付属していたドライバーはネットで調べると少し古いので最新のものにとりかえる。全く変化なし。古いドライバーが残っているとおかしくなるというので、ユーティリティを使って古いドライバーの削除とクリーンインストール。これも駄目。

 サイトによっては、NVIDIAのコントロールパネルでのオプションの設定変更だけで綺麗に治ったというのがあったが、全く効果なし。こんな簡単なことで治るわけがないと思う。

 さまざまなことを試してみた。結局のところ最初に比べれば発生頻度は少なくなったような気もするが、完治はしない。頻度が少なくなったとはいえ、ゲームで遊んでいて大事なところでフリーズに見舞われると気晴らしにもならない。フリーズは1分ほど待つと前の状況に復帰することが多いのだが、タイミングが悪いとそのアプリが落ちたり、システムが完全に止まったりする。

 マザーが古すぎて新しいビデオカードと合っていないというのが、どうも最大の原因のような気がする。しかしマザーを変えるとなると、CPUとメモリーまで入れれば、やはり数万円はかかるだろう。そんな馬鹿なことはしたくない。3Dを見るだけのためにとんだ疫病神を引き込んでしまった。

ビデオカードの不具合に決着つかず。別のボードを発注(1/2/2017)

 いずれにしても、こんなに長い間(少なくともWin7時代から)ユーザーを悩ましている問題が全く解決されていないというのも、このPC業界の不思議なところだ。最近のビデオボードのオプションは3D関係(恐らくDirectXというパッケージ)だけで軽く10個以上あり、何か技術の末端肥大を感じさせる。モンスター化して制御不能になってしまっているのではないか。

 年が明けても、あきらめきれず色々しつこく試していた。最も基本的なハードの部分、カードスロットの接触不良を疑い、ビデオボード基板の接点の掃除と差しなおしを何回かやったが、事態は進展しなかった(これで劇的に治ったという報告もある)。

 メモリーとの不適合を指摘するサイトがあり、そこではメインメモリーを交換したら解決したとあったが、この少し古いPCのメインメモリーを買いなおすのはやりたくない。(このサイトは系統的に良くまとめられている。高知の自作パソコンショップが2009年に詳細な調査を行っている。結論はメモリの相性問題ということだ。)

 メモリ交換でなく、PCのBIOSのアップデートでも解決したというサイトもあった。これなら費用もかからない。早速試してみた。久しぶりのBIOSのアップデートである。マザーボードのASUSのサイトを探すと幸い現在のバージョンより先のBIOSが見つかったので(もう2年も前のやつだったが)、入れ替えてみた。

 動かしてみる。ふむ、起きない。これが原因だったのか。暫く使う。駄目だ。1時間ばかり経って、やはり再現した。頻度は明らかに前より少なくなったようだが、全く0にはならない。

 マイクロソフトの基本ドライバーでは全く起きないので最悪の場合はこれに戻せば良い。ただ、このドライバーは3Dをサポートしていないので、Processingの飛行機は動かない。元の内蔵ボードに戻しても動かないことは同じだ。PCを取り替えるという手段も本末転倒である。だとすると、どういうことになる? そう、トラブルの報告の少ないRADEONのビデオボードをウェブで発注してしまったのだ。

谷中七福神詣でをしてきた(1/5/2017)
 しかしお正月なので、品物はすぐには来ない。というので新年での行事をご紹介しておこう。このあいだの筑波山歩きの山(街)歩き仲間が誘ってくれた七福神めぐりである。例年この仲間は、新年に都内の七福神詣でをしているそうだ。今年は、江戸最古という触れ込みの谷中(やなか)の七福神である。

Dsc00839 Dsc00845

 出発点は田端駅近くの福禄寿を祭った東覚寺で、ゴールは上野不忍池の弁天堂である。距離にしておよそ12キロ。街歩きとしては丁度頃合いの長さだ。昔の人は良く考えている。我々一行は正月5日、田端駅に集合した。

 歩き始めてまず驚いたのは、お正月ということもあるが、参詣者の多さである。それも高齢者の小団体が多いのでうっかりしていると他のパーティに紛れて迷子になる。我々も参加者が10人を越えていたので、グループを2つにわけて行動した。 Dsc00857 最近は御朱印帳で参詣の印を押してもらうのがはやっているが(スタンプラリーと同じ趣向)、ここには七福神をイラストした色紙(¥1000)が売られている。ここに各寺、神社の朱印を押してもらう(各¥200)。帰って壁に貼ると結構な正月飾りになる。

 田端駅近くの最初のお寺が少し離れているだけで、ほかは、いわゆる谷中墓地に点在するお寺の敷地内に七福神の祠がある。人通りが多いのはみんな七福神詣の人たちである。お寺によっては長い行列ができている。Dsc00849

 幸い、風もなく絶好の散歩日和で、不忍池の弁天堂で満願成就である。ちょうど日も落ちて来て、お酒を飲んでも後ろめたくない時間になってきた。解散する前に近くのビヤホールで新年を祝って乾杯である。いや生きてきてよかった。

ビデオカードはカードの交換でけり(1/9/2017)
 発注していたビデオカードが届いた。正月休みだったのでネット販売にしては少し時間がかかっている。今度はNVIDIAでなくてRADEON(ATI)である。

 こちらは3Dゲームなどには関心がない。安物で十分だ(玄人志向のHD6450 ¥4000少々)。実は年の暮れ、また秋葉原を覗いたのだが安いものは店頭には殆ど売っていなかった。店頭販売では単価の低い商品は効率が悪いからだろう(数万円が売れ筋のよう)。通販のポイントが溜まっていたので、出費は¥2000程度ですんだ。 Dsc00865 早速、とりかえる。PCI Expressの仕様がやっとわかってきた。前のビデオカードGT710は、PCI Express X8で、今度のHD6450は、X16(スロットのバス巾)ということが始めてわかった。最初のボードのスロットにすき間があったのはそういうことだったのだ。

 結果は予想した通り、トラブルは完全にきれいさっぱり解消した。何時間動かしても、全くフリーズは起こらない。古いマザーとの相性問題というが、これはやっぱり、NVIDIAの不具合としか言いようがない。性能的には、GT710より、3D性能が少し低いが、2DはむしろRADEONの方が高く、何といっても安定しているのが一番である。

 やれやれ、3週間近く悪戦苦闘したあの時間は何だったのか。この執筆時点(1/31)でも起きていない。PC関係で、このあいだのマザーボードといい、このNVIDIAのビデオカードといい、不要不急の部品がまた増えてしまった。ともあれ、これでやっと、本題の電子工作に戻れる。

RaspberryPiのカメラモジュールはあっけなく動いた(1/12/2017)

 電子工作の話に戻る。テーマは、このあいだRaspiのディスプレイを買ったときについでに買ってあったカメラ(Raspi カメラモジュールV1.3 ¥3000少々)はまだ一度も動作させていない。部品棚に眠ったままである(このモジュールは既にV2になって画素数も800万と高性能になっている。価格は高くなってしまった) Dsc00855

 実用ということでは、はっきりした目的はない。自宅の前の道から吸い殻を車寄せに捨てる不届き者がいて家族が怒っている。これを動かして、定点カメラか、ドライブレコーダー的な使い方をしてみれば面白いかもしれない。

 現在、当研究所には、3台のRaspiがある。無印のRaspiが2台(SAMBAサーバー、パンチルトの出来るライブカメラでいずれも最近は電源が入っていない)と、Raspi3が一台である。Raspi3は用途が決まっていないが、電力喰らいなので、無印のSAMBAサーバーにカメラをつなぐ。

 カメラは、最初、逆刺し(絶縁面に接点側が入るので副作用は心配なし)して動かなかったが、このサイトの案内で、専用のコマンド(raspistill や、raspividなど)を使い、簡単に静止画や動画を撮ることができた。

 検証は、SAMBAなのでWindowsディスクにコピーして、PC側で見る。RaspiでXwindowを動かすほどのことでもない。SAMBAサーバーにカメラをつけたのはこれが理由である。

 500万画素もあるので鮮明な画像だ。ビデオも問題なく撮れた。ビデオの再生は、WinPCでは動かなかったので、例の7インチのIGZOパネルを使った。

 config.txtの設定データをこのSAMBAサーバーに移してデスクトップを表示させた。これも順調に液晶パネルが動作し、例の超微細なデスクトップが現れる。シリアルターミナルから、ウェブサイトで教えられた動画プレーヤーomxplayerを実行させる。

 画面はデスクトップ画面である。何かもうひとひねりしないと画像が出ないと思っていたが、一息待ち時間があったあと、突然、画面全体に、工作室を逆さ(カメラモジュールが逆さまになっていた)に映した動画が見事再生された。5秒で10MBばかりのハイビジョンクラスの画像である。とても滑らかな再生で驚く。

久しぶりのアクリル工作は大変だった(1/17/2017)
 さて、カメラは動いたが、課題が2つ残っている。カメラのマウントと、カメラを汎用的なビデオディバイスにすることである。現在は専用のコマンドからで、motionや、mjpg-streamerのようなライブカメラのシステムを動かすには、/dev/videoなどのディバイスファイルにしないといけない。

Dsc00854  それはさておき、まずはカメラマウントの制作である。カメラモジュールは2センチ四方の小さな基板だけであり何らかのマウントが必要だ。それに、FFC(フレキケーブル)が短く、堅いのでカメラの固定が難しい。定点カメラにするならRaspiごと固定する手段が必要だ。

 手持ちのアクリル板を、いつものアクリル曲げ器を使って、カメラマウントに加工することにした。モデルは以前作った赤外線センサーのマウント台である。アクリル板を曲げて2つのコの字フレームを作り、ヒンジで接合する。

 部品庫に眠っていたA4ほどのアクリル板(厚さ2ミリ)をサーキュラーソーで、切り出す。小さなサーキュラーソーなので、20センチ近い長い板の切断は苦手だ。切断面がどうしても歪んできて回転部分の摩擦が大きくなり、下手をすると大事故の心配がある(材料の破損とか飛散)。 Dsc00862

 何とかだましだまし切り出した後、アクリル曲げ器でコの字型のフレームに曲げる。温度が少し低すぎるのか、どうもうまく曲がらない。久しぶりなのでノウハウを忘れてしまっている。温度を上げて何度か曲げを調整しているとき、少し力を入れて整形していたら、ポリっと割れてしまった。

 アクリル板は何度も同じところに熱をかけて曲げていると強度が極端に落ちることを忘れていた。焦げない程度に一気に強い熱を加え一回で曲げ切らないと材料が劣化することを、終わってから思い出す。やれやれ年はとるものではない。 Dsc00863

 結局、外側のフレーム(マウントを固定する方)は2回作り直した。2回目はサーキュラーソーが心配でコッピングソー(糸鋸盤)を使った。外側を半円形に切ると、少しそれらしくなった。

 このあと苦労したのが、チルトさせるためのヒンジの穴あけである。平面時に穴あけして正確な位置合わせをすることは殆ど不可能なので、曲げたあとから穴をあけるしかない。正確な位置決めのため小さいドリル穴から全部リーマーで直径15ミリまで円形を広げたのだが、これが大変で、指に豆を作ってしまった。

 苦労の結果、何とかそれらしいマウントが出来た。ただ、リボンケーブルが固くてマウントそのものを固定しないとカメラを安定した位置に止めることができない。実用的には、Raspiのケースそのものに固定する必要がでてきた。

試行錯誤の結果、まずまずのマウント(1/30/2017)
新年会が続いて工作の時間がとれなかったが、少し落ち着いたので、久しぶりにAitendoに行き、FFCケーブルと無印Raspiのケースが安売りされていたので購入した。

 FFCケーブルは、カメラのケーブルを下から出したくて順目のケーブルを買ってきたのだが、つけてみて大失敗に気づく。このまえのESP8266変換基板のときと全く同じである。FFCケーブルの接続面を替えたら接続は全く逆になる! これをつけてからそれに気が付く馬鹿さ加減にまた暫し呆然となる。

 これは買いなおすとして、はずみで買ったRaspiのケースはあたりだった。うまいぐあいにケース上段に段差が出ていたのでそれにあわせてマウントに溝を作り、きっちりその段差に固定する。おお、ぴったりカメラは固定された。こいつはうまくいった。嬉しくて記念撮影。

Dsc00864  さて次はソフトである。motionなどのライブカメラで動かすには、汎用的なディバイスファイルにするしかけが必要である。もとのSAMBAサーバーのOSはV3のWheezyで汎用的なビデオパッケージVideo4Linuxをサポートするカーネルモジュールが入っていない。最初、このサイトの情報でインストールを試みたがうまくいかなかった。

 そこで、OSの取り換えを試みる。最新バージョンのJessieが無印のRaspiで動く保証が得られなかったがだめもとで入れてみた。幸い、何事もなく順調にインストールに成功。めでたく/dev/video0というディバイスファイルが出た。

 これであとはmotionや、jpeg-streamerなどのインストールをすれば定点カメラが完成する。ブログの紙数も増えてきたので、このあたりで報告を一段落しよう。

| | コメント (0) | トラックバック (0)

2016年12月22日 (木)

ジャイロセンサーMPU6050とProcessingで飛行機の3D姿勢表示

 前から少しづつ進めていたプロジェクト、6軸の加速度・ジャイロセンサーMPU6050をESP8266のArduinoで動かして、PCの画面に3Dの画像(飛行機)を表示する開発がやっと一段落した。MPU6050の基板を手で動かすと、PCの飛行機がそれに合わせて動く。Dsc00804

 当研究所の大きな縛り「実用品を開発する」ことなら、MPU6050は本来ならドローンや2足歩行のロボット(まあ、これも実用品ではないが)に使って始めて開発と言えるのだが、そこまでの足慣らしということで始めた。ところがこれが思ったより難航したのである。Ws000011

Processingの3Dライブラリーが動かない(12/3/2016)
 Processingそのものは、すでに前回、単独で動くことを確認している。これからやりたいことは、MPU6050で検索すると必ず出てくる3Dの飛行機やティーポットをPCのProcessingの画面上で動かすことである。

 ところが3Dに必要なProcessingのリソースをダウンロードしようとすると、殆どの日本語サイトが紹介しているダウンロード先のAndrocityというサイトが変わってしまっていて、先に進めない。

 片っ端からウェブサイトを探し回って何とかファイルを見つけ、インストールには成功した。toxiclibというライブラリーも見つかった。しかし、動かしてみるとProcessingの3D出力のドライバーOpenGLでエラーが出る。平面図形は至極順調に動くのだが、OpenGLが以下のメッセージを出してエラーとなる。

Framebuffer error (framebuffer unsupported), rendering will probably not work as expected

 調べてみると、PCのグラフィックドライバーが古いと動かないようだ。このライブラリ(OpenGL)だけでなく他の3Dライブラリでもトラブっているようで、エラーメッセージをキーにすると海外のサイトが多数ヒットする。

Ws000009

 回避する方法は、残念ながら紹介されていない。基本的には新しいビデオカードに替えるか、メーカーがビデオドライバーを更新してくれるのを待つしかないようだ。しかし後者はこちらの場合望み薄である。

 現用のPCのビデオインターフェースが古すぎる。マザーに内蔵のビデオインターフェースはIntelのG33で、恐らく7年は経っている。最新のIntel汎用ドライバーに更新しようとしても、メッセージは「これが最新です」と出て、状況は変わらない。

 うーむ、買ってくるしかないか。前のPCで使っていた古いRADEONのボードは部品庫に残っているが、これとてかなり古く、動く保証はない。変なところで頓挫してしまった。余り意地になるのはやめようと思うが、どうも気になって他のことに移る気分にならない。

 本来の工作の方向ではない(単なるMPU6050の動作テスト)ので、潔く他のことをすれば良いと思うのだが、へそ曲がりなもので、出来ないとなると余計悔しくて気持ちが納まらない。因果な性分である。

ビデオボードを買ってきて解決(12/6/2016)
 色々迷ったが、次にやることが見つからないので、くだらない話だけれどビデオカードを更新することに決めた。ということで、買うことは決めたのだが、いざ具体的には何を買えばよいのか見当がつかない。PC自作から遠ざかって15年は経っている。

 ネットで久しぶりに「ビデオカード」をキーワードに検索をかけてみた。おお、出てくるわ出てくるわ。この世界はまだまだ活況のようだ。そのうち全体を俯瞰できる親切なサイトを見つけた。なにー、10万円を超すビデオカードが沢山市販されている。中には30万を越すボードもある。これ業務用ではないよね。ハイエンドPCゲーマー御用達のボードのようだ。

 こんな高いボードにはもとより縁はない。お値段は¥5000以下(さっきのサイトのランクでは5段階の下から2番目)、冷却ファンのない静かなボードが条件である。仕事の帰り、秋葉原に寄り、この前PC電源を買い替えたお馴染みのTwoTopで、適当なボードを物色する。ASUSのGeforce GT710を選んだ。¥4200余り。

 家に帰って久しぶりのPC拡張ボードの工作である。ビデオインターフェースのコネクター規格PCI Expressがえらく複雑になっていて悩ましい。バージョンが1から3まである上、2には枝番としてx1だのx16だのに分かれている。買ったきたビデオカード(2.0 x8)が現用のマザーに入るか心配だ。

 スロットに差してみると、何か接続されないピンの空きが多い。不安がよぎったが、とりあえずはきっちり入ったので試しに動かしてみた。BIOSは今のところ何もいじらない。新しいカードの方にビデオケーブルのコネクターをつけて電源を入れてみる。

 良かった。BIOS画面が映った。ビデオカードを自動認識してこちらを使うようだ。ドライバーを入れていないので、MicroSoftの汎用ドライバーで画像は荒いが、Win10までちゃんと動く。付属のDVDからビデオドライバーをインストールすると、正規の1920ドットの画面になった。やれやれ。

 さあ、目的のOpenGLのProcessingはどうだ。おおう、あっさり飛行機が出た。Arduinoとつないでいないので、飛行機はまだ正面を向いたまま動かないが、3Dの部分は問題なく動いているようだ。

 ビデオカードの効果は他にもあった。これまでMicroSoftの無料ゲームの中に、画像の乱れがあったり、やけに動きが遅かったりしたゲームがあったのだが、これらの不具合がすべて解消された。まあ、お金をかけたことは無駄ではなかった。

Processingで画像がグリグリ動く(12/7/2016)
 3Dが出たので、また暫くProcessingで遊ぶ。それこそティーポットやヨット、シリンダーなどの3D図形がマウスの操作で自由に動く。素晴らしい。

 すごく親切なProcessingのガイドがウェブで見つかった。それを夢中になって試す。いやいや、昔に比べると、良くインタプリターだけでこれだけ滑らかな動きが出来るものだと感心する。

 このサイトにも例の3D飛行機(MPUTeapot)の丁寧なインストール方法の紹介がある。この通り忠実に手順を踏めば簡単に動きそうだが、どうもこの前のスマホの無線操縦のように動いた後、何も出来なくなるような気がしてきた。

 もう少し基本からProcessingとArduinoを勉強した方が、のちのち良いような気がする。少し回り道でも、ひとつづつ段階を経て動作を確認していくことにした。ArduinoでMPU6050をドライブし、そのシリアル出力をPCのProcessingで受けて、画像ルーチンの入力にする過程を確認していこう。

 だいたい、MPU6050の6軸のセンサー値の意味も完全に理解しているわけではない。加速度センサーだけで測れるのは、飛行機で言えば、縦揺れ(ピッチング)と横揺れ(ローリング)だけで、縦軸(Z軸)の回転(ヨーイング)は、角速度センサー(ジャイロセンサー)で値を積分しないと測れないはずなのだが確証はない。ちょっとソースを覗いてみたけれど、全く手も足もでなかった。

 独自開発しようと意気込んでいたが簡単に白旗をあげた。このJeff Rowberg氏の開発したMPU6050関係のライブラリーは膨大で、MPU6050.cppなどは3000ステップを超える。I2Cのドライバーだけでも1000ステップ以上で、これを無償で公開されているのには頭が下がる。

ProcessingとArduinoの連携に目鼻がついた(12/10/2016)
 それでも、単にソースをコピーしてきて動かすことだけは避けたい。理由は、コピペだけでは身につかないProcessingとArduinoの技術を少しでも習得しておきたいからである。センサー、MPU6050のI2Cはライブラリを拝借するが、3Dの画像を出す部分は、せめて少しでも理屈を知っておきたい。

 作業を以下のように細かく分割して、ひとつづつ確認していくことにした。

(1)    Processingの学習  例のこのサイトがとても親切に教えてくれる。
(2)    Arduino スケッチとライブラリ構築の復習 これは上記のサイトのここが詳しい。 
(3)    Processingシリアル入出力のテスト
(4)    ProcessingとArduinoのシリアル連携 ここを参考にさせてもらった     
(5)    ArduinoとMPU6050の接続テスト
(6)    ProcessingとArduinoのハンドシェイクプロトコルの決定
(7)    ProcessingとArduinoの接続テスト
(8)    Processingの画像出力のスケッチ作成
(9)    MPU6050とProcessingのテスト

 現在は、(4)まで済んでいる。(5)が課題だ。ArduinoのシリアルコンソールにMPU6050の数値を出すスケッチはたくさんのサイトで紹介されている。これを試すことにする。

ステップ(5)MPU6050の接続テストまですんだ(12/12/2016)
 簡単に通過するはずだったのだが、意外に手間取った。原因はESP8266のI2Cの接続ピンの勘違いである。以前使ったピンアサインのメモに基づいて配線したのだが、MPU6050を認めないメッセージが出る。 

コピペさせてもらったソースに間違いはない(はずだ)。動かないとなると、途端に何も出来なくなるのがArduinoである。ピンの接触不良や、AD0ピンのプルダウンなどを疑うが問題はない。オシロなどを出して波形を見るまでもなく、何か基本的な間違いだと思うが、最初は以前自分で書いたメモを信じていたので途方に暮れた。

 気を取り直してESP8266の正式なピンアサインをネットで確かめる。あっあっあー、SDAピンが違うぞ。なぜだ。どうして間違ったところにメモしたのだ。正しい方にピンを差しなおしテストする。よーし、いいぞ。それらしい値が出てきた。

ステップ(6)(7)は既製のスケッチを流用(12/14/2016)
 次はArduinoのMPU6050のメッセージがProcessingのテキスト画面に出ることを確認する。これは問題なく動いた。ただし、Processingのテキスト画面はスクロールしないので単に、忙しく数字が変化するだけで、見映えはしない。

Procesingserial  Processingのテキスト画面をスクロールするように直したい気持ちが激しく盛り上がったのだが、やっとのことで自制する。ここで脱線するとまた戻れなくなる。我慢、我慢である。

 とりあえず、これでESP8266につないだMPU6050のデータは正しく、Processingに到着した。残るは最後の関門、画像表示である。既成のスケッチのソースを見て調べるが、そう難しいハンドシェイクはしていない。単にメッセージの頭に特定のキャラクター($)を入れて、それをトリガーに後続データを配分しているだけのようだ。

 難しいのはやはりセンサー値の加工である。色々ネットで調べる。クオータニオン(四元数、しげんすうと読む)という3Dでは常識らしい用語を発見して珍しく興奮し、暫く勉強する。いやあ、奥が深い。 

 これからMPU6050から出てきた数値を気安く加工しようと思っていたが、一筋縄で触れるものではなさそうだ。ここは素直に、既成のスケッチを使わせて貰うことにしよう。まずは動かすことが先決だ。

ステップ(8)(9)はMPUTeapot2のプロジェクトをそのまま使う(12/15/2016)
 人さまの動いたソースを借用するのだから、すんなり動くのかと思っていたが、そうは問屋が卸さなかった。参考にしたサイトは、すでに紹介したここである。

 このサイトは、以前、懸命に探し回ったリソースがちゃんとダウンロードできるようになっており、ここだけですべてが動く(実は大きな落とし穴があったのだが)。順調にMPUTeapot2のライブラリを入れてArduinoとProcessingを動かした。しかし、エラーメッセージが出るだけで機体は動かない。

 例のArduinoの弊害である。 スケッチソースは長大で、ちょっと目検したくらいでは何がおかしいのか見当はつかない。手も足も出ない状態だ。まあ、救いは、散々連携テストをしてきたので、ハードなどの問題はなく、動かない原因は現在入れたアプリケーションソフト(のはずだ)だ。

 ただ、エラーメッセージが奇妙である。つながったことを示すステートメントは出るが、何か(割り込み)を待つというステートメントのあと、タイムアウトが起きてリセットされ、これが延々と続く。

Initializing I2C devices...
Testing device connections...
MPU6050 connection successful

 

Send any character to begin DMP programming and demo:
Initializing DMP...
Enabling DMP...
Enabling interrupt detection (Arduino external interrupt 0)...
DMP ready! Waiting for first interrupt...

 

Soft WDT reset  (以下繰り返し)

 何らかの外部割込みをArduinoが待っているような感じだ。しかし、参考にしたサイトの結線図にはMPU6050の割り込みピンの接続はない。他のサイトを見るとMPU6050のINTピンが結線されている配線図や、動画が見受けられる。

 うーむ、どっちなんだろう。Arduino UNOでは割り込みピン#0に繋ぐという説明があるが、ESP8266には外部割込みピン#0はない(GPIO#0はあるが、これは制御用に使っている)。つまり繋ぐところが見当たらない。 Dsc00802

 こうなったら本当にMPU6050が割り込み付きで動いているのか(ソフトで設定できるようだ)、確かめるのが先決だ。もし、割り込みモードで動いているのなら、先の配線図が誤りということになる。

 オシロを持ち出して、MPU6050のINTピンを観測した。ピンポーン!当たりだった。I2Cのメッセージが出される前後に派手に割り込み信号が上がっているのを確認した。そうか、やはり必要なのだ。しかし、割り込み入力はESP8266のどこに入れたら良いのだ?

 恐る恐るArduinoのスケッチソースを調べ始める。良かった。見つかった。setup()ルーチンの中に、割り込みピンの定義をしているらしい以下のステートメントを発見した。

attachInterrupt(0, dmpDataReady, RISING);
mpuIntStatus = mpu.getIntStatus();

ふーむ、ここが0になっている。ESP8266のピン0は、ファーム書き込みの制御ピンのためプルアップされたままで入力には使えない。

やっとのことで飛行機が動いた(12/16/2016)

 ここを適当なピンに定義し直せば良いのはないか。希望の光が見えてきた。こいつをESP8266の適当なピンにアサインする。とりあえず2にしてみる。あせる手でジャンパーをMPU6050のINTピンの間に飛ばし、再ビルドする。

Ws000010_2  動く予感がする。まず、Processingを動かす。Arduinoはまだ電源を入れない。続いてArduino(ESP8266)の電源を入れる。これまではタイムアウトのメッセージが出るだけだったがどうだ。おおー、コンソールに字化けしたメッセージが出始めた。しかし依然として飛行機は動かない。

 割り込みジャンパーコードを抜き差ししているうち、突然メッセージが規則的なデータ列になった。同時に飛行機がズルッと動いた。何かのタイミングでMPU6050が暴走するようだ。ESP8266を立ち上げてから割り込みを有効にすると暴走しないことが多い。

Dsc00807  やった、やった。MPU6050を載せたミニブレッドボードを動かすと飛行機が姿勢を変える。反応はとても早い。やれやれビデオボードまで新調してやっとのことで、画像を動かすことに成功した。何度も電源を入れ直し動作を確認する。ささやかな達成感で胸が膨らむ。

 最後が少し手間取ったが(サイトの記述を信用しすぎた)、動いてしまえば何の問題もない。冷静になって考えれば、実にくだらない作業なのだが、仮説をたてて、ひとつづつ問題を解消し、それが思い通りになったときは、どんな小さなことでも嬉しい。これが電子工作の醍醐味である。

| | コメント (2) | トラックバック (0)

2016年11月28日 (月)

行き当たりばったりの電子工作(2)

 WiFiモジュールESP8266とスマホを組み合わせた玩具のクローラーの無線操縦は、ウェブのソースをそっくり頂戴して、すんなり動いた。しかし、Arduinoによる開発なので経験値はさっぱり上がらない。達成感にも欠けるし、先に進もうという意欲がどうも盛り上がらない。

 そうこうするうちに、前回のブログからもう一か月が経ってしまった。これまでの経験で、記事の間隔をこれ以上開けると内容をまとめるのに苦労する。で、まとまりに欠けるが、これまで書き貯めたメモを元にこれまでの活動をご報告する。相変わらずの行き当たりばったりでごめんなさい。

AtmelStudio7がすんなり入った(10/21/2016)
 ESP8266周りの制作が一段落したので、このあいだうまく行かなかったWin10でのAtmelStudio7のインストールを再度試みてみた。AtmelStudioの中核アプリVisualStudioは好きではないが、一旦動けばデバッグ機能が豊富なので動くことに越したことはない(まあ、AVRあたりのソース量ぐらいではあまりメリットはないが)。

 新しくインストーラーをダウンロードし直し、インストールをやってみた。これが何ということか、全く問題なくインストールが終了したのである。時間もそう長くかからなかった。理由はよくわからない。狐につままれた心境である。Ws000000 確かにWin10は1週間ほど前、更新が入った(不本意ながら)。AtmelStudioのインストーラーのバージョンも以前の、7.0-1006から7.0-1188に上がっている。しかし、どうも、これだけの理由だけとも思えない。動いたのは良いけれどあまり気分は良くない。

 実際にプロジェクトを入れて試してみた。正常に動いた。ただ、以前のAVRStudioのプロジェクトは認めてくれない。古いバージョンのImport/exportができるというのでやってみた。Importそのものは正常に終わったが、ビルドしてみるとmakefileでエラーになる。

 以前のAtmelStudio6のときも、こんなことがあったような記憶がある。ライブラリーのディレクトリ位置が、makefileの中身とずれているようだ。こういう統合環境のデバッグは意外に厄介である。ウェブ上で解決策を探るが、有力な情報は得られなかった。

 当面、includeするソースをカレントルート(main.cがあるところ)に置いておけば、正常にコンパイルできるはずなので、とりあえずそのままにしておくことにする。現在、AVRでの開発プロジェクトはない。

あっけなくDRV8835は稼働。こんな簡単で良いのか(10/29/2016)
 最近、秋月電子では、DRV8835というモータードライバーICが売られている。こいつはひとつだけで、2つのモーターの正逆転を個別に制御でき、容量も一回路あたり1.4Aまで流せる。以前試したBD6211あたりより容量が大きい。しかも今、作っているMP4212などよりはるかに安い(MP4212はひとつだけで¥380、DRV8835は2つ動かせて¥300)。

Dsc00767 モード0、1(2つのピンの1が正転、逆転になるか、一つのピンがON/OFF、もうひとつのピンが正転と逆転)の動作テストもする。これも全く問題なく動いた。

 このあいだ、秋月でMP4212のドライバーのフォトカプラーを買うときに、矛盾するけれどこいつも買ってしまったことは、前の記事ですでに紹介した。ただ、買っただけでテストはしていない。このままにしておくと部品箱の肥やしになってしまいそうなので、動かしておくことにした。

 動かすと言っても、ブレッドボードに刺して、ジャンパーコードで電池とモーターを接続するだけである。部品はいらない。とりあえずシングルモーターでテストする。何の問題もなくモーターは正転逆転した。少々回しっぱなしにしても、クローラーに使ったFA130くらいのモーターなら、チップはちょっと暖かくなる程度で楽勝である。

 MP4212で苦労した配線や、ダンパー抵抗も必要ない。あまりにも簡単に動きすぎて、気が抜ける。基板面積は恐らく1/10くらいだろう。Hブリッジを知らなくても、これくらいのモーターなら何も考える必要がない時代になったのだ。

 今まで秋月C基板の1/4近くを占めて作ったMP4212のモーター基板はいったい何だったのか。まあこれはもっと大きなモーター(数A)に使えるから良いものの、何かやるせなさを感じる。Arduinoと同じ展開だ。モーターの経験値は上がらないし、一旦動かなくなれば対処不能だ。

ジャイロセンサーMPU6050をどう料理するか(11/6/2016)
 スマホなどの普及で、安価なペリフェラルディバイスが大量に市場に出回っている。以前なら考えられない高性能なセンサーが破格の値段で買える時代になった。

 このMPU6050もそのひとつだ。4、5年前なら3軸の加速度センサーだけで数千円していたのが、こいつは、加速度、ジャイロあわせて6軸のセンサーなのに¥1000以下で手に入る。これもアマゾンで、ウェブの話題につられて、使うあてもないのにポチッとして買ってしまった。

 次のプロジェクトは、この部品箱の肥やしになっているジャイロセンサーMPU6050をESP8266に絡ませることにしよう。ウェブサイトには沢山の応用例を見ることが出来る。これはArduinoのおかげである。

 どうもI2Cで簡単に動くようだ。ただ、動かすだけでは面白くない。これまでに何度も懲りている。「入れました。動きました」で終わりたくない。もう少し、手の込んだことをやっておきたい。

 とはいえ、倒立一輪車や、ドローンなどの姿勢制御まで一気に進むのは簡単ではない。最近のスマホなどの動画をブレなく撮影できる手持ちジンバルなども食指をそそられるが、これもすぐに思いついて作れるレベルでもない。

 色々迷ったが、とにかくMPU6050を動かすことを当面の目的とし、結果を少し凝ることにした。単にコンソールに数字を出すだけでなく、PC上でポットや飛行機などの姿勢が変わるシステムを作りたい。Arduinoと連携して、PC上に動画を出すProcessingというアプリがあるらしい。

Processingのインストールなどで参考にしたサイトは、
   http://kimizuka.hatenablog.com/entry/2015/05/01/000000
である。Processingそのものの解説は以下が詳しい。
    http://robo.mydns.jp/Lecture/index.php?Processing

 しかし、構想ばかりが膨らんで、なかなか具体的な計画にならない。メモに構想(妄想)を書き散らすだけの日々が過ぎていく。

本日ESP8266で全くの徒労。最近こういうのが多いな(11/10/2015)

 このところ雑用で忙しかったが、久しぶりにまとまった時間が出来たので、そろそろ次のプロジェクトのハードのため、一つ残っていた予備のESP8266をピッチ変換基板に実装する工作をやった。

 これまでの2つのESP8266には何らかのファームが入っており、これをつぶすのに抵抗があったのと、何か手を動かしていないと落ち着かない性分になってしまったこともある。しかし、これが2日間の泥沼の作業になるとは予想してもいなかった。

 ピッチ変換基板は、Aitendo製で、milピッチのレイアウトがこれまでの一列づつの両側ではなく下に2段にまとまった基板だ。以前、この2種類を2つづつ4枚買ってあった。リセットSWやレギュレーターを配線したブレークアウト基板を共通にしたいため、ブレークアウト基板の方に2段目のソケットを追加して動くようにした。 Dsc00769

 よく考えれば、こんなことはあり得ない(ピンアサインが両側一列と下側2段と同じ)のだが、何を勘違いしたか、両側1列の片側をそっくり寄せてレイアウトして実装してしまったのである。これがまた情けないことに、すべての半田付けを終わって動作テストしたときに始めて気が付いた。

 テスターで調べたら、全くピンアサインが違っている。極く当たり前の話なのだが、これを今頃になって気が付くおのれの愚かさに暫し呆然となる。9本の配線のハンダ付け18か所が全く無駄になった。お馬鹿にもほどがある。

 まあ、ここで自暴自棄にならないところが、自分で自分を褒めてやりたいところだ(と必死に自分をかばう)。叫びたい自分を押し殺し、低温ハンダを持ち出して、ブレークアウト基板に増設したピンソケットをとりはずした。さらに普通のハンダを盛って、ハンダ吸い取り線で丁寧に掃除する。

Dsc00766 ここでさらに失敗をしたら破滅的なことになるので、慎重に作業を進める。やっと前の状態に戻った。このままでは腹の虫が収まらない。愚かな自分を慰めるために汎用基板の切片を取り出してピッチ変換基板のさらに変換基板を作り始めた。

 下段2段のピンアサインは、調べたら両側一列とは全く異なり、通常のピン順序を無視した無茶苦茶な配列で、どうもアートワークを簡単にするためらしい。ということで変換基板の配線はむしろ簡単に済んだ。ちょっと背が高くなったが、問題になるレベルではない。

Dsc00763 ほぼ2日かけて、新しいピッチ変換基板の変換基板が完成した。恐る恐るテストする。最初の誤接続でのESP8266の破損を心配したが問題なく動いた。一安心である。実にくだらない作業だったけれど、何とか事態を収拾した。不思議なことに、こんな後ろ向きの仕事なのに満足感がある。

Processing単体では問題なく動く(11/14/2016)
 MPU6050をテストするのにビジュアルなベンチを用意したいということで始まったProcessingだったが、インストールのあと、本題を忘れて、もっぱらProcessingの画像表示を楽しんでいる。

 当初、PCで動くProcessingは、外見がArduino IDEに似ているので、何かと思ったが、動かしてみれば単なるJAVAのインタープリターで、画像などを簡単に出せるものだということがわかった。Arduinoそのものとは直接の関係はない。

 「Processing 入門」などのキーワードで調べると、沢山のウェブサイトが見つかる。適当なものを選んで演習する。これは楽だ。実にあっけなくPC上で図形を加工しながら動画にできる。また年寄りの繰り言になるが、あのC言語でグラフィックLCDに円を描く関数を開発していたのは何だったのかという気分になる。

 Arduinoとの連携は、単に、Arduinoのデバッグ用のシリアルインターフェースを利用しているだけで、大層なしかけがあるわけではない(と思う)。 要するに、どちらかのトリガーで、あらかじめ決めたデータをArduinoが送り、それによってProcessingの画像が動くと考えれば良い。

 理屈がわかってしまうと、途端に先に進む意欲が低下する悪い癖が出て、開発のテンポが落ちる。適当な応用例がサイトで見つからないのだ。みんな沢山のライブラリーが必要なようで、やってみる気がなかなか起こらない(気位ばかりは高いが実はへたれである)。

筑波山に登ってきた(11/17/2016)
 そこで、電子工作以外の話題をひとつ。所長は関西の出身で、東京に出てきた京都の高校の同級生がここ15年近く健脚自慢のメンバーで定期的に山や街歩きをしている。今回は、筑波山に登るというので仲間に加えてもらった。Dsc00690

 ちょうど紅葉のシーズンなのでそれも楽しみだが、筑波山あたりは関西から東京に出てきた者にとっては全く盲点と言っていいくらい知らないところで、殆ど行く機会がない。しかもつくばエキスプレスという新しい鉄道に乗るのもはじめての経験で、何かわくわくする(所長は元鉄道おたくである)。Dsc00706 Dsc00732

 筑波山に登るといっても、ロープウエイとケーブルカーが整備されており、ほとんど登る行程なしに、男体山、女体山という2つの峰に行くことが出来る。それでも一週間も前に古い軽登山靴を物置から出して磨く。家族から、「まるで小学生の遠足ね」と冷やかされる。

Dsc00735 Dsc00746  朝8時に秋葉原に出る。ウイークデイなので長いエスカレーターは上りの通勤客の大群にはばまれ、地下の深いホームにたどりつくだけで一苦労である。終点のつくば駅からのバスは平日にもかかわらず乗客で満員だった。驚いたことに外国人のパーティが1/3近くおりバスの車内は外国語で溢れていた(彼らは大声ではしゃぐ)。 

Dsc00750  寒いとおどかされていたが、好天に恵まれて絶好の山日和である。男体山は、女体山より標高は7mも低いのに、山道は岩だらけの急坂で、かなり息が上がったが、女体山の方はアプローチが長いので簡単に頂上に出た。

 女体山からは霞ケ浦が一望できる。ただ、もやで残念ながら富士山は見ることはできなかった。それでも、帰りのロープウェイからの極彩色の紅葉は素晴らしかった。

PC連動ACコンセント自作に脱線する(11/21/2016)
 さらに、くだらない寄り道をしている。当研究所のメインPCには、PC電源連動タップが装備されており、メインの電源の入り切りで、周辺の機器(ディスプレイ、スキャナー、オーディオなど)も連動して作動するようになっているのだが、このタップの具合が最近おかしくなってきた。

 足元に置いてあるタップが足で動かされると、偶(たま)にだが、PC本体の電源が瞬断し、PCがリセットしてしまう。作動中のPCの突然の電源断は、Win10では少し丈夫になったようだが(セーフティスタートを強制されない)、この前の電源故障のときに懲りている。何とかしないといけない。

 この連動タップは10年以上経っているので買い替えても良いのだが、電子工作の経験を積んで来ると工作心が刺激されて、ただ買い替えるだけでは芸のない話である。で、脱線して、この連動コンセントを作り始めた。昔のPCならいざ知らず、今はUSB端子があるのでわざわざPC電源から5Vを引き出す必要もない。USBから5Vを出しリレーひとつで出来上がるはずだ。

Dsc00755

 ACインレット、アウトレットなどの工作だけである。プリンター電源のLAN制御のとき使った15Aを入り切りできるメカニカルリレーの予備があるが、せっかくだからもうひとつのAC制御、SSR(Solid State Relay シャープS108T02)を使ってみることにした。

Dsc00761  何の電子工作らしいところはない。単にケースの工作だけのようなものだけど久しぶりのコッピングソーやボール盤(んな大げさのものでなく単なるドリルスタンド)を持ち出しての工作は楽しかった。配線は、単に入力にLEDの制限抵抗を入れ、インレットとアウトレットのACの太い配線をはんだ付けしただけである。

 それでも慎重を期して、10項目に上る作業項目をメモに書き、赤ペンで消していく。SSRを普通のリレーと勘違いして、直接5Vを端子にかけ、ひとつ¥280もするSSRをお釈迦にしたことは秘密である。Dsc00759

 出来合いのヒートシンクをつけ、接合部分には本式に伝熱グリスを塗り、USBソケットを補強し(ソケット部は特に必要)、あれこれ3つ以上買ったケースの中から作りやすいケースを選び、半日かけてSSRによるPC連動スイッチが完成した。

 勇躍テストに入る。ACを扱うのでバラックで事前に動作テストは済んでいるが、PCで動かすのは初めてである。動いた! 念のためオシロでUSBが立ち上がる波形を見る。PCのUSB電源の立ち上がりは、起動スイッチと同時にUSB側も立ち上がるようで、パルス状ではなく徐々に(立ち上がり6ms程度)で5Vになるようだ(電源断も同じカーブ)。

 PCも無事立ち上がり、shutdownで電源も切れる...ん、切れない。えー、どうして?調べた結果、このPCのマザーは、待機時にWake Up LANなどのためにUSBがOFFにならないUSBコネクター部があるようで、USBプラグを待機時にOFFになるところを選んでOKとなった(マザーボード上のピンでOFFにすることもできるようだ)。

 とりあえず、工作の目的は果たした。少々足で電源をいじっても瞬断の心配はなくなった。きりの良い所なので、報告をここらで一段落する。

| | コメント (2) | トラックバック (0)

2016年10月20日 (木)

ESP8266とスマホでクローラーの無線操縦をためす

 メインPCの電源故障でWindows10をこわしてしまい、再構築したのだが有力なアプリが全滅してしまった。電子工作どころではない。ブログを書き込むだけの最小限のソフトを再インストールして、前回の記事は何とかアップしたが、その後も悪戦苦闘が続いた。

ロジックアナライザーのドライバーが入らない(9/15/2016)
 この間やっとWindows7からWindows10に切り替えた直後にこの事件である。ワードやエクセルは幸いインストールCDが手元にあったので簡単に戻り、ブログの記事のアップや会社の決算などは無事終わったが、電子工作の開発環境のアプリなどは、ショートカットが残っているだけで本体は殆ど影も形もない無残なありさまだ。

 アプリを使う機会のたび、少しづつ修復作業を続けた。大方のソフトは生き返ってきたが、この前も、てこずったZEROPLUSのロジアナLAP-C16128がうまく入らない。みんなWin10で苦労しているようだ。

 それでも最近は販売元が、win10をサポートする最新版を出しているので大丈夫だという情報を見つけた。しかし何度やっても、その公式インストーラーは変なエラーメッセージではねられる。例のエラーメッセージを直接Googleに喰わせる方式で探索すると、ウェブからは解決法が沢山でてきた。しかしどれを試してもうまくいかない。 Ws000008 何か汎用的な相性問題のようで、特定(ZEROPLUS)のアプリのウェブの記事は少ない。いくつかあるZEROPLUSの記事はみんなWin8時代のものばかりである。最初にWin10に入れる時も苦労している。このときは、何回か失敗したあと、いつのまにか動いた。どうも悪い予感がする。

悪戦苦闘。遂にLAP-C16128のドライバーインストール成功(9/20/2016)
 この1週間、喉に小骨が刺さったように気になっていた、ドライバーのインストールが、どういうはずみかうまく入った。何が原因だったのかはわからない。色々な方法を試すうち、偶然のようにうまく動いた。どうにも気分が悪い。

 製造元のWin10で動くというインストーラーでエラーが出る。このインストーラーはドライバーとアプリケーションを別々にインストールするようになっている。まずドライバーをインストールすると、途中で以下のメッセージが出てインストールが中断される。Win10のディバイスマネージャーのZEROPLUSのアイコンの下のLAP-Cドライバーには故障のマーク(!)がついたままだ。

 アプリケーションは最初の1回はなぜか問題なく入ったが、環境を元にもどすため、一度アンインストールして再度入れようとしたらその後は全く入らなくなった。エラーメッセージは、ドライバーもアプリも同じで以下のようなものである。
  1608: Unable to create InstallDriver instance.
  Return code -2147221021

このエラーメッセージを直接、Googleに放り込んで見ると、海外を含めてさまざまな解決法が出てくる。インストール時の共通のエラーのようで、沢山のソフトでの発生事例が報告されているようだ。どうしてこういうこと起きるのかという説明が不足しているので手探りである。

原因が何かがわからない。何かの拍子にwindowsのインストーラー関係のリンクがおかしくなるのだそうだ。こちらはWindows10を再インストールしているので、このあたりは大いに可能性がある。

 いくつかのサイトをまわるうち、以下の方法(Idriver.exeを独自に実行してから、インストーラーを動かす)をやると、少なくとも上記エラーは出ないで先に進むことがわかった。しかし、ドライバーは正常にインストールされない。

c:\Program Files\Common Files\InstallShield\Driver\1150\Intel 32>idriver

 レジストリーを綺麗にするユーティリティ(CCleaner)を見つけたので、これで不審なレジストリーを消去するが変わらない。仕事場のノートPCで試しにインストールしたら、何の問題もなくドライバーが入った。やはり、この自宅のPCの固有の問題であることは明らかだ。

 自宅にもどり再度挑戦する。こういうのは気になったら止められない性分である。CCleanerのメニューの中に、レジストリーだけでなく不要なプログラムを消す機能がある。これを見ていると、消したはずのLAP-Cのドライバーが存在していた。これは怪しい。とりあえず、それを消した。

 これが良かったのかもしれない。インストーラー始動前に、必ずこれ(Idriver.exeの実行)をやるようにし、さらに管理者権限で必ず、setup.exeを始動するようにした。何度目かのトライで何と、インストーラーが順調に動き、ディバイスマネージャーのアイコンから!マークが消えた!

 LAP-Cが問題なく動いた。ふー、やれやれ。決め手がなんであったのか確証がないのが心残りだが、とにかくこれで他のことに移れる。それにしてもOSの変更は大型機の時代からユーザーにとっては実に厄介なイベントである。

 昔は、性能が良くて安価な新しいハード機器を動かすために、渋々替えてきた(これはメーカーの戦略)。バージョンアップはそれなりにユーザーに利益をもたらしたのだが、今や、バージョンアップは、ユーザーにとって何の役にも立たない作業になり果てている。ベンダー、メーカーの都合に付き合わされるのは、もうそろそろ止めて貰いたい。

今度はAtmelStudioが入らない。これは少し静観(9/24/2016)

 次のAVRの開発環境、AtmelStudioは、結局、諦めた。これがなければAVRを動かせないわけではない。あの愚鈍な象のように重いVisual Studioは正直言って、あまり愉快な環境ではない。

 当研究所は、AtmelStudioで使っているのはエディターとビルドだけで、書き込みは、ChaNさん謹製の超軽いAVRSPである。コマンドプロンプトに一旦入れておけば、コマンドのリピートキー一発で何度でもビルドを繰り返せる。

 それでも一応は入れておこうと、最新版のAtmelStudioをダウンロードし、インストールを始めた。延々とVisualStudioをインストールし始める。そのうちインストーラーがハングアップしたようで、一時間近くほっておいても終わらなくなった。リソースマネージャーで見ると、どこかでループしていることは明らかだ。

 サイトの情報にも、いくつかハングアップの事例が報告されている。抜本的な解決策は見つかっていないようだ。まあ、AtmelStudioは必須の環境ではない。なければAVRtool Chainをインストールして裸でmakeしてもかまわない。これは少し静観することにする。

 そのうちWindows10に入っている無料のゲームソフトが思いのほか面白く、PCを立ち上げても、それに時間をとられて、まともなことをやる気力が盛り上がらなくなった。ゲームにはまって気が付いたら深夜という繰り返しの毎日で、電子工作そのものの動きが停滞してしまった。

久しぶりに秋葉原に行きモータードライバーなどを調達(9/30/2016)
 それでも、Win10のインストール騒ぎの最中、実は少しづつ続けていたハード工作がある。8月に面白がって買ったアームクローラーの工作である。モータードライバーをMP4212で作っていた。ブレッドボードでのテストでは問題なく動いた。

 クローラーにESP8266基板と、MP4212を2つ載せたモータドライバー基板を2階建てで取り付けるつもりで準備を進める。ブレッドボードから汎用基板に部品を移して配線する。久しぶりのはんだ付けを楽しむ。

Pa207520 クローラーについているモーター程度(マブチのFA-130)でMP4212を使うのは少し勿体ないが、以前、1Aまで流せるというBD6211というモータードライバーをこのモーターに使っておかしくしてしまったことがある。モーターが止まるほどの過負荷をかけると、こんな小さいモーターでも1A以上が流れこわれてしまったらしい。用心に越したことはない。

 このサイトの情報を参考に、最終的には、ESP8266とスマホでラジコン化するのが当面の目的だ。片側のMP4212の実装が済んだので、実際にモーターの電源を利用してHブリッジの動作を確認する。電源は、ニッケル水素電池2つか、800mAhのリチウム電池である。

 ところがMP4212のモータードライバーの動きがどうもおかしい。4Vのリチウム電池では何か瞬間的に貫通電流が流れるらしく、瞬断してうまく回らない(動くときもある)。回路的に悪いのか。あのフォトカプラーを直接論理回路化した回路が悪いのか。

 FETの動作原理を復習する。どうも、直接、ロジックだけであのHブリッジを動かすのは無理な感じがしてきた。あのままでは、FETのゲートに電荷が溜り誤動作するような。要するに単なるスイッチではドライブが出来ない感じがする。

 念のため、オリジナルが正しく動くどうか、フォトカプラー(TLP250)を試してみたくなった。久しぶりに秋葉原の秋月にでかける。行ったついでに、1.4Aまで動くというデュアルモータードライバーモジュールDRV8835(¥300)を買った。これはひとつで2つのモーターを動かせる。さっきのフォトカプラーの回路ならフォトカプラーだけで4つ(¥150X4=¥600)もいるところでこちらは断然お得だ。

 しかし、MP4212のモータードライバーの片側も実装し、電源の接続ピンを新しくしたら、Hブリッジは全くトラブルなく快調に動いた。MP4212モータードライバーの不可思議な動きは、どうもピンヘッダーの接触不良の疑いが濃厚だ。今、別個にテストしているが何の問題もない。

ESP8266の復習を始める。フラッシュファイルシステムも戻った(10/4/2016)    
 ESP8266をおさらいする。まずは、棚からとりだしたESP8266モジュールの埃をはらい、動作の確認をする。これまでやった実験(フラッシュファイルシステム、RTC、ATコマンドファームの書き戻しなど)を次々に追試した。

 フラッシュファイルシステムが動かなかったが、これはATコマンドモードに戻したとき、ファイル本体とディレクトリのリンクが切れてしまうらしく、フラッシュファイルをもう一度書き込んだらOKになった。こうしたリハビリでESP8266周りの視界が広がり、最終目的(スマホでラジコン)開発の体制が整ってきた。Dsc00584 最終目的は、ESP8266はソフトAPモードにして、peer to peerでスマホとつなぎ、ラジコン化することだ。このウェブ記事のソースをそのまま借用することにしている。このスケッチのスマホのボタンで、クローラーの前後進、左右移動が、ボタンのタップで出来るはずだ。

 まずは、ATコマンドでソフトAPモードにする。これは問題ない。簡単にスマホにサイト名が出た。勢いに乗って参考サイトのコマンドを入れて、スマホと接続。ESP8266のコンソールから接続を知らせるメッセージが出た。しかし、このあとのHTMLシーケンスはないので何もできない。これはここまで。

ESP8266とスマホでクローラーの無線操縦ができた(10/13/2016)
 人様のソフトをそっくりいただいて、ESP8266をAPモードにし、スマホとpeer to peerで結んだリモコンで、めでたく、このあいだ作ったアームクローラーが動いた。スマホのタップによる動作指示は、やはり少し遅れるので本格的な操縦というより「動きます」というのを確認できる程度と考えて良い。スマホのタッチスクリーンの操作をこれからマスターしていかないと実用にはならない。Dsc00588

 電源は、モーターをニッケル水素の乾電池2つ(2.8V)、ESP8266の方はリチウム電池(3.7V)に独立させた。ESP8266基板に、低ドロップレギュレーター(AMS1117)を実装して3.3Vにしている。

 このニッケル水素乾電池のフォルダーをシャーシーに固定するのにえらい時間がかかった。始めはフォルダーをかっこ良くはめ込み止めにしようと、アクリル曲げ機まで動員して、アクリル加工をしようと試みたのだが、意外に難しく(薄いアクリル板は曲げるとそこが極度に弱くなる)、バッテリーフォルダーの素材が瞬間接着剤を受け付けないタイプ(ポリスチロールか)で接着はあきらめた。Dsc00590

 かわりにリアフェンダー(アームクローラーは角度をつけて動くので)に、アクリル小片でバッテリーフォルダーをはさみ、ねじ止めした方法が、簡略だがとても具合よくバッテリーを固定することが出来た。始めから奇をてらわずこうしておけば良かったのだ。

 今回もソフトウエアはAruduinoのスケッチをそっくり拝借したので、全く経験値は上がらなかった。まあ、一旦決めたこと「ESP8266とスマホでラジコン」という命題を何とか挫折なく最後までやりとげたことが救いといえば救いだ。

 次のテーマが問題だ。折角買ったDRV8835はまだ動かせていない。いまだに、あの「ときめき」が電子工作では復活していない。当研究所の活動にはまだまだ暗雲が垂れ込めている。

また新東名を走ってきた(10/16/2016)
 ここで電子工作以外の話題をひとつご報告。車で関西に法事と墓参りのため、帰省した。3年近く前、亡くなった長姉の見舞いに来て以来の長距離ドライブである。例の新東名(第二東名から名を替えたらしい)は以前に比べると車の量が増えたが相変わらず快適だ。Dsc00632

 しかし、トンネルなどの一部は十分な3車線の広さがあるのに、速度超過を心配したのか、路側帯を広くしてわざと2車線にしている。確かに次元を超えたスピードが出るので何とか速度を落とさせようという魂胆なのだろうが、せっかくの機能を台無しにする、いかにも日本の行政らしい「余計なお世話」である。

Dsc00648 お墓は大阪(豊中)にあるが、法事は京都で行われた。いつも、京都では錦市場でおみやげを買って帰るだけだが、今回は珍しく市内の行事を調べて銀閣寺で特別公開があるというので、何十年ぶりかに東山の銀閣(慈照寺)に足を延ばした。

 特別公開は、足利義政の持仏堂で書院造りの原点といわれる東求堂(とうぐどう)の内部と与謝蕪村などの襖絵である。「写真はとるな。角のある持ち物をふりまわすな。壁にもたれるな」とやけにうるさい。まあ、国宝なのだから仕方あるまい。

Dsc00643

 ちょうど雨上がりで、庭園の緑がとても美しかった。義政は西の苔寺(西芳寺)を愛していたらしく、豊富に苔が各所に使われて庭を引き立てている。有名な砂の山や、砂の海原は江戸時代の考案らしく、義政本人の趣向には見えない。

 錦市場で、いつもの、三木鶏卵の卵焼き、打田の漬物、丹波の栗などをしこたま買い込んで、機嫌よく、秋の京都をあとにした。それにしても外国人の数はすさまじい。初日のホテル(ノク京都)は外資系もあるが、90%は外国人で、日本人の数に入れていた隣の夫婦連れは、近くを通ったら日本語を喋っていなかった。

Dsc00641 前回と違い、帰りの東名は幸い大きな渋滞にもあわず(海老名で30分くらいの事故渋滞だけ)、5時間余りで東京に戻ってきた。昔、正月一日に、がらがらの東名をしゃかりきに飛ばした私のコースレコード5時間ちょうどに迫る記録だ(もっともそのときの距離は506キロ、今は480キロ)。

| | コメント (2) | トラックバック (0)

2016年9月11日 (日)

電子工作は復活できるか。行き当たりばったりの工作

 また更新が遅れている。とうとう8月は記事を一本も出せなかった。このブログの大きなテーマである電子工作をろくにやっていないので書くことがない。当然と言えば当然なのだが、電子工作を始めてもう10年近く、ブログも8年を経過し、このブログは自分の備忘録として欠かせない存在になっている(物忘れがひどいのでこれが頼り)。

 大げさに言えばこれが人生の一部になってしまったような感じで、何か書いていかないと、自らの存在を否定してしまうような恐怖感を覚えるほどだ。ということで、読者の方には甚だ申し訳ないが、今回も脈絡のない行き当たりばったりの電子工作の記事を読んでいただくことになる。申し訳ない。

赤外線学習リモコンはとりあえず撤退。復旧作業に入る(8/1/2016)
 Windows10のインストールにかまっていたら、あっというまに8月になっていた。前回はやっとのことでブログ記事を上げたが、電子工作の部分は極くわずかで、大部分は、同窓会と病気とPCの話ばかりである。工作机のブレッドボード上の学習赤外線リモコンの配線は、ロジアナのプローブで山盛りのように盛り上がったままである。

 とにかく、先に進む意欲が生まれない。迷路に入ってしまったこともある。テスト対象にしている赤外線リモコンボリューム(自作)の方が頻々と暴走を繰り返すので、本題の学習リモコンのトラブル解明が進まないのだ。

 ロジアナで見る限り、ちょっと見たところでは、正しいビット配列を指定の時間間隔で出しているように見える(リーダービットなど)。しかし受け側の赤外線リモコンボリュームは全く反応しない。手持ちの市販リモコン送信機では苦も無く反応するのに、どうにも気分が悪い。

Ws000006 このリモコンボリュームは、Tiny2313を使っているので、SRAMが128バイトしかない。必要なデータを表示しようと思うと、すぐスタックがオーバフローし、リセットされてしまう。こいつのデバッグをしていると何かとても無駄なことをやっているような気がして気分が盛り上がらない。

 別のテストベンチを作るか、記録するデータを長さのデータではなく、一度デコードする方式に換えれば、先に進むのだろうが、これらを変えるのは、すべてかなりの手間(恐らく今のTiny861では無理)になるので、さらにやる気が起こらない。

 暫く放(ほう)ってあったが、このまま立ち枯れ状態になっているのも始末が悪い。とにかく、このテーマからは撤退することにした。ロジアナのプローブを片付けて机を整理する。テストのため、いじっておかしくなった(時々止まる)リモコン電子ボリュームの復帰から始める。

Dsc00525

 現在この電子ボリュームは使っていないとはいえ、元通りにはしておきたい。ソースに入れたテストステートメントをすべて抜き出して再コンパイルする。暴走はしなくなった。しかしこのボリュームの売りである電源を切る前のボリュームの位置を再現しなくなった。

 このしかけは、リセットICを使って、電源が切れる寸前に制御信号を入れ、EEPROMにその時の音量レベルを記録することで実現している。ソースコードを調べているうちに、リセットICの制御ピンとUART受信ピンが被っていることを発見した。テストのためのUART受信を生かしたままになっていた。

 やれやれ年は取るものではない。これまでのソースやブログの記事に明記していなかったので、このことをすっかり忘れていた。UART受信を無効にし、これで電子ボリュームは完全復活した。組み立てなおして所定のオーディオラックの位置に戻す。

アームクローラーの玩具を買ってみる(8/10/2016)
 simさんのブログに載っていた、キャタピラーが2重になった不整地走行可能なアームクローラーの玩具が急に欲しくなり、いつのまにかアマゾンの購入サイトでボタンを押してしまっていた。

 何かの当てがあるわけでもない。どれくらいの不整地まで踏破できるのか試してみたくなったような気がするが、これは衝動買いを正当化する言い訳で、要するに気分が乗っただけである。電子工作も本来はこういう「ときめき」から始めるべきで、無理にやるのは無駄が多い。自戒である。

 キットは、単に直進するだけの機能で価格は¥2000しない。しかし¥2000以下だと送料がかかる。良くしたもので、2モーターのリモコン対応の部品をつけると送料無料の金額になるセット販売の案内がある。躊躇なくこちらを選ぶ。昔はこういうのに抵抗があったが、今は全くない。

Dsc00569 到着したタミヤのプラモデル風のクローラーの組み立てに熱中する。作りながら、これをこれまでのリモコン用の機器をどう組み合わせるかあれこれ考える。もうXbeeは良いだろう。ESP8266かIntel Edisonか、それともRaspberry Pi(以下、Raspi)か。

 いずれにしても手を動かしていると、スランプを忘れる。2モーターのモーターアセンブリーも一緒に組み立てる。組み立てたあと、シャフトが違うことに気が付き、もういちどギヤボックスの組み立てをやりなおし。説明書が微妙に不親切だ。

 モーターの配線に2か月振りにハンダごてに火を入れ、雑音抑止のコンデンサーとリードをハンダ付けする。モーターを回してみる。問題なく両方動いた。とりあえずこれでメカの部分は完成である。

IGZOの液晶パネルを買ってしまう(8/18/2016)
  そのうち、オリンピックが始まった。予想外の選手がメダルを獲ったりして、日本が盛り上がっている。いつものようにメディアが金属回収業者のように「メダル、メダル」と叫び、例年このプレッシャーに負ける選手が続出するのだが、今年は続々と表彰台にあがる日本人選手の笑顔が何度も画面に映る。

 吉田沙保里の4連覇は実現しなかった。五輪主将はメダルをとれないというジンクスがあるらしい。しかし銀メダルなら大威張りではないか。若手が台頭してきたのだから先輩は喜ぶべきで、表彰式まで泣きじゃくるのは少々大人げない感じがした(主将なんだから)。

 クローラーの組み立ては終わったが、これをリモコンにするための実装の良いアイデアが浮かばずそのままになっている。そのうち、ウェブをみているうち別のものに関心が移ってしまった。

Dsc00553_2 これもどなたかのブログで、Raspiの液晶パネルの話が出て、以前から気になっていたのだが、急に再燃して欲しくなってしまった。夏休みで10日近く休んでいた事務所に出た帰り、久しぶり(2か月以上)に、秋葉原を訪れる。秋月電子はいつものようにごったがえしていた。

 この盛況を見る限り、電子工作が下火になった感じはしない。Raspi用の液晶パネルは前と同じ、店の前の平積みのカウンターに無造作に積み上げられていた。ついでに500万画素もある専用カメラなども購入。珍しく2万円近い出費である。

IGZOパネルは最初は気難しかった(8/20/2016)
 秋月には、2種類のRaspi用のパネルが売り出されている。ひとつは、純正のタッチパネルがつき、専用のインターフェースにつける、800x480のもの、もうひとつは、SHARP製の、何と1920x1200のパネル。どちらも7インチだが、SHARPのIGZOパネルは、HDMIインターフェースである。Dsc00551

 値段はどちらも1万円を超すが、どちらにするか迷うところだ。結局、汎用性、性能対価格比の優るIGZOを買うことにした。7インチで1920ドットである。フレキケーブルが微妙だというので、専用のスタンドも一緒に購入した(¥2000)。

 帰宅して、液晶パネルを取り出す。まず驚くのがその薄さである。スタンドのアクリル板の保護シートを、傷をつけないよう慎重にはがし、パネルを挟み込む。2枚ある基板を付属の取り付けポストを使って背面のアクリル板に固定する。

Dsc00552_2  ここまでは、それほど難しい作業ではないが、一番難儀したのが、薄紙のように薄いFP(フレキ)ケーブルの接続である。不安定な状態でパネルを持ち、基板側のソケットにケーブルを接続しなければならない。

 特に電源側は、4ピンしかなく、髪のように細い。ブログにも、この4ピンFPケーブルがコネクターに刺さらず泣いたという話が紹介されている(ハッチの上がる方向が逆)。こちらも何回か予行演習をしたあと何とかつながった。

P9057517 しかし、基板とFPケーブルの周りは裸で、このままでは何かの拍子に、ものが当たって、ケーブルが切れる心配が十分ある。色々考えた挙句、コネクター周りにプラスチックのガードを2面つけた。それにしてもこの細かさは尋常ではない。

config.txtはRaspiのBIOSだった(8/21/2016)
 久しぶりにRaspi3に火を入れる。順調にシステムは立ち上がったが、液晶は真っ暗のままだ。電源はシステムが立ち上がる前に入れておかないといけないとか、画面が出ているときに不意に電源を切ると液晶ピクセルが壊れるとか脅されている。えらく気難しい。

 何度か説明書を読み込み、指定通りのconfig.txtをtelnetを使って作ったが、画面は出てこない。config.txtを戻して、これまでのPCのHDMIケーブルを差し替えると、問題なくRaspiのデスクトップが出るので、犯人はこのconfig.txtの設定か、液晶パネルそのものである。

 心配なので、FPケーブルのコネクターの差し込みをやりなおす。念のため、実体顕微鏡を持ち出して、コネクター周りを視認する。大丈夫なようだ。とするとconfig.txtの設定誤りということになる。

 調べてみると、config.txtとは、RaspiのBIOSにあたる部分で、ハードに密着しており、少しでも違うとおかしくなることは十分考えられる。試しに、このパネル用のconfig.txtで立ち上げると既存のPCディスプレイでも真っ暗になる。

 もういちど説明書の、config.txtの記述と、実際のコーディングとの違いを調べ始めた。その結果、2か所も間違っていた。最初の、hdmi_pixel_freq_limit=200000000の0がひとつ多すぎるところと、frame_buffer_height=1200をmaxと同じ1920にしてしまっていた。Dsc00558

 これらを直して、祈る気持ちで再度、raspiの電源を入れる。おーし、液晶パネルのバックライトが明るく点灯し、画面右上隅にアイコンが現れた。とみるまに立ち上げのメッセージが矢のように流れ始める。間もなく、順調にデスクトップが現れた。いやあ小さい、しかし実に鮮明な画像だ。

いやあそれにしても小さい。すごい(8/23/2016)

 IGZOの7インチデイスプレイがやっとのことで動いた。嬉しくて記念撮影をする。HDMIケーブルが大きすぎてパネルが動く。もっと細いケーブルを買ってこなくては。マウスポインターは糸くずのように微小で、文字は殆ど読むことが出来ない。残念ながら画像や動画ビュワー以外の実用性には欠けるようだ。Dsc00555

 アマゾンでHDMIのスリムケーブルを入手した。届いたケーブルを見て吃驚(びっくり)する。こんな細いので大丈夫? 無事つながることを確認した。面白いので以前使っていたケーブルと比較写真。これまでのケーブルではケーブルを動かすと本体が動いた。

 デスクトップ画面の実用化のため、画面拡大の方法を模索する。調べた結果、Ubuntuにkmagという画面拡大のアプリがあり、これが一番使いやすそうである。しかし、raspiのOSは同じdebian系統だが、ubuntuではない。ウェブを調べたが、確証はとれない。

Dsc00566  だめもとで、試しにraspiで apt-get install kmagをやってみたら、感心にもインストールを始めた。無事、エラーもなくインストールされたので、勢いでkmagをターミナル端末から直接入力した。なんと、無事にubuntuのkmagがraspberryPiでも動いた。

 今のところ、kmagを立ち上げるところだけが細かいが、そのあとはそう苦労せずにターミナルからのコマンド投入が行えるようになった。少しは実用に近づいたかもしれない。

MP4212の回路に大きな誤解があった。モータードライバーを作る(8/15/2016)
 ウェブで刺激されて買った、キャタピラーが2重になって荒れ地を走行できるクローラーの玩具の話に戻る。モーターが動くところまでで止まってて、次はこれを何でドライブするかである。モータードライバーは、MP4212にしようと思っている。

 世間には数限りないモータードライバーが売られているが、へそ曲がりの所長としては、出来合いのモータードライバーを使うのには抵抗がある。どうせなら、裸に近い形から作りたい。といっても「へたれ」なので、単体のFETやパワーTRから組みこむのは疲れる。

 そこで、MP4212だ。このFETモジュールICはとうに生産停止になっているが、まだ在庫があるようで、入手性はそう悪くない(千石やサトー電気で買える¥300程度)。モーターの正逆転回路、HブリッジをひとつのICで実現できるようコンプリメンタリーなFET(N-MOSとP-MOS)が2つづつ入っている。

 このFETモジュールは、以前、自作サーボモーターの時使って、回路図まで公開している。しかし、今度のクローラーで調べているうち、もっと安全で簡便な回路があることがわかった。前の回路は、間違っているわけではないが、使い方によっては、ICを燃やす危険がある。

 前の回路は、正転と逆転のそれぞれの制御信号があるが、これを両方Highにすれば、貫通電流が流れる危険があるのだ。ソフトでそうならない保証はない。今度見つけた回路は、正転、逆転の2つの制御信号が同時にHighになっても、モーター部が短絡するだけで(ブレーキがかかる)、電源側は短絡しない。しかも前は必要だったドライバーのトランジスターが不要である。

 この回路図をみつけたので、急に自分も作りたくなった。オリジナルは、ドライバーにフォトカプラーを使っているが、同じVccを使うならこれもいらない。ブレッドボードで手早く作り、動くことを確認した。

リアルタイマークロック(DS3231)の月差は1秒以下(8/27/2016)
 クローラー工作の続きで、ESP8266のPWDでモーターを動かそうと、棚に放置していたESP8266を引っ張り出した。このブレッドボードには、I2C機器のテストに使ったRTC(DS3231)が付けたままになっている。Dsc003860002 ヘルスチェックのつもりで通電し、今年の4月1日に接続したままの時計の計測をしてみた。このRTCは以前のブログ記事に、月差が2秒以内と紹介した記憶がある。

 今測れば、4か月、149日間の誤差を測ることになる。シリアルポートを生かし、時計の表示を見る。いやあ、これは驚いた、遅れが3秒以内だ。30.4日を1ヵ月として、3X30.4/149 は、月差で0.61秒である。置いてあったところが地下室で温度の変化が少ない所とはいえ、信じられない精度だ。

いやあひどい目にあった。PC突然死亡。結局、電源不良だった(9/8/2016)
 メインのPCが急に動かなくなって、この4日間、これにかかりきりだった。おかげで遅れたブログのアップがさらに遅れて気の抜けたビールのようになってしまった。

 事件は、突然に起きた。いつものようにPCの起動ボタンを押したが、反応がない。電源コンセントがはずれているのかと確かめたが、何も変わっていない。起動ボタンを押して電源ランプが一瞬点くが、すぐに消えてしまうことがわかった。CPUのファンさえ回らない。

 思い当たることは何もない。突然、メインのPCが動かなくなってしばし呆然となる。あちこちいじっているうち、BIOSの画面までは出るようになった。どうもACプラグの差し込みがゆるかったかのような感じである。しかし、Windowsの立ち上げが始まると必ず途中で電源が切れる。

一旦切れたあとは、リセットボタンも、起動ボタンの押下の反応もなくなるので、最初はてっきりマザーボードが、ご臨終になったものだと考えた(これが重大な誤りだったことはあとでわかったのだが、この時点ではマザーだとばかり思っていた)。

 マザーのトラブルは交換するしかない。あわてて、サブのノートPCを使ってウェブで、ASUSの同じ機種のマザーを探す。5年以上も前のマシンなので、もうCPUのチップセットLG755の新品は売っていない。中古のこのマザーの後継機種らしいものを見つけて注文した。

 3日で届いた。いや助かった。すぐ組み立てにとりかかる。久しぶりの自作パソコンの工作である。いくつか切り傷を作りながら(安物のケースは特に危険)、これまでのマザーを取り外し、届いたマザーに組み替える。最初、メモリーだけ積み替えて苦笑い。CPUを忘れていた。

 さあ、組みあがった。電源を入れる。何と、何と、前と同じ症状で、電源が途中で切れた。うはあ、これは大変だ。これはマザーではなく、電源不良の可能性が高い。リセットボタンが効かなかったのでマザーとばかり思っていたが、ウェブによるとこれは電源不良の特徴なのだそうだ。

 時間が惜しいので、直接、秋葉に買いに行くことにした。車を飛ばし、近くのコインパークに車を止め、パソコンショップをはしごする。いわゆるDOS/V通りは、以前と様変わりしてパソコンショップはもう数えるほどしかなかった。

 昔懐かしいTwoTopがまだやっていたので、ここで適当なATX電源(玄人志向の500W)を買い込んで自宅へトンボ帰りする。電源の交換は、マザーほど大変ではない。組み替えて、本当に祈る気持ちで起動ボタンを押す。おお、動いた。OSの立ち上げまで行った。

 しかし、立ち上げの途中で突然電源が切れることを何度も繰り返したため、Windows10は、再起不能の状態で、システムの再構成を要求してきた。仕方がない。それに従うことにする。1時間近くかかって再構成は終了した。電源が切れることはなくなったが、システムの中身は散々な状態になっていた。

 ほとんどのアプリケーションが削除されてしまっている。このあと何とかWordなどを再インストールして、このブログを書ける状態までになった。それでも数多くのアプリが死んだままだ。とりあえず今の状況を報告して、今回の記事を終わることとする。

| | コメント (2) | トラックバック (0)

2016年7月21日 (木)

赤外線学習リモコンはデータ再現で挫折したまま進まず

 キャプチャーした赤外線のデータ列をロジアナで確認し、学習リモコンの工作は峠を越したと考えたのは甘かった。あれ以来すっかり電子工作への意欲が湧かなくなって、気が付けばもう2か月近くが経とうとしている。

 深刻なスランプである。何とか先に進めようと、作業の前にこれからの作業項目をメモに列挙し、気力を奮い立たせてPCに向かう。開発環境を立ち上げ、メモの手順に従って開発する。

Dsc00524

 これまでなら、一旦作業が流れに乗ると自然に手が先に進んでいくものなのだが、最近は少し結果が出ると、何故かそれ以上のやる気を失い、ほかのことに気をとられてしまう。これが愚にもつかないゲームや、ウェブサーフィンだったりする。困ったものだ。

 責任を転嫁する気持ちは毛頭ないが、どうも最近は電子工作そのものも前に比べると盛り上がりに欠けているように感じる。所長が始めた8年前は、活発な活動をしている掲示板やブログサイトが沢山あって、大いに参考にさせてもらったものだ。

 ところが、現在はみな低調で閑古鳥が鳴いている掲示板が多い。電子工作関連の雑誌も、以前はFPGAや32ビットCPUの基板が盛んに付録につけられて、みんなでわくわくしながら動かしていたものだが、最近はこういう話も聞かない。

 実は、所長の電子工作が低調なのは理由があって、5月の末、体調を崩し病院通いをしていたせいもある。工作をする気持ちのゆとりがなく、一時は、狭心症の疑いまでかけられたのだが、幸い誤診だったようで、今は全く症状はない。

 この話はあとですることにして、趣味の電子工作全体が低調な原因には思い当たる節がある。個人的で一方的な仮説にすぎないが、この低調さは最近のArduinoの普及と大きな関わりがあるように思える。

Arduinoの功罪
 商売の邪魔をする気は全然ないのだが、Arduinoで電子工作の世界は大きく変わった。しかし反面、つまらなくなった。まずメリットの方はご存知のように次のようなものだ。

ハードウエアのI/Oインターフェースが統一されているので、初心者は、面倒なI/Oピンの初期化に気を遣わないですむ。誤配線や誤設定をする恐れが少ない。最近は機種を超えて共通なのでハードウエア設定はさらに楽になり失敗はほとんどなくなった。

各種のペリフェラル(UARTやI2C、SPI)の設定も、スケッチライブラリーが全部用意されているので、プログラムを書くのが大変楽になった。ほぼデータの中身だけを心配すればよい。

各種のシールド(増設するディバイス)とそのライブラリーが用意されているので、簡単に高度な機能を実現できる。

 経費的には、はるかに高額になったとはいえ、便利になったことは間違いない。所長もESP8266では大いに恩恵を受けた。その反面、この道はあらゆるテクノロジーの世界がこれまでに経験したことと全く同じ道である。

Ws000003

 便利になればなるほど、細部を知らないでも先に進めるので、技術を身につける機会を奪ってしまう。つまり情報が隠蔽化され、ブラックボックスになっていけば、必然として次の弊害が起きる。

組み立てて、それで動けば問題ないが、一旦、動かないとなると、どこから手を付けて良いのか全く見当がつかなくなる。故障や、ちょっとした不具合にも対応することが出来ない。

作った製品の改善や、改良は殆ど出来ない。製品の応用もできなくなる。いわゆる技術力は身につかない。

それでもこうした複雑になったしかけを短時間に理解し、その応用ができる技術者は一部に存在する。しかし以前にも増してその数は限られる。これにより技術者間の格差はさらに広がる。大多数の一般の人は作って動かしただけで終わってしまう。

 最近の電化製品は、一旦故障が起きると一般の電気店では殆ど修理不能で、自動車もそうだ。ボンネットの中は完全なブラックボックスで点火プラグひとつ素人が交換できない。その製品を使うことが目的ならそれでも良いが、電子工作というのは作る過程を楽しむ趣味でもある。

 従って、電子工作にすぐ飽きる人が増える。ちょっと見は楽そうなので一時的に参入者は増えるかもしれない。しかし長い目で見ていると、参加人口はどんどん減っていくという寸法である。これまで繰り返されてきた、知らずに自分で自分の首を絞めているという業界の悲劇がここでも起きているように思う。

サードオピニオンまで聞いて何とか安心(6/23/2016)
 それはさておき所長の病気の話である。ある朝、コーヒーを淹れようとミネラルウオーターの2リッターペットボトルを持って機嫌よく階段を上がっているとき、突然、息切れがして胸が苦しくなりその場に座り込んだ。息切れは間もなく解消したが動悸がおさまらず、その後はちょっとした運動をするだけで、すぐ息切れがする。

 近くの医院で心電図や血液検査をしてもらうが、特に異常はない。最初は熱中症だと言われた。しかし気温が30 度以下の室内では考えにくい。頻脈は心理的なことでも起きるというので最初にもらった薬は何と精神安定剤だった。

 数日経って息切れはだいぶ良くなったとはいえ、洗車をしただけで息が上がる。近所の医院の医者は大病院で精密検査をすることを勧めてくれた。最初に行った大病院では、心臓エコーなどの検査を受けた。しかし、ここでも特に異常なしと言われる。症状は殆ど改善していたが、原因がわからないのは不安だ。

 さらにまた別の大病院に行く。ここの医者は症状を聞いて、「これは狭心症しか考えられない」と宣言する。なんだ、やっぱり狭心症なのか、そういえば血液が高脂質だと注意されている。ニトロ舌下錠までもらって覚悟を決める。ただ念のため、造影剤を使った心臓CTスキャンを撮ることになった。

 近くの医者に報告する。「すっかり病人にされちゃったのね」と笑う。このとき、こちらは狭心症を見抜けなかったこれまで2人の医者は藪(やぶ)だと思っていたので内心は穏やかではない。

 心臓CTスキャンの結果が出た。見せられた自分の心臓の血管はプラモデルでつくったようにつるつるで動脈硬化のかけらもなかった。医者はあっさり狭心症の見立てを取り下げた。で、同じときに撮ったCTスキャンの肺臓にいくつか血栓のあとがみられるので、肺塞栓症、そう、いま流行のエコノミークラス症候群だろうということに落ち着いた。

 そうか、前の2人の医者は藪ではなかったのだ。医者の見立てというのは恐ろしい。CTスキャンがなければ、ずっと狭心症の薬を飲まされているところだった。1週間飲んでいた薬が、動脈から静脈に急に変わって、薬局の薬剤師が笑っていた。

 とはいえ狭心症より、肺塞栓症の方が始末が悪い。血栓が出来る要因がはっきりしないからだ(2月に海外旅行にでかけているが3か月も前の話)。ただ一過性なので今は全く問題ないというのが有り難い。それに心臓が思ったよりきれいだったので安心している。

2年ぶりの小学校の同窓会。今度は世界遺産の宇治上神社と平等院(5/20/2016)
 さらに、電子工作とは関係ない話題をもうひとつ。実は前記事をアップする直前、例の、京都の小学校の同窓会が2年ぶりに宇治で行われたので行ってきた。そのときの写真を少しご紹介しておこう。

Dsc004520001

 宇治は硬貨の裏にも彫刻され、世界遺産にもなっている平等院の鳳凰堂が有名だが、実は、それ以外にも世界遺産に指定されているところがある。それが、平等院の川向うの北東に位置する、宇治上(うじがみ)神社である(京都のお寺や神社がすべて世界遺産ということではなく、全部で17か所)。

 所長も行ったことがない。同窓会をその近くで行うというので、また日帰りで京都へ行ってきた。同窓会の前に、その神社に行ったのだが、何の変哲もない神社で完全に足をすくわれた(これは予想した通りでもあったが)。

Dsc004530002

 世界遺産に指定された理由は、国宝となっている日本で一番古い神社の本殿が残っていることらしい。しかし別に驚くような建物でもない。これだけで他には何にもない。実にあっけない世界遺産だった。まあ観光客が殆ど来ていなくて、のんびりと散策できたことは収穫だった。

 今度の同窓会は、この世界遺産と、遠方から珍しい同級生(何十年ぶり)が来るというのに釣られて来たのだが、まさに60年ぶりに会った同級生は、頭が薄くなっていたが、話をしているうちに完全に小学校時代の面影が再現し、とても感動した(相手があまり自分のことを覚えていなくて少し残念だったが)。

Dsc004570006

正しいサブキャリア―周波数を作る(6/2/2016)
 電子工作の話に戻ろう。工作そのものは、前回記事のあと少しやっただけで、その後は殆ど進展していない。もともとは、無線WiFiモジュールのESP8266で学習する赤外線リモコン遠隔制御装置を、それこそArduinoで作るつもりだった。

 ウェブにはいくつかのソースコード(スケッチ)が公開されている。ここここのソースを拝借すれば恐らく問題なく動くのだろうが、それだけでは何となく面白くない。赤外線リモコンは応用範囲が広いので、ハードなどの技術をマスターしておきたい。そこであえてマイコンのAVRで基本的なところから作りこんだ。それが、深みにはまっている。

 赤外線の学習リモコンというのは、既存の赤外線リモコンの送信データを、受信してそっくり記録し、あらためて必要に応じて、その赤外線データを送信するもので、前回のブログ記事の通り、データ受信と記録の機能は、Tiny861を使って(最初Tiny441で失敗)、開発に成功している。

 次は送信部である。赤外線のデータ規格はさまざまな種類があるので、汎用的にするため、ここでデコードすることはやめ、忠実にその長さに基づいて赤外線を発信する方法をとることにする。エラー率は高くなるが、とりあえずはこれに挑戦する。

 送信用の赤外線LEDはこれまで使ったことがない。まずはミニブレッドボードに、送信用赤外線LEDとFET(2SJ377)をつけて、赤外線LEDがon/offできるか確かめる。確認のため普通の発光LEDを並列につける。問題なく動いた。制限抵抗が300Ω程度でも1m位は受信するようだ。

Dsc00527

 次はソフトウエアである。これまでの受信部とこの送信部を少し大きめのブレッドボードに統合したあと、送信側のロジックを開発する。キャリアーパルスはPWMでなく、通常のGPIOをタイマーで駆動して、duty比1/3のサブキャリアーを作った。

 割り込みルーチンにこれを組み込み、ON/OFFはメインループのフラグで行う。タイマー割り込みはサブキャリアーの2倍(on/off)のタイミング13μsで発生させる。メインループのON/OFFは、最少でも500~600μs単位なのでこれで十分動くはずだ。

 動かしてみる。オシロでサブキャリアーの周波数を測定する。うーむ、30Khzを下回っている(およそ28Khz)ので受信モジュールが正しく動かない可能性がある(仕様上は30~38Khz)。

 遅れる原因をチャートを書いて調べる。キャリアーパルスの遅れは、タイマー割り込みが起きて割り込みルーチンに来るときの時間(オーバーヘッド)だけが問題で、割り込みルーチンの中の処理は関係しない。実測してみるとこのオーバーヘッドは、8Mhzのクロックで4μs内外のようだ。

 それを加味して、タイマーの時間を調整する。しかし、どうも計算通りにならない。思い切って値を減らす。対症療法だが、これでやっとサブキャリア―が30Khzを超えた。まずはこんなもので良いだろう。

送受信の分離にてまどる(6/8/2016)
 受信で得たパルスデータの配列(立ち上がりと立下りの間の時間1バイト)から赤外線パルスを作るのは簡単だ。送信の指示があれば配列をループに入れ、先頭から配列データに入っている待ち時間を計算してウエイトし、データの最後まで送信LEDのスイッチをon/off(exclusive OR)させるだけである。

 しかし、最初はうまくいかなかった。同じCPUに送受信ルーチンを入れ込んであるため、送信赤外線が出始めると、受信側が割り込みを開始して動いてしまう。送信パルスは間隔を単なるループ回数で決めているので、正確な間隔にならなくなる。

 受信側の割り込みを動かないようにすれば良いのだが、これが意外に面倒だった。どうしても、最初のパルス受信を止めることが出来ない。送信パルスの発生は、タイマーの割り込みルーチンで動いているので始終動いており、受信モジュールの割り込みを止めるステートメントの場所が難しいのだ。

Led1

 停止をするステートメントの前後を割り込み禁止にし、ペンディングの割り込みを事前にクリアするステップを追加してやっとのことで、受信を黙らせることに成功した。その後はロジアナで波形を見ながら少しづつ送信波形を記録したデータに近くなるよう調整していく。

 ロジアナがまたも大活躍である。これがなかったら全く手も足もでなかっただろう。ロジアナさまさまである。Tiny861の20ピンが大いに役立った。いくらでもプローブ点を作れる。5本で解析すれば、だいたいのことはわかる。

Dsc00526

 現在の我が家にあるリモコンは5種類以上ある。学習リモコンの最終ターゲットはエアコンだが、このデータ列は長大なので、とりあえずは電子ボリュームに使ったSONY仕様のリモコンを当面のターゲットにして調整する。簡単といっても、こいつもリピートとして同じ信号が必ず5本近く出るので、正確な信号を再現することは結構難しい。

やっとのことで3機種の再生に成功したが、本体が受け取らない(6/22/2016)
 徐々にではあるが、学習赤外線リモコン送信部がそれらしい赤外線データを再生し始めた。SONY仕様の12ビットの信号も、ロジアナで見る限り、10%内外の誤差でデータをだしているようだ。

 リピートの処理はリピートとリピートの間の40msの間隔でタイムアウトをとり、2番目以降のデータを無視することで正しいデータが得られるようになった。エアコンのリモコンに対象を移す。データは多いが、何とか512バイト内(Tiny861のSRAMサイズ)に納まっている。

 いよいよ、当面のターゲット、寝室の最近新しくしたリモコンデータである。おやあ、Tiny861がリセットする。ええー、こいつは512バイト以上なの? 測ってみた(数だけ勘定する)。何と何と、こいつは292イベント(146ビット)もあり、しかも念の入ったことに、10ms程度の休みのあと同じデータが繰り返されていて軽く配列データが512バイトを超えてしまう。

Led2

 仕方がない。リピートのタイムアウトを10msに縮めて最初のデータだけを記録することにする。さらにテストを続ける。今度はデータ列の最後のイベントの割り込みがペンディングになり、これが次のデータ列とみなされて本来のデータが消えてしまうトラブルに悩まされる。これは、割り込みリクエストのクリアをいたるところに入れて回避する。

 悪戦苦闘の結果、3つのリモコンそれぞれで、ほぼ原形通りの波形を出力するようになった(まだ実地テストはやっていない)。こんなに長い間かかるとは当初考えても見なかった。原因は、それぞれのリモコンが持っている、リピート信号を除去するのに手間取ったことが一番大きかった。もうちょっと、プログラムの構造を考え直す必要があるかも知れない。

再生したデータで本体動かず。意欲がわかない。完全なスランプ(7/4/2016)
 体調はすっかり戻った。週2回のジムでも、プールで300mが楽に泳げるようになった。ただ、電子工作への集中力が途切れている。送信部のデータがほぼ想定通り出たので、実機でのテストに入る。対象は、まずは電子ボリュームにしているSONY仕様の一番簡単なリモコンのテストだ。

 オーディオコーナーに設置してある電子ボリュームを工作机に移し、ケースを外してデバッグ用のUARTを取り出す。うまく動けば良いが、動かないときの用心である。苦労して設定し、いよいよテストに入る。

Dsc00525

 だめだ。全く動かない。UARTにすらメッセージが出ない。送信データのデコードがうまく出来ない。一番簡単なSONYフォーマットのデータを受け付けない。たかだか12ビットのデコードが出来ないのだから、100ビット以上あるエアコンのデコードなど思いもよらない。

 何が原因か。赤外線の出力をちゃんと受け取っていることは確認した。出力波形は、入力とほぼ同じになっている。少しづつ違うようだが、誤差は20%もないだろう(600usが500us程度)。ただ、このあたりは10 %以下でないと駄目なのかもしれない。

 こうなると意地になるのが常である。電子ボリュームのソフトをいじって中身のデータを出せるような体制に入る。しかし、この機器のCPUはTiny2313で、SRAMが128バイトしかない。ちょっと詳しいデータを出そうとすると、スタックのオーバーフローで簡単に暴走してしまう。

 このあたりで集中力が切れた。このままでは泥沼である。体制をもういちど見直して最初から仕切り直しをしたほうが結局効率が高そうだ。しかし、電子工作への意欲が落ちているのでなかなか次の一歩が進めず、いたずらに時間が経つばかりである。

Windows10インストールで最初の犠牲者(7/12/2016)

 そんなことで別のことに興味が移ってしまった。Windows10である。今さらの感もあるが、今月末に無償アップグレード期限が切れるというので、渋々入れることにした。Windows7で何とか動いていたMSのFlight Simulator(FS 2004)が心配だが、まあそれはあとで考えることにして、これまでさんざん無視していたWindows10移行のボタンを押す。2時間近くかかった。

 ソフトは大体無事だったが、いくつかのハードがらみのアプリに問題が出た。Epsonのスキャナーは何とか、このサイトの情報で助かる。LAP-Cのロジアナはバージョンアップの情報があったのでうまくいくと思ったが、以前のファイルが残っていて正常に動かすのにてこずった。

 AtmelStudioや、Win95時代の定番のエディターや、ターミナルは無事だった。もちろんChaNさんのAVRSPも問題なし。開発環境はほぼ整った。やれやれ。

 FS2004は遂に動かなくなった。そもそもCD-ROMを入れないと動かないソフトは全滅のようだ(セキュリティの関係らしい)。OSそのものは確かに軽くなった。もっともこれは、Win10とともにメモリを増強したことが原因かも知れない(AtmelStudioがメモリ喰らいで、メモリを2Gから4Gにした)。

 大所が動いて、細かいところのテストに入る。意外なところがダメだった。サンワのUSB BlueToothドングルは、現在ほとんど使っていないが、こいつが動かなくなった。サイトを見るとなんと「Win10はサポートしていない」というではないか。最初の犠牲者だ。

 こいつは、仕事の帰り、ヨドバシに寄ってWin10対応のものを買いなおした。なんと、¥1000少々。気が抜ける価格だ。ウェブ上では、BlueToothの世界も沢山のバージョンがあり、色々な話が渦巻いているようだ。まあ、最近のボードは、このあたりはすべて内蔵だから、ドングルに関心が薄れたのかもしれない。

Dsc00530

 ヨドバシ秋葉原店は、膨大な売り場面積だが、BlueToothのドングルは5種類くらいしか売っていなかった。動かないという苦情が多いせいなのかもしれない。

 ともあれ、Windows10は今のところ順調に稼働している。ブログの紙数も増えてきたようなのでとりあえず活動報告をここで一区切りすることにする。

| | コメント (6) | トラックバック (0)

2016年6月 1日 (水)

落穂ひろいの電子工作(続き)赤外線学習リモコンで遊ぶ

遂にパワーダウンスリープの不具合が解消された(5/8/2016)
 機械式自動巻時計のゼンマイを巻く自動巻機(ややこしい)の不具合の話を前の記事に書いた。結局、原因解明ができず途中であきらめたのだが、記事の最後に「閃いた」というコメントを残しておいた。

 「閃いた」のは以前、似たような状況でAVRのマイコンに、ある機能を組み込んだことを思い出したことである。それは電子ボリュームの赤外線リモコンを作ったとき、パワーダウン時のEEPROM書き込みの誤動作をさけるフューズビットの設定、BOD(Brown Out Detect)機能である。09p6017508 BODとはVccが低電圧になったとき、CPUが誤動作しないよう内部でリセットする機能で、デフォルトでは設定されていない。ウェブ上でこんな記事を見つけたことも、BODが気になるきっかけになった。

 この記事は、スリープから目覚めるときにはBODを設定しておいた方が良いという内容で、直接現在の不具合とは関係ない。ただ今度の不具合は、CPU内部の不可思議な動き(電源断のときの電圧降下の遅さ/速さで症状が違う)に関連がありそうで、何となく臭う。

 こじつければ、電源が切れた後、パワーダウンスリープからVccが徐々に下がっていくとき、何らかの予期しない動きがあって今の状態になると考えれば、Vccが下がると同時にリセットがかかる方が望ましいことには違いない。

 ということで半信半疑だったが、藁をもつかむ思いで、件(くだん)のTiny2313にBODを設定してみることにした。フューズビットを見てみると、現在の状況では未設定である。何の確証もないが、物は試しである。4.3Vでリセットがかかるようにする。

 おおお、何ということだ。これでパワーダウンスリープで電源を抜いても、問題なく初期状態でCPUは動き始めたのである。いつも必ずトラブルが起きていた、ACアダプターのACコード側の抜き差しでも、全く症状は起きない。

 実際に運用してみた。見事、1週間問題なく動いた。やれやれ、何だったのだろう。全く根拠はないが、BOD設定をフューズビットに設定するだけで直ってしまった(その後も、順調に稼働中5/31記)。

すごい、DS3231の月差は1.2秒(5/10/1216)
 久しぶりにWiFiモジュールのESP8266を動かす。最後に触ったのは、I2CリアルタイマークロックRTC(DS3231)の動作テストである。このRTCはバッテリーバックアップがついているので、精度を調べるために大分前に正確な時刻を設定して放置してあった(4/1設定)。

 UARTをつないで、ESP8266に電源を入れる。現状のプログラムはUART上に5秒ごとに時刻を表示するようになっている。スマホや手持ちの電波時計の正確な時刻と見比べる。ふむふむ、なんと、殆ど誤差がない。こいつはすごい。

 このあいだ調べたデータシートのスペックによれば、月差で4秒近辺ということだが、今の時刻は2秒もずれていない。これまでに40数日間動いているのだ。多めだが2秒としてこれを365日12ヶ月で月差を換算すると1.2秒である。大したものである。08p6017503 まあ、最近はGPSが正確な時間をくれるようだが、こんなスタンドアロンのしかも廉価なチップがこの精度なのは偉い。この製品も、以前の超音波距離センサーと同様、オリジナルをコピーした中華製のようだが、こうした電子部品が普及することはアマチュアにとっては有り難いことである。

 長い目で見れば、先行開発にチャレンジする人(や会社)を減らすことになって産業全体では悪い影響を及ぼすのかもしれないが、ジェネリック薬品と同じような位置づけと考えれば、そう心配することもないのではないか(トップメーカーの囲い込みを防げる)と勝手な理屈をこねる。

AitendoでUSBプラグを買い、Tiny24で遊ぶ(5/11/2016)

 AVRのTiny13は安いし小さいので重宝している。しかし使えるI/Oピンとフラッシュサイズが少ないのが難点である。これまでのソフト資産を生かしたまま、ちょっと機能を拡張したくても次の適当な製品がない。

 Tiny85は、USIがつき、フラッシュも大きくなるが、なにせ8ピンなのでI/Oピンの制約は変わらない。といって、Tiny2313や、Tiny861は20ピンで急に大きくなりすぎる。データシートなどを調べると、このあいだには、14ピンの24/44シリーズがあるらしいが、日本の市場には出ていないと思っていた。

 それがAitendoのサイトを見ていたら、SOPのTiny24とTiny44が売られているのを発見した(Tiny24/44にはDIP版がない)。たまたまUSBのAタイプオスコネクター(ジャック)を探していて、いきつけの秋月や千石に気に入ったものがなくて、Aitendoで良さそうなものを見つけたところである。04p5127492

 ちょうど良い機会なので、久しぶりに直営ショップへでかけることにした。ここは秋葉原というより上野に近い。地下鉄日比谷線の仲御徒町の駅から歩いて5分かからない。おやあ、1階に店が見える。始め、全部がここへ移ったのか勘違いしたが、どうも狭すぎる。店員に聞いたら3Fにもあるという(ちょっと日本語が覚束ない女性店員が答えて)、そちらに回る。

 3Fのメインの売り場は前と同じ場所にあった。1Fの店はキット製品だけの売り場らしい。相変わらず結構な客の入りだ。膨大な品数だが、女性店員は的確に陳列場所に案内してくれる。Tiny24/44はすぐ見つかった。2つづつ買う。値段もリーズナブルだ(¥120と¥200)05p5217494

 帰ってきて、早速ブレッドボード上で使えるように、手持ちのSOPの変換基板を取り出したのだが、こいつが、やたらとごつく大きすぎる。長さが700mil(7ピン)なのは仕方がないが、幅は明らかに広すぎる(600mil)。20ピンの2313や、x61より大きく見えるのでは洒落にならない。

 というので、今までのテーマ(学習赤外線ユニット)そっちのけで、自分で変換基板を作り始めた。動きだした手が止まらない。切り出した汎用基板に耐熱絶縁シートを張って、その上に接着剤で表面実装チップを固定し、0.2ミリのUEW線で配線する。

07p5217501  前から憧れていたChaNさんの得意技である。作ってみると意外にしっかりしていて美しい。幅は、100milしか狭くならなかったが、完全な自己満足の世界である。興に乗って2つ(Tiny24と44)も作ってしまった。

赤外線LEDの制御にTiny24とFETを持ち出す(5/15/2016)
 前から考えているテーマはESP8266とスマホを使った赤外線リモコンの遠隔操作である。既成のリモコン信号を学習して、スマホから操作できる。いくつかの作例があり、ソースコードも公開されている。簡単にできそうだ。ESP8266の適当なアプリとして、部品も大分前に揃えてあった。

 しかし、部品を目の前にして、急に気分が変わった。このままブレッドボードに部品を差し、ソースをArduino IDEにコピペして動かすだけでは何か物足りない気がする。赤外線リモコンは、前に受信側は自作したが、送信側はまだ作ったことはない。

 ウェブの情報によれば、何やら送信用の赤外線LEDは、離れたところから動作させるには、1A近い電流量が必要になるらしい。マイコンのI/Oピンの最大電流は数十mAなので、当然なんらかのドライバーが必要になる。

 そういうことも含めて、すべてお仕着せのスペックで作るのが惜しくなった。ちょうどSOPのTiny24がブレッドボードで使えるように変換基板を作ったところだ。赤外線リモコンをこれで作りたくなった。

 赤外線LEDの送信側のハード制作は初めてで、それに慣れておこうという魂胆もある。トランジスターで動かしている例が多いが、ここは久しぶりにFETで制御してみることにした。改めてネットでFETのおさらいをする。1A程度のスイッチングなら手持ちの小さなFET (2SJ327)で十分だ。

 まずFETの点灯テストから始める。念のため、可視光線のLEDを並列につなぐ。受信側はセンサーの出力をオシロで確認する。点灯する。あれえ、反応がない。オシロを良く見ると、小さなパルスは入っている。

 念のため、エアコンや、電子ボリューム用の汎用リモコン(ソニー仕様)などを当ててみる。問題なく連続パルスが出ている。それなのに何故出ない? 暫くして、その理由がわかった。はっはっは、情けない話だが、サブキャリア―(35Khz前後)が必要なことをここで始めて理解した。

 だから「赤外線受信素子」ではなく、「赤外線受信モジュール」なのだ。サブキャリアーを発生させるしかけが必要である。まだ先の話だと思っていたが、あわててTiny24の変換基板をブレッドボードに載せ、35Khzのサブキャリアー発生装置を作り始めた(照れ隠しもある)。

 Tiny24/44のデータシートを改めて子細に眺める。タイマーや、ADコンバーターなどのペリフェラルは、殆どx61に近い装備で2313のようなUARTはついておらず、例のUSIが代わりにある。タイマー割り込みを使って、35Khz 1/3デューティのパルスを作る。

 特に迷うことなく、赤外線のサブキャリアー発生装置が完成した。早速、テストに入る。想定した周波数より少し低いが(30khz)パルスが出た。受信モジュールに向けてみる。問題なくタクトスイッチで入り切りする出力が、受信モジュールの変化と同期した。

 このあたりの赤外線リモコンのフォーマットについては、何といってもChaNさんのサイトが一番わかりやすくておすすめである。ただ、今度の学習リモコンは、各種のリモコンを汎用的に使いたいので、ここでの中身のフォーマットは関係ない。出来るだけ、原波形を忠実に再現することが重要だ。

SRAMが256バイトでは記録できない。いっそのことMega88にするか(5/23/2016)

 次は、赤外線データ列の記録である。赤外線パルス列の受信は、以前電子ボリュームの時に実装しているので、ソースコードをそっくり持ち込み、テストする。あっさり動いた。しかし、エアコンのデータ受信で頓挫した。

 エアコン(三菱)の送信データ列が多すぎて、Tiny24/44では入りきらないのである。配列が溢れて暴走する。データ蓄積を止めて回数だけで調べる。274イベントもあった。Tiny44のSRAMは256バイトでスタックを考えれば到底入らない。

 困った。何とかならないか。EEPROMにしまいながらとか、色々頭を捻ったが、最少で500μs単位で発生する赤外線データの蓄積を、ミリセカンドオーダーの記録装置でやろうということに、そもそも無理がある。

 最終ゴールはESP8266なので、テストベンチに凝るのも本末転倒である。潔く、換装を決意する。SRAMの大きさは、折角換装するなら1Kバイトくらいは欲しい。すると、Mega88あたりか。Tiny861では不足だろう。始め、Megaにするつもりでデータシートを見ていたが、861でもSRAMが512バイトあることを発見した。

 少し、迷ったが、Tinyシリーズの中の移植の方が、Megaシリーズへの移植より楽な気がして、SRAMの量に不安は残ったが、Tiny861に移すことにした(これが、えらいトラブルの元になるとはこの時点では露知らず)。

Tiny861の罠(わな) コンペアマッチとキャプチャー機能が排他的とは(5/25/2016)
 Tiny24/44とTinyx61のタイマーの構成はちょうど逆で、受信の時に使うインプットキャプチャー(邦版データシートでは、捕獲入力)機能は、Tiny24/44のタイマー1から、Tiny861のタイマー0に変わっている。

 それ以外は大きな違いはなく、順調に移植が終わった。コンパイルする。おやあ、インプットキャプチャーしたときの値を収容するICR0(Tiny24/44ではICR1)レジスターがヘッダーファイルにないので未定義エラーになる。

 何かおかしい。それと、通信のタイムアウト用に設定したタイマー0のコンペアマッチの割り込みルーチンが動いていないようだ。UARTで設定したOCR0Aレジスターの値を表示させてみると、0になっている(未定義エラーはとりあえずコメント化して回避)。

 暫く頭を抱えていた。データシートがどうも不審なのである。日本語版では、ICR0レジスターが存在するかのような説明(本項では捕獲入力レジスタはICR0と呼ばれますが、これは比較レジスタへの参照です)があるが、これでは何のことかわからない。

 念のため原文を引くと、Even though the Input Capture register is called ICR0 in this section, it is refering to the Output Compare Register(s).
で、どうもコンペアマッチレジスターが実体で、捕獲入力のレジスターは仮想的な感じだ。

 さらに、データシートを調べていって、決定的な表を見つけた。

表11-2. 動作種別(ページ48)

番号 ICEN0 TCW0 CTC0     動作種別 TOP値 OCR0x更新時 TOV0設定時
--------------------------------------------------------------
0    0   0    0  標準8ビット動作             $FF    即時  MAX($FF)
1      0       0        1    8ビット比較一致
                             タイマ/カウンタ解除(CTC)動作  OCR0A  即時   MAX($FF)
2       0      1        x    16ビット動作                    $FFFF    即時   MAX($FFFF)
3       1      0        x     8ビット捕獲入力動作        $FF       即時   MAX($FF)
4       1      1        x    16ビット捕獲入力動作        $FFFF   即時   MAX($FFFF)

 なんのことはない。これではっきりした。動作種別があって、もともとTinyx61のタイマー0は、インプットキャプチャーか、コンペアマッチにしかならないのだ。Tinyx61はTiny24/44に較べると古い設計のようで、インプットキャプチャー機能が独立していない。

 まあ、データシートを読み込まなかった自分が悪いのだけれど、何とも後味の悪い解決だ。データシートにちゃんと書いていない。OCR0Aレジスターは、インプットキャプチャーをenableにすると、コンペアマッチレジスターにならないのだ。

 いかにも両方出来るように書いてある。しかも、インプットキャプチャーのレジスター定義(ICR0)がデータシートにあるのに、ヘッダーファイルにない。混乱する。捕獲入力の値はOCR0AとOCR0Bレジスターに16ビット分が、TCNT0LとTCNT0Hから移されるというのオチである。

 インプットキャプチャーとコンペアマッチ機能は排他的だと、ひとこと書いてくれれば、何もここまで迷うことはなかったのにと八つ当たりである。いずれにしても、データシートのとおり、OCR0Aなどを使って、初期の目的は、Tiny861でもやっと実現した。274イベントのエアコン波形もめでたく記録された。

ロジアナの波形を頼りにプログラムの改修。至福の時(5/28/2016)
 めでたく全部のデータが記録されたので、中身の検証に入る。ここからは、オシロやUARTでは無理で、ロジアナの登板である。赤外線受信モジュールのふるまいは、正確にロジアナで捉えられている。

 それに加えて、マイコン内の割り込みルーチンや、データの処理部分にプローブ(GPIOピン)を設定し、調べ始める。20ピンのTiny861なので気楽に設定できる。

 うーむ、採集された値は、だいぶ原データと違う値だ。受信モジュールの割り込みから、本来のデータ収集をする時点がばらばらなので。誤差が大きい。これは、割り込み時点ではフラグをだすだけで処理をメインに持ってきているので、そのあいだに別の割り込みが入ったりして違ってくるのだろう。この方式では駄目だ。Ws000007

 これはやっぱり、割り込みルーチンの中で処理を全部済ませる必要がある。どうせなのでソースコードをつらつら眺め、コードの短縮化を図る。元のプログラムは律儀にピン(キャプチャーピン)の状態を忠実に調べてから、割り込みの区別(立下りか、立ち上がり)を換えているが、考えてみれば、これは必要ない(単にスイッチするだけで良い)。

 さらに、赤外線データのひとかたまりのデータの最初とそれ以降を区別するフラグを設けていたが、これも考えてみればいらない。最初につかんだデータは使わなければ良いだけだ。ただ、これによりタイムアウトだけが最後まで解決できなかった。データを受信したという印がなければタイムアウトを起こせない。 結局、このデータが来始めたことを知らせるフラグを復活させ、「データが来始めてタイムアウトするときだけ」真のタイムアウトとし、他のタイムアウトは無視するという逆転の発想で解決した。Ws000006

 こうして、割り込みプログラムの誤差はどんどん小さくなり、最終的には、当初200μs以上誤差のあったキャプチャーは、すべての遅れを5μsまで下げることが出来た。これは痛快だった。Arduinoを使っている限りでは、味わえない醍醐味である(シールドの設計者が独占している)。

 ロジアナの画面に、綺麗に揃ったパルス列を並べて至福の時を過ごす。UARTのデータもきっちり5%以下のAnalyz_remocon誤差で記録されている(0.33~0.31の範囲なので、2/32 = 6.25%)。あとは、この値に基づいて赤外線LEDを制御するだけである。紙数が増えてきたので、このあたりで報告しておこう。

Ws000004_2

 

| | コメント (0) | トラックバック (0)

2016年5月 9日 (月)

落穂ひろいの電子工作とRaspiの自動電源制御装置の改良

 Raspi3は簡単に動いた。しかし、もともと目的なしに衝動買いしたアイテムである。適当なアプリケーションはまだ思いつかない。画像処理は高速で、ネットサーフィンもそれほどストレスなく楽しめる。これをサブマシンのPCにしても良いのだが、今、特にそれが必要だということでもない。

 ということで、今まで懸案だったが、手をだしていなかった細々した周辺の工作やトラブルシューティングにいそしんでいた。そのうちひょんなことから新しいテーマが見つかり、連休はそれに夢中になっていた。この話はあとで詳しくするとして、その前のいくつかの作業についてご報告しておこう。

LM380革命アンプのケース入れ(4/15/2016)

 現在、当研究所のPCデスクには、4年前に作ったアナログオーディオチップLM380を使ったステレオアンプが、お菓子の空きプラケースに入って載っている。ケースのサイズが小さすぎ、スピーカー端子がはみ出してしまったため、未完成のままだ。

Dsc004420012  このあと作ったカナデンのデジタルアンプがちゃんとしたケースに入っているのに(といってもタカチの安物だが)比べると、少々扱いが雑で前から気にはなっていたが、そのままになっていた。 

 机の上に置いたままにしているのは、たまにスピーカーコードを切り替えて、こちらで聴くときがあるからだ。透明感のあるすっきりした音で、気分が乗らないときはこのアンプでバロック(それも初期)を聞くと、カマデンより疲れない気がする。

 このアンプは革命アンプと言われ、この制作記事は、今も当ブログで結構アクセスの多い記事のひとつだ。手が空いたので、折角だからこれをまともなケースに入れてやることにした。手を動かしていないと落ち着かない性分になっている。

 どんなケースにするのか、あれこれ迷ったが、結局、カマデンと同型(SW-125)のケースに落ち着いた。うーむ、創造力が落ちているなあ。まあ、形を統一するというのも環境を美しくみせるコツのひとつだと無理やり理屈をつける。

Dsc004210002  こんどは、カマデンのとき失敗した送風孔の位置を正確に開ける工夫をしてみよう。まず、1.2ミリ程度のドリルで下穴をあけ、錐やアートワークナイフで微調整する。そのあと2回くらいドリル穴を換えて所定の大きさ(3ミリ)にする。この結果、完全ではないが、前に較べれば格段に揃った穴があいた。

 基板の固定方法では苦労した。アンプ基板はケースのことを全く考えずにレイアウトしてあるので、可変抵抗器や、入力ジャックが外に出るようにしたら、ケースの側板と基板が干渉して、ケースがはまらなくなってしまった。

 本来なら基板の実装を変えるところだが、無精して、可変抵抗器の軸をパネルに固定することにした。こうすると今度は基板の固定が非常に難しくなる。正確に穴あけをしないと基板固定ポストの接着がすぐ外れるし、開け方を忘れて無理にはずそうとするとポストは簡単に破壊されてしまう。

Dsc004430013  基板の固定は、このままでは可変抵抗器の軸だけなので、フォンジャックを差し込むときはぐらぐらするし、いずれは可変抵抗器は壊れるだろう。どうしたら合理的な固定法があるか頭を捻った。

 色々考えた挙句、ケースには可変抵抗の軸だけで固定し、裏蓋をはめたあと、裏蓋から基板を釣る形で固定した。これでフォンジャックを差し込んでもぐらぐらしなくなった。

 こういう実装方法を考えるのは、実はとても楽しい。参考にする情報もないし基準もないので自己満足そのものだが、うまく行った時の快感はソフトでしつこいバグを見つけた時くらい大きいものがある。Dsc004260004

沢山の実用品の修理。腕時計の自動巻き機の修理にはまる(4/21/2016)
 これまで作った数多くの電子工作品が年を経て次々に故障を始めている。プリンターのLAN電源制御1号機がまた故障した。こいつはモジュラージャックの終端抵抗が内部で断線していることを、一年前、長い間かかってやっと突き止めたものだ。

 件(くだん)の抵抗器はリード線を強く押えたところ復帰したので横着して交換せず、そのまま動かしていたのだがやっぱり再発した。この交換は結構面倒なのでそのままになっている(プリンターの遠隔制御が必要なくなったこともある)。

 メトロノームの正確な時間間隔を測定するリズムキャプチャーも最近ノイズが出てうまく動かなくなった。電池を交換したが症状は変わらない。どうも電圧不足ではなさそうだ。今急にこれが必要ということもない(保有するメトロノームの補正は済んでいる)ので、これも手がついていない。

 そのうち、ここ4年近く毎日動いていた腕時計の自動巻き機もおかしくなった。ソフトパワースイッチを装備し、スイッチの長押しでスタート、さらに長押しでパワーが切れるようになっている。毎日、定期的に動かすため、昔FMのエアーチェックに使っていたタイマーで電源が入るようになっている。

 電源が入った時はソフトパワースイッチでなくても動くようにしてある。一日2回動かしているのだが、このところ時計の時刻が大幅に遅れることが多くなった。電源が入っても動かないときがあるようだ。

 試しに、タイマーではなく単に電源を入れてみる。ちゃんと動く。タイマーでスタートさせてみる。今度は動かない。ふーむ、接触不良か。重い腰を上げて、工作テーブルに持ち込みUARTを付けて様子を見た。すると問題なく動く。いつもの場所に戻す。動かない。何か馬鹿にされている感じだ。

 この装置のUARTはISPケーブルを使ったChaNさんのUARTを改良したものだ。どうもこいつを接続しているときはエラーが起きない。調べるうち現象がだんだん見えてきた。整理すると次のようになる。

Dsc004270005  パワーダウンモードでスリープしているときに電源が切られると、そのあと電源を入れても復帰しないことが多いということがわかった。タイマーがONになっている時間は、この装置の1セットの運転時間より長く、必ずパワーダウンモードでスリープに入る。UARTをつないでいるときは全くトラブルは起きない。

 これまで順調に動いていたのが何故こういう現象になるのかが謎である。接触不良ではない。片手間で調べられなくなった。すこし本腰を入れることにする。ISPケーブルがつながっているのは、MOSI、MISOなどのピンでこれらが全体に影響が出てくるとは考えにくい。あとは、VccとGNDそれにRSTだが、やはり、RST(リセットピン)が一番臭い。

 オシロに接続する。パワーダウンスリープに入ってもRSTはHighのままではある。ここまでは当然だ。しかし、電源コネクターをはずしても、RSTは下がらない。何と、これはどういうことだ。

 早速ウェブに助けを求める。スリープでは、すべてのピンの状態を保持すると書いてある。しかし、電源を切ってもRSTを含めたピンが続くとはどこにも書いていない。この電力はどこから来ている?わけがわからない。

 スリープでなく通常に動いているときに電源を切れば、すべてのピン(RSTを含めて)はあっさりLowレベルに落ちる。ところがスリープ状態では、電源をはずしても、信じられないことにRSTはHighのままなのだ。

AVRのパワーダウンスリープはVccまで保持される!(4/24/2016)
 あわててAVRのデータシートを見るが、そんなことはどこにも書いていない。I/Oピンが保持されるとはあるが、リセットピンまでがそうだとはどこにも書いていない。そのうち、もっと思いがけないことが分かった。そもそもVccが下がっていないのである。オシロを2現象にしてみて初めて分かった。

 確かに、このシステムには、モーターの突発的な駆動電流の影響を考慮して、Vccには100μFとインダクターのフィルターが入っているが、パワーダウンスリープでないときは、電源を切ると、一気にVccは下がるのに、パワーダウンスリープではなかなか下がらない。

 それではと、このコンデンサーを接続からはずしてみた。驚いたことに症状に変わりがない。パワーダウンモードでないときは一気に下がるし、ISPケーブルを差した場合はどちらも簡単に0にもどるのに、パワーダウンスリープ中での電源断では下がらないのだ。

 信じられない。とにかく、この影響でおかしくなっていることは明らかだ。Vccとリセットが0に戻らないので、再度電源を入れると、CPUは不安定な動きになる(暴走状態)。 

 試しに、10KΩでVccピンをシャントすると、あっさり落ちる。しかし、これではパワーダウンスリープ中も、この電流は流れ続け、なんのためのソフトパワースイッチかわからなくなる。なんとかならないか。

 しかもこの問題がなぜ顕在化せずにここまできたのかというのも謎である。少なくとも、ここ半年前までは、全く順調に動いていた。最初の長期動作テストでは、UARTを入れて調べているので、この問題がわからなかったのは当然だが、最近起きはじめたというのが、どうも解せない。

パワーダウンスリープ中の電源断は想定外のことなのか(4/28/2016)

 さらに、もっとおかしいことがわかった。パワーダウンスリープのとき、ACアダプターのジャックをはずして、再度、電源を入れ直すと正常に復帰することが多いのだが、ACアダプターをつけたまま、AC側で電源を切ると(現行タイマーの使用状態)、ほぼ確実にAVRはハングアップする。これは一体どういうことか。

 不思議なことに、ISPケーブルをつけたままでは、この症状は起きない。オシロで見ている限りでは、Vcc、RSTピンの電圧は、2分もすれば、0Vまで低下している。タイマー運転は1日に2回だけ。パワーオンリセットには十分な低電位だと思うのだが、ハングアップが起きているようだ。

 それにしても、経年変化でこういうことが起きている。パワーダウンスリープにしたまま電源を切ってしまうと、どういう動作になるかというのは、調べた限りウェブ上に情報は見つからなかった。

 確かに、ソフトパワースイッチの前提は電池駆動で電源は常時ONであることが前提だ。OFFになることは想定していない。従って、ここでの追及はどうも、CPU内部の話に行き着きそうで、余り深く詮索することは無理なような感じがしてきた。

 完全に暗礁に乗り上げた。こればっかりやっているわけにも行かない、移りたい次のテーマが見つかっている。残念だが、これは少し棚上げにしよう(少し閃いていることがあるが)。

Raspiの電源制御装置2号機の準備(5/1/2016)
 Raspi3周辺でやりたいことが見つかっている。それは以前、初代のRasPiで作った電源制御装置である。スイッチを押すだけで電源が入り、shutdownすると電流量の減少を検知してリレーで電源を切る。一般のPC と同じ操作イメージである。

Dsc004300008  ただ、問題なのは以前のプログラムではshutdown時の電流量が決めうちなので、ペリフェラルをつないだりすると(例えばHDD)、うまくshutdownと認識してくれない。個別にコンパイルし直さなければならない。これを何とかしたい。これが汎用化されれば使いみちはぐっと広がる。

 初代のRaspiに較べ、RasPi3は2.5Aが最大電流なので、前の2Aのリレーでは不安である。もう一台作ることにする。部品箱から手持ちのリレーを探す。たまたまあった3Aは少し大きく、これまでのケースには入らない。

 今度はUSBソケットを入れる予定だが、手持ちの少し大きいケース(タカチSW55)では何か間抜けな感じだ。ということで久しぶりに秋葉原に行って部品を調達することにした。

久しぶりのAVRの開発とケース工作にはまる(5/3/2016)
 連休中の秋月は大混雑していた、RasPi3が店頭に平積みで山のように並んでいた。値段は前と同じ¥6200で、どこよりも安い。早まってよそで買ってしまったことを少し後悔する。

 それはともかく秋月で見つけた3Aのリレーは前と同じ大きさで、余り小型化に寄与しない。諦めきれずに千石本店の2Fに行く。さすが千石だ。沢山のリレーがあった。値段は、秋月の4倍以上するが、スイッチング最大電流は2Aで最大通電電流3Aの国産オムロンのものが見つかった。

Dsc004290006  しかも、こちらの方が格段に小さい。これだけ小さくなれば、USBソケットを入れても前と同じケースに入るかもしれない。4倍といっても単価は¥400台だ。迷わず買い込んだ。リレーがこんなに高くても、この装置の部品代の総額は¥1000以下で押えられるはずだ。

 ただ、本当にこれまでのケースに入るか心配なので、これまでの小さいもの(タカチSW-40)に加えて、これより少し大きく、今までのものより小さいSW-50というのも念のため買っておいた(¥120)。

 帰ってきて部品合わせをしてみると、これが大正解だった。今度の装置はUSBのAタイプのジャックを入れることにしたのでSW-40はとても入らない。SW-40の1.5倍の大きさのこのSW-50がぴったりだった。

  小さなケースの工作は久しぶりである。楽しい。アートワークを念入りにやる。この前のときは、しっかり誤配線をした。ピンとピンの間隔が少ししかないので間違いやすい。回路図は前と全く同じにする(ソフトをこの前の無印Raspi用と共用したいため)。

 ケースの固定でまた遊ぶ。この前のものは2.6ミリの小さな固定ネジを4つも使っていたが、今度は裏蓋は単に蓋にするだけで、ケース上蓋に全てを実装することにした。

 考えているだけでは、先に進まないので、基板を切りだして、実際にソケットやプッシュスイッチを仮止めして、ケースと現物合わせをしながら入るかどうか試してみる。対象が小さいので自由度が極度に制限されるが、これが楽しみの要因になっている。箱庭、盆栽と同じような気分である。

Dsc004330007  ケースに少しづつ穴をあけ、部品がうまく入るか何度も調整を重ねて先に進める。USBソケットが出る穴を少し大きめに広げると、ちょっと見栄えが悪くなるが、きれいに入ることが分かった。ケースはABS樹脂なので加工が容易なのが助かる。

配線は間違っていなかったがTiny13を2回も逆ざし、一個失う(5/5/2016)
  ハードの実装は見通しがついた。次はソフトの方である。大分前から考えている(ソフト開発は紙と鉛筆さえあれば、いつどこでも出来る)。ターゲットはTiny13なので沢山ロジックは詰め込めないが、通電中の電流値をEEPROMに蓄積し、これが1/3や、1/2になったときshutdownと判定するロジックで良いはずだ。ただ、1KB以内に収めたい。Tiny85でも良いが少し勿体ない。

 最終的に決まったロジックは以下の通りである。EEPROMは使う必要がなかった。まず、Raspiの消費電流をシステムが立ち上がった一定の時間の後から計測を始め、この平均値から一定量以下の電流値をシャットダウン時の電流とみなして、この値で待機する。

 このロジックの根拠は、沢山のペリフェラルがあっても、シャットダウンのときとアクティブなときの間の電流差は一定という考え方に基づいている。比率でシャットダウン電流を推測するより汎用性があるはずだ。

 擬似コードでは、簡単に「一定時間待ったあと電流の平均値をとる」と書いたが、実際のコーディングはどうしたら良いのだろう。 プログラムは考えたようには動かない、書いた通りにしか動かない。まあ、あまり深刻に考えてみても仕方がない。コーディングしてみよう。

 書き始めると思ったより簡単に実現できた。もともとこのシステムは電源を入れた後、定期的(0.5秒毎)にADコンバーターを動かして電流値を測定している。この回数を記録しておいて、一定の期間の電流値をしまっておくだけである。それまでは、強制終了以外の電源断は行わない。途中で止めれば、最初からやり直すだけである。

Dsc004350010  さあ、出来た。考えたようにコンピューターは動いてくれるのか、ドキドキの瞬間である。

無印Raspiの2機とRaspi3で完動(5/7/2016)

 始めは、慎重にセメント抵抗を負荷にしてテストを始める。おやあ、頼りのUARTが出ない。同じ配線なのに、おかしい、何か虫が知らせたので、すぐ電源を切り、部品を触る。アッチッチ、CPUがやけどしそうに熱い。これはいけない誤配線だ。

 8ピンのCPUの配線を前回に続いて間違えるとは情けない。基板を裏返して最初から配線チェックをする。間違っていない。うーむ、どうしてだ。まさか、CPUを逆差ししているのでは、はい、逆になっていました

 あの熱さでは、息が絶えているか心配だったが、幸い、Tiny13はけなげに生き返ってレスポンスを返し、ファームの書き込みも無事に終わった。祈る気持ちで再度電源ON。よーし、ボタンを押すと、SCKを使ったUARTからメッセージが出て、1秒ごとの電流値を表示し始めた。(実はこのあと実装でまた逆差しし、ひとつをお釈迦にしたことは秘密)。

Dsc004390011  秋月でついでに面白がって買ってあったUSBメーター(積算値つき)をつけて、本番のRaspi3に接続する。1分後から計測を始める。30秒の平均値を出し、それより200mA低い場合はshutdownとみなすロジックにした。USBメーターは0.27Aを示し、shutdown時は0.04Aなので、これでぴったりマシンの電源が切れた。

 次は問題のSAMBAサーバーにしている無印Raspiのテストである。このRaspiにはハブ経由で2.5インチHDDがついている。HDDだけで0.2Aは常時流れる。最初作った電源制御装置は、この待機電流にそなえるため、コンパイルしなおして初期値を設定した。

 新しい制御装置に切り替えて、つまりRaspi3の設定のままで、テストする。何事もなく立ち上がった。shutdownである。こいつは、GPIOピンを見てshutdownコマンドを送る機能がついているので、所定のスイッチを長押しする。LEDの点滅が激しくなり、shutdown処理に入った。

 少し長い間、高負荷の電流が流れた後、「チッ」と小さな音がして、無事電源は切れた。よーし、それでは、もうひとつの無印Raspiはどうだ。こいつは今動かしていないが、ウェブカメラのサーバーになっている。

 こいつも問題なく、スイッチひと押しで電源ON、shutdownコマンドで電源OFFが実現した。うーむ、今度は売り物になるかもしれないな。今までのものは機械にあわせてコンパイルしなおす手間が必要だったので、みんなに使ってもらうことを躊躇っていたのだが、これなら問題ない。

こちらにTiny13による電源制御装置2号機のソース一式をAtmelStudio7のフォルダーの形でzipにかためたものを置きます。回路図は前の1号機と全く同じで、ソフトは共用できます。

「AutoPwr13a.zip」をダウンロード


| | コメント (2) | トラックバック (0)

2016年4月11日 (月)

ESP8266の冒険(3)は一段落。Raspberry Pi 3に手を出す

ESP8266モジュールのWiFi接続のキャンセルには成功(3/20/2016)
 安価なWiFiモジュールであるESP8266で色々遊んできた。その結果だが、こいつはブラウザーなどの重いネットワークの仕事はさすがにちょっと無理なことがわかった。深く解析したわけではないが、デフォルトの状態では画像の表示や中継転送速度は話にならないくらい遅い(前記事参照)。

 32ビットのCPUなので期待していたのだが、CPUクロックが80Mhz程度ではやはり力不足のようだ。リモートセンサーの数値データの送信や、リモート機器の制御などに使うのが無難だ。ただこちらとして問題なのは、このなかに、作りたいと思うアプリケーションが見つからないことである。02p1257479

 温度・湿度センサーに今のRTC(リアルタイマークロック)のデータを足してサーバーに送る携帯型の温湿度ロガーあたりが、差し当たっての有力候補なのだけれど、これをすぐ作ってみようという気分にどうもならない。

 当研究所のモットーは「実用に役に立つものを作る」ことである。なるべく「作りました、動きました、おわり。」というのは避けるようにしている。目的がないときは強引に目的を作る。これはなぜかというと、目的のない機械(しかけ)は制作努力を何にかけるかの焦点がぼけるため、圧倒的に開発効率が悪い。作った後の達成感にも欠ける。

 その意味で、温・湿度ロガーは目的ではある。しかし、無理に目的を作った感じなので、どうしてもその気になれない。とはいえ、折角、新しい世界であるESP8266(というかArduino環境)に慣れてきたのだから、もう少し付き合ってやろうと、これまで気になっていた細かい課題を解決することにした。

 それは、立ち上がりのときのUARTモニターのゴミ(字化け)と、バックグラウンドで自動的に動きだすWiFi接続のメッセージである。双方ともUARTを使わない限り何の支障もないし、無視してしまえば良いのだが、UARTを出力画面にしているときは何となく目障りだ。

 リセット直後のUART開始メッセージのゴミは、ESP8266のROMモニターが出している。ボーレートが74800bpsという中途半端な値なために字が化ける。調べたところでは、ユーザープログラムで、これを制御することは出来ないようだ。

 もうひとつのWiFiが勝手に立ち上がる問題である。これは、Arduino IDE環境におけるプログラム開発特有の問題だと思うが、LED点滅のような簡単なプログラムでも、必ず背後でWiFiが動きだし、WiFiの開始メッセージがUARTに出てくる。

Esp8266rtc  ウェブを探すと、WiFiをステーションモードにすれば、これが止められるという情報が見つかった。早速これを試してみた。しかし、ステーションモードにしても( WiFi.mode(WIFI_STA);)、止めることは出来なかった。

 出来ないとなると、余計気になるというのが当研究所の所長の性分である。さらにしつこく、あれこれサイトを探索する。すると、開発ライブラリーキット(SDK Sytem Developpment Kit)に、色々なモードを設定するAPIを見つけた。

 ここには必ずWiFiを制御するAPI(関数)があるはずだ。しかし一通り調べたが、見つけることは出来なかった。そもそも、このSDKは良くわからないところがある。実ライブラリーの所在がArduino IDEの中で不明である(バイナリーをどこにリンクする?)。サンプルソースには、このincludeステートメント(#include "user_interface.h")が入っているだけである。これだけでSDKのAPIが動くのか。

 半信半疑でテストしてみた。なんと、簡単にSDKバージョンを示す関数が動いた。しかし動かない関数もある(os_printfなどは動かない)。何やら問題としては奥深い、キーワードを頼りに、さまざま資料を探し回るが糸口が見えない。オープンソースという割には、情報がネットで不足している。

 良い加減飽きてきて、別のことをやっているうち、偶然、SDKの関数群の中に見つけた。何ということはない、その名もずばり、Wifi_station_disconnect()という関数があるではないか。今までの俺の目は節穴だったのか。

Ws000002  早速、これを持ってきてテストしてみた。ビンゴ!であった。見事にWiFiが止まって、無用な接続メッセージが止まった。久しぶりの達成感に幸せになる(安い娯楽だ。この項4/1/2016)。

RTCは恐ろしく正確だった(3/25/2016)
 ESP8266につけたRTC(リアルタイマークロック)のテストを続けている。これまでのところ、このI2CでつないだRTC(DS3231)の精度は極めて高い。3日連続で、1秒(0.5秒以下)行かない。このままでいくと月差は数秒と市販のクオーツ時計並みの正確さになる。

 遅ればせながらDS3231のスペックで確かめる。スペックによれば、±2 ppm(0~40℃)ということである。月差を調べてみる。1か月は、24 * 365 * 60 * 60 / 12(秒)なので、2,628,000秒。2ppmとはこの50万分の一で5.256秒となる。実機はこれを上回りそうだ。

 当初はESP8266の実用的なアプリケーションとして、このI2CのRTCに同じようなI2Cの温湿度センサーを加え、可搬型の温湿度ロガーを作ることを考えていた。好きなところに放り出しておけば、勝手にデータを記録し、蓄積する。定期的にネットに接続して送信する。

 どうせならウェブでグラフを出したい。データの蓄積は、ESP8266のフラッシュで十分か、省電力設計をどうするか、ウェブサイトにあるように何かIOT用の中継サーバーを利用するのか。あれこれ迷う。なかなか仕様が決まらない。これを作ってESP8266をそろそろおしまいにしたいのだが、いつまでも決まらない。

 そのうち赤外線のコードを記憶して再生するプロジェクトを見つけた。スマホを入力端末にして、赤外線リモコン(エアコン)を簡単に、ネットを通して遠隔操作が出来る。おお、これなら、温湿度ロガーより実用的だ。寝室のエアコンを居間から制御できる。

 仕様の決まらない温湿度ロガーは棚上げにして、このスマホを端末にしたリモコンの遠隔操縦をESP8266の卒業制作にすることにした。実は他のプロジェクトが待っている。最近、秋月でも売り出したRaspberry Pi 3である。

無線(WiFi)ルーターにはまる(3/27/2016)
 その前に、別の騒ぎを1つ紹介しておこう。ESP8266を本格的に運用するために、我が家のWiFi環境を整備しようと、手頃な無線ルーターを増設することにした。

 これが、めたらやたら設定の難しい無線ルーターにあたったのである。恐らくどのメーカーでも同じと思うので公平を期すため、ここではメーカーの名前は出さない。まともにつなぐのに2日以上かかった。 Dsc004150001_2

 現在、我が家のメインの無線ルーターは地下室と1Fをつなぐオープンスペースに設置され、1F居間と、地下のPCルームをカバーしている。このままでは、2Fが不感地帯となり、ESP8266を実用的に2Fのエアコンのリモコンにすることができない。

 従って、無線ルーターを1Fに上げ(こうすると2Fはカバーする)、地下は中継ルーターにすれば全域がカバーできる。ついでに1Fトイレのような難接続地域も解消できる。

 どうせ組み込み機器は最新のプロトコルはサポートしていないので高いものを買う必要はない。量販店で在庫切れになる寸前のルーターを探した。大体最大で600Mbps程度のものを選ぶ。値段も定価の半額以下の¥3000台で手に入る。

 設定を難しくしたのは、一般的なルーター設定ではなく、アクセスポイントとして使っている無線ルーターの中継(リピーター)機能の設定だったので、余計難しかったのかもしれない。

 始めは、単なる中継機能なので、簡単に設定できると思ったのだが、説明が少なく難航した。設定自体も、いくつもの手法があるのが、そもそもの混乱のもとなのだが、その内容が説明書だけでなく、ネット上の解説でも少しづつ違うのが問題だ。

 会社のサイトの情報は豊富なのだが、これがことごとくその解説どおりに動かないのである。説明されている画面が実際の画面と少しづつ違う。類推を利かせながら先に進むが、たいていはどの手順でも途中でエラーになってしまう。

 メーカーとしては何とかお手伝いしたいという誠意は感じるのだが(情報は多い)、どうしても先に進めない。特にやろうしていることが通常のルーター機能ではなく、中継(リピーター)機能なので余計混乱する。

 Netブック(WiFi機能あり)、メインのPC(WiFi機能なし)、スマホの3台を総動員し、だましだまし工場出荷リセットを10回近く繰り返してやっとのことで成功した。

 成功したと言ってもリピート機能は確認が難しい。SSIDが同じになってしまうからだ。正常に動いているように見えるが、新設した中継ルーターの電源を切っても通信速度が変わらなかったり、どうもおかしい。

 しかも、設定しようとした2.4Ghz帯(802.11/g)の中継がどうしてもうまく行かず、5GHz(802.11/a)にしかつながらない(リピート機能は単一バンド単位しか効かない)。5Ghzは自宅では速度は早いのだが、感度不足で、問題の地下や1F洗面所などの難接続地帯を解消できない。

 最後は少し離れた場所からのスマホでの設定で、やっと2.4GHz帯のリピート機能に成功した。偶然、スマホが2.4GHz帯のSSIDを発見した。何故、スマホでの接続に成功したのはわからない。まあ、動いたのだから、そっとしておこう。

RaspberryPi 3を衝動買い。OSのダウンロードに2時間以上かかる(4/1/2016)
 RaspberryPi 3である(以降RasPi3)。このブログを振り返るとRaspberryPiにはまっていたのは、もう3年前のことである。こいつにウェブカメラをつけたときの記事は今でもアクセス上位を占める当ブログの人気ページでもある。

 あれからRaspi 2というのが出たが、これは導入せず、IntelEdisonにした。今度のRaspi3は、飛躍的に性能の上がったRaspi2に較べれば、1.5倍の性能比だが、初代からは10倍もあるという。何しろクロック1.2GHzのQuad CPUなのだ。

 それに、WiFiやBlueToothも実装済みである。WiFiは技適が心配だが、ウェブ情報によれば、これもクリアし、先ほど秋月電子でも販売を開始したというニュースが飛び込んだ(即、売り切れたそうで、現在も在庫切れ)。

 ESP8266の冒険も一段落したので、目的もないのだが急に欲しくなった。どれだけ性能が上がったのが自分の目で確かめたい。売り切れと聞くとなおのこと物欲を刺激する。大所の店は売り切れのようだが、最近は、アマゾンなどの通販でも電子部品を手に入れることができる。

「Raspi3 販売」で検索すると、沢山ヒットした。秋月より少し高いがいくつものショップが売り出している。WiFiの技適が通っているのか一抹の心配はあったが、アマゾンが一番安かった(¥6458)ので、早速ポチッとしてしまった。

 数日後アマゾンからRaspi3が早くも届いた。心配していたが、技適マークがちゃんとついた正規品だった。

Dsc004170001 Raspiのインストールの案内はウェブサイトに山のようにあるが、意外にRaspi3のものは少ない。でもソフト的には2と全く同じだというので、サイトの情報を頼りに、手始めにOS(Raspbian)のイメージのダウンロードを気楽に始めた。しかし、これがえらい時間がかかったのである。

 総量は1.5GBだから大したことはないのだが、先方のサーバーが遅い。午前0時ごろから気楽に始めて終われなくなってしまった。次の日は出勤日なので、早く寝ないといけないのだが、こういう時に限って止められない。せまい道で電信柱とすれ違うときに何故か対抗車が来る感じである。

 結局、2時間以上かかって、やっとのことでイメージファイルのzipがとれた。これを解凍すると4GB近いイメージファイルが出来る。メインPCで、マイクロSDカードにコピーする。

Raspi3の描画能力は素晴らしい(4/8/2016)
 SDカードへの書き込みは、次の日だったが、4G近いサイズのイメージのコピーは結構時間がかかった。といってもダウンロードに較べればあっと言う間に終わる。ソフトの準備はあっけない。これだけである。次はハードだ。

Dsc004100001_2 初代のRaspiで使ったHDMIケーブルや、ワイヤレスキーボードをつなぎ、電源は手製のUSB AタイプコネクターとDCジャックの変換基板に秋月の5V 3AのACアダプターをつなぐ。

 メインPCのディスプレイを借りてスタートする。立ち上げる。おおお、出た!いやあ、早い早い。ブートメッセージが矢のように流れる。4CPUなのでラズベリーのアイコンが4つでるところがご愛嬌である。Dsc004130004_2 何事もなくデスクトップが立ち上がった。色々な整備を始める。日本語を設定して、立ち上げ直したら、デスクトップが豆腐のような盛大な文字化けで先に進めない。いけない日本語フォントが入っていないではないか。localeを戻そうとするが、どうもうまくいかない。

 誰もがやる失敗のようで、ウェブ上には回避策が沢山出ている。いずれも面倒なので、SDカードにイメージファイルを焼き直し、最初からやり直した。これが一番楽だ。raspi-configで初期設定をしたら再起動する前に、必ずapt-getで日本語フォントをインストールする。フォントのインストール方法もウェブサイトにちゃんと出ている。Dsc004110002_2

 ブラウザーは特別な軽いもの(Epiphany)が入っているようだ。日本語フォントが少し気に入らないが、ブラウザーも問題なくスムーズに動く。いやあ、初代のRaspiに較べれば雲泥の差だ。そりゃ、CPUの数が4倍、クロックもほぼ倍近くになっている。早いのは当たり前だ。下手をすると今のNetブックより早いかも。

Dsc004120003  殆どストレスなしに大きな画面(1920X1080)を制御できている。FireFoxもいれてみる(RaspbianではIceWeaselという名になっている)。これはさすがに心持ち遅い感じだ。しかし、これはサブマシンとして十分使える早さだ。音もすんなり出る。進歩の激しさに眩暈がする。

Dsc004160001_2  ワイヤレスキーボードでは前回同様、又少し手こずった。電池が完全に抜けていた。そりゃそうだ3年も放置しておけば待機電流だけで抜けるのは当たり前か。頭に来たので、久しぶりの基板工作とばかり、このキーボードにスライドスイッチを取り付けることにした。結果は、こんなもの。あまり褒められる品質ではないが、まあ、工作欲を満たすことはできた。

 さて、これで何をするのか。やれやれ、何か、前にもこんなことがあったような。誰かが言っていたが、結局電子工作って、作ることが楽しみなのだろうな。

| | コメント (0) | トラックバック (0)

2016年3月16日 (水)

ESP8266の冒険は続く(2) SDカードブラウザーやRTCで遊ぶ

 このブログは2ヶ月近いご無沙汰である。実は6年ぶりに海外旅行に出かけて電子工作をお休みしていた。旅行は70才以上の方々とスキーを楽しむツアーである。場所は念願のスイスのツエルマット。スイスからイタリアまでスキーで滑り込める。結論から言えば、猛烈に楽しかったが疲れた。

 4日以上連続してスキーするのは日本でも20代の学生の時以来始めてである。疲れるのは当たり前と言えば当たり前のことだが、帰ってきてすぐ風邪を引いて熱を出し寝込んだくらい疲れた。でも、昔からいつかは行きたい行きたいと願っていた所だったので、今は深い満足感がある。

Dsc001000001 そんなことで、電子工作は、半かけのまま放置されていた。体調が戻って、やりかけていたプログラム開発を細々と再開した。ESP8266のRTC(リアルタイマークロック)である。想定通り動き始めたので、ブログに報告することにする。

 この趣味を止める気はない。ここ10年の楽しみだったので未使用の在庫部品が相当溜まっている。今止めればすべてが無駄になる。とても止めるわけにはいかない(笑)。ということで、電子工作の話は少し古くなってしまったが、以下から順を追って報告する。

SDカードの不具合は前にも経験したお粗末エラー(1/28/2016)
 前回のテーマはWiFiモジュールのESP8266でフラッシュメモリに仮想ファイルを作り、画像付きのウェブサーバーを動かすことで、これはうまくいった。ESP8266のArduinoスケッチライブラリーには、SDカードのサポートがある。勢いに乗って、こいつも試してみたが、さすがにSDカードはすぐには動かなかった。

Dsc003850003 ブログに書いた後、本腰を入れてSDカードを動かす作業に入る、色々試したが、がんとしてSDカードは言うことを聞いてくれない。Arduinoのプログラムは動くときはあっと言う間だが、動かないとなると何をいじって行けば良いのか全く見当がつかなくなる。良くも悪くも情報隠蔽がうまく行われているので手がかりがつかめない。

 散々苦労した挙句、動かすことには成功したのだが、何のことはない、原因は昔のドジなミスの再現であった。トラブルシューティングとは、こんなものである。自分を責めてみても仕方がない。苦笑いするだけである。

 使っているハードのSDカードアダプターは、電子工作を始めた8年前、ルネサスの16ビットCPUボードH8/3069FやAVRのMega128などで、汎用的に動かすことを目的に作ったものである。リセットなどがソフトでできるようにするため、電源をFETで切れるようになっている。

 電源ONは、FETからの制御線をGNDに落とさなければならないのだが、これを完全に忘れていて、端子が浮いたまま(未配線)動かそうとしてエラーを起こしていた。確か、このミスは、H8/3069Fのときも全く同じ状況だったはずだ。要は電源が入っていない状態で動かそうとしていたことになる。

 究明のきっかけは、動作中の入念な電圧測定である。このFETスイッチは前のトラブルのあと、バイパスしてあるものだとばかり思いこんでいた。電源電圧がかかっていることを確認し、そうだとばかり勘違いしていた。このときの電圧測定が不十分だったのである。

 どうしても動かないので、もう一度、各部の電圧を念入りに測り直した。すると、規定より少し電圧が低いことが分かった。3Vであるべきところが、2.5Vしかない。ふーむ、これはおかしい。どこにも熱を持っているところはない。過大電流で下がっているのではない。

 それなのに、どうしてこんなに低い?色々調べるうち、このFETスイッチがOFFになっていることを突き止めた。で、どうして2.5Vが上がる。犯人は、ESP8266からのChipSelectの結線であった。これによって電源がOFF(ハイサイドで)でも、制御線を通して機器側に回り込んで電源電圧をあげてしまう。

 ちょうどAVRで電源を切っても、USB-UARTのプルアップされたRX(受信)から電流が本体に流れ込んで、PowerOnResetが出来なくなる現象と同じである。SDカードアダプターの制御線をしっかりGNDに落とし、SDカードが正常に動いたことは言うまでもない。

 やれやれ、解決したのは良いが、前のH8/3069Fのときも制御線をGNDに落とすのを忘れ、半年近くSDカードが動かない事件を起こしている。これとそっくり同じミスをするとは。年は取るものではない。

SDカードのウェブファイラー動く。しかし、実用には耐えなさそう(1/30/2016)
 SDカードが動いたので、その応用であるSDカードの中身をウェブから見られるウェブファイラーの実験に入る。使ったソースは、ここから頂いた。大したソース量ではないので、コピペ一発でスケッチを作り、動かしてみる。

Esp8266_sdcard  ビルドはNO ERRORだったが、実際の動作は、HTMLのエラーでまともに動かない。WiFiやサーバーの起動部分は正常に動いているようだ。用意されたSdrootというフォルダーの中のindex.htmlを読むが、どうもこのファイルではファイラーになっていないような気がする。

 GitHubの該当のディレクトリを見ていたら、Sdrootの下にさらにeditというサブディレクトリの中に別のindex.htmlがあった。中を見ると、どうもこちらの方が最新のようだ。試しに前のindex.htmlファイルと交換してみた。

 あてずっぽうだったが、見事にこれが当たりだった。ちゃんとブラウザーの画面にSDカードのファイル一覧が表示された。いやあ、たいしたものだ。スケッチソースを調べると、jpegファイルなどが画面に直接表示できるようである。 

 早速やってみた。出た。うーむ、出ることはでたが、目茶目茶遅い。以前のH8/3069F程度の遅さだ。測ってみたら、4KB/秒もかかっていた。SDカードの読み込みが遅いのか、ESP8266の中のスループットが低いのか今のところはわからない。しかし、これでは実用的にこのSDカードファイラーを使うのは殆ど無理だ。

Esp8266sdfiler  なるほどね。これが、ESP8266で画像の話題が出て来ない理由のようだ。なぜこんなに遅いんだろう。writeブロックが、1460バイト程度(HTTP_DOWNLOAD_UNIT_SIZE)では、こんなものなのかなあ。

 今のところ差し迫ったファイラーへのニーズがないので、追及に力が入らない。SDカードの実験はどうも先に進みそうにない。ESP8266への情熱が急速に冷めて行く。

ESP8266のアクセスポイント(AP)モードも超遅い(2/2/2016)
 長い間買うのを我慢していた、スマホ(iPhone 6s)を遂に導入した。海外旅行に向けて色々準備していることの一環だ。料金プランは月々の通話料を抑えるため端末を買い取ったが、長い間、単一ガラケーの所有者だったので、ポイントがかなり貯まっていて、思ったより安く手に入れることが出来た。それでも6万を超す出費だ。

 海外では4Gは通らないが、WiFiなら海外でも使えるルーターがレンタルできる。例えばスイスなら、swisscomというプロバイダーと契約したルーターが一日¥1000前後で借りられる。レンタルを申し込んで旅行に備える。

 自宅でWiFiのテストしていたときである。トイレに持ち込んでアクセスしたら、なんとここだけ我が家のWiFiが通らない。こういうときのESP8266である。こいつのWiFiモードには中継をするAP(アクセスポイント)モードというのがあると聞いている。早速試してみた。

 作業はとても簡単で、ATモードのとき以下のコマンドを入れるだけである。何でもない2ステップだ。動いたようだ。スマホにはちゃんとアクセスポイントとしてESP8266が表示される。
AT+CWMODE=2                     動作をアクセスポイント(AP)モードのみにする
AT+CWSAP="ssid","pass", chn, ecn 
ssid(id名)
pass(パスワード) 
chn(チャンネルID、1でよい)
ecn(エンコード 1= WEP, 2 WPA_PSK, 3 WPA2_PSK, 4 WPA_WPA2_PSK)

 いやいや、簡単なものである。繋いでみた。繋がることはつながった。しかし、残念。とても遅い。メールくらいならともかく、音声、画像は全く無理といってよい。

 WiFiの物理層のスループットがそもそも大きくないのか、組み込まれた32bitプロセッサーが遅いのか、それとも何か他に原因があるのかどうかはわからない。pingが1ms以上かかっていることから考えると、プロセッサーの論理層の処理が余り早くないのかもしれない。

 少し、ウェブで探してみたが、このあたりに言及するサイトは見つけられなかった。いずれにしても、ESP8266のWiFi中継は、デフォルトで動かす限り実用には程遠いレベルであることだけはわかった。そりゃそうだよね。¥500少々では無理な話だ。

ESP8266にI2C機器(DS3231)をつなぐ(2/8/2016)
 今度は、リアルタイマークロック(RTC)である。これもウェブあたりで沢山紹介されているI2CのRTC(DS3231)をアマゾンで手に入れた。このチップは、Arduinoで簡単に動くようである。I2Cなので結線もわずかである。これもあっけなく動いた。 

Dsc003890001  I2Cの部分はそっくり、人さまのソースを参考にしたのでこれに関しては、全く経験値は上がらない。手持無沙汰なので、Arduinoのコーディングの勉強を兼ねて、UARTで時刻の初期設定をするルーチンを組み込むことにした。

 簡単に行くと思ったがこれが難儀したのである。このArduinoの言語仕様がいまひとつ理解できていない。C++だというが、とても簡単なところでコンパイルエラーになる。それは、文字配列をストリング型に移すステートメントで言う事を聞かない。

 char buf[32];

として、新しいStringクラスのインスタンスstrに入れようと

   String str = new String(buf);

とするが、

error: conversion from 'String*' to non-scalar type 'String' requested

というエラーになる。どうもおかしい。Arduinoでは、newという命令が違う意味に使われているようなのだが、このあたりを解説するウェブサイトが見つからない。結局、このステートメントをあきらめ、最初からstring型で受信バッファーを作って、ごまかした。

 それに、Arduino IDEに付属しているシリアルモニターと、TeraTermなどのPCコンソールとは入力の状況がかなり違う。どちらも快調に動くしかけがなかなか作れない。これも、何とかArduinoの方に合わせ、初期入力が出来るところまで行った。

Dsc003860002  やっとのことでRTCの時刻設定が動き始めた。アマゾンで買ったこのDS3231基板には、時刻保持のためのボタン電池のフォルダーが裏に用意されている。良くわからないがボタン電池を入れて動かしてみた。電源を切って暫くしてもう一度電源を入れ直す。

 問題なく正しい時刻を表示した。これで当面RTCも動いた。 しかし、繰り返しになるが、どうも経験値が上がってこない。Arduinoの開発というのはこんなものなのだろうか。よく言われる諺の「靴を隔てて足を掻く(隔靴搔痒)」感が否めない。

あいついで新ディバイスの導入(2/15/2016)
 海外旅行のため、スマホに続いて思い切ってカメラも刷新した。ほぼ10年ぶりの更新である。撮像素子がほどほど大きく(APS-C)、軽量のミラーレスをチョイスした(Sony α6000)。これまでのデジタル一眼レフ(オリンパスE510)に較べれば、遥かに軽いうえに高性能である。

Sony_a6000  ISO感光度がとんでもなく高くなっているのに驚く(ASA25600)。夜の光景が真昼のように撮れる。WiFiでデータが送れる。ピント合わせが瞬間で終わる。いやいやここ10年の進歩はすさまじい。

 あれやこれやの新機器で周辺の整備に気を取られ電子工作どころではない。スマホやこのカメラを触ってみて、これまでの電子工作で驚いていた技術の進歩は、着実にこうした実社会にも反映されていることを実感した。

 スマホの方はGPSの進歩に感動である。何と地下鉄の中でもトレースするのだ。通勤の経路がほぼ完全にトレースできている。聞くところによると、a-GPSと言って、携帯基地局の場所から換算したGPSデータを送っているらしい。

 10年前、日本橋の事務所のビルの谷間では、現在地さえ把握できなかったGPSの性能に比べると格段の進歩だ。いや、車の無人運転が間もなく実用になるような時代だ。21世紀は着実に歩みを進めていることは間違いない。

15年ぶりの海外スキー。もう思い残すことはない(2/29/2016)
 海外スキーの話である。カナダで海外スキーしたのが15年前の話で、それ以来である。結論から言えば、やっぱり年だ。ヨーロッパまでの旅はいくら早くなったとはいえ、まだ10時間以上かかる。行き帰りの空の旅だけで相当体力を消費する。海外旅行はやはり若いうちに行っておくべきだ。

 搭乗するときビジネスクラス席を通過する。ゆったりとした席が用意されているようだが、いくら広くなると言っても、所要時間がエコノミーに比べて少なくなるわけではない。金をかけてもこの時間は少なくならないのだ。しかも時差で体の調子は一ぺんにおかしくなる。

Dsc002060003  20年ぶりのヨーロッパは、列車が新しくなって、さらに快適に早くなっていた。ツエルマットからインターラーケンという主要な観光地は昔、一日で回ることが出来なかったが、長大なトンネル(長さ34.5kmレッチュベルグベース)が出来て一時間以上短縮され、ツエルマットから日帰りで、ヨーロッパ最高標高列車地点のユングフラウヨッホまで行けるようになっていた。

 ここはほぼ30年ぶりの訪問である。しかし、今度も運命の女神はユングフラウヨッホで晴天をくれなかった。マッターホルンは2回とも微笑んでくれたのに、ユングフラウヨッホは2回ともはずれだ。最高点のレストランでワインを飲んでうさをはらす(気圧が低いので用心して一杯だけ)。

 氷河上のスキーは、日本とはスケールの違う滑り方ができる。何十年もスキーをやってきたが、至福の滑降を楽しんだ。もう思い残すことはない。ツエルマットからはリフト、ゴンドラを乗り継ぎ、国境を超えてイタリアまで行くことが出来る。この往復の一本だけで日本の2日分の滑走距離になる(30キロ以上)。

Dsc001470002  スマホのGPSは上空(成層圏以上か)では無効になることがわかった。成田から飛び上がり新潟方面に進路をとると間もなくトレースが止まる。しかし最寄りのチューリッヒ空港で復活した。日本で借りてきたスイスのWiFiルーターが動き、スイス国内のルート地図があらわれた。

 GoogleMapで現在地が把握できる。夢のような話である。いや、スマホに買い替えて良かった。スキー場での場所の把握も簡単に出来る。スイスのスキー場は大抵のコース上でWiFiが効く。もっとも、コース上ではガイドについていくのに精いっぱいで、これをゆっくり見ている暇はとてもなかった。

 帰りに、添付写真のような立体地図を高速道路のサービスエリアでみつけ思い切って買って来た(117スイスフラン、1万3千円程度)。枠が大きすぎて機内持ち込みは出来なかったが、添乗員の計らいで「こわれもの」として別送してくれた。感謝、感謝である。Dsc003910001

帰国してからの電子工作。ArduinoでRTC時刻設定部を整備する(3/15/2016)
 日本に帰ってきてすぐ、風邪を引き、電子工作の再開はさらに延びた。参加者の人たちにOneDriveで、撮りためた写真を配布する。先方からも写真が届く。写真を見る度に、その場の雰囲気が思い出され、気分が高揚する。

 海外旅行好きの親父が良く言っていたのを思い出した。「海外旅行は、行く前と行った後が楽しい。最中は疲れる」というのだ。父はいまの私の年齢と同じころ盛んに海外旅行を楽しんでいた。 まさしくその気分である。行く前は、期待と不安で胸が膨らみ、帰ってからは楽しかったことだけが残る。途中は既に書いた通り、疲れることが多い。

 事務所に出たり、久しぶりにジムに出てステップで汗を流したり、日常の生活が戻ってきた。そろそろ電子工作に戻る時期だ。机の前を片づけて、PCを開き、Arduino IDEを立ち上げて以前のソースを眺める。

 一応、UARTから年月日や時刻が設定できるようになっているが、現在の設定は、年月日時分秒をただ直列に文字列に並べ、一気に定義する方法で人間にやさしくない。ウェブでもっと親切な時刻設定のスケッチを探したが、簡単には見つからなかった。それなら自分で作ってやろう。このあたりは力仕事なので、適当なところを関数に切り出してやらないと冗長なソースになる。

Esp8266rtc  うーむ、まだ、ArduinoのC++に慣れないな。stringというデータタイプは便利だが、他のデータタイプがCとはずいぶん違う。1バイトのバイナリ―を定義するため、データタイプをbyteと定義すると、コンソール出力が十進数字で出てくるのには参った(余計なお世話だ)。

 何とかひねくり回し、一応I2Cのリアルタイマークロックの時刻をコンソールから設定するArduinoのスケッチが完成した。年と月日、時分秒の3つを別々に設定できる。既に設定したところはリターンキーで素通りできるのがちょっと工夫したところだ。曜日の設定は、ウェブから変換式を手に入れたので改めて入力する必要はない。
 以下に、DS3231を使ったRTCスケッチのソースを.inoファイルの形で置きます。適当なプロジェクトフォルダーに入れてArdluino IDEでコンパイルしてください。

「sketch_DS3231.ino」をダウンロード

  これを公開してブログ再開の節目としよう。まだ、WiFiモードがバックグラウンドで動くのが気に入らないし、立ち上がりの時のボーレートの違うメッセージのゴミも気になるが、これはいずれ直すことにする。

| | コメント (2) | トラックバック (0)

2016年1月26日 (火)

ESP8266の冒険は続く(画像付きのサイトにする)

 お正月というにはもう日が経ちすぎてしまいましたが、遅ればせながらみなさま明けましておめでとうございます本年最初のブログ記事を掲載いたします。内容は昨年暮れからのESP8266まわりのお話の続きです。やりだすと止まらない性質(たち)で、すっかりこのWiFiモジュールにはまっています。

 少し脱線気味なのですがArduino IDEで、とうとうページに画像の出るWebサーバーまでESP8266で作ってしまいました。ESP8266は結構大きなフラッシュメモリを持っていますので、これをファイル替わりに使うと、ちょっとしたJPEGデータを入れたページを作ることが出来ます。

 しかしさらに欲を出してSDカードにまで拡張しようとして頓挫しました。やっぱりハードがからむとArduinoと言えどもそう簡単には動いてくれません。ともあれ、暮れからここまでのESP8266によるWebサーバーの実験の数々をご紹介いたします。

Arduinoは楽だけど、こんな電子工作で良いのだろうか(1/3/2016)
 新年が来た。今年は家族が酷い風邪をひいてちょっとお正月どころではなかったのだが、電子工作は絶好調である。ESP8266に簡単なウェブサーバーを入れ、ネットを通してLEDの点滅が出来るまでになった。ウェブには他にも沢山の応用例が紹介されまだまだ色々なことができそうである。

02p1257479  出来たと言っても、今度のサーバーのLEDの点滅は、IPアドレスのあとにいちいち違ったリンク名を加えないと変わらない(/gpio/0か/gpio/1)。ここまで来たら一般の画面と同様、ON/OFFのボタンのクリックでLEDが点いたり消えたりするようにしたい。

 GitHubなどからサーバーのサンプルコードを片っ端から持ち込んで調べる。Arduinoのスケッチは、基本はオブジェクト指向言語のC++なので、Nodeのときにも愚痴ったように、この種の言語はデータの抽象化が大規模なので、ソースはとても追いにくい。

 そのうえライブラリーの公開がどうも一部だけなので(探せばあるのだろうが)、少し詳しく調べようとするとすぐ壁にぶつかって先に進めなくなる。それでも、ウェブ記事の中で、これからやろうとしている、hrefタグの文字列のクリックで候補を選ばせるようなっているスケッチを見つけた(ここのサーボモーター制御のところ)。

 半日かかってHTMLをもう一度勉強し直し、このソースを参考に、スケッチを修正し始めた。そのコーディングの最中、長年疑問に思っていた謎が突然解決したのである。謎というのは、ファイルの概念のないサーバーでどうやって別の画面へリンクしているのかが分からなかった。

 画面そのものは、あのタグの沢山入ったHTMLテキストをプログラムで作れば出るはずだが、画面から画面のリンクや、画像送出のロジックをファイルなしにどうやって実現するのかが謎だったのだ。

 考えてみれば、HTMLのタグ<href=リンク先>や<src=ファイル名>は、そのリンクをクリックすれば、クライアントはリンク先をこれにしたGET要求レスポンスをサーバーに返してくる。これらは単なる文字列なので、これを調べるだけで、サーバーはこれから何をすべきかが判断できる。

 そうか、何もファイルを用意する必要はないのだ。わかってしまえば何ということもない話だが、わからないときはこんなものである。今までもやもやしていた謎がすっかり晴れた。目から鱗が落ちた気分である。

 それはともかく、参考にしたスケッチを少しだけいじって、LEDの点滅が画面の文字のクリックで出来るように修正した。出来た。ちゃんと動いた。あきれた。7年前にドイツのソースコードを導入して、えんこらえんこら作ったAC電源コントローラーのしかけは、ものの見事に1時間もしないうちにESP8266の中で完動した。

Esp8266_led  これはESP8266がすごいということに加え、Arduinoのしかけが優れているということなのだろう。シリアルポートの開設にしても、GPIOの設定にしても、全くハードを知る必要がない。何も考えないで楽々とI/Oディバイスを動かせる。

 それに文字列の検索でも、文字列の中から所定の単語を拾い出す多様な関数が最初から用意されており、簡単にリンク先を選別するコードが書ける。文字数やデータタイプを気にする必要もない。

 しかし、これで本当に電子工作をやったことになるのだろうか。車の楽しみと同じなのかもしれない。昔は、中古自動車を整備して箱根の峠を超えられるかどうかが、一人前のドライバーの証しだと言われていた(昔のポンコツ車は坂で簡単にオーバーヒートして箱根を登りきれなかったのである)。

 電子工作でも同じだ。AVRやARMで、データシートを穴が開くまで読み、制御レジスターを設定し、せっせとコーディングしていた。UARTだけでも字化けせず通信出来るまで結構な手間と努力を必要としたのである。成功すればそれだけで美味しい酒が飲めた。車と同じで、電子工作の楽しみの場所がどんどん変わっているのだと考えるしかない。

フラッシュメモリーにファイルシステムを構築。本格的サーバーへ(1/8/2015)
 Webサーバーはファイルが使えれば本格的になる。ウェブによれば、ESP8266でもSDカードが読み書き出来るようだ。しかしハードの実装はそう簡単ではない。その前に、ESP8266が持っている豊富なフラッシュメモリーを利用したフラッシュファイルシステムを試してみることにした。

 index.htmlファイル位ならこの程度で十分だし、ちょっとした画像がESP8266のページに載るとお洒落ではないだろうか。日本語のサイト(http://blog.boochow.com/article/427214036.html)に、このフラッシュファイルシステム(SPIFFS)を丁寧に説明しているところがあったので、やってみる気になった。

 導入はこのサイトにあるように、1)まず、Arduino IDEのバージョンを開発用に換え、2)フラッシュメモリにファイルシステムをアップロードするプラグインをArduino IDEに加える。3)それを使ってESP8266のフラッシュにファイルシステムを作る。4)それを対象に、いくつかの関数群で、ファイルを登録したり、削除したり、中身を読み書きする。

 早速、指示通り作業を進める。2)のArduinoのプラグインのダウンロードとインストールまでは順調に進んだ。Arduinoの「ツール」メニューに、ESP8266 Sketch Data Uploadというプラグインのメニューが出来る。

 しかし次のステップ3)で止まった。プラグインを実行するとエラーメッセージが出て、ファイルシステムが出来ない。プラグインのバイナリ(.jarファイル)を入れる場所を替えたり(ユーザーディレクトリ内でもArduinoのシステムディレクトリでも動く)、プラグインのダウンロードをしなおしたり、色々やるが同じエラーだ。

 簡単にあきらめないのが所長の取り柄である。あきらめずに試行錯誤するうち、遂にプラグインが通り、ファイルのアップロードに成功した。原因はプラグインのバージョンが最新のArtduino IDEと合っていなかったためであった。

 日本語サイトが紹介した、プラグインのURLは、http://arduino.esp8266.com/ESP8266FS-1.6.5-1105-g98d2458.zipで、9/9/2015のタイムスタンプがあるが、これは少し古く、最新のSPIFFSのサイトにあるESP8266FS-0.1.3.zip(タイムスタンプは11/13/2015)だとArduino1.6.7でも動く。

 このプラグインは、カレントスケッチのフォルダー(現在の作業場所で.inoファイルのあるところ)の中に作ったdataフォルダーに収容されたファイルすべてをフラッシュメモリー内にインストールする。うまく行ったかどうかは、このdataフォルダー内のファイルの名前がアップロードの際に表示されるので簡単に確認できる。

Ws000002  この最新のプラグインの提供サイトは、最初の日本語サイトで紹介されたがリンクが行方不明(404)になっているサイトらしく、これを発見できたのは、例の「エラーメッセージの丸ごとサーチ」によるところが大きい。同様なエラーで悩んでいる人がポストした海外のフォーラムが見つかり、その中で紹介されていたサイトが上記のGitHubのサイトだった。

フラッシュ内のディスク読み出しは成功(1/9/2015)
 3)のファイル組み込みがうまく行ったので、次の4)のステップに入る。ESP8266のスケッチで、フラッシュファイルシステムを起動させ、ファイルが読めるかどうかのテストである。

 先ほどのdataフォルダーに適当なテキストファイルを入れた。Arduino IDEのプラグインを始動させ、フラッシュに書き込む。そのあと、このテキストファイルを読むスケッチを書く。表示先はシリアルモニターである。動かしてみた。問題なくテキストファイルの内容がモニターに表示された。

 よーし、快調だ。このファイルシステムの最終目的が決まっていないので何をもって成功と言えるのか、はっきりしないところだが、少なくともやろうと決めたことが確実に実現していくことは、とても気分が良いものである。次はいよいよHTMLの中への画像埋め込みである。

 ESP8266は、2MBのフラッシュメモリがあり、通常は半分も使っていない。さしずめ、JavaScriptなどを使った派手な制御画面のindex.htmlを作ることが第一の目標だが、もうひとつは画像の表示である。ページの背景画像にもなる。ただアップロードが遅い(11520bps 1.4KB/s)ので、テストのため小さな画像を探す。

 昔、携帯にいれていた先代の猫の絵が見つかったのでこれを選ぶ(12KB)。HTMLにおける画像の表示のロジックを調べ始める。どうもこれまでのArduinoスケッチのWebサーバーに関する関数群(メソッド、メンバー)の対象はすべてが文字列で、jpegファイルのようなバイナリーファイルは出来ないようだ。

 また、ネットで色々調べる。原理は、先ほどのGET要求レスポンスからファイル名を拾って、文字列のときと同様にファイルの中味を送れば良いはずだ。しかし具体的なコード例が見つからない。やっとpythonのページでやりかたを見つけた。

 何だ、やり方はとても単純だった。content type: image/jpegなどのヘッダーデータの改行文字のあとに、バイナリを送れば良いだけだ。しかし、これまでの使っていたArduino IDEのWebサーバーの関数で試してみたが、みなうまく動かない。

JPEGファイルの送出が難しい。バイナリ―データを送れない(1/14/2016)
 ESP8266の紹介サイトでも、このあたりになると日本語サイトは少ない。英語サイトにはあるのだろうが、つい無精して日本語版ばかり探す。ATコマンドでの動作など、入門部分を紹介するサイトは山ほどあるのだが、こうしたちょっと先に進んだ具体的な応用例を紹介するページは見当たらない。

 一方では、ここのサイトのように、かなり高度な開発を紹介しているところもある。IOTの最先端の部分でもあり、情報は少し閉じた所で流れているのかもしれない。まあ、ESP8266で画像を出すホームページの需要などは殆どないだろうから、当たり前と言えば当たり前か。

 ESP8266のWebサーバーのコードは、何種類かあって(ArduinoのEtherシールドからの派生もあるようだ)、その差を調べようとするが、参考になるサイトは見つからない。こうなると、紹介されているサイトのソースコードをしらみつぶしに調べて、バイナリを送っているコード例を探すしかない。で、片っ端から中味を調べる。

 すると、このサイト(ソース後半)で、こういう使い方をしているところが見つかった。

   client.write(dataFile, HTTP_DOWNLOAD_UNIT_SIZE);

 まず、printではなくwriteというメソッド(メンバー関数?)と、このHTTP_DOWNLOAD_UNIT_SIZEという定数があやしい。clientというwebサーバーのオブジェクトの仕様がどこを捜しても見当たらないので確実ではないが、どうみてもこれは、HTTP_DOWNLOAD_UNIT_SIZEの長さ単位にバイナリファイルを送っているように見える。

Ws000003  だめもとである。このdataFileオブジェクトに例の猫の絵のファイルを入れ、テストしてみた。
ビンゴ!である。ESP8266のLEDのon/off指示画面の下に見事に猫の画像が表示された。いやあ、嬉しい。表示速度は少し遅いが、まぎれもなく先代の猫の絵だ。

画像付きホームページ完成。スケッチソース公開(1/18/2016)
 いくつかのサイトのスケッチソースを参考にしながら、画像付きのLED点滅のホームページが完成した。制御方式は、最初はイベント駆動のような形をしたserver.on("リンク文字列",割り込みエントリ)で、割り込み先を作り、loop()の中は割り込みハンドラーだけにする方式だったが、途中で変えた。

 割り込み方式では、エラーが、どうやっても取れなかったことや(プロセスが終了しない)、共通する処理をすべての割り込み部に書く必要があり、コードに無駄が多かったので、普通のloop(){}の中にすべての処理を入れる方式に変えた。

 スケッチソースを参考までに以下に掲載する。この前に、jpegファイルは、esp8266.jpgとして前記のフラッシュファイルシステムに登録しておかないと動かないのでご注意。不慣れなC++コーディングなので無駄なところがあることはご勘弁ねがいたい(とりあえずはこれで動いている)。

/* フラッシュファイルシステムを使った画像の出るサーバー
 *  1/11/2016    (C) 2016 LABO Gataro
 *  ref. http://qiita.com/tadfmac/items/17448a2d96bd56373a66
*/
#include <Arduino.h>
#include <ESP8266WiFi.h>
#include <WiFiClient.h>
#include <ESP8266WebServer.h>
#include <FS.h>

#define BUFFER_SIZE 16384
const char *ssid = "XXXXXXX";      //"ここには無線ルーターのSSIDを記述";
const char *password = "YYYYYY";   //"ここには無線ルーターのパスワードを記述";
unsigned char buf[BUFFER_SIZE];
String s;
int val;
File jpegFile;
WiFiClient client;

//ESP8266WebServer server(80);
WiFiServer server(80);

boolean readFFS(){
   jpegFile = SPIFFS.open("/esp8266.JPG", "r");
   if(!jpegFile){
    Serial.print("Failed to open /esp8266.jpg");
    return false;
   }
   size_t size = jpegFile.size();
  if(size >= BUFFER_SIZE){
    Serial.print("File Size Error:");
    Serial.println((int)size);
  }else{
    Serial.print("File Size OK:");
    Serial.println((int)size);
  }
  return true;
}

void Drawjpg(){
  jpegFile = SPIFFS.open("/esp8266.JPG", "r");   // test test test
  size_t totalSize = jpegFile.size();
  delay(1);
  Serial.print("JPEG proc size=");
  Serial.print(String(totalSize) + "\n");
  client.write(jpegFile, HTTP_DOWNLOAD_UNIT_SIZE);  // send a binary file 
  jpegFile.close();
}

void setup() {
 Serial.begin(115200);
 delay(10);

 pinMode(2, OUTPUT); 
 digitalWrite(2, 0);
 
 Serial.println();
 Serial.println();
 Serial.print("Connecting to ");
 Serial.println(ssid);
 
 WiFi.begin(ssid, password);

 SPIFFS.begin();     // フラッシュFSを開く
 if(!readFFS()){
  Serial.println("Read FFS error");
 }
 
 while (WiFi.status() != WL_CONNECTED) {
   delay(1000);
   Serial.print(".");
 }
 // Solid IP http://ashiyu.cocolog-nifty.com/blog/2015/08/indexhtml-8dfa.html
 WiFi.config(IPAddress(192,168,NNN,MMM),WiFi.gatewayIP(),WiFi.subnetMask());
 Serial.println("");
 Serial.println("WiFi connected");
  
 server.begin();
 Serial.println("Server started");
 Serial.println(WiFi.localIP()); 
}

void loop() {
 client = server.available(); 
 if(!client) return;
 Serial.println("new client");
 while(!client.available()){
  delay(1);
 }
 String req = client.readStringUntil('\r');
 Serial.println(req);
 client.flush();

 if(req.indexOf("/gpio/0") != -1 ){
  val = 0;
 }
 else if(req.indexOf("/gpio/1") != -1 ){
  val = 1;
 } 
 else if(req.indexOf("/esp8266.jpg") != -1) {
  s = "HTTP/1.1 200 OK\r\nContent-Type: image/jpeg\r\n\r\n";
  client.print(s);
  Drawjpg();
  client.flush();
  delay(1);
  Serial.println("JPEG was sent");
  return;
 }
 s =""; 
 s += "<html lang='ja'><meta charset='UTF-8'>\r\n";
 s +="<style> a{ font-weight: bold; color: #FF6666;} </style>";
 s += "<h1>ESP8266 リモートLEDスイッチ</h1>"; 
 s += "<p>押されたスイッチは ";
 s += (val)?"ON":"OFF";
 s += "<ul>";
 s += "<li><a href='/gpio/0/'>OFF</a></li>\n";
 s += "<li><a href='/gpio/1/'>ON</a></li>\n";
 s += "</ul> \n";
 
 s += "<p> ここに画像を入れるテストをします </p>\n";
 s += "<img alt=\"graph here\" src=\"/esp8266.jpg\" />";    //"内の\はエスケープ
 s += "</html>\n";

 client.print(s);
 digitalWrite(2, val);
 delay(1);
 Serial.println("Client disconnected");
 client.flush(); 
}

SDカードの実装ができない(1/24/2016)
 このあとさらに、SDカードの実装まで挑戦した。以前使っていたリニアPCMプレーヤーのテストベンチから、SDカードアダプターをとりだしESP8266につける。大した配線量ではない、簡単にすんだ。

 次はソースだ。ソースは、すでに色々なところで公開されている。大元のGitHubまで戻り、sdcardinfoのスケッチを頂く。コンパイルも無事終了した。勇躍テストである。適当なSDカードを入れて電源ON。

01p1257472  残念、初期化がエラーで返ってきた。さあ、これからどうする。SDクラスライブラリの解析は資料もないし不可能だ。この種の言語は動けば便利だが、動かないときは全く手も足も出ない。とりあえずはオシロを持ち出して初期化の波形を調べる。

 調べた結果は、ESP8266からのCSや、CMD(MOSI)は正常に出ているが、SDカード側からはレスポンスがないということがわかった。うーむ、これはハードか。時々状態が変わるときがあるので、接触不良の可能性もある。

  オシロではこのあたりが限界だ。ロジアナで徹底的に調べるにしても情報が不足している。やっぱりハードがからむとArduinoでも一筋縄では行かない。このあたりで一区切りつけてブログに報告することにしよう。

| | コメント (2) | トラックバック (0)

2015年12月31日 (木)

次のお題はESP8266で決まり。この機能でこの価格は驚異

 2015年の暮れも押し迫ってきた。実は前回のDC-DCコンバーターの工作の最中、気になったディバイスがあって買っておいたものがある。これを次のテーマにしようと決めてはいたものの12月に入って何かと忙しく(忘年会が6回もあった)、あまり先に進んでいない。

 この研究所のブログの更新間隔は年々長くなる一方で、今年は遂に一ケ月に1回程度と言うありさまである。今回もこのまま行くと年を越してしまいそうだ。話を切らさないためとりあえず途中経過だけでも記しておくことにする。(12/31/2015記)

WiFiモジュールESP-WROOM-02(ESP8266)について(12/2/2015)  
 これがそのディバイスの名前である。最初はUARTのインターフェースを持った単なるWiFi(無線LAN)モジュールだと思っていたが、どうもそれだけではないらしい。ArduinoのIDE(統合開発環境)で開発が出来るというのだが、情報が断片的で今一つ全体が見えていなかった。

 昨年暮れあたりから話題になっていたが、WiFi部分が日本での技術基準適合証明(いわゆる技適)を取っていなかったので、関心は専門家や一部の好事家だけに限られていた。当研究所はArduinoはやらないし、インターフェースがUARTでは画像や音声は通らないし、WiFiならすでにEdisonがあるので、それほど強い興味を持たずにいた。

 それがこの春、技適を通ったモジュールが、次々に大手の電子部品店から発売され、ネット上で盛んに取り上げられるようになって詳しい情報が流れてくると、これがとんでもないチップであることがわかってきた。

Esp8266  何しろ価格破壊なのである。まず無線LANを通るインターフェースが¥500台で手に入るのである。しかもこのモジュールのI/OインターフェースはUARTだけではなく、SPIやI2C、I2S、それにPWM出力3チャンネル、普通のディジタルI/O、さらにADC入力まで持っていて、これらをユーザーで自由にプログラム可能だというのだ。

 ちょっと前までは、マイコンをネットにつなぐことだけで、相当な手間と技術力を要していた。ネットワークにつなぐICチップだけでも¥500以上したのである。それが同程度の価格で、無線LANがつながりUARTで制御できるだけですごいのに、色々なことが単体だけで出来てしまいそうなのだ。

 Linuxが動き高解像度画像や動画を制御できるBeagleBoneBlack(BBB)や、RaspberryPiなどのボードとは、応用の方向が違うので比較しにくいが、簡単な遠隔操作ぐらいなら、このモジュールだけで殆ど出来てしまうのではないか。Xbeeどころではない、恐ろしい話である。

 開発元は、中国の上海に本社があるファブレスメーカーExpressifという会社で、すべてオープンソースを謳っている。はじめArduinoインターフェースというので何かと思ったら、Arduinoのスケッチライブラリでユーザープログラムが開発できるということだった。gccでの開発環境も準備されているようだ。

 BBBや、Raspiのときも驚いたが、この中味は当初考えていた以上に隔絶したレベルに達している。まさしくIOT(Internet Of Thing)時代にふさわしい、革新的なディバイスだ。当研究所でも表面実装DC-DCコンバーターの制作が一段落したので、迷わず次のお題とすることとした。

あっさりATコマンドで無線LAN確立。でもまだこれは序の口(12/3/2015)
 モジュールは秋月で入手した(¥550)。良く調べずに買ったが、モジュールは2ミリピッチなので変換基板がいる。秋月の変換基板はブレッドボード用で気に入らなかったのでAitendoでピッチ変換基板だけ買った(Aitendoでもモジュールを売っている。¥580)。

 とりあえずは動作確認だ。ピッチ変換基板にハンダ付けし、ブレッドボードでテストを始める。あっさり動いた。WiFi接続を開始する。これも苦もなくつながった。pingで確かめる。少し遅いが、ちゃんとレスポンスを返してくる。にわかに信じられないがネットが通った。

 いやいやEdisonでも感激したけれど、このモジュールは¥500台で買えるのだ。信じられない。調子に乗って、ATコマンドでTelnet端末にしてみる。これも問題なく動いた。実際にシリアルから送ったデータが、Telnet端末にしたPCのコンソールに出力されるのを見ていると、何か心の底から感動が盛り上がってくるのを抑えられない。

 この単体だけでアプリが開発できるというなら、以前(7年くらい前)作ったLANによるプリンター電源の遠隔操作などいとも簡単に出来てしまうということだ。あのときは、¥1000近いNICチップと、¥200以上するマイコンが必要で、Cソースは数百ステップ、しかも有線LANだった。

 しかしATコマンドインターフェースでネットとつながることに驚いているのはまだ早い。本題はこれからだ。モジュールに用意されているUART以外のペリフェラルを活用すればもっと様々なことがネットを通じて行えるのだ。勇躍、次のステップに進むことにした。

ジャンパーのかたまりでないまともなテスト基板を作る(12/5/2015)
 その前にやることがある。これまでのATコマンドを使ったテストは、スルーホールに差せる「ばね付き」ジャンパーで変換基板とミニブレッドボードをつないだ空中配線状態である。プルアップ抵抗などを載せたブレッドボードの上はジャンパーで盛り上がっている。

 動作モードの切り替えにはGPIOピンを操作する必要があるし、リセットすることもあるので、この先は今の状態では不安である。Xbeeのこともある。Xbeeに較べれば1/5の価格なのでそう神経質になる必要はないが誤操作で動かなくなったチップの回復に無駄な時間を使いたくない。

 アプリケーションを何にするか決めていないので、マザー基板を作るのをためらっていたが、このままではどうにもテストが進めにくい。ESP8266を使いこなすためにも、とりあえずはちゃんとした基板にマザー基板を作ることにした。

01pc247421  定番の秋月のC基板を用意して、リセットスイッチや、ジャンパーピンをつけたマザー(テスト用)基板を作る。ただ、具体的な用途が決まっていないのでレイアウトに迷う。電源は、USBからとらずに独立した電源アダプターを付けることにする。サイト情報ではピークで100mA以上流れるので市販のシリアルのUSBに出ている3.3Vを使うのは無理なようだ。

 しかし、基本的なモジュールの結線がわかりにくい。書き込みモードの設定に必要なピンの数が2つなのか、3つなのかサイトによって違う。いくつかのサイトを渡り歩いて、何となく決めたが、これで本当に良いのか確信が持てない。とりあえずは3つとも指定通り出来るようピンヘッダーやスイッチをつけた。

ESP8266も奥が深い。何故みんなが飛びつかないかわかった(12/14/2015)
 かたっぱしからESP8266関係のウェブサイトを覗いて情報を蒐集する。いやいやこれは奥が深い。ブレッドボードの実体配線を丁寧に写真で紹介し、操作手順をひとつひとつ説明するサイトが多いが、全体が見渡せていないので良く分からない。

 しかも、開発手法には、どうもいくつか種類があるようで、具体的な手順が示されても、それがどういうことなのか理解できない。良く言う「自分が今何をやっているのか理解できない」レベルである。

 ATコマンドをUART接続で別のArduinoから送って操作するところもあれば、単体そのものをArduinoのIDEでプログラム開発するところもある。そうかと思えば別のフラッシュローダーで直接ファームに出来合いのバイナリをロードしているところもある。

 アプリケーションも、LEDチカチカから、既存のATコマンドインタフェースにSSL(暗号化ソケット層)を追加するプログラム開発の高度な解説まで幅がやけに広い。何を参考にすればよいのか迷ってしまう。この状態では、初心者は記事に書かれたことは出来ても、その先は全く進めないだろう。

Esp8266blink  わからないまま我慢して沢山の情報を浴びているうち、やっと何となく全体を理解することが出来た。これまでにわかったこと、何故これがわかりにくかったのかを以下にまとめてみた。

  • WiFiインターフェースの裏に32ビットのマイコンが隠れており、この仕様が表に出て来ないのでわかりにくい。アプローチがいくつかあるが(ATコマンドなど)、それぞれがなるべく内部を知らなくても動かせるように設計されているので、初めての者には何が何やらさっぱりわからない。
  • ATコマンドだけのインタフェースでも、別のマイコンをつないでUARTでおしゃべりすればWiFiを動かしてサーバーのようなこともできる。これと、ESP8266単体でのサーバー構築とは全く別になるのだが最初この違いが判らなかった。
  • Arduino IDEで開発可能というが、ハードの仕様が表に出て来ないので見通しがつかない。スケッチライブラリは良く見れば沢山あるのだが、最初は、Arduinoでの開発という意味が良くわからなかった。こいつはマイコンなのだ。その後このあたりを明確に示したサイトが見つかり疑問は解けた。
  • SPIフラッシュにファームを焼くフラッシュローダーが用意されているが、これを使いこなすのは容易ではない。しかも、技適に触れるような改造や改変が出来そうなところもあるようなので、触るのは少々勇気がいる。
  • 要するにウェブ上のほとんどの記事が何か単一の機能の実現の、しかも初心者向けの単方向の手順の解説が主なので、全体をつかめない。ブレッドボードの実体配線図とソースコードだけでは、このESP8266を理解することはとても無理だ。

ファームの戻し方がわからないので手が出せない(12/24/2015)
 嵐のような忘年会ラッシュ(11月末から数えてみると6回)、法事で関西を往復、続いて年賀状の準備、お正月の買い出しなど12月は気ぜわしい日が続いた。ESP8266の方は、ATコマンドでの実験の次のテーマ、ArduinoのIDEで独自のファームをテストするステップに入ったが中々手が出ない。

 Arduinoでファームを書き換えると、出荷時についているATコマンドインターフェースは上書きされてしまう。万が一ファーム書き込みに失敗しても元へ戻すようにしておきたいが、この方法が良く見えないので、先に進めないのだ。

 ファームの書き換えは、複数のバイナリ―ファイルを所定のアドレスに正確に焼く必要がある。この直か打ちのアドレス値が、ハードのバージョンによって違うのが悩ましい。アプリの開発は超上流のコマンドベースで、ファーム書き換えは超下流のアドレス直か打ちという落差の激しい開発環境で目が白黒する。

 それでも、薄紙をはがすように段々ESP8266の全貌が見えてきた。これまでにお世話になったサイトのURLを、簡単なコメントとともにご紹介しておこう(勝手リンク失礼)。

全体の俯瞰には最高。ちょっと専門家向け
http://bril-tech.blogspot.jp/2015/07/okiot.html

要約を知りたかったら、これがわかりやすい。所長が感じたことと同じことが書いてある。 http://einstlab.web.fc2.com/ESP/ESP.html

ファームの書き直しにお世話になる。ここでも「ねむいさん」が活躍していた。 http://blog.boochow.com/article/424450970.html

今回の見本にさせてもらったページ。ステップbyステップでやさしい
http://deviceplus.jp/hobby/entry0032/

丁寧なのだが、全体を見渡せない。いきなり難しくなる。
https://tech-blog.cerevo.com/archives/859/

リアルタイムクロックストリーミングをESP8266で実現。高度なプログラム開発 https://www.mgo-tec.com/blog-entry-50.html

ウェブサーバーからのLチカで本年の作業終了(12/30/2015)
 暮れも押し迫った30日、遂に目的のウェブサーバーからのLEDの点灯/消灯に成功した。まだ、いちいちURLを書き直さないと点滅しないが、曲がりなりにもArduinoによるサーバーの動作が出来るようになった。

 やれやれ、ファームの書き換えはいつものように冷や汗ものだった。サイトの説明には、MACアドレスは必ずメモして残しておけと注意されていたのだが、これを守っていないことを、ファームを書き換えた後に気づき青ざめる。しかし、ファームを書くローダーはチップを認識すると、そのMACアドレスを吐き、何の問題もなかった。胸をなでおろす。

 先を急いでいるので、吟味もせずサイトにあるソースコードをコピペしてコンパイルする。幸い通った。さあ、これでどうだ。順調にファームの書き込みも終わった。

Esp8266webled 早速立ち上げる。よーし、モニターのシリアルポートには指定通りのメッセージ。そりゃそうだ、一字一句変えていない。

 PCのブラウザーからURLを入力する。いいぞ。モニターにメッセージが出た。gpio/0からgpio/1に入れ替える。メッセージは出たが、LEDは点灯しない。うー、何が悪いのだ。あ、指示通りGPIOピンを換えていない。面倒なのでソースコードのピンに移し替えることにする。

 全部のピンを基板の外部ソケットに出しておいてよかった。ジャンパーを入れ替え再度テストする。おーし、点いた。ブラウザー画面にも、そっけないがメッセージが出る。gpio/0のメッセージを送る。消えた。

02pc317425  念のため、フラッシュローダーで、出荷時のATコマンドインターフェースに戻してみる。バイナリーファイルを焼くところが5か所もあるが、ひとつづつ慎重に設定する。幸いエラーもなく終了した。リセットすると、問題なく最初の状態に戻った。ただし、WiFiの設定は最初からやりなおしである(当たり前か)。

 やれやれ良かった。何とか年内にブログの原稿がだせそうだ。これでESP8266の開発環境整備は一段落した。このあとは自由にアプリケーションを考えることが出来る。PWMや、ADCまであるので何か面白いものを作ってみたい。

| | コメント (0) | トラックバック (0)

2015年11月30日 (月)

面実装のDC-DCコンバーターの制作にはまる

 ちょうど1ヶ月ぶりのブログの更新である。前回はTiny85のソフトI2Cスレーブのソースコードを公開したのだが、今回は全く別の話題である。

 ここのブログ(ココログ)は、アクセスされたページ数は時間単位でわかるが、公開したファイルが何回ダウンロードされたかは記録されない。この数が多ければアップロードにも力が入るのだが全くわからない。コメントや、リンク先の記事などが頼りである。

 これまでに、リニアPCMプレーヤーやソフトI2Cマスター、マイクロステッピングなどのソースは結構使って頂いたようで嬉しい限りだが、今度のI2Cスレーブはどうだろうか。自信はない。

 まあ、仕事ではないので気に病む必要はないのだが、反響がないと何となく独り相撲をとっているような感じで空しいものである(ちょっと自信作だったのだけれど)。そんなこともあって、I2Cスレーブへの熱意は急速に冷めてしまった。

14pb287401  実は、この一ケ月電子工作から遠ざかっていたわけではない。むしろ、半田ごてを握っていた時間は近来になく多かった。それなのになぜブログを書かなかったのか。それは、これまでの工作とは全く関係のない工作で、しかも結果が中々でなかった。要するに「はまって」いたからである。

 I2Cスレーブの続きを期待して来られた方には申し訳ないが、以下は、この「はまった」内容の報告である。

安価な大容量DC-DCコンバーターチップFP6291を見つけた(11/2/2015)
 FP6291は、ChaNさんの最新作(パッシブストロボスコープ)に使われていたDC-DCコンバーターICである。Aitendoのサイトを覗いていたら、偶然、販売されているのを見つけた。何と2.5Aまで流せると書いてある。しかも¥50だ。破格の安さだ(LM2735などは¥200以上した)。これは買うしかないだろう。

Pb307418  Intelが出しているEdisonのブレークアウト基板は、EdisonをUSBペリフェラルも含めて安定して駆動させるのに、7.5~13.5Vの電源が必要である。リチウムバッテリー1つや、エネループなどで動かしたいため、前からDC-DCコンバーターには関心を持っていた。

 現在は、ストロベリーリナックスが販売しているDC-DCコンバーターモジュール(LMR62421)を使って長時間カメラを動かすことが出来たので、実用上はこれ以上新たにDC-DCコンバーターを作る必要はない。

 しかし、大容量出力のDC-DCコンバーターモジュールについては、実はこれまでに何度か自作し(過去のブログ参照)、ことごとく失敗している(LM2735やNJM2360)。汎用基板では思うような性能を上げることが出来ないようだ。

 もしかするとこのチップで可能になるかもしれない。早速、Aitendo直営ショップに出かけた。このところAitendoづいている。FP6291は発振周波数が高いため通常のチップより少ないインダクターが必要で、推奨定数の3.3~4.8μHが手持ちにはない。Aitendoで探すと、何と4種類も見つかった。

 さらにAitendoのウェブサイトでは、別の大電流出力と称するDC-DCコンバーターモジュール(SDB628(B6285Y))を見つけてある。これも安い。¥390だ。これも店頭で探し出してゲットしておいた。

 帰宅して、まずはこのモジュールを先にテストする。おお、こいつは、エネループ4本(5.1V)で、9V、0.45Aを楽々出力する。これならEdisonにUSBカメラを付けても十分余裕がある。値段が安いのでほかにも使いみちがありそうだ。

ブレッドボードでは性能が出ない(11/5/2015)

 こんどはFP6291をブレッドボードで組む。うーむ、2.5Aなど無理だ。エネループでは、0.35Aも流せば、9Vから7Vまで下がってしまう。インダクターを大きなトロイダルにしてもダメ。ブレッドボードだからだめなのか。

 データシートを見ると製造会社はシンセンで、どうも白髪三千丈の世界だ。2.5Aなどこんな状況では望むべくもない。値段が値段だ。さっぱりあきらめよう、などと数日前書いていたのに、今度は秋月や千石電商の地下で3.3μHのインダクターを見つけ、買ってしまった。合計7種類。やれやれ。15pb307407

 これが意外に、このリード型の一番小さいやつの成績がトップだった。性能が上がらないのは、どうも部品ではなくブレッドボードだからのようだ。ストロベリーリナックスの商品紹介のページには、DC-DCコンバーター基板は配線をコンパクトにしないと性能が出ないと書かれている。面実装にすれば所定の性能が出るのかもしれない。

 今Edisonのマザー基板に内蔵しているストロベリーリナックス製のDC-DCコンバーターモジュールでもインダクターは超小型である。それでいて、ウェブカメラのついたEdisonを楽々エネループ4本で駆動する。一時間つけっぱなしでも全く問題はない。

 面実装のコンバーターモジュールは以前、秋月の汎用SMD(面実装)基板で、Aitendoで手に入れたEMH7601というチップを使って作ったことがあるが、これは5Vまでしか昇圧できないのでEdisonの電源には使えない。しかも部品と部品の間は、UEW線でつないだ、いわば「面実装もどき」である。 P2126927

 秋月のSMD汎用基板を見ているうち、アイデアが段々生まれてきた。横や縦の溝は、ハンダブリッジでつなぎ、不要なところはルーターで削り出せば、このSOT23のチップなら直接ハンダ付けして、すべて面実装パーツで組めるような気がしてきた。考え出すと、これが止まらない。

こだわると止まらない。面実装の部品を集める(11/7/2015)
 手持ち部品をテーブルの上に揃えてみる。FP6291のデータシートのリファレンス回路図のチップセラコン20μFは手持ちにはない(50μFはあるが、少し大きすぎる)。チップ抵抗は、何とか手持ちで間に合いそうだ。

07pb077377  正確な基板の拡大図を作って、アートワークの作業を開始した。仕事の帰りまた秋葉原に寄って、秋月でこの前、売り切れていた20μFのチップセラコンを入手した。こだわると止まらなくなる。俺も好きだなあと、思わず苦笑いである。

 ミニリューターの丸やすりで、不要なパッドを削って、必要な部分だけにする。実体顕微鏡を見ながらの作業なので、あっと言う間に削り出しが進む。段々プリント配線っぽくなってきた。簡単に配線(というか)作業は完了した。思ったよりうまくできたので機嫌が良い。

 次は、線をまたがるジャンパーを裏にまわすビアの穴あけである。0.8ミリが少し大きすぎたようだ。ここは実体顕微鏡が使えないのでなかなか正確に開けることができない。これまでの機嫌がいっぺんに悪くなる(めげやすいタイプである)。

17pb307414  ビアは、この汎用の面実装基板は、裏が全面銅面なので気を付けないといけない。そうか、この裏面をグランド面に使って配線するのが賢かったかなあ。しかし、アートワークが終わっているので今さら配線は換えられない。実体顕微鏡を見ながら注意深く裏面の銅面がジャンパーと接触しないように、ここだけ先にハンダ付けをすませる。

面実装の基板で苦戦(11/9/2015)
 いよいよ部品のハンダ付けである。部品そのもののハンダ付けは造作がないのだが、苦労したのが、パッドとパッドの間のハンダブリッジによる配線である。ハンダの表面張力が結構大きく、0.3ミリほどの隙間を恣意的にブリッジをかけるのがとても難しい。予期しないときには簡単にブリッジがかかるくせに、思ったところには出来ないものである。もどかしい。

 折角ブリッジが出来ても、隣のハンダ付けをしている間にいつのまにか外れている。CRあたりならとともかく、ICチップのところは何度もハンダ付けしたくないのになかなかうまくいかない。冷汗をかきながらハンダ付けを進める。

 やっとできた。念のため配線を確認する。うはあ、配線間違いだ。インダクターをダイオードの先につないでしまっている。やれやれ、ここはスペースがなくて回り込ませることはできない。やりたくないけれどジャンパーが必要だ。UEW線で付け加える。

 もう大丈夫だ。恐る恐る電源を入れる。だめだ。入力電圧と同じ電圧しか出力に出て来ない。熱を持ったりしていないので誤配線ではなさそうだ。慎重に最初から導通テスターなどで配線を確かめて行く。

10pb207389  何度も確かめるが間違っていない。うーむ、ハンダ付けの熱でICをお釈迦にしたか、不安がよぎる。ICを取り換えようかと低温ハンダを取り出しかけた時、間違いを発見した。何と分圧抵抗を間違って逆につけていた。そりゃ出力電圧が上がらないはずだ。

 これを正しい位置に直して、めでたく面実装のDC-DCコンバーターは所定の電圧が出た。早速負荷テストに入る。おお、結構頑張っているではないか。これまでで最高の出力だ。9V出力で、20Ωの負荷をかけ、8V以上の電圧だ。3Wは(400mA)出ている。

自作のDC-DCコンバーターでEdisonがカメラまで動いたが(11/13/2015)
 いやあ嬉しい。これまで市販のDC-DCコンバーターだけでしか動かなかった、Edisonの電池駆動はこれで動きそうだ。早速、EdisonにUSBカメラをつけ、サーバーを動かす。良いぞ、画像がでた。遂に自作のコンバーターでも動いた。やっぱり、基板を小型化することが大切だったのだ。

 ちょうど床屋に行く時期だったので、このコンバーター基板をポケットに入れて、いきつけの理髪店の親父に見せて自慢する。彼はタバコの空き箱で五重塔を作ったりする趣味人で、気が合っている。素直に感心してくれた。

 30万画素のカメラなら、250mA程度、100万画素のC270なら平均で300mA(いずれもオシロに0.5Ωのシャントを入れての計測値)流れるが、この程度の電流では出力電圧は殆ど下がらない(9V設定で8.5V程度)。

 ただEdisonの操作法を殆ど忘れているのは参った。まずパスワードが違うと怒られる。おかしい。いくつか入れるがみなはねられる。面倒なので、カーネルを作り直す(reboot ota)。WiFiが初期状態にもどるのでWiFiの設定もやりなおす。

 DHCPをやめて固定アドレスにする方法も思い出せない。やっとスクリプトを見つけて直したのだが、設定したIPアドレスにならない。2回やりなおしてやっと成功した。これは本格的に自分のためのマニュアルを作っておく必要があるな。 08pb117378

 長時間テストに入る。うーん、やっぱり長時間は無理なようだ。10分くらいすると出力電圧のリップルが多くなり、それに比例してCPUが誤作動するのだろう熱を持ち始め、15分で、システムはリセットしてしまった。

 動くことは動いたが、これでは実用にはならない。ストロベリーリナックス(LMR62421)とAitendoのDC-DCコンバーター(SDB628)は1時間でも大丈夫なのに残念である。

ここまで来て撤退するのか。さらにこだわるのか(11/15/2015)
 さて、どうするか迷う。前にも書いたように、Edisonの可搬ウェブカメラは、市販のDC-DCコンバーターモジュールで既に実現している。実用的にはもう自作にこだわることはない。ただ、面実装にしたのに市販のレベルに達しなかったのが悔しい(ブレッドボードならあきらめがつくが)。

 何がいけなかったのだろう。データシートや、その中の推奨配置図などを調べる。データシートの文面には基準電圧を決めるFBの部分はなるべく他からの干渉を受けないよう最短距離で配線せよというだけで、インダクターなどへの指定はない。ただ、インダクターはICピンのなるべく近傍が良いようだ。インダクターのジャンパー線は性能低下のひとつの原因かもしれない。

 それに、せっかくこの汎用基板の裏面がベタアースなのにこれを活用していないのも気になる。ただ、もういちど作り直すのも良いが、ハンダブリッジで配線するのはICを痛めそうでなるべくやりたくない。

 このところ雨の日が多く、テニスもアスレチックジムもお休みで、地下のパソコンルームにこもる時間が増えたが、どうも手が動かない。電子工作の何か新しいテーマがあれば良いのだが、DC-DCコンバーターの失敗が尾を引いている。

 そんなとき、ふと新しいアイデアが浮かんだ。ハンダブリッジ配線の難しさを解消する方法である。ウェブでたまたま極薄の銅箔テープを使って面実装する記事を見て思いついた。銅箔で隙間を埋めるのだ。

 銅箔テープの裏には接着剤がついているので細くカットして隙間に固定すればピンセットで抑える必要もない。おお、これは我ながら妙案だ。早速、近所のホームセンターにでかけた。しかし、残念、エアコン工事用の分厚い銅箔テープはあったが、配線に使うような極薄の銅箔テープはなかった。 09pb207380

 あきらめきれず、ネットで探す。何だ、いくらでも売っている。薄さはみんな統一されて0.3mmでこれより薄いのはない。適当な(アマゾン)ところで注文をかける。やる方向が見えると、それまで憂鬱な気分がいっぺんに晴れる。早速、裏面グランドを利用した2台目のアートワークにとりかかった。現金なものである。

銅箔テープ届く。これもそう簡単ではなかったが何とか成功(11/18/2015)
 2日もしないうちに銅箔テープが届いた。アートワークも済んでいる。ミニリューターによる不要パッドの削り出しもすんだ。裏面グランドのビア(VIA)配線の前に、銅箔テープを使ったハンダブリッジがうまくできるかテストする。

 結論から言えば、銅箔の裏の接着剤はハンダの熱で簡単に無効になって、切れ端だけでは全く失敗であった。切れ端はあっという間に半田ごてに付着してしまう。しかし、ここで諦めないのが所長のしつこさである。

 前の「面実装基板もどき」のときにやった、UEW線のハンダ付けを思い出した。切れ端のUEW線ではなく、長いUEW線をピンセットで保持し、ハンダが冷えてからニッパーで不要部分を切る。この方式で銅箔をハンダ付けすれば良いのだ。

 カッターナイフで短冊形に切った銅箔テープの一部をパッドの隙間に置き(または配線したいところまでさしわたし)、ピンセットで押えながらハンダ付けをする。そのあと残りを切り取る。見事成功した。やった、やったぞ。ハンダが綺麗にパッドを横切って盛り上がった。俺は天才か。鼻が膨らむ。いやあ、こんなことで有頂天になれるのだから趣味というのは良いものである。

2台目の面実装DC-DCコンバーター完動す(11/22/2015)

 裏面のベタアースへのハンダ付けは、ハンダごての容量を心配したがその心配はなくきれいにハンダ付けが済んだ。2回目の配線なので進行が速い。大きさも形もほとんど同じ自作の面実装DC-DCコンバーターモジュール2号機が出来上がった(基板切り離しは完成後やる)。 12pb237393

 インダクターの取り回しはレイアウト上、データシート推奨図のように最短にはできなかったが、1号機のジャンパー線よりは短くなっただろう。アースがベタアースになったのが期待と言えば期待である。

 入出力のリード線をハンダ付けし(いずれはコネクターにする)、いよいよテストに入る。最初はマルチメーターを出力側につなぎ、エネループをつなぐ。全く音沙汰がない。ええー、どうした?とインダクターを押した途端、マルチメーターの電圧がOLの表示の後、10V近くを指した。

 いかん、インダクターのハンダ付けが不良である。慌てて、はんだごてを温め直し、たっぷりハンダを盛って中まで溶かす。ICではないので十分に熱を加えられる。テストに入る。よーし、大丈夫なようだ。しっかり所定の電圧が出た。半固定抵抗を廻して出力を9Vにする。

 さあ、問題のEdisonのウェブカメラの実験だ。念のため、オシロで出力電圧と、出力電流を表示させ、長時間テストに入る。Edisonが立ち上がる。USBカメラをつなぐ。消費電流はこの時点で150mAぐらいになる。ウェブにつなぐ。電流は300mAまであがった。 16pb307413

 10分経った。1号機はこのあたりからリップルが増え始めたが、今度の2号機はピクリともせず快調に動いている。大丈夫だ。20分、30分、依然として問題なく動いている。いやあ嬉しい。40分、少しリップルが出てくるようになったが、大したことはない。カメラは順調に動いている。

 1時間が経った。若干消費電流が増えてきたが、これはEdisonが熱を持ってきたためで電源のせいではない。リップルは殆ど変らない。最後まで見届けたいという気持ちもあったが、1時間以上は、市販のコンバーターでも動かしていない。もうこれで十分だろう。1時間も電池でEdisonを動かす機会もなさそうだし、このあたりで実験は終了することにしよう。

 ということで見事、2号機は1時間以上の作動に成功した。これで、がた老AVR研究所は、晴れてDC-DCコンバーターの呪縛からとけて、別の電子工作が出来るようになった。めでたし、めでたしである。

| | コメント (0) | トラックバック (0)

2015年10月31日 (土)

Tiny85のI2Cスレーブライブラリーのソースコード公開

 いま流行(はやり)の電子工作というのならArduinoなのだろうけど、こちらは今やイギリスの半導体メーカーに買収されてしまったAtmelの8ピンマイコンでソフトI2Cを自作している。こんな遊び方は、時代錯誤になりつつあると思うが、これが当人には結構面白く、ハマっている。

 I2Cは必要ラインが少なくてすみ(2線。グランドを入れて3線)、バス接続が出来るのでピン数の少ないマイコンでは定番の通信インターフェースである。専用のハードではなく普通のI/Oピン(GPIO)を使ってソフトウエアでこのI2Cを実現したのものをソフトI2Cと呼んでいる。

 ただ、GPIOによるI2Cインターフェースのソフトは、マスター側がほとんどで、スレーブ側の制作例は珍しい。マイコンがマスターになって、スレーブであるI2C機器を制御するというのが一般的だからだ。スレーブをソフトで作るというのは今度のように、I2Cのない周辺機器をI2C化するときくらいに限られる。

01pa307348  前記事までに、I2Cスレーブソフトは、目標のTiny85で一応動いたのだが、これは当面の目的である超音波距離測定ユニットHC-SR04を動かす部分の機能だけで、汎用的な用途にはまだ不安がある(連続データの送受信など)。

 前回、ソースコードを公開しなかったのは、せっかくここまで動いたのだから、もう少し、色々なところで使えるように機能を拡大してからと考えたためである。 追加の開発は楽に出来ると思っていたのだが、実は結構てこずった。

 ああでもない、こうでもない、と試行錯誤の結果、何とか安定して動くスレーブインターフェースの開発に成功した。もうソースコードを公開しても恥ずかしくないレベルに達したと思う。誰かが使ってくれると嬉しい。

I2Cスレーブはユーザーインターフェースが難しい(10/10/2015)
 I2Cインターフェースのスレーブ側は基本的には完全な受け身で自らは何も動き出さない。マスター側のトリガーをひたすら待ち続ける。スレーブのメインプログラムは無限ループでマスターからの信号を待ち、通信が始まったら、マスターの出すクロックの指示をすべて守らなければならない。

 こういうときは、マスターからの信号は割り込みで処理するのが一般的である。マスターからのデータはひとつも落とせないからである。このためにスレーブ側のメインプログラム(対象機器の制御、データの受け渡し)は、I2Cとのやりとりの合い間に動くバックグラウンドタスクとして、非同期で動かす必要がある。

 こうした方法の定番というのを分かりやすく解説している参考書やウェブの記事を、これまで見たことがない。どういうやりかたで作るのが良いのかいつも悩む。このあたりのロジックや、アルゴリズムは、マルチタスクを制御するOS(オペレーティングシステム)のしかけそのものなので、市販の参考書はそれを意識して、たいてい仰々しい書き方になっている。実務的にとても理解しにくい(初めて読む人にはわけがわからないだろう)。

 最近はOSをやさしく紹介する本がいくつか出ているが、実際のソースコードまで落としたものは少ないようだ。目的がOSを理解させることで、具体的にソフトを動かして何かの用を足すことを目的にしていないからである。

 前記事までのソフトI2Cスレーブのメインプログラムは、あくまでもHC-SR04を動かすために特化しており、このままでは他の用途に使いにくいし、汎用的に使うにはまだ機能が不足している。ちょうど良い機会なので、他にも応用が出来るような構造にし、併せて解説も少し足し、これから同じようなことに挑戦される方の参考になることを狙うことにした(誰もいないか)。

 現在のライブラリの形式は、I2Cインターフェースそのものはi2c_slave.cというソースファイル1本に集中させ(ヘッダーファイルは、i2c_slave.h)、アプリケーションに依存するコマンド解釈などの機器制御とデータの受け渡しは、メインプログラムi2c_SR04_85.cにまとめてある。

02pa307350  従って、違う機器(LEDや、液晶表示装置、温度センサーなど)をI2C化するときは、このメインプログラムだけを目的に合わせて変更すれば良いようになっている。前にも触れたように、このあたりは定式化したやりかたがない(もちろん、知らないだけという可能性もある)ので、がた老AVR研究所なりの方法論で話を進めることをご了承願いたい。

 やり方は次の通りである。まず、使いそうな機能をいくつか想定して、実際にそれを実装する。このしくみを詳しく説明すれば、メインプログラムと、割り込み駆動のI2Cルーチンとの間の動きが明確になり、他への応用が容易になるのではないかという狙いである。

連続データの送受信が非同期で出来れば文句がないだろう(10/14/2015)

 どんな機能が役立つのかは、このI2Cスレーブを使う具体的な例を考えて、それを基に決める。色々検討したが、やっぱり今度のように非I2C機器をI2C化することが一番多いのではないかという結論になった。

 LCDなどの表示装置は既にI2C駆動のものも多いが、パラレル駆動のLCDや、LEDマトリックス、グラフィックLCDなどは、必要なI/Oピンを少なくできるのでI2C化するメリットは多い。ただ、これらの表示装置は、マスターからスレーブへの出力が殆どなので、I2Cとしてはそう難しくない。さらに、全体の処理速度を早くするために、多バイトのデータが一気に送れる機能があれば、もう文句はないだろう。

 一方、EEPROMやRTC(リアルタイマークロック)などの入力ディバイスは、スレーブからマスターへのデータ転送が必要になる。こういうディバイスには、マスターからコマンドを受け、すぐにリピートスタートで求められたデータをスレーブからマスターへ送り出す機能も必要になるだろう(この機能はこれまでの記事の通り開発済み)。

こうしたことから、汎用的なモデル機能を以下のようにまとめた。

(1) UARTコンソールのように、マスターから一定の長さのテキストを送り、スレーブ側で蓄積し、コマンドでそのデータを送り返す機能。

(2) スレーブ側に何らかのデータを用意し、マスターからのコマンドに応じたデータ値を1シーケンスでマスター側に送り返す機能。

(3) マスターからのコマンドによって、スレーブ側に接続した機器を制御する機能。これは(2)のバリエーションで、今回は、超音波距離センサーなどの起動トリガーコマンドがそれにあたる。

連続データのマスター書き込み(送信)は簡単に片付いた(10/15/2015)

 まず、(1)の擬似UART的な機能の送信の部分である。マスター側のコンソールから連続したデータ列をリターンキー(\r)を終端文字として一気にスレーブに送り、それをバッファーに一旦貯めた後、別のコマンドで一気にエコーバックさせる。

 これまでの開発で完動したのは、HC-SR04での、マスターからの1バイト送信と2バイト受信だけなので、今度は、スレーブの受信リングバッファーがオーバーフローしないように、スレーブのメインプログラムと割り込みルーチンがマルチタスク的に動く必要がある。

 メインプログラムで、割り込みルーチンのリングバッファーのポインターを常に調べ、割り込みルーチンでデータが入って、ポインターが進めば、すかさずデータを本体の配列に収容する。UARTなどでいつもやっている方式と同じである。

 マスター側のドライバーにコマンドを新設し、;(セミコロン)のあとの文字列が一気に送られるようなコードを加える。コーディングは簡単にすんだ。テストである。よーし、スレーブ側のデバッグ用のコンソールに送ったデータが綺麗に並んだ。これは問題なく動いた。

Tiny85console
次のマスター連続受信(スレーブ送出)が難しい(10/16/2015)
(1)のもう一つの機能、マスター連続読み込み(受信)である。マスターからのコマンドによって、配列などに貯められたデータを一気にスレーブ側から、マスターに送り返す。スレーブ側は待つだけで、駆動するのはマスター側のクロックであり、スレーブはそれに従ってデータを載せて行く。

 ここで問題が発生した。書き込みのときは、コンソールのキーボードから打ちこまれた終端文字のリターンキー(\r)文字を見てマスターがストップコンディションを発行し、スレーブ側はこれを検知する機能があるので(前々記事参照)、問題なく通信が終了する。

 しかし、マスター読み込みの終了は、最終文字のACK/NACKビットでマスターがNACKをセットし、スレーブに返すことになっている。マスターが、送られてきた最終文字(リターンキー)のACK/NACKビットに、NACKをセットすることは時間的に不可能なので、マスターはリターンキーであることを知ったあと、ストップコンディションを挿入することになる。

 うーむ、困った。スレーブ側にはマスター読み込み時のストップコンディション検知機能がまだ実装されていない。固定量のデータならマスターが最終文字にNACKをつけるので正常に止められるが、このままでは、可変量の連続読み込みの送信終了は受け取れないことになる。どうしよう。

 ここまで来て、引き下がるわけにはいかない。乗りかかった船である。マスター読み込みのステートマシンに、ストップコンディションを検知するロジックを追加した。コードそのものは、マスター書き込みのところと同じなので簡単に出来た。ただ、フラッシュサイズは3Kバイトを超えた。

 しかし、これがどうやってもまともに動かないのだ。ストップコンディションを検知できなくて、すべての通信でタイムアウトしてしまう。ロジックアナライザーを再び引っ張り出して、ステートマシンをプローブして、原因がわかった。懸念していた通り、処理が次のクロック(SCL)パルスに食い込んでいる波形を発見した。クロックが8Mhzでは、今の50khzのI2Cが通らない。

 結局、マスター読み込み(スレーブ送信)でのストップコンディション検出はあきらめる。となると何か回避策を考えなければならない。良い方法を思いついた。

 リターンキーを受信したら、とにかくマスターはもう一文字受信し、この文字にマスターがNACKビットをつける。こうすると、スレーブに通信終了を知らせることが出来る。マスターはこの文字を捨てればよい。ちょっと姑息だけれどなかなか洒落た方法だ。

 スレーブ側の、NACKによる終了はこれまで正常に動いている。上機嫌で自信満々テストに臨んだ。ところが、これでも通信は正常に終わらない。つねにタイムアウトしてしまう。ロジアナで見ても正常な波形だ。もう調べるところがない。完全に暗礁に乗り上げてしまった。

旧友会が2回(10/18/2015)

 息抜きに、ここで、ちょっと電子工作以外の話題をご紹介する。同窓会の話題である。これまで、時々、話してきた小学校や高校の同窓会ではなく、珍しい古い友人からのお誘いが偶然に、続けて2つもあり、久しぶりに飲み会をやった。

 ひとつは、40年前、地方に転勤した時に一緒に仕事をした会社仲間の旧友会で、もうひとつは、同じ会社ではなく、20年前に仕事で親しくなった取引先の友人の同窓会である。どちらも10年くらい前までは頻繁に会っていたが、このところご無沙汰だった。

 それぞれ、出席者の殆どはもう現役を離れている。まず、会うなり「病気と、孫と、髪の毛の話は禁止」という宣言が出て大笑いした。良く見るとみんな相当な禿頭だ。まあ、それはともかく、昔話というのはいつになっても楽しいものだ。結論から言えば、どちらもとても楽しかった。

 会社の旧友会には実は余り顔を出したことがない。現役の頃の上下関係をいつまでも引きずる人間が少しでもいると周囲の雰囲気が悪くなり気分よく話が出来なくなるからだ。今回は幹事が、人を選んでくれたようで全く違和感なく昔話を楽しむことが出来た。

 こうした旧友会は、自分の人生を遠くから見るような解放感がある。この年になると、現役時代の熱い感情的な部分が削ぎ落とされて、自らを、良くも悪くも客観的にみている自分を発見する。今さら何が出来るわけでもない。達観した見方が出来るのだ。

 2つの会合とも、久しぶりに酒が進み、帰りが大変だった。まあ、何とか人の迷惑にならずに帰宅できたが、この年で深酒はほどほどにしておいた方が良い。自戒、自戒である。

マスター連続受信(スレーブ送り出し)終了条件の謎(10/21/2015)
 電子工作の話に戻ろう。いやあ、今回も解決までが長かったが、苦労の甲斐あって、これまで不安定な動きをしていたマスター読み込みは、完全にNO ERRORで動作するようになった。

 今回の不具合は、前のバグのように、お馬鹿なミスが原因ではなくて、複雑な要因で起きていたバグだったが、少しづつ事実を積み上げ、思い付いた仮説を検証しながら、最終的にバグの原因を解明できたので、すこぶる機嫌が良い。迷宮入り寸前の難事件を見事に解決した名探偵の気分である。

 マスターからの連続書き込みは簡単に成功したのに、マスターが連続して読み込む方は、どうも調子が悪い。マスター読み込みは、スレーブがデータを送った後、マスターからNACK/ACKビットが返ってくるので通信の終了はストップコンディションが出なくても通信終了になるはずなのに、現状は殆どの通信がタイムアウトになってしまう。

 気に入らないのが、すべてがうまくいかないのではなく、時々正常に終わるときがあることだ。何かのタイミングで起きたり止まったりするというのが、一番厄介なトラブルである。ステートマシンにプローブ(SR04のトリガーピンを流用)を入れて動きをロジアナで確かめる。

 確かに、NACK/ACKビットを調べるステップで、マスターはNACK(1)を返し、そこをステートマシンが通過していることは間違いない。それならタイムアウトフラグはここでクリアされ正常終了するはずだが、そうなっていない。

 そうだとすると問題はそのあとだ。一連の通信が終わったあと、割り込みルーチンはステートマシンを初期状態に戻し、割り込みをクロック(SCL)からデータ変化(SDA)に替えて、次のスタートコンディションを待つ。このあたりがうまくいっていない可能性が高い。

 しかし、マスターは、NACKを返した後、ストップコンディションを発行している。ロジアナにもはっきりした波形が出ている。たとえ、NACKでリセットできなくても、ここでストップコンディションによって割り込みルーチンは初期状態に戻り、リセットされるはずだ。それなのにタイムアウトになる。二重におかしい。

遂にマスター連続受信に成功。原因はNACK処理ではなかった(10/25/2015)

 謎は深まるばかりだ。そこで、今度は、ステートマシンではなくて、スタート/ストップコンディションを受ける初期状態のデータ(SDA)の割り込みにプローブをかけてみた。本当にリセットされてこの割り込みを受けているか確認するためである。

 確認したからと言って何か成算があるわけではないが物は試しである。半信半疑でロジアナを動かす。問題の通信終了のシーケンスを拡大する。おやあ、ACK/NACKビットを受けるステートマシンの直後に、スタート/ストップコンディションを受ける割り込みが2つも発生しているではないか。

Tiny85stop  先に触れたストップコンディションの時に発生するのは想定通りだが、その前の割り込みは何なのだ。あっあっあー、わかったぞ。マスターがストップコンディションを出すための準備に、SDAをLowにする準備の部分を拾ってスタートコンディションにしてしまっている!

 NACKのリセットのあと初期状態に戻るのが早い割に、実際にSDAの割り込み処理に来るオーバーヘッドが長すぎ(17μsもある)、次のSCLが立ち上がってしまってスタートコンディションと誤認してしまったのだ。

 しかも、一旦、スタートコンディションと認知してしまえば、割り込みはSDAからクロック(SCL)に移り、このあといくらストップコンディションが来ても無視される。時々動くのは、SCLの立ち上がりの前に割り込みルーチンに来るときがあるからだ。このときは問題なく動く。よーし、間違いない。すべては氷解した。

 原因はわかった。しかし、SDAの割り込み遅れを早くすることは出来ない。そもそもは、ACK/NACKビットのSCLの立ち上がり中にリセットしてSDA割り込みを待ち受けること自体が違反だ。ここはSCLが下がって次のステージに入ってから、スタートストップコンディションを待ち受ける体制にするべきなのだ。

I2cslave_85  ACK/NACKビットのステートマシンのところに、SCLが次のブロックに行くまで待つプロセスを入れて、これまでのタイムアウトは完全に解消された。連続データは勿論、(2)のリピートスタート処理も全く問題なく動く。

 いやあ素晴らしい。仮説に基づき、ロジアナで少しづつ事実を追いながら原因を突き止めた。「デバッグは外へ、外へ」という格言どおり、原因は意外なところに潜んでいたのである。

ソースコードの公開。readmeもつけた(10/30/2015)
 紙数が増えてきたので、(2)や、(3)の機能の説明は、添付するソースコードのフォルダーの中にあるreadme.txtにまとめて書いたので、そこを参照頂きたい。回路図も念のため掲載しておく。

 冒頭でも述べたが、このソースコードはSR04というセンサーユニットをI2Cで動かすための機能と、連続データの入出力などのテスト機能が入った、汎用的なモデル機能をデモするプログラムで余り実用的なものではない。

 このソースを参考に、ご自分の用途にあったI2Cスレーブのプログラムを開発されたい。そういう意味では、余計な機能や冗長なコードがまだ沢山残っており、余り自慢できるものではないが、少しでも参考になればと恥を忍んで公開することにする。

以下に、2つのファームウエアのフォルダーとreadme.txtなどをzipでかためたファイルを置きます。同じファイル名でも、以前に公開したファイルと内容は全く異なっていますのでご注意ください。  

「I2CslaveSet.zip」をダウンロード

| | コメント (0) | トラックバック (0)

2015年10月 9日 (金)

Tiny85のI2Cスレーブライブラリー完成。今度もドジなミスで大騒ぎ

Tiny85への換装を考える(9/17/2015)
 Tiny861でI2Cのスレーブソフトが順調に動いたので、本来の目標、8ピンAVRへ換装する準備を始めた。超音波距離センサーHC-SR04が5Vなので、小さなブレークアウト基板に、DC-DCコンバーターと、8ピンAVR(Tiny85を予定)を載せ、EdisonやRasPiのI2Cで動かそうという計画である。

 同種のプロセッサーなのですぐ動くとは思うが、ピン数が少なく外部発振子は使えないので、クロックはこれまでの16Mhzではなく内蔵のCR発振の8Mhzになってしまう。動くかどうかは、やってみないとわからない。不安なのは、デバッグ用のISP-UARTが使えなくなることだ。動作確認が難しくなる。

 ただ、これから使うTiny85はフラッシュサイズが8KBもあるので、機能的にはまだ沢山実装できる余地がある。未開発のスレーブ送信(マスター受信)でのストップコンディション検知や、マスター受信のあとのリピートスタート機能も組み込もうとすれば楽勝だ。

01pa077329  いずれにしてもピン数が絶対的に足らない。ISPでプログラムすると完全に自由なピンは、わずか2本(GND、Vcc、RST、MISO、MOSI、SCKの残り)しかない。プログラムしたあとMISOなどが使えるとしても、全部で5本である。HR04のドライブに2本(エコーとトリガー)、I2Cに2本(SCL、SDA)使うとすると、残り1本しかデバッグ用に残されていない。

 パラレルにすれば、リセットピン(RST)が使え(Dragonも持っている)、1本増えるが、手慣れたISPからパラレルプログラミングにするのも難儀なことだ。というので、苦肉の策として、ISP-UARTの送信(MISO)だけをデバッグ用に残すことにした。ぎりぎりのリソース運用である(これが苦労の原因になるとは露知らず)。

 ここで訂正とお詫びである。前記事などで、8ピンAVRシリーズにはUSI(汎用シリアルインターフェース)がないと言っていたが、良く調べると、ないのは旧型の15や、最近の13などで、25,45,85には、ちゃんとUSIがついていた(ChaNさんのAtmelの紹介の表にあるIICは誤り)。失礼しました。とはいえ今さらUSIに戻るわけにもいかない。GPIOによるI2C化を進める。

秋月とAitendoで同じ超音波距離測定センサーを入手する(9/19/2015)
  このところご無沙汰だった秋葉原を久しぶりに訪れた。秋月電子の店内がすっかり模様替えしている。マルツと同じように部品棚が店内両側の高いところまで立ち並ぶ形式である。マルツと違って棚の奥に人が歩けるくらいのスペースが空いていて店員の補給路になっている。

 今日の目的は、秋月が同じ超音波距離測定センサー(HC-SR04)を、Parallaxのオリジナル品(¥3000近い。最近見たら¥3980に値上げ)と並行して売っているのを知ったのと、Aitendoにも同一品が出ているようなので、ついでに2つとも買ってしまおうというものだ。

 秋月のあと、足を伸ばしてAitendoの直営店に向かう。ここは秋葉原というより御徒町に近い。人気の少ないオフィス街を歩いて、エレベーターに乗り3階に着くと、意外な光景が広がっていた。

 土曜ということもあるが、店内が客で溢れているのだ。驚いたことにベビーカーが2台もはいっていて家族連れまでいる。自分のようなお年寄りから、おたくっぽいリュック姿の太目の若者まで、まさしく老若男女が真剣な目つきで部品を選んでいる。 02pa077338

 前にも書いたが、いかにも中国人らしい若い女性店員は意外にも商品知識が豊富で、SR04の展示場所を迷うことなく案内してくれた。面白そうなものが沢山あったが、広い店内(秋月より明らかに広い)と人に少し圧倒されてしまいSR04だけで帰ってきた。それにしても電子工作の裾野が広がっているようで喜ばしい。

3種のSR04の比較テストでは意外な結果が出た(9/20/2015)
 超音波距離測定センサーHC-SR04が、はからずも3種類そろった。せっかくなので、3つの比較テストをした。結果は、
Aitendoで買ったもの>アマゾンで以前買ったもの>秋月電子で買ったもの
の順で、機能に大きな差が出た(値段はすべて¥400近辺)。

 秋月電子のSR04はスイッチサイエンスが告知した通りの不具合品で、一定の期間の距離測定では問題ないが、一旦、3mを超す距離を測定しようとすると、echoパルスがHighのままとなり、triggerパルスを出しても元に戻らない。電源を切って再投入する必要がある。

 アマゾンで買ったものは、3mを超すとエコーパルスがHighのままになるが、トリガーをかけると復帰する。一方、Aitendoのものは、距離が長くてもエコーパルスがHighのままになることはなく必ず復帰する(パルスはある距離を超えると一定の長さになる)。

 不思議なことに秋月のものでも物理的なショックを与えると、正常に戻る。アマゾンで買ったものと、秋月のものとは基板のパターンは、スイッチサイエンスの言う駄目なロットと同じように見えるが、良く調べてみると微妙なところに違いがある。

 例えば、秋月の製品は、クリスタルのところの小容量のコンデンサーが省かれており(パターンもない)、パスコンもいくつか省略されている。Aitendoのものはシルク印刷の状況から見るとスイッチサイエンスのいう正常な旧製品と同じように見える。

 しかし、買ってきたものが、それぞれひとつだけなので、すべての商品が上記のようになると断定は出来ない。たまたま所長の買ってきたものが、そうだったというだけである。誤解のないように。まあ、実用に使うなら秋月のオリジナルのParallax社のものが間違いないだろう(高価だが)。もっとも秋月のものでもFETか何かでタイムアウトをとりリセットすれば使えないわけではない。

プリンターを買い換えて、旧型をリサイクルセンターへ葬る(9/21/2015)
 珍しく仕事が入って、プリンターを使う機会が増えた。10年近く前に買ったカラーレーザー(コニカミノルタ 2530DL)は、印刷機能はまだ十分働くのに、最近は紙送りが不調で、最初の一枚か二枚を必ず失敗する。

 だましだまし使っていたのだが、遂にエラーが復帰せず、3枚以上の印刷が不能になった(必ず3枚目で紙送りエラーになる)。使い始めてからの年数を正確に調べてみた。8年と11ヶ月、およそ9年である。微妙な年数だ。ウェブで調べると、同程度のプリンターなら1万円台で入手可能だ。ドラムがそろそろ寿命だし、修理に出しても、軽くこれ以上の修理代金をとられる可能性は高い。

 大分前から迷っていたのだが、結局新しいプリンターに更新する決意を固めた。買うことは造作がないが、困るのは古いプリンターの処分である。20kg近い重量があり、地下から1階に上げるだけでも大仕事である。

 それに、まだ十分動く(恐らく紙送りのセンサーあたりを交換するだけ)のに粗大ゴミに出すのはあまりにも忍びない。地球環境にやさしくない。ウェブで探してみると沢山の廃棄処理業者のサイトが出てきた。送料だけで無料で引き取ってくれるらしい。

 直接持ち込めば梱包もいらないという、ある業者のコピーに惹かれて東村山にあるリサイクルセンターに車で持ち込むことにする。 あと始末に困っていたが助かった。ただ20キロ近い箱を運ぶのは、地下から玄関を出て車に入れるだけで一大事業だった。海外旅行に使ったカートが思わぬところで役に立った。何とか腰を痛めずに車のトランクに入れる。

 自宅から小一時間で現場の処分場に着く。雑木林に囲まれた倉庫のようなところで愛想の良いおねえちゃんが迎えてくれる。あらかじめかけた電話も親切だった。レーザープリンターのほかに、自作のデスクトップPC、長女のこわれたノートパソコン3点も一緒に引き取って貰った。

 すべて無料である。身元を証明するものは不要(無料だからか)で、控えに住所氏名を書くだけである。部品どりが沢山行われることを祈って現場を後にした。合掌。

Nec5750c_2  新しいレーザープリンターは正価が8万近くするが、何故かネットで1万前後で売られているNECの5750Cを選んだ。DTP屋さんが、べた褒めしているサイトが検索上位にランクし、思わずポチッとしてしまった。値段は肩の力の抜けるこれまでの1/3の¥13,500。2日ほどで届いた。

 早速テストする。何の問題もなく動いた。前のコニカミノルタに較べると少し大きいが静かだし、早い。画質は確かに良くなった。文字も綺麗だ。もっとも、この間には10年近い年月が流れている。これぐらいの進歩は当たり前なのだろう。

久しぶりの家族旅行。世界遺産の白川郷へ(9/27/2015)
03p9257251_2

 次も、電子工作ではない話である。長女夫婦が岐阜に転勤になったので、家族と一緒に車で岐阜に遊びに行った。暫くぶりの長距離ドライブである。また第二東名を飛ばす。かなりの雨だったが、第二東名の路面からは全く水しぶきがあがらない。高速走行での雨は路面に溜まった水がハイドロプレーニング現象などを起こすので神経を遣うのだが、その心配もなく実に快適だった。

 岐阜に着いて少し早めの夕食の後、長女たちの案内で鵜飼を初めて鑑賞した。鵜匠たちが宮内庁職員だったとはこれまで知らなかった。格調が高いのである。ただ鵜飼そのものは、雨で川が増水して流れが速かったせいか、あっという間に通り過ぎ、ちょっと物足らなかった。

02p9277313_3 04p9277312_2

 鵜飼の写真を載せたが、すべて手ブレとピンボケでまともな写真にはならない。そりゃそうだ。動く舟の上から、篝火だけの光源では無理だ。ストロボもよほど強力でなければ効かない(恐らく禁止しているだろう)。雰囲気だけでも感じていただきたい。

 次の日は明治村を何十年ぶりかで再訪問し、最終日は世界遺産の白川郷まで足を伸ばした。このあたりは、40年近く前に、自動車(オンボロ自家用車)で通ったことがある。もちろん白川郷までは行けず、深い谷筋を延々と辿ってやっとのことで通り抜けた記憶がよみがえる。 01p9277326_2

 しかし、今は岐阜から白川郷まで自動車専用道路だけで行けるのだ。スイスアルプスにあるような山間(やまあい)に雄大な曲線を描くインターチェンジを通り、10キロを越す長大トンネルを抜けて目的地に着く。道路網の進歩には驚くばかりである。まさしく隔世の感である。

 初めて訪れた世界遺産の白川郷は、外人観光客であふれかえっていた。コスモスと稲穂が合掌造りの民家に良く映えていた。紅葉や積雪時も美しいだろう。ただ残念なのは合掌造りの家が着実に減っていることだ。昔の写真と較べると良くわかる。まあ、ここは完全な保護区ではないので無理と言えば無理な話だが。

Tiny85のI2Cがうまく動かない(10/2/2015)
 旅行から帰って、電子工作を再開する。Tiny85への換装は仕様をまとめただけで実際の作業は始めていない。小さなブレッドボードにTiny85を載せてテストボードを追加する。861から85 へのソフトの変更は、クロック変更によるタイマー設定の変更、GPIOピンの再設定ぐらいである。テスト用のUARTは送信部分だけ残し、受信側は省略する。

I2c_85full  大した作業ではない。ほどなく完成して、早速テストに入る。CRクロックなのでUARTの速度を少し落とす(38400 -> 19200)。UARTは無事Welcomeメッセージを出した。しかしI2Cの方は、どうも安定しない。マスター書き込みは何とか動いているが、読み込みが全くだめだ。

 デバッグ用のUARTメッセージだけでは原因がつかめない。得意のロジアナへのプローブは一本たりとも使えない。読み込みのステートマシン部にカウンターを設けて、UARTで動作を確認していくが、いくつもの不審な動きを見せて安定しない。

 まず、マスター受信バッファーとデータ配列の順番がおかしい。データはSR04の距離データを使っているのだが、1バイトずれている(これはいつのまにか直ってしまった)。それに、マスター受信のビットの送り込み回数が本来の24回(3バイト)のはずが、もう1バイト多い32回になっている(あとになってみれば、それは現状を正しく表現していたのだが、このときはわからない)。

 I2Cそのものの波形をロジアナでとってみると奇妙なことばかりだ。想定もしないところにストップコンディションが発生して通信が中断されているし、データはもともと全く狂っている。しかし化け方に規則性があるのが悔しい。ロジックで間違っていることは明らかだ。

今度も馬鹿馬鹿しいミスで、1週間を無駄にした(10/6/2015)
 ソースを追っかけては、メモ用紙にSCL、SDAのチャートを描き、動作を検証する。しかし間違っているところを見つけられない。第一、861では何の問題なく動いていたのだ(クロックは1/2になっているが)。Tiny861からTiny85への移植だけで、こんなにトラブルになる理由がわからない。

 何度か、ステートメントを換えて(SCLクロックを割り込みではなくwaitで待つなど)、動かしてみたが改善されない。クロック遅れで起きるのなら、状態が時々変わりそうなものだが、データの化け方は一定している。これが悔しい。

 いい加減、嫌気がさして(大きな目標があるわけでもない)、そろそろTiny85でスレーブを作るをもう止めようと思い始めた。それでも最後に、プログラムの動きを探るプローブ点を一つだけ作って、動きを確認し、それでもだめなら潔くTiny85を諦めることにする。

 マスター読み込みルーチンの動きだけでも調べれば何かがわかるだろう。テスト用にSR04のトリガーピンを使っても当面問題はなさそうだ(ユニットが勝手に動くだけ)。というので最後の手段、トリガーピンのGPIOにデバッグ用のプローブステートメントを当て、テストしてみた。

I2c_85lowintpt  これが大当たりだったのである。ロジアナの画面には目を疑う波形が現れた。何ということだ。最初のSCLの立下りのあと、複数の割り込みが入っている波形がでてきたのだ。何だ、何だ、これは何だ。ロジアナに記録されないSCLの動きがあるのか。暫く考えて、いや違う、もっととんでもないことに気が付いた。

 なに、SCLの割り込み設定をやっているか?あ、あ、あっ、861から移植するとき、UARTの受信ピンに合わせて削除したままなのではないか(861の外部割込み設定は共通)。その通りだった。外部割込み設定を未定義のビット0、0「Low割り込み」のまま動かしている。

 それにしてもなぜこれに気が付かなかったのだろう。マスター書き込みは、1バイトだけで間隔が狭いので、「Low割り込み」でも問題なく動いたのだ。一方、マスター読み込みは、多バイトで、マスターは1バイトづつ関数で送るので、バイトとバイトの間に少し間が開く。で、ここで複数回の割り込みが起きてトラブルになっていた。受信回数が想定より多いのは、このせいだったのである。あああ、もう少し深く考えれば、この状況を解明できたかもしれない。

 外部割込みの設定を(0,0)ではなく立下りの(1.0)にして、Tiny85は何ごともなかったようにI2Cのマスター読み込みを実現した。何度やってもエラーは全く起きない。タイムアウトもない。ああ、良かった。あきらめずに頑張って本当に良かった。このまま挫折していたら電子工作そのものの熱も冷めるところだった。

Pa097340  やれやれ、今度のドタバタ劇も、幕を開ければ、実にくだらないミスだった。しかし、こういう解決は、変な話だが妙にすがすがしい。これまでの暗雲が、すっかり晴れて、人生が明るくなる。これまで暗かった周りの世界が一変し、ものみなすべてが自分に対して好意を持ってくれるかのような変化だ。これだから電子工作はやめられない。

| | コメント (0) | トラックバック (0)

2015年9月14日 (月)

Tiny861のGPIOによるソフトI2Cスレーブソースの公開

 久しぶりにプログラミングに熱中していた。AVRのGPIOだけで動くI2Cスレーブインターフェースのライブラリ開発である。前の記事で、曲りなりにもデータの送受信が出来たことはお伝えしたが、安定して動作するまでには、やはり相当な時間が必要だった。

 ソフトI2Cスレーブを作ろうと思いついたきっかけは、前記事のとおり超音波距離測定ユニットHC-SR04の出力インターフェースをI2Cにするためである。超廉価な中華コピー品のSR04のインターフェースはアナログで、トリガーをかけると、距離に応じた長さのパルスを返してくる。しかも電源が5Vなので、EdisonやRasPiとは相性が余り良くない。P9147220

 で、ミニ基板にDC-DCコンバーターと、I2C変換用の8ピンAVRあたりを載せたブレークアウト基板を作れば面白かろうと始めたのだが、これがえらく難しい。巷(ちまた)にGPIOだけでI2Cのスレーブインターフェースを実現した制作例が極めて少ない理由が良くわかった。

 難しい理由はI2C通信の特徴であるスタート/ストップコンディションの認識である。マスター側は作る方だから楽だが、スレーブ側でこれを検知するのはとても厄介だ。プログラムを割り込み駆動にしなければならないため、よほどCPUクロックを早くしないと、2本(データとクロック)の割り込みをとりこぼしてしまう(あとから来たものが無視されるか遅れで正しい判断ができない)。

 I2Cスレーブと言えば7年前、AVRのTinyシリーズについているハードの通信インターフェースUSI(Universal Serial Interface)を使ってライブラリを作成し公開したことがあるが、USIには、もとからスタート/ストップコンディションを検知する特別なハードがついているのでこの難しさはない。

 今度の最終ターゲットであるTinyの8ピンシリーズには、そもそもUSIがない。出来ないとなると無性に作りたくなる性格で、今度もかなり強引なテクニックを駆使して(前記事参照)、GPIOだけでI2Cのスレーブインターフェースをでっちあげた。

 さらに、一工夫してリピートスタートコンディションも受け取れるようにした。まだテストが十分ではないので、胸を張れる状況ではないが、今のところ問題なく動いている。テストバージョンとしてソースコードをとりあえず公開することにする。

 さて、これがどういう風に出来上がったのか。例によっていつものドタバタ劇をご紹介する。

データが化ける。ロジアナでは正確なのに(8/25/2015)
 テストベンチはブレッドボード上である。Tiny861が2台載っており、一台は超音波距離測定ユニットHC-SR04がつながり、こちらがスレーブである。I2Cインタフェースの相手方の861はマスターで、両方ともテスト用のUARTで実行処理の制御と結果の表示をする。

P9157222  テストは、双方のUARTコンソールにコマンドを入れてはメッセージを確認し、ロジックアナライザーで波形を調べる。そのくりかえしである。前回記事までに、1バイトのマスターからの送信(コマンドのつもり)と、2バイトのスレーブからマスターへのデータ読み込み(データ送出のつもり)は、単独では成功している。

 スレーブ側のソースはライブラリを意識して、I2Cのインターフェースすべてをソースファイルひとつ(i2c_slave.c)とヘッダーファイル(i2c_slave.h)につめこんだ。メインであるi2c_HR04_861.cに組み込んだのは、SR04のドライブ部分だけでI2Cスレーブ機能とはすべて関数経由でやりとりする。データは直接渡さない(外部参照もさせない)。

 I2Cのスレーブ側は、すべて割り込みによって始まる。通信が始まってからは、クロック(SCL)のエッジを追っていけば良いのだが、通信シーケンスの最初を示すスタートコンディションは、SCLがHighのときにデータ(SDA)がHighからLowに下がるという決まりになっている(送受信中はSCLがHighのときにSDAが変化してはいけない)。これが厄介である。

 前の記事にあるように、これをSCLとSDAの双方とも割り込みで受けようとすると、割り込みのオーバーヘッドが大きく、よほどI2Cそのもののクロックを遅くしない限りスタートコンディションを把握できない(I2Cの転送速度は100kbpsが目標)。I2c_writeok

 そこで今回は、最初、SDAの割り込みだけを待ち構え、SDAがHighからLowになったとき、SCLを調べてスタートコンディションを判定し、そのあとすぐSDA側の割り込みを止め、SCLの割り込を有効にして、このあとのデータシーケンスをSCLのエッジで受け取るという裏ワザに近いロジックを考え付いた。これで何とか多バイトの送受信に成功した。

 しかし、最初は良いが暫くするとデータの中味がおかしくなる。それに、マスター書き込みのあとのマスターからのストップコンディションを認知していないので、通信はタイムアウトで終わるしかない。こんな状況ではまだとても実用になるレベルではない。さらなる作りこみが必要である。

 不思議なことに、字化けはロジアナで見る限りマスターは常に正しい値を送っているのに、スレーブが違った文字として受け取っていることである。もっとも、I2Cはピンの入力方向設定(HiZ)とプルアップ抵抗でHigh(1)となり、ピンの出力方向設定でLow(0)になるという微妙な仕掛けで0、1を表現しているので、このロジアナの示すデータが本当にスレーブ側のピンの状態を示しているのかは自信がない。

UARTとかぶっていた。これは解決。次はストップコンディション(8/27/2015)
 何度もテストを繰り返すうち、不具合に種類が2つあることがわかった。ひとつは先のデータ化けだが、もうひとつは通信エラーである。タイムアウトのおかげでプログラムはハングしないで戻るが、通信そのものがおかしくなっている。

 こちらの方は、ロジアナのプローブをスレーブのテスト用UARTの前後に入れてみて原因が判明した。時間的には十分離れていると思っていたUART出力部が、I2Cの最後の方と被っていたのだ。このUARTはソフトUARTで送信のときは割り込みを禁止している。これが割り込みで動くスレーブシーケンスの中に入ると目茶目茶になるのは当たり前のことだ。

 究極の解決ではないが、適当な待ち時間をデバッグ用のUART出力の前に入れて衝突を回避した。これで通信エラーは全くなくなった。データ化けは根が深そうなので、もうひとつの課題、ストップコンディションの認識が出来ないか、ロジアナの波形やウェブの情報を元に頭をひねる。

 現在は、受信も送信も、マスターから送られたストップコンディションを認知せず、通信終了はタイムアウトに頼っている。実用的にはSR04の距離測定の最小間隔は、人間相手なら0.5秒前後、ロボットに使っても0.1秒程度(そもそもSR04の測定時間が30ms近く必要)なので、100ms程度のタイムアウト(テストのため現在は1秒)で問題ないのだが、ライブラリとして公開するためには、何とかストップコンディション認知を実現させたい。

ストップコンディションのキャプチャーに成功(8/28/2015)

 ロジアナの波形を目を皿のようにして分析しているうち、ストップコンディションが出される場所はノーマルなときは必ず決まっていることに気付いた。1ブロックのデータの送受信が終わって、ACK/NACKを採取(または発行)するビットのあと、次の最初のデータ(第一ビット)のSCLパルスの部分しかストップコンディションは発行されない。

 もちろん、本式のハードのI2Cはデータストリームの途中でも、スタート/ストップコンディションを拾えるようになっているのだろうが、ソフトI2Cにここまでを要求するのは酷だろう。ストップコンディションが出てくる場所が限定されているなら実装は可能だ。

 つまり、データをマスターから1ビットづつ受け取るステートマシンのステップで、第一ビットのSCLがHighの段階でデータをとったあと、割り込みを抜けずにSDAの変化をそのままループで調べ続ける。SCLが下がるところまで調べて、割り込みルーチンを抜ける。

 SDAに変化がないときは、ペンディングになっていた立下りの割り込みがすぐここで入って通常通りのデータ処理が続く。SDAが変わっていたら、これがストップコンディションである。処理を中断して通信終了処理をする。I2c_slaveok_2

 うむ、我ながら良くできた。動く予感がする。いそいそとステートマシンのマスターデータ書き込みの部分にコードを加える。たいしたコード量ではない。何度もロジックを確かめて、テストに入る。

 マスター側のPCコンソールからデータを送る。スレーブに送られたデータがPCのスレーブ側のUARTに表示される。 これまでは、このあと必ずタイムアウトのメッセージが出ていたのだが今度はどうだ。おーし、いくら待ってもメッセージは出て来ない。良いぞ。何度も確かめて、タイムアウトしないことを確認する。

 データはまだ化けてしまうが、送信のストップコンディションの認知には成功したようだ。思っていたロジックが絵に描いたようにうまく動いたときは、どんな小さなものでも格別に嬉しいものだ。何度もコマンドを入れては子供のように喜ぶ。

16Mhzにクロックを上げると安定するが、改善せず(8/29/2015)

 字化けの問題である。不思議なことに、マスター読み込み(スレーブ送信)の方はほとんどないのだが、マスター書き込みは正しいのは最初だけで、そのあとは殆ど字が化ける。書き込み宣言のアドレス読み込みはエラーとなったことがないので、おかしいのは、データ書き込みのステートマシンのところであることは明らかだ(ビットハンドリングは全く同じロジックである)。

 ライブラリを意識しているので、I2Cのデータは、すべてバッファーに貯め非同期でメインとやりとりするようになっている。このあたりがあやしい。I2Cの送受信シーケンスのミスというより、バッファーのハンドリングがうまく行っていない可能性が高い。

 ということで、バッファーの中味をダンプするコマンドを追加して、送られたデータの中味を検証した。しかし問題はなかった。多数バイトのバッファーでも正確に、データを入れ込んで最後でまた最初に戻る。データの汚れは、これ以前に起きている。バッファーの中を誰かが汚しているわけでもなさそうだ。

 マスター受信の方はほぼ完全である。NACKがとれないのが問題として残るが、データは問題ない。しかし送信で相変わらずデータが汚れる。ロジアナでは全く問題ないのに何回かやるとデータが化けてくる。化け方が気に入らない。何かビットが増えて行くような感じである。

 そうなると原因は、I2Cのデータを読み込むビットハンドリングに疑いがかかる。前から気になっていたのだが、SCLの割り込みから実際に割り込みルーチンに制御がわたるのは、8Mhzのクロックで早くても5.4μsかかっている。

 I2Cの現在のクロックはおよそ60kbpsで、SCLが0の区間は、8μs。次のSCLの立ち上がりに近くちょっと不安である。もしかすると、次のSCLクロックにはいってしまってエラーになっている可能性がある。

 というので、意を決して、スレーブのCPUクロックを上げることにした。8Mhzから倍の16Mhzにしてみる。ロジアナで見ると、割り込みのオーバーヘッドは、半分の2.7μsまで下がり、波形がずいぶんすっきりした。ack/nackの判定ビットの処理も余裕である。しかし事態は改善しない。マスター受信は問題ないが、マスター書き込みはゴミが出る。頭が痛い。

最後はやっぱりドジなミス。I2Cスレーブとりあえず完成(8/31/2015)
 この1週間頭を悩ませていた不具合は、解決してみたらどうしてこれまで気が付かなかったのだろうという、またもお馬鹿な不具合だった。同じような文章をこれで何度書いたことか。

 ここに書くのもお恥ずかしい、単なるバッファーのクリア忘れである。データはビット単位に送られてくるので、1ビット単位のORで受ける。1バイト受ければ、バッファーの次のバイトに移る。これを使い増ししたら、次の回からは、前のデータにORがかかってデータは化けるというわけである。

 ははは、情けなくて笑うしかない。タイミングとデータライン(SDA)のHiZ化、ACK/NACKのときのSDAの値など微妙なところを探し回っていたが、問題は全く別の基本的なところだった。クロックなど上げなくても良かったのだ。

 変数の初期化忘れなど初心者がやるミスである。バッファー経由なので、ビットを受けるところは毎回新しいデータで始めているとばかり思っていた。ソースコードをよく見れば、ORを受けるところがバッファーの配列であることにすぐ気が付くはずなのに、思い込みと言うのは恐ろしい。

 送信がうまく行くように見えたときは、同じデータを送っていたからである。ああ、何というお粗末。これを直して、データの汚れは全くなくなった。やっと一歩前進である。肩の荷が下りた。あとは、マスター受信をタイムアウトでなく、まともなストップコンディションで、通信を終了することだ。

遂に送受信ともOK。GPIOによるAVRのスレーブインターフェース完成(9/1/2015)
  やった、やりました。久しぶりの勝利の美酒。マスター読み込みが最後までトラブっていたが、本日、遂に、タイムアウトを起こさず、一連のデータ送信(スレーブから)が問題なく終了した。I2c_readok

 マスター読み込みは、通信の終わりにマスターからNACKビットが来るのでストップコンディションを調べる必要もない(マスターは送っているが)はずなのだが、このNACKを認めず、常にタイムアウトになっていた。

 送信のエラーがとれて余裕が出来たので、ロジアナのプローブをさらに追加し後処理のプロセスに入れ、受信のシーケンスを仔細に追った。その結果、意外なところが原因であることが分かった。いやいやロジアナさまさまである。

 実は、NACKを認めていなかったのではなく、プログラムはNACKを見てとっくに通信を終了させていたのだが、次のストップコンディションの発行をスタートコンディションと勘違いして、この通信のタイムアウトが発生していた。これがタイムアウトの正体だった。

 間違っていたのは、スレーブ側ではなく、何と送り側(マスター)のストップコンディション発行の仕方だった。ストップコンディションの前に準備するSDAとSCLの変化のタイミングがロジアナを見ると少し短すぎる。このためSDAの変化の把握が割り込みで遅れ、SCLがHighになったところで認識されるのでスタートコンディションになってしまっていたのだ。

 うーむ、これは現在のロジックでは解決できない。暫く、頭を抱えていたが、SCLの変化を少し遅らせればこれは回避できることに気が付いた。 マスターでのロジックにwaitを加え試してみる。めでたくスレーブ受信のタイムアウトはなくなった。

 あわてて、おおもとのNXP社の正式仕様を調べる。P48に、スタート/ストップコンディションのSDAとSCLの変化は半クロック(100kbpsで4μs)空けることというスペックを見つけた。良かった。マスターの修正はスペック通りだった。いやあ気分が良い。

 だいぶ、I2Cに自信がついてきた。特に、最初良くわからなかった、データラインのChaNさんの方式(入力方向にしてラインHigh、出力方向にしてLow)が完全に理解できたのは大きい。I2Cの基本の部分である、プルアップされたライン上で複数のディバイスの間で通信するテクニックである(ワイヤードORというのだそうだ)。

 これまでは見よう見まねでI2Cマスターなどを書いていたが、こんな複雑な(面白い)しかけがあったということがわかっただけでも(いまさらながら)、こういう自作ならではの収穫である。Arduinoなどのラッパー製品を使っているだけではまず出来ない経験だろうと胸を張る(単なる負け惜しみに近いが)。

 お約束のソースコードの公開は整理してからと考えたが、少し気が変わった。このテストステートメントてんこ盛りの形のままの方が、かえって参考になるような気もする。何に苦労したかが一目瞭然で情報量は多い。整形した完成品のソースより参考になると思う。

最後のシーケンスの連続化でまたてこずる。しかし遂に完成(9/5/2015)
 とはいうものの、もう少し動かして動作を確認しておいた方が良いだろう。当初予定したSR04とI2Cの送受信の組み合わせも動かしておきたい。これが動けば大威張りだ。自信を持ってソース公開に踏み切れる。

 マスター側からコマンドを送って、SR04の測定をスタートさせ、得られたデータを送り返させるシーケンスである。これが当初の目的である。I2Cを使ったSR04の制御の第一歩だ。ところが、これがまた難航したのである。 I2cuartng

 送信、受信とも個別では全く問題なく動作する。ロジアナで見ても、綺麗な波形が想定通りに出ている。今度は、これの組み合わせだが、やることは同じだ。簡単に動くだろう。マスター側のプログラムに手を入れて、通信シーケンスを出すコマンドを作って動かした。

 これがまた全く動かない。やれやれどこが悪いのか。ロジアナで波形を見る。ありゃりゃあ、書き込みが終わった後の読み込みのシーケンスがでたらめである。そもそも最初のスタートコンディションを全く拾っていない。これは何か別のスレーブでの動作が邪魔していることは明らかである。すぐ原因に思い当った。最大の容疑者はUARTだ。ここのUARTはソフトUARTなので文字送信中は割り込みを禁止している。

I2cuartok  ロジアナに、送信関数の割り込み禁止部分にGPIOピンをあてて、波形をとってみたら一目瞭然だった。考えてみたら至極当然のことなのだが、マスター側で待ちを予想してwaitをとっていたのだが圧倒的に少なすぎた。今度もロジアナのお世話に大変なった。いやあ、こいつは無敵だ。

リピートスタートコンディションの認知も出来た(9/12/2015)
 最後に残ったリピートスタートコンディションの実装である。EEPROMのI2Cのように、コマンドを送ってストップコンディションを発行せず、再びスタートコンディション(リピートスタートコンディション)を出して、データ読み込みに切替え、1シーケンスでデータを受け取る機能である。

 今度のSR04のシーケンスでは使いにくい(測定に要する時間が長すぎて1シーケンスにしにくい)が、内部のディバイスの状況を伝えるときには便利で実装しておきたい。それに、ストップコンディションを実装しているとき、ここに少し手を加えれば、リピートスタートコンディションもすぐ作れそうな感触だった。

 久しぶりの仕事があって電子工作に手が出ない日が続いていたが、一段落したので早速、リピートスタートコンディションの実装にとりかかる。かねて考えていた通り、マスター送信のストップコンディション検知部にコードを追加する。if文にelseを加えるだけである。

 ほどなく出来上がった。こいつはテストが厄介で、送り側のプログラムにも手を入れる必要があるが、乗りかかった船である。黙々とこちらも準備する。マスター書き込み宣言で1バイト送った後、連続してスタートコンディションを発行し、マスター読み込みのシーケンスを送り込むコマンドである。

 スレーブ側バッファーに残っているSR04の距離データを呼び出すコマンドである。スレーブ側は、多重処理になるのでスレーブ側のテスト用のUART出力は厳禁だ。慎重にwaitステートメントを入れてUARTをずらす(これがないとやっぱり不安だ)。

 案の定、頻々とエラーが起きる。うぬー、この _delay_us()のマクロは、ある程度以上の待ちになるとおかしくなって、ちゃんと遅れてくれないようだ。ウェブを見るがどうも要領を得ない。_delay_msなどに切り替えて凌ぐ。I2crepeatok

 ロジアナで波形を見ながら徐々にデータを正確にしていく。最後に残ったのが、リピートスタートをしたシーケンスのあとに、必ずマスター書き込みデータが化ける不具合だった。リピートスタートは、データの第一ビットを読んだあと初期化されるので、バッファーにデータが残る可能性があるのだが、それがどうして汚れるのか理屈がつかない(必ずというのが気に入らない)。

 こうなったら対症療法になるけれど、シーケンスに入る前に必ずバッファーをクリアしてから始めることにした。よーし、直った。これで想定した機能はすべて揃ったことになる(マスター読み込みのあとのリピートスタートコンディションと、ストップコンディションは未実装だが)。I2cslave_861 完成まで1ヶ月を要したが、GPIOだけによるI2Cスレーブインターフェースが完成した。ベータバージョンだけれど、とりあえずソースコードを公開することにする。回路図も掲載した。スレーブの861の空いているI/Oピンは、殆どがロジアナのプローブに使われている。

以下にスレーブ側のソース一式(プロジェクト名がSR04でなくHR04になっています。プロジェクト名を変える方法がわからないのでそのまま。ご了承ください)と、マスター側のプロジェクトをAtmelStudioのフォルダーの形でかためたものを置きます。ソースコードにはあえてロジアナのプローブステップを沢山残しています。ご参考まで

「I2C_HR04_861.zip」をダウンロード

「I2C_861.zip」をダウンロード


| | コメント (0) | トラックバック (0)

2015年8月24日 (月)

電子工作迷走。超音波距離測定(HC-SR04)のI2C化が難しい

 今回もブログの更新が長い間滞った。正直なものでブログのアクセス回数は間違いなく記事更新間隔に反比例する。商売ではないので別に構わないのだが、アクセスが減っていくのを見ているのは余り気分が良くないものである。

 この間、電子工作をやっていなかったわけでもない。むしろ最近になく没頭しているのだが、結果が出ないので記事に出来ないだけである。先月、EdisonのPWM動作をオシロで確認して、実際にサーボを動かしたところまでは順調だったのだが、そのあとがいけない。

 思いつきで始めた全く別の工作にはまり、泥沼から抜け出すことができなくなった。少しづつ動いてはいるのだが、どうもすっきりした形にならない。その工作というのは、タイトルに書いた超音波測定ユニット(HC-SR04)のI2C化である。

 あとで詳しく説明するが、要するにAVRのGPIOでI2Cのスレーブ側を開発して、HC-SR04をEdisonでも動かそうという目論見である。気楽に作り始めて次々に落とし穴にはまって身動きが出来ないでいる。余り日をあけるわけにもいかないので、このあたりで、この一か月の経過をご報告しておこう。

EdisonのPWMで2つのサーボモーターが同時に動いた(7/25/2015)
 前回記事にあるように、mraaライブラリーを使ってEdisonのPWM出力波形をオシロで確認することはできた。次はこのPWM波形で実際にサーボモーターを動かすことである。パンとチルトの角度(0から180)の数字をシリアルコンソールから入力し、PWMパルスに変換する。コンソール入力ソフトは、通常のgetchar()とかfgets()などの標準関数を使う。01p7257211 ただ、Linux(UNIX)の標準入出力関数にはAVRなどと違ってキー入力を教えてくれる関数がない。これなしにコンソール入力コマンドを出すと、そこで処理が止まってしまうので具合が悪いのだが今回はコンソール入力をキーにパンやチルトをやるので問題はない。

 コーディングそのものはたいしたことはない。ただEdison内の開発環境は、まともなエディターもなく(あのviしかない)、リストの印刷もできない貧弱なものだが、紙に印刷してからデバッグするような大層なことはやらないし、ウェブなどで制御するのはまだ先の話だ。

 コンソール入力のフォーマットは、>角度1 角度2(enter)の入力で角度1のパン、角度2のチルトとなり、>角度3(ブランク)(enter) とやれば、角度3のパンだけ、>(ブランク)角度4(enter)とやれば、角度4のチルトだけということにする。

 テキスト入力(0から180までの数字キャラクタ)の解析(パース)は、入力の最後から文字を拾って行くというのが鉄則である。無駄がない。文字列の頭から解析しはじめると泥沼になる。擬似コーディングで何度もシミュレーションして仕上げる。こういうパズル的なコーディングは久しぶりなので楽しい。

 早速テストだ。いきなりPWMにつなぐのではなく、コンソール出力で2つの数字が間違いなくとりこめているかを確認する。2組の数字のときはやさしいが、一つだけの数字のときは、かえって面倒である。

 ふーむ、どうしても、後の組の数字が10倍になってしまう。何度もロジックを見直すが間違っていない。こうなったら、変数を片っ端から出力させてみる。いわゆるprintfデバッグである。

Edisonpwm  文字数を出してみて原因がすぐわかった。標準入力は、文字列の最後に必ず'¥0'(0X00)がついて文字数がひとつ多いのだ。ロジックでは無精してブランク以外を数字(0-9)とみなしていたので、これも数字とみなされ、あとが10倍されていた。やれやれプログラムは書いたようにしか動かない。

 コンソール出力に目指す数字が出たので、本番のPWM入力に進む。こちらは、浮動小数点なので単純に数式をいれるだけですむ。このあたりのCプログラミングはLinuxなのでとても楽である。整数しか使えないときは、変数を32ビットにしたり桁溢れに気を遣ったりする必要があるが、全く心配しないで気楽にコーディングできる。

 以前に開発したmraaライブラリーのテストプログラムのソースをこのコンソール入力のプログラムに足して、いよいよサーボのテストである。サーボモーターの動力はとりあえず手持ちのリチウム電池で独立させる(サーボの突入電流をさけるためEdisonの電源と共用しない)。

 EdisonのコンソールでCプログラムをスタートさせる。プロンプトがでて順調に立ち上がった。数字を入れる。ブルッとカメラが上下と左右に同時に動いた。念のため入れたオシロには、数ミリsec遅れて出る2つのPWMパルスが映っている。

 よーし、動いたぞ。片側だけの数字入力のテストもする。数字出力のテストがすんでいるので、それぞれカメラが、ピッ、ピッと左右上下に反応する。何でもないことだけれど無性に嬉しい。暫く夢中になってカメラを動かして楽しんだ。

(ここにパンチルトの数字をPWMに変えるCプログラムソースを置きます。何かの参考まで)
「pantilt.c」をダウンロード

Edisonで2台目のウェブカメラ完成(7/27/2015)
 サーボがコンソールから操作できるようになったので、勢いに乗って画像も出すようにしてみた。2台目のパンチルト式ウェブカメラである。カメラの操作はSSHで、画面はHTMLなので実用性はまだゼロだが、とりあえずでも動くことをこの目で見ておきたい。

 EdisonのコンソールをPC上で2つ立ち上げて、片側でウェブカメラを動かし、もう一方は、パンチルト操作のCプログラムを動かす。PCの方はブラウザーも立ち上げる。カメラは30万画素の操作キットのカメラだ。

 PCのウェブ画面で映像を確認する。よーし画面がでた。パンチルトのコンソールに戻って、コマンドを投入する。カメラは、ビビッという音と共に所定の方向に向いた。画像は一瞬見えなくなるが、納まると画像が見えて、別のシーンが映った。ははは、出来た、出来たぞ。大きく動かしたときはカメラを固定した蒲鉾の板を手で持っていないと、ひっくり返る。

 しかし、こんな手元でも、自分の手以外で画像が変わるのを見るのは感動である。片側数値だけ(パンチルトどちらか)の操作は、カメラが余り揺れないので画像の乱れは少なくて済む。コマンドの投入で目指した目標にカメラの画面が移動できるか遊ぶ(これは意外と難しい)。02p7257212

 いずれにしても、これで当研究所での2台目のパンチルト操作の出来るウェブカメラが実現した。これの具体的な用途はまだない。猫カメラはアクリルケースに入れないとこいつも攻撃される。でも、まあとにかく一段落である。

 残っていることは、カメラのパンチルト操作を画面の左右上下のバーでやれるようにすることだが、これは所長の不得意なウェブプログラミングになるのですぐには手が出ない。このあたりはアプリケーションによっても大きく仕様が変わるところなので簡単には先に進めない、とやりたくない理由を上げて自己を正当化する。

次の野望は超音波測定ユニットのI2C化(7/28/2015)
 実は前から企画しているプロジェクトがある。EdisonのI2Cシフターを買って来たころ思いついた企画だ。手元の部品箱には、超音波を使った距離測定ユニット(HC SR04)が使用されないまま、ころがっている。一年ほど前にはやったことがあって当研究所も買ってあった。

 昔から秋月あたりで売っている、Parallax社のものと形態がそっくりで、価格がべらぼうに安い。確か通常の電子部品店ではなく、アマゾンなどから売り出され、最近は秋月やスイッチサイエンスなどの電子部品ショップでも売り出した。 Hc_sr04

 どうも中華コピー品らしいが、動作報告がウェブに出るようになり、それほど評判も悪くなさそうだ。なにしろ、オリジナルは¥3000近くしているものが、¥400近辺である。当研究所にいつもコメントを寄せてくれる「ばんと」さんも以前動作報告されている。結構、精度も高いようだ。

 このユニットのインターフェースは5Vでアナログなので、EdisonやRaspiとは少々相性が悪い。このSR04を動かすArduinoのシールドがあるようだが、こちらは今さらArduinoをやるつもりはない。それにEdisonのArduinoボードは大分お高い。

 AVRか何かでI2CでSR04の測定の開始や、測定した距離値をディジタルで送るようにしてやれば、使い道が広がるのではないかと思う。やることは、I2CスレーブのインタフェースをAVR Tinyの8ピンシリーズで実現することである。

 I2Cスレーブと言えば昔々、AVRを始めたころUSIインターフェースのライブラリを開発しているが、これはAtmel社のサンプルソースをほぼ忠実になぞったものでオリジナリティに欠ける。しかも8ピンのAVRはUSIを持っていない。GPIOで作れば今度のやつはスクラッチなので大威張りだ。

まずはSR04距離測定ユニットのテスト。すんなり動いた(7/30/2015)
 おりしも時を同じくして、電子パーツショップのスイッチサイエンスのページに、件(くだん)のSR04のなかに不具合があるという記事が出た。問題があるという新製品の写真を子細に調べると、これはまさしくアマゾンで買った製品そのもので、秋月のものも写真で見た限りは同じである。もし、スイッチサイエンスのページのとおりだとしたら大問題である。

 I2Cの前にここの実装を先にやって、本当に動かないのかどうか確かめてみることにした。I2CレシーブはTiny8ピンシリーズで実装するつもりである。これも時期を合わせたかのように、秋月でTiny85が妥当な価格で売り出された。

 こちらには以前、DigiKeyで送料無料にするゲタのひとつとして、Tiny85をいくつか買ってある(¥200前後だったか)。しかし、これでいきなり開発するのはちょっとハードルが高い。というので、ちょうど手元にあったTiny861で実装にとりかかる。

 このあいだサーボモーターの実験をしたTiny861一式がブレッドボードに残っている。USIを使ったUARTが入っており手間が省ける。割り込みも使わない、タイマーひとつだけで、やってきたパルスの時間を測るだけである。大した時間もかからずにプログラムが出来た。早速テストに入る。

05p7307215_2  結果としては、不具合は全くなく、問題なしに2cmから3.5m近くまで計測が出来た。確かに、3.5mあたりを超えると、Echoパルスが戻らずラインが1になったままになるが、リセットしなければ元に戻らないわけではない。再度トリガーパルスをかければ復帰する。特に問題もない。

 とりたてて大げさに言うような不具合ではなさそうだ。スイッチサイエンスの使っているArduinoのプログラムなどでうまく動いていない可能性が疑われる。タイムアウトを設け、ある程度の時間、パルスが戻らなければ待つのをやめれば済む話である(当プログラムでもそうした)。

04p7307214_2 SR04の動きは確認できたので、いよいよソフトI2Cスレーブの開発に移ることにする。とりあえずは、このTiny861のセットに追加して実験し、うまく動けば、秋月で販売が始まったTiny85あたりで実装することにする。

GPIOのソフトI2Cスレーブプログラムの擬似コーディングは終了(8/8/2015)
 GPIOによるI2Cスレーブの自作はI2Cマスターと違って、そう簡単ではない。最初に触れたように、当研究所では発足当初の7年前、Tiny26でI2Cスレーブを開発したが、これはUSIインターフェース(Universal Serial Interface)というハードを使って、それもソースコードはAtmelのアプリケーションノートを丸ごと参考にして作ったものだ(デッドコピーではないが)。

 今度は、USIのないTiny8ピンシリーズが目標なので、これを利用することは出来ない。あらためてソースを引っ張り出して調べる。割り込み駆動とUSIの機構を駆使した複雑な形だ。GPIO化にあたって重要な課題が見つかった。USIはI2Cのスタート/ストップコンディションを検知するハードを持っているのに、GPIOではこれも手作りする必要がある。

 I2Cスレーブはあくまでも受け身の立場なので、通信ラインのSDA(データ)とSCL(クロック)は、データの採集や、収集とは別に、独立して割り込みをハンドリングしていないと、スタートコンディションなどは採集することはできない。

 あわててTiny8ピンシリーズの割り込みラインを調べた。良かった。外部割込みはひとつだけだが、ピンチェンジが使える。何とか、この石でも2本の割り込みラインは確保できそうだ(デバッグ用のUARTは出力専用になるが)。

 Tiny861は外部割込み2本とピンチェンジ1本があるが、外部割込みは割り込み条件が2本で共通なのは注意しておかないといけない(実は開発途上で発見してえらい目に会った)。リソースの確認をして、いよいよ擬似コーディングにとりかかった。結構、時間がかかる。

 SCL(クロック)のパルスで駆動するのがI2Cレシーブの基本なので、どうしても割り込み関数の中が重くなる。C言語では、レジスターの退避などでタスクスイッチが重くなる。しかし、これはやむを得ない。結局、ソースは、USIを使ったAtmelのアプリケーションノートのと同じような構造になってしまった。

 スタートコンディションを検知するルーチン(SDAのピンチェンジ)が悩ましい。このあたりは割り込みが重なり、オーバーヘッドが気になる。理屈ではこれで良いのだが、果たして考えたように動いてくれるか。3日近くかけて、擬似コードは何とか出来上がった。

ISP-UARTでつまづいている(8/10/2015)
 I2Cスレーブの開発が一段落したので、実際のコーディングの前に、I2Cマスターのドライバーの制作に取り掛かった。I2Cマスターは、これまでに沢山開発しており、参考にするソースは選ぶのに迷うくらいだ。

 秋月のRTC(リアルタイマークロック)を動かした7年以上前のソフト(記念すべき最初の作品、温度ロガー)から、最近のLPCMプレーヤーのI2CインターフェースのLCDドライバーまで沢山ある。一番古いが、みなさんに使ってもらっているRTCを動かしたUSIを使ったI2Cマスターが信頼性が高そうなのでこれを選ぶ。

 そういえば、このソースは、ISPケーブルで動くUARTが不調で、別のGPIOのUARTを使っている。そうだ、ちょうど良い機会なので、このデバッグもしてしまおう。UARTをISP-UARTで動くよう換装する。

 これが、つまづきの始まりだった。やっぱりまた動かないのである。オシロで波形を見てみると、PCからのキー入力は入ってきているが、受信が全く動かない。何かループをしている感じである。デバッガーを入れれば何かつかめるのかもしれないが、この程度でデバッガーをセットアップするのも難儀な話である。ロジアナも、こういう暴走状態の時はあまり役に立たない。

 あーでもない、こーでもないとソースコードを調べるうち、遂に問題点を発見した。発見してしまえば何故こんな簡単な間違いに気が付かなかったのかと思うぐらい、馬鹿馬鹿しいミスなのだが、バグと言うのはこういうものである。ピンチェンジの受信割り込みで、ピンが立下りかどうかを調べるIF文の条件が間違っていた。これまでに何回も経験したつまらないミスだ。

 ポートの1ビットをテストするときによくやる方法で、PORT & (1<<Pin番号)の結果を1で比較していたというお粗末である。最初のコードは、たまたまPin番号が0だったのでこれで動いていたのだが、ピンが移動していたのでバグになってしまったようだ。

こんどは、USIを使った前のI2Cマスターが動かない(8/12/2015)
 ようやっとUARTが動いて、I2Cマスターの動作確認に入る。スレーブはまだ出来ていない。出来たとしてもいきなりつなぐのは無謀だ。当然、確認はオシロで波形を調べることになる。ところが信頼性の高いと思われたUSIのI2Cマスターが思うような動きをしてくれない。

 最初は良いのだが、2回目になると全く波形が出なくなる。電源を切って、再度投入すると、1回目は動くがやはり次から駄目になる。頭を抱える。一難去ってまた一難である。単なるドライバーのつもりのI2Cマスターのデバッグをこれからまたやらされる羽目になった。

 どうもI2Cラインのハード設定がおかしいようである。I2Cのラインインターフェースはとても微妙に出来ていて、単純なポートのオンオフではなく、入出力方向の切替で行う。ラインをハイインピーダンス化する形でラインを上げるようだが、どうもこのあたりの設定がおかしい。

 暫く迷ったが、これ以上USIのI2Cマスターのデバッグをする気力がどうにも生まれない。I2Cのマスターなら、まだ他にも手段がある。GPIOのもあるし、いざとなったらMegaシリーズのハードのI2Cを使うことも出来る。マスターの開発をしているわけではないのだ。

GPIOのI2Cマスターは簡単に動き接続テストに移る(8/13/2015)
 お盆が近づいて事務所もお休みである。猛暑なので外に出かける気も起きない。このところ熱心に通っているジム(ヨガとプール)もお盆休みである。必然として、工作室にこもる時間が増える。日がな一日、電子工作で過ごすが、進展はいまいち順調ではない。

 潔くあきらめたUSIのI2Cマスターに替わってGPIO を使ったものにライブラリをとりかえる。このオリジナルは、ChaN氏のソースで、LPCMプレーヤーのミニLCD(I2C)に使っている。さすがはChaN氏制作のソースである。はなから全く問題なく動いた。

 綺麗にオシロにI2Cマスターの一連の波形が並んだ。始めからこれにしておけばよかった。I2Cのマスター書き込み宣言は、スレーブアドレスがないということで戻ってきているが、これはスレーブ側が動いていないので問題ない。

 いよいよ問題のスレーブのコーディングである。久しぶりに心が踊る。擬似コーディングから実際のソースに落としていく。SCLの両エッジの割り込みを受けて、ステートマシンでビットデータをハンドリングしていくのだが、スタートコンディションの検知と、ACK/NACKを伝えるステージのタイミングが難しい。実際に動くことを祈って、せっせとコーディング。ほどなく出来上がった。 07p8247217

スレーブは、はなからロジアナの力を借りる。(8/14/2015)
 ISP-UARTのトラブルにこりて、ここは最初からロジアナでデバッグを始めることにしている。割り込み駆動のプログラムのデバッグは普通のprintfデバッグでは出来ない。マイクロセカンドオーダーで動く割り込みルーチンに、printfなどのミリセカンドレベルのルーチンを入れたらデバッグにも何もならなくなる。

 久しぶりのロジアナである。あらかじめGPIOピンで沢山のプローブ点を入れ、逐一、ステートマシンの進行を追うことにする。各ブロックの入り口と出口にプルーブピンをいれて、これをロジアナで観察する。これまでのところ最強の解析手段である。

 ブレッドボードに2つのCPUを乗せ、スレーブ側、マスター側それぞれ1つづつUARTを立ち上げ、ついでにSR04も一緒に実装して、最終的には距離がマスター側のUARTに出力されるようにセットした。上には賑やかにロジアナのジャンパーコードが盛り上がる。

 スレーブ側はSR04の測定システムを兼ねており、スレーブのPCコンソールのリターンキーを押せば、距離値が出てくる。マスター側からの指示で、スレーブ側のHR04にトリガーがかかり、測定した距離値がマスター側のUARTに出てくるというのが、当面の最終ゴールである。

 ただ開発の手段が少しわずらわしい。マスター側のUARTをISP-UARTにしたので、スレーブ側のコンパイルの度に、ISPケーブルを抜き差ししなければならない。それでも準備が整って、いよいよマスター側のコマンドでスレーブが動くかどうかを試すところまできた。ドキドキの瞬間である。

驚くべき事実が判明。外部割込みがLowレベルでしか動かない(8/15/2015)
 コマンドを入れる。残念、スレーブアドレスがないというすげないメッセージである。これは想定したことで、むしろ、ロジアナの波形の解析が重要だ。すぐにロジアナの設定にとりかかる。

 ロジアナをスタートさせて、再度コマンドを打つ。出た出た。ロジアナから色とりどりの波形が出た。このロジアナにはI2Cのプロトコルアナライザーがあるので、まず、それの確認だ。いくつか設定して、無事、オシロで見ていたのと同じ波形が出ていることを確認した。

 しかし、GPIOピンで発生させたロジアナの波形(事実)は目を疑うものだった。まるででたらめに割り込みが起きているとしか思えない。SDAに設定したINT0とSCLのINT1の外部割込みの出方が考えた通りのところで全く起きていないのだ。I2c861

 やっぱり懸念した通り、オーバーヘッドが大きくて、割り込みがまともに動いていない。いくつかの割り込みは無視されている。特にSDAの割り込みは両エッジで動かなければいけないので、この間のSCL割り込みが見えなく、このままでは全くデータ収集(送出)ができない。それにしても、割り込みの起き方が不審である。エッジと一致していない。

 良くわからないので、まずは割り込みをひとつだけ(SCLの動き)にしてみる。おやあ、割り込みの出方が変わった。外部割込みは、立ち上がり、立下り、両端など発生条件を選べる。変えてみるが、全く変化がない。調べているうちに、これはLowレベル割り込みではないかと思われる状況だ。

 INT0(SCL)からINT1(SDA)に替えてみる。やっぱりそうだ。SDAはSCLに比べて変化が少ないのでそれがよけいはっきりわかる。だれかが割り込み条件を設定するMCUSRをいじったかもしれないので、プログラムのループの始まる直前でMCUSRそのものを出力してみたが、正しい設定になっている。

 それでも割り込みの起きる状態は、設定レジスターが00のLowレベル割り込みの設定と考えると合った動きをしている。I2Cのピンで使うと割り込みは、正しく設定できないのだろうか。まさか。

お馬鹿なミス。MCUSRとMCUCRを間違えていた。2日間の無駄(8/17/2015)
 Tiny861が悪いのか、それともこのチップだけが悪いのか疑って、手持ちと交換したが同じ(当たり前か)。ウェブにそれらしいエラータ情報はない。こんな基本的なバグが市販のチップにあるわけがないと思うのだが、現実には、全く想定した割り込みになっていない。

 どこも悪くないので、今度もCPUの種類を換えてみることにした。Tiny861からTiny2313に換装しようとソースを見ていた時である。861と2313とは外部割り込みの設定レジスター名は殆ど同じだが、念のため割り込み設定レジスターMCUSRを見てみたら、2313ではMCUCRになっている。

 えー、ここだけ違うのと861のデータシートを見たら同じMCUCR!! えっえっえー、ソースを見る。確かにMCUSRだ。何というお馬鹿な話だ。たちの悪いことに、MCUSRというレジスターは、861に存在し、コンパイルエラーにはならない。全く無関係のレジスターに設定値をえんこらえんこらセットして動かない、動かないと騒いでいたわけだ。情けなさに冷や汗が出る。

 気を取り直して、レジスター名をMCUCRに替えてテストする。ちゃんと割り込みは、立下りや立ち上がりで起きるようになった。これでスレーブの動きが少しづつさまになってきた。しかし、基本的には、危惧した通り、割り込みルーチンにはいってくる時期が完全に遅れている。特に、2つの割り込み(SDAとSCL)が被るときは、どちらかの割り込みが無視され、正しくデータを受け取れない。

 本来なら、これであきらめるべきなのだろうが、しつこいことでは人に負けない性格である。何とか、動かしてやろうという闘争心が盛り上がった。スレーブのGPIO版がウェブ上にないのが良くわかった。余程クロックが早くなければ、この割り込みのオーバーヘッドでまともな処理はできないのだ。

 現象を色々考え、スタートコンディションを検知する割り込みルーチン(SDAの両エッジで起きる)をシーケンスの最初だけにし、一旦スタートコンディションを受けたら、割り込みを止め、SCLだけの割り込みルーチンだけで動かすことにした。I2c861_8_21

 こうすると、ストップコンディションは受けることが出来ない。ただ、これはスレーブにとってはそう致命的な状況にはならない。SR04のデータ送出位なら、一連のシーケンスが終わったあと、タイムアウトをとって送信終了とすれば済む話で、受信ならマスターからNACKが来る。

タイムアウト機能を入れてやっと送受信ができた(8/21/2015)
 I2Cインターフェースのデータビットの最後のACK/NACKを返す方法が難しかったが、何とか、1バイトのマスターからスレーブへの送信(これはコマンド用)と、2バイトのスレーブからマスターへのデータ転送が動くようになった。

 どちらもまだタイムアウトを頼りにする送受信(一秒タイムアウト)なので実用には乏しい。それでも目指すSR04のI2C化にだいぶ近づいた。ブログを整理してみると、もう6ページ以上の量になった。このあたりで記事にしておこう。  
(ソースコード等は、もう少しまともなものになるまでお待ちください) 

| | コメント (0) | トラックバック (0)

2015年7月17日 (金)

EdisonのPWMをmraaライブラリーで動かす

mraaライブラリーでEdisonのGPIOは動いたが時間が不定(6/20/2015)
 Edisonプロジェクトの進展は相変わらず遅々としている。理由は簡単で、Edisonで具体的に何を作るかが決まっていないからである。しかし迷っていても先には進まない。無理やり目標を決めて進むことにする。結局、EdisonもRaspberryPiと同じ、パンチルトの出来るウェブカメラに仕立てることにした。まあ監視カメラはいくつあってもかまわない。何かの役に立つだろう。05p7167205

 前回にご紹介したサーボモーター2つでカメラをパンチルト出来る操作キットをEdisonのPWMで動かすことにする。ウェブカメラそのものは、既にEdisonで無線LAN経由で動いているが、サーボモーターの方はAVRで動かしただけで、Edisonではまだである。

 このあいだのEdisonマザー基板には、秋月で調達した1.8~5Vのレベルシフター(FXMA108)が仮止めしてあるが、配線はしていない。Edisonのピン出力は1.8Vなので、PWMで市販サーボを動かすためには、このシフターが必要である。

05p6247158  久しぶりのハンダ付けである。とりあえずEdisonのPWM(4本ある)と、ジャイロセンサーなどに使うI2C(これは2本)をアートワークした。5V出力は、20ピン2段のピンソケット(メス)をマザー基板に実装し、こちらからジャンパー経由で実験できるようにする。

 EdisonのGPIOピンの制御は、定番のmraaライブラリを使う予定だ。待ちきれないのでPWM部分だけ配線してすぐにテストを始めた。いきなりPWMのテストはきついので、スイッチサイエンスのページのnodeソースを参考にGPIO(12)を使ってLチカを最初にやる。ここはたまたまPWM0とピンが同じなので新たに配線を追加する必要がない。

 nodeは、感心にもmraaのライブラリーが用意されている(require('mraa')で動く)。Edisonのviでソースコードを入力する。これくらいの入力なら大した時間はかからない。早速動かしてみる。

 オシロでまず出力を確かめる。おおー、出た出た。おやあ、パルスが時々動かないときがある。それより不審なのが、レベルシフター(FXMA108)を通しているのに、LEDの点き方が安定しない。オシロで見るとパルス状になっている。

03p7157201 このシフターの電源供給力はスペックによれば、ピン単位50mA(全体では100mAまで)もあるので、10mAのLEDぐらい楽々なはずなのだが、いかにも頼りない波形だ。それに、点滅の間隔がかなりでたらめなのである。0.3秒で動いていると突然、点滅が止まったりして一定しない。

nodeでは正確なLチカは出来ないのか(6/26/2015)
 あわてて、ウェブにお伺いをたてる。やっぱり時間は正確にはならないと書いてある。しかし、msレベルならともかく、こんなに不正確なのだろうか。現在の300msの間隔でも正確なパルスになっていない。Edison用のこのYocto Linuxは、一般のLinuxと同様リアルタイムOSではない。同時に沢山のプログラムが動いているので、正確な待ち時間は作れない。

 考えてみたら、nodeのsetTimout( タイムアウトで呼ぶ関数, 待ち時間ms)は、再帰関数的な使い方で、確かに、そのあいだにコンソールに出力はしているし、無線LANの応答もしているだろう、LinuxはリアルタイムOSではないからそれまでと言ってしまえばおしまいだが、こんなに時間がまちまちなのはどうも納得できない。

 Yocto LinuxにはリアルタイムOSにするためのオプション(PREEMPT_RTパッチ)があるらしいが、カーネルの再構成が必要である。そんな大げさなことはできないし、これで解決するとも思えない。

 nodeではだめなのだろうか。いろいろ資料を探す。console.log()などのコンソール出力を省略すると、少しはまともになるが、時々、ずっこけて点滅をさぼるときがあることは変わらない。時間に厳密なPWMではこんなことは起きないだろうが、気になると先に進めない性分である。PWMそっちのけで色々ウエブを探し回る。

Edisonのクロスコンパイル環境の整備が難航(6/27/2015)
 しかし、この状況を説明してくれるサイトは見つからなかった。そのうちこれにばかりこだわるのも時間の無駄のような気がして、正式なCでプログラムを組んでみようということになった。CにはCPUループを使ったsleepなどの時間待ちの標準関数があり、nodeのようなプロセスをまたがるような待ちではないので少しは正確なはずだ。

 Edisonでのプログラム開発は面倒(エディターがviしかない)なので、このあいだやったPCのUbuntuで、Edisonのクロス開発をすることにする。ところが、Ubuntuに構築したはずのC言語開発環境をどう使ったらよいのか分からないのである。

 Ubuntuに入れたのはEdisonカーネルの再構成のための環境で、Makefileで動く。情けないことに、ここにmraaのライブラリをどうやって組み込むのかがわからない。下手なライブラリのインストールで、折角作ったカーネル再構築の環境がおかしくなるのは避けたい。

 ということで、これとは別に簡単なgccのクロス開発環境をこのサイトの案内で作ることにした。ここでEdisonの実行形式のプログラムまで作り(ここなら全画面エディターのgeditが使える)、Edisonへの実行ファイルの転送は、scpというコマンドを使う。

 順調にインストールが済んだので、サンプルプログラム("Hello World")を入力し、gccを動かしてみる。コンパイルが出来て実行ファイルが作られた。scpでEdisonに送ってみる。これも簡単に送れて、Edisonで実行すると無事"Hello World"が出た。よーし、好調だ。

 ところが、何故か肝腎のlibmraaのコード一式が別のところにインストールされてしまってリンクできない。/sysrootが決め手だったというサイトの言葉がカギなのだろうが、このあたりの技術レベルは見よう見まねレベルなので先に進めない。mraaが入らないのでは、何のために別の環境を作ったのか意味がないことになってしまった。

/sys/class/gpioでGPIOピンが動かない(6/30/2015)
 まあ、クロス開発ができなくても、Edisonの中でもやろうと思えばプログラム開発はできる。Edison内でのmraaライブラリは、opkgで大分前にインストールに成功している。エディターさえ我慢すれば、規模の大きなプログラムでない限り大丈夫だ。

 開発環境を調べているうち、さらに/sys/class/gpioという仮想ファイルを使えば、簡単にGPIOピンの操作が確認できることがわかった。脱線だがハードの状況を調べられる複数の方法があるのはありがたい。早速これを試してみる。

 ところが、これがさらに暗礁に乗り上げて、一歩も先に進まなくなったのである。肝腎のGPIOが想定通り動かない。ピンの定義であるexportと、direction(入出力)の定義は問題なく済んでも、実際の値(value)が入らない。mraaとは違う枠組みで動いていると思うのだが、オシロで見る限り、ピンが動いていない。

 しかも、汎用的なピンであるはずのGPIO40番(mraaでは37番、ややこしい)は4Hzで発振している。EdisonのI/OピンはUART以外にはどこも接続されていないはずだが、どうもすでに定義済みのピンがいくつかあるようで、export自体がエラーになるピンもある。わけがわからない。

 ウェブで心当たりを探すが、このあたりを詳しく解説したサイトを見つけることができない。ちょうどソフトとハードの中間の世界なので詳しい資料が不足している。

 そのうち、node.jsで不正確ながら動いていたGPIO(20)ピンもオシロで反応しなくなった。うーむ、これはどうしたことなのだろう、ハードだろうか。どうもGPIO(40)の発振といい、Edisonのハードそのものがおかしくなっている疑いが強くなってきた。

Edisonブレークアウト基板をもうひとつ買ってセットアップする(7/4/2015)
 久しぶりに秋葉原に寄る。迷っていたが、もう一台のEdisonを買うためである。少し見ないうちに、秋月電子の界隈は大きく変わっていた。向いの空き地に立派なビルが建って人の流れが変わっている。しかしメイド喫茶の客引きと外国人の団体は相変わらずで歩くのが煩わしい。

 今日は、本体以外にI2Cのコンバーター(FXMA2102)を買うことも目的の一つだ。このあいだの8チャンネルのレベルシフター(FXMA108)はプルアップが出来ないのでI2Cは接続できないということを知り、これを調達する。秋月の商売上手はさすがである。I2Cの配線をしていなかったのは幸運というか先見の明があったというか。

06p7167210 Edisonは本体だけでなく、ブレークアウト基板も一緒に揃える。前のブレークアウト基板は、充電中を示すLEDが点かなくなっているからだ。I2Cで何をやるかは決まっていない。I2Cで制御できる多チャンネルサーボ基板があるというので、これは将来のロボット構築に向けた準備でもある。

 帰宅して早速、2号機のEdisonブレークアウト基板をセットアップする。一応、nodeのウェブカメラサーバーが動くところまで作る。2回目なので作業は順調に進む。今度のYocto Linuxのイメージには、既にmraaライブラリがインストールされていた。

 ついでに、前記事で紹介したIPアドレスの固定化のためWiFiのwlan0をいじる。起動スクリプトでIPアドレスの設定をDHCP側にお願いするのでなく、単純に固定IPの設定をするだけである。簡単に変更できた。node側はこのアドレスで決め打ちにする。テストする。問題なく動いた。

 マザー基板に差すには、2号機にもピンソケット(オス)を実装する必要があるが、その前に、 サンハヤトのスルーホールに差しこんで使うジャンパーを活用して、2号機での/sys/classのGPIOピンの状況を調べ始めた。すると驚くべきことがわかってきた。

何と使えないGPIOピンが沢山ある(7/6/2015)
 これは驚いた。2号機でもおかしいのだ。使えないピンが続出した。ところがウェブサイトに出ているピンを試すとこれだけは動いている。サイトで使っているピンは大丈夫なのだ。一体これは何だ。

 ちょっと脱線になるが、しらみつぶしに、GPIOピンを調べて行った。驚くべきことに、作動するピンと動かないピンがあることがわかった。 Newedisonlist

 動かない状態は、2つあって、一見、sys/class/gpioXXが動いているように見えて(in/outのdirectionと1/0のvalueをノーエラーで受け付ける)、ピン上では何の変化もないもの。

 もうひとつはgpioXXの仮想ピンの定義が、最初からdevice busyでexportを受け付けないものの2種である。このことは、ウェブサイトを探したが、どこにも書いていない。

 サイト(Qiita)でまとめていただいたEdisonブレークアウト基板の早見表に、今回のテストの結果を加えてみた。GPIOとしてまとめたピンのところである。備考のところの赤が動かないピンで、青が動くピン、備考のところにこのGPIOピンに重複定義されている機能名を付加した。

 これを見ていると、どうも、Yocto Linuxの立ち上げで動かしたデーモンあたりがこのピンを定義し、そのあと正しくピンを解放していないのではないかと思われる状況である。動かないピンは特定の機能に集中している。UARTピンが2つともbusyなのは当然だが(それでもUART1は使っていない)。

カメラを動かしたEdison1号機にヒートシンクをつけるが熱暴走(7/7/2015)
 動作がおかしくなっている一号機でもGPIOピンの状況を調べた。全部のピンは調べなかったが、調べた限りでは(5~6本)すべて同じ状況だった。

 ついでに、2号機に加えた変更(IPアドレスの固定化)をこちらにも与えてテストする。カメラを動かしてみる。問題なく動く。ただ、こちらの方が少し熱を持つようだ。 01p7127196

 温度計で測ってみると、50℃を軽く超える。不安になったのでヒートシンクをつけてみた。 温度上昇は少し鈍化したが、60度近くになる。1時間程動かしたところでハングアップした。うーむ、ヒートシンクだけでは長時間には耐えられない。冷却ファンが必要かも。

 しかし、こんなに熱かったかなあ。前はもっと低いところで安定していた。1号機には何か別の問題がある可能性が高い。GPIO(37)で4hzの発振信号が続いているなど、I/Oピンに不審な動きが多すぎる。

1号機でシリアルを失ったのは、やはりショートか(7/10/2015)
 ヘッダーピンの実装のため、Edisonの2号機をブレークアウト基板から外した時のことである。2号機の裏面が絶縁ラベルで覆われている。おやあ、 1号機は違っていたような気がする。確かめてみる。

02p7137199  やはり、そうだ。1号機の裏面は表と同じようにアルミ生地のままプリントされている。ふーむ、何故変わったのだろう。閃きが走った。以前、この裏面とブレークアウト基板のピンヘッダーの配線部が接触していて、あわててはみ出たピンをニッパーで切り取ったことを思い出した。

 そうか、当研究所で起きた事故が他でもあったのだ。それで、ここの表面が絶縁されるようになったのだ。シリアルが動かなくなったのは、このショートに違いない。

やっとEdisonでPWMが動いた。nodeのLチカも正確になった(7/14/2015)
 道草を食っていたが、やっと2号機でPWMを実験する気運が盛り上がってきた。実はmraaのPWMの操作は実に簡単で、ピンを初期化した後、周期(usか秒)とduty比を整数と浮動小数で設定するだけである。

Edison_pwm サンプルコードはここを参考にさせてもらう。サーボモーターはPWMで、一般的な仕様では周期は10から20ms。仮に15msとすると、大抵のサーボは0.5msから2.5msのパルスが動作範囲である。このduty比は0.033から0.166である。この間で動かせば、サーボが最大幅動く。中点は、1.5/15 = 0.100である。

 Cソースの入力は10分もかからない。コンパイルも一瞬で終わる。問題なさそうである。本体のサーボに接続する前に、オシロにレベルシフターの出力を入れてテストする。

 恐る恐る、コンソールからプログラム実行のキーを入力する。おーし、プログラム通り0.5msパルスが1秒ごとに少しづつ増えて2.5msまで進んだ。コンソールにもduty比の数値がならぶ。浮動小数点が気楽に扱えるというのは、フラッシュの少ないAVRと違って贅沢なものだ。

 いやあ、ここまでが長かった。とりあえずはオシロ上だけだがEdisonでPWMが動かせることを確認した。今はPWMの1チャンネルだけだが、コンソールからパンチルトの2チャンネルのPWM値を入力し、自由に2方向にカメラを動かすことを次のステップにすることにしよう。

 勢いに乗って、このあいだの 1号機では不正確だったnodeのLチカプログラムを2号機でも動かしてみた。これが何と、全く正確にパルスが生成されたのだ。暫く動かしていても、パルス幅が乱れることは全くない。

 何ということだ。時間が不正確なのは、nodeのsetTimoutなどの関数ではなく、1号機の別の原因によるものだった。今のところ、ハードかソフトかはわからない。動画ストリーミングで高熱になるのも何かこれと関係あるような気もする。

| | コメント (2) | トラックバック (0)

2015年6月25日 (木)

Edison進展せず。電子工作に「ときめか」ない

 前回の記事から一か月以上が経ってしまった。これまでで最長の空白だ。Edisonの電池駆動カメラのプロジェクトは、IPアドレスを可変にするサーバープログラミングに熱中し、これが実現したとたん、やる気を失った。こういうことは良くあることなのだが、今度はさらに別のことが重なった。

 というのは、こんなに苦労して可変アドレスを手に入れなくても、WiFiでEdisonのホストIPアドレスを簡単に固定にすることが出来るということをウェブで知り(考えてみたら出来て当然なのだけど)、がっくり落ち込んだ。まあ、nodeの勉強には役だったと自分を慰めるが、実用的には徒労に近い。

 当研究所のモットーは、何度も書いているように「実用性」である。こういう無駄な作業は一番避けたいもののひとつである。それにこれでEdisonが動いたとしても、面白そうな応用が見つからない。要するに心が躍らないのである。

 最近、タイムズ誌で世界で注目される100人の一人に選ばれた、「片づけ」の名人、近藤真理恵氏の言葉を借りれば「ときめき」がないのである。電子工作での「これを作りたい」という気持ちは理屈ではなく、この「ときめき」に近い、と言うよりそのものである。これがないとやる気が起きない。

 まあ、この一か月の空白は、電子工作以外のことに忙しかったこともある。後程いくつかご紹介するが、今はこちらのほうが「ときめき」を感じることが多い。01p4127056 とはいえ、このブログは今や、電子工作だけでなく所長の生活全体の備忘録と化している。休んでいるわけにはいかない。メモにして残してきた、この一か月の行動記録をなるべく電子工作とつなぎながらご報告していくことにする。

移動カメラの実装を考える(5/20/2015)
 Edisonの電池駆動ウェブカメラは順調に動いている。起動の順序を変えてもWindowsでいつでも見えるようになっているのが嬉しい。しかし、ハードウェアは全くバラックのままで、このままにしておくわけにはいかない。何らかの実装を考えることにした。

 電池駆動でWiFiなのでカメラごと一体にすれば、使い勝手は格段に上がる。しかし、いずれはRaspberryPiのときと同じように、カメラをチルトやパンして動かしたいという野望もある(実はキットを買ってある)。考えているだけでは先に進まないので、とりあえずはEdisonと電池だけをケースに収容することにした。

 放熱も考えておかないといけない。Edisonはカメラを駆動させると、やけどをするほどの熱さではないが、手で触っているのがちょっとつらくなるほど発熱する。放射温度計で測ったところでは、USBカメラをつけると、室温20°で表面のアルミシールドが41℃前後、カメラを動作させると46℃近くまで上がることがわかった。

 ヒートシンクをつけたほうが良いかもしれない。電池での長時間テストもやってみた。電池は、NiMH(ニッケル水素)いわゆるエネループである。カメラをつけると400mA近く消費するようだが、4時間は楽に動いた(UM3型は1900mAh)。

 カメラで何をするか決まっていないというのが一番の問題だ。猫監視カメラを2台作るわけにもいかない。実は、このEdison移動カメラは、以前とりあげたドローン(マルチコプター)に積み込んで自宅上空を写すつもりだったのだが、あの事件ですっかり出鼻を挫かれてしまった。

 それにしても、今度のドローン不時着のニュースには驚いた。とうとうやったか、きっと誰かが悪戯するだろうと危惧していたのだが現実になった。ドローンは自作の格好のネタなので既製品を買わずに自作しようと、モーター制御を勉強したり、6軸ジャイロセンサーなどを入手して準備していたのだが、ぐずぐずしているうちにすっかり先を越されてしまった。

 既製品を早く買っておくべきだった。これでは、simさんが書いていたように、自作すると「ドローンを密造」ということになってしまう。このあいだスキーに行ったとき、同宿のスキーヤーから、Goproで撮ったムービーを見せられ、とても啓発されたのだが、こういうものは、思い立った時にやらないといけない(今の所長のスマホもそうだ。すっかり乗り遅れている)。

シリアルが動かなくなったのは、ピンヘッダーでショートさせたか(5/26/2015)
 Edison基板をピンヘッダーで固定したマザー基板を、見るともなしに見ていたときである。ハンダ付けしたピンヘッダーの反対側の突起が、Edison本体の裏のシールド板と接触しているように見えた。Edisonが裏にもシールド板が張り出していることに今さらながら気が付いた。09p6247177 お、お、おー、もしかすると、これがシリアルインターフェースが動かない原因なのか。あわてて、Edison本体をはずし(抜き差し30回まで保証。もう10回は抜き差ししたか)、触っていそうなところをニッパーで切る。2か所あった。一本はGND、もう一本は、問題のシリアルのUART1の RXだった。うーむ、これか。

 祈る気持ちで電源をON。残念、状態は変化せず、シリアルは生き返らなかった。落ち着いて調べ直してみたら、ショートしていたと思われるRXは、オシロで調べた時にちゃんとプルアップされた電圧が出ており、動かないTXの方は、最初から接触した形跡がない。

 現在のEdisonブレークアウト基板は、シリアルが動かないこと以外に、最初点灯していた充電中を示すLEDが点かなくなっているという不具合を抱えている。WiFiや、USBからの給電によるUSB仮想ネットは生きているので、日常の作業には差支えないが、不安は拭えない。

 いずれにしても、今後、少しまともな用途に使うことを考えるなら、Edisonは安全のためもう1セット調達する必要があるようだ。

恐れ入ったカメラ操作キット(5/29/2015)
 先にも書いたように、Edisonでもカメラを動かそうと、このウェブサイトで紹介されたカメラのパンチルトを行うサーボキットを、以前衝動買いしてある。サイトでの紹介が辛口だったので、買ったまま封も開けず放置し、余り期待していなかったのだが、ドローンの話が消えて、パンチルトをEdisonでもやってみる気になった。02p5307147

 包装を解いてパーツをとりだす。話には聞いていたが、確かにすさまじいキットだった。だいたいアセンブリーのカメラを装着するホルダー部分が、カメラのマウントと全く違うので、このままではカメラを取り付けられない。

 恐らく、設計当初に予定していたカメラが供給できなくなったけれど、サイトに改造記事をつけて販売を強行している感じだ。アセンブリーの金型を変えるのは確かに巨額の費用がかかるので同情したいところだが、それにしても、この紹介された改造方法が荒っぽい。

 カメラもアセンブリーも、ニッパーなどで取付け部分を双方とも全部切り取り、やすりとドリルで固定穴をあけてねじ止めするという乱暴なものだ。もう少しエレガントな改造法もあると思うのだが、やりかたがいかにも原始的だ。 

 しかも、サーボモーターに付属しているホーンは、どれも、このアセンブリーの取り付け穴に入らない。型に合わせて切り取れとある。サーボモーターも変わったのだろう。好い加減なものである。プラスティックなので加工は簡単だが、何か馬鹿にされている感が否めない。04p6247157

 サーボ2つとカメラ(30万画素ではもう時代遅れ)で¥3200と言う値段がちょっと眉唾だったのだが、噂どおりの豪快なキットだった。中華製だろう。改良記事をサイトに載せているだけでも良心的と考えないといけないのかもしれない。

 ともあれ、完成した。記事に指定されたカメラ側のホルダーをニッパーで切り取ることは止め、そっくりこれを残し、マウント側に板を接着し、カメラのホルダーで挟めるように工夫する。特にがたつきもせずうまくいった。

 このカメラはWindowsでは認識するが、Linuxでは駄目らしい。みんな別のカメラでテストしている。ただ、手持ちのC270は少し大きすぎて、このサーボでは重すぎて動かせないかもしれない。別のカメラを考えないといけない。

AVRではサーボは動いた。快調な動き(6/6/2015)

 出来上がった操作キットのサーボモーターを、いきなりEdisonのPWMで動かすのは大変なので、手直に動かせるAVRで動作確認することにした。1年ほど前、AVRで市販のサーボを動かす実験をしている。

 しかし、これが、なかなか手が動かないのである。電子工作以外にやることが増えてきて、こんな簡単なことでも腰が重い。それでも、やっと工作机に向かう気が起きて、ゆるゆるブレッドボードにTiny861のISP配線をすませた。操作キットの完成からここまでに3日以上かかっている。

 以前作ったサーボ制御のソフトをコンパイルする。おやあ、新しいAtmelStudioではコンパイルエラーが出る。おかしいな。前のプロジェクトではすんなり通ったのに。

 サーボモーターを動かしてから1年しかたっていないのに色んなことを忘れている。前のAVRStudioの時代のプロジェクトをimportで持ち込んでいるのだが、gccのディレクトリパスがおかしい。

 新しいAtmelStudioから新規に作るプロジェクトは問題ないが、importだけでは駄目なようだ。このあたりの原因究明をしている暇はない。とりあえずダミープロジェクトを立ち上げ、そこのmainソースファイルにこれまでのソースをぶち込んでAtmelStudioをだましてコンパイルしてみた。

 すると、includeファイルや、ソースライブラリーもうまくごまかされて全体のコンパイルに成功した。よーし、どんなもんだ。だいたいAVRでサーボを動かすのはテストのためだけである。このあたりはやっつけで先に進む。03p6247154 

 さあ、サーボのテストだと意気込んだのだが、これが、どうやって動かしたのか丸ごと忘れている。情けないものである。しかし、こういうときに役に立つのが、このブログの記事である。いやいや、書いておいて良かった。配線図も出ているので何の苦労もなく実験が始められた。

 最初のバージョンでは、UARTが邪魔してサーボがスムーズに動かなったが、USI-UARTを使った次のバージョンはスムーズにサーボが動いた。

 操作キットのサーボモーターは、小さい割には強力で、動作もきびきびしており頼もしい。しかも可動範囲が180°もあり汎用性が高い。サイト情報によれば信頼性が心配されているが、今のところ全く問題ない。操作キットを少し見直した。

なんだEdisonでもこのカメラが動いた(6/9/2015)
 操作キットについているUSBカメラは、Windowsでは動くが、Linuxではサポートされていないという。Windowsでのテストでは、一応認識され画像が出たが、どうもUVCカメラではなさそうだ。30万画素なので、C270あたりに見慣れてしまうと、玩具レベルでとても使う気にはならない。

 恒例の音楽発表会が近づいてきたので、それに気を取られて電子工作に身が入らない。それでも時間を見つけては、工作机の前に座るが、すぐにやることが見つからない。色々なところが手詰まり状態になっている。

 サーボは動いたが、AVRで動かすのでないので、これ以上は無駄だ。EdisonのPWMはmraaライブラリーで簡単に動きそうなのだが、実装になかなかとりかかれない。カメラを動かして何に使うかが決まっていないこともある。

 それより、動画のウェブ画面でサーボを動かすユーザーインターフェースが決まらない。スライダーのような操作でカメラを動かすと良いのだろうが、適当な動作例が見つからない。それにここはHTMLプログラミングの世界なので、今一つ食指が動かない。

 カメラを前にしてやることがなくなったので、操作キット付属の30万画素のカメラが、本当にEdisonでは動かないのか確認することにした。手始めにPCでUbuntuを立ち上げてテストする。Ubuntuに適当なビュワーをインストールして、カメラをつないだ。

 あらら、ちゃんと認識する。で、画像は?うん、問題なく映った。30万画素なので画面は荒いが問題ない。端末を立ち上げて、USBのリストを見る(lsusb)。うーむ、USBカメラとして問題なく認識されているぞ。ベンダーがMicrodia、メーカーがSonix Techと表示される(怪しい名前だ)。

 それでは、Edisonで動かないのはUSBの問題ではなく、ffmpegなどのアプリの問題なのか。あわてて、Edisonを立ち上げカメラをつないだ。lsusbでもカメラと認識した。では、動画サーバーのffmpegではどうだ。

 なんと、なんと。画像は荒いが、全く問題なく動画が配信された。ffmpegのバージョンが上がってこのカメラをサポートするようになったようだ。これは助かった。何かの時に役に立つ。

極めて麻薬性の高い練習発表会があったこと(6/10/2015)
 またこのシーズンが近づいてきた。習っている楽器(フルート)の練習発表会である。所長も年齢が70を越しているので、そろそろ引退を考えたいのだが、仲間がいるのでやめるにやめられない。それにこの発表会というのは、極めて習慣性、極端に言えば麻薬性の高い行事なのである。

 前にも書いたが、仲間内の人が聴いているだけなのに、そこそこの発表会場の経費を払い、伴奏者に謝礼を払い、先生からは容赦ないダメだしをされ、数か月、練習にもがき苦しみ、本番では、異常な緊張を強いられ、そして結果は大体練習を上回る演奏が出来なくて落ち込む。

 終わると、もうやりたくないと思うのだが、何故か、暫くすると楽器をとりだして吹いている。そのうち先生から次の発表会の曲目を何にするかの打診があり、今度こそはと練習をし始める。発表会が待っていないと練習に力がはいらないということもある。

 今年は良きライバルが、フルートを学んだアマチュアが誰しもあこがれる名曲の最高峰、ドップラーの田園幻想曲をやるというので、こちらは、バロックの名曲、バッハのフルートソナタ1番を選んだ。

 こいつが長い曲でピアノ(本式にはチェンバロだが)との合わせが難しい。しかも最後まで一定の音が出ないとバッハらしくならない。あれやこれや、ほぼ数カ月かけて練習をしてきた。

 本番前日のリハーサルでは完璧に近い演奏が出来たのだが、本番はいつのまにか上がってしまい、いくつか出だしに失敗し、不本意な結果に終わった。しかし、「とても感動した」といってくださる関係者もいて(半分はお世辞だろうが)、気持ちが救われる。まあ、音は我ながら最後まで良い音が出ていたと思う。

 打ち上げで、また盛り上がる。くりかえしになるが、なぜ人間と言うのは、苦しみながらお金と神経を払って、わざわざこうしたことを続けるのだろうか。打ち上げのこのカタルシスを得るためだけにやっているとも思えない。ただ、このときのビールは限りなく美味である。 

20年前のQUADのCDプレーヤーを修理しようとしたこと(6/12/2015)
 少し前から、動きがおかしかったのだが、フルートの練習のためCDを頻繁に取り換えて聴いていたら、トレイ駆動部が動作しなくなった。このプレーヤーは買ってもう20年もたち、この駆動部は一度修理しているが(ベルト切れ)、今度は別のところがやられたらしい。06p6247160

 こういう時に限って、こういうものは故障するものである。苦労してケースを開ける。最初、ケースの止めねじはいたづら防止のトルクスネジだと思っていたが、六角レンチネジだった。あわてて発注したトルクスドライバーセットが無駄になった。まあこれもいつかは役に立つだろう。

 ケースが開いた。おやあ、シャーシーの中に細かいプラスチックの破片が散乱している。うーむ、何かがこわれている。さらに基板類をはずして、機構部が見えるようにする。07p6247164

基板がいくつかに分かれ、リボンケーブルで接続されているところもあるので慎重な作業が必要だ。

 やっとトレイ駆動のモーターが見えてきた。あ、あ、あー、見事、トレイの駆動モーターのピニオンギヤの丸歯が欠けている。これでは空転だけしてトレイは動かない。もう20年も経った機械だ。経年変化でプラスティックが劣化したのだろう。08p6247166 一瞬、このギアだけを取り換える修理が脳裏に浮かぶ。ただ、この物理的なところをなおしたところで、実際のトレイの動きが復元するかは保証の限りではない。しかも、発表会が近づき、懸案の電子工作もある。そんな悠長なことをやっている暇はない。

 ただ、CDプレーヤーが今動かないのはまずい。冷静に状況を調べて、動かないのはトレイの駆動部だけで、他は問題ない(演奏もOK)ことを確認した。とりあえずは、トレイの前蓋に引き出すためのフックを付けて動かすことにし、プレーヤーを再度組み上げた。楽しみは残しておこう。

水洗トイレのタンクバルブをアマゾンから買って補修したこと(6/16/2015)
 そうこうするうちに、今度は2Fのトイレの水洗タンクが不調との家族の知らせを受けた。タンクに水が入るのに異常に時間がかかるようになったという。早速、タンクを開けてみると、水が止水フロートのバルブのところから水が漏れるだけで、通常の供給ホースから水が出ていない。10p6247190 当研究所は、昔、水道工事にも口ばしを突っこんだことがあって、大きなプライヤーやドライバーを備えており、簡単な水工事なら十分守備範囲である。早速工具を持ち出して、ボールタンクの調節バルブを取り外した。

 このバルブ(ダイヤフラム)の仕組みが良くわからない。細い針がダイヤフラムを貫通していて
両側の圧はここで素通りになるはずで、このゴム膜でどうして水が止まるのかわからないが、このゴム膜の別のところにも穴があいているところを見つけた。

 少なくとも、ここが悪いのに違いない。幸い、1Fのトイレも全く同じ型だったので、このバルブを装填してみた。思った通り2Fと同じ現象が現れ、このバルブが不良であることが確認された。

 こんな部品は市販されているのだろうか。DIY店に行く前に、ネットで調べてみた。すると、全く同じ部品が見つかって、1個から売ってくれることがわかった(アマゾン)。いやあ、良い時代になったものだ。11p6247192 数日後、無事部品が届いた。早速、つけなおしてみる。見事、水洗トイレの不具合は解消された。いやあ、気分が良い。その後、ウェブを漁っていて、このダイヤフラムの原理を詳しく解説するところを見つけて納得した。また、少し大きなDIY店でも同一品を見つけた。定番の補修部品らしい。

 このあと、電子工作で少し進展があったのだが、意外にページ数がかさんできたのでこのあたりで報告を区切ることにする。

| | コメント (0) | トラックバック (0)

2015年5月18日 (月)

EdisonでIPアドレスを変数化した動画サーバーが動いた

 Edisonの無線動画サーバーソフトは、ウェブでいくつか紹介されている。そのうちnodeを使ったこのサーバーは軽くて具合が良いのだがWindowsでは動かない。ローカルネットの中のホスト名を拾い上げる機能(Avahi)をこのサーバーが使っているからである。Windowsのためには生IPアドレスをクライアント用のソースコード(index.html)にハードコーディングしてやる必要がある。

 EdisonはWiFiでネットとつながっており、IPアドレスは勝手に設定されるので、このままでは運用性が極めて悪い。iTuneのソフトをインストールすればWindowsでも動くようだが、このためだけにクライアント側をいじるというのは、どうも本末転倒で、元プロのソフト開発者としては受け入れがたい解決手段である。

Node

 そこでnodeの勉強も兼ねて、自分のIPアドレスが変わってもストリーミングサーバーが動くように、このサーバーのソフト改修にこのところ熱中していた。久しぶりのPCプログラミングである。ここは電子工作のブログで、PCのソフト開発はなるべくやらないはずだったのだが、行きがかりで止まらなくなってしまった。

 悪戦苦闘していたが、このほど、まがりながら、当面の目的を果たしたので、そのご報告とともに修正方法を紹介することにする。オリジナルはMITライセンスなので、改訂したソースの公開は問題ないと認識している。ただし、オリジナル同様、完全な無保証、無責任であることはご承知置き願いたい。

Linuxでのnodeとexpressのインストール(4/24/2015)
 久しぶりの大物、node.js(正式名)である。これまでのウェブプログラミングの概念を破る革新的な手法ということで、少し勉強してみる気になった。ただ、node.jsは近年、分派活動(io.jsというらしい)が始まったりして、ちょっと先行きが不透明だったが、つい先日統合されるというニュースが飛び込んできた。ウェブサイトにはおびただしい量のnodeの紹介ページが存在する。

 Edisonのサーバーがnodeの中のHTTPサーバー用のモジュールexpressを使っているので、まずはWindowsでnodeとexpressの学習を続けていた。その結果、概要がつかめてきたので、いよいよ、本題のEdisonサーバーの改修に移ることにする。

 Edisonの石はIntel AtomでOSはLinux(Yocto Linux)である。ここのエディター環境は貧弱(viしかない)なので、この上で開発やテストを続けて行くのはつらい。このためPCのLinux(Ubuntu14.04)にもnodeをインストールし、こちらで動作を確認していくことにした。

 nodeのLinuxでの導入ツールはapt-getである。この環境は強力で、Windowsに比べれば嘘のように簡単だった。あっと言う間にすべてのモジュールがインストールされた(node,express,npm)。動作を確認する。expressも問題なく動く。

Screen20150427

 うまくいったのは、Linuxの環境(nodeの生まれ故郷)ということもあるがnodeに慣れてきたということもあるだろう。薄紙をはがすように、expressの構造も見えてきた。レンダリングのツールはejs(enbedded java script、組み込みjs)を選ぶ。

 ejsを選んだ理由は、HTMLに近く可読性が高いことによる。jadeなど省力を狙ったものは別言語のようで扱いにくい。それにしても、nodeでの付加すべきパッケージはやたらと種類が多い。しかも、バージョンの変化が激しく、各所でバージョン違いでのトラブルが発生する。しかし経験を積んできたので事前に必ず確認するようにし失敗は少なくなった。

 Windowsで懲りたので、Linuxでは少し計画的に作業を進めることにする。結構道のりが遠い。下手をするとまた脱線する。少し細かいが、以下のステップで行くことにした。

1. Linux(Ubuntu)でNodeのインストールとテスト。

2.  同        expressのインストールとテスト。

3.  同        ejsのインストール。ここまでは済んでいる。

4. 外部コマンド(ifconfig )によるIPアドレスの取得。これはWindows(ipconfig)ではnodeで実現できている。ウェブにたくさん記事がある(ここやここ)ので簡単だった。Linuxでのテストはここで済ませる。

5. ejsを使ってクライアントファイルをレンダリングし、所定のIPアドレスに変更する部分の開発。ここまではUbuntuでやる。

6. Edisonにnodeの上記スクリプトファイルの持ち込み。

7. Edisonでのサーバーテスト。いきなり動画サーバーを動かさないで別サーバーでテストする。

8. Edisonでの動画ストリーミングのテスト

Linuxでのnodeの勉強は順調(4/25/2015)
 PC Linuxでnodeを復習する。久しぶりのLinux環境である。Linuxも昔に比べると格段に進歩している。ブラウザー(Firefox)も明らかにWindowsより早い。USBメモリなど周辺のI/O機器も何もせずに認識する。特にサウンド関係が全く手づかずで動いたのには感動した。YouTubeでクラシックを聴きながら作業する。快適だ。

 少しづつnodeとjs(JavaScript)が見えてくる。ただ、無料で読ませて貰ってケチをつけるのは少々気が引けるが、どの入門サイトも、サンプルコードの中の変数名やプロパティ、さらにオブジェクトにどうして同じような名前を付けるのだろう。

 オブジェクト指向言語の変数や関数は、ピリオドなどでいくらでも派生できるので、同じ名前をつけると致命的に混乱する。しかも、この変数名が予約語なのか、一般の変数なのかの区別は、すべてモジュールの原典にまで戻らないと分からない。解読するのに一苦労である。

 海外のものでも、fooとかbarという名前がやたらと使われ混乱することおびただしい。経験者には自明のことなのかもしれないが、初心者にとっては、どの部分がオブジェクトで、どれが変数で、どれがプロパティなのかはわからない。

//foo.js
exports.foo = 'foo';
//main.js
var foo = require('./foo')
console.log(foo.foo); // 'foo'

こういうサンプルを見せられて、いらいらしないで読み下せる人がいたらお目にかかりたい。

 こんな悪態をつきながら、少しづつサーバーの機能を増やしていく。お手本にしたのはこれ。このサイトは少しづつ、実例付きで、相当高度なところまで案内してくれるので嬉しい。このサイトのコードを参考に、テーブル表記や、POSTによるデータ入力、ejsによるフィルタリングなどの初歩的なことができるようになった。

LinuxでもIPアドレスの抽出は成功。grepの正規表現にはまる(4/28/2015)
 IPアドレスの抽出は、Windowsのnodeですでに成功している。nodeでの外部コマンド出力については、以下のサイトが親切だった(前に紹介したところと同じ)。
http://yosuke-furukawa.hatenablog.com/entry/2014/07/26/145814

 今のところ、コマンドの出力文字列から、IPアドレスを抜き出す方法は、grepを2回使っている。まず、該当アドレスの行を抜出し、それをさらにIPアドレスだけに絞り込む方法である。

IPアドレスを抽出する正規表現: [0-9]+(\\.+[0-9]+){3}   (\は不要な環境もある)

 これを何とか一段で出来ないか、色々サイトを漁って調べているが、プログラムでも書かない限り無理なようだ。しかし、久しぶりのこういうパズルのような開発は面白い。正規表現は奥が深い。

 Windowsでは、grepのバージョンを上げる必要があったが、さすが本家のLinuxである。Linuxでは何の問題もなく成功した。ただ、Edisonではコマンド出力のフォーマットがUbuntuとまた違うので気を付けないといけない。

 grepも方言が多い。Windowsでは成功してもLinuxで動くとはかぎらない。しかも、UbuntuとEdisonではOSが違うのでifconfigの出力も違い、別のやり方が必要である。エスケープ\のタイミングが微妙である。[^ ](ブランクでない文字)という表現に気が付くまで迷走した。今のところEdisonでは以下のコマンドで抽出に成功している。

ifconfig wlan0 | egrep -o 'addr[^ ]+' | egrep -o '[0-9]+(.[0-9]+){3}'

正規表現に慣れない方のために、少し説明しておくと、ifconfigの出力メッセージが以下の通りなので、
wlan0   Link encap:Ethernet  HWaddr fc:c2:de:3c:c4:23
   inet addr:192.168.1.13 Bcast:0.0.0.0 Mask:255.255.255.0
   UP BROADCAST ........(以下略)

 まず、addrから始まり、ブランクで終わる文字列を残す。つまり、addr:192.168.1.13が残る。次に、数字の0から9だけで構成される1つ以上(カギかっこのあとの+)の文字と.のあと同様に一つ以上の数値の組み合わせが3個ある文字列を抽出すると、addr:がとれて、めでたく、192.168.0.13となるわけである。

Edison_ipaddr

Edisonのサーバーはejsを使っていなかった(4/29/2015)
 いよいよ、Edisonのnodeストリーミングサーバーの解析に入る。久しぶりにEdisonを立ち上げて様子を見る。ここのexpressはV4であった。ウェブ上の資料はV3が多い。ソースは最新のテクニックを駆使しているようなので、理解するのに時間がかかる。

 そのうちEdisonのサーバーソースは、ejsを使っていないことがわかる。勘違いしていた。しかし、IPアドレスの埋め込みは必要なので、ejsは使わなければならない。Edisonのソースコードをさらに真面目に調べ始める。いや、この前のmjpg-streamerほどではないが複雑な構造だ。

require関数(と呼ぶのか)の新しい形に戸惑う。

require(パス名).serveIndex(app,function(){ });

というステートメントが理解できない。いったいこれは何だ。

 調べた結果、serveIndexという関数が、別のところで定義したプライベートな関数で、その定義場所が前のrequireのパスであるらしい。このステートメントでexportされた当該関数を実行している。やれやれ。

 node(というよりjs)が難しいのは、こんな感じで、ある名前が、オブジェクトなのか、プロパティなのか、メソッドなのか、また、既に出来ているモジュールの予約された変数なのか、それともプライベートな変数定義なのかは、一つ一つ調べていく以外に、分からないことにある。

 ディレクトリ構造が変わってもソースが動くように、かなり抽象化したコーディングになっているようで、とても複雑だ。結局、サーバーの構造を変えることはあきらめた。姑息な手段だが、このサーバーの中はそのままにしておき、クライアント側のディレクトリに用意されているindex.htmlだけを換えることにする。

 ファイルアクセスが発生するが、立ち上がりの時の一回限りだ。幸いnodeは、ファイルをアクセスするモジュールは完備している。サーバーの開始直後に、直接ejsのレンダリングで書き換えて入れ替える。

Node expressのインストール不調の原因解明(5/3/2015)

 Edisonのnodeサーバーの解析で壁にぶつかっているころ、思わぬところで別の進展があった。Windowsでnodeのexpressが入らない原因が判明したのだ。何かゴミが入っているのだろうと推測していたが、そのゴミが見つかった。

 たまたま別の調べものをしていて、Winでのnodeのワークディレクトリ直下に.npmrcというファイルを見つけた。その内容は、prefix=C\;\Users\NODE\Nodist\binというテキストである。この文字列は、これまでさんざん頭を悩ましてきた幻のC;ディレクトリチェーンと一致する。

 いつもはこの下のプロジェクト単位のディレクトリで作業していたので気付かなかった。これを誰が作ったのかはわからないが、このいかにもプリファレンスファイル臭い名前は間違いなくインストール時に悪さをしている元凶に違いない。

 これを消してもういちど、npmでexpressをインストールする。大当たりであった。変なディレクトリも作られず、順調にインストールが完了した。expressのコマンドはどうだ。よーし、ちゃんと動く。

 これでWin7のexpressは所定のところにインストールされコマンドとして働くようになった。めでたし、めでたしである。ささいなことだけれど、こういうトラブルが解決したときの爽快感は何ものにも代えがたい

あともう少しだが、うまく整形されない(5/9/2015)
  IPアドレスの抽出に成功したので、残るは、index.htmlの書き換えである。これも思わぬところで新しい手法が見つかった。ejsを使った置換を考えていたのだが、もっと簡単な方法があった。jsのreplaceメソッドを使う方法である。お世話になったこのサイトの最初の講義のところで紹介されていた。

 nodeのfsモジュールを使ってプロトタイプのindex.htmlファイルの内容を文字列に読み込み、 str = str.replace('/置換される文字列/g', IPアドレス); とやると、IPアドレスが、置換される文字列(@などを使った他にない文字列)のところに置き換わる。gはglobalの略でマッチするすべてを変換する。

 こういうところはjsは便利である。変換したあとこのstrをfsで書き出す。造作のない作業だ。早速Windows版でテストしてみた。見事に、該当の場所がIPアドレスに換わった。良いぞ。おや、最後のところで改行され(0x0A)、行が折り返されている。Windowsだから改行が残るのだろうか。もしかすると、HTMLの中の改行は無視されるので問題ないかも。

 まあ、あれこれ考えるより、この外部コマンドの末尾の改行をとってしまえば良いはずだ。というので、ウェブでまた「末尾の改行文字をとる」「java script」などで検索するとすぐ解決法が見つかった。同じreplaceメソッドで、replace('/\n/g','')という正規表現である。

 ところが、こいつがエラーになるのである。fsで読んだファイルの文字列はうまくいくのに、外部コマンドの出力は文字列ではないとはねられる。わけがわからない。文字列オブジェクトを新規に定義して、そこにコマンド出力を移し替えてもだめである。

 これはWindowsだけの現象ではないかと淡い期待を抱いて、Edisonにコードを持ち込み、実際に動かしてみた。危惧した通りEdisonでもindex.htmlファイルの中のIPアドレスは折り返された。さらに一縷の望みを抱いて動画サーバーを動かしてみる。残念、画像は表示されない。悔しい。あともう少しなのに。

ちょっとしたきっかけで遂に成功。いやあ難しいもんだ(5/12/2015)
 この問題もちょっとしたことで解決した。ええー、こんなところにしかけがあったとは、というやつである。外部コマンドをjsで出す、execsync関数の解説ページを見ていた時のことである。外部コマンドの出力を文字列オブジェクトへ収容するステートメントで、冒頭に""という空白文字をつけ加えていることに気付いた。

 str = “” + execsync(“ifconfig wlan0 | grep ...

ふーむ、これはいったい何のためだ。こちらでは無駄なステートメントとしてこの部分は消してしまっていた。電撃が走る。むむむ、これは匂うぞ。

 外部コマンドの出力は文字列でなないと怒られている。文字列オブジェクトを新たに定義し、そこへ放り込んでもだめだったので論理性はないが、もしかすると、これが文字列にするおまじないなのかもしれない。

 だめもとである。この部分を加えてテストしてみる。ヤッホー、大当たりだ。改行文字を除くreplaceメソッドがエラーなしに正常終了した。焦る手で、index.htmlでもテストする。よーし、IPアドレスは折り返さずに表示される。

 喜び勇んでEdisonを立ち上げ、ソースコードを修正する。やった、やりました。外部コマンドから収集したIPアドレスが認識され、Edisonの動画サーバーが見事にWindowsでもストリーミングを開始した。JavaSciriptは型には全くうるさくないと聞いていたが、結構、気難しいことがわかった。

 現在の変更は、オリジナルの複雑なディレクトリ構造とは無関係に、本来、サーバーなどを置く場所にプロトタイプのindex.htmlを収容し、現在のクライアントディレクトリにあるindex.htmlを書き換えるという武骨な方法だが、とにかくこれでEdisonのIP環境がどう変化しても自分でアドレスを拾って正しく稼働する。

 公開は迷ったが、とりあえず、変更した分だけのソースリストをご紹介することにする。このソースの変更と、index.htmlの少しの変更、外部コマンド実行の関数、execsyncsのインストールが必要である。これについては公開したフォルダーのreadme.txtを参照されたい。オリジナルはMITライセンスなので、ライセンスファイルも同梱されている。

ここに、上記のソースファイルなどを入れたディレクトリーを圧縮したzipファイルを置きます。適当な場所に解凍して、中のreadme.txtを読んでください。

「Edison_server_js.zip」をダウンロード

| | コメント (0) | トラックバック (0)

2015年4月23日 (木)

Edisonの電池駆動無線カメラの実現へ

Windowsでnode.jsのストリーミング成功(4/5/2015)
 遂にWindowsでもEdisonのnodeサーバーの画像配信に成功した。うまくいかなかったのは、前の記事のコメントにあるように、単にクライアント側のindex.htmlファイルにWindowsでは動かないローカルサーバー名を使っていたことが原因だった。 

前々記事にも説明があるが、今度のnodeサーバーは、ローカルネットの中のホスト名を自動的に調べてネームサーバーなどの助けなしに、それが使えるような機能がついている。Unixの世界ではAvahi、Macの世界ではBonjourと言うのだそうだ。前回の記事のコメントで、tmz7273さんから教えて頂いた。

 WiFiではDHCPで自動的にIPアドレスを設定していくのでネットワークプリンターなどに固定のIPアドレスを振ることが出来ない。勝手に振られて迷子になってしまう。プリンターの個別のホスト名が使えれば、その心配はなくなる。Windowsでも使えるそうだが標準では入ってこない(iTuneをインストールすると入るらしい)。

 ffmpegとnodeサーバーの映像配信がWindowsで動かなかったのは、nodeのクライアント側のコードが、これを前提としていたためで、tmz7273さんからあらためてコメントを頂き、とりあえずコードの中のローカルホスト名(ホスト名.local)を直か打ちのIPアドレスに修正したら、難なくWindowsでも画像が配信された。懸案は見事に解決である。tmz7273さんには感謝、感謝である。

 これにより、Edisonの電池駆動の無線カメラの実用化は大きく前進した。早速1Fの居間に持ち込んで、ノートPC(WinXP)での画像配信を確認する。よーし、大丈夫だ。画面に地下のPCルームの光景が映った。

 この電池駆動の無線移動カメラはまだ何に使うか決まっていない。これが一番の問題なのだが、当面の目標は達成である。心なしか体が軽い。次の課題はこれの実装だ。ここまでは、本体と電池、それにDC-DCコンバーターそれぞれが、完全にバラックの状態である。 P4127056

電池駆動の移動カメラのケースの実装(4/7/2015)
 電池によって移動できる無線ウェブカメラというのは行き掛かり上の目標で、具体的な用途が決まっていない段階で実装するのは、少し危ない。とはいえ、このままにしておくわけにもいかない。せめて本体と電源関係はひとつにまとめて動かせるようにしておくべきだ。こうしておくと、次のアイデアも湧いてくるだろう。

 というので、手持ちのケースをいくつか取り出してレイアウトを考える。このあたり(タカチPB-2 110x80x33)が入りそうだ。2段にした単三電池4つのホルダーのため、秋月のCサイズの基板を少し切り詰めてマザー基板とする。

 ここにEdisonブレークアウト基板とDC-DCコンバーター、スイッチなどを置く。Edison基板は50本近くのピンヘッダーとソケットでマザー基板と固定する。Edisonの入出力ピンは、Vccが1.8Vである。3Vや5Vの一般のペリフエラル機器を動かすにはひと手間かかる。

 しかし心配ない。ちゃんと秋月では、1.8Vから5Vに双方向に動く8ビットレベルシフターIC(FXMA108)基板を用意してくれている。Edisonを買うときに、一緒に2つほど調達した。基板上の場所も確保してある。ただし、何に使うか決まっていないので実装は後回しである。用途の決まっていない基板のレイアウトはいつもながら難しい。

Edisonのシリアル端末が消える。nodeサーバーのソース解析に挑戦(4/10/2015)
 ところが、ここで大きな問題が起きた。突然、Edisonのシリアル回線が動かなくなってしまったのである。心当たりと言えば、ブレークアウト基板の下に密集しているGPIOピンにすべてピンヘッダーをつけて、マザー基板で固定するようにしたことだが、これが原因とは到底思えない。P4227062 Edisonブレークアウト基板はシリアルが動かなくても、OTG用のUSBソケット(J3)に、PCからタイプBのコネクターをつなげば、USBの仮想IPポートが生まれるので、WiFiがつながらなくても、そう心配ではない。とはいえ最後の頼み、シリアルが動かないというのは不安である。

 しかし、これにこだわっていたらいつまでたっても先に進めない。もし何かあれば、もう一台買い直す覚悟で先に進むことにする。まずは、今、直か打ちしているhtmlファイルの中のホストIPアドレス(Edison本体の)をnodeの中で変数として取得することだ。

 サンプルコードは何か事情があって、ホスト名にしか出来なかったと思われるので、もしかするとこの改善は難しいのかもしれない。しかし、今のままでは、Edisonの立ち上げのタイミングでその都度IPアドレスが変わってしまい、運用性が極めて悪い。

 この解決には、node.jsのソースが読めることが必須である。しかし、手続き言語のCなどと違ってオブジェクト指向のプログラムは、処理が外から見えないので、ちょっと読んだだけでは歯が立たない。何をやるオブジェクトなのかがわかっていなければ手も足も出ない。

 nodeの本を買って勉強はしているが、このEdisonのソースは、expressという定番のウェブサーバー用のモジュールを使っており、独自の変数や関数を自在に使っているので全くチンプンカンプンである。

 ただ幸いにも、nodeはWindowsでも動くそうなので、まずはEdisonではなくメインのWin7のPC上で実際にコーディングしながら勉強して行くことにした。しかし、これが苦難の道の始まりだった。

JavaScriptのお勉強にもどる(4/12/2015)
 nodeの言語であるJavaScript(以降js)の文法や構文はCに近い。かなり以前、頼まれてオブジェクト指向ではない普通のアプリケーションプログラムをjsで書いたこともある。nodeのソースはすべてjsなので、すぐ理解できるだろうと、なめてかかっていたのだが、どうも甘かったようだ。

 オブジェクト指向は、C++などが出る遥か昔のSmallTalkの時代に勉強し、理論としては完全に理解しているつもりだった。ただ、C++が出たころ、実際にコーディングしてみて、余りの煩雑さに途中で投げ出したことがある。

 C++はSmallTalkのように理論的に美しくもなく、既存の手続き言語を強引にオブジェクト指向化した言語だ。まともなクラスを作るのには結局アセンブラープログラムが必要だったり、グループで開発するならともかく、個人でプログラムを書くときに、効率の良い方法とはとても思えなかった。

P4127059 しかし、今度はそうも言ってはいられない。暫くもがいていたが、やっぱりjsそのものを理解しないと先に進めない感じがしてきた。 どんどん先祖へ戻る一番効率の悪いアプローチだが、ウェブ上で評判の高いこの本を買って来た。本当は、こちらなのだろうが、べらぼうな厚さの参考書をいちから読み進めるのは、この際、勘弁申し上げたい。

 買って読んでみてやっぱり後悔する。言語仕様そのものが好きな人には面白いかもしれない。オブジェクト指向の勉強にはいいが、実践的なところが少ない。どうも、このところ電子工作の参考書の選択は、恰好をつけすぎて失敗ばかりしている。これまでに参考書が役に立ったためしがない。

 しかたなくウェブサイトにもどって片っ端から、実際にコーディングしながら学ぶことにした。所長は、ウェブのアプリケーションプログラムの開発は殆ど未経験である。Perlで見よう見まねのCGIはやってはいるが本格的な開発はやったことがない。それでも最初のうちは好調だった。簡単にサーバーが作れる。

 node入門の記事に最初に出てくるコードはどこも殆ど同じで、これは問題なく動く。しかし、次のステップから一気に難しくなる。nodeではサーバーの構築は、色々な付加的なモジュールを使って進めるのが常道のようで、Edisonのサーバースクリプトにも使われているexpressがやはり定番のようだ。こちらも当然、expressを導入することにした。

node.jsのモジュールexpressが動かない。Lチカを超えられない(4/17/2015)
 ところが、このexpressが入らないのである。ウェブにはnodeについては無数の入門記事がある。Windowsだけの状況かもしれないが、多くの導入方法があり少しづつやりかたが違うが殆ど同じ手順だ。nodeのインストールはどれも順調に終わるが、expressに関してはいつも同じところで引っかかる。

 一見エラーもなく、expressはインストールされる。しかし、入っているように見えても、サンプルコードを動かすと、「そんなコマンドはない」というエラーではねられる。不思議なことにnodeはパスを必要とするのに、expressは必要としない(パスを通しても動かないことは同じ)。

 どうも、バージョンが変わるとインストール方法なども変わり、expressが所定のところに入っていない感じだ。新しいバージョンでは、npm install expressではなく、express-generatorを最初に入れないといけないのだそうだ。しかし、そうしてもexpressが動かない状況は変わらない。

 不思議なことに、カレントディレクトリー(サーバー環境の一番上のディレクトリ)には、expressをインストールするたびに、C;という一般には使わない記名のサブディレクトリが必ず定義され、ここにexpress関係が入ってしまう(セミコロンはCUIでは無効になる)。

 そもそも、nodeそのもののインストールからしていくつかの方法がある。あるところでは、「WindowsではNodistが良い」というし、本拠地のサイトから一式をダウンロードするのではなく、npm(nodeにおけるパッケージ管理環境)で新しいバージョンをいつも更新できる環境の方が良いとも言われる。

 いずれにしても、expressサーバーのスクリプトは動かない。色々なサイトを巡って片っ端から前の環境を消しては新たにnodeやexpressをインストールするが、全滅である。

 バージョンに合ったインストールをしていないことが、この混迷の原因だと思うのだが、今となってはもう遅い。Nodistという既にアンインストールしたはずのパッケージのディレクトリ名が、あのC;のディレクトリーの中に出現したりして、もうわけがわからない。

 そのうち、何故かいつもこういう状態でこれまで挫折していることに気が付いて愕然とする。雑誌の付録基板などのときも同じだ。言われるままにLチカまで進むが、少し先に進もうとすると一気に難しくなり先に進めなくなる。

 PID制御や、サーボモーターの時もそうだった。初歩の実験や理論については山ほど情報があるし、簡単に動くのだが、その先がわからない。今度もnodeサーバーが動くまでは至極簡単なのだが、その先に進もうとすると、こうして阻まれる。

 今の人たちは大変だなと思う。昔はベンダーに囲い込まれていたから、開発環境や、言語は選びようがなかった(歯を食いしばって頑張るしかなかった)。しかし、現在はオープンシステムで、それも百花繚乱、こうやって挫折しても次に移れる。しかし、簡単に移れることは逆に不幸なことなのだ(また同じ繰り返しになる)。

 このブログにも再三書いていることだが、理解できなくても我慢して浴びるように情報を摂取していれば、いずれは突然霧が晴れるように全貌が見える時が来る。これが電子工作(いやお稽古ごと全般)の醍醐味なのだが、現実となるとそう強がりも言っていられない。

 本当にnodeをこのまま勉強して行って、ものになるのか自信がなくなってきた。PCに向かっては、ため息をつく時間が過ぎる。そういうときは、何も考えず手を動かす作業が一番気が紛れる。このあいだの雑誌付録のUSB-DACのケースを作ったりして遊ぶ。P4237063

会社のPCでexpressは動いた。自宅でもなんとか成功(4/21/2015)
 それが、奇妙なことで解決したのである。自宅のPCでは何かゴミが残っているらしく、どうやってもexpressがうまくインストールできない。それではというので、仕事の出先のPC(Win8.1)に、まっさらからnodeをインストールしてみた(最近の仕事は開店休業状態で時間はたっぷりある)。

 手順の中では一番まとまっているこれを選ぶしかし、3のexpressの導入で引っかかる。前と同じだ。ただ、今度はこれまでに起きていた変なC;というディレクトリが作られる現象は止まった。ふーむ、少しは前進したか。

 次に、expressではなく、express-generatorだよと教えてくれたこのサイトの手順を試してみる。やっぱり、expressはコマンドとしては動かない。しかし、だめもとで、サンプルコードを動かしてみると、正常にサーバーが立ち上がったのである! 

 え、えー、ほんとか。間違いなくexpressを入れたHTTPサーバーが動いている。コンソールに直接expressを入れてもnot foundなのにnodeスクリプトとしては動く。わけはわからないが動いたことは事実である。

Express_test  帰宅して、とるのもとりあえず地下のPCルームにこもる。もう一度、全く新しいディレクトリを作り、環境変数も入念に今までのnode関係のものがないかチェックし、Program Filesの中も隈なく調べてnode関係がないことを確かめたあと、事務所で動いた2番目の手順をインストールした。

 おやー、事務所では出てこなかったC;というディレクトリが出来ている。やっぱりどこかにゴミが残っている。既に消したはずの、Nodistとか、最初に作ったワークディレクトリのNODEというサブディレクトリが出来ている。expressは危惧した通り、サンプルコードも動かない。

 しかし、このあたりになると、expressのディレクトリー構造がわかってきている。少し閃いたので、C;に入っていたexpressのディレクトリチェーンの中味を本来あるべきところへ強引にコピーし、C;ディレクトリを消して動かしてみた。

 ピンポーン!だった。見事に自宅でも、expressが動いてサーバーが立ち上がった。いやあ手間がかかった。こんなにnodeをインストールするのが大変とは思わなかった。原因は明らかに、C;という変なディレクトリを作る操作がインストールの途中で紛れ込み、それがexpressを動かなくしていたことは間違いない。

 しかし、それがなぜ起きているのかについてはまだ解明出来ない。また、expressそのものはまだコマンドとして単独では動かない。疑問はまだまだ残るけれど、expressはその後、処理を増やしていっても問題なく動いている。まあ、一山は越しただろう。やっとこれでブログに報告できるというものだ。

| | コメント (3) | トラックバック (0)

2015年4月 3日 (金)

Edisonの移動カメラ化はさっぱりすすまず

初めての五竜遠見スキー場。季節外れの豪雪(3/13/2015)
 今年2回目のスキー行が近づいた1週間ほど前、仕事から帰ってきて急に気分が悪くなり食べたものを戻した。微熱がある。夜遅くからは激しい下痢に見舞われる。どうもノロウイルスにやられたらしい。医者は3~4日で良くなると言ったが、出発まであと4日、スキーを中止するかは微妙なところだ。

 2日間は食事らしいものは何もとれず。スキーに行く前日にやっと下痢が納まり、おかゆが食べられるようになった。自分の車で仲間を乗せてスキーに行く約束をしているので中止は避けたい。連れに事情を話し、恐る恐る予定通りスキーに出かけた。

 関東平野は快晴だったが、スキー場に近くなると雪が激しくなった。春も半ばというのに猛吹雪である。宿のペンション前の坂が上りきれない。先に着いたもう一台の仲間の車は180度回転したそうだ。別の道から迂回して何とか宿の駐車場にたどりついた。

 今回のスキー場は、いつも出かける八方尾根の宿が競技会の本部になってしまったので、その隣の五竜遠見スキー場である。何十年もこのあたりに来ているが初めてのスキー場だ。楽しみにしていたのだが、体力が心配だ。

P3130352 でも泊まったペンションは当たりだった。ゲレンデにも近く、食事も上品で、ロビーに恐ろしく贅沢なオーディオ装置があるのに驚いた。バブルの儲かったときに先代が揃えたのだという。JBL4344などのスタジオモニター2組と、タンノイのArden(アーデン)が聞き比べられるようになっている。アンプはマッキントッシュ(管ではなく石)。クラシックはやはりタンノイが良い。

 体の方は、順調に回復した。当初食べられる量はみんなの1/4だったが、帰るころには普通に戻り、スキーをやるのには十分だった。ただ季節外れの大雪でゲレンデには、1m近い新雪が積もった。P3150367  腕試しに、圧雪していないバーンに飛び込んでみたら、雪が重く、スキーを浮かすことも出来ず、斜滑降のまま前のめりに転倒した。これが簡単に起き上がれない。深雪スキーなどと洒落れているような状態ではない。ほうほうのていで退散した。

 今回はノロウイルスのせいに出来るが、基礎体力は間違いなく低下している。残念だけれど仕方がない。体力相応(年相応)のスキーをやるしかない。まあ、スキーそのものは誰もけがもなく無事に東京に戻ってきた。

いんちきなSDカードリーダーで写真データを失う(3/17/2015)

 しかし、帰ってからも不運は続いた。スキーの写真をPCに移すため、カメラから取り出したマイクロSDカードをUSBアダプターに付けているうち読めなくなったのである。1回目は読めたのだが、2回目から全体が読めなくなる。ディスク自体がないというとんでもないエラーメッセージだ。

 USBプラグにSDカードのソケットがついている簡便なタイプのSDカードアダプターである。このアダプターは前にもこんな事故が有ったような気がする。確かこれで2回目である。SDカードを調べてみるとマスターディレクトリがこわれているようだ。家族が使っていたカメラなのでバックアップは殆どない。

 データそのものは壊れてなさそうなので、データを回収できるユーティリティをウェブで探した。有償、無償を問わず、無数のリカバリーソフトが見つかった。定番のものはなさそうだ。このあたりは商売になるようで、見つけるときは無料でも、取り出そうとすると有料になるソフトがあったりするので気を付けないといけない。

このリカバリーソフトで幸い99%の画像データは回収できた(家族の申告による)。面白いことにこのソフトは、Windows版はデータ回復が連続してできないなどの制約があるが、Linux版は全くフリーで使える。

 家族がカメラに入れたままにしていた写真データなので(大事なものはバックアップがあった)、幸い大事にならずに済んだが、一度事故があったにもかかわらず、このアダプターをそのまま部品箱に入れたままにしていた自分の不明を恥じる。このアダプターをどこで買ったのか今になれば全く思い出せない。とりあえずはゴミ箱に直行させた。

2つ目の抵抗を焼いて、遂にDCDCコンバーターの自作を断念(3/23/2015)
 こんなこともあって、電子工作の意欲は下がるところまで下がってしまった。Edison基板の電池電源の調査は、NiMH(ニッケル水素)電池4ヶを、DC-DCコンバーターNJM2360で昇圧して(7.5~9V)動かして以来、先に進んでいない。

 スキーに行く前に、インダクターを大型のものに取り換えたり、抵抗の定数値を変えてみたり、配線を短くして見たり、すこしづつ様々な方法を試していたが、いずれも目立った効果はなかった。

 性能に関わるファクターが沢山ありすぎる。まず、単体のNJM2360か、外付けにパワーTRを付けるか、さらにFETをつけるかの選択肢がある。それに、インダクターの種類でも結構性能が変わる(URL参照)。

 入力電源を何にするかでも最大出力電圧(電力)は大きく変わる。リチウムバッテリー(3.7~4.2V)の電池の大小でも変わるし、数Aの容量を持つACアダプターであっても、それに見合う電力が出るわけではない。定格容量内であっても電流を流していくと出力電圧が落ちて電力が下がる。 P3266976

 今のところエネループ、NiMH電池が一番高出力なようだが、これも満充電のとき(1.4V)は良くても、最後の方(1.1V以下)では、リチウムにも及ばない(4ヶで4.4Vなのだが)。

 色々いじったが、結局、入力をNiMH(4ヶ)に仮に固定し、設定電圧を7.5Vとして、単体では6.3V 294mA (1.85W)の出力が最大だった。外付けパワートランジスター(2SC3694)を入れても、6.7V 358mA(2.4W)までしか出力は出なかった。設定電圧は下手に上げたり(9V)すると、かえって出力は下がってしまう(電圧も電流も)。

 そもそもが、すべてブレッドボード上での実験である。汎用基板で組んでもうまくいかないことがあるという微妙な回路で、ブレッドボードのままで、性能が悪いと断定するわけにはいかない。それにしても心残りなのは外付けの効果があまり感じられないことだ。この回路図(FETひとつにTRを2つ)で組んだ外付けFET(IRLB8721)では、パワーTRより成績が悪かった。 

 実験をまだしていなかった最後の回路、FETとPNPトランジスターひとつ(2SA1015)を外付けしたものも試したみた。これも似たような性能で成果は上がらない。そのうち、誤接触で過大電流制限用の0.5Ω抵抗から一瞬小さな煙が出て、抵抗を焼いてしまった。

P3266989  ブレッドボードの配線をいじっているうちにVccをどこかでショートさせてしまったらしい。この抵抗を焼いたのは、これで2回目である。ひとつ5円もしないパーツだが、焼けて使えなくなってしまう(ひとつは断線、ひとつはキロオーム台に)こと自体が気分的に滅入る。これですっかり意欲を失ってしまった(へたれである)。

 UVCカメラ付きのEdisonを機嫌よく動かすには、7.5V入力なら、400mA以上を安定的に供給できないといけない(前記事の計測データから)。あともう少しなのだが、アナログは基礎がないので、何をするにもすべて手さぐりで方向を定められない。

 それにNJM2360は相当設計の古いICで、どこかのサイトでは化石とまで言われている。インダクターや、パワーTR、FETなど沢山部品を揃えてしまったが、ここからの撤退はそろそろ潮時のようだ。

ストロベリーのテスト前に、Intelブレークアウト基板の電源を調べる(3/25/2015)
 実は、スキーに行く前、前記事でとりあげたストロベリーリナックスのDC-DCコンバーター基板を注文してあった(これを2つ、これを1つ)。これらの基板は超小型で、いずれも3~5V入力から、20V近くまで昇圧し、電流も800mA以上出せるという触れ込みで、値段もそう高くない。

P4037050  スキーに行く直前に届き、簡単なテストをしたところ、NiMH電池入力でEdisonが短時間ながらストリーミングまで正常に動作してしまったのである。今までのNJM2360での最高はカメラを付けるまでで、ストリーミングはできなかった。

 この成功が、NJM2360のさらなる実験に力が入らなくなった原因のひとつなのだが、これが長時間カメラを動かし続けることできるかはまだわからない。このコンバーターの長時間テストの前に、Intel純正のこのブレークアウト基板の電源系統をもういちど調べ直すことにした。

 というのは、前の記事のコメントで、この基板には、5VのVccに直接接続する電源供給の方法があることを教えてもらった。そんなこともあるので、安易にストロベリー基板に頼る前に、何が最善策なのか基本的なところを押さえておきたいと思ったからである。

 頂いたコメントにもあるように、この基板の詳しい回路図は秋月電子のホームページにPDFとして出ている。それによると、基板には、以下の3つの電源関係のICが載っている。型番から調べるとそれぞれ次の機能を持っているようだ。

MIC2039   電流制限IC
BQ24079   リチウム電池充電IC
TPS62133   降圧DC-DCコンバーター

完全な理解ではないが、これまでに調べたところでは、外部の7.5~15V入力は、TPS62133の降圧コンバーター入力で、一旦5Vに落とし(5V_SYSとVBUS)、5V_SYSは、MIC2039の電流制限ICと、BQ24079のリチウム電池充電ICを経由して、V_SYSとなり、これがEdisonのVccに入る。従ってVccは5Vではなく、リチウムバッテリーの3.15~4.4Vの範囲である。

 このDC降圧コンバーターの効率がどれくらいか、コンバーターを通さないで、直接5VをDC-DCコンバーターで作って供給するのが良いのかどちらが良いかは難しいところである。効率からみれば直接の方が良いに決まっているが、負荷の変動にどちらが強いかはわからない。

 コメントにある5V供給というのがどこから供給することを指すのかわからない。5V_SYSは、このPDFの回路図によれば、端子として出ておらず、簡単に5Vを供給するポイントはない。VBUSはEdisonのOTGのUSB機器に供給する5V出力で、ここから供給するのは何かおかしい(一応SBDを介して5V-SYSに入るようになっているが)。

 何度も回路図を調べたが、適当な5V供給ポイントが見当たらないのと、この基板で完結している系を乱したくなかったので当初の予定通り、7~15Vの外部入力ラインに9V程度の電圧をかける方針で行くことにする。

ストロベリーリナックスのDC-DCコンバーターでカメラが長時間動いた(3/26/2015)
 このストロベリーリナックスのDC-DCコンバーターは、短時間ながらスキーに行く前、Edisonにつないでカメラのストリーミングが動いた。ただし数分しか動かしていないので、安定して動くかどうかはわからない。長時間テストに入る。

P3116971  最初、スルーホールに接続できるジャンパーと電流値を測るためのシャント抵抗を入れたミニブレッドボード上の配線で試してみたが、どこかで接触不良が起きるらしく、立ち上がるもののカメラをつないだり、基板を動かしたりするとリセットした。

 そこで、コンバーター基板にピンをハンダ付けし、ミニブレッドボードにしっかり差して動かすと安定した。一時間経っても、全く問題なくウェブカメラは動作した。よーし、電源のハードはこれで決まりだ。NJM2360は残念なことをしたが、さすがは既製品のDC-DCコンバーターである。この程度の負荷では殆ど熱を持たない(Edisonは触れないほどではないがカメラを動かすと結構熱くなる)。

 Edisonのウェブカメラの負荷はどれくらいだろう。topコマンドで測ってみる。それによるとCPU使用率は50%で、これはmjpg-streamerのモーションJPEGでも、node.jsのffmpegのMPEG1ストリームでも変わらなかった。

 PC側のリソースメーターで見ると、転送量はモーションJPEGでは2Mbpsを超えている。一方、node.jsはMPEG1なので1Mbps以下である。apacheなどのHTTPサーバーを入れるとCPU使用率は50%ではすまなくなり、もしかするとこのストロベリーのDC-DCコンバーター基板では動かなくなる危険もあるが、現在のままでは、とりあえず問題はない。

P4037046_2  やれやれ、やっとのことでハードの問題はクリアしたようだ。次はこれをどういうパッケージに実装するかであるが大きな峠は越した。次の課題は、ストリーミングソフトの決定である。

node.jsではどうしてもWindowsで画面が出ない(3/28/2015)
 NiMH電池による電池駆動は順調である。電池の充電も2回目に入った。途中で止まることもない。単3のエネループ(1900mAh)4ケで、少なくとも3時間以上は動いているので実用には十分だろう。

 問題は動画ソフトである。ストリーミング画像はmjpg-streamerも、node.js(ffmepegのMPEG1)のどちらでも安定して出ている。node.jsの方が軽くて良いのだが、実はこいつはWindowsでは画像が出ない。一方、mjpg-streamerはWindowsでも画像が出るのだが、自分用の画面を切り出すことが難しい。前のRaspberryPiのときは難儀した。

 このmjpg-streamerのHTTPサーバーは簡易版で、CGIをサポートしていないだけでなく、スタイルシートがとても複雑で改造を諦めた。モーションJPEGなので反応が遅く、全体に重い。自分用にカストマイズしたいのならApacheなどの別のサーバーを必要とする。

 そこでnode.jsの方をサーバーとすることにし、画像をWindowsで出せるよういろいろ調べてみた。いじったところは、主にffmpegのパラメーターである。しかし、色々、パラメーターをいじるが(ffmpegの)、何を入れてもダメである。Webを探し回るが適切な情報はない。どうも原因はffmpegではなく、node.js側にあるような気がしてきた。

 しばらくはnode.jsのお勉強をする。node.jsはPERLやRUBYのようなスクリプト言語(JavaScript)のインタープリターと考えれば納得がいく。インタープリターなのでソースコードが直に見える。調べたところでは、jsmpegというコマンド(?)がストリームをデコードしているようだ。

P4037054  しかし、ウェブを幾ら漁っても、これがWindowsでは動かないという文言が見当たらないのである。うーむ、ウェブの断片的な情報では、全体をつかむのが難しい。ちょうど良い機会なので仕事の帰り、久しぶりに秋葉原の書泉に寄って、こんな本を買ってみた。

 書泉はさすがに専門書が揃っている。node.jsの本だけでも10冊近くあった。ただ、何が適当な参考書なのかはわからない。迷った末、定番のオライリー本にする。脱線につぐ脱線だがまあ許してもらおう。このあたりでブログに報告することにする。もう20日も経ってしまっている。

| | コメント (4) | トラックバック (0)

2015年3月11日 (水)

Edison君に遊ばれている。UVCカメラの電池駆動の企みは難航

せっかくのUVCカメラが消える(2/22/2015)
 久しぶりのLinuxである。Edisonカーネルのビルドは出来たが、元のカーネルが既にUVCカメラをサポートしていることを知って、ビルドを中止し、あちこち(こことかここ)のサイトを拾い読みして映像配信(ビデオストリーミング)の実現を先に進めることにした。

 まず、このサイトのffmpegを使ったストリーミングサーバーに挑戦する。ところがリソースをとってくるgitが動かない。gitなどないというメッセージだ。このEdisonのパッケージシステムはopkgと言って、Ubuntuのapt-getと同じようなスタイルなのだが、とりに行くサイトのURLは自分で登録しなければならない。しかも、公式のものより、非公式のこれが良いと勧めるサイトもある。

 この登録しておかないと読みにいかないということがわかるまで暫く四苦八苦していた。映像配信については参考にするサイトが複数あるのだが、手順が微妙に違うので大変である。それにPCのOSがLinuxのときは(カーネルのコンパイルはここでしかできない)、今入力している端末がUbuntuへのものか、Edisonのものかが途中でわからなくなって混乱する。

 やっとのことで、ストリーミングサーバーのインストールに成功した。ただちに実行コマンドを投入する。うむ、動いたぞ。メッセージが出てきた。何い、カメラがない? 本当だ、USBカメラがなくなっている(dev/video0がNot Found)。

 どうしてだろう。アプリをインストールしただけでUSBのUVCカメラを認識しなくなった。何回か試してUVCカメラが入っていないことを確認する。そのうち、カーネルブートの途中で怪しいエラーメッセージがでているのを発見した。

 おやおや、kernel moduleの組み込みに失敗したというメッセージだ。途中から入るディバイスドライバーがインストールされないのでUSB関係は全滅だ。うーむ、わからない。これまでに入れた、ストリーミングサーバーと、カメラの画像を配信するソフトが悪さをしたのか。詳しく調べると、bcm_bt_lpmというモジュールが見つからないというメッセージである。これだけでは全くわからない。

 わけもわからず、ソフトをインストールしまくってきたので、原因の追究はほとんど不可能である。これらの映像配信ソフトは、新しいカーネルが前提なので、今のものと不整合になっていることは十分あり得る。インストールの途中で、こうした設定ファイルを壊したのかもしれない。P2236954

 というので、中止していたカーネルのビルドを最後までやってみることにした。これがまた長い。 PCのUbuntuでの作業である。カーネルイメージを作るステップで、ただファイルを焼くだけだと思っていたが、3325もの作業ステップがある。延々と何やら作り替えている。結局2時間6 分もかかった。やっとのことでPCにカーネルイメージが出来たようだ。

 いよいよ、Edison本体に焼込である。祈る気持ちでスクリプトコマンドを入力する。これはそれほど時間がかからなかった。さあ、カーネルが新しくなった。勇んでリブートをかける。ありゃあ、同じところでエラーが出たようだ。

 まちがいない。dmesgで確認すると、全く同じ状況でUSBディバイスがインストールされない。こうなると元のカーネルに戻すしかないが、その方法は急にはわからない。当然、無線LANも初期状態に戻っている。初期状態に戻せなければ、Edison君がゴミに近い状態になってしまう。顔が青ざめてくる。

 気分を鎮めて、周辺を確認する。救いは、エラーは出ているがシステムは立ち上がっていることである。カーネルでのUSBは認めないが、コンソールのCOM7はブレークアウト基板にある独立したUSB-TTLモジュールを使っているので、シリアルコンソールは動く。

ダメもとのreboot otaで復活。映像配信まであと少しなのだが(2/23/2015)
 USBソケットからではなく電源ピンからの給電でEdisonは動くことはわかった。まずは一安心である。現在の状況をまとめてみると、J16からのファーム焼込は不能。カーネルモジュールの読み込みがエラーでできないのでUSB関係は動かない。PCからは何も見えない。Ws000001

 J3のシリアルコンソールは動いているので、ここのシェルを経由してOSにコマンドを送ることは出来る。とにかく、わからないが、スイッチサイエンスの「買ったときに最初にやる方法」をやってみることにした。動いているシェルから、roboot ota を入れてみた。マスストレージのイメージは消えていないだろうという読みである。

 余り期待をしていなかったのだが、これが見事に動き始めた。順調にファームを書き換えて行く。そもそもこのreboot otaというのが何をするステップなのかわかっていないのだが、とりあえず何かやっているようなので期待は持てる。

 再構築が終わったというメッセージが出た。もう一度電源を入り切りして立ち上げ直す。なんと、あのエラーメッセージが消えた。NO ERRORでシステムが立ちあがった。いやあ、助かった。今まで入れたパッケージは消えたが、初期出荷時に戻ったことは間違いない。

 もういちどopkgをインストールしなおし、gitも入れる。段々様子がわかってきた。インストールしたffmpegは動いている。UVCカメラに作動中のLEDが点くので、このあたりは問題なさそうだ。nodejsのサーバーも動いている。不思議なことに今度はブート時のエラーメッセージは出ない。

 両方のパイプ(カメラとffmpeg、ffmpegからサーバー)も、どちらかを切ると反応があるので映像は送られているようだ。しかし、ストリーミングの映像を確認することが出来ない。うーむ、あと少しなんだけどな。

mjpg-streamerで念願の画像表示成功(2/25/2015)
 ffmpegが難航しているので、このあいだのRaspiで最初に動かしたmjpg-streamerを試してみた。こいつはソースからコンパイルしなければならない。道が遠いので敬遠していたのだが、そうも言っていられない。

 以前のRasPiのときは難航したcvnからのソースダウンロードは幸いあっさりOKとなった。opkgとgitを最新のものにしたからかもしれない。コンパイルも順調に終わった。動かしてみた。Edison_mjpg

 やったー、こちらは案外あっさり絵が出た。一度RasPiで動かしているからか。  2回目の成功とはいえ、やっぱり嬉しい。フレームレート15で640x480の映像が、快調に配信される。記念すべき、Edisonからの画像配信である。

 それにしてもたいしたものだ。カメラのUSBケーブルの方が重くて小さな本体が振り回されている。こんなちっぽけなものがWiFiを通して画像を送り出しているのだ。  これを電池駆動で動かせたら、移動体からの画像発信という夢の実現である。暫くカメラを動かして遊ぶ。ただ、このmjpg-streamerのHTTPサーバーの部分の改良は前に失敗している。このままでは、自分の好みの画面にすることは難しい。

 ということで、この前、途中のままだったffmpegの方を再挑戦することにした。この組み合せのサーバーには、耳新しいwebsocketという、これまでお馴染みのHTTPサーバーを使わないプロトコルを使った方式だという。

 この前、動かしたときEdison側は正常に動いたように見えた(エラーメッセージがないだけだが)。しかし、クライアントのPC側では画面枠はでるものの画像そのものを見ることが出来ない。mjpg-streamerの方が動いたので、少し余裕を持ってこのwebsocketと言う手法を少し丁寧に勉強してみることにした。

驚異のnode.js。websocketという新しいプロトコルで画像が出た(2/28/2015)
 この方式はHTTPサーバーを経由するのではなく、nodeというスクリプト処理プログラムでHTTPドキュメントを送るらしい。ひとつひとつがシングルスレッドで動く。つまりクライアント側とは常に一対一なので、多数で動かすときはかえって効率が良いのだという。

 確かに、マルチCPUがクライアント側でも当たり前になったり、回線の容量が桁違いに増えた状況では、Apacheなどの少数のサーバーにデータを集中してリクエストを一元化しているより早くなるのかもしれない。

 理屈はわかったが、実装がどうもまだ理解できない。node.jsというスクリプトマネージャーのようなところで、HTTPドキュメントを送っているようだが、具体的なデータの授受の手法は全く理解できない。

 実際に動かしてみると、エラーもなく動いているようで、クライアント側も反応があるのだが、画面の枠だけが表示されて、画像は出ない状況である。とにかく何を調べれば良いのか全く見当はつかない。P2266962_2

 ところが、PCでLinuxを立ち上げて、ウェブブラウザー(FireFox)を動かしていた時のことである。試しにURLを入れてみたら、突然、画像が表示されたのである。何だ、何だ、動いているではないか。画素数が320X240で荒いけれど間違いなくUVCカメラの画像である。

 パラメーターを640X480に換えて再始動してみる。ちゃんと高解像度で立ち上がった。何ということだ。Linuxでは動いていたのだ。慌てて、OSをWindow7側に切り替えてみる。やっぱりWindowsでは動かない。FireFox、IE、Crome、どのブラウザーもことごとく画面枠だけで表示されない。P2256958

 しかもLinux側では、IPアドレスではなく、node.jsに定義したEdisonサーバーのドメイン名を、クライアント側で入れるだけでリンクしてしまう。ええー、PCホストの/hostsやネームサーバーに登録もしていないのにどうして?

 いや、今までの概念を超えた方式のようで、まだ何が何だか良くわからない。Windowsでは動かないが、まあ、ここまでくれば上等だ。カメラを車に積んで景色を外に配信することは夢ではなくなった。

 残る問題は、カメラを含む大電力の供給である。Edisonは7.5Vから15Vの外部電源を要求する。これはUSBを含めた大きな消費電力を安定的に供給するためのマージンをとっているからと思われるが、この供給には、結構大きな電池が必要である。

 車載カメラの課題は、Edison本体から、電源の問題に移ったようである。

モバイルで動かそうと高出力DC-DCコンバーターにはまる(3/4/2015)
 Edisonによる車載カメラのプロジェクト(自然発生的だが)は、バッテリー電源の実装の段階に来た。その前に、実際のEdisonの消費電力を調べてみた。以下の数字はすべて7.5VのACアダプター経由で、1オームのシャント抵抗で測った電流値である。

 OSを立ち上げてアプリが動いていないとき     50mA
 ブート時やTopなどの常駐アプリ稼働時     ~120mA
 USB UVCカメラを接続し、OSが認識        ~150mA  
 Mjpg-streamer 静止画                  ~250mA    
     同上    動画                  平均350mA

始めマルチメーターで測ったときは、ピークが1Aを超す時があったので心配したが、オシロで確認してみると、1Aを越えるときは一瞬のピークの時だけで、ほとんどは上記の範囲に収まっていた。

 さて、7.5V以上のDC電源である。一番早い解決は、リチウム充電池(3.7~4.2V)を2つ直列にして、7.4~8.2Vを得ることである。余りにも芸がないが、これで動けば何の問題もない。実際に動かしてみた。

 ところが、UVCカメラを動かすあたりから動作がおかしくなり、現実に画像を送り出すには、この850mAhのバッテリーでは容量が足りないようだ。恐らく大電流時に電源電圧が規定より下がってしまうからだろう。もっと大きな容量のバッテリーか、電圧を上げる必要がある。

 さあ、困った。ちょっと前から、可搬で動かそうと、リチウムバッテリーひとつで7V以上をだすDCDCコンバーターの試作が難航している上に、究極の解決法も見事失敗した。別の方法を考えなければいけない。

 現在、試作しているコンバーターは、NJM2360がターゲットである。手持ちにはLM2735という新世代のチップがあるが、こいつは、既に何個か壊して少し挑戦する意欲が失われている。NJM2360の方は、沢山の方が色々試されており情報が豊富だ。とりあえずはこちらで進めている。

 外付けのパワーTRをつけると2A以上の出力が出せるらしい。トランジスターは発熱するので、どうせ作るなら、ここをFETにしようと回路図を探すのだが、なかなか適当なものが見つからない。

 それでも、いくつか回路例が見つかったので、手持ちのFETで回路を組んでみるが全然ダメである。始めブレッドボードのためかと思ったが、調べを進めるうち、リチウムバッテリーのような低電圧では、FETのゲートをドライブできないことがわかる。

 モータードライバーに使ったFETアレイ(MP4401)が、低電圧でも(2.5V)で動きそうなのを発見して、急遽さしかえる。動いたぞ。いや、リチウムバッテリーだけでは無負荷の時に電圧がでても、ちょっと負荷をかけると途端に電圧が下がってしまう。試しに、Edisonをつないでみるが、思った通り、立ち上がるものの、すぐ電圧が低下してリセットしてしまい使えない。

 いつものように、はまりだすと止まらないのが所長の悪い癖である。NJM2360にこだわってしまった。ストロベリーリナックスのDCDCコンバーター(LM2735)は、800mA(12V)が出せるというのをみて意地になってしまったこともある。

NJM2360にパワートランジスターを外付けしても動かない(3/8/2015)
 秋葉原に出た時に、秋月で、パワートランジスター(2SC3694)とゲート閾値電圧の低いFET(IRLB8721)、それにトロイダルのインダクターなどの部品を揃えた。本格的なDC-DCコンバーターを作る覚悟である。完全なプロジェクトの脱線だが、これはいつものことだ。

 まずはデータシートにも紹介されている外付けトランジスターによる出力である。これがうんともすんともいわない。ブレッドボードが原因ではないだろう。トランジスターのないときは快調に既定の電圧が出る。

 何度か、配線を確かめるが誤りはない。部品の定数を替えたりブレッドボードの配線を変えたりするが変化はない。どうも基本的なところが間違っているように見えるが、データシートを見ても間違っていない。インダクターをトロイダルに変えると、FETも入れない裸のNJM2360の方が、高出力になったりして気に入らないのだが、もっと気に入らないのがこのTRの不動作である。

 思いあぐねていたころ、ふと、トランジスターなどの極性を調べるテスターを以前面白がって買ってあったことを思い出した。(DCA75)。まさかと思うが、これでパワートランジスターの極性を調べてみよう。部品棚からDCA75を取り出して、早速測ってみた。なんとなんと、これがあたりであったのである。P3106967

 驚くことにパワートランジスターのピンの順番は、2SC1815などの小さなTO-92パッケージのものとは逆だったのだ。小さい方は、ラベルを見ながら左からECBなのだが、2SC3694のような TO-220タイプのピンは、ラベルを前にして左からBCEなのだ。

 データシートにはちゃんとそう書いてある。しかし思い込みとは恐ろしいものである。ふんふん、左からECBねと、ろくに確認もせず配線していた。パワートランジスターだから逆差ししても何にも起こらなかったけれど、いやいやお恥ずかしい。

NiMH電池でも、DC-DCコンバーターでは動かず(3/10/2015)
 トランジスター外付けのNJM2360はピンアサインを正しくして何事もなく動作した。負荷抵抗をつけて出力電流を測定する。インダクターをトロイダルの大型(9A)を入れたりすると、さすがに単独より大きな電流(350mAぐらいまで)を大した電圧降下もなく(7.5V設定で、7.02V)取り出せる。P3116974

 ブレッドボードなので少し不安があるが、こんなものだろう。まずリチウムバッテリーの電源でやってみる。いや、これは単独の時と同じで、Edisonの立ち上がりまでが精いっぱいで、USBカメラを付けた時点でハングする。トランジスターの外付けの効果はない。

 さてそれでは、用意したエネループ電池(NiMH)ではどうだろう。4ケ用意したので1.4X4=5.6Vまで上がるし容量も心配ないはずだ。動かしてみる。Edisonの立ち上がりは勿論OK。USBカメラも問題ない。さあ、最後のストリームサーバーの始動だ。

 残念、ストリームサーバーを動かした時点でシステムが不安定になり、ネットが落ちた。うーむ、難しいものだ。当面の方策はすべて失敗である。どうもお店を広げすぎたようだ。このへんで、戦線を整理し、ブログに報告することとしよう。

| | コメント (4) | トラックバック (0)

2015年2月21日 (土)

RaspberryPi 2ではなくて、Intel Edisonを買う

 最近の超小型CPUボードの進歩の早さは眩暈(めまい)がするほどだ。ブームに先鞭をつけたBeagle Boardが出たころは、1万円の前半(それでも超安値)だったが、ここへきて高性能、低廉化が止まらない。最近のRaspberryPi2(以降RasPi2)に至っては、これまでと値段は全く変わらないのにCPUがいきなり4つになって性能は6倍だという。

 RasPi2は秋月電子などの大所(おおどころ)の電子部品店でも販売が始まり、何度も発売直後に売り切れたりして、ちょっとしたブームである。BeagleBoardのとき、「これはもうPCだから、電子工作としてはやらない」と宣言した当研究所としても、先代のRaspPiのときは、余りの安さにたまらず2台も買ってしまった。このRasPi2の出現を心穏やかに見守れる状況ではない。

 これくらいの速さになると、ちょっと前のノートPCクラスのパソコンの性能である。これが手のひらサイズになってしまったのだから、アプリケーションの可能性は想像を超えて限界が見えない。アマチュアだけでなく業界そのものも何となく浮き足立ってしまっているような感じがする。

 しかし、アマチュアにとっては、今回の飛躍的な性能向上は実はアプリケーション的には、かえって使いにくいマシンになっている。これだけ性能が向上しても、用途が簡単に見当たらないからだ。それに、この高性能を生かせるアプリはどうしても大がかりになり、自作は容易なことではない。

 当研究所に導入された2台のRaspiは、幸い就職先が見つかり(一台は、我が家の現役ファイルサーバー、もう一台は予備役だけれどWebカメラ)、無駄にならずにすんでいるが、最初に買った初代のBeagleBoardと、BeagleBoneBlackは、用途が決まらないまま、多くの雑誌付録基板と同様、部品箱の不良在庫(積み基板ともいう)になっている。P2216943

 こんなわけで、迷った挙句、タイトルのようにRasPi2ではなく別のCPUボード(ボードというよりカード)を買ってしまったのだが、その経緯はあとで詳しく説明するとして、まずは、ここ2週間の電子工作の作業記録から報告する。

表面実装のDC-DCコンバーター基板完成(2/9/2015)

 LEDペンライト2号機を作っていた時にご紹介した、DC-DCコンバーターチップのMNH7601である。効率が良いというのでAitendoから買ってきてブレッドボードに組み、動作を確認したのだが、ブレークアウト基板にしようとして、チップの変換基板が大きなスペースを占めるのが気になった。P2066881

 せっかく、SOT23-5という3ミリ四方の小さなチップなのに、変換基板はmilピッチで4×3ピンの大きさで無駄に大きい。心電計プロジェクトが片付いて手が空いたので、これまで考えていた小さく実装する方法を試してみることにした。

 その方法とは、以前、用もなく買ってあった秋月の表面実装(SMD)汎用基板を利用して作ることである。買ったとき店頭で店員に聞いたところでは、この表面実装のパッドのピッチは1ミリピッチで、mil規格のものとは合わないということだった。

 しかし、SOT23のピンピッチは、0.95ミリとインチ規格ではなく、この1ミリピッチにぴったり合う。実際にチップをこの基板に載せてみると、横3ピンくらいなら0.05ミリのずれは全く問題にならないで綺麗に配置された。

P2076901  早速、秋月でこのために買ってきた47μFのチップセラコンと、表面実装のインダクターを載せてレイアウトをしてみる。うーむ、変換基板のときより高さは間違いなく低くなるが、面積はそう減らないな。

 簡単に見えたが、ハンダ付けは結構難儀した。難しいのは短い配線である。試行錯誤でやっとコツがつかめた。それはUEW線を短かく切ってしまわないで、長いままハンダ付けして行って、そのあとで切る。短くなったときは必ず、ピンセットなどで固定し浮かさない。さもないと一旦ハンダが溶けたら短い線は必ずハンダごての方に持って行かれ作業は振出しに戻る。P2076907

 たいした配線量ではないので、ほどなく完成した。チップの横の使わないパッドはミニルーターで削り取ったが、特にその必要はない。ハンダブリッジはすぐわかる。気分的なものである。このあいだのLAN基板のこともあり、少し強めに部品を動かして固定を確認する。よし、大丈夫だ。

 通電した。白色LEDが眩しく点灯する。いやあ、こんなものでも動くと嬉しい。インダクターが大きすぎたため、専有面積だけでみると、以前作った写真のHT7750基板に負けている。まあ、自己満足の世界である。P2126927

焦電型人感センサーのトラブルシューティング(2/11/2015)
 次の工作は、前々から気になっていた階段照明の自動点灯装置の修理である。Tiny13で焦電型の赤外線人感センサーを制御し、人が近づくとスタンドに明かりがつき、何秒後かに自動で切れる。意外にも家族で人気になり、すっかり実用品として活躍している。

 ただ、こいつ高感度なのは良いが、冬にエアコンの暖房をつけると、つけた直後の微妙な温度上昇で誤動作が頻発する。以前、入力ピンの基準電圧を上げたり色々やったが、改善できなかった。

 誤動作と言っても、照明が少々無駄に点くだけでそれほどの実害はない。まあ人感センサーそのものも、それほど正確性があるわけでもないので(良く駐車場などで突然点いたりしている)、放置していたのだが、手が空いたので少し本格的に修理することにした。P2126917

 方策は考えてある。微妙な温度差で動くのは、オペアンプの増幅度が高すぎるのではないかと言う仮説である(現在2段で1350倍)。このためアンプの1段目に半固定の抵抗器を入れて増幅度を下げてみる。ところが回路図が見当たらない。こういうときのブログである。PCを立ち上げて記事一覧を検索する。すぐに回路図は見つかった。

 画面が階段の上部で見られるようにオシロを機器のそばに移動し、反応をチェックする。ここで反応する限界まで増幅度を下げれば、誤動作が一番少なるはずだ。その結果、400倍くらいまで下げても十分反応し、誤動作は明らかに少なくなった。

P2216951  しかし回数は少なくなったとはいえ、ゼロにはならない。今度は固定抵抗を交換してさらに200倍まで落とした。反応は余り変わらない。いつものように距離3メートルくらいの階段上部でも確実に反応する。さらに誤動作は少なくなったが完全にはなくせない。

 温度変化による変動は、オシロで見ていると、温度が上がり始めると、5秒周期くらいの緩い上下動が少しづつ始まり、何回かののちついには閾値にまで下がって、その後、元にもどり、暫くするとまた始まるという周期を繰り返している。P2216953

 そもそも人を感じるということは、こういう微妙な熱変化を連鎖反応的に増幅して動作に結びつけているわけで、これを否定するわけにはいかない。しばらくこれで様子を見てみよう。

Raspberry Pi 2を横目で見てあえてIntel Edisonを買う(2/14/2015)
 RaspberryPi2である。色々なところで話題になっている。秋月では、売り出し初日で売り切れたそうである。何しろ価格据え置きで性能6倍だ。使うあてがなくても食指が伸びる。

 欲しいと思う半面、余りみんなが騒ぐと、その反動でむくむくと反抗心が出てくるのが当研究所の所長の性格である。自慢ではないが、天邪鬼なことでは誰にも負けない(あ、やっぱり自慢しているか)。だいたいこのRasPi2、買って何かに使うあてが全くない。以前のBBBなども使いこなせず積み基板にしているのに。

 自問自答しながら、それでも休みの土曜、自然に足は秋葉原に向かった。当然のように秋月も覗いて見る。これがすごい混雑だ。人が入口付近に密集し店内に入れない。余りの人出に驚いてしまう。RasPi2が店頭で売られているからだけではなさそうである。休みの日の秋月はいつもこんな状態らしい。

 しかし、RasPi2は買わないことに決めている。替わりに手に取ったのが、IntelのEdisonである。入口の平積み台にRasPi2と同じところに並んで売られている。実は元からこれを買う気で秋葉原を訪れた。そもそもEdison自体も今買わなければならない理由はないのだが、こういうのは弾みである。

 RasPi2ではなくIntel Edisonにした理由は次の通りである。まず、RasPi2には今思いつくアプリケーションがない。ただ速いだけでは面白くない。しかし、Edisonは無線LAN(WiFi)が標準でついているので、そのままロボットや、RCカーなどに載せて交信ができる。ウェブカメラを車載して周囲を見るというのは洒落ているではないか。

 しかも消費電力がRasPiに比べれば半分以下だ。ここでRaspiとの比較をしている。RasPiについている有線LANは大飯ぐらいで、150mAくらい平気で消費する。勿論、LANインタフェースのないAタイプもあるが、それでも本体だけで400mAは喰う(Edisonは公称250mA程度)。

 RaspiにあるHDMI周りのビデオの装備がないのもEdisonを選ぶ理由だ。RasPiのビデオだって、CPUパワーがまだ不足なので、限られた範囲の動画はともかく、Xwindowなどのデスクトップは、思ったほどスムーズには動かない。

 これがRasPi2で早くなるとしても、こうした大画面映像を動かす必要性はあまり感じない。事実、これまでのRasPiの開発でXを使ったことは殆どなく、全部キャラクターベースで済んでいる。このあたりのEdisonの考え方は割り切っていて、最初からビデオインターフェースが省略され、とてもすっきりしている。P2196931

 Edisonの物理インターフェースは0.5ミリピッチの精密なソケットなので、ブレークアウト基板が必須だ。Arduinoインターフェースをサポートするものと、しない基板とが2種類ある。所長はArduinoはやらないので、迷わず、素のブレークアウトボードを選ぶ。秋月で¥8,480。

 これが高いか安いかは論議のあるところである。ただRasPiにハブやWiFiのUSBドングルをつけたりバッテリーの充電装置(あまり宣伝されていないけれど、このブレークアウト基板にはリチウム充電池を充電する回路がついている)を入れたりすれば余り差がなくなる。

 というか、Edisonのこの小ささは尋常ではない。手のひらサイズということだが、これは手のひらではなくてSDカードのサイズである。拳の中にすっぽり納まる。ブレークアウト基板もRasPiの半分くらいしかなく、フリスクのケースに入りそうである。どうしてこちらがブレークしないのか不思議なくらいだ。

IntelEdison意外に手強い。やっとWiFiでつながった(2/15/2015)
 これが、簡単に行かなかったのである。スイッチサイエンスのサイトが一番詳しかったのだが、どこかが省略されていて、カーネルの再構成がうまく行かない。USBの仮想ネットワークがつながらないので、どうしてもシェルが立ち上がらない。

それならとシリアルを探すが、UARTが動かない。もうひとつのUSBコネクターからの UARTであることに気づくまで時間がかかった(その後、USBのネットワークがつながらないのはPC側の設定ミスと判明した)。

 マイクロUSBケーブルを2本差しし、やっとrebootが効いて、カーネルが作り直された。WiFiのテストに入る。これは順調に自宅の無線LANにつながった。しかし、地下からなので、IEEE802.3A(5Ghz)はつながらず、IEEE802.3G(2.4Ghz)しかつながらなかった。それでもつながった時は感動した。

 こんな小さな基板でたいしたものである。ブレークアウト基板を入れても、Raspiの半分以下の小ささである。これが無線LANを経由して、HTTPサーバーまで見える。RaspiやBeagleBoardで味わった驚きを、ここでも味わう。本格的なLinuxマシンが手の中に隠れるサイズで動いている。

Ubuntu14.04の導入にはまる。マルチブートが出来ないのであせる(2/16/2015)
 Edisonのカーネル再構築のため、メインPCでUbuntuを久しぶりに更新した。現在のカーネルはUVCクラスのUSBカメラをサポートしていないというのでその準備である。

 簡単に行くと思ったが、Windowsと共存を図るマルチブートではまった。最終的にはうまく行ったのだが、このあたりは失敗すると、OS全部が動かなくなる。冷や汗ものの作業である。

 長期対応版のUbuntu14.04をインストールする。インストールイメージのDVDをダウンロードし、現在のWin7のCディスク(1テラもあった)を少し削るという(150Gばかり)一番楽なインストールコースを選ぶ。

 小1時間くらいでインストールが無事終わったので、気楽に再始動をかける。ところがマルチブートローダーGRUBが全く出ず、これまでどおりWindowsが立ち上がるだけだ。ええー、何でー?インストールDVDのLinuxを立ち上げて確かめるが、Ubuntu14.04はしっかり所定のところへインストールされている。うーむ、どうしてだ。暫く考えていて思い当たるところが見つかった。

 現在のマシンは、動いているWin7システムにこれまで使っていたXPのシステムディスクを接続してデータを回収した。いわばブートディスクが2つある状態で動いている。BIOSのブートシーケンスから、このディスクは除外してあるので、Win7は何事もなく動いているが、Linuxでは怪しい。

 BIOSにはそれ以外にも、ディスクドライブの順序の設定というのがあって、前のXPのディスクドライブは、昔のパラレルATA(IDE)なのでWin7のSATAより優先順位が高い。良くわからなくなったので、このXPディスクの電源と、インターフェースケーブルをはずして再度Ubuntuをインストールした。

 ところが、これでも動かないのである。インストールの方法は、既に入れたパーティションに上書きする方法である。これも順調に終了したのだが、相変わらずGRUBは見えず、何事もなかったかのようにWin7が立ち上がる。

 ライブDVDのUbuntuでGRUBだけインストールすれば動くのかもしれない。ウェブサイトには、ライブDVDの立ち上げの時、コマンドモードにするオプションがあって、ブートシーケンスをいじれるような裏技が紹介されていたが、こいつは何をやってもカーネルパニックで先に進まない。

 インストールは簡単になったが、中の事情がわからないので途方に暮れるだけである。GRUBだけの個別インストールなんかはなるべくやりたくない(LinuxどころかWinまでが立ち上がらなくなる危険がある)。P2216942

 暫くぶりのPCでのトラブルである。今、Ubuntuが動かなくても致命的なことにはならないが、どうも、すっきりしない。デュアルブートではなくVMWareなどにすることも考えたが、このまま引き下がるのもしゃくである。

 インストールの方法にはいくつか種類がある。これを調べているうちに、ふっと気が付いた。もしかして上書きインストールの場合は、GRUB部分は全く同じだというのでここの書き換えは省略しているのではないか。上書きではなく、パーティションを指定してのインストール法に切り替える。ピンポーン!これが当たりであった。

 無事にGRUBの画面が表示され、やっとのことで、ディスクからUbuntuが立ち上がった。心配していた日本語環境も、インストール版はしっかりついていた(ライブ版では日本語入力不可)。

Edisonのカーネルビルドで一苦労。何とUVCは既についていた(2/20/2015)
 いよいよ目的の、Edisonカーネルの再構築である。ソースコードをダウンロードして最初からのビルドに挑戦する。当然性能の高いPCのUbuntuでコンパイルする。クロスビルドである。

 沢山の先人の方々が、この作業に挑戦しているので情報にはことかかない。どこのページを参考にするか迷うくらいだ。Edisonで映像配信をするためにカーネルのリコンパイルという、こちらがこれからやろうとすることと全く同じ目的のタイトルに惹かれて、まずはここを参考にする

 しかし、手順が複雑でなかなか先に進まない。数時間かかって、2800余りのステップの1937で挫折した。どうしてもひとつのエラーが抜けずに(bin/ubwebsockets-test-server近辺)、先に進まない。ここ以外にもいくつか違う手順があるようなのでここは諦める。

 次のサイトのほうは、動かしてみると、ここでのステップ数は400足らずだった。エラーは幸い出ず、警告1件だけで、ちょうど50分で終了した。いやあ、なんで同じ再構築でこんなにやり方が違うのだろう。

 勢い込んで、カーネル再構築のメニューmenuconfigを立ち上げて驚いた。もう現在のカーネルで、USBのUVCクラスはサポートされている。他にも色々なカメラのドライバーのチェック欄があるが、UVCクラスならこういうドライバーはいらない。UVCのサポートだけで動くはずである。

P2196929  ええーこれはどうしたことか。これらのサイトの記事が書かれたころは、カーネルはサポートしていなかったのが、最近になって入ったというのか。そう言えば、最初のスイッチサイエンスのインストール手順で、最新のファームをダウンロードして更新した。

 確かに、RasPiなどに較べれば情報は山ほどあっても、Linux周辺の基礎知識がないとまともに動かすまでのハードルが高い。EdisonのOS(Yocto Linux)は発表当初のバージョンが古くバグがらみだったということで評判を落としたと聞いている。このあたりがいまいちEdisonが盛り上がらない要因のひとつかもしれない。

 さらにウェブを検索する。キーワードを換えて行くと、続々Edisonがらみのページが見つかる。おお、usbのサポート状況を調べるコマンドがあった(lsusb)。ここのサイトを参考に、EdisonのOTGコネクターに、手持ちのUSBディバイスをつないでテストしてみる。ふむ、大丈夫だ。USBメモリーなどが問題なく認識され動く。さあ、それならUVCカメラはどうだ。

P2206934  どきどきしながら、UVCカメラをRaspiのWebカメラの雲台からはずし、Edisonに接続する。lsusbを入れてみる。な、なんと、なんと、全く問題なく、出力メッセージにUSBカメラの型番、LogitechのC270が表示された。/dev/video0もしっかり作られている。

 まだ動かせないけれど、ここまで認識すればもう大丈夫だ。何ということだ。あれだけ苦労したカーネル再構築は不要となった。まあ、貴重な経験をしたと考えることにしよう。それにいずれはやらねばならない作業だ。

| | コメント (0) | トラックバック (0)

«心電計は少しおやすみ。以前作った装置の修理にはまる