SDカードPCMプレーヤーの開発

非圧縮オーディオの再生はやはり難しい(12/23/08)
　色々迷ったが、直近の次のプロジェクトは16ビットDACを使ったデジタルオーディオに決めた。折角DACチップを買ったのだ。動かしてやりたい。他は別の用途にも使える。ターゲットマシンを何にするかも迷ったが、結局やはり使い慣れたAVRにすることにする。

　というのは、H8/3069Fの現在のMMCインタフェースのSPIは高速と言ってもデータシートを見ると最大速度が250khzしかない。GPIOで手作りすればもっと早く出来るのだろうが、このままではAVRのCPUクロックの1/2のSPI（最大10Mhz)に比べれば見劣りがする。ARMプロセッサーのSTARMはSDカードを、買ってすぐにつけたが、こいつは当初より映像処理を目的にしているうえ、開発環境がまだ整っていないのですぐには立ち上がれない。で、必然的にAVRに落ち着いた。

　ファイルからWAVデータを読んでDACチップに投げるだけのプログラムである。始めは軽く考えていたが、サンプリング周波数44.1khz、データサイズ16ビットステレオという非圧縮のオーディオストリームは、シリアルで流れるとすると1.4Mbpsの速さである。MP3のビットレート192kbpsとか256kbpsという速さに比べると桁違いに大きい。下手をするとファイルを読む早さが間に合わないかもしれない。あわててSDカードのアクセス速度を確かめる。

　がた老AVR研のこれまでの実測データは、クロック8MhzのMega168で、読み込みが200KB/秒だ（バッファーサイズ128バイト）。オリジナルのchaNさんのレポートでは、9MhzのMega64でバッファーサイズが2048バイトだと300KB/秒近辺である。PCMオーディオの1.4Mbpsをバイトに直すと176KB/秒。うーむ、微妙なところである。余裕がありそうに見えるが、今度はファイルを読むだけでなくDACチップにデータを送るオーバーヘッドがある。SRAMの小さいMega168ではバッファーを大きく取れず難しいかもしれない。

　しかも、サンプリング間隔は、44.1khzだから22(正確には22.67)μsしかない。こんな短い時間で一回のファイルアクセスを完了することはSDカードでは不可能だ。処理は必然的にこの間隔を越えて動かなければならないが、もし、ファイルシステムがタイムディペンダントな部分を含んでいれば、CPUチップだけで再生しようというこの計画は即、破綻である。

　ソースコードを念入りに調べる。いやいやソースコードがあると言うのは有難いことである。調べた結果、データの送受はすべて1バイトづつSPIのデータレジスタを経由しており、データの読みこみ、書き込みのチェックはループで待っていることがわかった。AVRのSPIは独立したハードウエアであり、途中で割り込みがかかって処理が中断しても、アクセスが遅れるだけでおかしくなることはない。良かった。良かった。これで基本的な問題はクリアした。CPLDやFPGAを持ち出さなくて済む（ということで中々使う機会がない）。

　次の問題は、先ほどのDACへの書き出し処理のオーバーヘッドを含んだSDカードアクセスがはたしてPCMビットレートを上回るかと言う問題である。平均で遅いのは話にならないが、平均より早くてもバッファーサイズによっては途中で音が途切れる危険がある。こればかりはやってみるしかないが、せめて全体の目安くらいはつけておきたい。DACチップ(BU9480F)のデータシートをさらに読み込む。

　すると、このチップは、サンプリング間隔の中間でLとRを切り替え、それぞれ16ビットづつ送れば、中間を前後の平均をとった値で出力することがわかった。いわゆるオーバーサンプリングである。音質が良くなるのは良いが、送出するほうはさらに大変になる。間隔は22μsの半分の11μs(正確には、11.3μs)になる。そのたびに16ビットづつ送ってやらなければいけない。

　残る課題は、DACへのデータ送出を何でやるかという話である。AVRのSPIはひとつしかないので、ここに使うわけには行かない。それにAVRのSPIは8ビットで、16ビットを一気に送るようなしゃれたしかけはないので、オーバーヘッドを縮める時間稼ぎもできない。GPIO（普通のIOピン）で、クロックを自分で作りデータを送る方法に自然に決まった。

　BU9480Fが動く最も早いクロック(BCLK)は、60ns、16.6Mhzであり、この速さでデータを送れば、オーバーヘッドが減らせてSDカードアクセスに余裕ができるが、AVRがGPIOで出せる最高周波数はCPUクロックの1/2なので、最大クロックは10Mhzとなる。この速さでDACの16ビット送出にかかる時間は1.6μsで、サンプリング間隔との差、11.3 ‐1.6 = 9.7μsが、SDカードアクセスにかけられる時間となる。このあいだに2バイト(16ビット）が読めればバッファーアンダーランになることはないという理屈だ。

　データアクセス速度に換算すると、206KB/sec以上であれば、継続的な再生が可能なことになる。しかし、1.6μsはAVRのクロックから換算した上限値で、前後のLRCKなどのスイッチを考慮すると、2～3μsはかかるだろう。そうだとすると必要なアクセス速度は、215～240KB/sec以上ということになる。

　感触としては何とか出来そうな感じである。詳細設計に入ることにした。AVRの種類は迷ったがまずMega128で全体の動作を確認し、うまくいけばMega168にデグレードして、最終的には電池駆動のSDカードPCMプレーヤーにすることにする。

Mega168でも動きそうだ(12/27/08)
　実装手順としては、次の順番で実験を進めていくことにした。

(1)まず、DACの処理オーバーヘッドを入れたSDカードアクセスプログラムを組み、速度が所定の条件を満たしているか確認する。

(2)そのあとDACの部分をコーディングして動作を確かめる。最初のステップでは、UARTでファイル選択、再生開始、終了の処理を制御する。

(3)その後、LCDでのロジックを考える。

(4)アナログ出力は最初、オシロで観測するだけとし、そのあとオペアンプ、LPF等を追加して最終的にはヘッドフォンをドライブする。

　問題のWAVフォーマットはウェブで簡単に手に入れることが出来た。ハードウエアは、既にブレッドボードにMega128のSDカードシステムが動いているので、当面これを活用してテストを進めていくことにする。

　(1)のステップである。これまでの実測がMega168だけだったので、Mega128でもベンチマークをとった。chaNさんのFatFSにはサンプルプログラムがついており、その中には、ファイルのアクセス時間を表示してくれるfr,fwというコマンドが用意されている。ただ、このコマンドの時間単位が10msなので、短いレコードの計測では誤差がでるため、これを1msに縮めてより正確にデータが測れるようにした。

　ブレッドボードのMega128のバッファーサイズは2Kバイト(2048)ある。chaNさんのクロックが9.2Mhzだが、こちらは8Mhzである。結果はクロックの違いを正直に反映して、わずかに遅くなったが、それでも300KB/秒近辺に納まった。次に、クロックを16Mhzに上げる。SDカードとのアクセスも倍になる。アクセス速度は期待通り、倍にはならないが倍近い550KB/秒にはねあがった。しかし、残念なことに読めないメディアがでてきた（パナソニック128MBのミニSDカード)。

　まあ、2GBのマイクロSDが読めるのでこの問題は先送りして次に進む。バッファーサイズを256バイトに縮める。これはCPUをMega168に落としたときに使えるかどうかのテストである。アクセス速度は当然下がったが、330～360KB/秒と十分な速さである。素晴らしい。面白いことに16MBのメディアの方が、2GBのメディアよりわずかだが早い（chaNさんのレポートと同じ）。

　次はいよいよDACの割込みを考慮したときのアクセス速度の測定である。タイマーのひとつTIMER0を使って何もしない割込みルーチンをつくる。11μs単位に割込みがかかり、その度に2μsループしてから帰るルーチンである。動作確認のためにモニターコマンドを追加して、割込みマスクをON/OFFできるようにする。

　動かしてみる。おや、アクセス速度は殆ど変わらない。勿論、割込みが入るほうが遅くなるが思ったほど遅くならないのだ。メディアを替えたり、データ量を変えるとわずかに変化するが、それでも1～2%しか低下しない。何故だろう。チャートを描いてみてその理由がわかった。300KB/秒というのは、等間隔で1バイトづつ読むとしてその間隔は3.3μsである。　SPIはデータレジスタをCPUが読むとフラグが立ち、次のデータが来るまでフラグは変わらない。CPUはこのフラグが変わるのをひたすらループして待っている。遅くならないのは、待ち時間に比べてCPUの処理時間が少なく、2μsのDACのオーバーヘッドの殆どがこの中に吸収されてしまうからだと考えられる。

　これで、SDカードによるPCMオーディオプレーヤーの基本的な問題はすべて片付いた。Mega168を16Mhzで動かせば、バッファーサイズが256バイトでも、かなり余裕を持ってPCM44.1khz ステレオ16ビットのオーディオデータをデコードすることができそうである。FatFSもR/Oにすればフラッシュサイズは8KB以下に納まる（LEDマトリックスのときに確認）。コーディングが楽しみになってきた。

　ソフトの構造はそんなに難しくない。ファイルのアクセス単位が大きいので、リングバッファーではなく、ダブルバッファーにして、DACの読み出しが別のブロックにあるときのみ、そこへデータを読み込むようにする。最初は、DACを止めておき、データが半分貯まった(2番目のブロックを読み始めた)とき、割込みマスクをはずしてデコードを開始する。このあとはDACのデコードとファイル読み込みとの競争になる。

　そろそろ、演奏の中断(途中から再開)、中止、曲の選定などの操作仕様を考える段階に来た。このあたりは最初のうちから考えておかないとソフトの構造が汚くなる。携帯機器にしたときのLCDの画面仕様も課題だ。手持ちの2行LCDで曲リストなどを出せるだろうか。Mega168なのでフラッシュメモリは限られている。なかなか難しそうだ。でも、それだから楽しいとも言える。

やっぱり画像と音響が面白い

お馬鹿な勘違いの照れ隠しにDACチップを衝動買い(12/16/08)
　H8/3069F LANボードのOS（MES)整備が一段落して、次の電子工作の課題をあれこれ考えていたが、やりたい方向が少しづつかたまってきた。そこで先日、久しぶりに秋葉原に出かけ、材料を買い揃えてきた。ひとつは、中古の5.4インチのカラーTFT液晶パネルである。アナログRGBとコンポジットの変換基板がついて￥2680(CocoNet）。

　前からカラーグラフィック液晶は欲しくてCRTC（ビデオコントローラー）をFPGAで勉強を兼ねて作り、静止画ビュワーにしようと考えていたのだが、このあいだのAVGAのプロジェクトの話と「そら」さんのコメントが後押しをした。とりあえず、このあたりから映像の勉強をすることにする。このあいだのAVGAはAVRのチップひとつでCRTCの部分まで作っているのだが、こちらはこの部分はFPGAで作る予定である。

　もうひとつが、鈴商で買った16ビットオーディオのDAコンバーター（ロームのBU9480F)である。実は、DACチップは当初買う予定がなかったのだが、このあいだH8の8ビットDACで16ビットのオーディオを再生出来るようなことを書いてそれが全くのでたらめであることがわかり、その埋め合わせと言うか、照れ隠しの衝動買いである。

　8ビットDACを2つ並べれば、16ビットデコードができるなどと気楽に書いたけれど、考えていた方法は、9ビットDACでしかなかった。加算回路などオペアンプの回路まで検討してブロックダイヤグラムを書き、制作手順まで考えたあと、寝る前に風呂に入っていて突然気がついた。馬鹿な話である。

　256段階(8ビット)しかないコンバータで、65535段階(16ビット)のオーディオデータを簡単にアナログに出来るわけがないのにどうして出来ると考えたのか今になると不思議としか言いようがないのだが、そのときは大真面目だった。出来ないとなると大上段にふりかざした手の降ろす場所がなくなってしまった感じである。デジタルオーディオを何としてでも実現しないと気持ちがおさまらなくなってしまった。

　このDACチップ(BU9480F)は、シリアル入力(SPI)で8ピンしかない。恐らく安いCD-ROMドライブのアナログ出力などに使われていた廉価版なのだろうか、値段が安い(￥200）。秋月のSOIC変換基板(9個入って￥100)につけると小さくて可愛い。こんなに小さくてもステレオ16ビットのデジタルデータをアナログにするのだ。偉いものである。

　秋月では、SACDレベルの24ビットオーディオをデコードする1bitDACの石(FN1242A )が￥800で売っており、それ以外にもNECの16ビットDAC（μPD6386)も、2つ￥500で手に入る。これはロームのものより倍のオーバーサンプリングが出来るようだ。しかし、デジタルオーディオの入門にはこんどのやつくらいがちょうど良さそうだ。

　とりあえずは、SDカードに入ったWAVデータの再生が目標である。プラットホームはまだ決めていない。SDカードを読めるボードは、今、AVR、STARM、H8と3つもあるので選択に悩むところである。

　液晶パネルの方である。包装を明けると、やはり中古なのでケースは赤茶け、表示面保護パネルにも少し傷がついていて値段相応というところだ。フラットケーブルがついていたが、このままで接続できるのではなく、加工が必要である。このあたりが安い理由なのだろうか。フラットケーブルのコネクターピンをピンセットで引き抜き、説明図どおり配線して、自宅のデジタル一眼レフのビデオ出力を入れてみた。おう、出た出た、コンポジット(NTSC)の部分は問題ない。色も綺麗だ。

　２つの方向の部品は揃ったけれど、プロセッサーまわりのハードや、ソフトの部分は全く手が付いていない。これからである。オーディオPCMデータのフォーマットは概念的には理解しているつもりだが、現実のファイルの中の実際のデータがどうなっているかまだ何も知らない。ウェブかバイナリエディタかなにかで調べる必要がある。

　電子工作はやっぱり音が出たり光がでてくるのが一番楽しい。結局、期せずしてAVの部品が揃った。しかし、この２つを合わせて何か作ろうとは考えているわけでもない。画像表示装置の目的は静止画ビュワーで、音響の方の目的はSDカードに入れた非圧縮のオーディオデータの再生である。

　SDカードの記憶容量の増加の速さと低価格化はもう驚異的というほかない。今の主流は、SDHCという2G以上の規格で、それまでの規格の2Gのメディアは￥100近辺という捨て値で売られている。これを利用しない手はない。マイクロSDなら小指の先ぐらいの大きさで、音楽CDが4枚は入るのである。組み込みマイコンでは、mp3が流行っているが、私はクラシック一辺倒なので、mp3の音は生理的に違和感がある。娘のMDラジカセ程度のスピーカーで聞いてもその差は歴然としている。どうも音が抜けた感じがしないのである。これだけメモリが安くなれば何も圧縮データで聞く必要もない。非圧縮のディスクプレーヤーを目指すことにする。

Telnetdは動いたが、OSはMESからTOPPERS/JSPへ(12/20/08)
　実は、もうひとつやりたいことがある。H8/3069FのOSの転換である。このあいだひょんなところでMESで動く、前とは別のTelnetdのバイナリが見つかったので入れてみた。少し古いバージョンのMES用だが、こいつは動いた。これでシリアルをつながなくても、イーサネットだけで開発が出来る。素晴らしいと思った。しかし、テストを続けるうち、問題点がいくつも見つかってやっぱり実用に耐えられる状況ではないことがわかった。

どんな問題点かというと、
・TelnetからPSコマンドを入れると固まる。本体のシリアルも動かなくなる。
・exitコマンドで接続を切ると、カレントディレクトリにヒストリーファイルを残し、次回の接続時に、無条件に実行してしまう。バグと思われる。 なお、このファイルはWindowsでファイルとして見えるが、消去できない。AVRのFatFSでは表示されない。ファイル名は空。RAM上では次のリセットで消えるが、SDカード上では残ってしまう。
・接続を切っても、クライアントのプロセスが残っていく。長期の運転には耐えられない。

　このTelnetdもソースコードが公開されていない。デバッグすることが出来ない。どうも欲求不満が溜まってきたので、そろそろOSのMESを諦め、TOPPERS/JSPに変えようかと思っていた、その矢先、ウェブに、同じプラットホームのH8/3069F LANボードに、このTOPPERSをOSにし、今やろうとしていることと殆ど同じことを実現しているページを見つけた。SDカードからデータを読むMP3プレーヤーとWebサーバー、それに簡単なモニターがついている。何をするにしてもソースが公開されているのは有難い。早速ソースコードをありがたく頂く。これで、いちから開発する手間が省ける。やっとTOPPERS/JSPに移る決意がかたまった。

　しかし、雑誌や、ウェブで勉強を始めたのだが、理論的な話はともかくTOPPERSそのものの実体がまだつかめない。ウェブにはインストールする手順や方法は山ほど出ているが、実際にこれをスタンドアロンで動かしてシステムにする話がどこにもない。あるのはテストプログラムを動かしているだけである。だいたいシェルに相当するものがない。

　しかもROMには簡単なローダーだけを入れ、TOPPERSカーネルはすべてRAMに展開して動かしているケースが圧倒的に多い。H8/3069FのフラッシュROMは512Kもある。何故、ここを活用しないのだろう。TOPPERSを使った市販のH8のアプリケーションボードはどうしているのだろう。フラッシュROMにすべてが入っていないと動かないはずなのだが、この手順を説明したウェブの記事が見つからないのだ。

　それはともかく、とりあえずはMES並みのシェルを開発することを次のターゲットにしようかと考えている。Linuxを入れる必要がでてきた。Cygwinでも良いらしいが、久しぶりのLinuxもちょっと食指が動く。TOPPERSのファイルシステムは、私もお世話になった、あのchaN氏のFatFSが使われている。心強い。

その後のH8/3069Fとアプリケーション

MESともう少しつきあう(12/8/08)
　このブログのタイトルは「がた老AVR研究所」で、余りH8ばかりやっていると看板と中身が違うと言われそうだが、今暫くお付き合い願いたい。というのも、2本前の記事で、MESに必要なコマンドが少ないと文句を言っていたが、訂正をする必要が出てきたのである。

　参考書を見ると該当するシステムコールはあるのだが、コマンドとしてはないことを、shellのソースを見て確認し、そう書いた。しかし、その後ウェブを見ていたら、ここのページで、文句を言っていた機能のコマンドが解説されているのを発見した。

　あわてて、MESを立ち上げ、コマンドを入れてみた。情報どおり、ちゃんと実装されていた（2.3r12)。実装されていたのは、作動中のプロセスの表示（ps)と、プロセスの消去(kill)、それとファイルのコピー(copy)である。私の見たshellのソースはかなり古いバージョンだったようだ。この3つのコマンドがあれば、大分助かる。前の記事の訂正をしてお詫びを申し上げる。

　それと、ウェブサイトでMMCが動かないH8用の最新バージョンMES(V2.3r18)でも、モジュール形式にしてmmc.exeだけを古いのにしたらMMCが使えたという情報を見つけた。早速、このサイトから古いmmc.exeを頂き、カーネルを作り直したら見事にMMCが動いた。ifconfigや、mountコマンドをautoexec.batに書き込んで、電源を入れたら自動的にネットワークやSDカードが動くようにする。これでウェブサーバー関係の開発がすぐ出来る環境が整った。

　勢いに乗って、これもウェブで見つけた、telnetサーバーを入れてみたが、これは残念ながら、送信はするが、パケットの受信でハングアップした。このソフトのソースコードがあれば恰好の研究材料になるのだがバイナリだけでは何ともしがたい。MES2.3r6用なのでr17では動かないようだ。MESは現在、最新バージョンが2.5になっており、情報がもう少しあれば、かなり遊べると思うのだが、いかんせんH8用の2.3のソースの提供がないもので手探り状態である。

　しかし、H8にはDACがついている。2つもある。ただし、それぞれが8ビットなのでオーディオには機能不足と考えていた。しかし、昨日テニスをやった帰りの渋滞のバスの中で突然ひらめいた。一方のDACの出力をオペアンプか何かで加算してやれば、8ビットづつ重ねて16ビットのPCMのオーディオ信号をデコードできるのではないか。このアプリケーションならアナログの勉強にもなるし、H8の活用にもなる。

　H8のデータシートを見ると、DA変換は最大10μsで出来るようなので、44khzのCDレベルのデジタルオーディオのデコード(22.4μsサンプリング)なら余裕である。ステレオにするのは難しい。時間的にはぎりぎり入りそうだが、8bitDACひとつで16bitデコードする方法が考え出せない。アナログ値をホールドする回路があれば出来そうなのだ。MCUのクロックは25Mhz。16ビットのデジタル値で判断するロジックを組んでも時間的には数百ステップの余裕がある。

　外付けのオーディオ用のDACチップを買ってくれば何でもない話だが、それは動いて当たり前の世界で、動きました。音が出ましたというだけのことである。こういう手持ちのリソースで何とか実現しようと工夫するところが一番楽しい。アマチュアの醍醐味のひとつである。色々調べ始めている。

わくわくさせるアプリケーションはないか(12/12/08)
　話はAVRにもどる。サイトを巡っていると色々なニュースにぶつかる。最近、AVRも人気が出てきたようで、一年前と比べると沢山のページが検索でヒットする。愛好者が増えているようだ。同好の士としては喜ばしい限りだが、先だってPICのマイクロチップ社がTOBをかけてAVRの製造元、Atmel社の買収を目論んでいるというニュースが流れて先行きに暗雲が垂れ込めてきた。もともと、PICはインテルで、AVRはモトローラだというキャッチフレーズが気に入ってAVRにのめりこんだのだが、友人に言わせると「敗者につくと損」なのだそうである。

　まあ仕事で使うのならともかく、趣味の世界である。そのときは、「いや私は判官びいきだから」と笑っていたが、それでもひいきにしている会社がライバルに買われるのは愉快ではない。少し心配していたが、最新ニュースによるとAtmelが拒否してこの話はそのままになっているらしい。

　それはともかく、アセンブラーでガリガリ、プログラムを書いているのではないので、日常的にはAVRの優位性を感じることはない。でも、AVRの素直なアーキテクチャー、開発環境のローコスト性、技術重視で商売気（げ）の希薄なところ（まあ、これが不振の大元だろう）などが気に入っている。何しろ秋月電子では、Tiny2313が￥100で買えるのである。Tinyから、Megaへのスケーラビリティも悪くない。

　海外では日本より人気が高いそうである。これもウェブで見ただけだが、安いAVRチップだけで、USBインターフェースを実現したり（HIDASPで話題になっている。オリジナルはここ）、AVGAと言って、チップひとつで、アナログRGBの出力までやってしまうゲーム（すんさんのページが詳しい。オリジナルはここ）など、面白そうな話題にはこと書かない。どうも目移りがしてなかなか次のプロジェクトが決まりそうにない。

　実用的な用途としては、今、考えているのが、AC電力センサー（正確には電流）ロガーのリモート化である。最近、話題になっているXbeeを使ってみたい。センサーを置く予定の場所は、家の台所の裏の分電盤である。無線LANも興味があるが、ちょっとおおげさ過ぎるし、イーサネットは結構消費電流が大きいので省電力化できない。ただ、このXbeeは市場に殆ど機器が出回っておらず、価格もそこそこする。しかも能力的に、家屋の階を隔てて通信が可能かを調べる必要がある（木造なら問題ないようだが）。ウェブで見る限りではその実例を見つけることが出来ない。まだまだ相当下調べが必要なようである。

　それにしても、ウェブはありがたい。「部品のついている基板を見ているだけでワクワクする」というキャッチコピーを獣医さんのページで見つけ、私と全く同じなのですっかり嬉しくなった。自分は工学部出身だが、どうみても頭は文系である。しかし、少年のときから、蒸気機関車のクランクシャフト、時計の精密な歯車、低空旋回する単座飛行機、細かい部品の乗った配線基板、オートバイの空冷エンジンのフィンなどは、見ているだけで頭の中がクラクラしてくる。この気持ちは今も基本的には変わらない。そうなのだ。男の中には、こういうものにしびれる人間が一定の割合で存在することを今さらながら確認した。

秋月H8/3069F LANボードの実力

作るものがない(12/1/08)
　H8でMMCインターフェースが動き、がた老AVR研究所の懸案は、これでほぼ片付いた。次の課題を探すため、現在の状況を整理している。これまでに買い込んだ雑誌付録基板が沢山ある。こいつらは、全て一通り動かしてみて動作することは確認したが、そのあと殆ど何もしていない。

　一番の大物はFPGA基板(Spartan-3E)だ。　これはやはり画像関係の大量高速データ処理まで登板はなさそうだ。開発環境は整えたが、周波数カウンターぐらいのアプリケーションでは25万ゲートが泣く。

　32ビットのSTマイクロのARMプロセッサー(STM32F103)は、このFPGAと組み合わせて使いたい。加速度センサーはついているが、まあ、機械を立てたり横にしたりしたときに画像が替わるのに使えるくらいか。適当なグラフィックLCDを手に入れて静止画ビュワーにでもしようと考えている。

　フリースケールのイーサネットマイコン(ColdFire MFC52233)は、まだ正式のモジュラーをつけていない。これも32ビットマシンで、フラッシュもそこそこあるし(256KBある)、SDカードをつければ、H8でやろうとしたことをほぼ充足できる。H8と少し被るがこのあたりが次の有力なテーマになりそうだ。

　NECのUSBマイコン(78K0)は、今のところ、ウェブで公開されたファームを入れて、AVR純正のAVRisp互換ライターに納まっている。ケースまで買ってあるが、これまでのchaN氏のAVRspの使い勝手が良く、なかなか登板の機会がない。ケースもそのままである。

　で、H8である。まだ具体的なアプリが思いつかないので、こまごました追認テストをやった。　MMCが動いたMESの古いカーネルはconfig.sysなどが含まれたバイナリーしかなく、ビルドしなおすことが出来ない。そのためネットにつなぐのにいちいちコマンドが要る。不便で仕方がない。それで新しいバージョンのMESでも動くかどうか試してみた。結果は、やはり最新バージョンV2.3r18では、動かなかった。結果として針の穴を通すような感じでMMCを動かしたことになる。

　MMCトラブルのきっかけを作った、Vccを制御するFET(2SJ325)のゲートがオープンでも電圧が出てしまうという現象についても時間が出来たので確かめてみた。ゲートにVccをかけても少し電圧が下がっただけで2V以上でていることがわかった。3.3VがVccで、ゲートをオープンにして、2.6V、ゲートをHigh(Vcc)にしても2.4Vの電圧がかかっている。これではSDカードは息絶え絶えだろうがレスポンスを返してしまう。もっともMCUはOFFだと思っているので実害はでない。

　FET単独でテストしてみた。単独では問題ない。ゲートをオープンにしたり、High（Vcc）にすれば、ドレーンは完全に0Vに下がる。回路で電圧が上がるのには思い当たることがある。カードには、SPIの配線が接続されており、カードの電源を切っても、これらの信号線からわずかでも電流が流れ、Vccを上げることになっているに違いない。

　それにしても、次の課題が見つからないというのもちょっと困った状況である。アマチュアの電子工作なのだから何も役に立つ用途を考える必要はないのだが、たとえないにしても、何かわくわくするものが欲しい。あれから色々、メモにインターネット応用のアプリケーション候補を書きとめているが、適当な材料がない。プリンターの電源制御は大当たりだったがあとが続かない。

　一番やりたいのは、ウェブカメラで、地下に居ながら居間の状況が見えるようにしたいのだが、家族から総スカンを喰うことは必定で、ちょっと手が出せない。外から見えるようになるなどと言ったら、ただではおかないだろう。まあ、ペットでも飼えば必然性が出てくるかもしれないが、この企画は残念ながら今のところ具体化の可能性は低い。

　外からもアクセスできるファイルサーバーはお家サーバーとしては実用的だが、ファイルサーバーは速度と信頼性が要求されるので、H8や付録イーサネットマイコンにはきつい。いくらなんでも記録媒体がSDカードというのでは話にならない。

　で、残るのはメールクライアントと電光掲示板、音声発生装置などを組み合わせた、ウェブ伝言板というものくらいなのだが、どうもいまいち意欲がわかない。要するにわくわくするものがない。むしろ、電力ロガーをXbeeなどを使って無線伝送させる方に興味がある。しかし、まだこれは少し敷居が高い。

　偉そうなことを言っているが、H8のCGIもまだ動かしていない。少し、このへんのお勉強をしてから先を検討することにする。

SDカードからでもRAMからでも転送速度が変わらない(12/4/08)
　H8を含めた具体的なテーマが見つからないので、H8で、これまでやりたかったウェブの画像ファイルの転送をテストしてみた。tftpを使えば、RAMに送ってテストすることも出来るが余り意味がないので今までやったことはない。電源を切ればデータはすべて消えてしまうし、起動するたびにファイルを送っていたのではおよそ実用的ではない（まだ、こだわっている）。何をさせるにしてもマイコンサーバーの画面が、無粋な文字だけでなく、ちょっとしたテクスチャーでも張ってあれば、楽しいし、見栄えがする。SDカードに入った画像ファイルがどの程度の早さで表示されるかは確認したいところだった。

　早速、SDカードにいくつかのJPEGファイルを入れ、index.htmファイルで指定してhttpコマンドでサーバーを立てる。うぬ、file not foundだと、何故だ。幸い、httpコマンドはソースがあるので調べてみる。何だ、index.htmのデフォルトは/ram0/にあるファイルで、カレントディレクトリではない。/mmc1にあるファイルは、パラメータにフルパスで入れてやる必要がある。　どうもこのhttpコマンドは練習プログラムのようでディレクトリの取り扱いが十分でない。indexファイル以外のファイルはカレントディレクトリにないとアクセスが出来ないようだ。プログラムを変えるのも面倒なのでカレントディレクトリを/mmc1にしてhttpを動かしてしのぐ。

　おう、出た出た。一昔前のインターネットを思わせる遅さだが、何とか180KBのJPEGファイルが表示された。8秒程かかる。SDカードのSPIのクロックはロジアナで見たところでは、200khz程度で、バイトに直せば25KB/sec。うむ、ちょうどほぼここの転送速度と合っている。SPIはもっと早くすることが出来るはずで（AVRでは数メガビット/秒）、ここを早くすれば、もう少し改善されそうだと、その時は思った。

　上機嫌で、では念のためRAMから転送すればどうなるか確認するため、tftpで同じファイルをRAMに送ってテストしてみた。ところが、これが何と全く早くならないのである。はじめは、まだSDカードから転送しているのかと確かめたが、間違いなくRAMからの転送である。7秒ちょっともかかっている。RAMのアクセススピードはメガビットのオーダーのはずである。これはH8からNICチップへの転送速度がボトルネックになっていることを示している。

　ウェブサイトでの、「秋月H8/3069LANボードは遅い」という評判はこういうことだったのか。I/Oポートの数を増やすため、NICチップのRTL8019との転送は16ビットでなく8ビットに減らしてあるという。それにしてもこれほど遅いとは思っていなかった。そういえば、pingそのものも、このあいだのMega168とENC28J60の組み合わせでは1ms台だったのに対して10～15msかかっている。転送速度だけの原因ではないかもしれない。

　SDカードのアクセスを早くすれば、実用的な速さになると期待していたが、これではいくら何でも遅すぎる。このボードを中心に家のリモコン環境を作ろうという思惑は完全にはずれた。静止画にしてもウェブカメラなどのサーバーとしては全く使えない。

　まあ、電源制御とか、テレメータリングなどの用途では速度は余り関係しないし、制御ポートが多いほうが汎用性は高い。このネットワークボードに合ったアプリケーションを見つけてやる必要がでてきた。

細々とした工作を楽しむ(12/5/08)
　次のテーマが見つからないのだが、困ったことに手を動かしていないとどうも落ち着かない性分になってしまった。そういうこともあって、今日は久しぶりに秋葉に寄って、テスターリードを買ってきた。秋月のテスター（マルチメーター）のリード線が断線しているのでその補充である。いくつか店をまわったが、意外に、小さいテスターに合う小ぶりのテスターコードがないのである。あるのは、みな無骨な大きなものばかりで、結局、三和のカードテスター用(\600)というのを手に入れたが、帰って合わせてみるとこれでも大きすぎる。

　この秋月のテスター（P-16）は安いし、機能が豊富なので(容量、周波数まで測定可能）、愛用しているが、気に入らないのが、横についているテスターリードの収納ケースだ。いちいちケースの中にリードを入れないと納まりが悪く片付いた感じがしない。リードを本体からはずせないのである。リードをしまうたびに、これを繰り返すと線が切れやすくなるのだがと懸念していたら、案の定やっぱり切れた。

　で、リードを交換するついでに、ケースの横に小さなピンジャックをつけてリードを別に収納できるようにした。これはなかなか上手く行った。それにしても、こんなせまいところに正確に穴を開けられるのも、工具を揃えたおかげである。がた老AVR研究所のコードの処理は写真にあるようにSフック（エスカン）を使っていつでも取り出せるようになっている。ここにテスターリードもかけておけば机の上が広く使える。

　次に取り組んだのが、機種交換して余った携帯の電池の2次利用である。ワンセグ携帯で買って1年で新しいのに取り替えた古い機械が残っている。電池もへたっていない。勿体無いのでこれを利用しようと前から考えていた。定格は3.7V 830mAhとパワーも十分だ。こいつを利用するために、東急ハンズで接点になる燐青銅線まで買ってある。アクリル板をくりぬいて電池ケースにし、ここに接点をつければ、ちょっとした携帯電子機器の電池代わりになるはずだ。充電は、怖いので自作ではなく元の携帯機器を利用する。

　工作の前に、電池がどれだけ余力を残しているか、ブレッドボードでテストしてみた。0.5ミリの燐青銅線を小さく切り、ブレッドボードに差して臨時の接点を作る。たっぷり充電すると、電圧は無負荷で4.3Vを指した。LEDをつけて15mA程度を連続して流してみる。10時間ほどで、最初の4.1Vから、4.0Vに下がっただけである。なかなか優秀だ。定格の3.7Vというのは、830mAhを出したあとの電圧なのかもしれない。余力はまだ十分あることが確かめられた。工作が無駄になることはなさそうだ。