DIV5142の統合コントローラ(PICO)を検討する！の巻き　2024.8.29

懸案は色々あれど
自作オーディオでの懸案事項というか、やり残しているものとか、途中でほっぽり出しているものとか、
数えだしたらキリがありませんが、その中の１つがDIV5142の統合コントローラです。

DIV5142自体は4WAYまで対応可能なディジタルチャンネルデバイダーになりますが、遮断特性は最大で-48dB/octです。
これでも十分だとはおもうのですが、さらに突き詰めると、さらに高次のフィルターが必要なことがわかっています。
そこで、PCM5142を２個シリーズでつかうことで、高次まで実現した２WAY用のチャンデバも作りました。

しかし、自身のシステムは３WAY＋サブウーハの構成でもあるので、そのままでは使えません。
使えるようにするにはDIV5142を複数枚つかってのシステムになります。まあ、それぞれを個別に
セッテングするようにすればいいのですが、ちょっとスマートではありません。
複数枚のDIV5142を統合的にコントロールできるものが欲しいところでした。

ネックのPICの代替はあれど
しかし、現状つかっているマイコンのPICでは容量的にかなり厳しいです.。最近のPIC18F27Q43になると、
ROM容量も128kBありますから、DIV5142でつかっていたPIC18F26K20（64kB)の倍あります。
であれば、なんとかなりそうではあったのですが、表示にグラフィックディスプレーなどをつかいたいところで、
そうなるとフォントデータを積み込む必要があり、その容量がかなり大きなものになるため難しいところです。

そうした中でRP2040というコントローラをつかったPICOなるものがでてきています。ROM容量も２MBと大きく、
さらに32BitCPUということでかなりの速度も期待できます（ちなみにPIC18Fは8Bitです）。

ちょっと前にPICOをつかったコントローラの企画をスタートしかけたことがありましたが、立ち消えに
なってしまいました。


３年ほどまえにここまで組み立てましたが、立ち消えになってしまいました。

今回はそのリベンジです。
仕切り直しということで、コントローラ基板も一新です。


こちらの基板をつかって統合ソフトの検討開始です。

リベンジで準備！
まずは、H/Wの準備です。統合コントローラについてはこの手半田での基板を使います。
一応320x240のグラフィックもつかえます。グラフィックより文字が沢山表示する目的でつかいます。
DIV5142には２個だけPCM5142を搭載した基板をつかいます。基板上のPICは使いませんから、
部品はかなり省いています。


まずはDIV5142と接続できる形で構成してみました。

いや〜、完全に忘れているなあ〜

プログラムは以前に作成したものをベースにしてと思いましたが、プログラムソースをみても
なにをやっているのか、サッパリわかりません（笑。過去のホームページの記事と付き合わせながら
読み進めてはいますが、なんのこっちゃ〜てな感じです。
やりたいことの概略はホームページにも記載していますが、そこから実際のプログラムに落とすまでの
過程がごっそり抜けています。これが、仕事ならちゃんとしたプログラムの仕様書やらフローチャート等を
記録として残すのでしょうが、そんな面倒なことはやってないですからね〜。

ちなみに、４WAY版のDIV5142を最初に検討し始めたのが今から７年前。７年もたてば忘れているよね？
と自身を慰められそうですが、２WAY版の改良を検討したのが、今からたかだか４年前です。４年前くらいなら
覚えていそうなものですが、自身の中では１０年くらい前のイメージになってしまっています。
ほんと、短期記憶が衰えたなあ〜（笑。

ということで、本当に最初から開発を進めるようなイメージになっちゃいそうです。

リンクも切れているなあ〜　2024.8.30

BIQUADフィルターの設計を解説しているページにリンクを張っていましたが、
再度見直そうと思ったら、リンクが切れていまし（下記）。
http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt

そりゃ、今更http://で始まるページなんてないですからね〜。
ということで、再度探しておきました。
AudioEqCookBook.txt
です。今度はリンクでなく、ファイルで保存です。
これでリンク切れはないでしょうが、このHPはいつまで維持できるだろう？

ついでにフィルタに関する備忘録

多段のフィルターを設計するときに必要になるのが、各段のQ値です。
このQ値の計算方法って、ネットで探してもなかなか出てこないのですが、
プログラムを見直して、一応メモをしておきましょう。

バターワースの場合
　　　　　　　　　　　　１
　Qn＝　−−−−−−−−−−−−
　　　　　　2 x cos(((2*n - 1)/4m) x PAI

ここでｍはBIQUADの段数で、ｎ=1..m　です。
BIQUADは１段あたり-12dB/octになるので、２段だと-24dB/octの特性になります.,
一応計算しておくとm=2なので
　Q1=0.54119
　Q2=1.30656
となります.,Q1xQ2=0.707ですね。

一応１８段まで計算しておきました。


これって、PICのときはROM容量が小さかったので、都度計算していましたが、
PICOだと容量は気にする必要はなさそうなので、テーブルで持っておいても良さそうです。
倍精度（8byte)だとしても、2.6kB程度の容量です。

Linkwitz-Rielyの場合
　こちらはQ=0.5で位相特性が優れていると言われるものです。
計算は偶数段のみになりますが、Qn'をバターワース自での計算結果だとすると

２段の場合　Q1＝Q２＝Q1’
４段の場合　Q1＝Q3＝Q1’、Q2＝Q4＝Q2’
６段の場合　Q1＝Q4＝Q1’、Q2＝Q５＝Q2’、Q３＝Q６＝Q３’

というようになります。すなわち半分の段数で計算したバターワースでのQ値の並びを
２度繰り替えす形になります。こうすればQ値は０.5になります。
バターワースの場合はQ値を乗算していくと０.707になりますから、0.707^2=0.5ですからね。
（間違っていたら指摘ください）

このLinkwitz-Rielyについても、テーブルで持たせたほうがいいかもです。
またテーブルはわざわざ12dB/OCT毎にしなくとも、24dB/Oct毎でもいいかもです。

PCM5142の連結は2個か３個か、あるいは４個か？

今回はPCM5142のDAC機能は使わない予定です。すなわち音は出ません。
単なるDSPとしてのみ使います。そのため、音を出すには外付けのDACを使います。
なぜかというと、DAC機能をつかうと、そこにかなりのリソースが消費してしまい、
フィルタの段数が持つことができません。ちなみにDACを使うとなると、192KHzでの
再生ではフィルターの段数は最大７段までです。しかし、ＤＡＣを使わないと、最大で
１２段まで使えます。
　１２段まで使えると、減衰量は12*12=144dB/OCTまで稼げます。
必要な減衰量としては200dB/oct程度は欲しいので、できれば１８段(216dB/Oct)は
欲しいところです。となると、PCM5142を３個連結してトータル36段として、
HPFに１８段、LPFに１８段を分配してやればいいことになります。
　ただ、DIV5142基板自体はPCM5142を最大で４個搭載できるので、全部使っても
いいかな〜。そうすれば、トータルで48段になってHPFに２４段、LPFに２４段分けられ
ます.このときの減衰量は288dB/Octになります。
　しかし216dB/octと288dB/octの違いってわかるのだろうか？

まあ、PCM5142を何個つかうかは、もっと後で考えましょう。
まずは、ちゃんとPICOで動かせるようになることが先決です。


12個のBIQUADフィルターを並べた場合です。


これでもサイクル数は255で、256未満なので192kHzで動作可能です。

だいぶ思い出してきました　2024.8.31

１２段のBIQUADを並べたフィルターを構成して、フィルターの遮断周波数テーブルを変えて
みたのだけど、なぜかうまく動きません。で、過去のプログラムを見直して、テーブル変更した
後に、それを有効にする（ＤＳＰに受け渡す）ためのスイッチ動作が必要なことを忘れていました。
で、スイッチをかけると、無事に設定した定数でフィルターが動くようになりました。
いや〜、ほんとに色々と忘れています。でも、だいぶ思い出してきました。

試運転は１２段ＢＩＱＵＡＤでのfc=1kHzでのLPFとHPFの特性です。
１２段ですから遮断特性は144dB/octです。1kHzから200Hz離れると
ほとんど減衰してしまうことがわかります。

HPF出力 f=800Hz (fc=1000Hz) LPF出力
HPF出力 f=900Hz (fc=1000Hz) LPF出力
HPF出力 f=1000Hz (fc=1000Hz) ちょうど-3dB LPF出力
HPF出力 f=1100Hz (fc=1000Hz) LPF出力
HPF出力 f=1200Hz (fc=1000Hz) LPF出力

192kHzに拘らなければ

192kHzでの再生に拘らなければ、もっとBIQUADの段数を増やすことができます。
実際として、いつも聞いているときは44.1kHzあるいは48kHzなので、それに限定させるなら
どこまで段数を増やせるか試してみましょう。

ということで、現状の１２段の倍の24段にしてみました。


BIQUADを２４段まで連結しました。

BUILD（実際の命令コードにコンパイル）してみたときのリソースは下記になりました.
フィルターの係数WORDは49%なので、まだまだ余裕はあります。
肝心のCYCLESは495なので96kHzの限界と思われる512未満を満たしているので、
96kHzは再生できそうです。ただ、inst(命令コード）は97%になっているので、これが限界の
感じです。

これならば96kHzまでは動きそうです.

一応、48kHz、96kHzの入力で動くかどうか確認しましたが、問題なく動作しました。
試しに192kHzでもやってみましたが、流石にうんともすんとも言いませんでした（笑。


BIQUAD28段でも96kHzまでは問題なく動くようです。

BIQUADが24段まで連結できるなら、BPFにしても144dB/Octの減衰率で
DIV5142が１枚で4WAYまで対応できそうです。２WAYにするなら288dB/Octまで
減衰率を上げることができそうです。

サブウーハ用だと
今のシステムが３WAY＋サブウーハであることを考えて、
サブウーハ用の構成も試してみました。サブウーハなので左右を一旦ミキシングしたのちに
24段のBIQUADに接続します。
この構成でコンパイルしてみたところ、CYCLESは256になりました。96kHz（512未満のはず）
は余裕ですが、192kHz（256未満）はギリギリ無理なようです。
まあ、そこまで欲張らなくてもいいですね。

サブウーハ用の構成です。

CYCLESが256になっているので、96kHzが限界でしょう。

サブウーハは減衰率をあげないと、ボーカルなどが漏れてきてしまいます。
いまつかっているサブウーハはアナログのLPFなので、おそらく次数は１2〜24dB/oct
程度なので、どうしてもポートから漏れてきて欲しくない音もでてきます。
しかし、288dB/octまで減衰率を上げられるなら、重低音のみの再生が可能でしょう。


タイムアライメントはどうする？　2024.9.1

DIV5142の検討においては、タイムアライメントに関するリクエストも出ていました。
過去の取り組みはほぼ忘れているので、今回、もう一度思い出しと確認をしてみました。


どのくらいの調整幅が必要？

「タイムアライメント」でWEBを調べてみると、でてくる記事はほとんどがカーオーディオに関する物でした。
そりゃあ〜、カーオーディオの場合は左右前後のスピーカから運転者までの距離ってバラバラだし、それを
補正するのは効果があるでしょうね。それに、運転者の位置ってほぼ固定されていますから、シビアな調整
もできるでしょう。車の場合だったら、およそ2m程度の範囲で調整できれば良い感じでしょう。となると、
音速から計算して6ms程度の調整範囲が必要でしょう。

ホームオーディオの場合で、BBSの書き込みにもあるように長大なホーンを使われている方は、
ドライバーがかなり後方に設置されますから1m程度の範囲での調整が必要なようです。
またホーンによってはC型で曲げておられる方もいるでしょうから、その場合は２ｍ程度は必要なのでしょうか。

ホームオーディオの中でもいわゆる普通のスピーカだと、たとえばツイータとウーハとの距離がズレているので
それを合したいという要求があるかもしれません。そういえば大昔にスピーカの位置をずらしたものがありました。

昔はこんなのがありました。引用：ＳＢ-８０００ (niji.or.jp)

でも、最近のスピーカってハイエンド品でもスピーカが平面に配置されているだけで、あまりそのあたりは気に
なっていないような気もします。なんせ試聴位置がばらつきますから、アライメント調整なんてほとんど意味がないのでしょう。
まあ、調整できるとして0〜20cmも弄れればいいのかもしれません。となると時間としては20cmとして約0.6msです。

PurePathStudioでのディレイ機能は

Basic DSPの項目にはDelayなる素子がありますので、これを使うとデータの時間を遅らせることができるようです。
まずはこの素子を１個だけつかって、どのような挙動をするかを調べてみました。

使えそうな素子はDelayです。


まずはDelayを１個だけL側に入れてR側との時間のズレを観察します。

Delayの素子をクリックすると、そのパラメータがでてきます。なかに
Delay1,Delay2,Delay3の３つのパラメータがありますが、関係するのは
Delay1だけのようです。これは、実際にコンパイルしたときのコードを
比較したところ、.Delay1を変更したときにのみ生成コードが変化したことから
わかりました。


Delay素子の設定パラ―メタはDelay1のみが有効のようです。

Delayで分かったととは
　色々と調べて分かったことを列挙すると以下の通りです。
　1.関係するパラメータはDelay1で調整範囲は１〜１６
　２.遅延量は設定値ｘＬＲクロック
　　　すなわち48kHzの場合だと設定値１で20.8us
　３.遅延量を16に設定すると、データメモリーは3.71%消費する。
　４.生成されたコードと設定遅延量との明確な対応不明
　　→単純にコードを弄って遅延量を設定することが現状困難。
　　　　もっと調査が必要。

最大遅延量は？
　上記の結果から、遅延量はLRクロック幅単位になりますから、
48kHzの場合で20.8us(7mm)、96kHzで10.4us(3.5mm)、192kHzで
5.2us（1.8mm）になります。
　ちなみに、カーオーディオでのタイムアライメントの調整方法のページをみていて
調整単位が0.35cmになっていて、中途半端な値だなあ〜と思っていましたが、
この機種ではちょうと96kHzでの動作なんですね。

調整単位が0.35cmということはFs=96kHz動作のようです。

さて、話を戻して最大遅延量ですが、これはデータメモリーの制約をうけることになりそうです。
遅延量１６の場合のデータメモリーの消費量が3.71%ですから、遅延量は最大でも430程度が限界です。
それも片チャンネルの場合ですから、ステレオ仕様だとその半分の215になってしまいます。
これを、距離に換算すると
　48kHzの場合は1.5m　(4.5ms)
　96kHzの場合は0.76m　(2.2ms)
　192kHzの場合は0.38m　(1.1ms)
となります。ホーンをつかっている場合などでは96kHzであればギリギリ使える範囲かな〜といったところです。
ただ、これは理想的な値なので実際にコードが実現てきるかどうかは不明です。
遅延量２１５を実現するには遅延量１６の素子を13.4個並べる必要があります。
そこで、片チャンネル１３個の遅延量１６の素子を並べてコンパイルできるか試してみましょう。

まずは１３素子を連結
問題なくコンパイル（ビルド）出来ました.
データメモリーの使用率が86.7%なのでまだ余裕ありそうです。

まずはDELAYを13素子を連結です。


DELAY１３素子の連結でのデータメモリ使用料は86.7％とまだ余裕あります。

１４素子はどうかな？
これもいけそうです。ギリギリもう１個は足せるかな？

１４素子で試してみました。


１４素子だとデータメモリーは93.36％なので、もう１個はいけるかな？

１５個はどうだ！
を！データメモリー使用量１００％でコンパイルできました。

DELAY（遅延量は最大の16）を１５個連結です


データメモリーの使用量はジャスト１００％になりました。

最大遅延量を更新
　１５個まで連結できるとなると、遅延量は最大で240になります。となると、
距離に換算すると、すこし長くなりそうです。
　48kHzの場合は1.7m　(5.0ms)
　96kHzの場合は0.85m　(2.5ms)
　192kHzの場合は0.42m　(1.2ms)

もっとも、もっと遅延量を多くしようとすればPCM5142を必要な数だけ連結すれば
いいだけですけれどね。
それと、あることに気付きました。命令サイクルが127となっているので、
おそらく384kHzでも対応可能です。単純にPCM5142をタイムアライメント素子
（ただし遅延量が小さいのでホーン用ではありませんが）としても使えそうです。

さて、ここからが難問です
遅延量が予めわかっていれば、その設定値でモデルを組んでコンパイルすれば済みますが、
任意の遅延量にする方法がまだ不明です。命令コードが解析できればいいのですが。
力づくでやるなら、遅延量で２４０パターンのすべての命令コードを作成することになります。
おそらく丸一日ぶっ通しで作業すれば、なんとかなりそうだけど・・・体力と集中力がもちそう
にないなあ〜。

あれ？割と分かりやすかった！　2024.9.4

＃ほとんど自分への備忘録です。

遅延量の設定はパラメータの係数変更で行うのなく、命令コード自体の変更
で行います。そこで、遅延量を変更したときの命令コードの違う部分だけを
ピックアップして、どのように変わっているかを調べてみました。色々とやって
わかったことを列挙すると、意外とシンプルでした。

必要なモデルとして遅延量設定値１６のDELAYを複数連結して、一番最後に
パラメータを変更したDELAYを接続です。
たとえば下記のようにDELAYを９段接続した場合、最初の１〜８段は設定値１６（最大値）で固定。
９段目のみ設定値を変えます。たとえば遅延量130（時間は2.7ms@48kHz)とする場合は
１〜８段目が１６、９段目が２というようになります（16ｘ８＋２＝130）。

段数の違うモデルを用意しておいて、最後の段だけパラメータを変更。

そこで、最後の段の設定値を変更したときの命令コード（１６ビットの様子）の差を観察すると、
設定値の差が命令コードに現れていることがわかりました。変化する命令コードの個数は
用いるＤＥＬＡＹ素子数に対応しています。


DELAYを９段接続　１〜８段は遅延量16(最大）で
９段目を遅延量１と遅延量２としたときの差。
ちょうど差１の命令コードが18個並んでいます。
最後に差の２倍の値が1個書かれています。


DELAYを９段接続　１〜８段は遅延量16(最大）で
９段目を遅延量１６と遅延量１としたときの差。
ちょうど差１5の命令コードが18個並んでいます。
最後に差の２倍の値が1個書かれています。

ここまで、わかればプログラムの作成が可能です。
まずは、ＤＥＬＡＹ素子を０〜１５段接続した１６個のモデルを作成しておいて、
基本の命令コードを生成です。そして、最後の段だけパラメータを変更した
モデルとの命令コードの変化アドレスを把握してテーブルにしておきます。

ということで、遅延量の設定ルーチンは下記のようになります。
　0.　PCM5142をスタンバイモードに設定（命令を書き込むため）
　1. 遅延量（０〜２４０）に応じたモデル(*1)の命令コードをPCM5142に書き込み。
　　(*)DELAYの最終段のみ設定値１。
　2.．遅延量から最終段の遅延量を算出
　　　たとえば遅延量130なら最終段は２　(130=16x8+2)。
　3.　最終段の設定値を演算して書き込み（変更箇所のみ）。
　4.　PCM5142のスタンバイモード解除（実行開始）

無事タイムアライメント機能が入りました
なんとかプログラムが出来上がりました。ということで、実験です。発振器の出力をオシロのch1に表示し、
もう一つは発振器の出力をAD変換してPCM信号に変更したのち、PCM5142(タイムアライメント）
に入れて、その出力をSRC(RenewSRC4137)経由でDAC（ＡＫ４４９７）に接続です。AD変換は
96kHzですが、SRCで48kHzに変更しています。

　発振器
　正弦波
　　　−−−−−−−−−−−−−−−−−−−−オシロｃｈ１（基準側）
　　　｜ー−AD変換−SRC−PCM5142ーDAC−−−オシロｃｈ２（遅延側）　　　　　　　　　

設定値０ （遅延なし）		遅延設定量０ですが再生波形はADC,SRC、DACを 経由しているので約1.79msの遅れがあります。
設定値80 1.66ms		3.45-1.79=1.66ms
設定値160 3.33ms		5.12-1.79＝3.33ms
設定値240（最大値） 5.0ms		6.79-1.79=5.0ms

ちょっと難点といえば、パラメータを切り替えるときにPCM5142をスタンバイモードにする必要があるので、
データの書き込みの間（数ms)は音が切れてしまいます。調整のときは、プチという音がでてしまいますが、
まあ仕方がないところでしょうか。

＃夜遅くまでやり過ぎました。明日（本日）から出張なので寝よ〜。

書き込み速度の向上はできるかな？　2024.9.7

タイムアライメントの調整をするためのデータ書き換えのためにI2C通信は結構量があります。
とくに、次数が高くなる（遅延時間が大きくなる）と通信量が比例して大きくなります。
現状だと、最大で数10msくらいかかってしまう場合もありそうです。そのため.
できるだけ、書き込み時間を短くしたいところです。

対策としては、下記の2点です。
　１.I2C通信速度を上げる
　　　現在はすべてソフトでI2C通信を行っていますが、冗長なところが多いので、もっと
　　切り詰めると数１０％は短縮できそうです。

　２.通信量を減らす
　　　データの書き込みについてはインクリメント機能が使えます。これをもっと活用すれば
　　データの通信量自体が減るかもしれません。ソフト的には結構面倒ですが---。

１（通信速度向上）については、I2C通信を行うすべてに当てはまるので、いずれ取り組まなければ
いけませんが、まずは２(通信量減）ができるか検討です。先に書いたように遅延量が大きくなると
通信量が増えますので、DELAY素子が１５段になった場合を考えます。

(*1)１バイト書き込む毎にデバイスアドレス、レジスターNo、データの３バイト送信が必要。
(*2)書き込みレジスタアドレスが連続していないので、インクリメント機能の効果は限定的

インクリメント機能をつかえば命令コード全体を書き換える時間は1/3と大幅に低減しますが、
これってDELAY段数が変わったときにしか使わないので、出番が少ないです。出番が多いのは
変化分を書き込む場合ですが、この場合は約７０％になる程度です。ちょっと少ないなあ〜。
でも、I2Cの書き込み速度の向上と合わせると全体で倍程度の速度向上にはなるかもしれません。

まずはI2C速度の向上を検討

I2Cの通信速度でのクロック速度は公称400kHzですが、限界をみるとSCLのLOW区間が1.3usで、High区間が600ns
ですから、トータルで1.9usになりますから約530kHzになります。公称の400kHzより仕様的にはすこし速くできそうです。

I2C通信が400kHzのときのタイミング

現状ではI2Cルーチンには至るところに1usのディレイを入れています。
なぜ1usかといえば、それがＣ言語でのＤＥＬＡＹルーチンの最小単位だからです。
ということで、繰り返しのクロック部分だけを抜き出して、現状ではどんなタイミングになっているか調べてみました。


現在のＳＣＬの速度です。結構のんびりしていますが、こんなもの？

ＨＩＧＨ期間が1usになっていますが、これは600nsまで短縮可能（余裕をみると700ns程度）。
LOW区間は2usになっていますが、これも1.3uSまで短縮可能（余裕をみると1.5us程度）

現状はサイクルは3usになっています。ギリギリ1.9usまで短縮できますが、すこし余裕を
みると2.2uS程度でしょうか。となると73％に短縮できそうです。これを大きいとみるか
小さいとみるか？

いずれにしてもDELAYルーチンは1usではなくて、700nsに変更したほうがいいでしょう。

とりあえずスペック内で速く　2024.9.8

I2CのDELAY関数を適当につくって試してみました。
I2Cの動作テストについては、400kHzで動作するOLEDをつかっています。
で、DELAY関数の変更で描画が速くなりました。

SCLのクロック速度を上げてみました。


I2Cの動作テストは400kHz動作のOLEDをつかってみました。
DELAY関数変更で速くなりました。

ついでなので、DELAY関数での遅延時間をどんどん短くしていきましたが、
かなり短くても動作するようです。SCLのHIGHクロック幅が約160ns、
SCLのLOWクロック幅が420nsでも大丈夫そうです。
SCLのクロック周波数にすると約1.3MHzくらいでしょうか。
ここまで短くすると、相当に描画速度が大きくなった感じがします。

ここまで短くしても動作しました。

ひょっとしてPCM5142でもこのくらいの速度でも動けるかもしれません。
まあ、仕上がってからどこまで速く動けるかは試せばいいでしょう。
とりあえずは、無理せず仕様範囲で動かしましょう。

ソフトはなんとでもなりそうなので、すこし置いておいて

使い方のバリエーションは？

どういう使い方を考えるか、ちょっと整理です。これで基板設計をどうするかが
見えてきます。

１.　１枚のみ使う方法
ａ．４ＷＡＹ用
　これは現状のDIV5142と同じ使い方です。ただ、DACは使いませんから各チェンネルとも
１２素子のBIQUADがフルに使えます。BPFとする場合は最大で-72dB/octまで使えます。
LPFあるいはHPFとする場合は最大で-72あるいは144dB/Octになります。


　　　　　　　　４ＷＡＹ用の構成

ｂ．２ＷＡＹ用
　これも現状のDIV5142-2WAYと同じ使い方です。DACは使いませんから
LPF、HPFともに最大で-288dB/Octになりますので、かなり高音と低音を
スパっと分離できることができます。


　　　　　　　　２WAY用の構成

ｃ．２ＷＡＹ用タイムアライメント付
　これは現状のDIV5142基板の改造でもできそうです。
LPF、HPFともに最大で-144dB/Octになります。
タイムアライメントはＬＰあるいはＨＰのどちらでも使えますが、
ホーンの場合は普通はＬＰ（ウーハー）側に取りつけるのかな？
タイムアライメントでの調整幅は48kHzなら最大15ms、192kHzでも
3.6msまで可能です。


　　　　　　　　２WAY用（タイムアライメント付）の構成

２.　複数枚使いの場合
　これはスピーカユニット毎に１枚つかう前提です。
　たとえば４つのPCM5142をすべて連結することも考えらますが、そのときの遮断特性は
ＬＰあるいはＨＰに限定すると-576dB/Oct、BPにすると-288dB/Octになります。
そこまで次数をあげなくてもよいので、タイムアライメント機能を入れたい場合は
DELAY段を１個〜３個まで調整できるようにします。まあ、普通のトールボーイのような
スピーカだったらDELAY段は不要か、あっても１段で十分でしょう。


　　複数毎使う場合。DELAYを入れる個数によってフィルタの次数が変わってきます。

　ひょっとしてDELAYだけ４段の組み合わせもあってもいいかもしれません。
そうすれば192kHzでも7.2mまで対応可能です。384kHzでも3.6mまでいけますから、
かなりのロングホーンでも対応可能になるでしょう。でも、そんなホーンって部屋に
置こうとしたら大変ですね。

基板の配置は？

複数の基板の接続はケーブルだとごわごわしてきそうなので、段積みできるようにしましょう。
下図のように上下の基板をコネクタとピンで接続できるようにします。多段積ができるように
コネクタとピンは２列に配置できるようにしておきましょう。
このとき、基板間の間隔は約13mmになるはずですから、L型のピンをつかってI2S信号を取り出す
ことも余裕でできるでしょう.。

基板間の接続方法


基板間の間隔はおよそ13mm程度になるはずです。

基板サイズはSTDで

今回はアナログ出力はありません。一応、取り出せるようにパッドだけは設けますが、コネクタ無しです。
そのため基板は小さくても大丈夫でしょう。いわゆる標準サイズで作成です。まず、必要な部品等をざっと
配置して、空間の余裕を確認です。まず問題はなさそうです。


外側はWIDEサイズ、内側がSTDサイズです。アナログ出力がないのでSTDサイズで十分です。

回路図も書いてみました。とりあえず、部品番号は適当です（コピペしているので）。
基板のアートワークを書いていると、回路図も多少変わってきますので、まだ仮です。

回路図も書いてみました。

こんな感じ？

ざっと描いてみました。

基板名はRenew　DIV5142にしてみました。

制御基板を描いていきましょう

制御基板ってPICOからコネクタへの配線になりそうなので、不要かなあ〜とも思ってしまいましたが、
やっぱりスッキリと組み立てることを考えた場合にあったほうがいいでしょう。

PICOについては秋月のRP2040基板のどちらでも使えるようにしておくと便利でしょう。
というか、手元にもPICOや秋月のモノや、中華製の基板など色々あったりするので、どれでも使えるようにしておいた
ほうがあとあと便利そうです。
また、表示器も色々と接続できるようにしておきましょう。おそらく、標準的につかうのは20x4のLCDですが、
デバッグのときにパラメータが多数表示できるようにグラフィックパネルも取り付けられるようにしておきましょう。

仕様
対応RP2040基板
　1.Raspberry Pi PICO （RUNスイッチもとりつけられるようにしましょう）
　2.　秋月RP2040（形状がすこし異なるので取り付け注意です）
　3.　中華製（PICOとほぼピンコンパチで、安いです）
接続可能表示基板
　１.　SC2004（20ｘ4のLCD：ピン配置が2x7の14Pinのもの．５V動作）
　２.　2004LCD(20ｘ4のLCD：ピン配置がインライン16Pinのもの．５V動作）
　３.　128x64ドットOLED（21x8の文字表示が可能）
　４.　320ｘ240ドットＱＶＧＡ（カラーグラフィックも可能）
スイッチ類
　１．プッシュスイッチ　４個
　２．ＶＲ　１個
　３．エンコーダ　１個
　４．赤外線受光モジュール　１個

まあ、こんな仕様として描いていきましょう。表示器が結構大きいので基板からはみ出してしまいますが、
実際問題として基板上に実装して使うことはないと思うので大丈夫でしょう。一番小さいＯＬＥＤ（128x64ドット)
であれば、基板内に搭載可能です.

こんな感じで描いていきましょう.


こんな感じかな？　2024.9.12

全体のアートワークを描いてみました。結構、色々と配線が多いです。


こんな感じで描いてみました。

あれ？微妙に違う？　2024.9.13

Raspberry Pi PICOと秋月のRP2040ボードは形状も違うので別物とわかりますが、
中華製RP2040ボードってPICOのコピーかと思っていましたが、よく見ると若干違うようです。
ちょっと、ここで整理です。


左から Raspberry Pi PICO, 中華製RP2040ボード、秋月RP2040ボード。
秋月は短いので違いは明確です。

PICOと中華ではハッチング部分が最大の違いの様子。

おおきな違いはそれぞれのボードでGPIO２３，２４，２５，２９が有ったり、なかったりします。
それぞれのボードのどれでも使えるように考えると、これらのポートは使わない方がいいかもしれません。
でも、勿体ないなあ〜。それに、ちょとピンが足りない場合もありそうです。

とりあえずＧＰＩＯの23,24,25,29は使わないようにしましょう。
少し修正して、残りを仕上げましょう。
あ，ベタはこれからです。


すこし修正です。

こちらも回路図を書いておかないと！

久しぶりに作業再開　2024.10.20

秋旅行からかえってきて約１週間。都合３週間以上経つとほとんど忘れてしまっています（笑。
でも、旅行前には回路図も書いておいたようです。えらいなあ〜俺（爆。


一応、回路図は書いてありました。

なんかおかしい？

回路図を確認していると、おかしいところがありました。
PICOのGPIO２２が入力と出力の両方で使われいます。
接続先はエンコーダおよびLCD表示器です。となると、
どちらか一方しかつかえないことになってしまいます。
うっかりミスかな？

しかし、GPIOを分けようと思ってもピンが足りません。秋月のRP2040ボードを使う前提
なら大丈夫ですが、やっぱりPICOも使いたいしなあ〜（一杯持っているので。

ということで、すこし回路図を修正してLCDのデータ(DB4〜DB7)については
シフトレジスタを追加してシリアルーパラレル変換でデータビットを生成することにしましょう。
ソフトの負荷は増えてしまいますが、RP2040の性能的は問題ありません。そもそも、
LCDの駆動には、いたるところに待ち時間が入っています。それだけ、デバイスの応答が遅い
ということなので、少々シリアルーパラレル変換に時間がかかっても問題なしです。

回路図修正！

シフトレジスタ（IC2）を追加です。

回路図をすこし修正しました。

この回路でパターンも修正しておきましょう。


パターンを修正しました。

さて、そろそろ製作にかかるかなあ〜。

基板ができてきました。　2024.11.11

こちらはコントローラ基板


こちらはRenew DIV5142

まずはI2Cコントローラから　2024.11.14

今回作成して基板群は外部からI2Cで制御されるものが多いので、まずはI2Cコントローラから先に組み立てましょう。
基板間を接続するピンの取り付けなどは、これからです。
しかし、ここで躓くとちょっと萎えそうになります。少々のバグは許容するので、致命的なバグは無しでねえ〜！


I2Cコントローラ基板を製作中です。

動作確認中　2024.11.15

とりあえず、動作確認作業を進めます。


まずはQVGA（320ｘ240）の接続は問題なさそうです。

ソフト作成にあたり、ＧＰＩＯの割り当てを整理です。
回路図から読み取ればいいのですが、一覧表にしておけば
あとあと便利です。

I2CのGPIO振り当て

スイッチ類のGPIO振り当て

QVGAのGPIO振り当て

LCDのGPIO振り当て

やっぱり要りそう！　2024.11.16

ソフトの製作においては、やっぱりI/Oとなるターゲットボード（Renew　DIV5142）もないと難しいところがあって、
コントローラ基板のデバッグはそこそこにしておいて、作成することに。
こちらは、すべて表面実装部品なので組み立ては割と短時間で済みます。
なお、部品の高さを低くしたかったこともあり、電解コンデンサの部分はＳＭＤのタンタル(22uF/10V)をつかいました。
秋月で売っているものです。I2Sの取り出しコネクタはL型のものを使っています。
また、コントローラとの接続ピンは基板の内側に取り付けました。

Renew DIV5142が出来あがりました。動くかな？


コントローラ側にもピン（基板の左端）を取り付けました。外部接続のピンは外側に。


基板間の接続コネクタは基板の内側です。コネクタは雌タイプです。雄タイプだと、
基板を机などの上に置いたときにピンが曲がる恐れがあるので、基板裏側には
雌タイプのコネクタをつかいます。

動作確認していきましょう！　2024.11.16

とりあえずコントローラの下にRenew DIV5142を接続して、以前に組んだソフトを入れて
動作させてみましょう。

まずは連結して動作させてみましょう。

さて、まだハードウエアにバグがあるかもしれませんが、ソフト作成しながらチェックしていきましょう。
しかし、あらためてプログラムのソースを眺めてみましたが、２〜３か月経つと、ほんとうにきれいさっぱり
忘れています。こりゃあ、一からの作成になっちゃうかもです。こういった、プログラムって一気呵成で
やらないとだめですね。

バグ発見！　2024.11.18

接続チェックしていて、いきなりバグ発見です。
出力バッファーの配線を間違えていました。全然PCM信号が出ないので調べたらわかりました。
バグの原因は回路図だったなあ〜。


出力バッファーの向きを間違えていました。


回路図修正です.

パターン修正は２箇所切断、２箇所ジャンパー


黄色の２箇所がパターンの切断箇所です。水色がジャンパー箇所ですが、これはICを実装してから行うのが簡単です。


ジャンパーはIC6,7の１番ピンをVcc(3.3V)に接続です。

これで大丈夫かな？

接続テストを行いました。DELAY機能が動作するかを確認です。
DELAYの係数は0〜240で変更可能なので、１０ステップ毎に動かして入力と出力の
位相のズレを確認です。96kHzで動作させているので、１ステップがLRクロックの差ですから
240で2.5msの差になります。

＜図をクリックするとムービーが動きます＞
下が入力、上が出力。DELAY係数を２４０〜０まで１０刻みで減少させて、
それを繰り返しています。

動画で波形に水平線が入りますが、パラメータの変更時はＰＣＭ５１４２をスタンバイモードにする
必要があるため、一度動作が停まるためです。

さて、そろそろ長くなってきたので、その２に移行です。

（パート２につづく）