がた老AVR研究所

　ちょうど1ヶ月ぶりのブログの更新である。前回はTiny85のソフトI2Cスレーブのソースコードを公開したのだが、今回は全く別の話題である。

　ここのブログ（ココログ）は、アクセスされたページ数は時間単位でわかるが、公開したファイルが何回ダウンロードされたかは記録されない。この数が多ければアップロードにも力が入るのだが全くわからない。コメントや、リンク先の記事などが頼りである。

　これまでに、リニアPCMプレーヤーやソフトI2Cマスター、マイクロステッピングなどのソースは結構使って頂いたようで嬉しい限りだが、今度のI2Cスレーブはどうだろうか。自信はない。

　まあ、仕事ではないので気に病む必要はないのだが、反響がないと何となく独り相撲をとっているような感じで空しいものである（ちょっと自信作だったのだけれど）。そんなこともあって、I2Cスレーブへの熱意は急速に冷めてしまった。

　実は、この一ケ月電子工作から遠ざかっていたわけではない。むしろ、半田ごてを握っていた時間は近来になく多かった。それなのになぜブログを書かなかったのか。それは、これまでの工作とは全く関係のない工作で、しかも結果が中々でなかった。要するに「はまって」いたからである。

　I2Cスレーブの続きを期待して来られた方には申し訳ないが、以下は、この「はまった」内容の報告である。

安価な大容量DC-DCコンバーターチップFP6291を見つけた(11/2/2015)
　FP6291は、ChaNさんの最新作(パッシブストロボスコープ)に使われていたDC-DCコンバーターICである。Aitendoのサイトを覗いていたら、偶然、販売されているのを見つけた。何と2.5Aまで流せると書いてある。しかも￥50だ。破格の安さだ（LM2735などは￥200以上した）。これは買うしかないだろう。

　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種類。やれやれ。

　これが意外に、このリード型の一番小さいやつの成績がトップだった。性能が上がらないのは、どうも部品ではなくブレッドボードだからのようだ。ストロベリーリナックスの商品紹介のページには、DC-DCコンバーター基板は配線をコンパクトにしないと性能が出ないと書かれている。面実装にすれば所定の性能が出るのかもしれない。

　今Edisonのマザー基板に内蔵しているストロベリーリナックス製のDC-DCコンバーターモジュールでもインダクターは超小型である。それでいて、ウェブカメラのついたEdisonを楽々エネループ4本で駆動する。一時間つけっぱなしでも全く問題はない。

　面実装のコンバーターモジュールは以前、秋月の汎用SMD（面実装）基板で、Aitendoで手に入れたEMH7601というチップを使って作ったことがあるが、これは5Vまでしか昇圧できないのでEdisonの電源には使えない。しかも部品と部品の間は、UEW線でつないだ、いわば「面実装もどき」である。

　秋月のSMD汎用基板を見ているうち、アイデアが段々生まれてきた。横や縦の溝は、ハンダブリッジでつなぎ、不要なところはルーターで削り出せば、このSOT23のチップなら直接ハンダ付けして、すべて面実装パーツで組めるような気がしてきた。考え出すと、これが止まらない。

こだわると止まらない。面実装の部品を集める(11/7/2015)
　手持ち部品をテーブルの上に揃えてみる。FP6291のデータシートのリファレンス回路図のチップセラコン20μFは手持ちにはない（50μFはあるが、少し大きすぎる）。チップ抵抗は、何とか手持ちで間に合いそうだ。

　正確な基板の拡大図を作って、アートワークの作業を開始した。仕事の帰りまた秋葉原に寄って、秋月でこの前、売り切れていた20μFのチップセラコンを入手した。こだわると止まらなくなる。俺も好きだなあと、思わず苦笑いである。

　ミニリューターの丸やすりで、不要なパッドを削って、必要な部分だけにする。実体顕微鏡を見ながらの作業なので、あっと言う間に削り出しが進む。段々プリント配線っぽくなってきた。簡単に配線（というか）作業は完了した。思ったよりうまくできたので機嫌が良い。

　次は、線をまたがるジャンパーを裏にまわすビアの穴あけである。0.8ミリが少し大きすぎたようだ。ここは実体顕微鏡が使えないのでなかなか正確に開けることができない。これまでの機嫌がいっぺんに悪くなる（めげやすいタイプである）。

　ビアは、この汎用の面実装基板は、裏が全面銅面なので気を付けないといけない。そうか、この裏面をグランド面に使って配線するのが賢かったかなあ。しかし、アートワークが終わっているので今さら配線は換えられない。実体顕微鏡を見ながら注意深く裏面の銅面がジャンパーと接触しないように、ここだけ先にハンダ付けをすませる。

面実装の基板で苦戦(11/9/2015)
　いよいよ部品のハンダ付けである。部品そのもののハンダ付けは造作がないのだが、苦労したのが、パッドとパッドの間のハンダブリッジによる配線である。ハンダの表面張力が結構大きく、0.3ミリほどの隙間を恣意的にブリッジをかけるのがとても難しい。予期しないときには簡単にブリッジがかかるくせに、思ったところには出来ないものである。もどかしい。

　折角ブリッジが出来ても、隣のハンダ付けをしている間にいつのまにか外れている。CRあたりならとともかく、ICチップのところは何度もハンダ付けしたくないのになかなかうまくいかない。冷汗をかきながらハンダ付けを進める。

　やっとできた。念のため配線を確認する。うはあ、配線間違いだ。インダクターをダイオードの先につないでしまっている。やれやれ、ここはスペースがなくて回り込ませることはできない。やりたくないけれどジャンパーが必要だ。UEW線で付け加える。

　もう大丈夫だ。恐る恐る電源を入れる。だめだ。入力電圧と同じ電圧しか出力に出て来ない。熱を持ったりしていないので誤配線ではなさそうだ。慎重に最初から導通テスターなどで配線を確かめて行く。

　何度も確かめるが間違っていない。うーむ、ハンダ付けの熱で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回やりなおしてやっと成功した。これは本格的に自分のためのマニュアルを作っておく必要があるな。

　長時間テストに入る。うーん、やっぱり長時間は無理なようだ。10分くらいすると出力電圧のリップルが多くなり、それに比例してCPUが誤作動するのだろう熱を持ち始め、15分で、システムはリセットしてしまった。

　動くことは動いたが、これでは実用にはならない。ストロベリーリナックス(LMR62421)とAitendoのDC-DCコンバーター（SDB628）は1時間でも大丈夫なのに残念である。

ここまで来て撤退するのか。さらにこだわるのか(11/15/2015)
　さて、どうするか迷う。前にも書いたように、Edisonの可搬ウェブカメラは、市販のDC-DCコンバーターモジュールで既に実現している。実用的にはもう自作にこだわることはない。ただ、面実装にしたのに市販のレベルに達しなかったのが悔しい（ブレッドボードならあきらめがつくが）。

　何がいけなかったのだろう。データシートや、その中の推奨配置図などを調べる。データシートの文面には基準電圧を決めるFBの部分はなるべく他からの干渉を受けないよう最短距離で配線せよというだけで、インダクターなどへの指定はない。ただ、インダクターはICピンのなるべく近傍が良いようだ。インダクターのジャンパー線は性能低下のひとつの原因かもしれない。

　それに、せっかくこの汎用基板の裏面がベタアースなのにこれを活用していないのも気になる。ただ、もういちど作り直すのも良いが、ハンダブリッジで配線するのはICを痛めそうでなるべくやりたくない。

　このところ雨の日が多く、テニスもアスレチックジムもお休みで、地下のパソコンルームにこもる時間が増えたが、どうも手が動かない。電子工作の何か新しいテーマがあれば良いのだが、DC-DCコンバーターの失敗が尾を引いている。

　そんなとき、ふと新しいアイデアが浮かんだ。ハンダブリッジ配線の難しさを解消する方法である。ウェブでたまたま極薄の銅箔テープを使って面実装する記事を見て思いついた。銅箔で隙間を埋めるのだ。

　銅箔テープの裏には接着剤がついているので細くカットして隙間に固定すればピンセットで抑える必要もない。おお、これは我ながら妙案だ。早速、近所のホームセンターにでかけた。しかし、残念、エアコン工事用の分厚い銅箔テープはあったが、配線に使うような極薄の銅箔テープはなかった。

　あきらめきれず、ネットで探す。何だ、いくらでも売っている。薄さはみんな統一されて0.3mmでこれより薄いのはない。適当な（アマゾン）ところで注文をかける。やる方向が見えると、それまで憂鬱な気分がいっぺんに晴れる。早速、裏面グランドを利用した2台目のアートワークにとりかかった。現金なものである。

銅箔テープ届く。これもそう簡単ではなかったが何とか成功(11/18/2015)
　2日もしないうちに銅箔テープが届いた。アートワークも済んでいる。ミニリューターによる不要パッドの削り出しもすんだ。裏面グランドのビア（VIA）配線の前に、銅箔テープを使ったハンダブリッジがうまくできるかテストする。

　結論から言えば、銅箔の裏の接着剤はハンダの熱で簡単に無効になって、切れ端だけでは全く失敗であった。切れ端はあっという間に半田ごてに付着してしまう。しかし、ここで諦めないのが所長のしつこさである。

　前の「面実装基板もどき」のときにやった、UEW線のハンダ付けを思い出した。切れ端のUEW線ではなく、長いUEW線をピンセットで保持し、ハンダが冷えてからニッパーで不要部分を切る。この方式で銅箔をハンダ付けすれば良いのだ。

　カッターナイフで短冊形に切った銅箔テープの一部をパッドの隙間に置き（または配線したいところまでさしわたし）、ピンセットで押えながらハンダ付けをする。そのあと残りを切り取る。見事成功した。やった、やったぞ。ハンダが綺麗にパッドを横切って盛り上がった。俺は天才か。鼻が膨らむ。いやあ、こんなことで有頂天になれるのだから趣味というのは良いものである。

2台目の面実装DC-DCコンバーター完動す(11/22/2015)
　裏面のベタアースへのハンダ付けは、ハンダごての容量を心配したがその心配はなくきれいにハンダ付けが済んだ。2回目の配線なので進行が速い。大きさも形もほとんど同じ自作の面実装DC-DCコンバーターモジュール2号機が出来上がった（基板切り離しは完成後やる）。

　インダクターの取り回しはレイアウト上、データシート推奨図のように最短にはできなかったが、1号機のジャンパー線よりは短くなっただろう。アースがベタアースになったのが期待と言えば期待である。

　入出力のリード線をハンダ付けし（いずれはコネクターにする）、いよいよテストに入る。最初はマルチメーターを出力側につなぎ、エネループをつなぐ。全く音沙汰がない。ええー、どうした？とインダクターを押した途端、マルチメーターの電圧がOLの表示の後、10V近くを指した。

　いかん、インダクターのハンダ付けが不良である。慌てて、はんだごてを温め直し、たっぷりハンダを盛って中まで溶かす。ICではないので十分に熱を加えられる。テストに入る。よーし、大丈夫なようだ。しっかり所定の電圧が出た。半固定抵抗を廻して出力を9Vにする。

　さあ、問題のEdisonのウェブカメラの実験だ。念のため、オシロで出力電圧と、出力電流を表示させ、長時間テストに入る。Edisonが立ち上がる。USBカメラをつなぐ。消費電流はこの時点で150mAぐらいになる。ウェブにつなぐ。電流は300mAまであがった。

　10分経った。1号機はこのあたりからリップルが増え始めたが、今度の2号機はピクリともせず快調に動いている。大丈夫だ。20分、30分、依然として問題なく動いている。いやあ嬉しい。40分、少しリップルが出てくるようになったが、大したことはない。カメラは順調に動いている。

　1時間が経った。若干消費電流が増えてきたが、これはEdisonが熱を持ってきたためで電源のせいではない。リップルは殆ど変らない。最後まで見届けたいという気持ちもあったが、1時間以上は、市販のコンバーターでも動かしていない。もうこれで十分だろう。1時間も電池でEdisonを動かす機会もなさそうだし、このあたりで実験は終了することにしよう。

　ということで見事、2号機は1時間以上の作動に成功した。これで、がた老AVR研究所は、晴れてDC-DCコンバーターの呪縛からとけて、別の電子工作が出来るようになった。めでたし、めでたしである。

　今回もブログの更新が長い間滞った。正直なものでブログのアクセス回数は間違いなく記事更新間隔に反比例する。商売ではないので別に構わないのだが、アクセスが減っていくのを見ているのは余り気分が良くないものである。

　この間、電子工作をやっていなかったわけでもない。むしろ最近になく没頭しているのだが、結果が出ないので記事に出来ないだけである。先月、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()などの標準関数を使う。　ただ、Linux（UNIX）の標準入出力関数にはAVRなどと違ってキー入力を教えてくれる関数がない。これなしにコンソール入力コマンドを出すと、そこで処理が止まってしまうので具合が悪いのだが今回はコンソール入力をキーにパンやチルトをやるので問題はない。

　コーディングそのものはたいしたことはない。ただEdison内の開発環境は、まともなエディターもなく（あのviしかない）、リストの印刷もできない貧弱なものだが、紙に印刷してからデバッグするような大層なことはやらないし、ウェブなどで制御するのはまだ先の話だ。

　コンソール入力のフォーマットは、>角度１　角度2（enter）の入力で角度1のパン、角度2のチルトとなり、＞角度3（ブランク）（enter）　とやれば、角度3のパンだけ、＞（ブランク）角度4（enter）とやれば、角度4のチルトだけということにする。

　テキスト入力（0から180までの数字キャラクタ）の解析（パース）は、入力の最後から文字を拾って行くというのが鉄則である。無駄がない。文字列の頭から解析しはじめると泥沼になる。擬似コーディングで何度もシミュレーションして仕上げる。こういうパズル的なコーディングは久しぶりなので楽しい。

　早速テストだ。いきなりPWMにつなぐのではなく、コンソール出力で2つの数字が間違いなくとりこめているかを確認する。2組の数字のときはやさしいが、一つだけの数字のときは、かえって面倒である。

　ふーむ、どうしても、後の組の数字が10倍になってしまう。何度もロジックを見直すが間違っていない。こうなったら、変数を片っ端から出力させてみる。いわゆるprintfデバッグである。

　文字数を出してみて原因がすぐわかった。標準入力は、文字列の最後に必ず'￥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のウェブ画面で映像を確認する。よーし画面がでた。パンチルトのコンソールに戻って、コマンドを投入する。カメラは、ビビッという音と共に所定の方向に向いた。画像は一瞬見えなくなるが、納まると画像が見えて、別のシーンが映った。ははは、出来た、出来たぞ。大きく動かしたときはカメラを固定した蒲鉾の板を手で持っていないと、ひっくり返る。

　しかし、こんな手元でも、自分の手以外で画像が変わるのを見るのは感動である。片側数値だけ（パンチルトどちらか）の操作は、カメラが余り揺れないので画像の乱れは少なくて済む。コマンドの投入で目指した目標にカメラの画面が移動できるか遊ぶ（これは意外と難しい）。

　いずれにしても、これで当研究所での2台目のパンチルト操作の出来るウェブカメラが実現した。これの具体的な用途はまだない。猫カメラはアクリルケースに入れないとこいつも攻撃される。でも、まあとにかく一段落である。

　残っていることは、カメラのパンチルト操作を画面の左右上下のバーでやれるようにすることだが、これは所長の不得意なウェブプログラミングになるのですぐには手が出ない。このあたりはアプリケーションによっても大きく仕様が変わるところなので簡単には先に進めない、とやりたくない理由を上げて自己を正当化する。

次の野望は超音波測定ユニットのI2C化(7/28/2015)
　実は前から企画しているプロジェクトがある。EdisonのI2Cシフターを買って来たころ思いついた企画だ。手元の部品箱には、超音波を使った距離測定ユニット(HC SR04)が使用されないまま、ころがっている。一年ほど前にはやったことがあって当研究所も買ってあった。

　昔から秋月あたりで売っている、Parallax社のものと形態がそっくりで、価格がべらぼうに安い。確か通常の電子部品店ではなく、アマゾンなどから売り出され、最近は秋月やスイッチサイエンスなどの電子部品ショップでも売り出した。

　どうも中華コピー品らしいが、動作報告がウェブに出るようになり、それほど評判も悪くなさそうだ。なにしろ、オリジナルは￥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が入っており手間が省ける。割り込みも使わない、タイマーひとつだけで、やってきたパルスの時間を測るだけである。大した時間もかからずにプログラムが出来た。早速テストに入る。

　結果としては、不具合は全くなく、問題なしに2cmから3.5m近くまで計測が出来た。確かに、3.5mあたりを超えると、Echoパルスが戻らずラインが1になったままになるが、リセットしなければ元に戻らないわけではない。再度トリガーパルスをかければ復帰する。特に問題もない。

　とりたてて大げさに言うような不具合ではなさそうだ。スイッチサイエンスの使っているArduinoのプログラムなどでうまく動いていない可能性が疑われる。タイムアウトを設け、ある程度の時間、パルスが戻らなければ待つのをやめれば済む話である（当プログラムでもそうした）。

　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を伝えるステージのタイミングが難しい。実際に動くことを祈って、せっせとコーディング。ほどなく出来上がった。

スレーブは、はなからロジアナの力を借りる。(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の外部割込みの出方が考えた通りのところで全く起きていないのだ。

　やっぱり懸念した通り、オーバーヘッドが大きくて、割り込みがまともに動いていない。いくつかの割り込みは無視されている。特に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だけの割り込みルーチンだけで動かすことにした。

　こうすると、ストップコンディションは受けることが出来ない。ただ、これはスレーブにとってはそう致命的な状況にはならない。SR04のデータ送出位なら、一連のシーケンスが終わったあと、タイムアウトをとって送信終了とすれば済む話で、受信ならマスターからNACKが来る。

タイムアウト機能を入れてやっと送受信ができた（8/21/2015）
　I2Cインターフェースのデータビットの最後のACK/NACKを返す方法が難しかったが、何とか、1バイトのマスターからスレーブへの送信（これはコマンド用）と、2バイトのスレーブからマスターへのデータ転送が動くようになった。

　どちらもまだタイムアウトを頼りにする送受信（一秒タイムアウト）なので実用には乏しい。それでも目指すSR04のI2C化にだいぶ近づいた。ブログを整理してみると、もう6ページ以上の量になった。このあたりで記事にしておこう。 　
（ソースコード等は、もう少しまともなものになるまでお待ちください） 

mraaライブラリーでEdisonのGPIOは動いたが時間が不定(6/20/2015)
　Edisonプロジェクトの進展は相変わらず遅々としている。理由は簡単で、Edisonで具体的に何を作るかが決まっていないからである。しかし迷っていても先には進まない。無理やり目標を決めて進むことにする。結局、EdisonもRaspberryPiと同じ、パンチルトの出来るウェブカメラに仕立てることにした。まあ監視カメラはいくつあってもかまわない。何かの役に立つだろう。

　前回にご紹介したサーボモーター2つでカメラをパンチルト出来る操作キットをEdisonのPWMで動かすことにする。ウェブカメラそのものは、既にEdisonで無線LAN経由で動いているが、サーボモーターの方はAVRで動かしただけで、Edisonではまだである。

　このあいだのEdisonマザー基板には、秋月で調達した1.8～5Vのレベルシフター（FXMA108）が仮止めしてあるが、配線はしていない。Edisonのピン出力は1.8Vなので、PWMで市販サーボを動かすためには、このシフターが必要である。

　久しぶりのハンダ付けである。とりあえず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の点き方が安定しない。オシロで見るとパルス状になっている。

　このシフターの電源供給力はスペックによれば、ピン単位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の配線をしていなかったのは幸運というか先見の明があったというか。

　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ピンを調べて行った。驚くべきことに、作動するピンと動かないピンがあることがわかった。

　動かない状態は、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アドレスの固定化）をこちらにも与えてテストする。カメラを動かしてみる。問題なく動く。ただ、こちらの方が少し熱を持つようだ。

　温度計で測ってみると、50℃を軽く超える。不安になったのでヒートシンクをつけてみた。　温度上昇は少し鈍化したが、60度近くになる。1時間程動かしたところでハングアップした。うーむ、ヒートシンクだけでは長時間には耐えられない。冷却ファンが必要かも。

　しかし、こんなに熱かったかなあ。前はもっと低いところで安定していた。1号機には何か別の問題がある可能性が高い。GPIO(37)で4hzの発振信号が続いているなど、I/Oピンに不審な動きが多すぎる。

1号機でシリアルを失ったのは、やはりショートか(7/10/2015)
　ヘッダーピンの実装のため、Edisonの2号機をブレークアウト基板から外した時のことである。2号機の裏面が絶縁ラベルで覆われている。おやあ、 1号機は違っていたような気がする。確かめてみる。

　やはり、そうだ。1号機の裏面は表と同じようにアルミ生地のままプリントされている。ふーむ、何故変わったのだろう。閃きが走った。以前、この裏面とブレークアウト基板のピンヘッダーの配線部が接触していて、あわててはみ出たピンをニッパーで切り取ったことを思い出した。

　そうか、当研究所で起きた事故が他でもあったのだ。それで、ここの表面が絶縁されるようになったのだ。シリアルが動かなくなったのは、このショートに違いない。

やっとEdisonでPWMが動いた。nodeのLチカも正確になった(7/14/2015)
　道草を食っていたが、やっと2号機でPWMを実験する気運が盛り上がってきた。実はmraaのPWMの操作は実に簡単で、ピンを初期化した後、周期(usか秒)とduty比を整数と浮動小数で設定するだけである。

　サンプルコードはここを参考にさせてもらう。サーボモーターは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号機の別の原因によるものだった。今のところ、ハードかソフトかはわからない。動画ストリーミングで高熱になるのも何かこれと関係あるような気もする。

　前回の記事から一か月以上が経ってしまった。これまでで最長の空白だ。Edisonの電池駆動カメラのプロジェクトは、IPアドレスを可変にするサーバープログラミングに熱中し、これが実現したとたん、やる気を失った。こういうことは良くあることなのだが、今度はさらに別のことが重なった。

　というのは、こんなに苦労して可変アドレスを手に入れなくても、WiFiでEdisonのホストIPアドレスを簡単に固定にすることが出来るということをウェブで知り（考えてみたら出来て当然なのだけど）、がっくり落ち込んだ。まあ、nodeの勉強には役だったと自分を慰めるが、実用的には徒労に近い。

　当研究所のモットーは、何度も書いているように「実用性」である。こういう無駄な作業は一番避けたいもののひとつである。それにこれでEdisonが動いたとしても、面白そうな応用が見つからない。要するに心が躍らないのである。

　最近、タイムズ誌で世界で注目される100人の一人に選ばれた、「片づけ」の名人、近藤真理恵氏の言葉を借りれば「ときめき」がないのである。電子工作での「これを作りたい」という気持ちは理屈ではなく、この「ときめき」に近い、と言うよりそのものである。これがないとやる気が起きない。

　まあ、この一か月の空白は、電子工作以外のことに忙しかったこともある。後程いくつかご紹介するが、今はこちらのほうが「ときめき」を感じることが多い。　とはいえ、このブログは今や、電子工作だけでなく所長の生活全体の備忘録と化している。休んでいるわけにはいかない。メモにして残してきた、この一か月の行動記録をなるべく電子工作とつなぎながらご報告していくことにする。

移動カメラの実装を考える(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が裏にもシールド板が張り出していることに今さらながら気が付いた。　お、お、おー、もしかすると、これがシリアルインターフェースが動かない原因なのか。あわてて、Edison本体をはずし（抜き差し30回まで保証。もう10回は抜き差ししたか）、触っていそうなところをニッパーで切る。2か所あった。一本はGND、もう一本は、問題のシリアルのUART1の RXだった。うーむ、これか。

　祈る気持ちで電源をON。残念、状態は変化せず、シリアルは生き返らなかった。落ち着いて調べ直してみたら、ショートしていたと思われるRXは、オシロで調べた時にちゃんとプルアップされた電圧が出ており、動かないTXの方は、最初から接触した形跡がない。

　現在のEdisonブレークアウト基板は、シリアルが動かないこと以外に、最初点灯していた充電中を示すLEDが点かなくなっているという不具合を抱えている。WiFiや、USBからの給電によるUSB仮想ネットは生きているので、日常の作業には差支えないが、不安は拭えない。

　いずれにしても、今後、少しまともな用途に使うことを考えるなら、Edisonは安全のためもう1セット調達する必要があるようだ。

恐れ入ったカメラ操作キット(5/29/2015)
　先にも書いたように、Edisonでもカメラを動かそうと、このウェブサイトで紹介されたカメラのパンチルトを行うサーボキットを、以前衝動買いしてある。サイトでの紹介が辛口だったので、買ったまま封も開けず放置し、余り期待していなかったのだが、ドローンの話が消えて、パンチルトをEdisonでもやってみる気になった。

　包装を解いてパーツをとりだす。話には聞いていたが、確かにすさまじいキットだった。だいたいアセンブリーのカメラを装着するホルダー部分が、カメラのマウントと全く違うので、このままではカメラを取り付けられない。

　恐らく、設計当初に予定していたカメラが供給できなくなったけれど、サイトに改造記事をつけて販売を強行している感じだ。アセンブリーの金型を変えるのは確かに巨額の費用がかかるので同情したいところだが、それにしても、この紹介された改造方法が荒っぽい。

　カメラもアセンブリーも、ニッパーなどで取付け部分を双方とも全部切り取り、やすりとドリルで固定穴をあけてねじ止めするという乱暴なものだ。もう少しエレガントな改造法もあると思うのだが、やりかたがいかにも原始的だ。　

　しかも、サーボモーターに付属しているホーンは、どれも、このアセンブリーの取り付け穴に入らない。型に合わせて切り取れとある。サーボモーターも変わったのだろう。好い加減なものである。プラスティックなので加工は簡単だが、何か馬鹿にされている感が否めない。

　サーボ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でサーボを動かすのはテストのためだけである。このあたりはやっつけで先に進む。　

　さあ、サーボのテストだと意気込んだのだが、これが、どうやって動かしたのか丸ごと忘れている。情けないものである。しかし、こういうときに役に立つのが、このブログの記事である。いやいや、書いておいて良かった。配線図も出ているので何の苦労もなく実験が始められた。

　最初のバージョンでは、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年もたち、この駆動部は一度修理しているが(ベルト切れ)、今度は別のところがやられたらしい。

　こういう時に限って、こういうものは故障するものである。苦労してケースを開ける。最初、ケースの止めねじはいたづら防止のトルクスネジだと思っていたが、六角レンチネジだった。あわてて発注したトルクスドライバーセットが無駄になった。まあこれもいつかは役に立つだろう。

　ケースが開いた。おやあ、シャーシーの中に細かいプラスチックの破片が散乱している。うーむ、何かがこわれている。さらに基板類をはずして、機構部が見えるようにする。

基板がいくつかに分かれ、リボンケーブルで接続されているところもあるので慎重な作業が必要だ。

　やっとトレイ駆動のモーターが見えてきた。あ、あ、あー、見事、トレイの駆動モーターのピニオンギヤの丸歯が欠けている。これでは空転だけしてトレイは動かない。もう20年も経った機械だ。経年変化でプラスティックが劣化したのだろう。　一瞬、このギアだけを取り換える修理が脳裏に浮かぶ。ただ、この物理的なところをなおしたところで、実際のトレイの動きが復元するかは保証の限りではない。しかも、発表会が近づき、懸案の電子工作もある。そんな悠長なことをやっている暇はない。

　ただ、CDプレーヤーが今動かないのはまずい。冷静に状況を調べて、動かないのはトレイの駆動部だけで、他は問題ない（演奏もOK）ことを確認した。とりあえずは、トレイの前蓋に引き出すためのフックを付けて動かすことにし、プレーヤーを再度組み上げた。楽しみは残しておこう。

水洗トイレのタンクバルブをアマゾンから買って補修したこと(6/16/2015)
　そうこうするうちに、今度は2Fのトイレの水洗タンクが不調との家族の知らせを受けた。タンクに水が入るのに異常に時間がかかるようになったという。早速、タンクを開けてみると、水が止水フロートのバルブのところから水が漏れるだけで、通常の供給ホースから水が出ていない。　当研究所は、昔、水道工事にも口ばしを突っこんだことがあって、大きなプライヤーやドライバーを備えており、簡単な水工事なら十分守備範囲である。早速工具を持ち出して、ボールタンクの調節バルブを取り外した。

　このバルブ（ダイヤフラム）の仕組みが良くわからない。細い針がダイヤフラムを貫通していて
両側の圧はここで素通りになるはずで、このゴム膜でどうして水が止まるのかわからないが、このゴム膜の別のところにも穴があいているところを見つけた。

　少なくとも、ここが悪いのに違いない。幸い、１Fのトイレも全く同じ型だったので、このバルブを装填してみた。思った通り2Fと同じ現象が現れ、このバルブが不良であることが確認された。

　こんな部品は市販されているのだろうか。DIY店に行く前に、ネットで調べてみた。すると、全く同じ部品が見つかって、1個から売ってくれることがわかった（アマゾン）。いやあ、良い時代になったものだ。　数日後、無事部品が届いた。早速、つけなおしてみる。見事、水洗トイレの不具合は解消された。いやあ、気分が良い。その後、ウェブを漁っていて、このダイヤフラムの原理を詳しく解説するところを見つけて納得した。また、少し大きなDIY店でも同一品を見つけた。定番の補修部品らしい。

　このあと、電子工作で少し進展があったのだが、意外にページ数がかさんできたのでこのあたりで報告を区切ることにする。

　Edisonの無線動画サーバーソフトは、ウェブでいくつか紹介されている。そのうちnodeを使ったこのサーバーは軽くて具合が良いのだがWindowsでは動かない。ローカルネットの中のホスト名を拾い上げる機能(Avahi)をこのサーバーが使っているからである。Windowsのためには生IPアドレスをクライアント用のソースコード(index.html)にハードコーディングしてやる必要がある。

　EdisonはWiFiでネットとつながっており、IPアドレスは勝手に設定されるので、このままでは運用性が極めて悪い。iTuneのソフトをインストールすればWindowsでも動くようだが、このためだけにクライアント側をいじるというのは、どうも本末転倒で、元プロのソフト開発者としては受け入れがたい解決手段である。

　そこで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も問題なく動く。

　うまくいったのは、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のサーバーは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」をダウンロード

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コンバーターそれぞれが、完全にバラックの状態である。

電池駆動の移動カメラのケースの実装(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ピンにすべてピンヘッダーをつけて、マザー基板で固定するようにしたことだが、これが原因とは到底思えない。　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のように理論的に美しくもなく、既存の手続き言語を強引にオブジェクト指向化した言語だ。まともなクラスを作るのには結局アセンブラープログラムが必要だったり、グループで開発するならともかく、個人でプログラムを書くときに、効率の良い方法とはとても思えなかった。

　しかし、今度はそうも言ってはいられない。暫くもがいていたが、やっぱり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のケースを作ったりして遊ぶ。

会社のPCでexpressは動いた。自宅でもなんとか成功(4/21/2015)
　それが、奇妙なことで解決したのである。自宅のPCでは何かゴミが残っているらしく、どうやってもexpressがうまくインストールできない。それではというので、仕事の出先のPC(Win8.1)に、まっさらからnodeをインストールしてみた（最近の仕事は開店休業状態で時間はたっぷりある）。

　手順の中では一番まとまっているこれを選ぶしかし、3のexpressの導入で引っかかる。前と同じだ。ただ、今度はこれまでに起きていた変なC;というディレクトリが作られる現象は止まった。ふーむ、少しは前進したか。

　次に、expressではなく、express-generatorだよと教えてくれたこのサイトの手順を試してみる。やっぱり、expressはコマンドとしては動かない。しかし、だめもとで、サンプルコードを動かしてみると、正常にサーバーが立ち上がったのである！　

　え、えー、ほんとか。間違いなくexpressを入れたHTTPサーバーが動いている。コンソールに直接expressを入れてもnot foundなのにnodeスクリプトとしては動く。わけはわからないが動いたことは事実である。

　帰宅して、とるのもとりあえず地下のPCルームにこもる。もう一度、全く新しいディレクトリを作り、環境変数も入念に今までのnode関係のものがないかチェックし、Program Filesの中も隈なく調べてnode関係がないことを確かめたあと、事務所で動いた2番目の手順をインストールした。

　おやー、事務所では出てこなかったC;というディレクトリが出来ている。やっぱりどこかにゴミが残っている。既に消したはずの、Nodistとか、最初に作ったワークディレクトリのNODEというサブディレクトリが出来ている。expressは危惧した通り、サンプルコードも動かない。

　しかし、このあたりになると、expressのディレクトリー構造がわかってきている。少し閃いたので、C;に入っていたexpressのディレクトリチェーンの中味を本来あるべきところへ強引にコピーし、C;ディレクトリを消して動かしてみた。

　ピンポーン！だった。見事に自宅でも、expressが動いてサーバーが立ち上がった。いやあ手間がかかった。こんなにnodeをインストールするのが大変とは思わなかった。原因は明らかに、C;という変なディレクトリを作る操作がインストールの途中で紛れ込み、それがexpressを動かなくしていたことは間違いない。

　しかし、それがなぜ起きているのかについてはまだ解明出来ない。また、expressそのものはまだコマンドとして単独では動かない。疑問はまだまだ残るけれど、expressはその後、処理を増やしていっても問題なく動いている。まあ、一山は越しただろう。やっとこれでブログに報告できるというものだ。

初めての五竜遠見スキー場。季節外れの豪雪(3/13/2015)
　今年2回目のスキー行が近づいた1週間ほど前、仕事から帰ってきて急に気分が悪くなり食べたものを戻した。微熱がある。夜遅くからは激しい下痢に見舞われる。どうもノロウイルスにやられたらしい。医者は3～4日で良くなると言ったが、出発まであと4日、スキーを中止するかは微妙なところだ。

　2日間は食事らしいものは何もとれず。スキーに行く前日にやっと下痢が納まり、おかゆが食べられるようになった。自分の車で仲間を乗せてスキーに行く約束をしているので中止は避けたい。連れに事情を話し、恐る恐る予定通りスキーに出かけた。

　関東平野は快晴だったが、スキー場に近くなると雪が激しくなった。春も半ばというのに猛吹雪である。宿のペンション前の坂が上りきれない。先に着いたもう一台の仲間の車は180度回転したそうだ。別の道から迂回して何とか宿の駐車場にたどりついた。

　今回のスキー場は、いつも出かける八方尾根の宿が競技会の本部になってしまったので、その隣の五竜遠見スキー場である。何十年もこのあたりに来ているが初めてのスキー場だ。楽しみにしていたのだが、体力が心配だ。

　でも泊まったペンションは当たりだった。ゲレンデにも近く、食事も上品で、ロビーに恐ろしく贅沢なオーディオ装置があるのに驚いた。バブルの儲かったときに先代が揃えたのだという。JBL4344などのスタジオモニター2組と、タンノイのArden（アーデン）が聞き比べられるようになっている。アンプはマッキントッシュ（管ではなく石）。クラシックはやはりタンノイが良い。

　体の方は、順調に回復した。当初食べられる量はみんなの1/4だったが、帰るころには普通に戻り、スキーをやるのには十分だった。ただ季節外れの大雪でゲレンデには、1m近い新雪が積もった。 　腕試しに、圧雪していないバーンに飛び込んでみたら、雪が重く、スキーを浮かすことも出来ず、斜滑降のまま前のめりに転倒した。これが簡単に起き上がれない。深雪スキーなどと洒落れているような状態ではない。ほうほうのていで退散した。

　今回はノロウイルスのせいに出来るが、基礎体力は間違いなく低下している。残念だけれど仕方がない。体力相応（年相応）のスキーをやるしかない。まあ、スキーそのものは誰もけがもなく無事に東京に戻ってきた。

いんちきな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アダプターであっても、それに見合う電力が出るわけではない。定格容量内であっても電流を流していくと出力電圧が落ちて電力が下がる。

　今のところエネループ、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Ω抵抗から一瞬小さな煙が出て、抵抗を焼いてしまった。

　ブレッドボードの配線をいじっているうちにVccをどこかでショートさせてしまったらしい。この抵抗を焼いたのは、これで2回目である。ひとつ5円もしないパーツだが、焼けて使えなくなってしまう（ひとつは断線、ひとつはキロオーム台に）こと自体が気分的に滅入る。これですっかり意欲を失ってしまった（へたれである）。

　UVCカメラ付きのEdisonを機嫌よく動かすには、7.5V入力なら、400mA以上を安定的に供給できないといけない（前記事の計測データから）。あともう少しなのだが、アナログは基礎がないので、何をするにもすべて手さぐりで方向を定められない。

　それにNJM2360は相当設計の古いICで、どこかのサイトでは化石とまで言われている。インダクターや、パワーTR、FETなど沢山部品を揃えてしまったが、ここからの撤退はそろそろ潮時のようだ。

ストロベリーのテスト前に、Intelブレークアウト基板の電源を調べる(3/25/2015)
　実は、スキーに行く前、前記事でとりあげたストロベリーリナックスのDC-DCコンバーター基板を注文してあった（これを2つ、これを１つ）。これらの基板は超小型で、いずれも3～5V入力から、20V近くまで昇圧し、電流も800mA以上出せるという触れ込みで、値段もそう高くない。

　スキーに行く直前に届き、簡単なテストをしたところ、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につないでカメラのストリーミングが動いた。ただし数分しか動かしていないので、安定して動くかどうかはわからない。長時間テストに入る。

　最初、スルーホールに接続できるジャンパーと電流値を測るためのシャント抵抗を入れたミニブレッドボード上の配線で試してみたが、どこかで接触不良が起きるらしく、立ち上がるもののカメラをつないだり、基板を動かしたりするとリセットした。

　そこで、コンバーター基板にピンをハンダ付けし、ミニブレッドボードにしっかり差して動かすと安定した。一時間経っても、全く問題なくウェブカメラは動作した。よーし、電源のハードはこれで決まりだ。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コンバーター基板では動かなくなる危険もあるが、現在のままでは、とりあえず問題はない。

　やれやれ、やっとのことでハードの問題はクリアしたようだ。次はこれをどういうパッケージに実装するかであるが大きな峠は越した。次の課題は、ストリーミングソフトの決定である。

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というコマンド（？）がストリームをデコードしているようだ。

　しかし、ウェブを幾ら漁っても、これがWindowsでは動かないという文言が見当たらないのである。うーむ、ウェブの断片的な情報では、全体をつかむのが難しい。ちょうど良い機会なので仕事の帰り、久しぶりに秋葉原の書泉に寄って、こんな本を買ってみた。

　書泉はさすがに専門書が揃っている。node.jsの本だけでも10冊近くあった。ただ、何が適当な参考書なのかはわからない。迷った末、定番のオライリー本にする。脱線につぐ脱線だがまあ許してもらおう。このあたりでブログに報告することにする。もう20日も経ってしまっている。

せっかくの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というモジュールが見つからないというメッセージである。これだけでは全くわからない。

　わけもわからず、ソフトをインストールしまくってきたので、原因の追究はほとんど不可能である。これらの映像配信ソフトは、新しいカーネルが前提なので、今のものと不整合になっていることは十分あり得る。インストールの途中で、こうした設定ファイルを壊したのかもしれない。

　というので、中止していたカーネルのビルドを最後までやってみることにした。これがまた長い。 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からは何も見えない。

　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を最新のものにしたからかもしれない。コンパイルも順調に終わった。動かしてみた。

　やったー、こちらは案外あっさり絵が出た。一度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ドキュメントを送っているようだが、具体的なデータの授受の手法は全く理解できない。

　実際に動かしてみると、エラーもなく動いているようで、クライアント側も反応があるのだが、画面の枠だけが表示されて、画像は出ない状況である。とにかく何を調べれば良いのか全く見当はつかない。

　ところが、PCでLinuxを立ち上げて、ウェブブラウザー（FireFox）を動かしていた時のことである。試しにURLを入れてみたら、突然、画像が表示されたのである。何だ、何だ、動いているではないか。画素数が320X240で荒いけれど間違いなくUVCカメラの画像である。

　パラメーターを640X480に換えて再始動してみる。ちゃんと高解像度で立ち上がった。何ということだ。Linuxでは動いていたのだ。慌てて、OSをWindow7側に切り替えてみる。やっぱりWindowsでは動かない。FireFox、IE、Crome、どのブラウザーもことごとく画面枠だけで表示されない。

　しかも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を取り出して、早速測ってみた。なんとなんと、これがあたりであったのである。

　驚くことにパワートランジスターのピンの順番は、2SC1815などの小さなTO-92パッケージのものとは逆だったのだ。小さい方は、ラベルを見ながら左からECBなのだが、2SC3694のような　TO-220タイプのピンは、ラベルを前にして左からBCEなのだ。

　データシートにはちゃんとそう書いてある。しかし思い込みとは恐ろしいものである。ふんふん、左からECBねと、ろくに確認もせず配線していた。パワートランジスターだから逆差ししても何にも起こらなかったけれど、いやいやお恥ずかしい。

NiMH電池でも、DC-DCコンバーターでは動かず(3/10/2015)
　トランジスター外付けのNJM2360はピンアサインを正しくして何事もなく動作した。負荷抵抗をつけて出力電流を測定する。インダクターをトロイダルの大型(9A)を入れたりすると、さすがに単独より大きな電流(350mAぐらいまで)を大した電圧降下もなく(7.5V設定で、7.02V)取り出せる。

　ブレッドボードなので少し不安があるが、こんなものだろう。まずリチウムバッテリーの電源でやってみる。いや、これは単独の時と同じで、Edisonの立ち上がりまでが精いっぱいで、USBカメラを付けた時点でハングする。トランジスターの外付けの効果はない。

　さてそれでは、用意したエネループ電池（NiMH）ではどうだろう。4ケ用意したので1.4X4=5.6Vまで上がるし容量も心配ないはずだ。動かしてみる。Edisonの立ち上がりは勿論OK。USBカメラも問題ない。さあ、最後のストリームサーバーの始動だ。

　残念、ストリームサーバーを動かした時点でシステムが不安定になり、ネットが落ちた。うーむ、難しいものだ。当面の方策はすべて失敗である。どうもお店を広げすぎたようだ。このへんで、戦線を整理し、ブログに報告することとしよう。

　最近の超小型CPUボードの進歩の早さは眩暈（めまい）がするほどだ。ブームに先鞭をつけたBeagle Boardが出たころは、1万円の前半（それでも超安値）だったが、ここへきて高性能、低廉化が止まらない。最近のRaspberryPi2（以降RasPi2）に至っては、これまでと値段は全く変わらないのにCPUがいきなり4つになって性能は6倍だという。

　RasPi2は秋月電子などの大所（おおどころ）の電子部品店でも販売が始まり、何度も発売直後に売り切れたりして、ちょっとしたブームである。BeagleBoardのとき、「これはもうPCだから、電子工作としてはやらない」と宣言した当研究所としても、先代のRaspPiのときは、余りの安さにたまらず2台も買ってしまった。このRasPi2の出現を心穏やかに見守れる状況ではない。

　これくらいの速さになると、ちょっと前のノートPCクラスのパソコンの性能である。これが手のひらサイズになってしまったのだから、アプリケーションの可能性は想像を超えて限界が見えない。アマチュアだけでなく業界そのものも何となく浮き足立ってしまっているような感じがする。

　しかし、アマチュアにとっては、今回の飛躍的な性能向上は実はアプリケーション的には、かえって使いにくいマシンになっている。これだけ性能が向上しても、用途が簡単に見当たらないからだ。それに、この高性能を生かせるアプリはどうしても大がかりになり、自作は容易なことではない。

　当研究所に導入された2台のRaspiは、幸い就職先が見つかり（一台は、我が家の現役ファイルサーバー、もう一台は予備役だけれどWebカメラ）、無駄にならずにすんでいるが、最初に買った初代のBeagleBoardと、BeagleBoneBlackは、用途が決まらないまま、多くの雑誌付録基板と同様、部品箱の不良在庫（積み基板ともいう）になっている。

　こんなわけで、迷った挙句、タイトルのようにRasPi2ではなく別のCPUボード（ボードというよりカード）を買ってしまったのだが、その経緯はあとで詳しく説明するとして、まずは、ここ2週間の電子工作の作業記録から報告する。

表面実装のDC-DCコンバーター基板完成(2/9/2015)
　LEDペンライト2号機を作っていた時にご紹介した、DC-DCコンバーターチップのMNH7601である。効率が良いというのでAitendoから買ってきてブレッドボードに組み、動作を確認したのだが、ブレークアウト基板にしようとして、チップの変換基板が大きなスペースを占めるのが気になった。

　せっかく、SOT23-5という3ミリ四方の小さなチップなのに、変換基板はmilピッチで4×3ピンの大きさで無駄に大きい。心電計プロジェクトが片付いて手が空いたので、これまで考えていた小さく実装する方法を試してみることにした。

　その方法とは、以前、用もなく買ってあった秋月の表面実装(SMD)汎用基板を利用して作ることである。買ったとき店頭で店員に聞いたところでは、この表面実装のパッドのピッチは1ミリピッチで、mil規格のものとは合わないということだった。

　しかし、SOT23のピンピッチは、0.95ミリとインチ規格ではなく、この1ミリピッチにぴったり合う。実際にチップをこの基板に載せてみると、横3ピンくらいなら0.05ミリのずれは全く問題にならないで綺麗に配置された。

　早速、秋月でこのために買ってきた47μFのチップセラコンと、表面実装のインダクターを載せてレイアウトをしてみる。うーむ、変換基板のときより高さは間違いなく低くなるが、面積はそう減らないな。

　簡単に見えたが、ハンダ付けは結構難儀した。難しいのは短い配線である。試行錯誤でやっとコツがつかめた。それはUEW線を短かく切ってしまわないで、長いままハンダ付けして行って、そのあとで切る。短くなったときは必ず、ピンセットなどで固定し浮かさない。さもないと一旦ハンダが溶けたら短い線は必ずハンダごての方に持って行かれ作業は振出しに戻る。

　たいした配線量ではないので、ほどなく完成した。チップの横の使わないパッドはミニルーターで削り取ったが、特にその必要はない。ハンダブリッジはすぐわかる。気分的なものである。このあいだのLAN基板のこともあり、少し強めに部品を動かして固定を確認する。よし、大丈夫だ。

　通電した。白色LEDが眩しく点灯する。いやあ、こんなものでも動くと嬉しい。インダクターが大きすぎたため、専有面積だけでみると、以前作った写真のHT7750基板に負けている。まあ、自己満足の世界である。

焦電型人感センサーのトラブルシューティング(2/11/2015)
　次の工作は、前々から気になっていた階段照明の自動点灯装置の修理である。Tiny13で焦電型の赤外線人感センサーを制御し、人が近づくとスタンドに明かりがつき、何秒後かに自動で切れる。意外にも家族で人気になり、すっかり実用品として活躍している。

　ただ、こいつ高感度なのは良いが、冬にエアコンの暖房をつけると、つけた直後の微妙な温度上昇で誤動作が頻発する。以前、入力ピンの基準電圧を上げたり色々やったが、改善できなかった。

　誤動作と言っても、照明が少々無駄に点くだけでそれほどの実害はない。まあ人感センサーそのものも、それほど正確性があるわけでもないので（良く駐車場などで突然点いたりしている）、放置していたのだが、手が空いたので少し本格的に修理することにした。

　方策は考えてある。微妙な温度差で動くのは、オペアンプの増幅度が高すぎるのではないかと言う仮説である（現在2段で1350倍）。このためアンプの1段目に半固定の抵抗器を入れて増幅度を下げてみる。ところが回路図が見当たらない。こういうときのブログである。PCを立ち上げて記事一覧を検索する。すぐに回路図は見つかった。

　画面が階段の上部で見られるようにオシロを機器のそばに移動し、反応をチェックする。ここで反応する限界まで増幅度を下げれば、誤動作が一番少なるはずだ。その結果、400倍くらいまで下げても十分反応し、誤動作は明らかに少なくなった。

　しかし回数は少なくなったとはいえ、ゼロにはならない。今度は固定抵抗を交換してさらに200倍まで落とした。反応は余り変わらない。いつものように距離3メートルくらいの階段上部でも確実に反応する。さらに誤動作は少なくなったが完全にはなくせない。

　温度変化による変動は、オシロで見ていると、温度が上がり始めると、5秒周期くらいの緩い上下動が少しづつ始まり、何回かののちついには閾値にまで下がって、その後、元にもどり、暫くするとまた始まるという周期を繰り返している。

　そもそも人を感じるということは、こういう微妙な熱変化を連鎖反応的に増幅して動作に結びつけているわけで、これを否定するわけにはいかない。しばらくこれで様子を見てみよう。

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の考え方は割り切っていて、最初からビデオインターフェースが省略され、とてもすっきりしている。

　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までが立ち上がらなくなる危険がある）。

　暫くぶりの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のサポートだけで動くはずである。

　ええーこれはどうしたことか。これらのサイトの記事が書かれたころは、カーネルはサポートしていなかったのが、最近になって入ったというのか。そう言えば、最初のスイッチサイエンスのインストール手順で、最新のファームをダウンロードして更新した。

　確かに、RasPiなどに較べれば情報は山ほどあっても、Linux周辺の基礎知識がないとまともに動かすまでのハードルが高い。EdisonのOS(Yocto Linux)は発表当初のバージョンが古くバグがらみだったということで評判を落としたと聞いている。このあたりがいまいちEdisonが盛り上がらない要因のひとつかもしれない。

　さらにウェブを検索する。キーワードを換えて行くと、続々Edisonがらみのページが見つかる。おお、usbのサポート状況を調べるコマンドがあった（lsusb）。ここのサイトを参考に、EdisonのOTGコネクターに、手持ちのUSBディバイスをつないでテストしてみる。ふむ、大丈夫だ。USBメモリーなどが問題なく認識され動く。さあ、それならUVCカメラはどうだ。

　どきどきしながら、UVCカメラをRaspiのWebカメラの雲台からはずし、Edisonに接続する。lsusbを入れてみる。な、なんと、なんと、全く問題なく、出力メッセージにUSBカメラの型番、LogitechのC270が表示された。/dev/video0もしっかり作られている。

　まだ動かせないけれど、ここまで認識すればもう大丈夫だ。何ということだ。あれだけ苦労したカーネル再構築は不要となった。まあ、貴重な経験をしたと考えることにしよう。それにいずれはやらねばならない作業だ。