前振り(ながい)
昨年8月まで設計は 74595 を 3 つにして、 CPU PHI2, CPU ROMSEL といった制御線は GPIO で制御していたが、 flash programming の性能がよくない(具体的にはソースが複雑になりすぎる上に遅い)ので制御線も 74595 を 1つ追加して DMA で動かすことにした.
ROM dump では address が increment, data 出力は不要. この場合は動かす address 16 bit で 74595 は 2 個ですむため追加した制御線の DMA を利用するかは条件を設定して切り替えるようにした. 一方 flash programming は制御線を DMA で激しく替える. ROM dump で制御線もいれて動かすこともできるが処理速度は半分になる.
複数の似た処理の統合
このため制御線の DMA を利用するか否かはソースでは処理の途中で新旧の実装でかなり分岐していて、最後にハードウェアを動かすところで1つになる. 途中の分岐は無駄が多いのでできるだけ減らすのが今回の目的.
ハードウェアに近いレイヤの統合は予想外に早く終わったのでその上位のレイヤの統合をし始めた. こちらは難易度が高く、統合ができていない. 統合の処理は使い回す関数をコピーして flash programming のコードは一旦削除して、簡単に構造に戻している.
転送の限界調査
ハードウェアに近いレイヤの統合の時点で ADC の Sampling Freq を可変値にすることができた. 音質は重要ではなく sampling freq を上げていって、どの速さまで限界を知りたい. できれば ROM dump の DMA が動いているときに USB の転送も ROM dump より早く動いてくれているとわかればもっと早くできるし、DMA を頻繁に止める処理もいらなくなる.
sampling freq は前回は定数 16 kHz だったので、20 kHz, 30 kHz と上げていったが 21 kHz で止まった. 一番長い音声が約3秒で、21 kHz の時点でデータ量が約 65,000 bytes になっていた. 止まった理由は一度に転送できるデータを 16 bit に指定していてそれを超える量を想定した設計になってない. つまりプロトコルの再設計が必要.
