PCMプレーヤー続き: どのSDカードにも頭出し位置を記憶させる

LTC4054を買ってしまった(4/1/09)
　それにしてもウェブはありがたい。このあいだリチウム電池の充電用ICはショップでは品切れだと書いておいたが、ウェブのひょんなところでこのICが行きつけの千石電商でも置いてあることを知った。今急にこのICが必要なわけではないが、こういうものはあるときに手に入れておかないといつなくなるとも限らない。仕事の帰り秋葉原に立ち寄り、店を覗く。

　2Fの半導体売り場のアナログICのところにそれはあった。いやあ、さすがは千石だ。商品名はLTC4054ES5-4.2とある。データシートによればこれが正式の型番のようだ。価格は￥440。通販と変らない値段だ。800mAまで充電できる。ケースから取り出そうとするとこれが豆のような小ささだ。2つ購入する。ついでに秋月電子でSOT23用の変換基板を手に入れる。こいつはこのあいだ見つけた裏表6種類の表面実装のチップをDIPに変換できる基板だ。少し大きいが実験用なら問題ないだろう。

　意気揚々と家に帰り、基板にあわせてみたら、この基板にはLTC4054のSOT23-5のパターンがない！　それにしても、この小ささは尋常ではない。チップ部品とかわらない小ささで、5ピン出ている。ピン間隔は0.95ミリ。くしゃみでもしようなら間違いなく吹き飛んで行方不明になる。これで0.8Aの充電ができるのか。ウェブの製作記事にあるように、大きめのランドにつけて放熱をしないといけないかもしれない。

　秋月の変換基板にSOT23-8というのがあり、真ん中のパタンを合わせてしまえば何とか使えそうだ。問題はこれより電池フォルダーをどうやって作るかである。やっぱりこれまで考えていたように、アクリル板をくり抜く方法が一番確実と思うが、作業量を考えるといますぐという気分にはならない。

16Mhzでは出だしがおかしいファイルがある(4/03/09)
　Mega328のクロックを16Mhzにして、実装版でテストしている。ブレッドボード版でテストしたとき、5枚あるうちの1枚のカードが、最初の曲の再生で、出だしの2秒あたりまでバッファーアンダーランのときのような割れた音ではじまるようになった。間もなく正常に戻るが、あきらかにディスクアクセスが遅れてバッファーの前の音を拾っている感じだ。

　SDカードの抜き差しを何回かやって接触を良くするとこの現象は消えたので、実装版も16Mhzの石に取り替えた。ところが、実装版でも発生した。さらにもう一枚同じような症状が出るファイルが出てきた。必ず、カードの最初のファイルで起きるので、これが原因かと一旦消して別のファイルを書き足し、問題のファイルを移してみるがやはり同じ。20Mhzでは起きない。ファイル読み込みのリトライをやっているのだろうか。

　SPIの速度をクロックの1/2の8Mbpsから、1/4の4Mにするとだいぶ現象は納まったが、まだごく稀に起きるときがある。気持ちが悪い。それもトラブルの発生する音楽ファイルが限定されている。クラスターチェーンの読み込みなどでの遅れならば、ファイルの位置を替えたら変るはずだが、直らないというのも腑に落ちない。電池の消耗量を調べて余り変わらないようだったら、クロックを20Mhzに戻した方が精神衛生上良いかもしれない。

ブログの引越しで大騒ぎ(4/5/09)
　このブログはNiftyを使っている。実は、本来のIDで使えるブログは学校の同窓会のブログに提供しており、研究所のこちらの方はフリー版だ。まあ、ひさしを貸して母屋をとられた形だが、最初はこちらをホームページ形式にするつもりだったので仕方がない。ところがこのあいだNiftyから、6月からブログのアカウントを一元化するという知らせが届いた。フリーならいくらでもアカウントを作れるが、料金を払っているNifty会員には複数アカウントどころか、NiftyのIDでしかブログが作れないというのも矛盾した話である。複数アカウントには追加料金がいる。

　文句を言ってみても始まらない。ただ同窓会のアカウントがひとつというのは大変困る。というのは執筆者を複数にして彼らにブログ専用のIDとパスワードを知らせてあるからだ。一元化されると、私のクレジットカードの支払いから料金体系の変更まで出来るIDを教えないと今の状況を維持できない。みな友人とはいえ、このIDを人に教えるわけには行かない。しょうがないので、同窓会のブログもフリー版に移動することにした。

　これが難儀したのである。2日間かけて何とか引越しを終えたが、写真の移動ができていない。無料で使っているので余り文句は言えないが、このブログの移動は最悪の環境だ。

　最初は、記事の読み出し、書き出しという機能があるのでこれを使えば簡単に出来ると思っていたのだが、記事を読み出してみたら、記事だけで4MB近くある。はじめわけわからずに、これを書き出したら、ファイルサイズが大きすぎると怒られた。

　調べてみたら、何とNiftyのアップロードのファイル容量の最大はたったの１MBだという。SPAMやロボットの横行で制限したらしいが、それにしてもこれでは話にならない。あわててブログのTypePad形式を調べ、ファイルをいくつかに分割して、昨夜なんとか記事だけの移動は成功した。

　写真も出るので、これでOKと思ったのはぬか喜びだった。旧ブログのURLからすべて写真を引っ張ってきていることを発見して愕然となる。何だと、この画像ファイルはどうするんだ。こちらに全部引き取って、リンクの張り直しか。冗談だろう。これでブログの引越しができますなどとは言わないで貰いたいものだ。

　悪態をついてみても始まらない。アップした写真のダウンロードをしようとして、また愕然となった。まとめて画像ファイルをダウンロードする機能がない！参ったである。何か本気でハッキングしてこのディレクトリツリーを全部引き出す方法を考えたくなった。そうでなければ、ひとつひとつの記事のHTMLからファイルを少しづつ抜いてくるしかない。

　気の遠くなるような作業である。記事だけで200本以上あるのだ。写真の画像ファイルは数千枚にのぼるだろう。サムネールがついたり、クリックするときの補助的なタグにもファイルのURLが入っている。つまり数千枚の3倍、万を越すファイルの移動を手でやれというのか。ここを空家にして本来の研究所のブログにしようと思っていたが、これではいつになったら空家に出来るか見当もつかなくなってしまった。

複数のSDカードの演奏位置を覚えこませる(4/8/09)
　通勤の往復にSDカードプレーヤーを持ち歩いている。ヘッドフォンを音が漏れやすいゼンハイザー(PX100)からSONYの安物のイヤホーンに替えているので良い音は楽しめないが、昔使っていたウオークマンなどに較べれば格段の音質で、頭出しが楽なのが良い。すっかり気に入ってしまって、家族から冷やかされている。

　使ってみてすぐ気がついたのが、折角、SDカードの頭出しの場所を覚えさせても、別のSDカードを差し替えると、それが無効になってしまうことである。1枚のときは良いが、何枚もSDカードを差し替えるときは不便で仕方がない。そうか、情報はEEPROMに入れるのだから、何枚SDカードのデータを記憶させても、SRAMを圧迫するわけではない。フラッシュはMega328で32Kもあり有り余っている。EEPROMも余裕の１KBだ。

　思いついたらすぐに体が動くタイプである。早速、SDカードの情報を配列形式で複数個、EEPROMに覚えこませ、全体のファイルサイズ、ファイル数がかわらないSDカードは頭出しの情報を残していく改修にとりかかった。EEPROM上に構造体を定義する手法をウェブで勉強する。構造体の配列を作って、そこへ次々にSDカードの情報を残して行き、一致すれば、そのときの頭出しを使い、SDカードが新しければ、古いものを消して登録する。

　EEPROMの0番地は、リセットなどのタイミングで壊れると言うので、4バイトほどシフトさせてから、配列を置く。ロジックはそんなに複雑でない。これまでのファイルリストと同じような構造だ。昨日の夕方から夕食を挟んで夜10時過ぎには出来上がる。テストしてみた。しかし、全く思うような動きをしない。まあ、プログラムは考えたようには動かないものだ。

　UARTを組み込んでデバッグするのもおおごとだ。EEPROMはAVRispでダンプして見ることが出来る。ダンプさせてみた。なにい、データは一組しか記録されていない。しかもEEPROMの頭から書き込まれている。確か4バイトずらしたはずなのに。それに配列の位置を記録するデータがない。うーむ、わけがわからない。細かいところをつめずにメモを数行書いただけでコーディングを始めると大体こういうことになる。EEPROMの関数の仕様を何度も確かめる。ここは前に間違った順番を教えられて大いにはまったところである。

　結局、その日は解決できなかった。次の日、冷静になって考える。今まで動いていたのだから、EEPROMの関数にしろ、ハードにしろ、いくらEEPROMのダンプがおかしいと言って、この辺がおかしくなることはあり得ない。やはり新しく作ったロジックが間違っているとみるのが順当だ。

　気分を改めて最初からソースリストを見直す。あああ、行をまたがるif文のカッコのあとに；（セミコロン）がついている。何と言うお馬鹿なミス。これを直してやっとSDカードの情報が複数入るようになったが、相変わらず頭出しが出来ない。これも冷静に見直していくうち不備が見つかった。曲を選んでいるときの配列位置の変数の取り扱いがおかしい。該当のSDカードのところに保存されていない。昨夜は頭に血が昇って見つからなかった不具合がものの30分もしないうちに解決してしまった。

　一度書いた手紙はすぐに出さずに一日置けと良く言われるが、デバッグも同じらしい。EEPROMが頭から書かれているのも、コンパイラーは必ずしも定義順にメモリを割り当てるのでなく、大きい順に割り当てていることがわかる。1バイトのカード情報の変数は一番最後に割り当てられていた。前にやったようにアセンブラー的に#defineでアドレスを決め打ちしていかないとEEPROMの思ったところに変数は置いてくれないようだ。

　これでSDカードプレーヤーはより実用的になった。どのSDカードもファイルをいじらない限り、5枚まで（数はいくらでも増やせる）頭出しを覚えていてくれるようになり、選曲が楽になった。ついでに16Mhzのクロックと20Mhzクロックのときの消費電流を測る。待機時で20Mhzのとき19mA、16Mhzのときは18mAで、再生時もそれぞれ56.5mA、55.5ｍAと殆ど変らない。何だ、これくらいの差だったら、少しオーバークロックだけれど20Mhzで動かしておこう。

ここにV2.1として5枚までのSDカードの頭出し情報を記憶しているバージョンのソースコードを置きます。クロックは20Mhzに戻しました。例によってプロジェクト名は前のバージョンと同じSDPLAY328ですのでご注意ください。

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