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」をダウンロード


| | コメント (0) | トラックバック (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)

2015年2月 6日 (金)

心電計は少しおやすみ。以前作った装置の修理にはまる

 ちょうど一カ月ぶりのブログの更新である。こんなに間が空いたのは、心電計プロジェクトが一段落したあと一気に気が抜け、ブログに報告するような工作の話題が少なかったこともあるが、それより些末なことにこだわる所長の粘着気質も影響している。特にこの2週間はこれまで作った装置の修理にどっぷりはまって、抜け出せなくなっていた。

 電子工作を始めて間もないころ作ったLANによるプリンターの遠隔電源制御コントローラーが、また故障したのである。家族が独立してこの装置の必要性は薄れていたのだが、当初これが原因と考えていた見込みが次々にはずれてしまい、最後は完全に意地になっていた。 A4111243

 で、何とか原因究明に成功して、こうしてブログの記事を書いているのだが、その原因と言うのが、これまでの常識を超える不具合で、今のところ動いているものの、怖くてまだ完全な検証には至っていない。その顛末も含めて、この一か月の研究所活動をご紹介する。

息抜きにLEDペンライト2号機制作(1/12/2015)
 心電計はTFT液晶に想定通りの画面が出て一息ついた。スケールを振幅や時間幅に合わせて可変にしたりするソフト開発や、脈拍数を大きなフォントで表示する機能など、まだまだ実用までにやりたい工作が残っているのだが、とりあえずは少しお休みすることにしよう。

 心電計の作業の合い間に少しづつ部品を揃えていたやりかけの工作がある。乾電池ひとつで動くLEDペンライトの2号機である。この手のライトは100円ショップなどで山のように売られているが、DC-DCコンバーターの応用例として作った自作1号機が思いのほか使い勝手が良く(小さくもなく大きくもない。へたりかけの電池でOKなど)、意外に重宝している。

 それで、ずいぶん前に2号機を作ろうと思い、以前にも紹介したAitendoのPT1301というDC-DCコンバーターICを入手してブレークアウト基板に作りこんだ。LEDランプや、ケース、スイッチなどの部品も揃えた。1号機は2Fの洗面所、2号機は工作室に常備する予定だ。 P1136849

 スイッチの固定など全体の工作は済んでいない。こういう円筒の中にものを詰める「しかけ」は、何故か工作心(ごころ)を刺激する。固定の仕方に沢山の方法があり、「最も工数が少なく」「確実に固定され」「着脱が容易」な構造を考えるのは楽しいものである。

 スイッチは、だいぶ前から一号機の「モーメンタリー」(押すときだけON)ではなく、「オルタネート」(押してONさらに押してOFF)に動く小さなものを探していたが、期せずして、秋月とAitendoで、オルタネートの小さなタクトスイッチが最近発売された。恐らく、同じ製品だと思うが2号機にはこれを使うことにする。 P2066893

 それとAitendoでは、前から気になっていたDC-DCコンバーターICが売られていることを発見した。今度のペンライトにも使えるし、これまで何度か昇天させてしまった9Vレベル(乾電池の006Pの代替)のコンバーターにも使えれば嬉しい。

別のDC-DCコンバーターIC、EMH7601をAitendoから入手した(1/14/2015)
 このDC-DCコンバーターは、ふとしたことで、このサイトで絶賛されているのを見つけた。効率が良くて、回路も簡単だという(ショットキーダイオードが不要)。作ろうとしているペンライトには既にDC-DCコンバーター基板が用意されているが、これも急に欲しくなった。面白いものでこの物欲というのは全く理屈抜きに突然湧いてくるというのが不思議なところである。

 0.7Vからでも動くというので、LEDペンライトにも使える。久しぶりに、末広町のAitendoの直営店舗に足を延ばした。車をコインパークに入れ、少し歩いて店のあるビルに向かう。このあたりは秋葉原の商店街と全く雰囲気の違う中小オフィスビル街だ。平日にもかかわらず周囲は閑散としている。

 お店は3階にある。人気(ひとけ)の少ないビルで入口から店に入るまで誰にも会わなかった。店内は開店当初より品物が充実している。ただ、ICなどはランダムにあちこちの棚にブロックで並べられているので探し出すのが一苦労だ。

 ここにきた目的は、このICとオルタネートスイッチ以外に、去年の暮れジャンクで買ったシャープの7インチディスプレイ(¥7000が、千円以下になっていて衝動買い)のフレキケーブルと接続基板を手に入れるためでもある。P2066881

 膨大な変換基板の棚から、幸いコネクター付きの40ピンの基板が見つかりこれを買うことにする。少し高い(¥780)が、0.5ミリピッチのハンダ付けをしないですむ。これで7インチディスプレイの工作はいつでもとりかかれる体制ができた(何を作るか決めていないけど)。

 いそいそと帰って、早速、PCを立ち上げ、データシートを調べる。EMH7601は、最大出力電圧が5.5V止まりということをデータシートで見つけて少しがっかりする。ただ、500mAまでとれて効率が高いというのは魅力だ。 P2066877

 ブレッドボードに、変換基板に載せたEMH7601をつけて早速テストする。おお、へたった乾電池ひとつで、煌々と白色LEDが点灯した。ただ、この変換基板どうも大きすぎる。せっかくのSOT23の小さなチップが台無しだ。このあいだの秋月の表面実装部品用のべた基板に小さく実装したくなった。いや、脱線はやめておこう(と言いながら、秋月でSMDの47μFコンデンサーを入手)。

ペンライト2号機完成(1/17/2015)
 
EMH7601は有力なDC-DCコンバーターではあるが、これでペンライトを作ってしまうと、せっかく作った前のPT1301基板が無駄になってしまうのは痛い。どちらを採用するか迷って、このEMH7601とこれまでのPT1301との簡単な性能比較をしてみた。

 その結果、乾電池1個の領域では、全く変わりがないことがわかった。どちらも1.2Vから、2.8V近辺まで出力する。一号機は、AS1322を使ったストロベリーリナックスのブレークアウト基板(¥950)を使っている。これとも比較してみる。P2066897

 一号機のLEDランプは、2号機にする予定のランプとどうも型番が違うらしく色温度が明らかに違う。明るさでいうのなら一号機の方が明るいようにみえるが、正確な測定器がないのでわからない。マルチメーターで測ったところでは、出力電圧は上記2つと殆ど変らなかった。負荷のLEDランプの種類が違うので何とも言えないところだ。

 結局、これまでのPT1301の基板を生かすことにして、ペンライトの組み立てに集中する。ランプのハウジングと、アクリルボディは変わっていないので、外観は1号機と2号機で全く同じになってしまい、思わず笑ってしまった。ちょっと見ただけでは見分けがつかない。P1246869

 スイッチだけが、2号機がオルタネートスイッチになっている。このスイッチの固定が一番厄介だった。スイッチの可動部が円筒にあけた穴と干渉してスムーズに入り切りができない。といって、スイッチを完全に固定してしまうと脱着ができなくなる。

 最初、秋月で売っていた、円形のユニバーサル基板[AE-20mm-TH] を使ってスイッチを固定しようとしたが、円柱にストッパーを接着剤でつけて固定する方法が、どうもうまく行かず、結局、一号機と同じような基板片を十字に組んで摩擦で止める方式に落ち着いた。 P1246872

 こんなささやかな工作でもやりだすと止まらない。あんまり凝るのも何なので、適当なところで切り上げて、とりあえず完成とする。裏はまだテープで止めただけだ。部品が固定できれば配線は一瞬で終わる。出来上がったペンライトを並べて記念撮影。オルタネートスイッチはやはりとても便利だ。つけたままにしてライトを任意の場所に固定できるアングラーのようなものが欲しくなった。

LANのプリンター電源遠隔コントローラーの修理(1/21/2015)
 この遠隔AC電源制御装置は、電子工作を始めて間もないころ、ドイツの制作記事を参考に、マイクロチップのNICドライバーENC28J60を使って作ったものである。途中、ACアダプターが壊れて交換したが、この8年間全く問題なく動いていた。

 娘が結婚し、離れた所からプリンターの電源を制御する機会がなくなって気が付かなかったのだが、あるとき、動かそうとしたら、ネット上で認識できなくなっていた。PINGも応答しない。手動のスイッチは動くので、マイコン(Mega168)が動いていることは間違いない。モジュラージャックのリンクLEDが点灯していないので、ENC28J60あたりに問題がありそうだ。

 使用機会がなくなっているので、急いで修理する必要は全くない。暫く放置していたのだが、心電計プロジェクトも一段落したので、重い腰を上げて修理することにした。

 まず、定石通り各部の電圧を測る。問題ない。修理用のUARTをつないで動きを確認する。ふむ、ENC28J60は初期化が済んだというメッセージを出して立ち上がった。NICチップは正常のようだ。しかし、モジュラージャックのLEDはどちらも点灯しない。

 当然、PINGをかけても応答しない。ケーブルを抜き差ししていると、おっと、LEDが一瞬点いた。何、LANケーブルの接触不良か。いや、そうでもなさそうだ。ケーブルを換えても、ソケットをグリグリしても変化はない。時々、つながるが、暫くすると切れてしまう。 P1246862

 こういうときの故障部品の定番は、まずIC、次に電解コンデンサー、コネクターと決まっている。念のため予備のENC28J60チップと差し替えてみる。レディメッセージが出たと言っても信用はできない。

  症状は全く変わらない。ENC28J60とモジュラージャックを実装したサブ基板を、手で少しづつ動かしていると突然LEDが点き、PINGも通るが、切れるとネットも切れる。しかし、Mega168の応答は正常でハングもしていない。

 ENC28J60でもなさそうだ。電解コンデンサーはこの回路にはないので、残るはモジュラージャックである。8年も使ったのだ。壊れても不思議ではない。しかし、この換装は簡単ではない。まず手持ち在庫に、このパルストランス付きのモジュラージャックがない。買ってくるしかない。

やった!モジュラージャックだったと意気上がったのもつかの間(1/24/2015)
 仕事の帰り、秋葉原に出て、秋月でモジュラージャックを入手した。このブレークアウト基板がほしいのだが、まだ置いていない。パルストランス付きのモジュラーは2種類になっていて値段が違う(¥300と¥200)。

 スペックもフットプリントも全く同じで、今まで使っていたのが高い方のようだ。面倒なので2種類とも買って帰る。換装は実はとても厄介だ。モジュラージャックとENC28J60チップをサブ基板に載せ、サブ基板とメイン基板の間をピンのハンダ付けで固定しているので、このピンのハンダ付けからはずさなければならない。

 文句を言ってみても自分に返ってくるだけなので、黙々とハンダ吸い取り線でハンダをとり、メモに間違えないように、ハンダ付けの位置を書き留めて、少しづつ外していく。 モジュラージャックのハンダ付けも注意深く外す。

 このあたりも前の配線図だけでなく現実の配線をメモに残しておかないと危ない。以前の配線図は制作の極く当初のものであり、そのあと変更されていることがあるからだ(変更したことなど憶えていない)。

 やっとのことで換装が終わった。電源を入れる。やった!モジュラーのリンクLEDが点き、ネットの交信が始まってアクセスLEDが点滅する。モジュラージャックが不調の原因だったのだ。いやあ、苦労が多かった分、感動はひとしおである。久しぶりのカンがあたって意気軒昂、痛快この上ない。

 さあ、元へ戻そうと、基板をケースに戻し、ねじ止めの前に念のため電源を入れると、なんと!動かなくなっている。何い、モジュラージャックが原因ではなかったのか。新しいモジュラージャックでも同様な現象で止まってしまった。

 何という事だ。故障の原因が物理的な接触不良であることは間違いない。しかしモジュラーでないことは現象が再現することから明らかだ。動かない状況には2つあって、LEDが全くつかないときと、LEDがついてもネット上でつながらないときとがある。

 実はケースに戻す前に、モジュラーのLEDの緑と黄色が逆だったので、この交換をするため、サブ基板の配線を少しはずし配線の付け直しをしている。こうなるともう原因が特定できなくなってきた。実体顕微鏡で詳しく配線のハンダ付けを調べていくが、あやしいところは見つからない。こうなってくると意地になるのが所長の悪い癖である。P1246863

 サブ基板の配線面は、メイン基板に固定すると見えなくなるので、メイン基板との間の10本のピンをローハイトのピンソケットで着脱できるような作業にとりかかる。こうすればサブ基板を裏返しにして動作を調べられる。

ソケットに取り換えるも現象が特定できない(1/26/2015)
 メイン基板とサブ基板の間を離してテストが出来るようになった。それまではハンダ付けで両者をつないでテストしていたので、時々、配線間違いを起こして大騒ぎになるのだが、これで避けられる。

 ピンソケットの間にジャンパーを介して、メイン基板とサブ基板を物理的に離せたので、爪楊枝などで配線面をたどり、ハンダ付け不良や部品不良を調べるが、はっきりした徴候は出てこない。相変わらずランダムにモジュラーのLEDは点き、勝手に消える。泥沼が続いている。

 少なくともメイン基板の接触不良ではなさそうだ。サブ基板の物理的な接触不良が原因だろうということはわかった。メイン基板をいくら押したり、歪めたりしても状況に変わりはないが、サブ基板の押さえ具合でLEDが点いたり消えたりする。1日近く点いているときもあるが、ちょっと触っただけで切れたりする。

 ICでもない、ソケット(モジュラージャック)でもない、ハンダ付けでもないとなると、あとは抵抗とか、セラミックコンデンサーとかのパーツになる。しかし各部品を点検するとなると部品をはずすしかなく簡単に調べられるものではない。

 8年近くも動いていた機械だ。どこかは壊れるだろう。しかし、こんな不毛な作業を続けているのが段々馬鹿らしくなり、サブ基板だけ作り替えようかと考え始めた。この機械をすべて廃棄するという選択肢は今のところない。こんなことで負けていられるか。

久しぶりの志賀高原は寒かった(1/29/2015)
 そうこうするうちに、スキーの日程が来た。久しぶりの志賀高原である。学生時代に一緒に滑った昔の仲間が来るというので、日を合わせて集まったのだが、何と70を過ぎた所長が最年少で、みんな70後半の先輩方ばっかりだった。それでもみなさんお達者で年を感じさせない。P1290332

 4年ぶりの志賀高原スキーは楽しかった。3日間の日程で幸い良い天気に恵まれ、たくさんのスキー場をくまなく滑るいわゆる「スキーサーカス」を楽しんだ。志賀高原は谷をいくつかはさんで変化に富んだ多くのスキー場があるので滑りがいがある。

 最終日は、志賀の最高峰、横手山まで登った(と言ってもリフトだが)。ここには日本で一番高いパン屋さんがあるので有名である(高いと言っても値段ではなく標高)。ここの山頂は、蔵王に匹敵する美しい樹氷でも知られている。P1290333

 眺望も素晴らしい。この日は雲もなく、妙高、戸隠から、白馬連峰、穂高と槍、微かに噴煙を上げる御嶽山、それに富士山まで、すべて確認できた。ただ、寒いこと寒いこと、恐らく零下15度はあったと思う。余り寒くて手が凍え写真は良く撮れなかった。

 頂上から続く渋峠のスキー場の雪質は最高で、いつも自分が上手くなった気分にさせてくれる。横手スキー場の穴場は実は、メインコースから派生して伸びた小さなゲレンデ、横手第5、6リフトだ。誰も滑る人もなく、ここからの笠岳の眺望は絶品である。S_p1290334

遂に原因を究明。リンクレベルの終端抵抗のハンダ付け不良(2/3/2015)
 
スキーから帰ってきて地下の工作室にこもる。電源コントローラーのトラブルシューティングが待っている。もうそろそろ決断の時だ。メイン基板とサブ基板に分けて、サブ基板のどこかの接触不良であることまではわかったが、それ以上の進展はない。

 隅から隅まで40倍の実体顕微鏡でハンダ付けのおかしなところをチェックするが、みな問題ない。残った調査対象CR部品をはずすくらいなら、もう一度、サブ基板を作り直す方が早い。適当な基板を決めてレイアウトを考え始める。

 それでも諦めきれず、爪楊枝で各部品を少しづつ触っているときのことだ。パルストランスに並列に入っている終端抵抗を少し強く押したときに突然リンクLEDが点灯した!何い、外見上のハンダ付けは全く問題がなく綺麗に見えているところだ。

 さらに強く押す。もう、切れない。リンクLEDはついたままだ。横でアクセスLEDが忙しくブリンクし始める。これは一体どういうことだ。以前、UEW線ではこういうことがあった。しかし、51Ωの終端抵抗のリード線は軟銅線でハンダは綺麗に盛り上がっている。

 抵抗がぐらぐらしているわけでもない。それなのに、内部で接触不良を起こしていたのである。長い間、がた老研究所を悩ましていた、コントローラーの不具合がやっとのことで解決した。いや、これまでに何回、サブ基板をはずして点検したことか。この状況はこれまでの常識を超えている。P2066882

 この部分の再ハンダ付けは、色々考えたが、とりあえずこのままにして装置を全部組み上げ直した。最終のねじを締め終わった途端、また不具合が再発すれば(これがよくあることだが)、ここのハンダ付けをもう一度やりなおそうと考えた。せっかく動いているのに下手にいじってまた動かなくなるのが怖い。

 全部を組み上げ、ケース固定の4つのネジを締めて、恐る恐る電源を入れる。おめでとうございます。装置は全く問題なく正常動作を開始した。2日経つが今も問題ない。奇妙な解決だがとにかく肩の荷は下りた。これでブログに報告できる。

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

2015年1月 8日 (木)

心電計プロジェクト:スケールが出ると心電計らしくなる

みなさま明けましておめでとうございます
 当ブログも開設以来7年が経ち、電子工作歴は何と、もう足掛け8年になりました。毎年のお正月には、これまでの総括と今後の抱負を一言載せるのが恒例になっていますが、今年はどうも適当なことが思いつきません。電子工作が、仕事をやめてからの第二の仕事のようになり、余りにも生活に溶け込んでしまったからでしょうか。

 昨年、嬉しかったことをひとつご報告しておきます。IT企業に勤めている娘の職場の友人が数名、ブログを読んで、ぜひ話を聞きたいと当研究所を見学してくれたことです。電子工作の面白さをみんなで熱く語りました。ブログのおかげで、色々な人と交流ができる。ありがたいことです。

 それはともかく、プロジェクトの続きです。心電計のプロジェクトもいよいよ大詰めに近づき、2.4インチTFT液晶に、それらしい心電波形が出てきました。昨年暮れからの作業の状況を以下にご紹介します。

keiさんありがとう。ピークが出ました(12/20/2014)

 心電波形はひとまず出たが、前記事にも書いたように、どうもピーク値(R波)が低すぎるような気がする。これは心臓疾患ではなくてセンサー部からのデータを端折っている(2回に一回しか送っていない)ため、ピーク値を逃している可能性が高い。

 UARTで10ビットのデータを2バイトに分けて送出しているが、先頭バイトを識別するため、データの送出を1回休んで間隔を空けている。これをもう少し縮めるか、このあいだコメントで頂いたように、2バイトの先頭ビットに細工をして10ビットデータを送れば、間隔を空けなくてもよさそうだ。

 実は、こうしたデータの内部構造にまで立ち入るプロトコルは、なるべくならやりたくなかった。しかし擬似コーディングしてみると、この先頭バイトに識別ビットを載せる方が、下手に時間を空けるより(1回分より少ない時間を作るのが難しい)、はるかに簡単に実装できそうなのだ。keiさんという方からコメントでご提案をいただいた方式である。

 10ビット(ADC値)データを2つに分割し(等分に分ける必要はない)、第一バイトのMSBに1を立てて(つまり128以上)、128より小さい第二バイトと区別する。ロジックそのものは至って簡単だが、AVR、ARMの両方のコードを同時に変更する必要がある。

 まず、AVRの送出側を変更し、PCのバイナリ―端末アクノリッチでデータを確認する。想定通りのデータを確認してから、ARM側を変更する。何度もロジックを確認してビルドし、祈る気持ちで接続した。 Pc246789 テストする。一発で動いた。良いぞ、コーディングミスはなかったようだ。よーし、ピークのR波が鋭くたち、世間でよく見る心電波形の形になった。良かった、良かった、自分の心臓がおかしくなったわけではない。keiさんありがとうございました。

 久しぶりにAVRをいじったので、ついでに気になっていたAVR側のデバッグをした。稀れにだが、デジタルフィルターを通さないノイズの入ったままのデータが送られる時がある。電源の抜き差しを頻繁に行ったときに多い。リセットすれば直る。サンプリングに失敗しているとみられる。

 コードを調べていくと、ADコンバーターのサンプリングを10回もやっていることがわかった。一回9μsのADCサイクルで10回というと100μs近くになる。送出間隔は、635μsなので、この程度なら大丈夫だとは思うが、試しにこれを2回に減らしてみた。

 あてずっぽうだったが、これが原因だった。何度電源を抜き差ししても一回もトラブルは起きなくなった。よーし快調だ。心電波形はこれでほぼ完全になった。

 いよいよ画面に、枠線や、数字を出すステップに来た。それと、トリガーを考えなければならない。今は連続して波形を出しているので、心拍のピークは一定のところに出ない。これを一定の位置から画面に出すようにしたい。これが出来れば本格的な心電図になるのだが、この実現はそう簡単ではない。

画像表示関数をデバッグする(12/21/2014)
 この間トラブった描画関数について、作者のねむいさんから丁寧なお詫びコメントが入った。こちらが好き勝手に使ってこけているのだから、恐縮されるとかえってこちらが戸惑ってしまう(オープンソースは無保証が大前提)。

 自分だって昔に開発したコードのバグを指摘されるのは、有り難い反面(建前)、実は何となく昔の思い出したくない古傷に触れられる感じで、そう手放しで喜べる出来事ではない(本音)。これが仕事なら本当に助かるけれど、遊びで作ったのにケチをつけられるのはたまらないと思う。

 なので、何かこのところ狙い撃ちをするみたいに不具合に遭遇してしまい、かえって申し訳ない気持ちでいっぱいである。荒さがしをしているつもりはないのに結果としてそうなっている。こちらこそ、ごめんなさい、ごめんなさいである。

 まあ、それはともかく、新版で解消したので差し替えて下さいということだが、全部を差し替えるのは大変なので、ソースをみてどこが違っていたのか確かめてその修正だけをすることにした。不具合は2つあった(関数Display_DrawLine_If())。

 ・差分を積み上げるときの数をせっかくABS()で正数にしているのに、元の数で計算。

 ・if(数値)は、0がfalseで0以外がtrueなのだが、数値>0とすべきをif(数値)としていたために負数がすりぬける。

いずれも、全くのケアレスミスである。しかし所長も正しいコードと比較するまで机上デバッグでは見つけられなかった。ソフト開発というのはこういうものである。まさしく書いたようにしか動かない。どんな簡単なソフトでも動くまで信用してはいけない。

 グラフの描画は最初、2重線を引いていたが、折れ線だと1本線でも十分綺麗にでることがわかり一本に減らす。ロジックが少し簡単になった。これで残っている不具合は、電極の装着が依然不安定なことだけになった。

 電極は、前にも書いたように暫く(1分程度)同じ位置に固定していると接触抵抗が下がって波形がでてくるのだが、5分以上置いておいても出てこないときがある。始めつけた場所によると思っていたが、どうも断線の可能性が高い気がしてきた。

 しかし導通テストでは大丈夫である。しつこく調べるうち、遂に、1本のコードで断線を発見した。かしめてあるコードの中の部分で断線していたのだ。かしめた部分をドライバーでこじてゆるめ、コードを引っ張ったらポロッと切れた銅線が出てきた。こういう微弱電位の断線はたちが悪い。

意外に簡単にトリガーはかけることができた(12/26/2014)
 トリガーである。波形を常に一定の場所から描くことである。だんだん、オシロスコープに近い処理が必要になってきた。リアルタイム性は余り求められていないので、トリガーは出てきたデータを一旦バッファーに貯めて、そこから考えれば大抵の方法は思いつく。

メモに沢山思いついたことを書きとめながら色々考えていたが、結局、以下の簡便な方法でやることにした。

・1フレーム分のデータを蓄積し、その中の最大点のポイント(R波)を記録しておく。

・描画は、その最大点より少し前からスタートする。このポイントがフレームの先を越えたらフレームの最初から描く。ここで少しずれるときがあるが、余り厳密には考えない。

・描画と記録の速度を同期させておけば、オーバーランやアンダーランの心配なく、描画が続く(はずである)。

・ただし、フレームの最初の方にピークがあるときは、最大1画面程度まで描画は遅れる。リアルタイムな心電波形ではない。また、最初すぐに波形は出てこない。

 仕様はできた。コーディングする。1画面(300ポイント)のバッファーを定義し、バッファーがいっぱいになったタイミングで、描画の位置を計算する。決まればバッファーの中のデータから描画する。あとはリングバッファーの処理と同じである。

 少々、トラブルがあったが思ったほど難しくなく、ほどなくトリガーの効いた画像が得られた。タイミングが早くなってもピークを含む心拍波形を常に表示することができるようになり、俄然心電計らしくなったきた。

 いやあ、苦節うん十年ではないが、これで、だいたい想定通りの機能は実現した。満足感に浸る。残るは力仕事の枠線(スケール)描画である。そう、数値も出してやりたい。

枠線を出す。やっぱり数値表示が欲しい(12/29/2014)

 枠線は簡単に出ると思ったがやはり落とし穴があった。線を増やしていくと全体がハングするのだ。おかしい。デバッガーを動かすが、落ちるところが一定しない。うーむ、何かオーバーフローか何かでデータが壊されている感じだ。

 オシロで動きを確かめて原因が判明した。何と枠線を引くのに80msもかかっている。一方、UARTは絶え間なくデータを取り込んでいる。UARTのバッファーは256バイトもあるが、ここが怪しい。

Pc286791  そう、やっぱりオーバーフローだった。0.6ms単位に2バイトのデータを出すから、80msも待たされれば、266バイトのデータがバッファーに溜まる。はい、これではだめです。UARTのバッファーを256バイトから倍の512バイトに拡張する。

 ところが、UARTはバッファーサイズを拡げただけでは動かなかったのである。バッファーの変数は16ビットでとってあるのにおかしい。ソースコードを詳しく調べて原因はすぐわかった。関数の中の一時的な変数が全部8ビットで定義されていたというオチである(ねむいさん、ごめんなさい。また見つけちゃった)。

 これを直して無事、枠線も出た。しかし、枠線だけでは何となく物足らない。やっぱり数字がついていないと雰囲気が出ない。文字の表示は、この液晶を縦位置で使うために今度の心電計では、この文字表示列を90°右に回転させる必要がある。これは簡単にはできない。

 ねむいさんのソースはもちろん2バイトコードの漢字まで表示できるのだが、今度のARMはフラッシュが128KBしかないので全部含めてビルドができない。しかも、開発環境がCooCoxという全く違う環境である。必要なところだけソースツリーからつまみ食いするような形でモジュールを取り出してくるのは、とても気を遣う。

 自慢にもならないが、こういう開発の方が、まるごと持ってくるよりはるかに難しいのだ。しかもこればっかりは開発者に聞くわけにはいかない。しかし、やりだしたからにはやめるわけにはいかない。黙々とソースコードを調べては持ち込む作業を続ける。

 ねむいさんのソースは相当進化していて、新しいバージョンではフォントのサポートが滅法増えている。最新版ではFONTX2タイプのフォントが10以上もある。ディレクトリの構造が悩ましい。CooCoxで動くかどうか。

 ふむ、ふむ、FONTX2のファイル.FNTファイルはバイナリーなので、includeは簡単ではない。どうしているのだろう。おお、ChaNさんのテクニックが使われている。なになに、.incbinというgccのアセンブラーgasのディレクティブだ。うーむ、CooCoxの環境でライブラリーパスはどうなる。

CooCox環境で、ARMの文字表示に成功(1/4/2015)

 あっと言う間に2015年を迎えた。今まで我が家で男は、所長とオス猫だけだったのだが、ここ数年婿殿が増えて正月は男女同数になっている。家内が和装にこっていて正月は全員で和服に着替えるのだが、今年はさらに男3人全員が和服に揃えたのでちょっと壮観だった。

P1016809_x  自宅の前で記念撮影をする。自宅は近くの神社の参詣経路にあたっている。通行人の視線が眩しい。その足で元旦の初詣に行く。今年は思ったほど混んでいなかった。寒かったからかもしれない。お正月は酒を飲むので電子工作はお休みである。

 3日の箱根駅伝が、史上始めての青山学院大の完全優勝で終わって、電子工作の再開である。暮れから始めた文字出力の開発を続ける。文字フォントのincludeが出来ないでいる。環境が、CooCoxなのでリンクの方法が全く見当つかない。

 CooCoxのConfiguration画面のcompilerオプションで環境変数の定義は簡単に出来るようになったが、includeパスでは.incbinがファイルを認めてくれない。色々やったがだめである。CooCoxのパスは、実際のディレクトリパスとは全く違う仮想的なパスを定義することが出来るので余計ややこしい。

 試行錯誤の末というより、愚直にソースコードのFNTファイルが入るところにフルパスを入れたら見事に認めてくれた。いやあ、最初からこれでやれば良かったのだ。コンパイルが通って一息ついた。ここまで来ればあと少しである。

 コマンドを新設して、適当な文字を出すテストルーチンを作る。 ふむ、出ない。ああ、そうだ。初期化を忘れている。前の気圧計の時の初期化ルーチンをそっくり持ち込んで再度テストする。 出た出た。12X6のポイントの小さいフォントだが、画面に文字が出た。

 さて、これからまた一仕事である。この文字フォントを右に90°傾けて縦置きにしなければなならない。

縦置きフォントが出た。文字が出て画面は一気にそれらしくなる(1/6/2015)
 文字フォントの回転に頭を抱えている。最初、素直にフォントグリフを縦にスキャンするルーチンを擬似コーディングし、実際のソースをみながら開発に入ったところ、描画ルーチンの実装で重大な思い違いを発見して愕然となった。

 ねむいさんの描画ルーチンは色々なところで高速化が図られており、文字フォントはひとつづつのピクセルを描画するのではなく、文字フォント枠(レクタングル)をあらかじめ描画ドライバーの原始関数で設定してから、そこへ連続したピクセルデータを送って、ドットが流し込まれる方式がとられている。

P1066837_2  画像処理ドライバーで良く使われる高速化手段である。この方式ではスキャンする方向が決まっており(もちろんコマンドで方向は換えられるが、原始関数を駆使する必要あり)、今のままでは、フォントグリフを縦に並べることは出来ない。

 一旦、文字を作ってから、縦のドットを横にスキャンするような形でドットを拾って送り込む必要がある。うーむ、単純に考えていたが、文字を回転するのはえらく難しくなってきた。文字が画面上縦になるのを我慢すれば、このまま出しても良いが、やっぱりみっともない。

 暫く考えていたが、ここまできて辞めるわけにはいかない。速度は遅くなるかもしれないが、2次元配列にフォントを流し込んでから、これをさらに縦横に転置するロジックを作ることにする。

 コーディングしてみると意外に捗った。既存のルーチンをうまく活用してFONTX2形式のフォントを、fontdata[x][y]などの二次元配列に流し込み、このxとyを逆さまにしてやれば良いだけである。

 ついでに既存のフォント出力も、この方式に替え、パラメーターでフォントの回転が出来る関数をでっちあげた。意気揚々とテストに入る。まずは、ノーマルの出力(画面の赤)。うむ、問題なく表示された。

 次は、問題の回転出力である。うーむ、ゴミが出るだけだ。あ、配列番号が間違っている。配列の番号は0からスタートするので最後からスキャンするときは、1少ない数値から戻らないといけない。一番最後も0を含める必要がある。P1076846

 よーし、見事に文字列が縦に表示された(画面上では横の緑文字 ABはオリジナル関数から)。ここまで来れば実際の心電波形に数値を入れてみよう。勢いが止まらない。いそいそとコーディングする。数値はとりあえずは固定値で良い(増幅率や時間で変数にするのはあとで)。

 出ました。出ました。数値が出ると枠線も俄然本式に見えてくるから不思議だ。急いでリストバンドをはめて実際の心電波形を出し、写真撮影をする。いやあ、ここまで来るのは長かったが、とりあえずは、ちょっと見映えのする画面になった。

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

2014年12月18日 (木)

心電計プロジェクト:TFT液晶に念願の心電波形が出た

 プロジェクト開始から半年かけて、やっとのことで2.4インチTFT液晶に想定通りの心電波形を出すことに成功した。まだ、枠線を引いていないし、振幅や時間幅の調整は、UARTによるPCコンソールからで、ケースにも入っていないバラックである。実用性はまだ限りなくゼロだが、とりあえずは一段落である。当初の計画いえば第4ステップの終了にあたる。

 それにしても、このプロジェクトは次から次に課題が発生して苦難の連続だった。今回も最後の最後で、画像ルーチンのバグに悩まされ、結局、コードを書き換えるという姑息な方法でバグを回避した。以下はその顛末である。

息抜きのつもりがストレス。1005チップ部品は手では無理(12/4/2014)
 前回のブログ記事は、センサーからのデータをフォトカプラー経由でSTM32F103が受け取り、TFT液晶にその値をグラフ描画するところまでだった。このときは心電波形をまだ確認していない。でもここまで来ればあともう一息である。

 画像が無事に出て、ちょっと息抜きに別のことをやりたくなった。こういう道草が今回のプロジェクト遅延の大きな要因でもあるのだが、なかなか止められない。寄り道のタネは秋月が最近出した、極小USBシリアルアダプターである。Pc056735 こいつは、秋月の定番のFT232RLを使ったUSBシリアルアダプターより、小型で(USBコネクターはマイクロだが)、値段も安い(¥600)。特にあてはないが買ってあった。しかし、今までのUSBアダプター同様、送信口(マイコンから見れば受信側)の電圧が2.7V近く上がる。例の「セパレーター」が必要だ。

 それより気に入らないのが青色ダイオードのパイロットランプである。日本人3人がノーベル賞を受賞したのであまり大きい声で言えないが、実は所長はこの青は好きではない。パイロットランプというのは、人の神経に触らない暖色系が良いのだが、青色というのは何となく人を不安にさせる。

 で、当然換装することにした。大きさは1608なのでこのチップLEDなら、緑、赤などの手持ちがある。低温ハンダを使わずに少し強引に青色LEDをはずす。何とかはずれた。ありゃま、隣の1005の制限抵抗(1kΩ)も一緒にはずれかかった。つけなおすためこれもはずす。

 ところが、この豆粒のようなチップ抵抗が行方不明になったのである。ピンセットで少し強くつまんだら、飛び跳ねたのだ。テーブルを慎重に見回し、床を這いずり回って調べたが見つからない。やれやれ1005の抵抗なんて手持ちはない。

 探し回るうち、こんなことに時間を浪費している自分がさすがに恥ずかしくなって、パイロットランプなしで行こうと決め、周辺を片付けているときに偶然発見した。何とチップ抵抗は、ハンダ付けのための固定に使っていたミニブレッドボードの表面と中の接続端子板の隙間に入っていた。

 難儀はこれですまなかった。ハンダごての熱で基板のLEDのパターンがはがれてくる。万事休す。あきらめきれず、銅線の切れ端で強引に新しい緑LEDを固定しようとして、今度はLEDをまたピンセットで飛ばしてしまう。そのうちハンダの熱で新しいLEDも表面をはがしておしゃかにする。

 こうなったら我慢くらべのようなものである。3つめのLEDを意地になって取り付け、やっと換装が終わった。ところがこのLEDが点かないのである。息抜きのつもりで始めた電子工作がこのありさまでストレスが一気に貯まる。何もかも放り出して大声を出したい気分である。

 ばかばかしいことをしている自分に無性に腹が立つが、ここで爆発しては今までの苦労がすべて無駄になる。ぐっとこらえて(笑ってください)、気分を鎮め、状況を最初から確認する。そのうち、基板を触ると一瞬LEDが点いたのが幸運だった。ハンダ付け不良の疑いが濃い。

 しかし、ちょっと見た所では問題はなさそうである。さらに色々触って試してみる。その結果、1005のチップ抵抗の一方が完全にハンダ付けされていないことを発見した。ハンダが多すぎてチップをとりかこんではいるが接触していなかったのである。やれやれ。

コンペアマッチが効かないのもお恥ずかしい基本的なミス(12/10/2014)

 雑事で忙しかったこともあるが、わかってしまえば極く当たり前のことに、この3日間頭を抱えていた。今度もここに書くのもお恥ずかしい基本的なミスである。

 心電波形の表示は、時間軸を可変にしておきたい。というのでARMのタイマーにコンペアマッチのステートメントを入れたのだが、これが、がんとして指定の時間に割り込みが入らないのだ。

 気に入らないのが、コンペアマッチの割り込みは順調にかかっているのに、どうしても時間が指定の時間にならない。必ずタイマーのオーバーフローの時間になる。

 いざとなれば、オーバーフローのタイマー設定値を変えても良いのだが、これまでARMのタイマーでコンペアマッチの機能は使ったことがない。経験値を高めるためにも、動かしておきたい。しかしAVRと違って、ARMのタイマーは高機能なので設定することが山ほどある。どれが正しい設定かわからない。

 PWM出力ピンも使わない単純なコンペアマッチだが、それだけでも10近いステートメントで定義しなければならない。ひとつひとつを何度も参考書やウェブのサンプルと見比べるが、どこも間違っていない(ように見える)。謎は、割り込みは正常にオーバーフローと区別しているのに時間が変わらないことである。

 結局、オーバーフロー割り込みとコンペアマッチ割り込みの2つの時間をオシロに出して、始めてその間違いに気づいた。画面にはコンペアマッチの指定分だけ遅れた同じ幅の波形が出た。あ、あ、あ、何という事だ。もう情けないというか、ただ笑うしかない、基本的な勘違いである。

 要するにカウンターがコンペアマッチしたときにリセットしていないのが原因である。AVRではコンペアマッチするとカウンターがリセットされていたので、そのままにしていた。あーあ、何で今まで気が付かなかったのだろう。

 ちゃんと、コンペアマッチで割り込みがかかっても、レジスターをそのままにしておけば、次の割り込みは、レジスターが一周してくるときだ。つまりオーバーフロー値から一歩も動かない時間となる。当たり前だ。

 ARMの関数一覧から、レジスターの値を設定する関数を探し出し、ゼロにするステップを加えて、めでたくタイマーは指定の時間に割り込みがかかるようになった。コンペアマッチで必ずカウンターがリセットされるという思い込みが招いたお粗末である。

グラフもそれらしい波形が出てきた。増幅が難しい(12/12/2014) 
 PCコンソールからのコマンド入力で、表示速度が変化できるようになった。表示される心電波形も、腕のサポートを少しきついハンカチにして、時間をおくと(数分)、だいぶそれらしい波形が出てきた。皮膚と電極の間の抵抗は、時間をかけないと低くならないようだ。Pc116761 ただ、表示波形は、振幅がまだ小さいので、増幅してやる必要がある。しかし、やみくもに、出た数字を大きくしても電圧の高いところでの変化はオーバーしてしまう。AC測定のような工夫が必要である。

 中位電位の設定が難しい。出てくるデータが必ずしも、中間で上下しているわけではない。しかも移動する。始め、中位電圧をコマンドで指定するようにして、そこを起点にAC測定ということにしたが、中位点を固定してしまうと波形がそこからずれると表示されなくなる。難しいものだ。

 そのうち、うまい方法を思いついた。1フレーム(画面)程度のデータの平均値をとり、それを次の画面の中位電位にして、そことの差分を増幅する。画面ごとに中位電位が変動するが、これにより、相当程度増幅(10倍近く)しても、折れ線グラフがはずれなくなった。

 増幅度も、コマンドで調整できるようになり、これで心電波形もかなりはっきりでてきた。嬉しい。やっと完成に近づいてきた。やはり、腕に電極をしっかりつければ倍率を上げなくても明瞭に出てくる。しかし、グラフ表示がドット単位なので、値が飛ぶところは、点だけになってしまう。Pc146773

 これは、以前からわかっていたことで、大きく値が変化したところは何らかの補正をしてドットを補っていく必要があるが、考えているうちもっと良い方法を思いついた。しかし、この実現にはまた難儀が待っていたのである。

ラインを引く描画関数のバグに悩まされるが、回避した(12/16/2014)
 折れ線グラフの補正は、何も、大きく変動したときだけに限定する必要はない。始めから、ドットではなく、前の値からの線分を引けば、完全な折れ線グラフになる。おお、これは完全な解決だ。こういう解決は気分が良い。線を引く関数は、たいていの描画関数には揃っているはずだ。

 あった、あった。Disply_DrawLine_If()という関数を見つけた。画面上の2点を指定すれば、そこに指定した色で線を引いてくれる。これまでのDisplay_FillRect_If()という描画関数(グラフを太くするため2X2の領域塗りつぶし関数)をこれに換えるだけで良いはずだ。

 ただし、起点と終点がいるので、起点となる前の値を残しておく変数を新たに設定する。コーディングはあっという間に完成した。上機嫌でテストに入る。

Pc166774 おやあ、変な斜め線が入って正しい波形にならない。これは何だろう。値が急激に上昇するときにヒゲが沢山入る。下降の時は問題ないが、よく見ると上昇のときはわずかな変化でも正しい線が引かれていない。

 最初は、符号付の指定である関数の引数に符号なしのデータを入れているのが原因かと思って、データを揃えたが変わらない。仕方なく関数のソースコードを調べ始めた。

 何やら難しい手法で線を引いている。コメントによれば Bresenham Algorithum(ブレゼンハムアルゴリズム)というのらしい。ウェブで調べると、こういう描画の時の古典的な定番のテクニックらしく、色々なサイトで紹介されている。

 少し調べたが、間違いはなさそうだ。こういうソースコードにバグは考えにくい。何か、前提となるところが間違っているのだと思うが、思い当るところがない。もしかしたら、入れている数値がおかしいのかもしれない。

 こうなると意地になるのが所長の特徴である。コマンドを新しく作って、心電波形に近いピークの波形(一方が最少の変化で、もう一方が激しく動く)をリテラルで指定し表示させてみた。見事に間違った波形が表示された。よし、関数のバグであることに間違いない。

 しかし、どこが間違っているのか特定できない。机上の計算では間違いないのに何故か暴れる。暴れる原因は、線分のX座標の低いところから高いところの線だけがおかしく、逆は問題ない。Y座標はどちらでもセーフである。

 考えているうち、簡便な解決法を思いついた。線を引くだけなら、どちらを始点にしても変わらない。関数のバグは解明できなくても、描画する前に始点と終点を調べて、バグが出ない方向で関数を呼び出せばよいのだ。

 早速、コードを追加し(ifで同じ関数を引数だけ換えて呼び出すだけ)、テストに入った。でました。でました。これまでのような飛び飛びの描画ではなく、連続したグラフが美しく表示されるようになった。ラインを2重に引いた(座標を1つずらす)ので折れ線グラフがはっきり見えるようになった。

Pc176775

 まだ、細かいところや、枠線などがないので完璧とは言えないが、当面の心電波形の表示はこれで完成と言える。いやあ、長かったけれど何とかここまできた。達成感で胸が膨らむ。

 このあとは、スケールを描くこと、PCコンソールではなく、ロータリーエンコーダのようなもので調整が出来るようにすること、ケースに入れることなどが残っているが峠は越した。

 ただ、少しひっかかるところがある。表示波形のR波(一番鋭いところ)のピーク値が低いことだ。後のT波、U波と同じくらいである。もしかしたら病気なのかも知れないが、そうではなくて、サンプリングが少ない可能性の方が強い(希望的観測)。

 AVRとARMのUARTインターフェースで、第一バイトを識別するためデータを端折っている。残さずデータをARMに送るのは、以前、コメントでいただいた、5ビットづつの2バイト送信ロジックを検討してみるのも面白いかもしれない。いやいや、やることはまだ山ほどある。

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

2014年12月 3日 (水)

心電計プロジェクト:STM32F103の心電波形表示で悪戦苦闘

 かれこれ半年かけた心電計プロジェクトは遅まきながらARM(STM32F103VB)で2.4インチTFT液晶に心電波形を表示するソフト開発まで進んだ。それにしても、液晶を動かすだけに大騒ぎしたり、フォトカプラーの選定に川崎まで高速カプラーを買いに行ったり、センサー部のTiny861のUARTにはまったりして、やたら脱線が多い。 Pb296721

 前の記事から20日余り、少しづつ作業を進め、やっとのことでTFT液晶から実際のグラフが表示されるようにはなった。しかし以前、DACでオシロに出したような綺麗な心電波形はまだ出てこない。これを待っていると次の記事がいつになるかわからないので、とりあえずこのあたりで経過報告をしておくことにする。

USI-UARTは動いた。送信プロトコルを決める(11/11/2014)

 センサー部のTiny861で動かなかったUARTは、もともとISPケーブル経由でPCとつなぐUART(ISP-UARTと勝手に命名)で、ARMへのUARTインターフェースは、最初からバッファリングの出来るUSI-UARTを予定していた。I2Cを通してDACに送っていたデータは今度はARMに送られる。このUARTの移植は問題なく終了し、プログラムは動き始めた。

 UARTらしい波形がオシロから出ている。念のためロジアナで出力波形を確かめた。ところが、これが全くでたらめなデータなのである。ISP-UARTに続きこれもダメかとがっくり来る。どうしてなのだ。何を間違えたのだろう。

 気を取り直して、慎重に状況を最初から調べる。ほどなくロジアナのプロトコルアナライザーのボーレートが設定と違っていることを発見した。早速、設定を合わせる。おお、ちゃんと正しい出力データが出てきた。やれやれ、ほっと胸をなでおろす。

 通ったのは良いが、ここは送信プロトコルが問題で、まだ具体的な仕様を決めていない。10ビットのバイナリ―データが2バイトでセンサー部のディジタルフィルターから送られてくる。データの時間間隔は625μsで、38400bpsのUARTなら2バイトだと、260μs(スタートストップいれて10ビット)の2倍、520μsかかるので、ほぼ連続してデータが送られることになる。

 何もしないで送ると、どれが第一バイトかわからなくなるので、何らかのロジックが必要である。10ビットは、1023が最大値なので、最初、第一バイト(右詰めとして)が3以下という、洒落たロジックで第一バイトを識別しようとした。しかし0~1023の中で、それでも区別できない数値が20個近くあることがわかり(0,1,2,3,256,257,258,259など)、あきらめた。

 結局、採用した方式は、精度を犠牲にして連続して送るのをあきらめ、2バイトと2バイトの送出単位の間に一定の待ち時間を設け、受信側は、必ずその待ち時間だけ待ってから第一バイトを受け取る方式にした。Ws000000

 グラフ表示が最大320ドットで長くでもスキャンは一秒間隔なので、3.3ms単位以下のデータは表示しても意味がない(前の記事の33msは間違い)。1ms程度の待ち時間を入れても大勢には影響ないはずだ。

 テストを進める。Tiny861のPCコンソールモニターでの値と、ロジアナのデータの値がほぼ一致した。待ち時間は、625μsの送出を1回休んで間隔を明ける。従って、送信頻度は、約1.25ms単位となる。  まだ、ARM側のソフトが動いていないが、ロジアナの波形は正しいデータを示している。間違いないようだ。これで、AVR側のソフト開発は一段落である。ARM側のソフト開発の前にフォトカプラーの実装をすませてしまおう。

フォトカプラーとインバーターをつける。インバーターは不要か(11/12/2014)
 センサー基板のすみに、フォトカプラーTLP512と、一緒に買って来たシングルチャネルインバーターTC7S04Fをつける。SOT23-5の極小のチップだ。持ち合わせの変換基板にハンダ付けする。フォトカプラーは論理反転するので元のUARTにするためである。Pc026733

 SOT23-5の変換基板が結構大きく6ピンのフォトカプラーと同じくらいだ。この変換基板はもう1ノッチ小さくできるような気がする。それはともかくハンダ付けは簡単に終わった。配線を確かめて早速テストに入る。

 Tiny861のUART出力ピンを一つ間違えて、出ない出ないと騒いでいたが、オシロをあてて間違いを発見し、フォトカプラー経由でも問題なくUART波形が出た。テストしているうちに、このインバーターもいらないような気がしてきた。Pc026728

 フォトカプラーの出力側を、エミッタフォロワーの形にすれば、順論理になる。どうしようか迷ったが、まあ、配線してしまったものを取り外すほどのことでもない。このままにしておく。バイナリ―端末アクノリッチでUART出力が正しく出ていることを確かめた。これでAVR側は完全である。少しづつではあるが、完成に向けてことが進んでいく。気分が良い。

Ttl  ちまちましたハンダ付けをやっているうち、もう少し手を動かしたくなった。こういうのはやりだすと止まらない。SOT23のインバーターチップを見ていて、これを汎用基板に直接ハンダ付けすれば、変換基板を使わずにもっと小型化ができる気がしてきた。

  そういえばUSBのUART TTLアダプターの受信側に電圧(負論理なのでNO DATA)がかかってAVRが幽霊動作をする現象をさけるため、かなり昔に、トランジスターのエミッタフォロワーで受けて受信側を遮断する「セパレーター」を基板の切れ端に作ったことがある。Pb266713

  AVRは低電圧でも動作するので、USB経由のUARTをつないだままにしておくと、power on resetがかからない。この現象は今度のプロジェクトでも起きて迷惑している。しかし、このセパレーターはブレッドボード用で、こういう基板同士の接続では不便で使っていない。そうだ、SOT23のチップトランジスターなら在庫がある(2SC4116)。これを使って小型化してみよう。

 いつもの脱線である。本題が順調に進んでいないときは、こうした工作を無性にやりたくなるものだ。ちょうど秋月で極小TTL UARTアダプターを買ってきたところだ。こいつにもつけられるよう汎用基板の4×4の切れ端に、ピンヘッダー、チップトランジスターとチップ抵抗2つを実体顕微鏡でハンダ付けする作業に入った。Pc016725

 ほどなく、写真のようなアダプターが完成した。配線図を参考までに。抵抗やスピードアップコンデンサーはチップ部品である。もちろん38400bps程度なら問題なく動く。いやあ、こういう道草を食っているから本題がちっとも進まない。

ARM(STM32F103)のUARTが2つ同時に動かない(11/18/2014)
 ゆるゆるとARMの開発に戻る。Tiny861からの送出データを受け取るUARTの増設だ。ねむいさんから頂いたソースコードは、複数のUARTが定義できるようになっている。始めは簡単に増やせると思っていた。しかし、これがまた難儀したのである。

 ソースのUARTの初期化ルーチン(conio_init(UARTn))が、どうも良くわからない。この初期化ルーチンは引数にUARTの番号を入れてやれば、それに応じたUART(この石はUARTを3つ持っている)を初期化しているので、併設が出来るものだとばかりと思っていた。

 しかし、2つUARTを初期化すると、2つとも動かなくなる。ソースコードを調べ直す。ふーむ、case文以外に#ifのプリプロセッサ―でUARTルーチンを制限している。なぜだろう。調べていくうち、どうもこのコードではUARTをダブって定義できないような感じがしてきた。

 見かけは、引数にUART番号を入れさせて、独立してUARTが併存できるようなコードにはなっているが、2つめを定義すると動かなくなるというのは、何か変数が被っているに違いない。しかしARMのUARTの初期化は、GPIOピンの定義から始まってややこしくAVRのように簡単ではない。ちょっと見ただけでは何が何だかわからない。

 さらに、仔細にコードを調べて行って遂にUARTの構造体が共通であることを発見した。こいつを独立させて(もうひとつ分ける変数があったが)、めでたく2つのUARTを動かすことに成功した。そもそも、2つ同時にUARTを動かす初期化ルーチンではなかったことに早く気付くべきだった。 Ecg_arm_in

 いよいよ、センサー部のTiny861とARM(STM32F103)をフォトカプラー付きUARTでつなぐ。まず、ARMを立ち上げてPCにコンソールを出してから、センサー部の電源を入れる。よっしゃー、PCコンソールから16進表示したセンサーのデータが溢れるように出力された。良いぞ。

UART2つが同時に動いたが、データの取り込みはうまくいかない(11/20/2014)
  このままではコンソールからデータが溢れて中味がわからないので、PCからのコマンドで一部だけ表示するようにソフトをいじり、中味の検証に入った。おやあ、第一バイトと第二バイトを取り違えているデータが頻々と入っている。

 皮肉なことに、正直に何もしないでデータを読む方がかえって間違いが少なくなる。何とも馬鹿にした話である。待ち時間がおかしいのか。コンソールデータだけではわからないのでロジアナを持ち込んで精密に波形を調べ始めた。どうも1msだけでは区別がつかないようである。

 仕方がない。AVRに戻って、待ちの間隔を2倍にした(2回休む)。しかし、2回休むと、AVR側が2バイトづつ送らなくなったり、どうも不安定だ。コードのなかでcontinue文を使ったのが原因のようだ。愚直にif文を区分けして、このトラブルは解消したけれど、これに係っている暇はない。先に進む。

 間隔は、データ2個分1.25msまで空いた。1msの待ちで最初のデータを識別するには十分な時間である。しかし、データは頻々と第一バイトと第二バイトを逆さまに読むケースが続出する。ARMの待ち時間がおかしいのかとGPIOピンでわざわざ時間を出してみたが正しく1msだった。

 うーむ、何が悪いのだろう。この方式では識別ができないのか。別の方法も考えるが、こんな簡単なロジックがうまく動かないというのが気に入らない。別の方式の検討に力が入らない。頭を抱える。

素晴らしく美しい富士をめでる(11/22/2014)
 ちょっと息抜きに、電子工作以外の話題をご紹介。こんなに美しい富士山の姿は、これまで見たことがなかったので、その感動のおすそわけである。 Pb226692

 知人に伊豆高原に別荘を持っている人がいて、毎年、季節の良いころに仲間で利用させてもらっている。今年は紅葉を目当てに友人と何台かの車ででかけた。伊豆は観光シーズン中は海岸沿いの道が大渋滞するので少し遠回りになるが箱根に上がって尾根伝い(天城スカイライン)に行くことが多い。

 箱根の山は、紅葉が中腹から美しく色づき歓声を上げながら山を登っていたが、圧巻は峠を登り切って振り返った時の富士山の姿である。十国峠からの景観が特に素晴らしい。

 晩秋の裾野から雪をかぶった富士山が丸ごと見える。こちら側からの富士は、宝永山の火口壁が目立って山梨側に比べると少し見劣りがするということだが、そんなことを感じさせない迫力である。

  この峠周りルートは、霧が出たりすると地獄になるが、こんなに晴れるのも珍しい。駿河湾から裾野、頂上にいたるまで雲一つないというのは、これまで何回もここを通っているが初めての経験だ。道行く車やツーリングのバイクもあちこちで車を止め、盛んにシャッターを切っていた。

  この景観がめったに見られない証拠は、帰りの道中で明らかになる。この話を聞いた海岸沿いで来た別の車の友人が、天気が良いので帰りは山に上がったのだが、靄(もや)がかかって富士山は全く見ることが出来なかったそうだ。相模湾側は青空が出ていて雲も高かったのだが山の天気というのはこういうものである。

やっと間違いなくデータを受け取れるようになった(11/25/2014)
 旅行から帰って電子工作に戻る。データの受け取りはまだ正確に行えない。こんなにエラーの多い状況ではグラフは曲線にはならず、散布図状態にしかならないだろう。

  ARMのUARTをなめてかかってえらい目にあっている。毎日が暗い。下らないことにこだわっている自分がみじめで余計気持ちが落ち込む。しかし数日後、このトラブルはあっけなく解決した。たまたま居間から地下室のPCルームに降りる階段の途中で間違いに気が付いた。

  これが、電子工作の醍醐味だなどとうそぶくのも悔しい基本的なミスである。今度もわかってしまえば何でこれに気が付かなかったのだろうと思う基本的なミスだったのだが、わかるまでほぼ2日間かかった。

  要するに、keypressed()という関数をキーに受信データの到着時間(バッファーにデータが揃ったとき)を一生懸命測っていたのだが、実際にはデータを読まなかったため、バッファーに次々にデータが貯まり、条件が揃ったときに読むデータは、ずっと前に受信したデータだった、というオチである。

  これでは、何もしない方がデータが正しく読めるはずである。原因がわかってしまえば修正はあっというまだ。データが来たときは、必ず受信関数でデータを読み、バッファーを空にしておくだけである。修正に要した時間は1分もかからない。

  コンパイルしなおして、正しくデータが読めていることを確認する。よーし、画面一杯にデータを出しても、全く乱れはない。やれやれ。あっけなく治ってしまった。 トラブルが解消するたびに、いつも何とかならないかとは思うが、こればっかりは仕方がない。考えたようには動かない。書いたようにしか動かないという格言をかみしめる。

悪戦苦闘が続く。まだ心電波形は出てこない(11/30/2014)
 いよいよ最後のステップ、得られたデータの画面表示である。枠や数字、スケールの表示はあとにするとして(これは面倒だが力仕事)、気になる数値のグラフ表示のロジックをコーディングしながらつめる(本当はおすすめしません)。

  以前考えた通り、出力値(0~1023)を液晶表示ドットY軸(240ドット)に正規化して、2X2ドットのピクセル(最初は赤、画面が暗くなるので黄色に変更)を打っていく。ロジックは何も難しくない。グラフはX軸の最後(320ドット)まで行くと最初に戻る。

  描画のとき、以前、打った値を覚えておき、表示と同時に消せば(黒で描画)、常に一つの波形が表示される理屈である。コードそのものは簡単で開発はすぐ終わった。わくわくしながらビルドする。NO ERRORだ。CoIDEは快適で、コネクターを一切いじらずに、テストまで一気に進める。Pb276718

  デバッガーを抜けてスタート。画面に待望のグラフが出た!おやあ、これはグラフではなく、単なる散布図だ。それに、やけに画面表示が早い。タイマーが機能していないのか。オシロで画像表示のタイミングを調べる。何い150μsだとー、早すぎる(設定は2ms)。ARM(STM32F103)のタイマーにコンペアマッチのコードを入れたが、これが機能していないようだ。

  タイマーの問題はあとにするとして、この散布図状態は明らかにロジックミスだ。何とかしなければいけない。ソースコードを調べる。ここのミスはすぐわかった。保存すべき描画ポイントを間違えている。前の描画ポイントではなく、出すべきポイントを消している。

  それなのにどうして描画されるのだ?このあたりを追及しているヒマはない。とにかく間違っていることは確かなので、正しく描画の後にデータをセイブするロジックに変える。再度テスト。おおー一本線のグラフが出た。いや、何本も線が出る。しかし夜中も2時近い、もう寝よう。

  表示が早すぎるのはタイマーを間違えているからで、これは時間を調整すれば良いのだが、問題は多重に出る線である。値が不安定になっていることを示している。またデータの第一バイトと第二バイトが正確に読めていない可能性が高い。

  寝る前に入った深夜の風呂の中で、また突然、原因に思いあたった。第一バイトと第二バイトをループを別にして読んでいるのだが、描画ルーチンが入ったことによって時間遅れが生じ、第二バイトを飛ばしてしまっているに違いない(第二バイトの読み込みにも時間条件をつけて離れていると無効にしている)。

  考えてみたら、第一バイトを読んだ後、第二バイトが来るまでここで待っていても全く問題ない。無理に非同期に動く必要は何もないのだ。むしろ、描画ルーチンのタイミングによっては、第一バイトだけ読んで表示をする可能性もあり、ここは2バイトを読むまで動かない方が良い。

  ゆっくり風呂に入っていられなくなった。迷ったけれど、風呂から出てジャンバーを着込み、地下の工作ルームに降りてPCの電源を入れ直しCoIDEを立ち上げる。思い立ったら寝られない性質(たち)である。眠気は吹き飛んでいる。Whileを使って第二バイトを待ち、そのあと描画ルーチンに行くように制御を変えた。

 よし、グラフは一本線になった。まだ描画タイミングが150μsと早すぎるので線はめまぐるしく動くが、少なくとも1本だけのグラフで動くようになった。少なくとも多重な線が出ることはない。時間を遅らせるのは明日にしよう。

  次の日、タイマーのデバッグに入る。ARMのタイマーについては、4年前の以前の記事を参考にしていたのだが、結局、このサンプルソースに誤りがあることがわかった(修正してあります)。プリスケールを決めるステートメントに重複があり、2番目のTIM_PrescalerConfig()は、無駄だったのだ。

  これを消去し、やっとタイマーは想定通りの時間で動き始めた。当然、画像もそれらしいゆったりとした心電波形(らしきもの)を表示し始めた。嬉しい。苦労が多ければ多いほどこの喜びはなににもかえがたい。Pb296722

  しかし、プローブを腕に巻き付けて心電波形が出るのを待ったが、穏やかな直線が続くだけで、一向に心電波形らしきものは出てこない。この状態は前にも経験がある。ピークが0.5V P-Pなのに4Vスケールで出しているからだ。

  この改修には少し時間がかかる。どの電圧範囲を広げるかを決めるのは簡単ではない。この前の記事からもう20日が経っているので、そろそろこのあたりでブログに報告することにする。

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

2014年11月10日 (月)

心電計プロジェクト:表示部の詳細設計とインターフェースに悩む

心電波形表示の擬似コーディングを始める(10/20/2014)
 長い間道草を食ってきたが、やっと心電計の波形表示部の詳細設計まで来た。それにしてもこのプロジェクトは遅れに遅れている。始めたのが6月だから、もうそろそろ半年近くになる。オシロで波形を見たのが7月なのに、これをARMで液晶表示をしようとしてから事が進まない。

 ARMの開発環境の整備から始まり、TFT液晶が動きだすまで、基板を買い直したりして2ヶ月もかかってしまった。どうも最近は集中力が落ちている。PCに向かってもすぐ設計に入れず、ついWindows7に入っていた無料ゲームで時間をつぶしてしまう。効率がガタ落ちである(スパイダーソリティアの中級がとても難しい。最初は20回に一回もクリアできなかった。現在は、勝率10%)。

 まあ、繰り言を言っていても始まらない。TFT液晶は何とかカラーバーまで出たので、これでやっと波形表示のソフト開発に入れる。心臓パルス波形をオシロスコープのように折れ線グラフで表示するところだ。

 オシロスコープのロジックは、難しいことを言い出せばきりがないが、基本原理は簡単だ。対象測定値の変化を時間単位に点で表示し、これを連続的に出して画面の端に来れば再び同じことを繰り返すだけである。

 単位時間が短くなり、一秒の1/1000(ミリセカンド)、1/100万(マイクロセカンド)の世界になれば、どのタイミング(トリガー)で、どれだけのデータ範囲を画面に描画するかなどとなると、とたんに難しくなるが、幸い、心臓の鼓動は1秒程度の非常に長い周期なので、そういう気遣いはいらない(はずだ)。

 こんどの液晶の描画単位は240X320ドットである。これを横に使い、300ドットの間を2秒程度でポイントを打ち終えれば、元に戻ってポイントを打ち直す。そのとき前に描いたポイントを消していく。この繰り返しで心電図の波形が表示できるはずだ(ほんとうか)。

 こういう描画で一番面倒なのが、この折れ線グラフよりむしろグラフのスケールや、数値の表示である。このあいだのグラフィック気圧計でも、プログラムの殆どの手間は、縦横の線や、日付の表示にかかっていた。

 オシロスコープのソフトは、ネットのあちこちで紹介されているようだが、見ないことにしている。困ったときは頼りにするつもりだが、初めから見てしまうのには抵抗がある。見たことでそれに縛られたくない。少し意地になって独自開発を目指している。201411090012

 印刷の裏紙にメモを書き散らし、イメージを膨らませながらプログラムの骨格を作り始めた。表示だけならどうと言うことはない。問題なのは、センサー部から送られてくるデータを取りこぼしなくいかに表示部に送るかというインターフェースの部分である。

TFT液晶基板の実装版は簡単に動いた(10/27/2014)
 その矢先、親戚に不幸があって丸々一週間の間が空いた。この間、関西を2往復した。年も年だったし(80才)、長い闘病の末だったので覚悟は出来ていたが、亡くなったのが兄弟の中で一番仲の良かった長姉だったので少し精神的に参った。

 何もしていないと次から次に思い出が湧き出してきて気持ちが沈む。それを拭っ切るために、少し無理にでも電子工作に気持ちを向けることにした。関西から帰ってきて工作机を整理していたら、TFT液晶基板の実装がまだ済んでいないことに気付いた。

 TFT液晶の接続は、このあいだ買ったスルーホール用のジャンパーによる仮接続で、このままにしておくわけにはいかない。それに、センサー部のディジタルフィルターのマイコンTiny861もブレッドボードにささったままだ。まずは、液晶基板の実装をやることする。

 実装を先延ばしにしていたのは、レイアウトに迷っていたからである。ウェブなどの作例を見ると、こうした液晶画面の実装は殆どは、基板の上に重ねていくスタック構造が主流で、この前のグラフィック気圧計もそうなっている。

 ケースのことまで考えると、コンパクトにするためには必然的にこの形になるのだが、もうちょっと面白い実装はないか色々調べていた。しかし良いヒントは得られなかった。

 結局、芸のない話だが前と同じスタック方式で、CPU基板の上に主基板を載せ、その上にTFT液晶を載せることにした。早速、両面の汎用基板を切り出す。前と同じスタイルなので作業に迷うところは少ない。

 少し工夫したところは、普通のピンヘッダーとソケットでは背が高くなりすぎるので、TFT液晶と主基板の接続を背の低いICソケットピンにすることにしたところか。ピン側は、秋月が最近売り出した「細ピンヘッダー」を使った。201411090010

 これで今までのスタック基板が何となく間が抜けた感じだったのが、少し引き締まったスタイルになった。それに、この種のピンヘッダーは高価で使いにくかったが、これは安いのでお財布にも優しい。

 3時間で15本(30個所)の配線が済んだ。ショートだけしていないことを確認して通電。あっさり動いた。まあ、ロジックも何もない、コネクターとピンの間をつなぐだけの作業なので造作がない。

詳細設計を進める。インターフェースが難しい(10/29/2014)
 問題のインターフェースの設計である。これまでのセンサー部と、表示部のインターフェースを具体的に決めなければならない。その前に電源だ。センサー部は生体に接続するので、万が一を考えて電池で駆動する。表示部はACアダプターかUSB経由で電源を供給し、センサー部とはフォトカプラーで絶縁する。

 インターフェースのプロトコルである。I2Cは既にDACで使っていて開発が不要だが、こいつは絶縁が簡単にはできないのでパスである(双方向で動く必要がある)。無線のXbeeが一番スマートなのだけれど、今のところストックがない。

 これも、あれこれ迷って、とりあえずはUARTでフォトカプラー経由でつなぐことにした。受信はいらないので、送信だけの1チャンネルで良い。

 送出データは最初、保守性を考えてキャラクターで送ることを考えていた。しかしキャラクターにすると3バイトが必要で、38400bpsの速度(当研究所のUART標準)では、センサー部の最小サンプリング単位625μsを軽くオーバーしてしまう。

 画面表示は早くても数十msのオーダーなので、平均化などして送出単位を延ばせばよいのだが、このあたりの調整は表示部でやりたい。ということになると2バイトバイナリで送るのが順当なところだろう。

 読み込みのロジックは結構面倒だ。受信は、UART受信割り込みでデータを取る予定なので、2バイトづつで1ブロックのデータを識別する必要がある。姑息な方法だが、フラグを立てて、最初のバイトと、2番目のバイトを区別する方法に決める(最初のデータを落とすとおしまいだが)。

 画面表示のタイミングは独立したタイマーの割り込み(正確な時間表示のため)とし、センサー部からの数値データの受信とは非同期にする。こういうところの設計はなるべく独立して動くようにしておくのがコツといえばコツである。

 こうしておくと、プログラムの開発が別々に出来るし、いわゆる丈夫な(Robust)なプログラムになる(バグや変更に強い)。プログラムの構造は決して簡単にはならないし、ステップ数も多くなるが、独立して動くようにしておく方が、保守性は高い。オブジェクト指向と同じである。

 描画のタイミングを確かめておく。画面には2周期くらいの心電波形が出るようにして、一画面300ドットが2秒、1周期なら1秒。1ドットの描画タイミングは、33~66msと極めて長い。これに対して、センサーからは、最速で0.625ms単位にデータが送られてくる。

 たまたま読んだ1つだけのデータをそのタイミングの値にするのでなく、平均値を計算しておいて、それを使うべきだろう。タイミングがずれた時や、バッファーの書き込みと読み出しはどちらを優先するかなど、決めておくことが多い。なかなか具体的なコーディングには入ることが出来ない。

フォトカプラーの道草。TLP552はぶっちぎりに早い(11/2/2014)
  そんななか、また本題とは関係ないところで脱線してしまった。今度はフォトカプラーである。センサー部と、表示部の間の絶縁をする、UARTのフォトカプラーの選定で道草を食ってしまった。

 まず、実際の38400bpsのUARTに試しに手持ちの汎用カプラーPS2501を入れてみた。全く動かない。オシロで波形を見る。細いパルスは出ているが、UARTの波形の形を成していない。出力側の負荷抵抗や、入力LEDの制限抵抗を少しいじるが全く効果なし。やっぱりだめか。Fg

 このまえのウェブカメラの駆動部ではRaspiの間でフォトカプラーを使ったが、これは単なるスイッチ入力なので速度は関係ない。そういえばフォトカプラーでUARTをつなぐのは始めてだ。どの程度のUART速度が良いのか。汎用カプラーでも、立下りは25μsなので、40Kbpsくらいまで行くはずなのだが何故通らないのだろう。

 急に、このあたりを調べたくなってきた。高周波パルスなら、自作したシグナルジェネレーターが20Mhzまでの矩形波が出せる。こいつでフォトカプラーを通してみれば一目瞭然だ。でもそのうち、シグナルジェネレーターの出力ではフォトカプラーを駆動できないことに気づいた。201411020005

 今までだったら、ここで諦めているところだが、電子工作歴も7年となると色々な手を思いつく。よせば良いのに、ついこれまでの経験を生かしたくなる。オペアンプで増幅し(AC 1VをP-P 5VのDCにする)、ボルテージフォロワーで受ければ、LEDぐらいは動くはずだ。

 思い立つと、矢も楯もたまらなくなってしまう気質だ。早速、試してみる。2倍程度の反転ACアンプとボルテージフォロワーの組み合わせをブレッドボードにでっちあげる。意気揚々とテストに入った。うむ、LEDを点灯させても波形が出ている。良いぞ。

ところが周波数を上げていくと波形が崩れてきた。矩形波が三角波になり最後は消えてしまう(DCになる)。何い、常用のオペアンプLM358ではそもそも10Khz以上を増幅できないのだ。ええー、オペアンプってこんなに遅いの?

 そうか、音声周波程度までしか動かしたことがなかったか。しかし、オペアンプなら手持ちは他にも沢山ある(計装アンプまである)。ただヘッドアンプ用が多いので高周波に使えるかどうか。それに、両電源でないと性能を発揮しないオペアンプもあったはずだ。

 自信はなかったが、とりあえずは、レールtoレールのLM6428で試してみることにする。これは確か高周波にも強く、単電源でも動く。ブレッドボードなので交換はいとも簡単で差替えるだけである。201411020001

 おーし、LM6428ならMHzレベルも余裕でOKだ。これでMhzオーダーの対LEDパルスを出す装置が完成した。喜び勇んで、手持ちのフォトカプラーを片っ端から動かしてみた。

 結果、PC817, PS2501、TLP521のような汎用カプラーは、9600bpsがやっとである。10khzを越えると、長いturn off時間で次のパルスと一緒になってしまい、元の波形とは似ても似つかない形になる。

 では、かねて用意の高速フォトカプラーTLP552(¥200)ではどうだろうか。このフォトカプラーは、以前FETスイッチを作るためにサトー電気まで行ってフォトボル(TLP590B)を買いに行ったとき、何かの時にと買ってあったものである。DIP8ピンだが、一回路しか入っていない。データシートを見ながら通常のフォトカプラーと違う結線をする。

 動かしてみた。何と、こいつはすごい。オペアンプもMHz近くなると矩形波がなまってくるが、これを見事にカバーして楽勝でパルスを伝達する。10Mbit/sの性能は伊達ではない。この急ごしらえのパルス発生装置では上限を測れなかった(オペアンプの方が降参する)。ただし、パスコン(0.1μF)を入れないと確実に発振する。

別のフォトカプラーTLP512を調達(11/5/2014)

 しかし、このTLP552は1個¥200(千石では¥242)と汎用カプラーに比べれば、5倍近いコストである。それに10メガビットオーダーまで動くというのに、この程度のものに使うのにはちょっともったいない。どうしようかと迷っていたら、サトー電気のウェブサイトで、TLP512という高速カプラーが¥140で出ているのを発見した。201411090009

 こいつは1Mbitまで動くとあるので、38400bps程度のUARTの接続にはぴったりだ。値段も半分とは言わないが大分安い。脱線につぐ脱線だが、こうなるとどうにも止まらなくなる性質で、手に入れたくなった。

 次の日、車で環七を南下して久しぶりにサトー電気の川崎店まで足を延ばす。片道20キロ。ガソリン代を考えたら通販の方が安いと思うが、ま、ドライブのつもりなら腹も立たないと自己正当化する。せっかくなので10個手に入れた(このあたりは生産停止が多いので買い置き)。201411050007

 ついでに欲しかったシングルチャネルのインバーターTC7S04Fも10個買う(10ケで¥500 これも生産停止品)。高速で正負論理を切り替えたりするときに、トランジスターでは遅すぎ、インバーターICを1回路だけ使うのも大げさな時に便利である。それに、今度の高速カプラーは論理反転してしまうので、必要になるかもしれない。これはSOT23-5の小さなチップだが、変換基板があるので怖くない。

201411050006

 帰って、早速、TLP512のテストをした。うん、38400bps程度では全く問題ない。115200bpsあたりになると少々怪しくなるが、ほぼ、問題なくパルスを通した。DIP6ピンなので、TLP552より小さくできる。これでUARTを絶縁するフォトカプラーの準備が出来た。

モニター用のISP-UARTが動かない!Tiny861のバグか?(11/8/2014)
 フォトカプラーの実験はそろそろ切り上げて本来の工程に戻ろう。ブレッドボードにささったままだったセンサー部のディジタルフィルターのTiny861の実装である。

 アナログアンプの基板には既にスペースは確保してある。つけるパーツは殆どない。単にISPピンを立てて、それぞれの入出力(アナログ入力、UART出力)をつなぐだけである。フォトカプラーのスペースも空けておく、今後の改造(Xbeeを追加したい)にそなえて、Xbeeチップの場所も考えながらレイアウトする。これも特記することもなく順調に終了した。201411090011

 このあとの地獄が待っているとも知らず、鼻歌混じりでソフトの開発に移る。インターフェース部の通信インターフェースの開発である。これまでは、モニター用のUARTと、I2Cだったが、今度は、UART2つになる。

 Tiny861はハードのUARTを持っていない。2つのソフトUARTを用意しないといけない。当然のように、モニターには、ISPケーブルだけで動くISP-UARTをテスト用に入れ、これまでコンソールに使っていたバッファー付きUSI-UARTをデータ転送用に移すことにする。

 まずは、AVRSPのプログラマー経由で動くISP-UARTの組み込みである。AVRを始めて以来、何十回も繰り返した手順だ。ソースコードの最初の開発日付は、7年も前の2007年から始まっている。ChaNさんオリジナルのUARTモニターにピンチェンジ割り込みの受信ルーチンが追加されたものだ。

 バージョンも、ChaNさんのアセンブラーが残っているソースから、最近のCのライブラリで統一したバージョンまで沢山ある。最新のバージョンを選んでライブラリを取り換え、テストする。

 これがウンともスンとも動かないのだ。おかしい、何も変わったことはしていない。とりあえずオシロで送受信波形を調べる。なにー、PB1(ISPではMISO)から何も波形が出ていない。PB0はPCコンソールからの入力なので波形が見えるの当然で、ピンチェンジの割り込みは入っているようだ。

 ISP-UARTは、リセットピンがenableのときに動く特殊なUARTで、PB1はプログラムをロードするときは派手に動いているのでハード的には問題ない。しかしUARTとしてPB1を使おうとすると最初に一回パルスがでるだけで動かない。UART関数の送信ピンをPB1ではなく、PB2やPB3にすると問題なく送信波形が出力される。???である。

 以前、リセットピンとグランドの結線を間違えて同じような現象で悩んだことがあったことを思い出し、何度も配線チェックをするが、間違っていない。プログラムのバージョンを取り換えたり、最初のChaNさんのソースまで戻ったが、動かない。

 念のためにCPUチップを取り換えたが、もちろん同じ状況である。もう調べるところがなくなった。途方に暮れる。ISP-UARTが動かなくても大勢には影響しない。ただでさえ遅れているのにこれ以上遅らせるわけにはいかない。結局、諦めた。

 普通のGPIOのUARTに切り替える。何という事もなく動いた。モニター用のUARTピンを追加しなければならなくなったが、それだけのことだ。しかも、このUARTは本番時には使わない、やれやれ。Tiny861のバグは、まあ考えられないだろう。どこかで勘違いをしている可能性が大きいが、とりあえずは、このあたりでブログの記事を上げることにする。

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

2014年10月16日 (木)

心電計プロジェクト:CooCoxでARMの表示系ソフトを開発する

UARTのテストでつまずくがデバッガーに助けられる(9/21/2014)
 少しづつCooCoxの環境下での開発を進めている。Lチカはうまく行ったので、次は定番のUARTである。UARTでモニターを作ればCPUの動きをとりあえず完全に把握できる。CooCoxにはリポジトリ一覧画面があり、そこから数多くのサンプルソースを得ることが出来る。適当なUARTのサンプルを見つけてきてプロジェクトを作った。

 割り込みを使った送受信サンプル、usart_txrx.cである。内容を確認する。どうも変数の名前が変だ。iとか、jなどの変数名が文字カウンターと受信データそのものに使われている。iとかjは内部のカウンターなどだけに使う名前で、具体的な意味を持つ変数には、それを連想できそうな名前にするのが、わかりやすいプログラムの定石だが、それが守られていない。

 まあ、それは良いとしてもmainの中に勝手に割り込み関数の実行ステートメントが挿入されている。これおかしいよね。割り込みで飛び込んでくる関数をmainで実行しても意味がない。これ以上追及するのも大人げないので、さっさと消して先に進む。

 しかけは、いつものようにPCからのキーボード受信待ちでプログラムを止め、キー入力で動く簡易なモニターである。手始めにLEDの点・消灯のコマンドを入れる。ほどなくコンパイルはOKになった。動かしてみる。送信はうまく行ってWelcomeメッセージは出るが、入力を受け付けない。Ws000002 難しいことは何もしていない。それなのに、さっぱり入力データが所定のバッファーに入らない。何度もソースを見直すが間違っていない。ロジックアナライザーを登板させるのも気が引けるぐらい簡単なところなのに動かない。

 そのうち、今度の環境にはデバッガーが入っていることに気が付いた。やせ我慢しないで積極的にこれを使ってみよう。ただ、このデバッガー、ブレークポイントを設定してもそこで止まってくれない(フラッシュ下では無理なのか)。

 しかし、変数は表示できるので、キーを延々と打ってステップ実行で動きを追いかけてみた。AVR などと違ってさすがは32ビットマシンである。UARTの受信だけで結構なステップ数である。

 その結果、原因が判明した。何のことはない、以前苦労した外部変数の宣言ミスだった。データを受け取るところと、それを取り出すところが違うので外部変数にしてあったのだが、同じ名前でもタイプが違うとエラーにもならないで別の変数になってしまう。

 今度の場合は、extern宣言のとき、うっかりデータタイプをつけ忘れたのが原因である。警告は出ていたのだろうが見落とした。情けない。

 それにしても、デバッガーにはお世話になった。今度のデバッガーは、UARTの入出力がデバッグ中にも動いたので助かった。デバッガーによっては、UARTのような時間依存する入出力では動かないものが多い。

 これでプログラムのテストは、LEDの点滅、UARTの動作まで進んだ。ここまで来れば本番を入れても大丈夫だろう。

CooCoxに画像表示ソースを移植する(9/24/2014)
 いよいよ、心電計の画像表示のプログラムをCooCoxで開発するステージに達した。2年前に開発したグラフィック気圧計のソースコード一式をCooCox環境に持ち込む。

 このソースは、「ねむい」さんが開発したTFT液晶のSDカードのファイラー(ChaNさんが原型)がオリジナルで、ここの画面描画ルーチンを利用させてもらって2日分の気圧をグラフ表示している。

 今回はSDカードは使わないが、買ってきたTFT液晶のコントローラーが前と同じILI9325なので(というより同じものを探して買った)、描画部分を流用しようという腹づもりである。

 ねむいさんのソースは、数多くのプラットホームに対応しているだけでなく、数えきれないくらい多くの液晶コントローラーをサポートしてくれているのが嬉しい。液晶ディスプレイの初期化や、描画ルーチンはコントローラー単位に全部違うので、これだけサポートしてもらえると、安心してジャンク液晶を買うことが出来る。

 ただ、その設定は、makefileでの環境変数を定義するだけで一発で動くようになっており、そのためプログラム構造が階層化され、構成は非常に複雑で一筋縄ではいかない。特に今回はmakefileが使えないので、定義をどこでやるかが問題だ。

 しかし量が膨大だからと言って立ちすくんでいては先に進めない。こういうときは目をつぶってとにかくソースファイルを持ち込んでみることだ。まずは、プロジェクトのフォルダーにソース一式を放り込む。

 もちろんこれだけではCooCoxはプロジェクトのリソースとしては認めてくれない。project画面でノードを右クリックすると、add group とadd filesというアイテムが出てくる。これがどうやらプロジェクトにリソースを入れるコマンドだと当たりをつける。

 試しに、適当な名前で新しいgroupを定義してaddしてみるとフォルダーになった。add filesは文字通り、ソースファイルが、そのディレクトリに入るようだ。これはうまいぞ。自分の予想があたって上機嫌である。

 鼻歌まじりで、沢山のソースコードをプロジェクトに入れて行く。不思議なことに、プロジェクトフォルダー内のヘッダーファイルは自動的に探してincludeしてくれる。ただしあとでも書くように、出来るところと出来ないところがある。

 適当なところで、ビルドをかける。予想通り膨大なエラーメッセージが出る。まあ、これは織り込み済みだ。ここからが勝負である。ひとつづつエラーメッセージを見ながらつぶしていく。1日半かけて、やっとのことで全体のコンパイルエラーはなくなった。

 動くかどうかは全く分からないが少なくとも、画面を出すルーチンはNO ERRORになった。同じようなことをやろうとしている方と、これからの自分のために(備忘録として)、遭遇したエラーの数々を簡単にまとめておく。

  • _IO というデータタイプ(CMSISのvolatile の代わりに使うタイプ宣言)が何故かsyntax errorになる。--> volatileに戻してOK。うまく行っているソースもある。?である。
  • stm32ペリフェラルライブラリーのincludeを明示的にしないと引かないモジュールがある。      -->わけはわからないが、その都度、#includeを追加してOK
  • falseという汎用的なシンボルが未定義でエラーになるソースファイル( term_io.cなど )がある。これは前もそうだった記憶が。    -->適当に#defineして追加。

とりあえずコンパイルは通った。ちょっとした達成感に満足する。 ただこの段階は壮大なオペラで言えば単に序曲が終わったくらいのところで、これからが何幕もある本番に入る。どんなドラマが待っているか、期待と不安が高まる。わくわくどきどきのこの気分はいつもたまらない。

printfでsegment fault(9/25/2014)

 とはいえ、環境の異なるところへの、まとまったソース群の移植はそう簡単にはいかない。しかも、CooCoxは、makefileもリンカースクリプトも見えない統合環境である。果たしてこのまま動くかどうかは何の保証もない。

 だいたい、このプログラムのUARTそのものは、ねむいさんのコードでは、printfが使われていた。ややこしいので最初はコメント化し、自前の別の出力関数を使うつもりをしていた(そのためのUARTテストでもある)。

 しかし、途中で計画を変更した。たまたまCooCoxのリポジトリを見ていると、その中にsyscalls.cがあるのを見つけた。printfは、標準入出力ライブラリを使うので、こうしたサポート関数が必要なのだが、CooCoxが持っているということは、メモリ管理をしてくれているということだ。このまま動くかもしれない。

 喜び勇んでsyscalls.cをincludeし、printfのコメントをはずしてコンパイルしてみる。おおー、通った。NO ERRORだ。ただし、フラッシュは一気に30KBを越えた。まあ、フラッシュは128KBあるのであまり心配しない。

 まだTFTディスプレイは実装していないので、画像表示部はコメント化したまま、とりあえずUARTだけ動かしてみる。わくわくしながらフラッシュを書き込んだ。JTAGのおかげで30KBを越えるファームも数秒でロードされる。だめだ動かない。PCには何のメッセージも出ない。しかし、今度はデバッガーという強力な味方がいるので先に進める。Ws000000

 よーし、USARTの初期化は順調に動いているようだ。USARTの出力直後にハングしていることがわかる。ふーむ、割り込みベクターがおかしいので、送信のあと、おかしなところへ飛んでいるようだ。そういえば、ねむいさんのオリジナルからNVICの初期化をするルーチンをmain.cからはずした。

 これはベクターテーブルをSRAM領域か、FLASH領域にするかをリンカースクリプトで決めるルーチンだった。今回はリンカーが見えないので、defaultに戻そうと削除したやつだ。必須なのか。だめもとで、このルーチンを復活させる。

 動いた!コンソールにWelcomeメッセージが出た。いやあ、嬉しい。いそいそと次のモニターの部分の受信ルーチンを、全くダミーだったmain()のループに入れていく。さあどうだ。あらら、またsegment faultだ。

 今度のエラーはどうも根が深い。ステートメントを少しづつ増やしていくと突然ハングに入る。何か予感がしたので(このへんが長年の経験によるカンだろう)、printfをはずして、自前のcputsというUARTストリング関数に換えてみた。

 ピンポン!である。全く問題なく動いた。printfのメモリー制御部分のエラーである可能性が高い。さっきのsyscalls.cがうまくいっていないことは確かだ。なにしろメモリーのレイアウトは全く手さぐりである。リンカースクリプトが見えないのでいじりようがない。

CooCoxのFAQでprintfが解決(9/26/2014)
  このまえの仕事が一段落し、事務所のPCでネットを見ていたら、CooCoxの本拠サイトでprintfに関するFAQを見つけた。printfを動かす手順である。これだ、これこれ。結構複雑だ。後学のために、邦訳しておく。

(1)スタートアップルーチン(startup_stm32f10x_md.c)で以下を追加する。
#define STACK_SIZE   0x00000400   //スタックサイズの拡大(最初は0x100)                                                            //余り大きいとSRAM容量を超えるので注意
__attribute__ ((section(".co_stack")))    //スタック領域を実際にとる
unsigned long pulStack[STACK_SIZE];

(2)メインルーチン(int main())で、以下を追加する。
/* Set unbuffered mode for stdout (newlib) */
setvbuf( stdout, 0, _IONBF, 0 ); 
   //stdoutをバッファリングしない
#include <stdio.h>                           //もちろん、本体をインクルード

さらに、CooCoxのRepositry画面で、commonの項目から、C Libraryを選んで、syscalls.cを加える(これはもう済んでいる)。

(3)configuration画面で、Linkタブを選び、LibraryでUse base C libraryを選択して、Linked Librariesの入力枠にm(小文字のmだけ)をAddする。これは何のためかわからないが、言われる通りにする。

 帰宅して早速試してみる。Configuration画面でリンカーのオプションがいじれるようになっているとは知らなかった。少しづつCooCoxの環境に慣れてきた。

  FAQはSTM32F4xxシリーズ用だが、必要なステートメントはF10xにもあったので大丈夫だと思う。動かしてみる。おおー動いた。スタックサイズが微妙で、オリジナルの256バイトではハングする。4KとるとSRAMがもう一杯と怒られる。1K(0x400)で十分動いた。

  自分の予測や見込がぴったり当たって思い通りの結果が出るというのは、どんなささやかなことでも嬉しいものである。いつもながら幸福(しあわせ)な気分を味わう。電子工作の醍醐味のひとつだ。いや、喜んでいるばかりでは先に進まない。TFTはどうした。そう今度はハードの配線が待っている。

新しいジャンパーコードが活躍。しかしTFT液晶基板動かず(9/27/2014)
 気を良くして、いそいそと次のハードの工作に移る。CPU基板からTFT液晶ボードへの配線は、このあいだ買ったサンハヤトのスルーホールに差すジャンパーを使うことにしている。 201410010001

 8ピンバスを使うので配線量は少ない。思っていた以上に簡単にうまく行った。ハードの準備はあっけなく終わって、残るはディスプレイのドライバーソフトである。最後の難関だ。TFT液晶のドライバーの初期化さえ動いてしまえば、あとの画面表示の開発は楽しいプログラミングになる。

 このねむいさんのコードは、大量の数のディスプレイをサポートしている。そのための抽象化が何段にもわたっているのでとても複雑だ。不要なコードを消しつつ、慎重に何度も確かめながらアサインしていく。Eclipse風の、ソースコードでのマクロ定義や、#ifdefを区別してくれるCoIDE(CooCoxの統合環境名)の環境は、こういうときにありがたい。201410010002

 ただ、ILI932x.cは何故か、16ビットモードにしかならず、新しい#defineシンボルを新設して強引に8ビットアサインに変更する。何度か失敗しながら(#undefで一旦、前の環境変数をクリアし、また#defineで定義し直すなどの小細工)、やっと実際のピンと関数の中の変数が一致した(CoIDEで確認できる)。

 ピンアサインと初期化ルーチンの確認をすませ、いよいよ、これまでコメント化したTFTディスプレイの初期化のルーチンを本番に戻し、TFTを生かしたテストに入る。

ディバイスコードは出るのに反応なし。またTFT液晶基板の不良か(9/30/2014)
 2日間がんばってテストしたが、結論は残念ながらタイトル通りの結果である。最初は全くの門前払いだった。printfでdeviceコードを出力させて調べてみると、何と、このTFT液晶(LM024C9325)のコントローラーはILI9325ではなく、ILI9328だった。

 店のウェブ記事では9325と明記してあり、型番がいかにも9325風なので、すっかりだまされていた。あわてて、9328の初期化シーケンスをねむいさんのソースライブラリから抜き出し、取り換える。しかし、それでも液晶画面は白いままである。初期化によって画面は黒くなるはずだが変化がない。

 コマンドを送って、正しいdeviceコードを返しているのに(8ビットモードであることはジャンパーをわざと外して確認)、次の初期化で画面が黒くならない(レクタングルを黒で塗りつぶす)のは、やっぱりハードが悪いと結論するのが自然なところだろう。

 deviceコードを返すコマンドが正しく動いていることは、データラインのジャンパーを外してみると違った値になるので間違いはない。移植のときのミス(何しろ変則的な使い方をしている)を疑って、別のサイトから初期化シーケンスを持ってきて試してみたが、やはり同じだった。やれやれ、基板不良の可能性が高い。

 もし、これでこの基板が不良なら、Aitendoで買ったディスプレイの不良率は軽く30%を越えることになる(7枚のうち2枚完全不作動、1枚画面一部欠落)。しかし、ここほど安くて沢山の種類が選べるところは他にない。こんなものと諦めてまたここで買うしかないか。

 残念ながら、店は国慶節の休みに入っていてすぐに買いに行くことができない。ブログに書いた原稿を編集しながら時が来るのを待つ。

2台めも動かない。これはハードではないだろう(10/3/2014)
 Aitendoの新しいリアル店舗を訪ねる。末広町の東北、もう御徒町に近いところで秋葉原から少し遠くなった。広さは倍くらいあるだろうか。店員の数も増えた。最近ニューヨークに上場したAlibabaの電子材料店舗群に比べれば値段ははるかに高いが、それでも日本では破格の安さだ。特にリアル店舗は実際に手に取ったりできるのがありがたい。

 TFT液晶を2台買う。1台は、2.4インチの前と全く同じILI932xを使ったもの、もう一つはArduino用という、3.5インチで320x480のTFT液晶を衝動買いした。安かったので(¥1980)、つい買ってしまったが、また部品箱の肥やしになりそうである。

 帰宅してとるものもとりあえず、TFTのテストをする。ジャンパーを取り換える。これは便利だ。すぐ終わった。期待をこめて電源ON。ややや、画面は白いラスターのままである。何と、これでも動かない。期待が大きかっただけに、がっくりくる。

 まさか、2台とも不良ということは、いくらチャイナクオリティだと馬鹿にしていても、ちょっとありえない話で、これは、こちらの初期化の失敗とみるのが順当なところである。

 メモに症状をもういちど書き直して、対策を練る。データシートをダウンロードして、いちから調べ直しだ。STM32の方は、オリジナルのGPIOEポートをGPIODに変更しているが、全く問題ないことを確認した。

 一番あやしいのは、8ビットモードがILI932xで最初、定義できなかったことだ。強引にピンを割り当てたが、プログラム中での16/8ビットモードの書き分けが心配だ。ソースコードをしらみつぶしにして、#ifdefで分けていないか探す。コマンドを出す関数で1ヶ所、変更されていないところを見つけた。これだ!これにちがいない。喜び勇んでビルドし直し、テストする。

 いや、やっぱりだめだ。同じような白ラスターが出るだけである。リセットしたときのような点滅もない。こうなったら、コントローラーの動きを最初からチェックして、少しづつ正しくコマンドがコントローラーに送られていることを確認するしかないか。

ロジアナで派手に波形を出しても正常。暗礁に完全に乗り上げる(10/9/2014)
 ロジックアナライザーに目いっぱいのプローブをつけて動作解析である。液晶の制御ピンに5ピン、データバス8ピンにグランド、合わせて14ピンがジャンパーケーブルに群がる。壮観な眺めである。ただ、このロジアナ(ZEROPLUS)のプローブは出来が良く、着実にピンを捉えるので使いやすい。

201410090003  救いはJTAG関係が好調で何度でも簡単にビルドしてテストが続けられることだ。ロジアナで所望の波形はすぐ得られた。最初、データバスのenable信号WRが出ていないところを発見し、これだ!と色めいたのだが、サンプリングが遅すぎることに気が付き、戻したらちゃんと波形が出ていてがっかりする。

 初期化は順調にやっている。時間遅れもぴったり。8ビットコードで2回WRやRDを出していることも確認できた。何だ。ちゃんと制御信号を送っているではないか。最後の制御コマンド、0x07(display on)も、所定通りのビットが立っている。問題ない。 Ws000001

 これで完全に暗礁に乗り上げた。ディバイスコードが正常に戻っていて、波形も正常。それで動かない。うーん、もしかして、2台目も不良? 信じたくはないが、客観的な状況はそれを物語る。しかし、ちょっと有り得ない話で、3台目を買いに行こうという気にはならない。

 やることがなくなって、とうとう、また、ねむいさんに助け舟のメールを出した。これで何回目か。まあ、すぐには返事は来ないだろうから、少し頭を冷やす良い機会と、TFT液晶とARMのソースの解析を続ける。

 いろいろ勉強させてもらった。 ARMのGPIOの特殊な使い方(BSRR BRRレジスター、IDR、CRLレジスター)や、ディスプレイコントローラのロジックなど、こういう機会でなければ勉強する機会がなかったところに、すっかり詳しくなった。

やっとのことでTFT液晶が動いた。カラーバーが眩しい(10/14/2014)
 ほどなく、ねむいさんから丁寧な返事が来て、色々な助言を頂いた。こちらの状況を報告しながら、少しづつ言われた処理を試していく。メールのやりとり数度、しかし、事態は好転しない。ブログの記事も、もう一か月近くご無沙汰だ。そろそろ出さないと書き溜めた記事が古くなってしまうと思っていた矢先、問題は一挙に解決した。

 これが面白いことに、ねむいさんがソースの不具合に気づいて知らせてくれたのと、自前で暫定的に初期化に成功したのと1時間も差がないというドラマティックな展開となった。いやあ、みなさんから時々、波瀾万丈とか七転八倒とからかわれるけれど、まさしく今度も劇的な結末となった。

 発見の端緒は、CS(チップセレクト)ピンの不審な挙動である。初期化の途中、なぜかCSがdisableになってしまっている。始め気が付かなかったが、長いスパンで波形を見ていた時発見した。ねむいさんにはこれを知らせてあったので、これをヒントに不具合を見つけられたのだと思うが、ロジアナの波形には、はっきり映っている(添付のロジアナ画像の丸で囲んだところ)

 もしかしたら、CSの結線がされていないからかもしれない、と最初は思った。でも、Highにするとdeviceコード読み取りそのものが動かなくなるので、CSが効いていることは間違いない。しかし、初期化の途中で何故CSが上がるのか。

 試しに、コマンドの中に、CSをset/resetするコードを加えて動かしてみる。これで大部分は、その通りになったが、まだごく一部でCSが暴れる。おやあ、TFT画面を見ていると何か少し変化したぞ。ふーむ、ピンへの出力がパワー不足か。ピンをプルダウンしてみる。これは効果なし。ただ、前のように全く無反応ではなく、画面がほんのわずかだが暗くなった(ような気がする)。

 それではいっそのこと、CSピンを強制的にグランドに落としてはどうか。STM32のGPIOピンに悪影響があるかもしれないが、まあ壊れることはないだろう。そうだ、はずしておけばよい。乱暴だが入力ピンをはずして、液晶のCS端子をグランドに落として(enable)、リセットする。

201410140004  あっあっあ、画面が真っ暗になった。ひやっほー、初期化に成功した。間違いない。念のため、clearを赤でしてみる。見事、画面が赤くなった。やったやったぞ。いやあ嬉しい。これを電子工作の醍醐味というと誤解されそうだが、うまく動かないからこそ、この喜びは何にも代えがたいのだ。

 気分が落ち着き、PCでネットを見たら、ねむいさんからメールが届いていた。おおお、不具合が見つかったという知らせだ。時間を見るとちょうど自分が見つけた時とほぼ同じ時刻が発信時刻だった。何という偶然。

 ILI932x.cというドライバーを8ビットモードで使って、しかも、データピンとコントロールピンを同一のポートで定義しているときにのみに起きる現象のようだ。恐らく、私のCSピンの動きをみて発見されたのだろう。

201410140005  原因は、実にささいな1ステートメントの定義違い(8ビットのところへ16ビットデータをぶちこむ)なので訂正は、わずか一か所(8ビットキャストをするだけ)である。これで、めでたく、CSを強制的にenableにしなくても正常に初期化された。

 動きの確認のため、早速やっつけでカラーバーを出すコマンドを作ってテストする。問題なく出た。赤、緑、黄、青の4色の鮮やなカラーバーが眩しい。いやそれにしてもこの10日余りは地獄の日々だった。 しかし解決の美酒はこのうえなく美味い。でもソフトウエア開発の難しさを改めてかみしめる。これが仕事でなくてよかった。

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

2014年9月19日 (金)

心電計プロジェクト:表示部のARM基板の開発環境を一新する

 心電計プロジェクトは迷走を続けている。心電波形をオシロで確認してから、もう2か月近くたつが、次のステップの波形の画面表示は、道草(無関係なAVRのUARTのデバッグ)ばかり食って、一向に進まない。

 そのせいなのか、このブログのアクセス回数がこのところ減ってきたように思う。商売にしているわけではない、別に何の問題もないのだが、気分的にはあまり良くない。ということもあって、少し発破をかけてプロジェクトを進めることにした。

 これまで、オペアンプで増幅した心電波をディジタルフィルター(AVR)にかけてノイズを除去しI2CのDAコンバーターでアナログに戻して波形をオシロで見たが、実はこれは波形を確認するための寄り道で(ステップ3)、本来はフォトカプラーのUART経由でARMに送り、2.4インチTFT液晶画面に表示をするのが最終目的である。これで初めてスタンドアロンの心電計が出来上がる。

 久しぶりのARMである。プラットホームはSTM32F103という今や時代遅れのチップだが、心電計のグラフを表示するくらいなら問題ないはずだ。在庫整理にもなる。

Aitendoの生基板で2つめのARM基板を作る(9/5/2014)
 ARMの基板は以前作ったグラフィック気圧計のときと同じ、AitendoのSTM32F103用の生基板(¥450 [PCB-STM32F103V])を使う。必要な部品は、大分前から少しづつ揃えてきている。 前に同じものを作っているので特に迷うところはない。雑誌付録(CQ-STARM)の基板からはずしたCPUチップは既にハンダ付け済みだ。201409140001

 RTC(Real Time Clock)は今回のプロジェクトでは使わないが、基板にはパッドが用意されている。せっかくなので時計用の32.768khzクリスタルを秋月で買った。これが何と¥100で4つも入っている。しかもえらく小さい。世の中の進歩はこんなところにもあるのだと感心する。

 チップ抵抗やコンデンサーは、これまでジャンク基板から昆虫採集のように集めてきたものが沢山ある。それでもさすがに足らないものが出てきて、千石電商の地下で買い足した。ここはすごい。1608と2012の大抵のチップ部品が揃っている。リールを短く切ったものが10ケ¥50で手に入る。 目に優しい2012で揃える。

 表面実装部品のハンダ付けは楽しい。どんどんはかどる。プリント基板なので誤配線の心配もない。あっというまに20ケ以上の部品が実装され、コネクターも揃った。さて、いよいよ残るはソフトである。PCが新しくなっているので、まずは開発環境を一から作り直さなければいけない。Eclipseを入れるかどうか迷っている。

日本のテニス界がすごいことになっている(9/9/2014)
 電子工作以外で最近感動したことをひとつ。想像もしていなかったことがニュースになっている。テニスの錦織圭選手の全米オープンテニス大会決勝進出である。10代の初め頃から逸材といわれ、いずれはグランドスラム(4大大会のこと)で活躍すると言われてはいたが、怪我に悩まされて、いつも今一歩のところで涙を呑んでいた。

 それが、今年になって人が替わったように突然勝ち始め、あれよあれよという間にランキングを上げて、遂にこれまで日本人の誰もが到達できなかったところまで勝ち進んでしまった。それも世界ランク1位のフェデラー相手に互角以上の試合をしての決勝進出である。そうなるかも知れないとは思っていても、いざ本当になると改めて感動する。

 野球ファンには申し訳ないけれど、イチローや松井がどれだけ活躍してもWorldwideということではテニスとは比較にならない。何十年も前、ホンダがF1レースで優勝した時も、世界に与えた衝撃は大きかったのだが、日本ではそれほど騒がなかった。今度のこともこれに近いかもしれない。

 それにしても今までにない快挙である。日本の評価を上げたということでは国民栄誉賞を2個や3個あげても良いくらいだ。今回は優勝を逃したが、まあ、まだ24才だ。あまり早く頂点に登りつめないで落ち着いてやるほうが長持ちするのではないか。

 新聞記事の中では、今、世界的に通用する日本人アスリートがすべてゆとり時代に少年少女時代を送ったという指摘が面白かった。確かにそうかもしれない。彼らの日本人離れした度胸や自信は、これまでの日本人と一味違うような気もする。

レイアウトが難しいので、スルーホール用ジャンパーセットを買う(9/11/2014)
 それはともかく意気込んで工作を始めたのだが、レイアウトが難しい。普通にやると、TFT液晶基板、CPU基板、それをつなぐメイン基板の3枚になってしまう。これを避けたいのだが、なかなかうまいアイデアが浮かんでこない。

 さらに、時間軸、波形高の調整をロータリーエンコーダーで格好よくやろうと考えているのだが、このレイアウトも決まらない。接続は当面、フォトカプラーを使った有線にしようと考えているが、無線のXbeeにしたい気持ちもある。201409140002

 そんなこんなでなかなか具体的に進まない。CPU基板はすべて配線を終えたのだが、何となく怖くて通電できない。全体の構成が決まらないので、ハードの工作はこれ以上進めない。I/Oピンをソケットにするか、ピンヘッダーにするのかでも迷う。

 ちょうどそのころウェブで、基板のスルーホールに差して使えるジャンパーが売られていることを知った。これならまだ基板の構成が未定でも安心してテストが出来る。ストロベリーリナックスのジャンパーは、何故か目茶目茶高い(10本で¥4720)のだが、さらに検索してみると他にもあった。

 この、サンハヤトのものが安い(TTW-200 10本で¥738)。サンハヤトにしては珍しくリーズナブルな価格だ。アマゾンでも売っている。ここなら送料もかからない。迷わず2袋を注文した。ほどなく届いた。早速試してみる。201409140003

 ちょっと固いが良さそうだ。ただ、抜き差しを繰り返せば甘くなることは考えられる。しかし恒久的に使うものではないので、そう心配しないで良いだろう。レイアウトは考えていてもきりがないのであとにすることにして、次のソフトウエア開発環境の導入を進めることにした。ファームの書き込みは前と同じシリアル経由か、JTAGか。

ARMの開発環境を整理してみる(9/12/2014)  
 ARM系は気圧計以来すっかりご無沙汰で、開発環境が大きく変わっている。たくさんのハードやインターフェースが登場し、何が何やらさっぱりわからない。いちから勉強しなおすことにする。紙にでも書いて全体を整理しないと、とても理解できそうにない。

 それでも、ウェブ情報を読み進めるうちに、だいぶ事情がわかってきた。開発環境が激変したのは、JTAGまわりではなく、HLA(High Layer Adapter)といわれる、新しく加わったハードの開発環境で、JTAGそのものは変わっていないようだ。

 STマイクロには、STLink(/V2)というハードがある。例の激安のDiscovery評価基板に、必ずついているやつだ。汎用のCPUがついていて、USBを経由してターゲットCPUのファームを焼くプログラムが内蔵されている。ターゲットとのインターフェースはJTAGではなくて、新しい規格のSWD(Serial Wire Debug)などを使う。

 NXPのLPCシリーズにも同じようなハードが用意されている。LPCLinkと称している。mbedは最初は独自のインターフェースだったが、その後このLPCLinkでも扱えるようになったようだ。こうしたハードのデバッガー(プログラマー)とターゲットとのインターフェース規格も、昔はJTAG一本だけだったのが、SWDとかDFU、CMSIS-DAPなどの新顔が登場し、話がややこしくなっている。

 こうした商用ツールと、新しいインターフェース規格が次々に市場に投入されているところへ、GNUなどのオープンソース勢がからんで互換品を出したりして、話が余計わからなくなっているようだ。いずれにしろ、JTAGそのものがなくなったわけではないことは確認した。

 以前ARMで、お世話になった「ねむい」さんが活躍されている。ウェブの情報収集では必ず彼(彼女?)の名前が出てくる。しかも、ねむいさんのサイトが一番詳しくて親切だ。暫くしてその理由がわかってきた。

 要するにGNU環境で(無料で)、無制限にソフトを開発できる環境を作ろうと考えると、日本語で検索する限り、必然的にここに行き着くのだ。ねむいさん自身がオープンソースのデバッガーの開発にコミットしておられるようで、情報が早い。

 今度の生基板は旧来の20ピンのJTAGインターフェースがついている。JTAGのためにチップ抵抗を10ケ近くもハンダ付けした。これを利用しないとこの手間は無駄になる。これまでのOlimexのJTAGドングル(ARM-USB-TINY FT2232系)とOpen OCDで問題ないはずだ。

 ただ、Open OCDのバージョンが大幅に上がっているので、その対応をしなければならない。ねむいさん謹製のバイナリをしっかり頂戴する。

Open OCDのインストールはしたがCooCoxへ浮気する(9/14/2014)
 万が一JTAGが動かなくてもこれまで愛用していたROMモニターによるシリアルの書き込み環境がなくなったという情報はどこにもないので、あのMCUISPやFlashMagicでも書き込めるはずだ。ファームの書き込み手段についての不安はもうなくなった。

 開発環境のもうひとつの大きな要素、ソースコードなどの処理環境である。ARMではEclipseを使おうと思っているのだが、頼りのねむいさんが、蛇蝎(だかつ)のようにEclipseを嫌っているので、ねむいさんのインストールガイドのまま行くとEclipseを使わない環境になってしまう。

 自分だってEclipseにこだわっているわけではない。あれば便利というだけで、当初苦労してスクリプトを入れたOpen OCDのプラグインは殆ど使わなかった。ただ、階層化しているソースコードを検索する強力な機能がついているので、何度か助かった記憶がある。入るのなら入れたい。

 それはともかく、バージョンの上がったOpen OCDのインストールである。Open OCDは問題なく入ったが、Win7のPCが、OlimexのJTAGドングル(ARM-USB-TINY)を認めない。ドライバーのアイコンに!がついたままになる。

 あわてて、ウェブを探し回る。みなさん苦労しているようで、すぐ対応策は見つかった。 これで、ディバイスマネージャーのアイコンにちゃんとOlimexのサインが出た。

 いよいよ、Open OCDのテストである。DOS画面でコマンドを入れる。動いた。しかし、cfgファイルがないと怒られる。ここからは、次の環境を意識しないと設定ができない。ねむいさんのガイドではinsightなどGNU系のデバッガーソフトのインストールが待っている。さらにエディターを別に用意しなければならない。

 うーむ、もう少し楽な方法はないか。ねむいさんのガイドをもういちど読み直す。すると、「初学者向け」の開発環境としてCooCoxを勧めているところを見つけた。Eclipse風なのだという。ちょっとサイトを覗いてみる。すると、

  • Eclipseをベースにした統合開発環境
  • ARM系全体で使える
  • JTAG SWD双方サポート
  • フラッシュ制限なし
  • もちろん無料

となかなか良さそうである。こちらの要件にも合っている。

 「初学者向け」というのに少し抵抗を感じたけれど、なに、初学者に違いないのだから何もこだわることはない。無償なのはありがたい。入れてみることにす る。CooCox公式ガイドによれば、本体を入れる前にまずgccコンパイラー一式を落とせということである。素直に従う。Ws000000

 CooCox指定のgccは、ねむいさんの勧めるgccツールチェーンと同一だった。おお、これは幸先が良さそうだ。ツールチェーンは問題なくダウンロードできて展開もスムーズに終了した。

 本体のCoIDEのダウンロードを始める。これがサーバーがやたら遅い。サイズは450MB少々なのだが、スピードが100KB/secいかない。全部落とすのに一時間以上かかった。

CooCoxでデバッガー環境が出来てしまった(9/16/2014)
 ダウンロードは時間がかかったが、インストールは早かった。ただ立ち上がりはEclipse並に遅い。似たような画面があらわれた。手さぐりで動かしてみる。まずは、ダミーのプロジェクトを立ち上げ、Configuration画面でデバッガーを設定する。OlimexOpenOCDを選ぶ。

 マニュアルは殆ど見ないでも先に進める。Device画面で、STをクリックするとSTM3210x系のチップがずらりと並び、そこからSTM32F103VBに行き着く。残念ながら富士通のFM3は載っていなかったが、SpansionというメーカーのMB9BF36..,というチップが気になる。

 ググってみたらピンポンだった。Spansionが富士通セミコンダクターを買収したらしい。ただし、雑誌付録のMB9BF618Tはラインナップされていない。しかし、もしかしたら使えるかもしれない。ちょっと楽しみになってきた。

 それはともかく先に進もう。Debug画面に戻って、フラッシュ書き込みを指示する。おやあ、エラーメッセージを吐いて動かない。赤文字でUSBの接続が出来ていないというメッセージだ。おかしい。PC上では認めているのにどうした。初手からつまづいた。

 定石通り、ウェブに、「CooCox Olimex ARM-USB-TINY」のキーワードで探す。今度も一発で対応策がでてきた。Olimex本体のサイトのページである。 英語だけど読みやすい(外国人の英語だからか)。なになに、なんだと、PCの設定は全部未定義に戻せとある。  言われるままに、ディバイスマネージャーでドライバーを全部削除する。未定義の!のついたアイコンに戻った。

 CooCoxのDebug画面に戻り、ファームの書き込みを選ぶ。なんと、沢山のメッセージを出しながらCoFlash(恐らくOpen OCDのラッパー)が動き、あっけなく、JTAG環境が動いてしまったのである。

 メッセージによれば、しっかりファームを書き込んでいる。NO ERRORだ。何もしないプログラムだが、int  main()のループのなかに矢印がでて止まっている。レジスターの値もそれらしい値だ。Open OCDでさまよっていた部分は全てすっ飛ばして、いきなりフラッシュを書いてGDB状態になっている。今までの苦労は一体何だったのかと思うほどの拍子抜けである。 Ws000001

 しかし、まさしく「初学者向け」の環境である。OpenOCDらしい沢山の経過メッセージが目にも止まらない速さでconsole画面を流れるが、コマンド入力などは一切受け付けず、全く触(さわ)ることは出来ない。

 いずれにしてもデバッグ環境だけでなく、スタートアップルーチンから、各ペリフェラルのディレクトリチェーンまで今までとは全く異なってしまった。すべてCooCox任せである。これまでのプログラムは全部このあたりが書き直しになる。これも少し困ったものだ。

Lチカまで成功。しかし道は遠い(9/17/2014)
 テストしたプログラムは何もしないループするだけのダミープログラムなので本当にプログラムを書き込んだのかどうかを確認することにした。OlimexのCooCoxガイドにあるLED点滅のプログラムをsampleフォルダーから引き出し、実際に動くかどうかのテストをしてみた。

 今度はComponent画面である。ここのComponentの意味は、ペリフェラルライブラリ―のGPIOやRTC、ADC、USART、SPI、DMAなどの要素の意味である。ここで必要なペリフェラルを選ぶと、CooCoxが依存する他のコンポーネントも自動的にディレクトリごと読み込んでくれる。このあたりがミソだろう。

 Lチカなので、クロック関係のrccと、I/Oポートのgpio、それにスタートアップのCMSIS coreを選ぶ(これは指定しなくても自動的に入っていた)。Lチカのsampleソースも選ぶと、gpioピンをトグルするソースが入る。そのソースコードのピンを現在のAitendo基板のピンに揃える。それだけである。ビルドし、デバッグに入る。

 何と、これで簡単に動いた。赤と緑のLEDが賑やかに点滅する。やれやれ、何もしないでARMプログラムが動いてしまった。難しい話は何もない。 あっというまに、CooCoxでプログラム開発が出来た。ソースコードをなめ回し、ライブラリーを探し回り、ウェブで情報を求め、何度も門前払いを喰らいながら、やっとのことで動かしたことを考えれば、実にあっけない結果である。201409190004

 しかし、こちらはARMの開発を既に少しやっていたのでCooCoxのしたことが大体わかるが、初めての人が言われるままにサンプルソースからLチカを動かせたとしても、中身を理解することはこれではほとんど不可能だろう。

 Arduinoあたりはこれに徹しているので(情報の隠蔽化)、それはそれで良いのだが、ARMの直接の開発で、この方法が先まで全部通用するとは思えない。英語のマニュアルには、良く「今からやることを理解できてない人は、やってはいけない」という言い回しがあるが、こういう開発法は、これに反しているし、理解しないまま先に進んでも、いずれ挫折することになる。

 ちょうど目隠しされて歩かされるようなもので、所長のもっとも嫌うところなのだが、これだけ簡単にLチカが出来てしまうと、何ともはや、こちらを行くしかなくなってきた。OpenOCDのあの豊富なコマンドとメッセージに未練があるのだけれど、ここから出発するしかないか。

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

2014年8月29日 (金)

心電計プロジェクト:表示系工作の道のりは遠い

 心電計プロジェクトは、オシロスコープでやっとのことで心電波形を見ることが出来たあと、例によって一気に気が抜けた。さらに、珍しく仕事の依頼が来て久しぶりに調査データの分析をしたり報告書の下書きをしたりしていた。月末には、新しく加わった家族と一緒に何年かぶりの墓参りで関西に帰省した。電子工作をやる時間がない。ブログも一か月ご無沙汰だ。

 とはいえ、このブログは備忘録も兼ねている。年ごとに短期記憶力が失われているのは確実で、こうした記録は欠かせない。時々、日記やブログを読み返しては自分の現在位置というか立ち位置を確かめている。不思議なことに読むたびに何か安心する。みなさんはどうなのだろうか。

 ということで、少し脈絡に欠けるが電子工作を含めたこの一か月の出来事を時系列でご紹介する。

表示系のプラットホームにするARM基板が多すぎて困っている(8/1/2014)
 それにしても懸案の心電波形がオシロで見えた時は本当に感激した。プロジェクトの開始は6月初めだから期間としては2ヶ月経っていない。FPGAでフォトフレームを作ったときは画像が出るまで半年以上(7か月)かかっていた。それに比べれば短いけれど感動の大きさはあまり変わらない。

 今まで、とても手が出ないと思っていた生体系の微弱電圧をアナログアンプとディジタルフィルターで捕捉して、とにかくそれらしい脈拍波形を自作機器で捉えることが出来たのだ。この先は、脳波(EEG)計測や筋電流によるロボット制御などの道につながり、アプリケーションの範囲は無限に広がる。

 プロジェクトの次のステップは第4ステップの心電波形表示部の開発である。こちらは勝手知ったデジタル系なのだが、着手する意欲はすぐには生まれない。地下の工作ルームでやることと言ったら、両腕に電極を当てて波形を出るか確かめる再現テストだけである。よーし、何度やっても同じ波形が出る。間違いない、自分の心電波形だと悦に入っている。情けないことだ。

 手がすぐに出ない理由はもうひとつある。映像を出すCPUチップを何にするか迷っている。画像表示装置は、このあいだAitendoで2.4インチTFT液晶モジュール(2P-CP2401T-C ¥1650)を用意したが、CPUチップが悩ましい。

 BeagleBoneBlackや、RaspberryPiでは少し重すぎる。手慣れたAVR(先日、秋月で買ったMega1284あたり)が楽なのだが、mbedを含めたARM系のCPUの積み基板が手元に溢れているのでこれを消化しておきたい。

 というのも、このところのARM系マシンの進化の速度が激しく特に開発環境はちょっと目を離しているすきに完全な浦島太郎状態になってしまった。この機会に何とかキャッチアップしておきたいという目論見である。

 それは良いのだが、心配なのは手持ちの評価基板は数はあるけれどみな少々時代遅れになっていることだ。果たして最新の開発環境で動くのか不安である。部品箱にある積み基板の数々を棚卸してみた。

 まず最新(ここでは)のチップのF4discovery評価ボード(STM32F407)は、とんすけさんの例のAudio Visualボードになってしまっているので使いにくい。雑誌付録のLPC2388はFreeRTOSの実験ボードのままである。RasPiの導入でこのリアルタイムOS応用の意欲は失せているのだが、このボードには苦労して開発したLANポートが載っているので、これを無駄にしたくない。

 mbedも大分前にStar Board Orangeというマザー基板を手に入れてある(¥1400)。これにはSDカードスロットやLANのモジュラーまでついているので、心電計のようなスタンドアローンの機器にするのは勿体ない。

201408280002 F3discoveryという評価ボードもある。これも未使用だが、これには3軸加速度センサーがついており、これが無駄になる。さらにFM3、RX61などの32ビットプロセッサーも手つかずで余っているが、開発環境の整備を考えたら先が長くて手が出しにくい。

 というわけで、結局、候補として残るのは、昔、CQ-STARMと言われる基板から剥がしたSTM32F103チップだけである。これをAitendoの生基板(余分に買ってあった)につけて、これまで開発したグラフィック気圧計と同じ形にする。この石はフラッシュが128K、SRAMが20Kしかないのでちょっと不安だが、心電波形の表示くらいなら何とかなるだろう。

 それにしても、ARMの開発環境やプログラマーは、ちょっと見ないうちに大変化を遂げていて何から手を出せばよいのか見当がつかなくなっている。せっかく買ったOlimexのJTAGドングルは使えるのだろうか。ハードの工作よりこのあたりの開発環境の勉強の方が課題である。

Window7にしてAVR開発環境づくりにひと苦労(8/3/2014)
 心電図プロジェクトの合い間に、このあいだから始めていたメインPCのXPからWindow7への更新が片手間ではすまないくらい大変になってきた。このWindow7は仕事の友人からマシンごと無償で譲り受けたもので、CPUは少し古いがCore2Quad6600という4つもCPUを持っている高性能マシンである。

 いまどきWin7への更新の話をするなど笑われるだけだが、このブログをお読みの皆さんならご承知のように、所長は一旦うまく動いた環境は余程のことがない限り使い続けるのが基本方針である(問題なく動いている環境を変えるのは無駄以外の何物でもない)。いくらサポートが切れても、WinXPを止める気は全くなかった。

 それがどうして更新することになったか。理由は簡単で、使っているWinXPマシンが壊れてしまったからである。これまでのWinXPマシンは、Athlon64の自作なのだが、大分前からブート直後にマザーボードのCPU温度センサーが誤動作して警報ブザーで止まるトラブルがたまに起きていた。

 だましだまし使っていたのだが(立ち上がれば全く問題なし)、そのうちこの暑さでとうとうビープ音(ピーポーピーポーという間抜けな音)が何をやっても止まらなくなり、仕方なくWin7に切り替えた(チップの中の故障なので修理は殆ど不能と思われる)。

 最初は、XPマシンからDASD一式をこのWin7マシンに接続し、少しづつアプリケーションを移していたのだが、段々手がかかるものが出てきた。特に、AVRの開発環境は難航した。今まで何の不都合を感じなかったので、AVRStudioは4のままだったし、プログラマーも7年前にChaNさんから頂いたAVRSPだ。フラッシュが少ないので書き込み速度が少々遅くても痛痒を感じなかった。

Ws000001 AVRの開発環境もARMに負けずに大きな進化を遂げ、AVRStudioもATmelStudioと名前まで変わってしまっている。せっかくなので更新することにする。インストールは特に何ごともなく成功した。Look&Feelは全く以前と異なっている。しかし、ソフトの立ち上がりが遅い。調べてみたら昔、重いことで評判だったVisualStudioがベースになっているという。遅いはずだ。

 動作テストをする。プロジェクトの作成は順調に行き、コンパイルまで行った。prog_chrがないと叱られたのはご愛嬌でこれは数年前、ばんとさんが報告されていた。その通りにして無事コンパイルも成功した。

 しかしこのあとが大変だった。何と頼みのプログラマーAVRSPが動かないのである。このAVRSPは、Mega328が動かなかった時、BorlandのBCC5.5でコンパイルし直したものだ。DLPORTIO.DLLがないのでコンパイルし直せというエラーメッセージである。もう一度作り直す気力はない。

Ws000002 オリジナルを持ち込んでみる。こんどは「giveio.sys」がないと怒られる。ふーむ、ウェブ情報では、さすがにWindow7ではgiveio.sysはサポートしていない。あきらめきれず、サイトをさまよっていると、-pvオプションで動いたという報告を見つけた。オリジナルのreadmeには、このオプションはUSBでは死ぬほど遅くなるということなので試したことはない。

 しかしreadmeを読み返していると、pvオプションは、単に、ポートIOをAPI経由か、ダイレクトかを区別するだけのオプションに思える。それなら、レガシーのCOM1を通すのに-pv1とすれば、良いのかもしれない。早速試してみる(幸い、Win7マシンにはCOMポートがついていた)。

 あたったー、これだー。今までと全く変わりない速さで、AVRSPが動いた。プログラマーは純正のDragonも持っているし、そろそろAVRISPmk2を買おうかと思っていたのだが、その必要がなくなった。これはありがたい。

 AVRSPにこだわるのには理由がある。当研究所のAVRプログラムはAVRSPの機能を使ったUART、ISP-UART(と勝手に呼んでいる)を使ったシステムが多く、AVRSPが動かないのは、前のシステムを検証することが出来ないことになる。動かしておきたかった。

Window7で失ったレガシー機器(8/7/2014)
 FPGAの開発環境や、ARMの開発環境Eclipseなどは、ちょうど良い機会なので、新しいバージョンを改めてインストールしなおすことにしている。これは使うときにやれば良い。ところが、もっと重大な問題があることに気が付いた。

 これまでにもご紹介した通り、所長は年期の入った飛行機マニアで、PCのフライトシミュレーターの操縦用に、本格的な、ペダルと操舵ハンドルを所持している(最近はめったに遊ばないが)。これらの機器のインターフェースはUSBではなく、昔のサウンドカードに必ずついていたMIDIやゲーム機器とつなぐgameport(DSUB15ピンのアナログインターフェイス)である。

 MSの少し古いフライトシミュレーター(FS2004これが一番充実している)は幸いWin7でも順調にインストールが出来たのだが、このgameportのサポートが、WindowsVISTA以来、切れていることに今さらのように気づいた。フライトシミュレーターの醍醐味は、キーボードでは味わえない。

201408280001 USBで動く同じような機能を持った機器が売り出されているので、これを買えば良いのだが、前とほとんど同じ機能のハードをもういちど買い直すのはいかにも無駄で、そんなことはしたくない。

 最初、gameportとUSBとの変換アダプターがあると思って、ウェブで検索したら、日本ではもう売っていないが、アメリカのアマゾンで売っているのを発見した。喜び勇んで、アメリカAmazonの会員登録をして、これを買おうとしたら輸出禁止製品にひっかかった。

 フライトシミュレーター関係の機器は、どうも311テロ以来うるさくなっているようだ。あの時のテロリストはMSのフライトシミュレーターでジェット旅客機の操縦に熟達し、実機を簡単に操縦したと言われている。

 何かほかに手がないかウェブで探し回った結果、アメリカの好事家(日本人二世か、Daniel Kawasakiという名前)がハードのドライバーを開発して、Creative(サウンドカードの開発元)のフォーラム上で公開したらしいが、すでにリンクが切れ、現物を手に入れることはできない。

 Creativeフォーラムのメンバー登録までして、このドライバーの行方を追っかけたのだが、どうしても見つけられなかった。このほかにもサイドワインダーというMSのジョイスティックのゲームポートインターフェースをUSBに変換するマイコン基板の自作ページというのがウェブ上にあり、AVRチップ(Atmega32U4らしい)を使う。

 これにも強い魅力を感じたが、こちらの手持ちディバイスCH-Productの製品がこれで動くという保証は全くない。これもあきらめるしかない。とにかく、ここ暫くはフライトシミュレーターで遊ぶことが出来ない。残念である。

ARM基板に入れるUARTコンバーターの移設でまた道草(8/16/2014)
 心電計プロジェクトの第4ステップ、表示系の基板は、結局、一番古いSTM32F103(CQ-STARMについていた石)を、AitendoのSTM生基板(気圧計につかったものをもう一つ買ってあった)につけたものにする。これに最近買った2.4インチのTFTディスプレイを載せる。

 ぼちぼち、部品箱から基板やCPUチップなどのパーツを取り出し、制作の準備に取り掛かる。久しぶりのQFP100ピンのCPUのハンダ付けは順調にすんだ。実体顕微鏡の威力を見せ付けられる。この生基板にはシリアルインターフェースのRS232CソケットがついていてUARTドライバーのADM3202チップのパタンがある。

 部品箱には表面実装のADM3202の予備がなかった。必ず必要なインターフェースではないが空きのままにしておくのも何なので、買いなおそうと秋葉原に行ったら秋月がお盆で休みだった。千石でも売っていたが秋月の価格の2倍以上するので買わずに帰ってきた。

 こうなると意地になるのがいつもの癖である。SOPのADM3202なら以前RS232Cのブレークアウト基板を自作したときに使っている。これを強引にはずして、今度の基板に使うことにし、元のブレークアウト基板はストックのDIPのADM3202に付け替えた。相変わらずお馬鹿な工作である。

201408280003 ところが付け替えたブレークアウト基板が動かないのである。心電計のUARTでテストしたが動かない。UARTの接続はいつも送信か受信で大騒ぎするのだが(今度も間違えていた)、やっと動いたと思ったら、今度は初期メッセージだけが文字化けする。

 CP2102などのUSB経由では問題ないのに、このRS232C経由だと駄目なのである。納得できない。おかしいのはオープニングメッセージだけで、あとは大丈夫である。ほっとけばよいものを(滅多に使わない)、動かないとなると、(しかも字化けというのが気に入らない)どうにも気になって先に進めない性質(たち)である。

USI-UARTのバグを見つける(8/19/2014)
 ロジアナを持ち出して調べる。あれえ、送信の前に、TXラインに0.1μsほどのグリッチ(細いディップパルス)が出ている。これか。USBのUARTは無視するが、RS232Cではだめなのか。テストに使っている、この心電計のUARTは例の、USI-UARTである。ほっておくわけにもいかない。

Ws000000  プローブ点を増やして、このグリッチがどこで発生しているのか追求する。調べた結果、おかしくなっているところは何とUSI-UARTの部分ではなくメインプログラムのポートの初期化のところだった。

 PORTレジスターを設定したあと、DDRレジスターを初期化すると、一瞬、DDRレジスターの設定で、値が0になってしまうようだ。へー、こんなことってあるんだっけ。DDRの設定のあとPORTの初期設定をするようにしてグリッチはなくなった。

 これで字化けはなくなったはずとテストする。ところが最初は治ったのだが暫くするうちまた字化けが始まった。ふーむ、これではなかったのか。さらに、しつこく調べる。

 その結果、やっと原因をつきとめた。原因は別のところだった。ロジアナの波形を詳しく調べていて、初期のデータのボーレートパルスが規定より長いことに気付いた。USI-UARTのボーレートはしっかりしたタイマー割り込みを使っているので長さが変わることはないはずなのだが。

 う、待てよ。一文字送信関数では送信バッファーにデータをセットするところは、タイマー割り込みで動くデータを取り出すルーチンとの衝突をさけるため、割り込みを禁止にしている。そうか、この期間が長すぎればタイマー割り込みは待たされてボーレートが長くなってしまう。

 ロジアナで、送信関数の割り込み禁止区間にポートを叩くテストステートメントを入れてチャートをとってみた。見事な波形が出てきた。初期のメッセージが大量にあるときは、ボーレートの1ビットの間に沢山の送信リクエストが集中し、決められたボーレートの20%以上の長さになっていることがわかった。

Ws000003 原因がわかれば、対処はやさしい。割り込み禁止区間をなるべく短くなるように区間を分ける。今度の場合は2つに分割するだけで、見事にUARTは字化けしなくなった。いやあ、快感である。これだから電子工作はやめられない(このUSI-UARTのソースは公開しているので、もう少しテストをして近いうちに改善版をリリースしたい)。

帰省と久しぶりの仕事でプロジェクトが進まない(8/25/2014)
 電子工作がペースに乗りかけたところでまた邪魔が入った。何年ぶりかの仕事である。政府関係の大型汎用機システムの調査で、NDA(秘密保持契約)があるので、詳細をここで書くわけにはいかないがこれが滅法面白い。昔とった杵柄(きねづか)で心が躍る。

 数値をみては対数グラフにデータをプロットして、全体を確かめていく。仮説にもとづいて、思っていたようなデータが並ぶと、デバッグに成功したような快感を覚える。やっぱり本業(雀の涙のような報酬らしいが)の方が細かい作業をしていても充実感がある。まあ、これは仕方がないか。

 それが一段落して、月末には車で久しぶりに関西に帰省した。目的は、このところさぼっていたお墓参りである。ここ数年で娘たちが結婚し、その連れ合いも同行して4年ぶりの墓参りとなった。新幹線にしなかったのは、現地での足の便と、第二東名を走ってみたかったためである。

 第二東名は140km/hが設計速度ということで、これは実際に走ってみて実感した。実に快適である。ハコもの行政が問題になる以前の着工で、民主党政権時代には過剰投資が問題となったもののひとつだが、走っているだけならこんな快適なことはない。払った税金を取り戻しているような感じで余計気分が良い。

 関西の道路状況も何年か車で走っていなかったこともあって、ずいぶんと進んでいた。京都大阪の間の交通事情は何年か前は、高速は名神一本だけで常時渋滞だったのだが、京滋バイパスや、第二京阪バイパスなどの開通でとても楽になっている。

 墓参りは、気になっていた親戚(世話になった義兄)のところもすませて満足して帰ってきた。しかし、お盆をはずして日程を組んだのだが、帰りは事故が重なった意外な大渋滞に巻き込まれ(沼津の第二東名分岐点あたりから海老名まで連続60キロ近く)、8時間以上かかってしまった。

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

2014年7月26日 (土)

心電計プロジェクト:DACのMCP4726でオシロに波形が出た

 前回のブログ記事から20日以上も経ってしまった。それにしても今回の心電計プロジェクトは予想以上に難航している。遅れたのは他にやることがあって時間がなかったこともあるのだが、それでも、やっとのことで心電波形をオシロで確認することができた。これでステップ3の終了である。

201407240009  うまくいかなかった原因は、いつもながら、わかってしまえば、なぜこれに気が付かなかったのかと思うばかりの下らないミスである。まあ、これが面白くて電子工作をやっているようなものだが、それにしても動かなかった時の暗澹たる気分がまだ頭に残っている。因果なものである。

 負け惜しみになるが、こんなものでも問題解決のケーススタディとしては役に立つかもしれない。ともあれ以下はこの20日余りの顛末である。

DAコンバーターを変換基板につけてデータシートを勉強(7/2/2014)
 身体から取り出した微小な電圧をアナログアンプで増幅し、それをAVRマイコン(Tiny861)のADコンバーターで数値化し、デジタルフィルターでハムノイズを除去した。そこまでは良かったが、数値データをグラフにする手間がかかって繰り返しテストができない。

 そこで、DAコンバーターで数値を再びアナログに戻し、オシロで波形をみようと(ロードマップではステップ3)、秋月電子で最近売り出されたDAコンバーターMCP4726を買ってきた。 1チャンネル、12ビットのDACで値段も安い(2ケで¥180)。ディジタル側のインターフェースはI2Cである。

 MCP4726には詳細なデータシートがついているが、ウェブには使用例がどこにも見当たらない。I2Cインターフェースはこれまで色々使っているので何とかなると思うが不安は残る。まあ、人柱になるのもたまには良いだろう。

201407240010  まずはデータシートを慎重に読み込む。マイクロチップ社のICなのでやたら丁寧なデータシートである。86ページもある(職場の裏表印刷のプリンターでやっと印刷)。O-Familyさんのように翻訳してあげれば喜ばれるのだろうが、そこまでの気力がない。

 それにしても、たかがDACなのになぜこんなたくさん機能があるのだろう。I2Cでデータを受け取ってアナログ電圧に換えるだけにしてはEEPROMまでついている。何のためなのか。

 ひととおり目を通しただけで、全部を理解したとはとても言えないレベルだが、単に数値データをアナログに変えるだけのオペレーションならそう難しくはなさそうだ。

 EEPROMの使い道はまだ良くわからない。判然とはしないが、電源断を含む運転を想定していて、前の値を保持しているだけのようだ。コマンドが沢山あって色々なことが出来そうだが、当面は関係ない。ディバイスのアドレスは出荷時に固定で、あとからは換えられない。

 データシートには具体例があるので、数値入力12ビットをアナログ化する手順だけなら間題ない。1ブロックを27ビットとし、頭1バイトをI2Cのマスター書き込み宣言、続いてデータバイト2バイトを送る。それぞれのバイトのあとにACKビットが1ビットづつ付くので計27ビット分を送ると、ディバイスはアナログ電圧をラッチする。

 リニアPCMプレーヤーのミニLCDを動かすのに使ったI2Cライブラリーを持ち込む。これはChaNさんがFatFSのモニターの中でタイマーに使っていたGPIO版を移植したものだ。そっくりソースコードでプロジェクトに放り込み、必要な機能だけを絞っていく。

 沢山、LCD用の関数があるが全部取り除く。I2Cのクロックは、625μsのサンプリング期間に27ビットが送り終える速さにしなければならない。ビットレートを100khz程度で、30ビット->300μsで送れるようクロックを調整する。

I2CインターフェースのDAコンバーターは動いた(7/7/2014)
 Tiny861を載せたブレッドボードの横に、MCP4726を載せて配線する。6ピンしかないので接続はいとも簡単だ。どんな波形が出てくるかわからないので、最初からロジックアナライザーをI2Cの端子、SCL、SDAにつないだままテストに入る。

 おーし、出てきた出てきた。スタートコンディションは出ているようだ。ロジアナのプロトコルアナライザーを早速入れてコードの解析に入る。うむ、これまでUARTに出力していた数値らしい値が送られている。ただ、ビットレートが100Khzにしては遅い。625μsのサンプリング期間を超えてしまっている。

 ロジアナの波形をさらに分析する。どうもクロックSCLのDuty比がおかしい、ソースコードをチェックする。おやあ、delayコマンドが沢山入っているなあ。データを送るところや、スタートコンディションを作るところに無駄と思われるdelayが入っている。

 ミニLCDのときは速度に十分な余裕があったので神経質になっていなかったが、今度はシビアなので、このあたりは直さないといけない。delayコマンドを少しづつ減らしてロジアナでチェックする。余り減らしすぎるとSCLクロックがおかしくなるので慎重に減らしていく。

 何回かのコンパイルで27ビットの送信は、サンプリング期間に収まった。これはもう動いているだろう。ロジアナでの出力はバッチリだ。出力ラインをオシロのプローブにつけて本番実験開始である。

 おやあ、出てこない。入力は完全なのに。あっあっあ、そのピンは出力ピンではなくてVrefピンだ。6ピンしかないピン配置を間違えている。あせるとろくなことはない。気持ちを落ち着けてジャンパーを付け替える。 Mcp4726_i2c

 出てきた、出てきた。それらしいアナログ出力が出てきた。アナログアンプの入力端の操作で上下する。しかし、心電波形らしい波形は全くでてこない。ただ、直流が出るだけ。オシロを2現象にして、アナログアンプの出力と、DAコンバーターの出力を調べる。

 DACは完全に動いているようだ。見事にハムノイズはとれているが、肝腎の波形が出てこない。ハムノイズのレベルに合わせて基線部分は上下するが(これがUARTに出した時に見た脈流だろう)、心電波形らしい鋭いパルスはどこにも見当たらない。ディジタル部は問題ないが、やはりアナログアンプの問題に戻ってきた。

 アナログアンプは、あれから進展はない。相変わらずハムノイズの嵐で心電波形らしいデータはまだお目にかかれない。どこを直して良いのかわからないのだ。暗礁に乗り上げたままである。

音楽教室おさらい会とワールドカップで電子工作はお休み(7/14/2014)
 そうこうするうちに一年に一度の音楽教室の発表(おさらい)会が近づいてきた。所長は、中断もあるが足掛け何十年と楽器(フルート)を同じ先生から習っている。先生のお年はもう75 才、レッスンというよりお年寄りの茶飲み話仲間のようなつもりで教室に通っている。

 ここでは、一年に1回か2回、生徒(全部大人か年配者)を集めた仲間内の発表会を開く。半年がかりで課題曲を仕上げていくのだが、前にも書いたように、この発表会というのが麻薬性の強い行事なのである。誰かに聞かせるわけでもない、単なる仲間内のおさらい会、勉強会という位置づけなのだが、これがなぜかはまる。

 プロになるわけもないのに、先生からは容赦ない指導が加わる。今さらうまくなるわけがないのだがこちらにも意地というものがある。一生懸命にさらう。そのかいあって始めはたどたどしかった曲が、音楽らしくなってくると嬉しいものである。しかしあとで録音を聞くと大抵がっかりする。

 何度さらっても、うまく行かないところがある。音程やリズムもおかしい。先生は、「なぜこんなところではずれるのか信じられない」などと嘆かれると、いくら本当でも、正直、気分が落ちこむ。

 しかし本番は容赦なく近づく。練習が気になって、電子工作はすっかり手が付かないでいる。というのも昔々、発表会でかなりうまい人が、突然あがってしまい最初から最後まで音が出なくて、みんなでじっとうつむいて曲が終わるのを待っていたという恐怖の経験がある。そうならないよう必死に曲を繰り返し練習し、最低限の音はでるようにさらっていく。

 本番である。これまでの練習の成果が試される時だ。何のために何ヶ月も同じ曲をさらってきたのか。これまでの投資が実を結ぶかはすべてこの演奏で決まる。所長は血液型がB型なので、ようするに「安定した不安定」である。吹いてみるまでわからない。

 あがっていないので気分よく吹いていると、不用意なミスが続いて自滅に近い結果になるときがある。そうかと思えば、ガチガチに緊張していても、なぜか調子が上がってきて練習以上にうまく吹けるときがある。

 細かいミスを気にしないで、耐えて吹いていると知らぬうちに難しいところが通過できる。あがってしまうとだめだが、あまり冷静でもかえってうまくいかない。このあたりの回復力は、何と言っても練習量で決まる。だから練習はさぼれない。

 今回は、まあまあで、70%の出来か。電子工作のデバッグは、解決しないと勝利の美酒を味わえないが、演奏は終りさえすればあとは極楽である。ドーパミンがたっぷり放出され、本人は数日は幸せな気分にひたれる。恐らくマラソン完走のあとの解放感と同じである。

 1ヶ月くらいは、楽器をケースから出すのもいやなくらいだが、そのうちいつのまにか取り出して吹いている。そして数カ月もすると、次の発表会の曲の選定がやってくる。あんなに苦しい目をして練習し、会場費やピアニストの謝礼に高い出費をしているのに、なぜかまた発表会に出る気になる。不思議なものである。

アナログアンプ不調。あきらめるか(7/18/2014)
 発表会とワールドカップでとられていた時間が電子工作に戻ってきた。アナログアンプのトラブルシューティングである。両腕からとった微弱な心電波形をノイズの中から拾うにはどうしたら良いのか。

 いろいろ手を尽くしたが、すべてうまくいかない。まずノイズ自体が大きすぎる。ディジタル系をつなぐと電源を入れなくても出力ラインには盛大なノイズがでる。それに20Khzあたりの細かいノイズもあらわれ、これはオペアンプの発振が疑われる。オペアンプをLM358から、LPCMプレーヤーに使ったNJM4580などに換えてみるが事態は改善されない。 201407260011

 DACはうまく動いているようだが、オペアンプの出力がべた(クリッピングされた)な矩形波なのが気に入らない。心電波形がすべて隠れてしまっているのではないか。増幅率が過大で、ノイズと心拍波形が上限を越えれば、ノイズフィルターそのものも動かないはずだ。

 というので、前段の計装アンプ部と、そのあとの増幅部(LPF付)に半固定のVRを入れて増幅率を可変にしてみた。抵抗値を上げて増幅率を落としていくと、矩形波のハムノイズはちゃんとした正弦波に戻った。しかし心電波形らしいものはどこにもあらわれなかった。ウェブの資料では心電波のR波(一番鋭いパルス)はノイズを突き抜けて観測されているが、ここにはそれが出てこない。

 理屈が良くわかっていないので、原因究明の方向が見えないのである。ハムノイズを軽減する方法がわからない。アースなどをつけたり、シールドケーブルを使ったりするのだろうが調べた限り、心電計でこういうことをしている例はない。

 助けを求めてウェブをさまよう。あれから「心電計」だけではなく、「心電計 回路図」で検索すると、以前より多くの回路例を見ることができた。いずれもLM358のような廉価版のオペアンプではなく、高額な計装アンプなどを使った例が多い。やっぱりLM358ではだめなのだろうか。

 段々自信がなくなってきて、仕事の帰り秋葉原に寄り、秋月電子で1ケ¥400の計装アンプLT1167や高精度オペアンプLT1112を買ってしまう。このまま引き下がるのは悔しい。2台目を作ろうという算段である。

201407220001 何のことはない。電極をしっかりつけたら波形が出た!(7/23/2014)
 それが、2台目の制作にとりかかろうとした矢先、解決してしまったのである。あてもなくオシロに電源を入れ、べたな出力電圧を漫然と見ていた時だ。何となく一秒ごとの小さなパルスが画面に出ているのに気が付いた。

 ふーむ、雑音にしてはパルスの出方が周期的だ。これは何だろう、試しにオシロのDCカップリングをACにして、感度を上げてみた。おおー、これは心電波形だ。間違いない。腕に付けた電極を動かすと波形が飛んでしまうが、暫くするとまた波形が戻ってくる。

201407230006  半固定抵抗を動かして増幅率を変えてみる。腕を動かすと波形が乱れるし、筋電流が出るということなので自由には変えられないが、増幅率の大小は関係ないようだ。リップルが矩形波になっていても関係ない。

 腕を机の上でなく、座っている膝の上まで降ろすと波形はさらに強くなった。これは間違いなく心電波形だ。一番鋭いR波だけでなく付随したS波など他の波も見える。1divを100mVまで上げるとくっきり心電波形が見える。

 いやあ、感動である。念願の心電波形である。自宅のオシロで見えている。調子の良い時だと、300mV P-PのR波(一番鋭いパルス)が観測できる。要するに、電極をしばらく当てていると、波形が強くなっていくのだ。

201407230007_2  嬉しくて、家族を久しぶりに工作室に誘い、彼女の心電波形も見てみた。皮膚抵抗が違うのか、夕食のビールのせいか簡単に心電波形が出てきた。やれやれ、何をやってもうまくいかず、あげくにもう一台別のアナログアンプを作ろうとした直前に動いてしまった。

どうしてこれがわからなかったのか分析する(7/25/2014)
 気持ちが落ち着いて、今回のトラブルの集約をしてみる。要は、電極を完全に皮膚に密着させていないことによる入力電圧不足である。実に簡単な最初にチェックするべきポイントである。何故これに気がつかなかったのか。

 人のせいにするには気が引けるが、まず参考情報にこうした注意がなかったのがここまで迷走した原因であることは否めない。銅やアルミは接触部で電気化学反応が出るのでステンレスにしなさいとはあるが、十分皮膚と密着させなさいとはどの資料も書いていない。

 次は、自分が慌て者なので、電極を付けて反応がないと次々に電極をずらして様子を見ていたため、波形を見落としていたこともあるだろう。皮膚と電極の間の接触抵抗は、どうも変化するらしく、暫く同じ個所に密着させていると抵抗が低くなっていくようだ。

201407230008  さらに、1.5mV P-Pの元の心電波を1000倍近くするのだから、DAコンバーター出力は、1V近く振れるはずという思い込みがあった。そのためオシロのDCカップリングでなくACカップリングにして感度を上げるということに思い至らなかった。

 考えてみたら、最初のアナログアンプ出力は、2.54V P-Pだが、ディジタルフィルターのAD変換とDA変換で単位が大幅に変わって来るので、パルスは倍率通りにはならない。調子の良い時は、アナログアンプ出力でも、R波のピークが観測でき、そのときのP-Pはスペックどおり1.5Vを超えているのだ。

 何度も再現テストをして、心電波形がオシロから出ることを確認した。いやあ、苦労したけれど、心電計プロジェクトは難関を突破した。サポーターをもう少しきつくして電極を皮膚に密着させるようにすれば、つけて10秒後には間違いなく波形が出てくる。

 これで、心電計プロジェクトは、次の映像化ステップに移ることができる。こちらは得意のディジタルなので先行きは明るい。I2CのDAコンバーターのソースコードライブラリは、全部が終わってから公開するつもりだが、もし要望があればまだ半かけではあるが、いつでも公開できる。

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

2014年7月 2日 (水)

心電計プロジェクト: ディジタルフィルターまで動いたが

 心電計開発のロードマップは出来た。今回のプロジェクトは、高精度アナログアンプにマイコンを使ったディジタル数値処理、それにTFT液晶などの描画ソフト開発と多彩なステージがあり、楽しみが多い。

 まずはステップ(1)の、心臓からの微弱電圧を拾うアナログアンプの開発である。参考サイトには、いくつかの回路図が載っているので、制作上の不安は少ない。アナログなので、ブレッドボードではなく直接、汎用基板に作っていくことにする。

 調べたところでは、少なくとも3種類の定数値付きの回路図(ここが2つここが1つ)が見つかっている。いずれも特に難しいことはしていないし、実装上の問題もなさそうだ。なかでも雑誌にも掲載されているここのサイトの回路は、LM358という廉価品のオペアンプを使っている。

 他の回路図は高価な計装アンプなどを使っていて、その入手が難しい。迷わずこのLM358の回路を使わせて貰うことに決めた。電源は、このあいだ千石で買ったジャンクのリチウム電池を使う。容量、電圧とも丁度良いサイズだ。

アナログアンプは出来た。しかしノイズだけで波形の検証はできず(6/13/2014)
 3日かけて久しぶりの汎用基板のハンダ付けを楽しんだ。今回は慎重に、出来た部品面のアートワークをスキャナーでとりこんで反転させ、ハンダ面のアートワーク図も作る。CR部品が多く、アートワークは結構複雑だ。Blg_p6116529

 LM358のような汎用オペアンプで、生体系の微小電圧を増幅できるのか半信半疑だが、まさか動かない回路図が雑誌に載ることはないだろう。動くことを信じてせっせとハンダ付けする。UEW線は殆ど使わない。CRのリード線だけで接続する。

 ちょっと工夫したところは、各オペアンプのVccにつけるパスコンをチップ部品にしたところか。なるべく実装をコンパクトにしようと思いついたのだが、本当は手持ちの0.1μFのセラコンがちょうど在庫切れになっていたという事情もある。

 全部組みあがったところで、最後のボルテージフォロワーの入力に並列に入れる2000pF(1000pF×2)のコンデンサーを忘れているのに気づいた。かなり密集して実装したので、部品一つでも追加するのが難しい。やむを得ずリード線一本だけを表側に通して配線を終了した。

 くだらないけれど、こういうチマチマとした工作が何故か好きである。何もそんなにこだわらなくても良いと思うのだが、自分で配線ルール(UEW線でも交差させない、可能な限りハンダ面で解決、保守性を考慮するなど)を作って、その制限のなかで目的を達成するのが楽しい。Blg_p6166539

 ハンダ付けするところがなくなった。アナログアンプの完成である。何度も配線チェックをしてから通電テストに入る。ここの検証は簡単ではない。最初は、商用電源のノイズが重畳した出力が得られるだけなので正常に動いているかどうかは、次のデジタルフィルターの完成まで待たねばならない。Blg_p6166531

 それでも折角出来たのだから、オシロで波形を見ることにする。心電計の身体接続部はまだ作っていない。とりあえずリード線の先端の銅を出し、手首や足首にまいたハンカチの隙間に押し込んで、テストする。 予想通り、盛大な50Hzパルスが出るだけで、心電波形らしいものは全く見ることは出来なかった。まあ、増幅はしているようだから、これはこれで良いとしよう。

デジタルフィルターのマイコンの準備(6/17/2014)
 サッカーのワールドカップが遂に始まった。日本とコートジボアールの初戦は惜しかった。本田の先制ゴールで心のどこかに「守り」の気持ちが出てしまったのだろう。岡田元監督もTVで言っていたが、ドロクバが入って相手チームの雰囲気が明らかに変わったのに単調に「守って」いたところを前がかりになられて簡単に点を取られた。

 まあ、4年に一度のワールドカップは世界中で32チームしか本大会に出られない。連続して出場しているだけでもたいしたものである。大会前日本に完敗したコスタリカが、強豪ウルグアイを破るという番狂わせがあるのもワールドカップである。奇跡を信じて応援していこう。

 電子工作の話に戻る。とりあえずアナログアンプは動いているようだ。サンプリングを短くすると、頭の切れた50Hzがもろにトリガーされて出るだけ。周期を長くすれば、参照サイトにもあるように50Hzの嵐で心電波形は全く隠れてしまっている(のだろう)。

 ただ、サンプリングを1秒程度にすると、50Hzがはずれて何となく心電波形らしいものが出てくるところがある(写真参照)。しかし、こんな交流波形を見ているだけでは埒(らち)があかない。アナログアンプはこれくらいにして、デジタルフィルター制作のステップ(2)に進んだ。

Blg_p6166530  ブレッドボードにデジタルフィルターのマイコンを準備する。石は、ADコンバーターを持っているTiny861を選ぶ。クロックが悩ましい。今度のフィルターは、商用電源の周波数(関東では50Hz、関西は60Hz)の周期にぴったり合わせてサンプリングをする必要がある。

 参照サイトでは、32段階のFIFOを採用している。始め、なぜこの数を選んだのか良くわからなかったが、ロジックを調べているうち謎が解けた。2バイト演算の最大数に合わせているのだ。ADコンバーターの分解能を10ビットとすると、数値の範囲は、0から1023になる。1サイクルの合計値を計算する必要があるので、32×1024=32767で、符号付2 バイト整数を使うのなら、これでピッタリである。

 マイコンのクロック周波数は、50Hzのフィルター精度をなるべく高くするため正確な625μs(20/32ms )のサンプリング間隔が作れるように決める必要がある。タイマーのプリスケール値は設定できる値が限られているので注意が必要だ。色々調べた結果、部品箱にあった、7.372Mhzのクリスタルが一番有効になることがわかった。

 この石は、以前正確なUARTボーレートを出すために買ってあった石で、これを使うと、プリスケールを32にすると、144tickでぴったり625μsになる。またUARTは192の分周で38400bpsのビット幅に誤差0%で入る。

家具固定のL字金具で電極を用意したり、ディジタル部を開発したり(6/20/2014)
 近所のホームセンターでステンレスの電極を見つけてきた。家具の固定などに使うL字ホルダーだ。結構な値段(一本あたり¥200)がする。3本いる。電極には圧着端子をつけたコードをつなぎ、コードの先はテスターで使うミニジャックをつける。ミニジャックとソケットは、秋葉原駅下のラジオセンターで赤黒以外の端子を見つけた。青、黄、緑など沢山の色があった。

Blg_p6166532  作ってみると、例の雑誌の写真に出ている電極と全く同じ形だったのに苦笑する。体につけるサポートはマジックベルトを考えたが、結局、テニスのリストバンド(汗取り用)が沢山余っていたのでこれを流用した。足首につけるのがちょっとつらい。

 このあと、たまたま立ち寄ったスポーツ用品店で足用の適当なサポーターを探した。しかし安価なサポーターはみんな輪状で、マジックベルトのようにはがせるようなものは、何故かとんでもなく高価(¥2000以上)なので、買うのをやめた。まだ動かないのに凝るのはよそう。

Blg_p7026542  ミニジャックのソケットを、雑誌記事と同じように基板にハンダ付けして仮止めし、アナログアンプの方はだいぶさまになってきた。ブレッドボードに載せたTiny861は、動いてからこの基板の残っている部分に実装するつもりだ。

 ディジタルフィルターのソフト開発に入る。当研究所ではスクラッチからソフトを書き出すことは滅多になく、これまでに開発したコードを流用することが多い。今度もタイマー割り込み駆動のプログラムの中から、アクリル曲げ器に使った熱電対温度制御部を選んだ。こいつはADコンバーターを使っているので好都合だ。

 新しいプロジェクトを作り、そこへ、そっくり前のソースを持ち込んだ後、これを頭からどんどん換えて作っていく。ディジタルフィルターの数値出力は、UARTでARMなどの表示系(ステップ4)に送ることになるが、とりあえずはキャラクターに直し、PCのUARTコンソールに出力させる。

 UARTの出力速度は、サンプリング周期より遅いので、このあたりはバッファー付きの送信関数でないと、まともに表示がされないだろう。おあつらえむきにこの前作ったUSI-UARTが役に立ちそうである。

デジタルフィルター(ステップ2)は動いているようだ(6/21/2014)
 擬似コーディングは、プログラムが似たような構造なので簡単に終わり、コードの開発は1日もかからなかった。問題はUART出力をどのタイミングでやるかである。UARTにフィルターの出力を出すとき、625μsのサンプリングの度に、3桁のキャラクター(38400bpsで621μs)を連続して出力することは無理だろう。

 とりあえず、32段のFIFOが1周するたびに一回、UARTを動かしてデータを出すことにする。これくらいなら全く問題がない。USI-UARTのお陰で万が一、次の割り込みにかかっても系を乱すこともない(はずだ)。

 ソフトが出来上がったので早速テストに入る。と、これが全く動かない。このあとの紆余曲折はいつものことなので端折るが、結局、何とか動くまで3日もかかってしまった。まあ、それにしても、いつもながらの大騒ぎである。プログラムはまさしく考えたようには動かず書いたようにしか動かない。まずは超初歩的なミスから。

(1)USI-UARTは独立したシリアルラインを持っている。それに気づかず、いつものISP-UARTだと思ってファーム書き込み後ISP書き込みモードにしたまま動かないと動かないと騒いでいた(ISP-UARTは、書き込みモードで動く)。

(2)FIFOバッファーのオーバーフローに気づかず、暴走を繰り返す。1バイト違っていただけだが。

(3)タイマーのプリスケールの設定が全く違っていて、とんでもない値と原因不明の暴走。

始めは不精してオシロで全部片付けようと思ったが、UARTが出るところまでなら何とかなっても暴走は歯が立たない。すぐにロジックアナライザーの登板を仰いだ。ロジアナはやはり強力で、上記(2)以降のトラブルは雲散霧消した。始めからロジアナを使えばよかったのだ。

 まだ、データのないとき文字が化けるときがあるが、何とかPCのUARTコンソールにデジタル出力の数値が連続して出るようになった。PCのリターンキーで出力を開始し、次のリターンキーで表示を止める。

Uartdata

 PCのコンソール画面上に、数値データが並ぶので、それを画面上でコピーし、エクセルのデータにとりこみ、折れ線グラフにする。おおお、出てきた出てきた。50Hzのハムノイズはすっかりとれて、なにやら1秒に一回程度の波があらわれた。

 現在のUART出力は、サンプリング値を全部表示するとバッファーがオーバーフローするので、32段に一回だけの表示でカーブが緩いが、周期からみて脈拍の波に違いない。感動の一瞬である。

Ecgbest

 ただ、波の基準値が一定していない。それに波形も綺麗に出るときと出ないときがある。アナログアンプを調整したいが、エクセルのグラフに出すまでの手順が厄介なので、アナログの方をいじるわけにはいかない。それにUARTがまだ不安定で、表示が時々字化けするのを止められない。

ロジアナでUARTの字化けも解決。デジタルフィルターはこんなものか(6/23/2014)
 ロジアナで本格的なデバッグに入る。ADコンバーターを動かすところ、USI-UARTの送信関数の出力、さらにUSIのボーレートカウンターなどにプローブ点を設置し、ロジアナで動きを観察する。

 プログラムは凡そ考えたとおりに動いていた。ADコンバーターは着実に625μs単位にデータを取得しており、UARTの送信関数も一瞬のうちに処理を終えている。このあとUSIの4ビットカウンターの割り込みで実際にデータが送られていくのだが、これも間違いなさそうだ。

Digftr

 しかし、字化けしているときは、タイミングが合っていてもUARTの送信データの方がまるまる汚れて出ている。文字をシフトレジスターに入れるときにおかしくなっている。となると考えられる原因は、データをシフトレジスターに入れるタイミングと、送出するときの衝突である。

 あらためてソースコードを眺めてみた。cli()とsei()で割り込まれるのを防止している送信関数の範囲は、データバッファーのカウントを換えるところだけで、実際のデータをバッファーにセットするところは割り込み禁止になっていない。

 データバッファーに入れるところで衝突しても、送出時はそこは関係ないので問題ないはずだが、どうもここがくさい。直すのは造作のないことなので、試しに、この部分も割り込み停止にしてみた。

Blg_p7026546

 なんと、これで直ったのである。アナログアンプの電源が切れていても(このときが字化けが多い)、全く問題なし。延々とデータを出してもきっちりデータを出力する。字化けは完全に解消した。

 データをいくつかとる。みんな1秒に一回程度のパルスを捕らえている。ただ、基本電位が安定しないし、だいたい波形が心電図らしくない。原因は20ms間隔でデータをとっているからだとは思うが、正弦波的な波形で、いわゆる心電波のいくつかの特徴的な波が出てこない。

 これ以上のUARTでの測定は面倒なだけで進展が遅い。そろそろ別の表示法を考える時期のようだ。DACを使うか。32ビット系のTFT液晶に向かうか、迷うところである。DACを使って、オシロの2現象で比較したいところだが、早くTFT液晶でまともな波形を出したい気分もある。

20ms単位の表示では心拍の波形は表現できない?(6/25/2014)
 ぐずぐずしている間に、サッカーのワールドカップでは日本が負けてしまった。結局2軍のコロンビアでも全く歯が立たなかった。今から思い返せば、あの初戦の前半であげた本田の先制ゴールがすべて仇になったように思う。

 一瞬、世界のトップレベルになったという錯覚がメンバー全員に行き渡って我を忘れてしまったのではないか。日本はまだ、そんなレベルではない。必死にボールに喰らいついて、がむしゃらに点を取りに行かなければ行けないのに、ついその気(一流のつもり)になってしまったのではないか。それくらい、あの本田のゴールは素晴らしかった。

 まあ、それはともかく電子工作である。どっちにするかまだ迷っている。もういちど参考情報を熟読する。採集方法は間違っていないようだ。波形図を見ると100HzくらいのR波が出ているが、この波形は確かに20ms単位では正確な値は表示できないはずだ。

 1秒間だけ精密な波形を出力する方法も考えてみる。せっかくUSI-UARTを採用してデバッグに苦労したのだから、もうすこしこの方法もやってみたい。

 しかし、サンプリングを1/8の4ms間隔にしても変わりがなかった。今度は取得データ範囲が短くなるため、波形の把握がかえって出来なくなる。難しいものだ。どうもアナログアンプもおかしいのかもしれない。もう一度、念入りに回路図を調べ、基板の配線を確認するが間違いはなかった。

DAコンバーターを買ってきた。人柱になるか(6/27/2014)
 雑誌記事の写真を見ていると、フィルターをかけるまえの商用電源のノイズに入った波形には、心電波形のいわゆるR波(一番鋭いピーク)はノイズの上を超えて観測されている。一方、こちらの補正前の波形には、これが見られない。

 色々アナログアンプをいじる必要があると思うが、現在の手順では沢山データを取るのに多大な労力を要する。といって、ARMの表示系を実現するには、まだかなり道が遠い。色々迷ったが、結局、以前寄り道と考えていたDAコンバーターを使ってアナログにし、オシロで調べるのが一番早道のような気がしてきた。

 手持ちに12ビットDAコンバーターがあったはずだ。部品箱を漁る。しかし急には見つからない。出てきたのはオーディオ用の16ビットのDAコンバーターだが、こんなことに使うには抵抗がある。BU3616というビデオ用のDAコンバーターは8ビットパラレル入力で話にならない。

 確か以前、秋月で買ったと思っていた12ビットコンバーターを部品箱の底から、やっとのことで見つけた。何と、こいつはDACではなくてADコンバーターMCP3204だった。完全な勘違いである。やれやれ。

 仕方がないので、手頃なDAコンバーターチップを入手することにする。秋月のサイトを覗く。MCP4726*というI2Cインターフェースのチップが安価で良さそうだ。ただ、これを使った参考例が、全くウェブ上では見つからない。

 データシートは、マイクロチップ社製品らしく、懇切丁寧な(14Mbytesもある)PDFがあるので何とかなりそうだが、使用例が見つからないのは痛い。まあ、人柱になるのも良いか。先日、秋葉原に立ち寄って現物を入手した。

Blg_p7026541  ブログの更新が滞ってきたので、このあたりで報告することにする。さあ、この寄り道がどうなるか。

(* 修正済み 以前7026と誤記。失礼しました)

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

«次の工作プロジェクトの模索、心電計の開発へ