3号機のソフト改善とSTM32Primer2の改修

ジッターを実測する（1/10/10)
　SDカードを使ったリニアPCMプレーヤー3号機のソフトの改善は、演奏中の経過表示に成功して一段落した。 ハードの方は、2回目の基板を発注したOlimexから、fax  receivedのメールを受け取ってもう1週間近くなるが、まだ出荷の知らせはない。正月明けなので遅れているのだろうか。

　当面やることがなくなったので、このあいだ入手したSTM32Primer2でもテストしてみようかと考えていた時、ふと思いついたことがある。リニアPCMプレーヤーのジッターの問題である。CPUのクロックのジッターより小さいということで、無視できるとしたが、やはり気にかかる。本当に無視できる遅れなのか実測することが出来ないか。

　DACの割込み用タイマーは、比較一致が起きて割込みルーチンに制御が渡ったとき、既に次のカウントがスタートしている。このカウンターの値は取得可能だ。DACのLRCKをトグルして、データを送り出した直後に、この値をどこかに記録して調べればよい。

　問題は、膨大なデータが出てくるので、それをどうするかである。データの殆どは同じ値で割込みが重複した時だけ1～2クロック遅れた数になるはずだ。こういう変動なら、直前のデータを残しておき、前と違ったらカウントしていってその合計を1/2すれば変動したおおよその回数が求められる。うまくいきそうだ。

　思いついたらやらずにおれない性格である。早速、AVRstudioを立ち上げ、コードを入れてみた。値は、演奏を中断した時にLCDに出す。これが驚いたことに、予想よりはるかに大きな値があらわれた。10秒の演奏で数千回という数字だ。Tick割込みは1秒、3300回なので10回に1回は割り込みが被っている勘定になる。ええー、そんな馬鹿な。これはおかしい、そんなに多いはずがない。念のため、Tick割込みのない前のバージョンV3に戻って同じコードを入れて測ってみた。

　うひゃあ、同じ数字だ。何だ、何だ。これはどういうことだ。AVRのタイマーリソースはシステムクロックである。全く同じクロックで動いているのに、割込みのタイミングで既に1クロック以上のずれがある。わけがわからなくなってきた。割込みルーチンに条件分岐があるとは思えない。一体これはどういうことなんだろう。

　タイマーの値は、36と37であることがわかったので、今度は、これ以上の遅れのときだけ測ってみた。すると、さすがにTick割込みのないV3では、どれだけ長時間測っても、数回にとどまった。測った時間に比例しないので、これは恐らくスタートと中断の時のカウンターのずれだろう。

　いよいよ、Tick割込みを入れて経過時間を表示するバージョン4の測定だ。38以上のときのみカウントする。おお、数字がでてきた。秒をセクターから計算して正確な値を出す。メディアを替えて、数十回測る。平均では、1秒に20回から25回起きている。この数字は、DAC周波数(88.1khz)を、Tick割込みの周波数（300μsなので3.3khz)で割った数字、26.7に極めて近い。

　素晴らしい。このあいだの計算が合っていた。１秒間に8万8千回起きている割り込みの中での20数回は極めて小さい数字だ。やっぱり、UIは0.0004ではなくこれより2桁ほど小さい値になっていることが確かめられた。

ロジックアナライザーで確かめる(1/11/10)
　100ns(2ステップ）以上遅れるサンプリングの回数はわかったが、それがどれくらいの遅れになっているのかはわからない。ロジックアナライザーならサンプリング周波数を高くすれば、実際の眼で確かめられるが、膨大なサンプルから、ジッターのところを探し当てるのは不可能に近い。

　しかし、このジッター実測のカウントするところでI/Oポートを叩けば、目印になって見つけやすい。勢いに乗ってこれも実験してみた。ロジアナのサンプリング周波数を20Mhz以上にすれば分解能は50nsになるので1クロックの差が見える。

　測定の結果、遅れは予想通り、2クロック遅れが最大でそれ以上の遅れは出ていないことがわかった。そしてDAC割込みの遅れは31～35ms間隔で発生していることがわかった。良かった。頻度から言えば、3000サンプルに1回である。ソフトで実測した値とピッタリ一致する（理論値の1/2だが）。UIは、遅れを100nsとして平均では0.000003である。殆ど無視できる値だ。満足、満足である。

Tick割込みの影響を0にする方法があった(1/12/10)
　ところが、これまでの話を一挙にくつがえす有力な情報が入った。 いつも的確な助言をしてくれて、お世話になっているkugaさんからの前回記事への久しぶりのコメントである。

　コメントにもあるように、コンペアマッチのタイマーには、比較値と一致すると割り込みが起きるだけでなく、出力ポートを叩いてくれる機能があるが、これにトグルする機能もあるというのだ。PWMなどの制御に使うものらしい。0とか1にするというのは知っていたがトグルする機能があるとは知らなかった。

　えー、本当？あわててデータシートを見る。ちゃんと書いてある。いやあ知らなかったなあ。トグルできるのなら、これまでのジッターの検討もへったくれもない。これをLRCKに使えば、この動作はハードで動くのだから、Tick割込みの遅れの影響は仕様上ゼロになる。

　いやいや、知らないと言うことは恐ろしいことである。一気に解決してしまった。しかし、これを実現するためには、これまでのピンアサインを変える必要がある。恐る恐るソースコードを調べる。DAC割り込みに使っているタイマーは、TIMER2で、このコンペアマッチの出力ポートは、あー駄目だ。SDカードのSPIに使っている。

　いや、待てよ。TIMER0のトグル出力ポートOCA0はPD6 というロジアナのプローブに使っている空きポートだ。TIMER0は、現在SDカードや、タクトスイッチの監視に使っている。こいつをそっくりTIMER2(DAC割込み）ととりかえてしまえば良い。良かった。大幅な変更をしなくて済む。すっかりスワップしてしまえば、このポートは、今のLRCKの隣のピンだ。今発注している新基板の変更もジャンパー一本ですむ。

　それにしても、kugaさんの的確なコメントはとても有難い。いつも難関を切り開いてくれる。44.1khzサンプリングが可能になったのも、彼がもうひとつのSPIを教えてくれたおかげだし、ポートを出力にしていてADコンバーターの入力インピーダンスが低いと騒いでいた時も誤りを指摘していただいた。kugaさんには足を向けて寝られない。お住まいはどこなのだろうか。

改修したが、確かめられない(1/14/10)
　TIMER0とTIMER2をそっくり交換する改修にとりかかる。ハードの変更は、ブレッドボードならLRCKを隣のピンにうつすだけ。実にあっけない。

　ファームを書き込み、テストする。出た。あれ、連続演奏が効かない。これはタイマーの時間が変ってしまったせいに違いない。データシートを確かめる。うわあ、TIMER0とTIMER2ではPWMのついた同じ8ビットタイマーだけれど微妙に違う。

　プリスケールの定義が違っていた。TIMER0の1/1024のプリスケール設定は、TCCR0Bレジスタの0x05だが、TIMER2は、同じレジスタ(TCCR2B)の0x07だ。時間が1/8になっている。これでは同時押しが利かないわけだ。

　これを直して、プレーヤーはすっかり元に戻った。音は？　いやこの違いは全くわからない。仕様上はTick割込みを使わないバージョンよりさらにジッターは少なくなっているはずである。これを確かめる？　残念ながら、これを確かめるためには大掛かりな測定器が必要だ。とてもそんなことはやっていられない。

　少し残念なのは、 2回目の基板が、出来上がる前から、ジャンパーが必要なことがわかってしまったということだけれど、背に腹は代えられない。殆ど音には効いて来ないと思うけれど、少なくともジッターの心配をしないで済む。

　ただ、気をつけなければいけないのはソフトの管理だ。これまでのように気楽にソフトのバージョンアップは出来なくなる。それに名前の付け方も難しい。すでに3号機と言っているソフトのバージョンはV4になっている。ソフトの内部では4.1としたがAVRstudioのフォルダーは分かりやすいようにV5にしてしまった。いずれ何とかしなければ自分でも間違えそうだ。　

STM32Primer2のコンデンサーを替える(1/15/10)
　プレーヤーの改善が一段落したので、懸案のSTM32Primer2の改修工作に入った。ねむいさんのブログなどで話題になっていた、STM32Primer2の電源周りの不具合の対策である。ブログなどによると、USBからの通電で、レギュレーターに定格を越える突入電圧がかかり、レギュレーターが焼損するという不具合である。

　製造元(Raisonance)では、レギュレーターの配線を太いのに替えて対策したということだが、対策済みの機器でも発生し、究極の解決策は、レギュレーター周りのコンデンサーをタンタルから積層セラミックに取り替えることだという。

　これにそなえて、既に積層セラミックのチップコンデンサーは、秋月で入手済みである。
本家のサイトでマニュアルなどを落とす。ここは回路図から、外形図まで全部ダウンロードできる。親切だ。交換対象のC23とC56の場所はすぐわかった。

　久しぶりのハンダ付けである。まず既存のコンデンサーを取り外す。慎重を期すため、例のサンハヤトの実装部品取り外しの特殊ハンダを使う。簡単にとれた。表と裏の部品を外し、秋月で売っている、10μFのチップコンデンサーを付け直す。

　無事2つとも交換。電源を入れ直す。気のせいか少し画面が明るくなったような気がする（そんなことはないか）。

　いずれにしても、先人が数々の実験の成果をウェブに上げてくれていることで、万全の対策がとれる。有難いことだ。これがなければ、こちらもレギュレーター焼損で泣いているところである。この場を借りて先人のみなさんにお礼を申し上げておかねばなるまい。

少しSTM32Primer2と遊んでみた(1/16/10)
　レギュレーターの不安が解消されたので、少しPrimer2を触ってみた。キットについていた小さなCD-ROMでドライバーをインストールする。これがうまくいかない。第一、最初のWelcome画面が消えない(日本版のWindowsではタスクマネージャーで止めるしかない）。

　こういうときも、ウェブが頼みだ。検索する。あった、あった。ここや、ここから沢山情報が手に入る。なんだ。そのままでは違うフォルダーに行ってしまって正しいINFファイルがあたらないようだ。WinXP用のフォルダーまで降りてインストールする。無事、ドライバーはインストールされた。

　あんまり沢山の開発環境を入れたくないのだが、OSをバージョンアップするのは、この環境が必要だということで、指定のARMtoolをウェブから落とした最新版でインストールした。XPでは不安定ということだったが、何事もなく開発環境Ride7が動いた。Eclipse風の盛り沢山なIDEだ。

　順調に、OSも最新の3.8に上げる。アプリケーションも一緒に入れる。10個以上のゲームやユーティリティが入った。興に任せて少しづつ動かしてみる。五目ならべやマンデルブロー図など盛りだくさんのアプリケーションがある。

　暫く、遊んでみた。苦心して開発した人に申し訳ないが、所詮は128×160の液晶画面だ。どうあがいてみても玩具の域を超えることは難しい。自分が開発していないでこういうことを言うのも失礼だが、どうもむなしい。わくわくする感動がない。

　昔から、モバイルには余り興味がなかった。GPSや通信、音楽プレーヤーなどならわかるが、携帯の小さな画面でチマチマとゲームをやったり、苦労して小さな文字を入力するのが何が面白いのか理解できない。実際の何かの役に立つならともかく、野外に出て、何もわざわざ小さな画面でゲームをすることもないだろう。まあこれは、「システムは役に立たなければならない」という当研究所長の一方的な偏見でもあるが。

　ということで、Primer2のテストはこれくらいにする。ここでも、これを何に使うか具体的に決まっていないという問題が一番大きい。一体何に使えるのだろう。