トップページ | 2008年9月 »

2008年8月の20件の記事

2008年8月31日 (日)

LCDを待ち時間なしで動かす

電源逆差しでRTCがお亡くなり(5/11/08)
 SDカードのプロジェクトが一段落したので、工作室を整理しながら、今までやり残していた作業を少しづつ始めている。電力ロガーのセンサーの出力がACであることがわかっていたので、ブリッジダイオードでDCにして手元にある電気機器を測定したり(これが意外に直線性が悪く補正が必要か)、遊びに買ったLEDマトリックスのトランジスタアレイ(TP62083)の定格を調べて、基板の構成を考えたりしていた(最終的には4文字くらいの電光掲示板にしたい)。

 先の話はともかく、前から気になっていたのが、I2Cを使ったLCDドライバーで表示しているデジタルクロックである。1秒タイムアウトですっかり丈夫になったドライバーだが、一晩置くと、表示が止まっていたり、2行ダブって表示されたり、まだ実用レベルとは言いがたい状況である。LCDの表示がダメなのか、I2Cが空振りしているのかわからない。

 UARTをつなぐと何事もなく表示が始まるので、デバッグの手段が見つからず放置してあった。懸案が片付いたこともあってアイデアが浮かんだ。そうだEEPROMにログを記録しておき、それを後から見れば良い。幸いメインチップはTiny861なのでフラッシュは余裕があるし、EEPROMは512バイトもある。節目でデータを書きタイムスタンプを書き込んでおけば直前の状況がつかめる。

 思いついたら実行に移さないと気がすまない性分である。早速、奥に置いてあったLCDデジタルクロックのブレッドボードを取り出し、秋月で買った3個めのRTCモジュールを差して久しぶりに動かす。問題なく動く。AVRstudioのプロジェクトをLCDのメインに移し、eepromのルーチンを組み込み始める。

 組み込み始めてから、LCDドライバーの方も換える必要がでてきて結局ドライバー側もファームウエアを書き換える。ISPケーブルが2つのボードを行き来し神経を遣う。何とか双方のファームを書き直し、データの取り出し部まで書かずにとりあえず動かし見る。

 これが、動かないのである。まあ、すぐ動かないのには慣れている。少しづつこれまでのルーチンを入れながら動かすことにする。まず、LCDドライバのケーブルをはずし、これまでのステップを全部コメントアウトしRTC部分だけ動かしてみる。なに!これも動かない。そんな馬鹿な。念のためRTCモジュールをSDカードのボードに差してみると問題なく動く。

 少し考えて原因がわかった。LCDドライバーへのコマンドをコメントアウトしていないので、ここでI2Cがハングしている。モジュールが原因でないので元のモジュールを戻し、LCD関係をスキップするファームを書き換えて電源ON。

 まだ、動かない。えー、どうしてとモジュールを見たら、何と逆に差している。大抵のICはたすきがけの位置にVccピンとGNDピンがあるから逆ざしは致命的だ。この間10数秒。慌てて電源を切り、元へ戻すが遅かった。レジスタは読めるが書き込めない。そのうちreadも出来なくなった。

 ちょうど車の物損事故のときの気分と良く似ている。怪我をしたり、たいしたお金を失ったわけでもないのに、無性に自分が腹立たしく気分が納まらない。車と違って外見は全く変わりがないので余計口惜しさがつのる。 やれやれ、また秋月に行って買ってこよう。いや余り早く行くとまた必要もないものを買ってしまいそうである。もうすこし後にしよう。

LCDのビジーフラッグの問題が解決(5/14/08)
 電源逆ざしでICを失い気分が滅入っていたが、久しぶりのクリーンヒットが出て気分は最高である。今年の正月から奥歯にものが挟まったように気になっていた問題が遂に解決された。LCD表示のビジーフラッグを調べて表示するロジックの実装である。

 LCD表示は、AVRを始めてすぐ取り組み、豊富なWebの情報をもとに動かせるようになった。I2Cを使ったLCDドライバーまで作ったが、長時間表示させると調子がおかしい。表示が止まっていたり、2重に表示される。これを解明するためEEPROMを使ったトレースの仕掛けを作ったのだが、これがまだハングするのである。EEPROMには何にも残されていない。I2Cがおかしければ必ず何か証拠が残るようにしてある。こうなると原因はI2CではなくLCDの表示そのものである。

 LCDがハングする原因はLCDの制御が終わらないうちに次のコマンドを送ってしまっている可能性が高い。さらに待ち時間を増やしてみたが同じ。しかし、待ち時間を調整して動かすのは余り嬉しくない。確かに1本信号線は節約できるが、本来のLCDの能力を生かしていないことになる。しかし、LCDのREADを使ってビジーフラグを見る方法は、さんざん試したが、どうやっても動かず、諦めてみんながやっているように時間を待って書くコードにしてしまった。

 データシートによれば、コマンドの処理時間はたかだか60μsなのに、待ち時間は1ms以上必要で、それ以下ではハングアップしてしまう。理屈に合わないが、それだけの待ちを入れれば動いたのでそのままになっていた。

 ハングアップとは直接関係ないが、ちょうど良い機会なので、少し念入りに調べてみた。Webを漁ったが、どのソースも待ち時間を入れているだけで本格的なビジーフラグを見るコードを探し当てることが出来ない。諦めきれず、「LCD」「待ち時間」などのキーワードで調べているうち、あるサイトにLCDを使った製品のPDFがあり、そこには待ち時間ではなく、LCDのビジーフラッグを調べているフローチャートが掲載されていた。このプログラムはビジーを見るために2回READをしている。えー、頭のbit7(busy flag)を調べるだけで良いのに何故2回も読む必要があるのだと思った瞬間、頭を電撃が走った。これだ。LCDの初期化で散々4ビットモードにするロジックを研究したはずなのに、フラグを見るREADを一回しかしていない。

 あとから考えれば、何でもない話だけれど、全くこれに気がついていなかった。そのWeb
を見たのは職場である。帰宅して夕食もそこそこにLCDの試作プロジェクトを立ち上げ、LCD表示基板から石をはずしてブレッドボードにLCDを取り付ける。お世話になったTiny26の余命をすごさせるLCD 表示基板には、こういうこともあろうかとLCD端子をそのまま引き出したソケットがつけてある。

 急いで色々なところからコードをかき集め、待ち時間ではないビジーを見る関数にENABLEをもう一回とデータレジスタを出力から入力、さらに出力に戻す修正を入れる。あれだけ頑固に動作を拒否していた仕掛けが何の問題なく動いた。心なしか速い感じがする。ハングアップする原因は明らかだ。次のREADで下半分が読み出され、関係ないビットをビジーフラグにみなして、それが0なら先に突っ込んでハングアップする確率は50%、奇数回にOKになれば、あとの処理は4ビットづつずれて目茶目茶になる。

 問題が解決したときの最高の気分を味わう。何度経験してもこの気分は何物にも替えがたい。長い間の懸案が片付いたのだ。今までの暗い気持ちが嘘のように晴れ天下をとった気分になる。山登りで頂上に着いたときと同じ爽快感である。

ここにビジーフラッグを見て表示するLCDのドライバーとヘッダーファイルを置きます。
表示速度ははるかに速くなりますが、RW線を所定のポートにつなぐ必要があります。

「NewLCD.lzh」をダウンロード

 今夜は旧友との飲み会でへろへろだったけれど、帰って来てすぐPCに向かう。やり残している仕事(?)がある。今まで文字を表示するたびに1msとか1.5ms待っていたルーチンとの性能比較だ。酔いで覚束ない手先でロジアナのプローブを接続し、LCDの最大の文字数32文字を表示させる。何と32文字表示するのに2msかかっていない。10倍以上の速さである。大量に出力すると見た目でもはっきり一気に表示されるのがわかる。今までは一呼吸かかっていた。LCDというのはそういうものだと思っていたが、申し訳ないことをした。LCDに謝らなくてはなるまい。

やることが多すぎる(5/20/08)
 難問が解決して、少し気が抜けてしまった。何しろやりたいことは山ほどあるので、何かやりだしても、他のことに気が散ってなかなか先に進まない。こういうときは手作業が一番落ち着く。アイテムラボから買った変換基板にMega128の実装を始めた。実は、変換基板をユニバーサル基板につけるピンヘッダーを1000ピン(\1500)も買ってある。

 なぜこんなに買ったかというと、秋葉原などで売っているICピンヘッダーは金メッキなどの高いものしかなく、Mega128の64ピンだけで\300以上かかり変換基板分を入れるとチップの値段に近づいてしまう。

 表面実装はやってみたいが、基板を自作しない限り安定した配線は望めない。それにブレッドボードがとても使い勝手が良いので、このボードを基本にすべての工作を進めて行きたい。で、変換基板なのだが、いくらなんでもチップの値段に近いところまでかけてやるのはいただけない。これだと64ピンでも\100以下ですむ。

 少し飲みに行けば\5000やそこらはあっという間に使ってしまうが、電子工作になると途端にみみっちくなるのは不思議だ。消費感覚と言うのは相対的なものなのだろう。0.8ミリピッチのTQFPの半田付けはこのあいだ大騒ぎして済ませてある(4/29)。ブレッドボードにつけるための小さなCPU基板に64ピン分のソケットをつけ、ここへ変換基板を差し込む。まだ用途の決まっていないときの基板の位置決めは難しい。QFPのピン配置に慣れていなく、しかもMega128は電源ピンが3組もあるので電源とファーム書き込みのISPピンの配線だけでも結構頭を捻る。ついでにパスコンにこのあいだ買ったチップコンデンサーをピンの間に半田付けし悦にいる。

 出来上がってチェックしたら、あろうことかチップコンデンサーをつけたところだけ1ピンずれていた。マーフィーの法則である。2ミリに満たないチップコンデンサーのとりはずしが簡単ではないことをいやというほど知らされる。ウェブでチップパーツの取り扱いに大げさな注意があったのを笑っていたが確かに笑い事ではない。くしゃみをすれば間違いなく部品はあっというまに吹き飛び、見つけることは殆ど不可能だ。

 半田まみれになりながら何とかチップコンデンサーの移動は終わった。テスターで容量が定格にあることを確認し胸をなでおろす。まあ、1ヶ\2なのだけど、部品を動かす前に壊してしまうと言うのは抵抗がある。生きとし生けるものというが、職人の感覚では道具、部品、材料すべてに命が宿っている気がする。無機質な要素を集め、工夫し、汗を流して、何か動く命があるかのようなものにすることが無性に楽しい。

 Mega128が動いた。Gataro研のフラグシップである。今のところSDカードとNICチップをつけてインターネットのマイクロサーバーのCPUになる予定である。A5211285

 手を動かしだすと止まらなくなった。やりかけになっていたボタン電池をつけたRTC基板もついでに完成させてしまう。これでブレッドボードにつける変換基板がらみの小さなユニットは、作り始めた順番に、DCアダプタ基板2ヶ、NIC基板、SDカード基板、RTC基板の5つになった(NIC基板は電源コントローラに実装済み)。これにMega128のCPU基板が間もなく加わる。

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

MMC(SDカード)をMega168で

Mega168を2つも失う悲劇(5/2/08)
 LANの電源コントローラが正式運用を始めて実験の中心は、SDカードアクセスの方に移った。chaN氏のFATファイルシステムの話は前から読んでやりたいと思って、Mega128を入手していたのだが、まだまだ先のプロジェクトになると思っていた。ところがこのあいだMega168でSDカードのTinyFSを動かしたという記事を読んで急にやる気になった。組み込みウェブサーバや、計画している電力ロガーの記録媒体に早く使いたいという事情もある。

 そんなこともあって、ソフトはスクラッチをあきらめ、chaN氏のソースを参考にMega168の環境に移し始めた。彼のコードはとても洗練されていて参考になる。しかし、これがなかなかコンパイルが通らないのだ。このプロジェクトのきっかけになったMega168を使った 記事は、ソースが公開されているが、肝腎のコードサイズを小さくする方法が全く書かれていない。このソースを使えば良いようなものだが、それでは前と同じで進歩がない。そこで勉強を兼ねてオリジナルをもとに、コードを解読しながら機能を減らしたり、バッファーサイズを縮めて何とか16Kぎりぎりに収めた。

 RTCとのインタフェースのI2Cはオリジナルでは何故か標準のハードを使わず、スタートコンディションから何から全部ソフトで作っている(これがシンプルで素晴らしい)。これを標準I2Cにして、秋月のエプソンのRTC(リアルタイマー)で動かすようにしたら、コードが200バイト近く減った。

 ここまでは順調だったが、悲劇が襲ったのはテストに入ってからである。UARTが動くところまで行ったが、それ以降はなかなか進まない。カードが入っていないという状態で完全な門前払いである。Mega168の記事ではこのあたりは全部省略され電源は常時ONで動かしているようだが、折角コントロールできる機構なのでつけてやりたい。しかし、ここのしかけが良く分からない。電源が入る前にポートでチェックしている。そんなことできるのか。

 何度かファームに書き込んで動かしているうち、書き込みエラーが起きた。ファーム書き込みのSPIとカードアクセスはピンが共通である。慌ててピンをはずして試みるが同じ。そのうちMCUを全く認識しなくなった。このチップは全くの新品でこんなに早く書き込めなくなることは考えられない。ライターの不具合かと他のボードのMCUを試すが問題ない。

 過電圧をかけたこともないし、熱も全く持っていない。Device Not Foundという冷たいメッセージが出るばかりである。チップの予備はもうない。初期故障なのかと諦め、あわててネットを開き以前Tiny861を買ったショップに注文する。次の日、車で入谷まででかけチップを手に入れた。約束の時間より早かったので、秋葉原の秋月に寄って、H8/3069Fというマイコンボードを買ってし
まった。どうも、何かが動かなくなると不安になって衝動買いしてしまうようだ。

 こいつはフラッシュが512Kもあり、NICチップもRTL8019という本格的なコントローラがついている。これが完成品で、たったの\3450である。実は以前買ったLAN電源コントローラの参考書にこれが詳しく出ていて、このあたりになると10年前に熱中したLinuxが動き本格的な組み込みシステムになる。欲しいセットだったのだ。ついでに千石で安いリードタイプのFET(2SJ325 \100)があったので買う。トランジスタでカードの電源を制御しているが、何となく不安だったからである。

 この不安は的中した。新しいチップをブレッドボードに挿し、実験を続けていたら、また同じ現象が起きたのである! 初期故障でもなんでもない。これは何かが起きている。Gataro研究所始まって以来の大事件である。立て続けに2つも心臓部のチップを失ったのだ。

まず、疑うべきは何故、オリジナルの記事の回路で、トランジスタをつかわずFETを使っていたかである。トランジスタはコレクタにカード電源の負荷がかかりベースがMCUのポートにつながっている。トランジスタがOFF状態でもプルアップ抵抗などを通じてカードを通してMCUに何らかの電流は流れる。しかしMCUの入力ポートは高インピーダンスでMCUを破壊することなど有り得ないはずである。

次に考えられる原因は、カードの電源電圧とMCUの電源電圧の違いである。しかし、これも論理判定で混乱する程度で、壊れるところまで行くとは考えられない。ネット上で色々キーワードを換えて調べてみたが、それらしい情報は見つからない。

 しかし、今の状態では、取り替えても3回目の悲劇が起きる可能性が高い。暫く途方に暮れていたが、結局、オリジナルの回路に忠実に戻すことにした。これなら問題ないはずである。幸いFETが手に入ったので、電源コントロールも組み込める。電源電圧も3.3Vに統一する。0.5Aのレギュレータだが何とかなるだろう。

明け方近くまでブレッドボードの配線を全面的に取り替えて次の朝(といっても昼近くだが)、起き掛けに突然ひらめいた。そうだ電源が入る前にカードが入ったか、ライトプロテクトがかかったかがわかるのは、スイッチが入っているからなのだ。chaN氏の回路図には出ていない。慌ててサンハヤトのソケット基板をテスタで調べる。この基板には記事には出ていない何本かの端子が出ており、シールドかなにかと思っていた端子と、カードインサートなどの端子が導通していた。これだ。

 ここを配線して、プロジェクトは少し前進した。SPIのコマンド送出まで動いた。もう10数回書き込みをやっているが、まだチップはこわれていない。オリジナルと全く同じ配線なのだから、これで壊れたら電波か宇宙線ということになる。それにしても、電源電圧の差で本当にチップはこわれるのだろうか。

何とかセクターまで読めた
(5/3/08)
 SDカードアクセスのプロジェクトは、やっとのことでSDカードの読み出しに成功した。動いてから考えてみれば、何でこんな間違いに気がつかなかったのだろうというケアレスミスの連続である。プログラムのデバッグというのはこういうものだ。動作環境が違うのだから、そこだけ目をつけておれば良いのだが、どうしてもロジックに目を奪われてどうでも良いところばかり疑ってみたりする。

 メインの初期化のところのポートの設定は、目を皿のようにチェックするが、カードの電源を入れるところでもう一回ポートの初期化を行っているのを見落とし、カードのチップセレクトのポートが入力になっているのに気がつかなかった。ロジアナでは、ちゃんとチップセレクトのCSがLow(1)になっていないのに気がついていたが、カードの初期化にはCSをHigh(0)にしたまま70クロック動かしてカードを始動させるという記述に惑わされていた。A5101280

 テストを始めて4日目にして、何とかセクタ単位のデータは吐き出してくれるようになった。FATレベルはまだ動かない。フラッシュサイズが一杯なので必要な関数を小出しに入れている。まだ足らないらしくシステムがリセットしてしまう。それとRTCがまだ動かない。まあ、これはテストステートメントを入れていけば何とかなるだろう。

 やれやれ、人のソースを見るのは疲れる。しかし、chaN氏のソースは非常に洗練されていてとても参考になる。「良い仕事してますねえ」と感心する。しかし、コードサイズは絞っても16K近くになる。Mega128クラスでないと、ちょっと他の応用はきついかもしれない。

 Mega168は順調に動いている。これも寝ながら思いついたのだが、Mega168急死の原因は、やはりトランジスタの電源制御の疑いが濃い。NPNのトランジスタ(2SC1213)なので、SDカード周りのグランドがコレクタにつながって浮いた状態がOFFである。これだと、カードの電源は接続されたままのSPIインタフェースを通して全て流れていく。これはまずい。

 以前、LCDのバックライトをトランジスタで切ったとき、切ったほうが動いているときより電流が多く流れる経験をしている。SDカードは数十mA近く流れると言うことだから、これがMega168のSPIピンに流れれば、壊れる可能性がある。

H8に浮気しそう(5/4/08)
 このあいだのAKI-H8/3069Fを動かしてみた。始め間違えて6VのDCアダプタを直結し、もうちょっとでまた悲劇が起きるところだったが、何とかOSをROMに書き込むことに成功した。これは2MのRAMを持っているので相当本格的なことが出来る。

 このRAMにロードするメディアとそれをドライブするROMのOSがあれば、フラッシュ100回までという制限なしに、自由にプログラムの開発が出来る。もちろんWindowsからもロードが出来るが、コンパイルはともかくプログラムの実行の度に、Windowsからロードするのは美しくない。このあたりが、一番やりたいところなので、SDカードのアクセスは是非実現しておきたいところなのだが、こいつが手強い。

 テニスから帰ってまた地下にこもり、開発に専念する。リアルタイマーは単純なミスが見つかり、クロックの移植は成功したのだが、論理的なファイルの状況表示がうまくいかない。システムがリセットされるのはメモリをオーバーランしているからだろう。その場所をみつけるため、LEDやテストステートメントを挿入するが中々特定できない。

 ファイル構造体の定義の中に512バイトという大きな数字を見つけ、これを減らしても状況は変わらない。このあいだのMega168で動かしたと言う記事のコードを見てみると実際のバッファーサイズが80バイトしかない。構造体が512なのにどうしてバッファーはこんなに小さいのか。ロジックが読みきれていないので試行錯誤でやるしかない。

 現在のこちらのバッファーサイズは256バイト。バッファーは大きければ大きいほど良いはずなのだが、試しに半分の128に減らしてみた。 これが何と、動いたのである。理由はわからない。ちゃんとディレクトリの位置、FATテーブルのセクタ、ファイルの数などが表示された。やれやれお疲れさんでした。 16MのSDカードがうまく出たので、128Mの方を試してみる。セクタ単位は問題ないが、論理ファイルの表示は途中でリセットがかかった。

 まだ完全ではないが、SDカードのプロジェクトもほぼゴールに近づいたようである。あとは、この応用だが、フラッシュ16KのMega168ではテストに精一杯でSDカードを使いこなすのは、やっぱりMega64クラスにならないと難しそうだ。H8なら全く問題がないが。

ほぼ完全にSDカード読み書き成功(5/10/08)
 CPUチップを2つ犠牲にしたが、SDカードアクセスは試作ボードで、想定の機能をほぼ満足し、実用に近づいた。128MのSDカードは最初読めなかったが、いくつかの関数を使わないようにしたら正常に読めるようになった。どうもメモリ管理を自分でやらないとリセットしたりハングするようだ。まだソースが読みきれていないのでこれは後の課題とする。

 ロガーなどの実装のときのためFETを使った電源制御とプルアップ抵抗などSDカードの回路をサンハヤトの変換基板に組み込みブレッドボード上を整理する。昨夜、酔っ払ってピンをひとつ間違えて差込んでVccをショートさせ、あやうくレギュレータを昇天させるところだったが、時間が短かったので何とか助かった。動かないので念のため部品を触っていて、レギュレータがやけどしそうになるほど熱いのを見つけ、あわてて止めた。このあと動かしたが、特に問題はなかった。いや結構丈夫なものだ。A5101274

 余裕が出来たので、ベンチマークをとってみた。8MのCPUクロックで128MのSDカードは、Readでは200KB/秒、Writeでは20KB/秒と、chaN氏のレポートの半分くらいの速さだが、フラッシュ16K、SRAM 1KのMega168でこの数字は立派なものだ。これでAVRマイコンの世界では破格の大容量記録装置を手に入れたことになる。

 ソースはオリジナルは消さずにすべてコメントアウトし、これからMega168クラスでFATシステムを動かす人のための参考になるようにしたが、オリジナルをコメントアウトしたソースを公開するのも気が引けるので、変更点をまとめておく。

  • 元のメインプログラムはすべての機能を試せるようにかなり大きいので、コマンドを半分以下に減らす(main.c)
  • バッファサイズを縮小  ファイルバッファは2048を128 UARTは120から40 (main.c)
  • 電源制御、チップセレクトなどのポートを変更。(mmc.c)
  • 10msのインタバルタイマーのタイマーレジスタ変更。(main.c)
  • RTCを秋月のRTCモジュール(エプソンRTC8564)で動くように変更。ついでにオリジナルのソフトIICをMega標準のIIC機能を利用。

 以上で、TinyFATFsを使いフラッシュサイズ16K以内(fw,frなどの性能テストコマンドを含む)の16,078バイト、SRAMが798バイトに収まっている。コードの内訳は、ttf.cが7キロ、SDカードをアクセスする下位ルーチンmmc.cが2キロ、リアルタイムクロックが1 キロ、その他UARTやXitoaなどの周辺ルーチンが1キロ程度で、残り5キロはメインのコードとコンスタントである。

 従って、電力ロガーなどのアプリは5キロ以内に収めれば、何とかMega168でSDカードに記録するロガーが出来そうである。

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

2008年8月29日 (金)

AC電流センサーを入手

ハードは難しい(4/11/08)
 2年ぶりの人間ドック、15年の寿命を全うした老猫のお葬式と立て続けに行事が続き、なかなか電子工作に時間がとれない。昨夜は、気がせいてテスタで電圧を測っていたら、100VのAC部分にテスタ棒が触れてしまい、ダイオードとフォトカプラの2つの部品の命を一瞬にして失ってしまった。何しろ真空管時代に入学祝いに貰ったアナログテスタをいまだに重宝して使っている。デジタルと違って視認性が良いし、このテスタはレンジの設定が絶妙で使いやすい。大抵のテスタのレンジは5と10刻みだが、これは、6、12刻みなので5V、100Vなどを測るのに便利なのだ(当ブログ冒頭の写真に写っています)。

 しかしテスタ棒(プローブ)の電極の先の太さは真空管時代の太さだ。ACがどれくらい降圧されているかプローブを当てたとき、生の100Vが来ている下のランドに触れ、小さなアークが飛んだ。やった。しかし、ヒューズやブレーカが落ちるほどのアークではない。ダイオード、フォトカプラなどに外見の変化はない。小さなアークはダイオードが犠牲を一身に引き受けてくれたからかと調べたが、導通状態でこわれていた。これはまずい、先に波及している。フォトカプラも苦労してはずして調べる。やはりこちらも100Vを喰らって息が絶えていた(こちらは断線状態)。 合掌。

 泣きながら(うそです)、2つの部品を交換。ついでに、先日の入力ポートがおかしかった負論理のオープンコレクタをやめ、オープンドレインで出力するよう回路を変える。MCUのポートのプルアップが何か悪さをしているような気がしたからだ。

 しかし、結果は同じだった。そりゃそうだ。オープンコレクタもオープンドレインも原理は同じなのだから余り意味はない。結局、このあいだのNICチップとMega168のレベル補正に使った3ステートバッファ(74HC126)に余っていた1回路分を使って分離することにした。これで、フォトカプラの出力をMCUの入力ポートに入れることが出来た。

 やれやれ、本質的でないところに時間を取ってしまった。しかし、それにしてもハードの世界は難しい。小学生の時から真空管ラジオをいじり、大学の専攻も電子工学という世間ではこの世界の専門家と言われるだろう自分でも、実務経験がなければ内実はこんなものである。

AC電流センサーを購入した(4/18/08)
 この記事はAVRの話がメインなのだが、一週間近く書き込んでいない。あまりに早くEtherNetの電源制御が実現したもので、すっかり気が抜けてしまい次の課題が見出せないのだ。いわゆるTCP/IPスタックといわれるソースと格闘しUARTを使ってHTTPの勉強をしようと意気込んでいたのだが、とりあえず究極の目的の電源制御があっさり実現してしまった。

 このドイツのWebサーバーのしかけは良く出来ていて、パスワードをファイルのディレクトリとして取り扱い、そこそこのセキュリティはあるし、電源の状態はしっかり把握しているし実用上もう何の不足もない。

 仕方がないので、せめて背景にテクスチャーを張ろうと思ったけれど、どんな小さい画像ファイルでも10Kバイト以上あり、SRAMが1K、EEPROMが512バイトのMega168ではとても歯が立たない。

 sleep機能を入れたところでMCUよりNICチップの方がはるかに消費電流が大きく、節電の効果は余りないし、機能的にアップするわけでもない。要するに、いじって楽しむところがもうないのだ。ただ、3Vのレギュレータが結構熱くなり、密閉したときが心配である。熱抵抗を計算したところでは大丈夫なようだが、ヒートシンクをつけたほうが良いかもしれない。それに、手動スイッチをつけたいのだが、もうスペースが殆どなく思案している。

 というわけでもないが、AC電流センサーを秋葉原で入手した(¥1600)。レーザープリンタの電源制御を安心してやるために、これが常時どれくらい電流が流れるのか調べておきたかったからである。トロイダルコイルに適当に線を巻けば出来るらしいが、調整が必要だし、やはり出来合いのものが安心だ。Pict0713_2

 それにしても秋葉恐るべしである。一間そこそこの小さな店構えなのに当たり前のように電流センサーをしかも何種類も在庫していて一個から売ってくれる(東邦無線 ラジオセンター)。安いのや(¥1000)、小さいのもあったが、家全体の電力量も記録することも考え、コアが分離できて既存の配線にも使える標準品を買ってきた。

 これが結構面白い。ちゃんと30W位の電気スタンドから電圧が出て(数十mVだけど)、電流ロガーのセンサーとしては申し分がない。レーザープリンタは予想したとおり、ドラムが回っているときは定格の13Aほど流れるが、待機中はせいぜい数十W程度であることが確かめられた。これなら密閉したケースで長時間通電しても問題なさそうである。

 PCの待機電力が結構喰っているのに(10W以上)驚いていたら、測定を終わって正規の接続にもどした直後、何とPCの電源そのものが、突然小さな金属音とともに死んでしまった。何か関係があるとはとても思えないのだが微妙なタイミングである。

 スタンバイの5Vが死んでいる。電流センサーのインダクタンスでサージ電流でも流れたのだろうか。それにしてはこわれたときが同期していない。まあ、この電源は、かなり年期が入っているのでもう捨てても惜しくない。予備の電源でとりあえず動かした。こいつが動かないとAVR制作も出来ない。この予備も相当古いので新しい電源を手に入れる必要がある。久しぶりにPC関係の買い物で秋葉に行くことにする。

いやお恥ずかしい(4/21/08)
 PC電源では何ともみっともない経験をした。久しぶりのPCパーツの購入で、ウェブで事前に調査をし、先週の土曜、秋葉で400Wの電源を買ってきた。これまで250Wで十分動いていたので、こんなに大きなものはいらないのだが、今や、400Wが最小クラスだ。まあ、ビデオカードを増やしてマルチディスプレイにでもするときに役に立つだろう(フライトシミュレータに一時はまっていた)。

 ところが、こいつが動かない。マザーからはずして電源コントロールをグランドに落とすと電源が入る。PCにつなぐと動かない。てっきり初期故障だと思い、今日、重いめをしてユニットを店に持ち込んだ。これが意地の悪いことに店では動くのである。相性問題というやつである。店では相性については保証しないと言われ、仕方なくまた重い目をして持ち帰った。

こうなったら自分でTTLを組んで動かしてやる。昔と違ってハードの知識が増えている。ひとまず、動いている電源で、電源コントロールPS_ONの電圧を測る。スタンバイ時、4.5V、電源ONで見事0.1Vまで下がっている。ふーむ、マザーは悪くない。

 今度は新しく買ったユニットである。とりあえずケースに入れないでマザーボードだけにコネクタを差し込む。ん?何かこれまでと感触が違う。差し込まれ方が深い。これか。あわててスイッチを入れる。青色LEDが点いて何ごともなく動き始めた。Pict0717_2

 やれやれ、初心者のよくやる差し込み不良である。ケースに固定するとマザーの差込口はユニットのちょうど裏になり手が入りにくい。前の電源と同じようなところまで挿していて入ったものと勘違いしていたのである。いやいやお恥ずかしい。お店で粘らずあっさり帰って来て良かった。もっと恥をかくところだった。

 ついでに買ってきたレギュレータのヒートシンクをつけて何とか気を紛らせる。このヒートシンクは¥100(千石2階)なのだけれど可愛い。結構、放熱効果もある。スイッチも買ってきたがこれは、入りそうにない。

盛大なチャタリングを観測(4/25/08)
 LAN電源制御コントローラの制作も大詰めを迎えた。ネットワーク上での機能はもう十分だけれど、当初より想定している手動スイッチがまだ実装できていない。手動スイッチはどうしても欲しい機能である。目の前のレーザープリンタを動かすのにわざわざネットワークを経由するのでは使い勝手が悪すぎる。いちいちコンセントをつなぎかえているようでは意味がない。

 秋葉原に行くたびに適当なスイッチを探していたのだが、なかなか見つからない。ケースにスイッチをつければ簡単だが、これ以上ケーブルが増えるのは保守性が悪くなるので避けたい。しかし基板はもう一杯でよほど小さなスイッチでないとつけるところがない。千石電商で、基板に横向けに置く小さなプッシュスイッチを買ってきたが、ケースの外にボタンが出てしまい、これでは不用意にスイッチを押してしまいそうで運用性が悪い。

プッシュスイッチを探しているときに超小型のマイクロスイッチ(それもたったの¥50)を見つけA4271268 た。これがあまり可愛いので、何かあてがあったわけではないが、一緒に買ってきてあった。私は昔からこういう小さな部品が好きで衝動買いである。しかし、これを手の中で動かしているうち、ひらめいたことがある。

上蓋に穴を開け、マイクロスイッチのレバーのところに、棒を下ろせばスイッチが押せる。上蓋には何かガイドになるチューブを取り付ければ良い。チューブでなくてもコードを通す時に使うナイロンブッシングが使えるかもしれない。抜け落ちないように棒にストッパーでもつけておけば良い。次々にアイデアが浮かんできた。これはうまく行きそうだ。

 電子工作の面白さは、こういう自分なりに独自の「しかけ」をあれこれ考えるところにある。自分の工夫で考えたとおりに動いたときの喜びは何にも優る。邪道だけれどこのあいだのボタン電池をかませて温度センサーの必要な電圧を確保した仕掛けなどもそうだ。勿論DC-DCコンバータでもできるが余りにも大げさすぎる。

 「しかけ」に目処がついたので上蓋の工作はあとにして、とりあえずマイクロスイッチを基板に取り付け、MCUのポートにつないでスイッチ機能を組み込む。こういう手動スイッチには必ずチャタリングという厄介な現象があるのでこれを回避するソフトを組み込む必要がある。今度はソフトの世界の工夫だ。いろいろな方法があるが、まあスイッチの数も少ないので、ワンショットのタイマを動かしてチャタリングが終わるのを待つことにする。もちろんただ待っているだけでは、パケットをとりこぼす可能性があるので、割込みの入った時点でタイマをスタートさせ、あとはメインループの中で時間がたつのを逐一調べる。

 デバッグのためUARTに割り込みのたびに文字をださせることにしてテストしてみた。ちゃんとスA4251255_2 イッチは働いたが、割込みが10数回起きている。えー、何か別のことがおきているのだろうか。心配になってロジアナで調べてみた。いや、驚いた。やはりそのとおりだった。マイクロスイッチは特にばねを使っているのでチャタリングがすごいことが良く分かった。

 ただ、1ms程度で落ち着くので10msも待つ必要はないかもしれない。ロジアナで調べてみると、10msどころか30ms以上もかかっていることがわかった。タイマのカウントの計算違いかと計算しなおしたが合っている。もしかしたらMPUのクロックがちゃんと所定の12.5MHzになっていないのかとロジアナでクロックを見たがこれもピッタリ12.5MHzだ。A4251257_2

 調べているうちに原因がわかった。スイッチを押して出力が出るところをリレーからとっていた。リレーなどの機械部品の遅れはミリセカンドのオーダーになるのは当たり前だ。ロジアナのプローブ点を増やしてさらに確かめる。

 いや面白い。画面のピンクの逆△がスイッチの押されたところで、盛大なチャタリングが起きた後(短いパルスで赤くなっている)、Aの時点でリレードライブのトランジスタが動き、BでリレーがONされたところである。Aまでは正確に10msで、AB間は何と30msくらいかかっている。しかもご丁寧なことにリレーはONのときは、接点が力余って行き過ぎ、一瞬また切れているのがわかる(OFFのときは起きない)。

 人間の目からは一瞬でもこんなに沢山のことが起きていることが手に取るようにわかる。いやいや1万円そこそこのロジアナだけれど素晴らしい。未知の世界を発見した気持ちになってとても充実した気分を味わった。

最後の最後にミス(4/29/08)
 連休初日に家族で東急ハンズにでかけ、懸案のプラスチック棒を入手した。20センチ¥150が高いのか安いのかわからないが、お誂えのように直径5ミリのスチロール棒が売っていた。慎重に寸法を測ってケースにナイロンブッシングの穴を開け、スチロール棒を切って、コンパウンドで磨きプッシュスイッチの形にする。マイクロスイッチのばねが効いて軽いプッシュスイッチになる。快調である。しかし、最後の放熱穴をついでに好い加減に開けたのが良くない。3ミリのドリルで5つ穴を気楽に開けたら最後のひとつがずれて開いてしまった。Pict0718

 あーあ、である。今度のコントローラのケースの工作は我ながらプロ並みの仕上がりと内心得意に思っていたのだが、最後の最後で小学生の夏休みの工作レベルに落ちてしまった。気を抜いてやるとろくなことがない。

 コントローラを置くところは夏でも高温にならない地下室で、放熱孔がなくても大丈夫とは思ったのだが、何しろ常時電源を入れておかなければならない。用心のために孔を開けたのが良くなかった。最後の一つがずれてみっともない姿になる。いずれ大きく開けて何とかしたいが、すっかり気分が落ち込んでしまった。

 その他の工作は順調だ。次のプロジェクトはマイコンに大容量の記憶装置をつけるMMC(SDカード)デバイスの実装にしている。そこそこ高速だし、古い携帯電話やデジカメの余ったSDカードが活用できる。これがあるとマイコンのWebページも賑やかにできる。

 まず、実験用に、ヒートシンク、スイッチ、LEDのついた5VDCアダプター基板を作る。ブレッドボードに取り付けるためピンヘッダーを下に出した。 次に既に入手してあったサンハヤトのMMC(SDカード)ソケット変換基板(これが高くて\1000以上した)に、ピンを半田付けし、これもブレッドボードに付けられるようにした。

 回路図は、Webページに沢山公開されているが、やはりchaN氏のものを参考にする。MOS FETになっているカードの電源制御は、MOS FETが手元にないので、トランジスタに替えて動くことを確かめた。あとはプルアップ抵抗などをつければハードは完成だ。ブレッドボードはこういう実験には本当に便利だ。

 問題はソフトである。chaN氏のTinyFSを使ってしまうことになりそうである。LAN制御と同様、本当はスクラッチから作るべきなのだが、どうも不精になっていけない。理屈がわかっていれば、どんどん活用すべきなのだけれど、これではいつまでたっても技術レベルが上がらない。

 今度のネットワーク制御も原典のひたすらデータが来るのをループして待つ方式ではなく、割込み制御をやろうと思ったが、このENC28J60はデータシートどおりの割り込みが起きていないことが実験で明らかになった。そう言えば、オリジナルの記事にも割込制御は不安定なのでやめたという記述があったような気がする。 迷ったが、今のところ安定して動いているので、これ以上手を入れることは止めた。

 これとは別に、完全なお遊びだが、LEDマトリックスを買ってきてある。これはMMCが動けば、8ドットの日本語フォントでも入れて、電光掲示板にでもしようと思っている。そうだ、表面実装にもチャレンジした。

 秋月で買ったMega128をアイテムラボの変換基板に乗せてみた。MMC制御のためである。こいつは64ピンのTQFPでピン間は0.8ミリなので、そう難しくないだろうと、最初、たかをくくって気楽に2面を半田付けしたところ、残りの面がずれていることがわかって最初の半田付けは大失敗であった。冷や汗をかきながらウェブに出ていた細線を使う方法でやっとのことではずし何とか変換基板につけることができた。いやいや勉強することが山ほどある。

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

LAN電源制御成功!

15Aを制御するのは大変(3/31/08)
 電源部の実装ではまっている。気楽に15Aと言っていたが、部品が揃わないのである。リレーは簡単に手に入ったが、AC関連のありふれたパーツはみな定格が10Aどまりで、あらゆるものが問題になる。あってもごつくて、考えているケースにとても入らない。一番の問題が手動操作用のスイッチで、コントローラの作動を反転させる階段スイッチのような単極双投スイッチを探したのだが、適当なものがない。あっても、それだけでケースが一杯になるような大きさで高く(¥1000近い)、下手をするとスイッチを入れる動作だけでケースがこわれてしまいそうだ。

 世の中にはマイクロスイッチというのがあって、これが双投の上、軽く15Aをクリアし大きさも親指の頭くらいで値段も高くなく(¥300前後)、ぴったりなのだけど、こいつは殆どがモーメンタリ(押しているときだけON)で、プッシュスイッチのような動作をするものがない。ここの業界も縦割りが進んでいて棲み分けが出来ているようだ。

 ヒューズもそうだ。市販のヒューズボックスは10Aが最高で、それ以上は車載用の防滴型などの特殊なものに限られる。ACインレットもなかったが、これは秋葉原のラジオデパートを探し回って偶然、電源コード店で見つけた。しかし、インレットとアウトレットを2つ並べるスペースがない。やっぱり今の小さなケースでは(125×80×32)無理なのか。結局、100V側で切り替えることをあきらめ、インレットは省略し、スイッチはMCUがわのソフトで対応することにした。

 ここで問題になるのが、通電の監視である。ソフトでなく実際の通電をモニタしたいが、相手は100V ACである。まあ、LEDを光らせるつもりでフォトカプラをつければ何とか分離できそうだと、最初は気楽に考えていたが、考えてみればAC50Hzのパルスが伝えられたのでは通電の確率は50%になってしまう。そうか、DCにしないといけないのだ。フォトカプラの前でダイオードとコンデンサで直流にしてやれば良い理屈だが、Webなどにはこういう乱暴な方法はどこにも書いていない。

 こうなったら自分で確かめるしかない。100Vいきなりでやるのはちょっと怖いので、昔買ってあった6Vを出すトランスを取り出し、6Vでやってみることにした。実は50Hzのパルスになるというのは、この実験でわかったというお粗末。受け側がHighにならないで中間でふらつく理由を考えていて、平滑コンデンサーの必要性に気づき100μFを入れてやっと考えていたように平坦になった。

 面白いので本当にパルスになっているか、ロジアナで確かめてみた。いや、ちゃんとパルスが出ている。コンデンサーの容量を減らしていくと33μFあたりでパルスになる。面白い。昔習った時定数で計算してみた。電源インピーダンスは6V、5mAだから1.2KΩ、時定数CRは、33×1.2でおよそ40msが最初の電圧の36%になるところである。

 次のリップル(半波整流)が来る20msではどれくらいかというと、直線で減衰するとみなして65%くらいか。100μFだと90%近く残る。この間あたりに閾値があるようだ。すごい。昔習ったことが役に立っている。何かとても得をしたような気分を味わった。

ブレッドボードでレーザプリンタの電源制御成功!(4/3/08)A4041236
 電源部の仕掛けがやっと出来た。15Aのコードはやわらかいコードを選んだはずだが、ケースが小さすぎてACインレットをつけられなかったので、とりまわしがやりにくい。コードを動かすとケースごと動いてしまう。まあ、殆ど固定しておくので実用的には問題がないが、テストの時は気を遣う。何しろ100Vである。昔、真空管ラジオの頃、250Vに感電して、指の先に穴を開けた経験があるが、それほどでないにしても気分のいいものではない。

 電源部は予定外の部品が入って苦労した。ヒューズボックスは10Aのものしかなかったのでつけない予定だったが、やっぱり心配だ。家の部品箱をさらっていたら、30Aのガラスヒューズが出てきた。昔の自動車用だけど、サイズはぴったりである。試しにレーザープリンタの電源を通して30枚ほど連続印刷してみた。

 ほんのり暖かくなる程度で特に問題はなさそうだ。予定を変えてつけることにする。まあ熱を持ったらヒューズが溶けるので最悪の事態は避けられる。やっぱりヒューズは万が一を考えて付けておきたい。 これが、測ったようにピッタリ縦の電源基板にはまるのである。ただしリレードライブ用のトランジスタはメイン基板に追い出されてしまったが、これは殆ど問題がない。

 配線が全て終了し、慎重に一部分づつテストしていく。まずリレードライバーをブレッドボードに組み、ブレッドボード側の電源でリレーを動かす。「カチッ」と頼もしい音がしてリレーが動く。定格は100mAだが、電池の4Vで70mAしか流れていないけれどちゃんと動く。偉い。次が問題のフォトカプラ部分である。

 とりあえず、何も接続せず100Vを通電して様子を見る。異常はなさそうだ。ブレッドボードにLEDを組み、出力側につなぐ。通電。点いた!電圧を測ってみる。20KΩの抵抗で計算どおり入力側の電圧は1.1Vになっている。いや順調。順調。

 ACアウトレットに出力コードを半田付けする。これで電源部とケースは離せなくなってしまうが仕方がない。試しに照明スタンドをアウトレットに差込み、ブレッドボードのドライバの入力をONにする。点いた。フォトカプラからのLEDも点灯する。

 調子に乗って、大きいほうのブレッドボードに組んであるLANコントローラの一部にこのリレードライバを移し、出力LEDの部分が入力になるようにする。PCを立ち上げてウエブブラウザを動かす。

 やった。画面のクリックで照明スタンドが点灯した。マイコンを始めた去年の10月からおよそ半年、商用電源の制御がLANを経由して可能になった瞬間である。嬉しくて居間のノートPCからも動かしてみる。もちろん当たり前のようにスタンドは点く。

 ここまで来たら最後までやるしかない。レーザプリンタを接続する。今度は13Aだ。リレーは15Aまで大丈夫だから問題ないはずだが、何故か緊張する。プリンタの電源を入れてブラウザでON。ところがプリンタは動かない。頭から血が引いていく。もう一度OFF/ON。やっぱり動かない。えー何で? 音がしていないか、何かにおいがしないか、一生懸命耳と鼻をきかすが何の変化もない。 電源を切り、気を取り直して最初から調べなおした。いやいや何のことはない、レーザプリンタのインレットのところがコードを引っ張ったために抜けかかっていただけだった。A4041235

 インレットを差し込みなおし再度テスト。通電のLEDが点いた。少し遅れてプリンタの中のリレーが「カチッ」と音をたてお馴染みのウオーミングアップの音がしてプリンタは無事動き始めた。ブレッドボードだけれどレーザプリンタの制御が実現した。何枚か印刷して30分ほど様子を見る。

 電源を切って、基板の電源部をチェックする。リレーはほんのり暖かくなっている程度でヒューズボックスは殆ど変化はない。ヒーターやドライヤと違ってレーザープリンタは待機の時の消費電力は極めて少ない。心配なさそうである。

 あとは、ブレッドボードの回路をメイン基板に実装するだけである。ああ、手動スイッチのソフトを追加する必要があるが、これは完全にソフトウエアの世界なので特に問題はない。さあ、この目標も最終段階に来たようである。次のテーマを探さないといけない。

実装がほぼ終了。ケースの上蓋工作を残すのみ(4/9/08)
 構想10年じゃなかった、去年AVRを始めて以来、最終の目的にしてあったネットワークによる商用電源の遠隔制御装置が遂に12センチ×7センチのケースに実装され、実際に動き始めた。メイン基板の配線は、殆どICとの間の接続だけなので、アートワークも簡単に終わり、半田付けも楽だった。リレードライバが電源部から引っ越してきたが、まるで測ったように空きスペースにぴったり納まる。快調、快調。A4111243

 はやる心を抑えてコンセントに電源ケーブルを差し込む。電源ONの緑LEDが点灯、ブラウザでONをクリックするとリレーの音とともに赤いLEDが点灯した。配線間違いもなく、見事に実装版が動いた瞬間だ。レーザープリンタに接続し様子を見る。暫く使ったが、印刷しない限りレーザープリンタは殆ど電力を消費せずリレーがほんのり暖かくなる程度で全く問題ない。ただ、NIC基板は100mA以上流れるのでこれよりやや暖かい。

 残る作業は、上蓋に電源コードの穴を開けてブッシングをつけること。2本のLEDの穴をあけるのみとなった。ただ少し気がかりなことがある。100V出力のモニタにフォトカプラで赤LEDを点灯させているのだが、将来のためにMega168の入力ポートにつないだら、highにならないのである。フォトカプラはプルアップして負論理にしてあり、LEDは制限抵抗を介してVccにつながる。負荷抵抗の形になるのでおかしいけれど単独なら別に問題なく、lowで点灯する。

 ところが入力ポートに接続すると、フォトカプラがOFF状態でもLEDがついてしまう。デジタル回路の入力インピーダンスは非常に高いはずで、ポートをつないだだけで変わるとは思えない。Webで色々探すがどうも良く分からない。フォトカプラの出力はいわゆるオープンコレクタでデータシートによれば10mAくらい流しても問題ないはずなのだが、何か勘違いをしているのかもしれない。

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

EEPROM 93C46の怪

次々にデータが消えていく(3/21/08)
 まだ、モジュラーのLEDの橙色側(リンク成立)が点かないとか、5VではやっぱりMegaがリセットを繰り返して動かない、などの問題を抱えているが、予想に反して余りにも早くネットワークが開通してしまったので、予定が全く狂ってしまった。 AC電源を入り切りする部分、ケースなどの実装も実は具体的な設計は何もしていない。 デバッグしながら準備しようと思っていたのだが、何か気がぬけてしまって先に進めない。

 前に、ダウンロードしました。コンパイルしました。動きましたでは、面白くないと書いたが、現実はそのとおりになっている。だいたいSPIインタフェースそのものが私にとっては始めてのインタフェースなのである(ISPはSPIを使っているが)。 ソースを眺めていても良く理解できない。

 そういうこともあって、SPIの勉強を兼ねて、将来このコントローラを外部から動かすことを考えて、正規のMACアドレスをジャンクのPC用のNICカードから拝借することにした。自宅、会社で使わなくなったNICカードをISAバス時代から残してあり(別にこれが目的ではなかったが)戸棚から出してみたら4枚も出てきた。何とこのうち3枚がお馴染みのEEPROM、93C46(DIPとSOIC)とそのコンパチ(HT93LC46)を使っていた。

 ISAバスのNICカードはさすがにもう使わないだろうと、このカードから93C46をとろうとするが、これが難しい。ピンまわりの半田溜まりが結構深く小さなこてでは、簡単にはとれない。ピンの半分近くを折ってしまってやっとのことで取り出す。ピンに細い線を半田付けしてソケットにつけなおし、早速SPIを組んで、データを取り出そうとした。0713_93c46

 Megaには標準のSPIがあるが、これまたへそ曲がりが出て、わざわざTiny861でUSIインタフェースを使う。I2Cの経験がものを言ってこのときのロジックを大幅に拝借し思いのほか早くできた。I2Cに比べれば格段にプロトコルは簡単である。ただ、読み書きが2バイト単位なのが少しややこしい。

 93C46のデータシートはWebに沢山ころがっている。問題はどこにMACアドレスがどういう形で収容されているかである。幸い、このあいだ買った参考書にNE2000互換のNICチップが使うデータマップがでていたので、これが参考になりそうである。

 最初、うんともすんとも言わなかったが、USIのシフトレジスタの設定をいじっていたら、突然動き始めた。このへんがUSIインタフェースが難解だといわれるところだろう。クロックの作り方に関して非常に自由度が高いのだ。システムクロックでも、タイマでも、外部からでも、何でも駆動できる。今のプログラムは、Atmelのアプリケーションノートを参考にしているが、これなどUSICRという制御レジスタをアクセスするだけでクロックラインが上下する。

 うんちくはさておき、データが出たので間違えて消してしまったときのためすぐ記録する。このNICカードはISA時代なのでP&Pの会社情報などは入っていなかった。OUIというコードをWebで探したら、台湾製のノーブランドのカードのMACアドレスは韓国籍の会社が取得していた。

 謎が始まったのはこのあとである。機嫌よく何度か、EEPROMの中身をダンプさせていたら、おかしなことにデータが段々消えていくのである。えー、読むだけでデータが消えてしまう?そんな馬鹿な。コードを調べたら、1Kビットを1Kバイトと勘違いして、ありえないアドレスまで読みに行っていることがわかり制限内にもどすが、後の祭り。データはすべてAll 1(0xFF)で埋め尽くされた。

 この段階で、開発が終わったのは読むだけの処理であった。急いで書き込みの処理を加えて動かしてみる。うむ、ちゃんと書ける。最初の読み返しでは正しく書いたデータが表示される。ところが何回かすべてのデータを読み出す読み出しをやると、データが崩れてくるのである。今までの常識が音を立てて壊れる。こんなことってデジタルの世界であるのか。

ミステリーは解決。深刻な勘違い(3/22/08)
 暗い気持ちで朝を迎えた。躁鬱(そううつ)の性格なものだから、ものごとがうまくいかないと周りがみな自分に敵意を持っているような気がして、暗い海をひとりボートであてもなくさまよう気分になる。寝ながらあれこれ考えて朝食もそこそこに地下のPCのおいてあるオーディオルームにこもる。

 昨夜までわかっていることは、64バイトまでのアクセスがすべて順調で、それ以降のアクセスで異常になることが確認できている。64というのが臭い。1Kビットだからちょうど半分、64を越えるとバイナリでは1つ、位が上がる。うーむ、何かありそうだ。念のため、ロジックアナライザーで65バイト目を読み出しているアドレスを調べてみた。なにい、コマンドがREADの10でなく、ERASEの11になっているぞ。しかしアドレスは正しく65だ。

 あれ、アドレスフィールドが6ビットしかない。しまった。このアドレスは2バイトのワードアドレスだった。64以上のアドレスは0にもどり、ビットが繰り上がって、READコマンドはERASEコマンドに変わってしまう。write enableをかけないと消去はできないはずだが、現象はERASEコマンドを出したと想定するとピッタリ合致する。そう言えば、きのう65バイト目を書き込んで0バイト目が消去されていた。

 データシートを穴があくほど読み直したが、このアドレスがワードアドレスであるとは何処にも書いていない。まあ、6ビットしかアドレスフィールドがなくて128バイトを読み書きしようというのだから、バイトアドレスでないのは自明なので、どこにも表記がないのだろう。それにしても深刻な勘違いだ。

 二つ手に入れた93C46のMACアドレスはすべて消されてしまった。いや、待てよ。これまで読んでいないデータはERASEの範囲からはずれている、残っているはずだ。これまでのデータは記録してある。早速プログラムをワードアドレスに修正して読み出してみた。あった。今まで読んでこなかったデータが出てきた。

 今度は、MACアドレスの解読である。どうも2つのカードともNE2000互換ではなく、参考書どおりのデータ配列でない。リトルエンディアンかどうかもわからない。しかたがないので、OUIのデータベースを繰り返しサーチし、シリアルナンバーがそれらしい(00が続かないなど)組み合わせで2つ取り出した。これまで韓国と日本の企業だったが、今度のは2つともアメリカ産になった。まあ、これはいんちき臭いので、外に出すときはMACアドレス書き込み済みのEEPROMを買おう。

 ということで、93C46の怪は解決した。SPIインタフェースの勉強にはなったが、やはりすべて自分の勘違いによるものだった。暴走ではないかと疑った93C46のみなさま、御免なさい。アドレスというとバイト単位という思い込みが今度もトラブルを呼んだ。自戒、自戒である。

電源部を考えている(3/27/08)
 LANによる電源コントローラは最終目標を、離れたところにあるレーザープリンターの電源を、HTMLで入り切りすることにしていた。 CGIでも書いて何か入力させると言うのならまだ先があるが、特に考えられる応用がない。単に電源を開閉するだけなら、今のコードで十分間に合う。SPIインタフェースを勉強したけれど、ソフトに手を加える余地はもうないのだ。

 こうなるとあとは電源部である。こういうこともあろうかと秋月で15A以上を入り切りできるSSRを買ってあった(¥250)。当初は、今さらリレーでもあるまいと思っていたのだが、説明書を読むとSSRはかなり大きなヒートシンクをつけないと、10A以上は無理だと言うことがわかった。今考えているケースには入りそうもない。レーザープリンタは定格が1.3KW、13Aも喰うのだ。急遽、リレーを探した。15Aを開閉できるリレーが千石で売っていることがわかる(¥350)。小さいし(25ミリ×13ミリ)、消費電力もわずか0.5W。なんだやっぱりリレーの方が合理的だ。

 問題は、コントローラの電源である。イーサネットは結構電流を食う(実測で130mA程度)ので電池というわけにはいかない。ところが裸のスイッチング電源に適当なのがない。売っているのは、30W以上の大きなものばかりで、このコントローラの予定消費電力3W程度のものは、ACコンセントと合体したアダプタタイプのものしかない。秋葉であちこち店を覗いたが、どれも最低でも10Wクラスからだ。アダプタで動かせば良いのだが、外に出るケーブルが増えるのは嬉しくない。

 考え付いたのが、ケースにコンセントをつけて、アダプタを中に入れてしまう方法だ。これなら、アダプタを固定する手間も省ける。買ってあったタカチ(SS-125 80×32×125)のケースを見ると、おあつらえ向きに間仕切りのスリットが中に入っていてここに適当な板をはさみ、ここにACプラグをつければACアダプタが固定される。間仕切りで高圧のAC部との隔離もできる。 我ながらうまいアイデアだと思うが、他の人はどうしているんだろう。

 LANコントローラの心臓部の基板に、半田付けの不備が見つかった。このあいだからモジュラジャックの橙色のLEDが点いたり消えたり不審な動きをしていたのだが、ウレタン線の半田付けの不良だった。こいつ、しっかりついているように見えるので用心しないといけない。これで2回目である。

 Mega168が5Vで動かないトラブルもあっけなく解決した。よく考えてみたらクロックをNICコントローラから貰っているが3.3Vなのだ。これでは不安定になるのは当たり前だ。一番最初の電子工作のとき買ってあった74HC126(シリアルISP書き込みアダプタの時に使ったラインバッファ)でクロックなどいくつかの信号線をレベル変更したら、全く問題なく動作した。

これで後顧の憂いはなくなった。あとは電源部の実装と、メイン基板の制作である。

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

2008年8月27日 (水)

Mega168インターネット開通

NIC基板の実装進む(3/11/08)
 休みをはさんで4日連続の研修講師を何とか終了し(いや、喉が涸れた)、晴れて電子工作に専念できる体になった。アートワークは、研修資料の準備の合間をぬってとうにすませてある。USB-SPIブリッジよりはるかに複雑なパターンになっているが、少しづつ半田付けが進んでいる。このチップは電源ピンが各ブロックごとに独立しており、そのグランドと電源の間単位にパスコンをつけなければならないので結構大変である。Nic_artwork

配線図に0.1μFが5ヶ並んでいるのがそれなのだが、最初、5つまとめて0.5μを買ってくるというお馬鹿なことをやった。やっとのことで搭載すべき部品はすべて半田付けが終わった。あとは信号線を引き回す工程が残るだけである。基板の穴を殆ど使い尽くし、パスコンが10個近く点在するさまは壮観である。

 嬉しくなって、家族に見せて回る。勿論、馬鹿にされる。しかし美しい。昔飛行機のソリッドモデルを木から削りだし、綺麗に塗装した模型を何度も何度も取り出しては悦に入っていたことを思い出す。それにしても安上がりな趣味だ。部品代で¥1100するかしないかである。鈴商で入手したチップビーズもきれいに基板上に乗っている。

 ソフトの方も、薄紙をはがすようにわかってきた。MACアドレスをどうするかが課題だが、内部で使う限り、あまり心配することはなさそうだ。そろそろテスト手順を具体的にする時期かもしれない。

NIC基板動く!(3/13/08)
 狭い道の離合で後ろも見ずにバックしてきた車に逆オカマを掘られ、気持ちはブルーなのだが、電子工作は絶好調である。このところ熱中してきたNIC基板のすべての配線が終わり、いよいよ動作テストの段階に来た。きのう、電源を逆にさして危うくこのあいだの二の舞になるところだったが、今度は慎重に確認し、ENC28J60をソケットに挿して通電する。

 やった!ハブのインディケータに10Base/Tのノードが接続されたことを示す橙色のLEDが点る。基板側のLEDは時々緑のアクセスLEDが点滅してパケットを拾っていることを示す。配線の間違いはなさそうだ。今度もパーフェクト。少なくとも、NICチップのENC28J60のEtherNetまわり(PHY層)は完全に動いている。Enc26j80

 いや、良くここまできた。配線技術は格段に進歩した。アートワークを完全にやっているのが誤配線をしないで済んでいる原因だろう。一段落して、これまで作ったシリアルISPアダプタから、温度ロガー、LCDドライバ、USB-SPIブリッジをテーブルの上に並べてみる。実装密度は最近のものほど高く、今度のNIC基板は自分でも惚れ惚れするほど精密な出来だ。

全部を並べると、最初に作ったISPアダプタの配線の稚拙なことA3141204_trimaが良く分かる。このときは0.16ミリのUEW線だからコンパクトにいくらでも作れるのに、DSUBピン あたりは配線の引き回しが下手で空中配線になってしまっている。いい加減な配置をした結果である。

 さて、ここからはソフトの世界に入り、次はMegaまわりのTCP/IPスタックの開発である。オプティマイズのページでは、Mega168ではほとんどアプリが乗らないということだったが、HTTPプロトコルを使ってフラッシュサイズがMega168の半分しかないMega88で、HTMLベースのコントローラがちゃんと動いている例が、少なくともウェブに2つ(日本とドイツ)掲載されている。

ドイツ(http://tuxgraphics.org/electronics/200611/article06111.shtml)
日本(http://www.kannet.ne.jp/tomaru/kenkyuushithu/hardware/webac/webac.htm)

 どうも3つともオリジナルはSCU(サンタクララ大学)の人の書いたこのNICチップのドライバーソース(http://hubbard.engr.scu.edu/embedded/avr/avrlib/docs/html/)をモディファイしているようで、上位のTCPスタックを絞りこんで小さくしているようだ。 しかし、どこかのソースを落としてきて、コンパイルしました。入れました。動きました、では、どうも面白くない。といってスクラッチからNICチップのドライバを書いていくパワーもないし、あまり意味もない。

 とりあえず、NICチップのドライバレベルは皆さんと同じように利用させてもらって、上位レベルを自作してみようと思う。UARTを使って色々なコマンドを送り反応を見たいのだが、どのレベルで切り分けるのが面白いのかまだわからない。もう少し調べる必要がある。

HTTPサーバーが動いた!(3/17/08)
 完成したNIC基板がPHY層(電気物理層)まで動いていることは、確認された。次はファームウエアのソースである。インターネットを通じて電気機器を制御するシステムの回路図の中では、ドイツのWebのものが、一番簡単そうなので、ソフトウエアもこれをベースにすることにする。サイトからソースをダウンロードし、試しにAVRstudioに入れてコンパイルしてみたら、これがあっさり通ってしまったのである。

 こういう海外のソースは、コンパイルしてみるとコンパイラ環境の違いで色々エラーが出るものである。まあ、エラーをなくそうと手を入れている間にソースの中身も理解できるというメリットもあるが、コンパイルが通っても動かないというケースが多い。

 本当はNICのSPIインタフェースのドライバーから作るのが筋だけれど、全体のコンパイルが余りにも簡単に通ったので、ホスト(Mega168)との接続も彼の回路と同じにして動かしてみたい欲望にかられ、止めることが出来なくなった。

 もっとも回路図は少し変更した。オリジナルはすべて3.3Vベースだが、ホストを5Vにして、Mega168のクロックを20Mhzにした。これは、オプティマイズの言うSPIインタフェースを8~10Mhzの範囲で動かせ(マイクロチップ社のERRATA情報による)という指示で、SPIのクロックをこの範囲で動かすにはMega168では5Vにして2倍の16MHz以上のクロックが必要だからである。この時点では、日本のオプティマイズの方を信用していた。ENC28J60は5Vトレラントなのでとりあえず直結しても大丈夫なはずだ。

 NIC基板の配線に比べればホストとの接続は気が抜けるほど簡単でブレッドボード上にすぐ完成した。ファームウエアはデバッグ用にUARTを組み込んでもフラッシュサイズは4 キロバイトあるかないかである。勢い込んでLANケーブル、デバッグ用にUSBシリアル変換モジュールで標準UARTをつないで電源をいれてみる。ISP-UARTが一番簡単だが、SPIインタフェースはこのISPを使うのでデバグには使えない。

 しかし、最初は動かなかった。UARTを入れてメッセージを出させると、初期化は出来ているものの全くパケットを拾っていない。たまに受け取るが、自分宛ではないので無視している。pingをPCコンソールから打つと、一瞬LEDがつくので下位レベルは動いているようだが、本当にNIC(ENC28J60)がまともに動作しているかは確認することが出来ない。SPIドライバも作っていないので、何から手をつけて良いのか見当がつかない。この日も夜中の2時をすぎたので作業をやめる。

 次の日、事務所に出て、仕事を早々に片付け、pingの仕組みをあらためて勉強した。NICとMegaとのやりとりがあれば、MegaはIPアドレスをNICを通してPCに返しているはずである。つまりARPが動いているかどうか調べる必要がある。調べてみたらUNIXだけでなく、WinXPにもARPコマンドがあって、PCのARPテーブルが出ることがわかった。帰宅して早速テストすることにする。

 pingは全く受け付けていないことがわかった。では何故、LEDが点いたのか、わからない。ネットワーク関係の調査はこれくらいにして、基本的なことから始めることにする。ソースのENC28J60のバージョンコードを出力させる関数が見つかったので、それを動かしてみる。00が表示され、ENC28J60はやはり動いていないようだ。

 やれやれ、始めからやり直しか。待てよ。3VならNIC基板で作っている。NICのコマンドのドライバーを作り始める前に、ドイツのWebの回路図のとおり動かしてみて動かなかったらソフトの準備をしよう。ブレッドボードをいじって回路図のとおり、MegaのVccをNIC基板の3.3Vから供給するようにし、クリスタルを取り外し、クロックピンにNICのクロックラインを接続する。少し配線変更が必要だったが、ものの1時間もかからない。これでMega168は25Mhzの半分のクロック12.5Mhzで動き、SPIはまたその半分で動くはずだ。

 MicroChip社のエラータのturn around(回避法)のところに「SPIを8~10MHz以外で動かすときは、ENC28J60のクロックと同期させること」という説明を事務所で読み、急にこのドイツの回路に信憑性があるように感じたのも、この回路図にこだわった理由でもある。

 はやる気持ちを押さえてスタートさせる。PCのデバッグ画面にバージョンコードが04と表示される。うむ、前とは違う。うまく動いている予感がする。急いでブラウザーを立ち上げ、NICのIPアドレスを打ち込む。Lan

 動いた!Webの情報の通りの画面(といっても文字だけだが)が出た。クリッカブルになっているSWITCHの文字の上をマウスでクリックする。見事、テスト用のLEDが点灯した。遂にGataro研の組み込みコンピューターがインターネットと会話した瞬間である。UARTにも自分宛のパケットを受けとったというメッセージが並ぶ。早速ソースをいじって画面のクレジットの表示を換えてみる。ちゃんと換わる。当たり前のことだけど無性に嬉しい。妻に報告するが当然のこと予想通り何の反応もなし。娘だけが少し喜んでくれた。「で、これでプリンタの電源入るのね」と画面のスイッチを押しそうになって、あわてて事情を説明する。

 動いてしまったので、ちょっと予定が変わったが、メモリサイズがまだ、1/4のわずか4キロバイトに留まっているので、この先が楽しみだ。メモリが128キロあるMega128が¥1000程度で、このあいだTQFP64ピンの変換基板も手に入れたので(送料が価格の半分近くだったけど)、これを使えば相当のことができそうだ。

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

イーサネットのENC28J60

NICチップを買ったぞ。もうあとには戻れない(2/25/08)
 調査の原稿3本を事務所で手早く片付けて、今日は久しぶりに秋葉の秋月に寄る。 あれこれ考えていたが、やはり次期の開発対象は、ロボットでなくEtherNetにすることにした。EtherNet経由の電源コントローラは、家族の要望もあるし、部品も入手しやすい。ただしソフトウエアは相当な量になり自主開発は恐らく不可能で、ネット上のオープンソースに頼らざるを得ない。

 色々調べた挙句、結局マイクロチップのENC28J60というSPIインタフェースを持ったNIC(ネットワークインタフェースコントローラ)チップ(\600)を2つも買ってしまった。あわせてパルストランスの付いたモジュラージャック(\300)も購入、合計¥900。DIPソケットというのが良い。PIC向けには色々ソフトが用意されているようだが、AVRは商売敵だから何も用意されていない。しかし、Webには、フリーのAVR版ドライバが結構出回っていて、スクラッチからコードを書かなくてすみそうである。

 例によって2組買って¥2000近い投資。電子工作の世界ではもうあとにはもどれない高額の投資である。気の早いことに電源のON/OFFは秋月の25Aまで流せるSSRキットも準備してある。このヒートシンクをついでに買ってくる。これから少しづつ資料を集めていくことにしよう。今度の山は相当、難度が高いと思うが、やり甲斐のある目標であることには間違いない。

ボタン電池が空(から)になっている!(2/26/08)
 久しぶりに温度ロガーを動かして、温度が正しく表示されないのに気がついた。もう電池がなくなったのか、いや、LEDは1秒ごとの点滅を少し暗くはなったが正しく繰り返し、PCにつないでみてもちゃんと応答して、時計も正確だ。

 まさかと思いながら、ボタン電池で昇圧している温度センサーの電源電圧を測る。なんと、2Vしかない。MCUの電源電圧より低い。そんな馬鹿なとボタン電池を取り出して測ってみると信じられないことに、マイナス電圧が出ている。考えられることは、スイッチを切った後、MCUを通して流れる漏洩電流で、ボタン電池が昇天したことである。試しに、新しいボタン電池を入れて電源を切った後流れる電流を測ってみた。なんということだ。1.4mAも流れている。ボタン電池は、温度ICの動作電圧4.5V以上確保するため、Vccと、温度ICの電源の間に接続されており、電源スイッチを切っても、ここはつながったままである。冷静に考えれば、確かに電流が流れる可能性はあるが、これほどまでとは思わなかった。A3041171

 皮肉なことに、電源スイッチを入れると、ボタン電池の消費電流はマイクロアンペア以下のほぼ0になる。切ったあと1.4mAも常時流れれば、200mAhくらいしかないボタン電池はあっという間に消耗してしまう道理である。USBのバスパワーが信号線を通して流れ込む経験をして学習したはずなのだが、半導体の難しさをまた認識させられた。こちらはハイインピーダンスの真空管、トランス育ちなので、どうもこのあたりが無神経になる。

 双極双投のスライドスイッチを急遽、部品箱から見つけ出し、ロガーのボディにとりつけ、ボタン電池も電源を切ったときMCUから切れるようにする。こういうときは、ミニルータのおかげで、穴あけが大変楽になった。

USIインタフェースを使ったソフト(マスタ、スレーブとも)I2Cの完成
(2/28/08)
 最初の温度ロガーでUSIインタフェースを使ったマスター側のソフトウエアを開発し、このあいだのLCDドライバーでスレーブ側のソフトが完成したが、まだ双方で動くことは確認していなかった。コードを公開するからには、これは是非やっておかなければならない。まあ、両方ともAtmel社のアプリケーションノート(AVR310 、312)のソースがオリジナルだから、あまり威張れる筋合いではないが、AVRのソースにはマスターもスレーブにもバグがひとつづつあり、あのままでは2つとも動かない。それにあのコードは変数の名前が無闇に長く、とても読みにくい。まあ少しはお役に立てるだろう。

 確定申告も、研修の資料の準備も終わったので、始めることにする。これまでのソースにソフトI2Cのマスターだけをテストするプログラムがあったので、それにLCD関係のテストに使ったコードをコピーして動かしてみる。いくつかのコンパイルエラーを直すだけで、これは一発で何の問題なく動作した。このあいだのUSB-SPIブリッジの時のパーフェクトゲームほどではないが、気分が良い。このUSB-SPIブリッジはこのテスト中、何もしないで自動的に38.4kbpsのUARTになることがわかった。賢い奴だ。

 NIC(ネットワークコントローラ)の資料もだいぶ集まってきた。チップの日本語のデータシートがあるのがありがたい。その日本語も割りにしっかりしている。マイクロチップのユーザー対応がAtmelに比べると格段に優れていると言うウェブの評判どおりのようだ。

PICNICというPICを使った同種のボードを題材にした参考書も入手した(¥3200もしたが)。ざっと読んだ感じでは、レジスタの設定などやることは沢山ありそうだが、それほど難解ではない。特にシリアルのSPIインタフェースになっているので、パラレルでデータバスをハンドリングしなければならないNE2000互換のチップに比べれば開発は格段に楽なようだ。

やっぱりドリルスタンドが欲しい(2/29/08)
 明日からまた2日間の志賀高原スキー行き。準備が済んだので、また地下のオーディオルームで電子工作である。LANコントローラのNIC基板を少しづつ作り始めた。まず、RJ45モジュラーソケットの固定から始めた。いつも思うのだが、なんでこういうソケット類のピン配置の規格は、どれもこれも、ばらばらなんだろう。こういうときのために買っておいた変換基板とも全くあわず頭にくる。

 仕方なく、ユニバーサル基板に穴を開ける。前のDSUBは苦労したが、今度はミニルータに1ミリドリル刃がある。ところがこれがなかなか上手く行かない。刃が折れる心配より、正確な位置に刃を落とせない。センターポンチのようなもので穴を開けても穴が小さすぎ、どうしても少しずれる。しかもユニバーサル基板なので一旦ずれてあけると修正が殆ど不可能になり大穴になってしまう。

 やっとのことでモジュラーソケットを取り付ける。8ピンのハーフピッチずれたところの1ミリ穴はうまく入ったが、固定用の変形穴は片側を失敗し大穴になってしまった。ただ、穴の位置を正確に基板に写すの方法を発見し(一旦紙にソケットを密着させて穴を開けた後、その紙を基板に当てる)たのは収穫だった。この方法で次は綺麗に開けてやる。やっぱりドリルスタンドが欲しくなってきた。

 4×3.5センチの基板(この前のUSB-SPIブリッジ基板の残り)に、ソケットとNICチップを乗せて、全部の部品が載るか試してみる。うむ、何とか載りそうだ。この基板のモデルはオプティマイズのNICアダプタで、(http//optimize.ath.cx/spi_ether/spi_ether.htm) オプティマイズではNICチップが表面実装の小さいものに比べこちらはDIP版なのであれほど小さくは出来ないが、そこそこ小さくまとまりそうだ。

鈴商恐るべし(3/5/08)
 講師を担当した2日連続の講座の前日だと言うのに、仕事帰りに秋葉原に寄る。準備は全部済んでいるし、スキーや、テキストの準備でこのところマイコンに遠ざかっていたので足が自然に向かってしまうのだ。NIC基板の部品を揃えるためである。

 コンデンサや抵抗は千石電商で落ち着いて選び(秋月は慌しい)、クリスタルは秋月が千石の半額なので、秋月で買う。残るは、オプティマイズの回路図で唯一緒元のわからない部品、チップビーズである。秋月では¥2000もするセットでしか売っておらず、1つや2つのためにこれを買うのはばかげている。海外のページでは、フェライトコアに何回か銅線を巻くだけで良いというので、フェライトコアを探したら、ちゃんと千石の地下にあり、これを買う(@¥50)、いやさすがは秋葉原だ何でもあるなと感心して、時間があったので、近くの鈴商という部品屋を覗いてみた。昔はジャンク屋だったはずだが、小奇麗な専門パーツ店になっている。これがなんと驚くことにチップビーズをバラ売りしていたのである。

 それも、1ミリ以下の豆粒のようなものから、何個もならんだフェライトアレイのようなものまで品揃えも豊富で、何を選べば良いのかわからないくらいだ。いや驚いた。恐るべし鈴商である。オプティマイズのWebの写真に近いものを選ぶ(10 ヶで¥100)。今のところ外観しか判断基準がない。まあ、EMI対策の部品なので余り大差はないだろうと楽観している。

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

2008年8月26日 (火)

USB-SPIブリッジの制作

何となくしっくりこない解決(2/12/08)
 chaN氏のUSB-SPIブリッジを作ろうとして、このところ、はまっていた。
最初に作ったシリアルISPアダプタは順調で何の不自由もしていないのだが、AVRマニアのサイトではプログラムライターの話題が盛り上がっていて、やれ鶏卵問題(AVRライタに使うAVRは何で焼く?)だの、0.5ミリピッチのICをつけたの、速度が速くなったのだと、AVR関連のどのサイトに行ってもその制作記が載っている。

 こういうものにこだわるのは、音楽を聴かずに周波数特性にこだわるオーディオファンを連想して余り関心がなかったのだが、秋月で、わずか¥100と聞いて思わず4ヶも買ってしまったTiny2313の使い道に困っていたのと、USBシリアル変換モジュールも予備があることなので作ってみることにした。ウェブサイトに、この秋月の変換モジュールを使った例が見当たらなかったのも作ろうとした動機のひとつである。

 定番のブレッドボードで試作してみる。ブレッドボードはこうした試作には実に便利だ。ジャンパ線でなく単線をボードに密着させて配線すれば、かなり恒久的な装置にも使える。何より変更が簡単だ。ただ、一旦抜いてしまうと元のポイントへ戻すのが厄介になる。

 今回はソースがあるのでプログラミングは必要ない。クロックとボーレートのところだけを直し、久しぶりのアセンブラーコンパイルである。ところがこれが通らない。エラーを見ると、予約語のORをシンボルに使おうとしてエラーになっている。何かいやな予感がしたのだが、いくつかのエラーはコードそのものに余り影響がなさそうなので、すべてコメント化し、とりあえず発振子(7.368Mhz)にあったファームが出来た。

 このUSB-SPIブリッジの仕様書は何と英語しかない。英語はともかくどうも前提が省略されていて、今ひとつ何をやろうとしているのか理解しにくい。AVRSPという私も愛用させてもらっている書き込みソフトのUSB版だと思うが、モードが沢山あり、どのモードで書き込めば良いのか迷う。ソースコードを頼りに色々パラメータを入れて動かしてみるが、どれも冷たく「No spi bridge found」というメッセージで全くの門前払いである。

 UARTのテストステートメントをいれるわけにはいかないので、早々とロジアナを出動させ信号を見る。モードによって多少違うが、PC側から話しかけたとき、正しく答えていないようでもあるし、ときたまターゲットの方に反転したデータを送り出したりしている。制御線の切り替えがあるはずなのだが、ロジアナで見たところでは動きは殆どない。ただ、制御線の論理を逆にすると少し動きが違ったりして、ますます混乱する。

 USBシリアルの変換IC(FT232RL)はオリジナルのICとパッケージが違うだけで全く同じである。このブリッジは沢山の人が作っていて改良版もいろいろあるが、どの制作記でも制御線の反転に言及したサイトはない。研修講師の資料送付の締め切りが近づいてきて、お尻にそろそろ火がついてきたのだけど、何とも気になって2日間これにかかりきりだった。

 配線に間違いがなく、ICも同じ、それでも動かないとなるとこれはこちらでアセンブルしたバイナリを疑うしかない。オリジナルのバイナリが10Mのクリスタルを使っているのを換算し、それに合わせたボーレートにしてAVRSPを動かしてみる。

 何のことはない。オリジナルのバイナリはすんなり動いたのである。フューズビットの読み出し、プログラムの書き込み、何の問題もない。230Kbpsの速さなので書き込みは猛烈に速い。始めFTDI社のUSB変換ICのオプションを変えて動いたので、こいつが真犯人だと思ったが、デフォルトでも全く問題なく動いた。結局アセンブラーのコードがおかしかったのである。何ともしっくりこない解決だった。chaN氏の使ったアセンブラーはAVRstudioのと違うのだろうか。試しにファイル比較のソフトをウェブから落としてきて調べてみたら、確かに数ヶ所違いがある。ボーレートの変更にしては多すぎると思うのだが。

久しぶりに完全試合(2/17/08)
 USB-SPIブリッジがブレッドボードで動いたので、今度は実装して、小さなケースに納める工作が待っている。研修講師の資料作成が思いのほか順調に進み休み前には、ほぼ目処がついたので、週末は工作に専念できた。まず、ミニルータを使って、基板の切り出し、上蓋のUSBソケットの穴あけをすませる。切り出しは楽だったが、穴をあけたあとの削りだしは、やはり支持工具がないと電動は難しいことがわかった。最後は平やすりで整形が必要であった。秋月の変換モジュールのピンヘッダーが高いのでぎりぎりまで切って、ジャンパーも短くする。

 昨日の昼から配線を始める。ケースが小さいので実際の配線の前に部品配置を完全にやっておく必要がある。いわゆるアートワークである。シングルピンのICソケットは有用で、中に抵抗器をいれることが出来る。アートワークも何回もやると要領を覚えて楽になる。結構、綺麗にレイアウトが出来て自己満足する。A2181066

 配線作業そのものは、昨夜2時間、今日、テニスから帰って2時間、家内の誕生日祝いに横浜中華街へ一家で夕食を食べに行き帰ってから1時間で完成した。どきどきしながらUSBソケットを差し込む。 ターゲットボードの電源がUSBから供給されLEDが点灯した。何か焦げる匂いがしないか一生懸命鼻を聞かす。頼りになる五感は今のところこれしかない。PCのDOS画面を出してコマンド(AVRsp)を送る。出た!正常にターゲットボードのMCU情報が表示された。 MCUを換えて見て違うメッセージを確認する。いやあ久しぶりのパーフェクトゲームである。気分は最高。これだから工作はやめられない。A2181062

しかし、ソフト的には納得がいかない結果なのである。あれからchaN氏のソースコードのオリジナルをAVRStudioのアセンブラに通してみてバイナリを比較してみたら全く同じであった。リストを変えたところは、CPUのクロックとシリアルのボーレートで、結果としてはひとつのプリスケール値になってコードに残るはずである。そこで試しにオリジナルと同じプリスケール値になるよう手持ちの発信子に合うボーレートにしてアセンブルしてコードを比較してみた。しかし全く同じにはならない。ただ、このまえの4行から変更行が1行に減った。

 で、これを実際に動かしてみたら見事に動いたのである。???である。これ以上はアドレスとコードが併記されたアセンブルリストでもない限り解析は難しい。これはこれくらいにしておこう。何しろ動いているのだから。まだ、やらなければならないことが沢山ある。

丈夫になったのは良いけれど(2/22/08)
chaN氏にソフトUARTのソース流用の許諾をお願いしたら、2日もたたずに快諾を貰い、公開に向けての準備は整った。それは良いのだけれど、実は、I2Cスレーブのプログラムにはまだ不具合が残っている。最初のうちは快調にデータをLCDに出しているのだが、暫く送信を続けるとタイムアウトが起きてマスターまでハングアップさせてしまうのだ。

 いずれ解明しなければとは思っていたのだが、こういう段々おかしくなるという不具合のトラブルシューティングは難しいもので、そのままになっていた。プログラムのトレースなどツールの完備したPCや大型機の世界でもこの種のバグは焦点を絞るのが難しく、昔から厄介なバグのひとつである。

 ましてやマイコンの世界、シミュレーターはあっても時間がらみのシミュレーションは、その準備だけでも大変で、現実的にはほぼ不可能だし、トレースをとろうにも限られたメモリではいつ起きるか分からないハングアップに備えるには、それなりのプログラミングをする必要がある。もともと余命の少ないTiny26だ。下手にいじるとフラッシュの寿命が来て元も子もなくなってしまう。

 と言って、このままではとても公開できるソースにならない。USB-SPIブリッジが意外に早く順調に動いたので(何となくしっくり来ないけど)、少し本腰を入れてデバッグを始めた。仕事が順調に捗って締め切りより5日も早く資料が仕上がったこともある。

 まず、気になっていた1秒タイマが始終動きっぱなしの問題は、データシートを良く読んで、タイマのプリスケールの設定(制御レジスタTCCR1Bのビット0~3)を0にすればタイマが止まることがわかり、これを修正する。これで、通信が終わったあと割り込みをマスクするだけではハングしていた(原因不明だが)バグは解消した。今までは、必ずタイマを一回タイムアウトさせて次のタイマスタートを送信の開始にかけていた。それでも何回目かの送信でハングするのである。

 この修正で元のバグも一緒に解消されるかと淡い期待がかかったが、それは甘かった。ハングするまでの時間は少し延びたが、相変わらず、10回前後の送信で、まず送信データが表示されなくなり、次のマスターからの送信でマスターもハングする。ハングする理由はわかっている。I2Cのスレーブ側の唯一の抵抗手段、クロック線(SCL)をLowにしたままにしてマスターが送信してくるのを待たせる手段、クロックストレッチがかかったままになり、マスターがデータを送れなくなるからである。

 しかし、USIインタフェースを使うスレーブ側のソースにはSCLをLowにするステートメントは何処にもない。USIインタフェースのシフトレジスタが制御している。下手にSCLを強制的にLowを解除するようにしたら(簡単に出来るけど)、系全体がおかしくなって通信そのものが出来なくなる恐れがある。

 タイミングチャートを作り、ソースを入念に追う。ソースは一応機能レベルを3段階にわけ、アプリケーションに近いプログラムでは全くI2Cのことを知らないでデータ受信が出来る構造にしてある。従ってプログラムは必然的に非同期で動いている。このあたりは時間の経過に気をつけないと、考えたようには動いてくれない。MCUのクロック(4000KHz)と、通信速度(100KHz)の差を十分考慮する必要がある。大差はあるようだけど、ソースはアセンブラでなくCだ。割込みのオーバヘッド(数十クロック)を考えると1/40の差はすぐ埋まってしまう。

 通信の開始(スタートコンディション発行)から始めて、遂に怪しいところを見つけた。データが受信バッファに入り、アプリケーションがデータをLCD用のバッファに移すところで終了条件を聞いている。こいつはループになっていて必ず最初に終了条件を聞く。USIインタフェースは非同期に動いているので、もし、バッファに移す前に終了条件が送られてくると、バッファにデータが渡らない内に受信シーケンスが終わってしまう可能性がある。

 これだ。こいつが最初にデータをとりこぼす原因だ。完全にデータを読み終わるまで、バッファ移動はしない構造に改めることにする。 I2Cには、マスタが送ってくるデータがいつ終わるかをスレーブが判定できないという問題があり、このプログラムでは、終了条件をひたすら待って、データ受信を終わらせている。スレーブからNACKを送って終わらせることも出来るが、これは上位のプロトコル(固定長か、レコード長を最初に送ってくる)が決まっていないと出来ない。

 UARTのときもそうだったが、私にはどうも同時処理にこだわってプログラムの構造を複雑にしすぎる癖がある。長い間OSの元で開発してきたからCPUを専有するのに罪悪感があるのだ。昔は、複雑なロジックを作り長いループにしてしまって他の人に迷惑をかけてよく怒られた。マイコンがやるように、I/Oが終わるまで、ループして待つなどもってのほかだったのだ。

 郷愁にふけっている場合ではない。早速、ベタに終了条件を待つ方式に変えてテストしてみる。おお、良さそうだ。やっと直ったか。これで公開しても大丈夫だな。それにしても手間をとらせたな、と機嫌よくテストを終わろうとして、最後に、念のため、最大サイズ(32文字)の連続テストをやってみる。

 出た。画面をクリアする。あれ、クリアされない。しかし、次のデータを送信するとLCDには表示される。クリアなどの1文字コマンドだけが動かない。テスタを信号線に入れてみると、コマンドを送ったあと、さきのクロックストレッチが発生するが、1秒タイムアウトのおかげで初期状態にもどり、信号線はHighになって開放される。

 やれやれ、1文字コマンドは効かなくなるが、丈夫なLCDドライバーにはなった。マスタをハングアップさせることはない。1文字コマンドが動かなくなるのはバッファがオーバフローして、どこかを破壊しているからだろう。まあ、これはぼちぼち調べるとする。

何度同じ間違いをするのか情けない(2/24/08)
 1文字コマンドがうまく動かないのは、次の日ロジアナを持ち出して、余計なデータが送られていることを確認した。マスターのMega168はテストマシンということですべてやっつけコーディングで用をたしている。I2Cの場合はデータの送り方が厳密なので本当はまずいのだが、そうそう集中してコーディングは出来ない。

 ありあわせの関数でデータを送るのをやめ、LCDドライバ用にちゃんとしたwrite関数にしたら、ピタリと症状はおさまった。これですべて想定した機能は動くようになった。少々乱暴なデータを送っても、今度は1秒タイムアウトですべてをリセットする機能がついているので安心である。残っているといえば、スレーブの電源を止めたときにI2Cそのものがハングすることだが、これは仕様の疑いもあるのでもう少し先送りする。

 ただ、心残りは何故これまでのコマンド送出でハングし、修正によってうまく動いたのか理屈が通らないことである。動かない時との違いは、データの最終をあらわす改行記号(0x0D)が2つか1つかのところだけである。プログラムは読んだデータが改行ならば、これまでのデータを受け取り、それ以下は消してしまう。2つあることは何の関係もないはずなのである。

 まあ、動いているのだから良しとしておこう。確定申告締め切りの時期が近づいてこまごまとした伝票の整理に飽きて気晴らしに、LEDを順番に点けて遊ぶ回路をブレッドボードで作り始めた。こういう手作業が何と言っても一番紛れる。

 LEDだけでは面白くないので、点滅間隔をUARTから変えられるようにする。2313のピン配置は26とは全く違うので結構手間がかかる。回路組み立てに1時間、プログラム開発に1時間、軽く動くはずが、これがまた動かないのである。やれやれ。

 送信は動いて初期メッセージを表示するが、キーボードからの受信が出来ない。LEDを挿入するが、受信のピン割り込みが起きていない。2313は26と違って261や861と同じようにピンチェンジ割込みを個別のピンに限定することが出来る。26でやったように送信のときの割込みのマスクや、割込み要求フラグを消して回る手間が省けて楽なのだが、レジスタの名前が違っていたりしてややこしい。データシートを隈なく読むが、動かない原因がわからない。気晴らしのつもりがかえってストレスが溜まってしまう。夜中も2時をすぎたので寝ることにする。

 翌日、確定申告をやっとのことで下書きまですませたので、AVRに戻る。デバッグはこういう気分転換が効果的なようだ。ソースを最初から流してみてLEDのポート番号が実際と違うことに気づく。最初の石、26のピンアサインが頭にこびりついていて間違っていた。2313のピン番号は下から上に増えていくのである。

 あわてて修正し動かしてみる。何のことはない。LEDはキーボードを押すと点灯するではないか。ちゃんと割込みがかかっている。ISPのUARTは正論理なので1を確認してデータを読みに行くはずだと次のステートメントを確認する。あっ、またビット5を1で比較している!!やれやれまた同じ失敗だ。何度同じ間違いをすれば済むのだろうか。これで3度目だ。しかも前と全く場所なのである。

 また、弁解めくが、要するにLEDの番号違いというミスが重なったため、究明の方向が狂ってしまった。デバッグの時のひとつひとつの確認の大事さが身にしみる。

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

2008年8月24日 (日)

やっぱりボクが悪かった

I2C経由のLCDドライバー完成(2/3/08)
 ニセコの深雪を堪能し、命の洗濯をして朝起きてみたら、東京も雪だった。やることは沢山あるのだけれど、4日も空けたマイコンいじりに自然に手が行って、食事もそこそこに作りかけのLCDボードの配線を急ぐ。ひとつひとつは無機質な部品を半田付けでなどで固定していき最後は何らかの機能を持った製品にするという作業は、どんなものでも理屈ぬきに楽しいものである(プラモデルなどが最たるものだ)。A2161040

 配線が一番綺麗に出来るレイアウトにしてスキーに行く前にそこだけ配線し、テストしてみたらこれが逆順だったことがわかり頭を抱える。ピンを迂回させて何とか形にし、遂に正月以来制作していたLCDドライバーが完成した。I2Cの3線でLCDを表示することができる。お笑いは今これを使う目的がないことなのだが、フラッシュROMの寿命の近い、始めて買ったマイコンチップTiny26 の安住の地としてはふさわしい。これで2台のシステム(というのか)を完成させたことになる。(ISPライターを入れれば3台)。  

 次の課題は、2313を使ったUSB-SPIブリッジ、SDカードライター(ソケット基板を買ってある)あたりを予定している。イーサネットドライバはちょっとまだ敷居が高い。TCP/IPプロトコルの学習には最適だと思うが、コードを自前で書くところまでは行けまい。既存のフリーのドライバがあるが、それをインストールするだけではつまらないし、あまり勉強にならない。

とうとう犠牲者が出た(2/4/08)
 当GataroAVR研究所(gataroken)は発足以来、一人(ひとつ)の事故(おしゃかにする部品)も起こさず、LEDの点滅から2線インタフェースによるMPU接続まで実現してきたが、本日遂に最初の犠牲者が出た。それは秋月で買ってきた低ドロップ型3端子レギュレータ(¥100でコンデンサつき)である。

 今までのAVRはすべて電池で動いてきた。電池では火事を起こすほどのパワーはないので安心だし、最近は低電力化が進んでいるので実験に不自由しない。商用電源からとるDCアダプタはもう今は使わないモデムやハブなどのPCの周辺機器のものが山ほど残されているが、ユニバーサル基板やブレッドボードに簡単につけられるDCアダプタのソケットがなく、スイッチング電源そのものに何となく不安を感じていた。こいつはテスタで測っても、電流が微小のときは正規の電圧を示さないやつもあるので安心できない。

 ところが、このあいだ秋月の近くの千石電商でソケットをユニバーサル基板につけられる変換基板を発見し、ちょうどLEDを沢山使ったアプリケーションを考えていたときだったので、早速入手し(2つで\550は少し高いけれど)電池の消耗を気にする必要のないACからのVcc供給を始めることにした。

 定番の3端子レギュレータとコンデンサをその変換基板につけて、この基板をブレッドボードに挿すだけで5Vを安定供給できるようにする。今から考えれば、もう少し事前に調べてから半田付けするべきだったのだが、レギュレータは以前何度か使ったことがある。入出力さえ間違えなければと気楽につけて早速動かしてみる。

 これが5Vを示さないのである。DCアダプタが供給する6V(正確には6.8Vもある)から1Vしか低くならない5.5V内外の出力である。おかしいなと別のDCアダプタ(9V)を試しに挿してみたとき、一瞬、基板から淡い煙が見えた。「やった。これは壊した」。試しに手で触って余りの熱さに飛び上がる。しっかり火傷をしてしまった。

 何か誤配線をしたに違いない。変換基板を確かめる。ソケットから出ている端子に間違いなく入力が接続され、使われていない端子を利用して出力側としそこへ電解コンデンサが配線されている。間違いはない。プラグをはずしてテスタで導通を見ると、何と、入出力が短絡されている!そんな馬鹿な。

 あわてて、まだ半田付けしていないもうひとつの変換基板をブレッドボードに挿して、実際の電圧を測ってみた。これが何と言うことか、今まで出力だと思っていた端子に電圧が出ている。ソケットから直に出ている入力端子(と思われる)は0V。あれえ、さっき導通していたはずなのに、これは一体どういうことなんだ。

 知らないということは恐ろしい。Webで調べてDCアダプタのソケットは、3本端子が出ており、そのうち2本はプラグをさす前は、オーディオのRCAジャックのようにもう一方の端子と導通していることを知った。信号線でもないのになんでこんな仕様なんだろう。理解に苦しむ。(その後、電池との切り替えのためと知りました。無知とは恐ろしい)

 つまり最初、テスタでプラグの接触するところと導通していることを確認し、基板のパターンも入力だと思われた端子は実は、プラグを挿入したときに切れる出力(というか空き端子)側だったのである。空き端子と思われた端子が実際のソケットからの出力、つまりレギュレータの入力側であった。

 この誤解によって、逆接続されたレギュレータは苦しんだ挙句、9Vを喰らって遂に昇天したのである。可哀相なことをしてしまった。もしかしたらと淡い期待を抱いて、変換基板からはずし、ブレッドボードで正規の配線に戻してみたが、3V余りを出力する単なる抵抗器に変わり果てていた。事前に良く確かめずにつないでしまった俺に全責任がある。悪かった。許せ。合掌しながらゴミ箱に埋葬した。

 私は電子部品はよほど高いものでない限り、検証と予備を兼ねて必ず2つ以上買うことにしている。レギュレータも2つ買ってあったので、もうひとつを正規に配線する。正確な電圧(4.99V)でLEDを沢山つけても全く温度はかわらない。ごく普通のレギュレータなのだけれど妙に頼もしく感じられたのは不思議なことである。

基板工作の定番ミニルータを買ったぞ(2/5/08)
 次のお題、chaN氏のUSB-SPIブリッジのため、小さなケースを2つ買ってある。最初の温度ロガーの基板とケースや、オプティマイズのロジアナのケースは、ありあわせの金鋸や40年も前に買ったかってのラジオ製作用の金やすりで切り出し、あとは紙やすりで根気よく削って何とかそれなりの仕上がりにした。しかし、いつまでも牛刀をふりまわすのも芸がない。次はまともな工具で楽に作ろうと考えていた。

 最近のブロードバンドサイトでは、世界中のマニアたちが電子工作の出来栄えを見せるだけでなく、製作過程をつぶさに記録したビデオまで公開している。このなかで、ミニドリルで簡単に基板を切り出し穴を開けているシーンが印象的だった。これに刺激されたこともある。 基板を手にとってレイアウトを考えているうち、急に思い立ってDIY店のJ-Martに出かけた。

 千石電商にあったミニドリル(ミニルータと言うのだそうだ)と同じ、Proxxonの製品のコーナーがあり、研削ビット(刃)とセットになると良い値段(1万以上)なので迷ったが、結局、0.5~1.5ミリ(これはすぐ折りそう)のドリルビット3本セットも含めて買うことにした(¥11,500)。ロジアナ以来のマイコン関係の大きな買い物である。

 家に戻って早速試してみる。切断用のやすりディスクを装着のときに力を入れたら、あっさり割れて、セットに5枚も付いていたことを納得させられたが、試しにUSB-SPIブリッジのケースに入るユニバーサル基板を切ってみた。

 いや、これは楽だ。あっと言うまにケースにぴったり収まる基板をきれいに切り出すことができた。1ミリ以下の穴あけはプリント基板でも起こさない限りやることはないと思うが、細かいケースの加工はこれで格段に楽になる。これからの制作が楽しみだ。

 このミニルータはボール盤やフライス盤になるアダプタが売り出されていて、これが結構精密なつくりでそれほど高くなく(一万以下)、道具欲(こういうのがあるか)をそそる。ビットの折れ予防や、正確な穴あけには欠かせないが、まあここまでやることはないだろう。

やっぱりボクが悪かった(2/6/08)
1/17の「今度はボクは悪くない?」の記事で、インタバルタイマをはずしたら動いたので、自分は悪くないと書いたが、?をつけておいて良かった。通信とタイマは密接な関係があり、タイマをつけたくらいで本来はおかしくなるわけがない。恐らく何かのチョンボだと思っていたけれど、原因をつきとめられなかった。それが、解決したのである。

 そろそろI2Cのソースリストを印刷しておこうとI2Cスレーブルーチンのリストを整理していたら、コメントアウトしたタイマーのステートメントがあったので、ついでに少しデバッグすることにした。あのときは先を急いでいたのでそんな余裕がなかったのである。

 まず、タイマを完全に独立させて1秒ごとにLCDに*を出すようにして動かしてみる。問題なく動く。次に、タイムアウトの時に行うI2Cのリセットをやめて通信のスタートでタイマが動くようにする。何と問題なくデータが2回目以降も送られる。何、リセットが問題か。LCDを良く見ると、少しおかしい。*が送信データの前についている。1秒タイムアウトなので、送信データが送られてから暫くして*がつかないといけない。

 タイマがスタートした直後に*がありそれから送信データが表示される。割り込みがスタートの時に起きているのだ。あーあーあ、わかった。何で気がつかなかったのだろう。こんな簡単なミスに。タイマの取り扱いに慣れていないからこういうことが起きる。

 原因はこうだ。1秒タイマはタイムアウトすれば次のスタートまで割込み許可のビットをマスクして割り込みを止める。タイマは一度動き始めると止められない(止めることも出来るが手続きが面倒)。そして、割込み要求を上げつづける。この状態で、次のタイマースタートでこのマスクをはずした途端、待っていた割り込みがここでかかる。

 要するに1秒タイマになっていなかったのである。割り込み先では割り込みを止めるのでもう割り込みは起きない。しかし、割込み要求ビットは上がったままなのでスタートのときに起きてしまう。ここで通信関係のリセットをかければ、当然先のデータは読まれない。これが1回目は動き、2回目から沈黙する原因だったのである。

 原因がわかれば、対処は簡単である。タイマースタートの前に、割込み要求ビットをクリアしておくだけである。たったの1ステートメント。タイマーを使いこなしている人には常識なのかもしれないが、素人の私には、プログラムは書いたようにしか動かないという格言が身にしみる。

 まあ、負け惜しみかもしれないが、よく見つけたと思う。*が送信データの前にあるという些細な事実から、長い間何が原因かあれこれ考えていた不具合が見事に解決された。現場に残された微小な証拠から犯人をつきとめた名探偵の心境で、風呂に入って寝るまでうきうき気分だった。それにしてもこの楽しさは何なんだろう。100冊の推理小説を読むより面白い。

バグのとれたソフトI2Cスレーブのコードは前の「Tiny用ソフトI2Cスレーブ」の記事にまとめて置いてあります。

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

Tiny用のソフトI2Cスレーブ

今度はボクは悪くない?(1/17/08 11:30)
 2日間悩ませたトラブルがやっと解消した。USIインタフェースを使ったTWI(I2C)スレーブの通信である。Atmel社のアプリケーションノートを参考に、スレーブ側の通信ルーチンをこのあいだから作っていた。LCDに表示する通信だから割込みを使わなくても良いのだが、汎用性を考えるとやはり割り込みは使いたい。目茶目茶読みにくいAtmelのソースコード(変数名がやたらに長く日本人には視認性最悪、技巧に走って分岐条件が複雑、丁寧な記述とそっけないハードコーディングが混在)を1週間かけて解読し、動きを理解したところで書き始める。

 最初、割込み部分を最小にしようと考えたが、処理がメイン側と、割込み側で分離され、ソースが読みにくくなる。まあ、商用製品じゃないんだからあとのメンテナンスにこだわることはないのだけれど、メインに持ち込むと、割り込みをとりこぼしデータが化けたりする可能性は高くなる。スレーブ側は、シフトレジスタで送受したあと、クロック線をLowに引いてマスターを待たせることができるらしいが、いきなりこれを実装するのは無茶だ。ということで、意気込んでは見たが、ソースは結局Atmelの構造と同じになってしまった。初めての本格的な、割込み駆動のソフトである。

 細かいミスや、Atmelソースのバグ(スレーブアドレスの末尾1ビットを消すのにシフトしている。このコード、テストをしていないのかも)を修正し、思ったより順調にデータが受信され得意になっていたのが15日夜。ところがこの先がいけない。一旦データを受信したら、それ以降、全く動作をせず、リセットしないと元に戻らない。最初はどこかでループしているんだろうと気楽に考えていたが、どうもそうではない。

 割込み駆動だと、ループしていても割込みだけは受け付けるので、どこが問題かわかりにくい。あちこちにテストステートメントを挿入してみるが、どこも正常である。しかも最初は何の問題もなくデータを受信してUARTを経由して端末に表示されるのに、次からは割り込みを受け付けたという文字が表示されるだけで、がんとして先に進まない。

 ロジアナを引っ張り出してシーケンスを見るが、これは想定どおりの結果である。最初は良くても、次はマスターの呼びかけに全く答えていない。ところがハングした後も別のスレーブ(RTC)の通信は最初ははずすが、2回目以降はちゃんと受け付ける。そして自分のところでないとはねている。こいつ、選り好みをしてやがるのか。そんなことどうしてわかるんだと、親のMega168の送信シーケンスを見るが全く同じ。

 データシートのUSIの説明を読み返す。割込みルーチンにUARTの送信ステートメントを恐る恐る入れてシーケンスを確認する。制御レジスタの中身を表示する。問題ない。そりゃそうだ、最初はちゃんと動くんだから。次の日。見るともなく見ていたkuman氏のページで、シフトレジスタはUSISRという制御レジスタのあるビットに1を書くことで始めて動く(最初は単にステータスを表示するビットだと誤解)という説明で、目から鱗が落ちあわてて修正するが、これも同じ。まあ、これは、今まで不審な割り込みが記録されていた現象の原因と思われるが、何しろ1回きりで次が動かない。これでは先に進めない。

 今朝から寝床の中で、1回目と2回目で状態がどう変わったかという視点で考えているとひらめいたものがある。 I2C通信のところは2回目のときに、全てを最初の状態にもどしている。これで動かないのはもうプログラムではなく、ハードの問題になる。

 しかし、それ以外に違うところがひとつあった。それは、通信の乱れをリセットするために開始条件割込みが起きると1秒タイマーをスタートさせているところである。タイムアウトが起きると無条件にインタフェースを初期化して次にそなえるというしかけだ。タイマーは一旦スタートさせると止められないので、そのあとは割り込みをマスクし、開始条件のたびにタイマーを初期化している。タイマとUSIインタフェースは全く別のハードだから、「こんなの関係ない」のだけれど、もうこれ以外に調べるところがない。

 ほとんど期待もしないで、「そんな馬鹿な」とか言いつつ、タイマースタートのステップを削り動かしてみた。これが、何と、通ったのである! 始めは目を疑った。いや、ちゃんと送られたデータを表示する。何回やっても正常に動作する。一体どういうことだ。これは。タイマーの割込みマスクがUSIにまで影響するのか。

 データをバッファサイズ以上に送るとおかしくなったりするが、とりあえずはスレーブ受信はうまくいった。やれやれ。しかし、いまだに信じられない。よくよく調べてみたらやっぱりこちらの原因だということになるかもしれないが、今度ばかりは俺のせいじゃない。しかし、2日間、よく頑張った。日頃、言っているトラブルシューティングのコツ「原因解明は外へ、外へ」を証明するデバッグであったことは間違いない。

LCD(液晶ディスプレイ)まで到着
(1/19/08)
 I2Cスレーブの泥沼から這い出てからは、早かった。タイムアウトはあとで考えることにして、いよいよI2Cの当面の目的、LCD表示に向かう。このあとは、Tiny26を手探りで動かさなければならないので、慎重に準備をする。プロジェクトを別に起し、そこへ今までのコードを足しこんで行く。まあ、ピンの位置を間違えたり(RTCの場所を動かしてピンをずらすのを忘れる)、UARTとI2Cの読み込み変数を変えるのを忘れて、データが出ているのに動かないので頭を抱えたり、折角、I2Cのピンのセットアップが済んでいるのに、ハードコーディングしたLCDの初期化ルーチンがそこを壊したりなどのミスはあったけれど、ロジアナを出したり、エラーステートメントをてんこ盛りにしてデバッグする手間もなく、泊り込みの調査部会のあとの4~5時間で、待望の他のMCUからのデータがLCDに表示されるのを確認した。嬉しくて思わず拍手をした。A2161043

 お正月(3日)以来の作業である。あとはこれをTiny26に移す工程が残っているが、そう難しい工程ではない。完全に山を越した。USIインタフェースを使ったソフトTWI(I2C)はこれで、マスター、スレーブとも一応完成である。それにしても、Mega168のインストールからずいぶん時間がかかった。まあ、AVR経験3ヶ月にしてはよくやったと思う。Atmelのソースを参考にはしているが、バグを直してあげたし、おあいこだろう。 次の開発目的は、やっぱりEtherNetなのか。USBspiも作っておきたい。

そうは問屋がおろさない(1/22/08)
 もう峠を越した、次は、EtherNetだと気楽に書いたのは3日前だったが、何のことはない。また完全にはまっている。まず、LCDに出す最大メッセージ(32バイト)の出力の最後データが欠けるバグに頭を抱えた。ソフトウエアの開発で一番間違えやすい、臨界点のバグである。アマチュアのプログラムだからこだわることはないのだけれど、精神衛生上良くない。移植する前に完全にしておこうとリストを何度も見返すが、これが悪いところが見当たらないのである。

 C言語は配列が0から始まり、文字列と配列のデータの長さが違う、データ形式も違うなど、文字列の取り扱いはとても混乱する。一字でもはみだすと他のデータを壊して原因不明の障害の元になるので何度も紙に書いて確認するが、間違っていない。はずしかけたテストステートメントをまた突っ込んで洗いざらいデータを出してみると、ちゃんとデータを準備しておりコード上の間違いはなさそうである。どうもI2Cがデータをバッファに溜めこむタイミングと最後のリターン文字をキーにLCDに出力しはじめる時期がぶつかって最初の文字を取りこぼしているような感じである。

 I2Cの速度を落とせば、どうなるかとクロックを落としてみたら、余計データをとりこぼすようになって慌てて元に戻す。非同期処理のバグ取りは本当に難しい。プログラミングの真髄はRobustness(堅牢さ)で、こういうバグは是非取っておきたいのだが、これは本格的なICEなどのデバッガーでないと無理だ。万策尽きてもう寝ようと夜遅く風呂に入っていて湯船の中でふと思いついた。そうだ。何も今の非同期の構造にこだわることはない。LCDにデータを出すだけなのだから、データをすべて受け取り終わるまで待っていれば良いのだ。UARTと一緒に動かしていたから、今の構造になっているが、ベタに待っていれば良い。どうせミリセカンドの世界である。

 次の日、早速プログラムを簡単にし、動かしてみる。何の問題もなく最後の文字まで出力される。やれやれ始めからこうしておけば良かったのである。勢い込んで、いよいよ最終ステップのTiny26への移植作業にとりかかる。てんこ盛りになったテストステートメントや、デバッグでお世話になったUART、それに今は使えないタイマー(これは今度の構造でも前と同じ現象になった)の部分を取り外し、26に合わせてポートの場所を換え(26のUSIインタフェースはISPピンと重なる)てプログラムを作る。サイズも1.5キロバイトまで下がった。念のため861のまま動作確認する。問題なく動く。

 引き出しにしまってあったTiny26を取り出し、コンパイラーをTiny26指定にしてバイナリを書き込む。端末から文字を入力する。出た!と喜んだのもつかの間、後半にゴミデータがついてくる。えー、861とこの部分は何の変更もないはずなのにどうして? 試しに、861に戻すと問題なく表示される。USIインタフェースのデータシートを確認するが、変わったところは何もない。最後の最後で足をすくわれた感じである。

 奇妙な現象である。WinAVRのコンパイラーオプションを変えてみると、字化けする場所が変わってくる。???である。最大の最適化では3文字目から、コンパイラオプションのO1では10文字目からゴミデータとなる。データが多いと1文字だけであとはすべて00データになる。マスターのストップコンディションを発行する位置を変えるだけで字化けどころか文字そのものがでてこなかったりする(これは861でも起きた)。

 よりによってデバッグ用のUARTをはずしてからの現象である。何か馬鹿にされているような気分だが仕方がない。LCDにデータを出してみるが、LCDは表示が限られるし、低速なので無闇に入れるとおかしくなってしまう。ロジアナもこういうときは役に立たない。データ表示と同じ結果が確認されるだけである。色々調べた結果、原因は大体つかめたが、その解消方法が見当たらない。

 要するにI2Cでは、マスターからの送信の終わりをスレーブが知ることができない。ストップコンディションの発行が唯一の手がかりなのだが、861と違って、26はそのあいだもUSIインタフェースが動き続けデータとして送り込んでいるのが原因であることまではわかった。しかし、これをどう止めればよいのか方法がわからないのである。

 逆に何故861ではうまく行っていたのだろう。USIのシフトレジスタはSCL(クロック線)の立ち上がり、立下りでドライブされデータを受け取って行くがロジアナで見る限り、SCLは動いておらず、シフトレジスタは動かない。従ってデータは入ってこないはずである。26ではこれが動いているようだ。

 ところが不思議なことに、多量のデータを送ると、最初のうちからデータが乱れ始めることがわかった。そうなるとデータの最後を空打ちしてゴミを出していると言う仮説はあやしい。もっと他の原因がありそうだ。データを受け取り始めたときにこのストリームがどれだけ続くかMCUにわかるわけがない。それが大量のときに限って最初から乱れるのは人間的だが、機械ではありえない。なぞは深まるばかりである。こうして今日も深夜を迎える。

間に合わなかった(1/23/08)
 大量に送るときは最初からおかしくなるという、いかにも人間臭い反応について、一晩考えていた。データが送られて来たときに先のことは当然、知る由もない。人間でも無理である。今朝目覚めてみると、2年ぶりの雪だった。起きるかどうか逡巡しているとき突然ひらめいたものがある。そうだ、プログラムの構造は、データ読み込みを一旦全部やってから、表示に移るしかけになっている。ここで間違えれば、昨日のようなことが起きてもおかしくない。そうか、I2Cのやりとりばかりに気を取られてこの部分に気がつかなかった。

 朝食もそこそこに、地下に降りてPCに電源を入れる。コンパイラで状態が変わるというのが臭い。大量データを読んだときのみ、データを汚している可能性がある。バッファの位置を変えてコンパイルしてみた。勢い込んでバイナリをMCUに書き込む。ファーム書き込みの画面に見慣れないメッセージが出た。また、電源を入れるのを忘れたか。いや、ちゃんと電源が入っている。メッセージを良く見ると、Parity Errorの表示。

 去年の10月に買ったTiny26の書き込み回数の寿命がつきたことを示すメッセージである。間に合わなかった。最初に買ったMCUだ。目茶目茶な書き込み回数である。10000回を保証するとあるが、とうとうこの回数を超えてしまったようだ。ファームの書き込み制限があるので、早く、このMCUをLCDのドライバーにしようと、これまでやってきたのだが、タッチの差で間に合わなかったのである。

 プログラムさえ入ればマイコンとしては何の問題もなく動くはずである。ちゃんとした余生を送らせてやりたかった。そのために場所を提供しようと苦心してきたが、残念ながら何の役にも立たない石になってしまった。もう少し早くこのプロジェクトを始めるべきだったと悔やまれる。合掌。

そそっかしいにもほどがある(1/27/08)
 いやいや、生来のあわてものの性格はこの年になっても変わらない、困ったものだ。ParityErrorですっかりショックを受け、Tiny26をもう少しで生きながら埋葬するところだった。あれ以来、ちょっとした虚脱状態に陥り、気を取り直そうと、秋月でTiny2313を4個も買ってきてしまった。何しろ、秋月では2313がひとつ¥100なのである。可愛がっていたペットが死んで、さびしさの余りすぐ別のペットを買い込んでくる心境でおかしくなる。この石はADCがついていないが、生意気にもUARTを備えており、こうした通信系のドライバーにはかえって都合が良い。

 調査の報告書の執筆が思いのほかはかどったので時間が出来た。早速、元のブレッドボードのLCD回路はそのまま残し、新ブレッドボードの空いている上段に2313の場所を作って、26のLCDドライバーをそっくり配線しなおした。ISPピンをつけ、avrsp -rで2313の接続を確認してから、プログラムを2313用に修正し、ファームを書き込む。ところがこれがまたエラーになるのである。何い、そんな馬鹿な。よく見ると、ISPとピンを共有するI2Cのケーブルが接続されている。これをはずすと、ちゃんとファームは書き込まれた。

 待てよ。前のTiny26でもI2Cの配線はしたまま書き込んでいた。ひょっとすると、これがこのあいだのParityErrorの原因だったのかもしれない。急いで、しまってあったTiny26 を取り出し、前のブレッドボードに挿して、I2Cケーブルをはずして書き込む。何と、問題なく書き込めるではないか。でも前と同じ状況なのだろうなと、Megaを立ち上げて表示テストをしてみる。何と、何と、これがエラーが出ないのである。2行分32文字を全く問題なく表示する。

 何が原因かはわからない。しかし、今はちゃんと動く。わけがわからない。書き込みが不十分でエラーが出ていたとしか考えられない。Tiny861では問題がなかったのは、I2Cポートの場所が861では独立していたからである。いやいやとんだ勘違いであった。しかし、わかって良かった。もう少しで使える石をゴミ扱いするところだった。考えてみれば、買ってから3ヶ月、1万回が限度だとすれば、毎日100回以上ファーム書き込みをしないとこの回数に達しない。いくら夢中でやったとしても、これはいくら何でも多すぎる。おかしいとは思っていた。

遂に犯人をつかまえた(1/28/08)
 Tiny2313でもはまってしまった。はじめ順調にLCDに32文字を表示するので安心していたら、どうもおかしい。少しづつ入力していくと2行目に文字が出てこない。一気に32文字送るとちゃんと最後まで表示する。???である。プログラムは前の26用なので、デバッグ用のUARTが入っていない。しかも、ISPピンはI2CにかぶっていてソフトUARTに使えない。2313は専用のUARTを持っているが配線もソフトもまだ準備していない。

 LCDに表示させようとしたが、テストする対象にテストステートメントを表示させることには所詮限度がある。ソースコードは全く変えていないのにこの不審な動き。わけがわからない。まあ、Tiny26 が生き返ったから、こだわることはない(LCDドライバーにする予定はない)のだが、気に入らない。あれこれ考えた末、こいつのUARTを動かして徹底分析することにする。俺も懲りない男だ。深夜2時、配線を終えてこの日は寝た。

 翌28日、仕事から帰ってきて再びPCに向かう。Mega168のUARTルーチンを拝借して2313のUARTを作る。USB-UARTアダプタはMegaのを移す。こういうときのブレッドボードは実に便利である。これがいちいち半田付けをしていたら気の遠くなる作業だったことだろう。

 ところが送信は一発で動いたのだが、受信が反応しない。割り込みを使わないベタの受信でデバッグするところもないコードなのに動かない。暫くして原因がわかった。メインループのsleepから目覚めるのにダミーの割込みルーチンをコピーし忘れていたのが原因。これも初期化のときに、割込みを生かす設定になっていたのを「おかしい、これは間違いだ」とか言いながら割込みをdisableにしている。このときに気づくべきなのだが、思い込みというのはこういうものだ。大事故は大抵これが原因で起きる。

 さて、UARTから続々と状況が出力されて原因はすぐわかった。表示カラムがとんでもない値で動いている。カラム設定のコマンドで一旦正しくなるが、行換えで狂う。これでは2行目に行かないはずである。表示カラムはグローバル変数で、初期化のときに必ず0にしている。メインと処理関数のところで違うものを指しているか、データを汚している。試しに、変数の定義を、処理関数のところからメインの方に移してみる。

 直った!前のTiny26では問題なく動いていたのは何なのだ。間違いなく、gccのリンカーあたりのバグである。やっと犯人を一人つかまえた。ひょっとすると以前ソフトUARTではまっていた、カウンターが変なところでリセットされるのもこのあたりが原因だったのかもしれない。単なるコソドロだと思っていたら、一連の連続強盗の犯人だったようなものだ。

 いずれにしても、バグが解明されたあとの気分は何物にも替えがたい。安月給で昇進も期待できない刑事が犯人探しに夢中になる気持ちが理解できる。これで心おきなくニセコでスキーが楽しめる。

ここに後述するバグを取ったUSIインタフェースを使ったソフトI2Cスレーブのコードをおきます。なお、この前後の不具合はすべて、SRAM変数とスタック領域が被ったことが原因と思われます。そのつもりでドタバタ劇を見てください。
「I2LCD26.lzh」をダウンロード

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

Mega168のUART

Mega168でまたはまる(01/06/08)
 お正月休みもいよいよ今日で終わり。10日近く。長かったが考えてみたら、お正月の行事以外は、マイコンだけの正月だった。あっという間に時間がたったように思う。昨日、焼きもちをやいたのか、かまってもらえなかった車が故障して工場入り。折角、今日は秋月に買い物に行こうと思っていたのだが、とりやめ。そのかわり、またAVRで遊んでいる。

 温度ロガーを久しぶりに動かしてみる。何と、バッテリーに直結し、念を入れてスーパーキャパシタでバックアップしてあるRTCが動いていない!そんな馬鹿な。電圧を測ってみる。1.1Vしかない。電池はまだ2.8V以上ある。誰が犯人だ。テスターで見たところでは、コンデンサーの逆流防止につけたダイオード(ショットキーバリアダイオードIS4)で激しく電圧降下している。順方向の損失が少ないと言う触れ込みなのにこれではRTCは動けない。ブレッドボードの電池(4.2V近く)を供給してやる。ところがRTCは目覚めない。青くなる。壊れた? たかだか¥500のものだが、最近は¥500もする部品は重要部品だ。

 念のため電圧を測ってみる。これが1.4Vにしか上がっていない。RTCの動作最低電圧は1.7V。やれやれ。荒療治でダイオードのところショートさせて動かしてみる。何と、RTCは正確な時刻をけなげに返してくるではないか。思わず、チップをさすって苦労をねぎらってやった。考えてみたら、コンデンサが動くのは電池がないときだけ。ダイオードがなく逆流したとしても電池に影響はない。ダイオードをとりはずすことにして一件落着した。

 Mega168の話である。新しいブレッドボードにお目見えした。手始めにソフトUARTをつけてPCとやりとりするテストプログラムを入れてみる。Megaクラスになるとデータシートの量は半端ではない。2分冊にしてもTinyの1冊分を上回る。それにしてもこのドキュメントがすべて日本語になっているのはありがたい。ボランティアだそうだ。頭が下がる。Tinyとはだいぶレジスタの名称や機能がかわり、あちらこちら直してテストにこぎつけた。

 これがまた動かないのである。送信はデータポートをプルアップしてデータがおかしくなったのを除けば順調に出来たのに、受信がまた全く反応がない。Tinyと違うところはピンチェンジ割込みが詳細になったこと位で違いはない。これまたロジアナを取り出し、調べるとどうも割り込みを止めたはずなのにビットが来るたびに割り込みが入っている。

 スタートビットは論理1なのに、試しに0で動くようにすると、字化けしながらもデータは受け取れる。それにしても割り込みがデータ入力中に来るのは何故だ? MegaはUARTをハードで持っているのであまりこだわることはないのだが、これもやりだしたら止まらない。昨日の夜から散々悩みぬいて、ようやく気がついたのは、またまたここに書くのも恥ずかしい前と同じお馬鹿なミスだった。

 このあいだビットハンドリングで反省したばかりなのに、また同じ思い違いである。弁解になるが、解明が長引いたのには原因がある。これまでのTinyのプログラムにそもそも勘違いがあったのに、ビット0に受信ポートがあったお陰で、何の問題もなく動いていたのだ。つまりポートをある1バイトのエリアに読み込んで所定のビットの値を調べるとき、

DATA=PORTx & (1<<PINy);  とすると、DATAには、PINyの値だけが入る。

ビット表現なら、00010000 というような値だ(y=4のとき)。データが0なら 00000000になる。これを1(00000001)と比較してもどちらも一致しない。Tinyのときは、yが0だったので、00000001で偶然、一致していたのである。Megaはピン位置が3にあり、00001000で、10進数字なら8と比較しなければいけない。

 ロジアナで、データを読んでいる最中に割り込みが上がっている様子が見えたのも混乱を増した。良く考えてみれば、スタートビットが上がっていないので読み込みルーチンを素通りしていただけである。データはプログラムとおかまいなくPCから送られ、その都度プログラムは対応するが何もしていなかった。いやいや便利になるのも良いが、情報が多すぎると言うのもまた別の問題だ。何か世間と同じようなことがここでも起きている。

もう止まらない(1/9/08)
 来週までに調査報告書を仕上げなければならないのだが、少しづつ進めては、AVRに逆戻り。まあ、2編とも構想がまとまったので執筆は一気にやろうと先送りである。テーマさえ決めれば3日もあれば原稿は書ける、とか言いながら面白いほうに手が動く。

 7日の仕事初めも、午後は秋月へ懸案のUSBシリアル変換モジュールを買出しに行く。¥950。秋月ではUSBシリアル変換ケーブルが\1200なので安いのか高いのかわからないが、Tiny26のLCD表示プログラムのデバッグにUARTは必須で(もう、これのないMCUのデバッグは非能率で考えられない)、PCにもうひとつのシリアルチャネルをつけるためこのモジュール(RS232CでなくTTLベース)はピッタリなのだ。

 これが今から思えば何でもないのだが、動くまでに1日半悩ませた。ISPで機嫌良く動いていたテストプログラムが、全く動かない。USBのドライバーは何の問題もなく、秋月の説明書どおりインストールされPC上で、COM4が出現した。TeraTermでCOM4を指定して端末を開くが全く応答がない。通信関係はこれだから嫌だ。しかし、こちらには今度は強力な武器がある。ロジアナである。次の日(1/8)早速プローブをあちこちつなぎ、データを取ろうとする前に、何気なくDTRピン(先方の準備OKを示す)をテスターで測ってみたら、何と0V。PCのターミナルを止めると5V。あれえ、制御線って負論理だったっけ。何はともあれ、AVR側のプログラム通り、Vccに直結(無条件に通信開始)してみるとデータがターミナルに出た!とりあえずモジュールが動くことは確認されたが、データは化け化けである。A3141232

 スタートビットの位置がおかしいのかと、今度はロジアナでデータをチェックする。正しく送られているようだ。同じUARTでプログラムを変えないと動かないと言うのはおかしい。ロジアナでシリアルに送られたビット列を解読するのは結構厄介で、USBの方のビットレートがUSBプラグを抜き差しする度にデフォルトの9600bpsに戻ったり、USBをさしたままだと、AVRの電源を切ってもAVRが生きていたり(後述)、何がなにやらわけがわからなくなって一旦は実験を投げ出し、調査のほうのメモを書いたりする。

 こういう気分転換が問題解決には良いようだ。何気なくロジアナのビットストリームを見ていたら、送信データの最初が1になっている。前から気になっていたのだが、chaN氏のISPを通したUARTがスタートビットを0にして動かず(RS232Cは負論理のはずなのに)1にしたら全く問題なく動いたのでそのままにしてあったことを思い出した。

慌てて参考書を調べる。データは負論理、制御線は正論理が正式とある。chaN氏のソフトUARTはどちらも正論理のようだ。しかし、これはISPライタを通したUARTで正式ではない。うーむ、このUSBシリアルは制御線も負論理になっているが、データを反転させてみることにする。ブレッドボードはこういうとき本当に楽で、引き出しから昔懐かしい74HC00を取り出し、インバータを作って送信データを反転させてみる。

 出た!勢いに乗って受信ラインも反転させる。これも動いた!いやいや長かった。この解決したときの快感はいつものことながらなにごとにも替え難い。それにしても制御線まで負論理にするのは違反だ。

 AVRの電源を切ってもUSBとつながっていると動く話である。確かにトランスやフォトカップラーで絶縁されているのでなく、線でつながっているので電気的には動いておかしくないのだが、信号線の結線だけでVccに電圧が上がって動くというのは信じられない。AVRは低電圧版なので動く(テスタで2V近くある)のはわかるが、インバータを通してもVccが上がるのである。???である。結局、インバータの電源をUSBから供給されるようにしたら止まった。インバータは動いているので信号ラインは正確な値になるからと言えば説明がつくが、何となく割り切れない。

信じた私が馬鹿だった(1/10/08)
 電源を切っても動く「お化け」の話はさておき、気持ちよくMegaがお話をするようになったので、調子に乗って、USB経由のシリアルをISPピンではなく、正式のMega168のUARTにつなぐ。これは次のTiny26のスレーブI2C通信をデバッグするには必須で、まずTiny861をISPにつなぎ、別のUSIインタフェースでスレーブI2Cをテストしてから、そっくりTiny26に持ち込んでTiny26 をLCDドライバとして役立たせる計画の一環である。(この手順はこのあいだ思いついて我ながら感心した手順。これがTiny26 のLCDドライバ開発のきっかけでもある)

 そう、Tiny26はUSIインタフェースがひとつしかなく、これをI2Cに使ってしまうと、UARTでのデバッグが出来なくなる。ロジアナはハードとして出ているピンには無敵だが、MCUの中身まではプローブすることは出来ない。UARTでPCにデータを吐き出させるのが効率が良いのだ。そのためにはMega168は別のシリアルでデータのやりとりをやる必要がある。

 と、これがまたうまくいかないのである。コードはあっけないほど簡単で、ちょっと複雑な制御レジスタの設定も、懇切丁寧なウェブの説明があるのでこれを参考にすぐ設定できた。ところが、動くには動いても字化けだらけで話にならない。コードは余りにも簡単でデバッグするようなところは何もない。だいたいMega標準装備のUARTは制御線もないフリーランニング(制御線は別のピンで作れと言うこと)なのでこのあたりを調べる余地もない。それに制御線でデータがおかしくなるわけがない。

 夕食後、調査原稿そっちのけでロジアナをつける。化けているデータを画面で見てみてもその通りのデータでこれまた埒が明かない。調べるところは制御レジスタしかないが、これまた割り込みも使わない簡単設定なので調べるところは殆どない。途方に暮れてデータシートのプログラミング例を見るともなく見ていたら、ウェブ上の情報では、「これは同期シリアル向けの設定で関係ないのでしょう...」と書いてあるレジスタの設定が非同期でもある。

 これが何と、ビットフレームの大きさを決める設定ではないか。慌ててデータシートを読み返したら、デフォルトは8ビットでなく、5ビットになっている!要するに、関係ないといわれて、この制御レジスタを全部0にしていたのが原因で、8ビットのデータをせっせと5ビットにみなして通信していたのが原因であった。

 午後遅くから始めて、夕食をはさんで6時間。コーディングは1時間足らず。MegaのUARTは何事もなく動き始めた。同じ38.4kbpsだが、ソフトUARTより早く感じる。信じた自分が悪かった。このあいだの正論理のUARTといい、情報を無条件に信じてはいけないとわかってはいても、デバッグではつい頭に血が昇って冷静になれなくなる。良い教訓ができた。

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

オプティマイズのロジアナ

ロジックアナライザを衝動買い(12/27/07)
 1万円程度で手に入るロジックアナライザ(ロジアナ)は今まで調べていたオプティマイズ社のカメレオンUSBを使ったものが一番良さそうなので、というよりこの破格の安さとそこそこの性能はこれしかないことがわかったので、とうとう事務所で注文してしまった。最近は銀行振り込みもオンラインであっという間に出来る。明日届く予定だ。

 キットはTQFPの半田付けに自信がないのと、不確定要素をなるべく減らしたいため(測定器動作の心配をデバッグ中にしたくない)、プラス\3500の製作代行を付ける。それでも全部で\13,000。これ以外のロジアナはPCを使ったやつでも5万、中古で10万、ハードの新品はいくら安くても20万近くするのだ。

ロジアナがあれば、UARTから始まる通信インタフェースの解析には無敵になる。USBにどうせこれから行くが、これがあるのとないのでは目が見えるか見えないかぐらいの差がある。次の目標はUSBよりEtherNetだ。ネットワークを使ったリモートスイッチを考えている。このときにも欠かせない。

温度ロガーの方は、今日、ケースの上蓋の穴あけを終わった。スイッチが少し奥になってしまったが、仕上げはまずまず。プラスチックなのでつい削りすぎてしまう。もう少し上等なやすりを手に入れる必要があるようだ。Ac290821

 昨日は、温度センサー(LM35D)が3V以下で動作を停止し青くなったが(9Vバッテリか、DCコンバータが必要)、発想の転換で、RTCに予定していたボタン電池(3V)をこれに切り替え、事なきを得た。RTCは20μAしか消費しないので、単三だけで何年も持つ。点けっ放しでも大丈夫だろう。最近は数ファラッドあるコンデンサーが安くで手に入るのでこれでバックアップする予定だ。
 10月以来、猛進してきた温度ロガーの道は、ここに来て最終ステージに辿りついた。あとは、RTCを組み込んで当初の計画は完了する。

ことしもあと2日(12/30/07)
 2007年もあと2日を残すばかりとなった。AVRプロジェクトは発足2ヶ月余りで当面の目標、RTC(リアルタイムクロック)付の温度ロガーが完成し、一段落した。実機が3Vバッテリーなのでスーパーキャパシタ(0.1F)がどれだけバックアップしてくれるか未知数だが、昨日のブレッドボード(4.5V)では4時間以上動いていた。電池の交換くらいの時間は大丈夫だろう。

 I2Cのテストルーチンをこれまでの温度ロガーに組み込む作業は簡単に終了した。RTCの組み込みが一番大変だった。計画的に位置を決めてあったのだが、やはり実際に配線してみると、たくさん不都合が出る。これを回避するレイアウトを考えるのが、電子工作のもうひとつの楽しみなのだが、少しスペースが小さすぎた。

 最後の不具合がスーパーキャパシタの背と上蓋との干渉である。これは発想の転換で、台座のビス位置のスペーサーを2ミリほど削って何とか納めた。A3041176

 いや、それにしても、このはまりようはどうしたことだろう。おとといからのロジアナが動いたときは本当に感動した。これまで雑誌や参考書で見せられてきたタイミングチャートが簡単に画面に表示される。しかも自分の作った機器のチャートだ。この手の測定器をいじるのは、大学の特別演習で大崎のソニーの工場で使ったテクトロニクスのシンクロスコープの時以来である。40年ぶりだろうか。

 UARTとI2C(TWI)のデータのやりとりを記録した。昨夜は寝るのも忘れて、送信側と受信側のデータを表示して悦にいっていた。これでイーサネットとMMCの組み込みに挑戦できる。

新春もAVRであける(1/3/08)
 温度ロガーのしつこいバグ(データが一巡すると化ける)の原因をとうとう発見した。これが2008年の最初の収穫である。Tiny861にしてEEPROMに余裕が出来、条件が揃わなかったのだが、このあいだ再現し、頭を抱えていた。見つかってしまえば何のことはない、至極当たり前の不具合なのだが、思い込みというのは恐ろしい。お正月休みを利用して、この前使ったテストプログラムのバッファサイズを縮め実際に温度を記録してバグを確認した。そう、接触不良でも電池の消耗でもなかった。リングバッファは外からは連続したデータエリアに見えるので、遇数で書いていけば偶数で取り出せるはずだと思い込んでいた。しかし、消されていくデータはデータサイズが奇数だとずれる。

 こう書けば何故これが今までわからなかったのか不思議なくらいだが、バグと言うのはこういうものである。これを直し(単にサイズを偶数にしただけ)、ついでに日付が温度にみなされないよう工夫してRTC付温度ロガーは、ほぼ完全となった。スイッチを入れるだけで測定開始の月日時分を記録し、5分間隔で連続20時間、温度を測定できる。Ws000001

 大晦日にテストしたLCDの電源をON/OFFするしかけ(これが久しぶりのトランジスタを使ったドライバーでとても簡単に動く)を組み込んだLCD表示プログラムは、箱根駅伝を見た後、着手し2日の夜に完成した。PCからのコマンドで、LCDが点いたり消えたり、キャラクタを表示したり出来る。子供だましのしかけ(もちろんこれはテストプログラム)だが、無性に嬉しい。この面白さは何なのだろう。

ロジアナは強力だが(1/5/08)
 くだらないことでつまづいている。退役したTiny26の余生をシリアルLCDのエンジンで有意義にしてやろうと、このあいだからやっているLCDプログラムだが、ビジーフラッグを見て高速表示する本格的なプログラムにしようとしてこれが動かない。

 こういうときこそ活躍するのがロジアナである。早速、手作り のプローブをブレッドボードに立て測定する。出た出た。あるところで無限ループに入っているのが一目瞭然である。待ち時間なども簡単に実測できる。素晴らしい。しかし、動かないのである。A3141230

 ループは抜けたが、肝腎の表示が出ない。ロジアナはピンの状況は正確に伝えるけれどデータの中身は見えない。結局、UARTを通してデータの中身を吐き出させて始めてバグの正体が見えた。これもここに書くのも恥ずかしいお馬鹿なミス。思い込みと言うのは本当に恐ろしい。ビットが一つしか立たないデータだから1だとばかり思い込み、1で比較していたというお粗末である(最上位ビットなので128)。

  これで直った(つまり待たなA3141228_2いで先に行っていたのを止めた)と思ったが、意外や意外これでも動かない。ロジアナではそれらしく、何回かビジーを調べて次に進んでいる様子が記録されているのにガンとしてLCDは文字を表示しない。

 まあ、表示そのものに数十msかかるLCDを高速化することなど無意味なのだが、やりだしたら、とことんやらないと気のすまない性格である。今までのenableの期間が短すぎるので少し待ちをいれたり(ロジアナで気になっていた)、ビジー待ちの場所を替えたりしたが、結局時間切れであきらめた。

 ロジアナは強力だが、これだけですべてが解決するわけではないことを学んだ。しかし、これがなければ、データはenableを上げたときにしか読めないということを知らずに悩んだことだろう。書き出しは向こうがそのときに読むわけだから、あとで良いわけである。

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

Tiny用のソフトI2Cマスター

世の中には色んなことが(12/17/2007)
 AVRについて語れる数少ない友人(通信関係会社のモデム開発者)と久しぶりに飲んで愉快に帰ってきた。TTL、TK80、Z80の話が通じる友人である。私の作った名刺サイズの温度ロガーを飲み屋に持ち込んで評価してもらう。彼の最初の反応は、「で、データバスはどのピンなの?」である。いやあ半導体の進歩はすさまじい。ワンチップコンピュータなどと言っていたのが、35年前。今やPCですら64ビットバス、ギガを超えるクロック、テラを越すハードディスクの時代である。昔日の思い出に花が咲いた。

 閑話休題。AVRの続きである。先週あたりから、RTCモジュール(例によって秋月で\500で購入)とのI2C通信にはまっている。Megaでやれば良いものをこだわって、USIインタフェースを使ったTinyのソフトウエアマスターI2Cをこのほど完成させた。昨夜、Atmelのアプリケーションノートを元に、関数群をコーディングし、一発でRTCからデータが表示されたときは感激した。I2CはMMCなどの周辺ディバイスとのやりとりには欠かせないので、勉強の意味もある。

ソフトI2Cマスタのソースコードはこちらです。
「I2C_test.lzh」をダウンロード

こいつが結構気難しい。データの読み出し、書き出しは出来るようになったが、どうも内容がおかしい。I2Cのやりとりでチョンボをしているのか、このレジスターがおかしいのか判別がつかない。月日時分秒はBCDなので上位ビットは使われていないが、ここのビットの状態が不定なのである。下位ビットは合っているので大丈夫だと思うが、I2Cも信用は出来ない。(マスクビットをあてて安定した。要するに無駄なビットが立つ。データシートに出ていた。お馬鹿なミス)

それよりショックだったのは、このRTC、電源を切ると今までのデータが全くなくなってしまうことだ、クロックパルスの設定まで何もかもなくなるとは思っていなかった。これでは、「博士の美しい数式」ではないが一瞬と言えども電源を切ることはできない。電源を切ったら最後、全部設定しなおしである。これは参った。ボタン電池をつけた簡便なRTC(Real Time Clock)はないのだろうか。これはやっぱりTiny26の出番かもしれない。

バグが沢山あった(12/20/07)
 忘年会の連続で帰りが遅いが、それにへこたれずPCの前でAVRをいじっている。EEPROMの書き込みは大分前に完成し、玄関などの温度を測っているが、どうも様子がおかしい。2時間ばかりで測定が止まっている。温度が低すぎるから?そんな馬鹿な。零下45度でも動く工業規格だ。はい、これも原因は私でした。861でEEPROMが512バイトになっているのにポインターが256までしか入らない1バイトだったためである。

 しかし、エリアを確保してもうまくいかない。折り返しのデータがおかしくなる。相変わらずコンパイラーからは、「ポインターに変なデータを入れるな」と怒られている。これをなおそうと思ったが結局わけがわからなくなってやめた。キャストの考え方がいまひとつ理解できない。Ac140772

 それはともかく、結局サイズをわざと小さくしてデータがぐるぐる回るようにしてテストしてみたら、たくさんバグが見つかった。要するにデータエンドなどの臨界点での検証が不十分だったのだ。Cは++などの演算子が便利なのだが、よーく考えて使わないととんでもないことになることがわかった。
 RTCの方は、とりあえず年月日時分秒を表示させるところまで行って一段落している。バッテリーバックアップより、コンデンサー(スーパーキャパシタというのだそうだ)バックアップの方が簡便なのだが、用途がまだ具体的でないので判断が出来ていない。

バグつぶしの爽快感(12/25/07)
年賀状の添え書きもやっと終了し、しつこいバグがこのところ連続で解消されとても爽快な気分を味わっている。512バイトのEEPROMの方は結局テストルーチンを作り直し(これがTiny26用だったので大幅書き直し)、直接512バイトを叩き込んで実際にトラブルが起きることを確認した。アドレスレジスタを見ていたら原因がわかった。512バイト目をアクセスするのは、アドレスでは511番地。つまり512番地はアドレスレジスタの中身は全部0になる。つまり、最初の番地に書き込むことになる。

 最初の番地(0番地)はファイルが存在する特別のコードが入れてあり、これが合致しないとファイルが無いものとして初期化されることになっているので、当然ファイルは初期化され、データは消えてなくなったのである。こう書いてみれば極く当然のように見えるがここまで辿りつくまでが大変だった。

 もうひとつのI2Cのトラブルもしつこかった。RTCのデータをすべて吐き出す処理で、最後に必ず考えられないエラーステイタスが返って来る。データが正しく出ているので最初放置していたが、どうもおかしい。最初、予期せぬエラー条件が出て、これを無視した経緯がある。連続してコマンドを出すとデータが読めなかったり、書けなかったりする時がある。ロジックアナライザでもあれば、一目瞭然なのだが、時間の経過で動く状況を挿入したステートメントで判断するのは難しい。しかも、時々起きるというのが一番厄介なバグである。

 結局、これもテストステートメントをいたるところに挿入し、あらゆる状態をUARTを通じて端末に吐き出させてみて原因がわかった。これを余りやると環境を変えて何をやっているのかわからなくなる危険があるのだが、背に腹は代えられない。原因は2つあった。ひとつは、RTCに対して読み出しを連続してかけるとき、最後の読み出しは、マスタのこちらから終了のサインを送らなければならないのだが、これを怠ったためおかしなデータを送り続け、データの衝突が起きていた。もうひとつは、Atmelの方の不具合で、ストップコンディションのクリアをするのを忘れていた。Atmelのソースコードで、エラーチェックのところがコメントアウトされていたのは、このバグがとれなかったためと思われる。

 いや、トラブルシューティングのあとの爽快感は素晴らしい。4Mのクロックで200Khzの伝送速度までOKだ。しかし、やっぱりロジックアナライザが欲しいな。こういう手探りの捜査は、解決したときの興奮は大きいけれど生産性が悪い。

温度ロガー完成版のソース(他の関数もこれが最新です)
「Thermo_Logger861V2.lzh」をダウンロード

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

標準入出力的EEPROM

仕事先の忘年会で機嫌よく帰宅。酔眼朦朧だが、いとしいTiny26のために地下のオーディオルーム(PCが置いてある)でISPインタフェースの調査をやっている。それにしても急に寒くなった。吐く息が白い。しかし地下は温度は21.8度(温度ロガーによる)で快適だ。EEPROMを標準入出力のような関数で使うプログラムの開発はあっけなく実現した。ただ、最初の不具合が色々なところを修正しているうちに直ってしまったのが少し心残りだ。たったの128バイトしかないEEPROMだけれど、メインプログラムでEEPROMの構造を全く知らなくても、データを自由にアクセスできる。リングバッファーにしてあるので、古いほうから消えていく。
ソースコードはこちらから
「eeprom_test.lzh」をダウンロード

 コードサイズは2K、2048バイトを残すところ8バイト、2040で納まった。LCDはとても入らない。この状況で、次は実装である。事務所が秋葉に近いので空き時間に行こうと狙っていたのだが、あれこれ雑用があって果たせなかった。ケースに入れたり、電池サイズを考えたり、これはこれで工夫の余地のある面白い作業なのだが、残念ながら少し先送りである(電車賃を払ってまで秋葉に行くほどでもない)。3ステートバッファーの仕様とか、AVRのミニカーネルとかWeb上には情報が満載だ。マイコンの次の目標はやはり2足歩行のロボットなのかもしれない。

みなさん御免なさい
 実装用のTiny26版のソフトの仕上げでまたつまづいた。最初の温度が記録されないのである。メモリサイズは数バイトを残すだけなのでテストステートメントが挿入できない。ADコンバーターの部分を色々調べても問題はない。こいつ立ち上がるのに時間がかかるのか、そういえば、前のときも最初の計測はデータが狂っていた。それともメモリサイズが満杯になって、コンパイラーがいんちきなコードを吐いたか、電池がいよいよなくなってきたからか、など考え、資料も調べたが、そんな情報はない。

 家内と久しぶりに高島屋へでかけメガネの更新のついでに秋葉原に寄り、スイッチなどの小物を手に入れ実装に向けては順調なのに、これではTiny861への換装も出来ない。問題点をメモに書き出し、結局、ADCのテストプログラムを別に書いてみることにした。

 これが何と、全く問題なくADCは温度データを最初から出力するではないか。そんな馬鹿な。さらにデータをとってみる。はい、悪いのは私でした。10回測って平均値を出しているのだが、これが11回測っていた。当然10回目はまだ平均値が出ておらず結果は0だ。何回かするとこれまでの計測値が合算されて正常(にみえる)な値が出力されていたというお粗末。ADCさん、コンパイラーさん、電池さん、みんなを疑って御免なさい。悪いのはみんな私でした。

 良い教訓ができた。四の五の考えないで、事実をつめていくことがデバッグの近道ということ。それに注意深く事実を調べること。現象をメモに書き出し、全体を見ることだ。
(12/8)

線路は続くよどこまでも
 昨夜、まるで小学生が出来上がった模型を枕元に置いて寝るように、名刺サイズの実装版を枕元に置いて寝た。いや私は寝室の温度を測るためである。5分おきに温度データを10回測り、EEPROMに記録していく。5分に一回LEDが暗闇で光るのが頼もしい。

 いやいや、これまで色々なことがあった。AVRをやってみようと思ったのが2ヶ月前。あれこれ考えたきた構想が実際に現物として目の前にある。俺もやれば出来るのだという自信がみなぎる。861への換装は思ったほど難しくなかった。何と言ってもメモリサイズは4倍である。余裕のプログラミングが可能だ。

しかも、1.7Vでも動く低電圧版だ。始めうんともすんとも言わないで真っ青になった実装版だが、スイッチの位置間違いか何かで、誤配線も無くすんなり動き始めた。ところが、温度がおかしい。調べてみたら温度センサーの電源電圧は何と4Vからになっている。3Vは規格外だ。電源電圧を上げる負電圧コンバーターなどの対策をWebで探すうち、ふとこれは前にもあった現象だと気がついた。そう、センサー入力ピンをプルアップしていたのだ。

Ac060748これを直して遂に名刺サイズの温度ロガーは95%完成した。残りは上蓋の穴あけを残すのみである。今日、6時間ほどの寝室のデータをターミナルに表示し、Copy&Pasteで、Excelに移してグラフまで描いてみた。「厨房ですよ」ではないが、これで「温度ロガーの出来上がりー」である。

しかし、ドラマはこれで終わらなかった。ブレッドボード上の開発機の具合がおかしいのである。UARTのデータが化ける。昨日の実装機に入れたチップは全く問題ないのに、もうひとつのチップがおかしい。しかし、このチップも実装機に入れると問題なく動く。???である。何もいじっていない。前のTiny26まで持ち出して調べたが原因がわからない。どうもデジタル的なトラブルでなAc140763 く、アナログ的な感じだ。このまえ内蔵CRクロックのTiny26がおかしかったときと現象が同じなのである。発振を疑ってブレッドボード上の不要な配線を取り除いてゆき、殆ど裸になったところで現象は止まった。

 対症療法だがこれで、次のステップに進める。いや線路はどこまでも続いているようである。
(12/13/07)

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

2008年8月22日 (金)

割込み制御ソフトUART

今度は開発環境が(11/24/07)
 冒険物語はこれで終わりではなかった。ソースが大きくなってきたので懸案のファイルの分割化でまた奇妙な現象に悩まされた。定石どおり、ヘッダーファイルを作り、関数のプロトタイプと#ifdefを使ってグローバル変数をそこへ移してコンパイルした。これが通らないのである。やれ関数を多重に定義しているの、知らない変数があるなどと身に覚えのないエラーが頻発し先に進めない。

 まあ、今まで何のためにあるのか良く理解できなかった#ifdefだの#ifndefなどのプリプロセッサーの指令をマスターできたのは収穫だったが、要するにヘッダーがうまく機能していない。それではというのでヘッダーをやめて、全部分割したファイルに戻してやってみる。所詮ヘッダーファイルを#includeするというのはそれぞれのソースにコピーしているにすぎない。ところがこれでもエラーが出る。フルートの勉強会から気分よく帰ってきて、その勢いでPCに向かい、ソースファイルを一本に戻してみた。何とこれでも同じエラー。

 これは間違いなく開発環境がおかしい。他のプロジェクトを見に行ってみると、何と何と前のプロジェクトからソースファイルが消えてなくなっている!今度のプロジェクトはこのソースのコピーを新しいプロジェクトに持ってきて展開していたのだ。開発環境のAVRstudioのバグである。やれやれ。印刷とバックアップがあるので実害は少ないが、ひどい目にあわされたものである。要するに環境の中にソースファイルが2つ入っていて、画面上にはひとつしか見えなかったのだ。それで多重定義だとコンパイラーが怒っていたのだろう。

 この環境は、無料なのであまり文句は言えない。しかもコンパイラーはプラグインのgccコンパイラーで環境それ自体と独立している。makefileのパラメータを切るのが面倒でこの環境を使っているが、エディターも余り使いよいものではないし、そろそろ見直しが必要なのかもしれない。ソースコードデバッグは割り込みやタイミングの必要なソフトでは余り役に立たないし。

平和な気持ち(11/25/07)
 研修講師の準備をまだ何もやっていない。明日から1週間はこのマイコン騒ぎを封印しなくてはなるまい。しかし、ちょうどその節目に開発が一段落して気分はとても爽快だ。開発環境の方は、新しいバージョンをダウンロードしてはみたものの、この手の新バージョンは用心しないといけないので、インストールはやめた。特にWeb上での情報はない。

 不具合は、新しい環境(プロジェクト)を作り、いちからファイルを用意したら、全く問題なく、ファイル分割は成功した。ただ、レジスター変数の宣言(使わないという)をそれぞれのソースファイルにしなくてはならない。これは面倒だ。とても公開など出来ない。

 考えてみれば、時間にクリティカルなのは、送受信のデータをループで待ちをかけながら、処理するときだけで、バッファリングは関係ないことに気づいた。割り込みルーチンをC言語側に持って来れば、面倒なCからASMへのアドレス渡しをしないですむ。これがうまく行ったのである。割り込みルーチンのdis-assmeblerリストには壮大なpush/popがつながり、最初動かないのであれこれ待ちの調整をしていたが駄目。しかし、原因はもっと簡単で、単に入力のHigh/Lowを間違えていただけ。これを直したら、全く問題なく動いた。38.4kbpsでも大丈夫。
ソフトUARTのソースコードはこちらです。lzhファイルを解凍して中のADC_TEST.txtをご覧下さい。「ADC_TEST.lzh」をダウンロード

 これで、この研究の成果は、公開しても大丈夫なレベルに到達した。とても平和な気持ちでこの記録を書いている。

開発一段落(12/1/07)
 今度のマイコンは当面の目標を温度ロガーにおいている。室内の温度の推移は前から気になっていて、どの程度の温度差が各部屋にあるのか知りたいからである。このTiny26はEEPROMメモリが128バイトしかなく、保存できるデータ量が少なすぎる。シリアル通信のことも考えれば、既に買ってあるMega168は4倍の512バイトあり早くこれにすべきなのだが、生来のへそ曲がりがここにも出て、今のチップで何とか機能をつめこんでやろうと無理をしてきた。ソフトUARTもその典型だ。このあいだTiny26の後継機種861(これはSRAMが8キロ、EEPROMが512バイトある)が日本で売られていることを見つけ、わざわざ入谷まで行って買ってくることもないのだが、まあ、昔ハムで多段スーパーの向こうをはって0V1という最小の受信機でDX(遠距離通信)をやっていたようなものかもしれない。

 それでもこの温度ロガーは、タイマー1の一秒クロックで暫定のTODを作り(これは一回で想定どおり動いた。だいぶ慣れてきたようだ)、PCに現在の温度を知らせるところまで来た。PCでのコマンド入力もバックスペースの処理を考えて相当こなれてきた。

 まあ、このへんは玄人だからな。ブレッドボードから健気にPCに十秒単位に温度を知らせているチップを見ているといとおしくなる。EEPROMの処理は検討だけでまだ手をつけていない。小さいけれどそれなりにファイルの形で使いたいので色々考えている。このときが何と言っても一番楽しい。Robustnessだったか、オブジェクトとして独立したソフトを作る工夫が面白い。

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

温度計測でのお粗末

 いやはや、LCD表示で頭を抱えていたのもつかのま、温度測定IC(LM35D)とADC用に新しく構成したシステムでもお馬鹿な間違いをやって、夜更かしすることになった。何のことはない。AVRstudioに慣れないせいで折角作ったバイナリでなく前のバイナリをせっせとTiny26に食わせて動かない、動かないと悩んでいたのだ。タイムスタンプを見ればロードしているバイナリはずっと前のファイルだとわかるはずだが、頭に血が上っているとそこまでの注意力は望めない。
Ab060716_01
 LCD表示も難物だった。これは2日くらいかかった。参考にしたソースがヘッダーファイルを別につけているから#defineのところさえ換えれば、別の構成でも通用すると頭から信じたのが悪かった。4ビットハンドリングは面倒なものだが、中身のソースは何のことはない完全に環境依存で、これは中身を全部理解してからでないとこのソースは使えない。ただ、独立性を高めようとすると無駄なコーディングが多くなり、Tiny26ではメモリがそろそろ一杯になってきたので自分もハードコーディングしてしまった。
 LCD表示のソースコードは以下にあります。
「LCD_1st.lzh」をダウンロード

スリープはあっけなく実現した。電流計(テスターにピンコードを追加:これはクール)でループ(6mA)から半分以下の2mAになるのを見て満悦であった。結局LEDが一番電力を喰うことが分かった。LCDのバックライトも余計(10mA以上)だ。さきほどのトラブル解消のあと、今システムは演算する前の温度の数字が表示されている。結構正しい。これで、温度ロガーの第一の大きな山を越えたことになる。メモリは1152バイト でまだ半分残っている。このあとはTODとシリアル送出である。

 次の日、寝る前にロジックを思いつき、早速昼前から試してうまく動くことを確認した。温度表示の小数点以下がいつも同じ数字なのが気に入らなかった。考えてみれば、どれだけ繰り返し測りなおしてみてもマイクロセカンドの範囲では測った温度がかわるタイミングは万に一つで、これは1秒の間に何回か分けて測る必要がある。今の構造を殆ど変えずにWAITのところで温度を何十回かに一回測ることでこれを実現した。これで、小数点以下が小刻みに変化する。 やったやった。得意になってつい鼻歌が出る。
(11/8/2007)

暗礁に乗り上げる
 思うようにデータがPCから受け取れず悩んでいる。送信は今朝、ポートをプルダウンすることであっさり解決した。AVRプロジェクトも最終段階に入り、今はTiny26にないUART機能をソフトで実現しようと、ここ数日メモを10枚近く書き散らし奮闘している。

 Mega168があるのだから、こだわることはないのだが、Tinyのような小さい石で温度ロガーを作ることに意義がある。しかも、このシリアルの世界は昔からの私の十八番である。ちょっとのことで諦める訳には行かないのだ。コードサイズも何とか2Kバイトに入りそうだし、もう一息なのだが、受信だけがうまくいかない。

 割り込みとリングバッファーを使った少し欲張りな仕様で、4本同時に出る割り込みをなだめすかし、何とかハングアップせずにデータをとりこむところまではうまくいった。リングバッファーアドレスのASM関数への受け渡しや、割り込みの制御など、我ながらうまくやったと思うのだが、肝心のデータがでたらめなのでは話にならない。しかもリングバッファーのカウンターがリセットされるときのデータが特におかしい。わずか1命令サイクルが増えるだけでデータが変わるとは思えない。SRAMをいじるやつは他にはいないし、やっぱり受信タイミングなのかなあ。(11/15/07)

やっとのことで脱出
 いや、今度のやつはきつかった。SoftUARTは、紆余曲折の上、何とか19.2kbpsの半二重送受信が実現した。AVRから送信が出来るようになったので、あらゆるところのデータをPCに送らせて解析したが、どうしても説明のつかない現象に根を上げ、アセンブラーをやめてCで作り直したら(20分でできた)、一発で通ってしまった。

 奇妙な現象は2つあった。これがリングバッファーの動きをおかしくしていたのだ。まず、レジスタ変数でアセンブラに渡したリングバッファのアドレスがどうも、おかしい。ピンチェンジ割り込みのルーチンの方が1バイトずれている。これはバッファーのデータを16進表示にして最初のデータが00なので始めて確認できた。LEDを要所に挿入して、不規則な割り込みで処理が乱されていないことは確かめてある。

 このアドレスずれは、対症療法で、割り込み側のアドレスを減らしておくことで対処できたが、問題は、受け取り側(Tail)のカウンターが途中でずれることである。奇妙なことに、送り込み側(Head)のカウンターが0に戻ったサイクルでカウントアップしなくなるのである。昨日の夜は、バッファサイズを何種類か変えて同じようになることを見て絶望的な気持ちになった。

 こんな器用なことがMPUに出来るわけがない。ここにはOSはおろか、モニタープログラムも動いておらず、今ロードしたプログラム以外に動いているものは何もないのである。みんなお前がやっていることなのだ。予想もしない容疑をかけられた被疑者のようなものである。割り込みが悪さをしているわけではない。高々10ステップばかりのリングバッファの処理である。レジスターの指定を色々かえてみたが、結局、この頑固なバグは解明できないでいた。世の中が暗くなる気持ちだ。

 残されたひとつの手段は「このルーチンを使わないで別に作る」ことである。こんな小さなルーチンにバグが潜んでいるとは思えず、原因は他にあると考えられ、期待は大きくなかったが、物は試しとCでその部分を書き直してみた(20分もかからなかった)。

 何と、直ったのである。ここ1週間悩ましてきた不具合は綺麗に解消され、快適にデータが受け取れるではないか。いったい何が原因だったのだろうか。今でもわからない。
(11/21/07 午前1時)

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

2008年8月21日 (木)

みんなお前が悪い

 今度は割り込みルーチンが動かず弱った。ロジックがお粗末だったのは昨日の時点でわかっていて、真理値表を作ってきれいな形にした。要はスイッチの押し下げと、開放の2つしか状態は無いのだから、フラグを2つも使う必要が無いのだ。

 それでもプログラムは気まぐれな動きをする。時々と言うのが一番始末が悪い。ハードを疑って、というのもこのあいだは割り込みピンをプルアップしないで動かなかったこともあるので、Vccといわれる電池の電圧とか電流を調べたが問題ない。

 銀行とドンキの買い物につき合って珍しく時間をあけてAVRstudioを立ち上げる。昨夜は少しデバッガーを調べてgccのシンボルデバッグが出来るのに感心して「これなら割り込みさえシミュレートできれば相当できるな」と思っていたのだが、何のことはない、解決は別のところにあった。

 割り込みPINの入力を確認するために、ポートアドレスと入力PINのANDをかけているのだが、ポートアドレスの表記が勘違いであった。PB6とは右から7番目(0から始まるので)のビットのことで、2進表示なら 01000000だ。しかし、PB6そのものは、単なる0x06に置き換わる。つまり、00000110でこのピンに対して入力を聞いていたのだ。

 わかってしまえば、単純なミスだ。ビット演算は慣れていないのでこういうミスがでる。判明するまで、機械や電池を疑って申し訳ないことをした。全部俺が悪かった。負け惜しみになるが、時々動いたというのはどういうことなんだろう。
(11/1/2007)

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

WinAVRを動かす

 AVRマイコンの冒険は留まるところを知らない。初めてチップを買ってきたのが、今月の16日、それ以来、すっかりこれに没頭している。フルートレッスンは明日だが、練習もしている間も頭の中をロジックが離れない。こんなに熱中したのは、10年ほど前のLinux以来だと思う。単なる電子工作ではなく、私にとっては、長年仕事で日頃溜めていた不満や願望を何らかの形で解決してくれているという思いがある。Linuxの時もそうだった。

 Linuxのときはカーネルの中を覗ける楽しみがあったが、すでに膨大な蓄積のあるOSであり、個人の裁量は多寡がしれている。しかし、8ビットMCUはモニターもOSもなければ、メモリ空間もキロワードの世界であり、I/Oは1ビット単位だ。それでいてクロックは20MHzはとれるし、割り込みも多重に出来る。タイマーもUARTもハードで持っているし、今まで外付けのA/Dコンバーターやちょっとした周辺機器の接続にこまかい結線が必要で、まともな機械にするには相当な時間と経験を必要としたのに、A/Dコンバーターは内蔵しているし、たいていのものは、単にI/Oピンに機械をつなぐだけで、ハードは完成してしまう。

 そのうえ、PICはいちいち、チップを別の機械に移し、プログラムをロードしなければならないのに、このAVRはターゲットマシンにほんの少しのインタフェース線をだすだけで、プログラムが焼けてしまう(最近はPICも出来るらしいが)。しかも、このフラッシュROMは1万回以上焼き直しができるので気楽に書き換えられる。何と言っても値段は最初に買ったTinyクラスで¥300しないし、先週、通信販売で手に入れた中型クラスのMega168でもひとつ¥500だ。

 さらにPICからの優位なところは、無料のCコンパイラーを使ってプログラムが組めることだ。AVRのCコンパイラは何とオープンソースのGccなのである。私も2本ほどアセンブラーで書いて構造が見えてきたところで、Cに開発環境を換えた。

 WinAVR(gccのこと)の環境設定が混乱したり、Cでのビット演算に苦労したり、C特有の文法に惑わされたりしたが、ボタンの押下でLEDの点滅間隔を設定するプログラムを母体に、ASMからCへのポーティング、タイマー割り込みの導入、スイッチの外部割込み による制御など、順調に実験が進んでいる。Aa230710_2

 ブレッドボードも、事務所の帰りに寄った秋葉原で短いジャンパーピンを買い増し、すっきりした形になった。秋月では、定番のLCDモジュール(オレンジ、バックライト付)を¥900で手に入れ、着々と温度ロガーへの道を進んでいる。

 極細の熱収縮チューブのおかげで、コネクター周りは格段にきれいになった。ただ、外部割込みは現在時点で完全稼動していない。割り込みが起きることはわかっているのだが、スペックどおりの動きをしないのだ。デバッグがあちこちに挿入したLEDというのもつらい。早くシリアルインタフェースを完成してオンラインデバッグができるようにしたい。
(10/30/07)

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

マイコン開発顛末の続き

 LEDを順次に点滅させるプログラムをアセンブラーで書いた後も、冒険物語が続く。アップルの6502以来のアセンブラーである。対象が全部1バイトというのもせせこましいが、ビットの数え方が右から0で始まるのでやたらと紛らわしい。ピン配置の番号、ポートアドレスの番号、データ内のビット番号、さらに出てくるピンの論理値が自由に操作できるというのも混乱の元だ。

 まあ、ソフトウエアの世界はもう40年の経験があるから、ハードほど不安ではない。アセンブラーは、I/Oや割り込みの部分の処理を理解したくてわざと試している。AVRはフリーのCコンパイラーが使えると言うのも売りで、まもなくCに移る予定だ。

 ところが、LEDの出力のときは問題なかったが、入力ではまった。入力といっても、簡単な押しボタンスイッチだ。ボタンを押している時間をLEDの点滅の間隔にするというプログラムで、参考書どおりにコーディングしても入力を認めない。2~3種のコーディング例を見て同じことをやっているのだが、がんとしてボタンを認めない。プルアップしてみたり、ポート位置を変えてみたりしたが駄目。シミュレーターで動かしてみると、入力さえ認められれば動くという確認はとれたので、ハードの問題か。

 意外なところで解決をした。こういうマイコンの入出力は、PORTと呼ばれる、I/Oアドレスに、INとか、OUTと言った命令でワークレジスターを介して行われる。そのまえに、当該のPORTの入出力の指定とか、さきほどの論理値の選定(0をHighとするかなど)などのデータを、このポートに出力しなければならないのでややこしい。

 少々疲れて、参考書のコーディング例を見るともなく見ていると、PORTAというアドレス以外に、PINAというアドレスがあることがわかった。アセンブラーのこういうシンボルは同じものに対して別の名前をつけるということはよくあることなので、気も留めなかったのだが、アセンブラーのリストを見ると場所が違うことに気がついた。

出力は、PORTAとかPORTBのままである。半信半疑で、PINの方から入力してみるとビンゴ!であった。こんなことは当たり前すぎるということなのか。少なくとも私の見た参考文献には書いていなかった。まあ、とにかく、やっと考えていたとおり、ボタンの押している時間で点滅するLEDプログラムが完成した。

初期のアセンブラ、CのLEDプログラムのソースコードはここにまとめてあります。
各ファイルの説明は、中のTiny26test.txtをお読みください。

「Tiny26test.lzh」をダウンロード

さて、現在のマシンはブレッドボードに仮付けされ、周囲をジャンパー線がうず高く行きかっているとても実用とはいえない実験機械である。これから、タイマー、割り込み、スリープなどの機能を学習し、省電力の温度記録ロガーを作成する予定である。
(10/22/07)

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

マイコン製作にはまる

はじめに

記念すべき最初の記事です。備忘録のつもりでこれまでずっと書き溜めた記録があります。これを公開するのが一番手っ取り早いのですが、今読み返してみるとちょっと冗長すぎる感じがします。  ただ、今までの経験を言えば、他の人が困っている状況を知ることは大変自分にとって参考になりました。「みんな同じ苦労をしているんだ」と思うと、とても励みになるのです。恥を忍んで少しづつご紹介していきたいと思います。

10/20/2007
マイコン製作にはまる

  株式の低迷で手持ち無沙汰になり、GPSロガーとか、長年の懸案だった自記温度計の自作などの資料を散策していたら、たまたまAtmel社のAVRワンチップマイコンを知った。ワンチップマイコンはMicroChip社のPICマイコンが有名で、私も5年ほど前、参考書を買って少し調べたことがある。レジスターの数が少なく余り好きになれないアーキテクチャーで、プログラムをロードするのにライターが必要だったりして実際にものを手に入れて実験するところまでは行かなかった。

  それに、本屋の電子工作の参考書や秋月などのショップに行っても、PICばっかりで生来のへそ曲がりが出て嫌気がさしていたところに、AVRの発見である。PICがインテルならAVRはモトローラというWebの情報も気に入った。その気になれば今はいくらでもWebから情報だけでなくソフトも手に入る。

  先週あたりからWebで調べ始めて、どんどん熱が上がり、遂に今週の火曜、久しぶりに秋葉原を訪ねた。当然のように千石電商で部品を調達する。秋月には、ご時世だろう団塊の世代の元ラジオ少年らしい年配者でごったがえしているが、千石は玄人向けなのですいていて助かる。ただ、ここでは私も素人の方に入るので店員との応対は気を遣う。 2Fの半導体の売り場の兄ちゃんに「Atmelのマイコンチップは...」と恐る恐る聞くとと「うちはAtmelおいてません!」と剣もほろろの返事である。代理店か何かの事情があるのか。AtmelはEEPROMでは有名な会社なんだけどな、とひとりごち。

 仕方なく、秋月によってチップを手に入れる。一ヶ¥280。肩の抜ける値段である。DIPソケットのATmega8あたりが欲しかったのだが、この店は何故か、megaシリーズはQFPなどという0.8ミリピッチの表面実装の石しか置いていない。あんなもの顕微鏡でもなければ自作で半田付けはできない。仕方なくTinyシリーズのATtiny26で我慢する。まあ、最初なのだからあまり背伸びはやめよう。

 車を走らせて家路に急ぐ。久しぶりの高揚感がある。家に帰り、半田ごてを出し、部品棚をかきまわし製作の準備をする。夕食もそこそこに地下の部屋にこもってWebから集めた資料を元に実体配線図を描き、まずISPシリアルライター(PCとターゲットマシンを接続するところ)の製作。これは暫く使うので、小さいユニバーサルボードで組んでいく。WebにはAVRマイコンの自作記が数多くあり、情報には困らない。UEW(ウレタン)線というのもここで初めて知った。

 DSUBコネクターを無理やりボードに固定するのに時間がかかり、夜中も2時を過ぎたので4箇所くらいの半田付けを終わったところでやめる。前に電話回線の着呼でPCを立ち上げるアダプターをTTLで作ったときより楽だが、線が細くもう拡大レンズなしにはきれいな仕上げはできない。

 次の日は飲み会で夜がつぶれたので、工作を再開したのは木曜である。家内を吉祥寺に送って帰ってきた昼前から夕方まで工作に没頭し、ほぼ出来上がった。ターゲットマシンができないと通線テストもできないので、こちらはブレッドボードでLEDを点ける簡単なしかけをつくる。ブレッドボードは結構便利であることにあらためて気づいた。AVRstudioというAtmel社提供の開発環境をダウンロードし(いや高速回線にしておいてよかった)、早速テストに入る。もう夜中を過ぎているが、こんな面白いことをやめるわけにはいかない。

 悪い予感はあたって、接続しても全く何の反応もない。そんな機械はありませんとにべないメッセージである。通信が絡むシステムのデバッグが一番難物だ。すべての要素が完全に動いて、やっと結果が出てくるAll or Nothingの世界なので、分析ツールがととのっていないと手がつけられないのである。

 そうも言っていられないので、少しづつ調べ始める。Webをよく読んでみたら、このISPアダプターは、AVRstudioという開発環境ではサポートされていないことが判明。あわててフリーソフトのAVRspを落として動かしてみるが結果は同じ。これでこの日はあきらめる。

 金曜日。家内が決算の申告をするというので、アッシーを引き受け、ついでに秋葉原に再度寄ることにする。「松屋でそばを食おう」という惹句で決まり。ドライヤーで熱収縮チューブを熱したとき誤ってICを壊した可能性も捨て切れなかったのでその補充を買っておきたかったのだ。夕方から再開するが、ICを換えてもだめ、ターゲットマシンの配線をあれこれ換えてみるも変化なし。シリアルのクロスケーブル指定のピン接続がどうも腑に落ちないので、もういちど参考書にあたって確認するが、ちゃんと合っている。このchaN氏は相当の技術レベルの人だ。

 テスター代わりのLEDを回路につけ、PC側の接続ソフトを動かすと、一瞬ターゲットマシンの入力線で光るのを確認し少し安心するが、これ以上のことはわからない。ケーブルが少し長すぎるも気になるが、この程度で動かないと言うことはないだろう。結局、この日は、古いテスターのボリュームを取り替えたり(シャフトが足らなくて仮止め)、開発環境を調べたりして、時間をすごす。それでも寝たのは3時。 A3141195
土曜日。フルートの練習をやって、工作の再開。重なるときは重なるもので、手の中に入ってしまうGPSロガーがこの日届き、これも触りたいのだが我慢する。もういちど、初手から、ISPアダプターのチェックを、昨日買ったマルチメーターの導通テストモードでひとつひとつ調べ始めた。DSUBピンと、抵抗のところは「接続されている」、その配線は途中、別のピンを経由してそこも接続されているの だが、念のため、そのピンにプローブをあてると「導通していない」! 何と言うことだ。ウレタ ン線が被覆をつけたまま半田付けされていたのだ。ピンに線を一回まわして、そA3141198_2の上から半田が乗っているので外見上からは完全につながっているように見える。試しに線を引っ張ってもビクともしない。

 あわてて半田付けをしなおし、午後4時。製作を開始して3日半目にやっとブレッドボードのATtiny26マイコンはLEDの点滅を始めた。開発時間は、初日6時間、2日目12時間、3日目8時間4日目3時間というところか。いや久しぶりに、解決したときのあのぞくぞくする気持ちを経験した。ほんとに安い娯楽である。このあとは正直言って、今までの自分の得意分野(ソフトウエア)に入る。サーミスターも買ってある。EEPROMを足せば不揮発メモリは200バイト以上あるTiny26なので、温度ロガーはこれだけで作れそうである。

今回の功労者:
秋月の¥2100のマルチメーター
 
(導通テストモードは助かった。これがあったので導通テストまでやる気になった)

ブレッドボード
 (はじめよく使い方がわからなかったが、これは便利だ)

chaN氏のWebページ、kumanさんのAVR試行記
 (そもそものライターは彼のオリジナル。またkuman氏の懇切丁寧な試行錯誤の報告がとても力になった。この場を借りて、厚く御礼申し上げます。)

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

トップページ | 2008年9月 »