タイミングが怪しいデータ出力系の修正を行う。

MCUから出力されるオーディオ・データに5Vドライヴの負荷が掛かると、LCDの描画がチラつくことが判明。　原因は不明だが、厄介な感じがしている。

負荷を外すと波形の表示が綺麗になるので、DAC（故障気味）からなんらかのフィードバックが発生しているものと思われるのだが、、、。　ちなみに、ロジック・アナライザ側では何故かこの問題が観測されない。



データの出力をPCM5102Aのデータフォーマットのタイミングと比較した場合、



意図的に作ってあるLRCKとBCKのズレが少々気になるが、



これは、BCKの位相をLRCKのエッジから128fs分だけ遅らせて、データが確定するタイミングに安全マージンを持たせる意図がある。

このタイミングが許容範囲に収まるかどうかは、「食い合わせの問題」になってくる。

遅延時間のセッティングは、D-FFによって行われる同期パルスの解像度に依存している。　意図的に遅延を設定してマージンを持たせることは、DAC（受け側）に於けるBCKの扱いがデータの確定を優先した非同期方式の場合に効果がある。



逆にBCKとLRCKがガチガチに同期されている場合にはタイミングの判定がクリティカルになってくるのだが、AlesisのDACの場合はLRCKから内装されたオシレータによってBCKを生成している手前、



外に出てこないBCKの位相差が判らないために、タイミングの辻褄合わせは実測値で行うしか手段が無い。

AL1201は、BCKのダウンエッジで読み込みデータが確定するのだが、送出側の遅延時間を128fsとすると、このタイミングではアウトとなる。



FPGA側の端子が余っているので、BCKと同期させた別出力の端子を生成して、これを充てるのが正解だろう。



何れにしてもDAC側が正常に動作しているのであれば、LRCKとBCKの位相差に問題が生じない極大値・極小値の入力時に反応がある筈で、それが無いということがDACの動作不良を証明している。

その後、VHDLにLRCKの出力端子を追加しているが、



何故かWCKの逆相になっている。（ミスを修正した筈だったのに）　とはいえ、BCKと信号のエッジが一致すれば、左右のCHが逆転するだけなので、実験を行う上で支障はない。

BCKのダウンエッジと同期をとった場合、



PCM5102Aはこのタイミング。

BCKのアップエッジで同期を取った場合、



AL1201はこのタイミングだが、BCKがチップ内で生成されるので、比較を行う意味はない。

逆相出力の原因は、失敗に気付いて再インプリメンテーションまでは行ったものの、



書き込み作業そのものを忘れていたことにあった。　この件で実害は殆ど発生しないが、（L/Rなどという仕切りは観念的なものなので）朝方の寝惚ける時間帯にまたもや間抜けをやってしまった。

PCM5102Aの試験はこの体制で行うことになるが、



取り込んだデータがLRCKの半波長後のタイミングで出力されていることが判る。

追記：

CKWを14番pinに配置したところ、MSBの取り零しが乱発した。　pin配置を21番に戻して、取り零しは皆無となった。

CKWは送出側でデータのステイタスが確定した状況で”H"が出力されるのだが、FPGAの内部配線によってLATCH信号との相対的な遅延時間が「改善」された結果、先頭のデータが取り零されてしまう。　やはりFPGAのpin配置はタイミングに対してクリティカルに作用するようだ。



よく考えると、これはLATCH信号の立ち上がりとCKWとの相対的なタイミングの問題で、14番pinに信号を配置することで内部配線の遅延時間が変化して、MSBの立ち上がりにLATCHの立ち上がりが間に合わなくなり、その結果、データが取り零されるものと推測している。　

改善の方法は、IDEから指摘されるようにLATCH信号ラインの遅延を解消することが本道ではあるが、どうも物理的にそれは無理っぽく、結果的に仕方なく遅延時間を織り込んだ信号のマネージメントを行うことになっている。



回路自体は至極単純な構造の反復なので、



コンパイラが適当な判断をしてくれれば良いと思うのだがそれは叶わず、試しに構成素子の規模が4倍のデバイスを対象にインプリメンテーションを行っても結果は変わらない。　

使用する素子には外部端子が32pinという物理的な制限が認められるが「構成回路の規模により発生した制限」とも違うようで、これはデバイスと回路の相性の問題なのかもしれない。

受光素子HFBR2412の配線ミスを発見する

部品の到着を待つ空き時間に試験を行おうとadatブリッジ基盤を眺めていて重大な設計ミスを発見した。


　
この参考回路の記述が正しいのだが、プリントパターンを確認したところ、受光素子から出力される信号が逆相で接続されているようだ。　ミスの原因は、回路構成とデバイスの選択を2重に思い違えていたことで、その所為で不毛な作業を繰り返すことになってしまった。

まず、使用しているデバイスを勘違いしたのが最初のミスで、adat規格に対応できる通信速度を検討した結果、アナログレシーバーを選択していたのが、



HFBRのアプリケーションノートに記載されていた「遅い方のTTL出力のモデルを使った通信回路」を勘違して参照した結果、基盤の配線を間違えることになった。



HFBR系のデバイスは似たような型番のモデルのピン配置が2番と6番で反転するという非常に嫌らしい設計で、まずはこの罠に嵌まった形になるのだが、自らの注意不足は否めない。

次に、実際に使用しているデバイスの刻印を読み間違えるという、またしても信じられないミスを連発した結果、折角修正を行った基盤を元の間違えた状態に戻すという無駄な作業を行い、それに気付いて再修正を繰り返すという作業に2時間余が費やされることになった。

失敗の最大の原因は、プロジェクトを放置した結果の忘却にあるので、記憶が鮮明なうちに修正を行うことにした。



配線の修正箇所は、受光素子の出力・2番ピンからクオンタイザーICの入力・4番ピンにコンデンサを介して接続している部分で、修正が可能なプリントパターンだったことが幸いしている。



配線が直線的で単純なシェイプになった分、微々たるものではあるが修正前よりも信号の通りが良くなる筈だ。



実際に配線をやり直した箇所は写真中央の4x2のランドの部分で、表側と裏側の誤配線をルーターを使って切断した後、裏面から極細のワイヤーで修正を行っている。

それにしても、受光素子の出力を受けるICが「量子化器」とは物々しいネーミングだ。

実は、同じ間違いをテルミンのオーディオ基盤でもやらかしているのだが、



こちらはそもそも「DACが使えない」という笑えない話になっている。　赤が追加発注を行った修正版。

ヤバいのは、この過程を経てもなお「間違いを間違って記憶していた」ことで、中期記憶の減退を感じてしまう。

adat系ICの使用を諦める

不良品のDACからの出力をオシロで観測しているが、



これは高周波なので音として認識することができない。



CH1は44.1kHzのオーディオクロックなので、CH2のDAC出力は明らかに時間軸のスケールが変なのだが、波形それ自体は元波形の設定どおりにクリップしていたりするのが嫌らしい。

ちなみに、液晶画面で表示される波形はピッチに関係なく基本波が表示されるので、実際の周波数を知るための参考にはならない。



午後に入ってDACの出力をチェックしたが、正しい波形を描いているように見えるものの、DACが全く反応しない。　BCKとのタイミングも問題なく、ステーブルにクロックを吐いている。



試しに、ソケットのDACを入れ替えると、在庫していた５個のうち４個が無反応で、



残りの一個も変な動きをしている。　なお、無反応なチップでは、電源投入後に電圧が降下していく現象が観察される。



能書きにあった入力の3.3V対応という仕様が怪しい場合を想定して、データラインをレベルシフターによって５Vまで昇圧しても、



結果に変わりはなく、変な動きをするチップにはやはり変な動きが観測され、残りは沈黙したままと、3.3V規格で接続したときと全く同じ反応が得られた。　５V変換後のアップエッジに見られる波形のナマリ具合が怪しいが、これは電気特性がプアな配線材に生じた寄生容量の影響と思われる。

バルク品のロット毎不良品を掴まされた可能性が濃厚となる一方で、送出系の設計がVHDLを含めて失敗している可能性はゼロではなく、別のチップを用意して結果を見ることで不具合が発生している箇所の決着をつけるべきだろう。

５Vの変換が行えるようになったので、試しにadatEncoderに通電したら、いきなりチップから煙が出た。

配線を確認したが、出力が１つしかないというシンプルな端子の構造故に間違いは考えられず、



電圧も上限が5Vなので過電圧による故障も考えられない。

これもディスコン品を買っていたのだが、やはり初期不良だったようで、電源端子の抵抗値を測ると完全に短絡モードとなっていた。　製品にする場合は危険過ぎるので、この辺りの部品のチョイスについては一度考え直す必要がある。

DAC系が全滅したので、別のDACが到着するまで待機することになったが、これは頭を冷やす良い機会なのかもしれない。　　遣い易いDACは他にもあって、PCM5102Aが良さそうだ。



翌日は一日、新しく導入する予定のDACに合わせて基盤を新調していた。　



DAC周りの回路がシンプルになり、adatEncoderを搭載しない分だけ配線の取り回しを楽に行えた。　全体の集積度はあまり余り変わらない雰囲気だが、右端のエリアが空白になっている。



オーディオボードの方も新調したDACに合わせた配線を終えたが、半固定抵抗ポットのグランドをFETスイッチでオンする回路の動作確認が未了なので、この部分の試験をブレッドボードで行うことにする。

得体の知れない半導体を判定するのに便利なアイテムを使って、パーツの素性を特定した。　



SMDは端子を測定器に直接繋ぐことが出来ないので、チップを1個犠牲にして変換ボードに取り付けた。



端子の極性が判ったので、ブレッドボードに簡単な回路を組んでSource Drain 間の抵抗値を測定したところ、Gate電圧を抵抗を介して電源電圧までプルアップした状態で300kΩ以上、Gateに接続した別の抵抗を介してGate電圧をグランド電位に落とすと約230Ωと、負論理でスイッチングが行われることを確認できた。　PchのFETを使う機会は意外と少なく、自分の経験ではコンプリメンタリでアンプを組んだ時位だろうか。

実際には、Gateに接続した抵抗とCで時定数を設定して、スイッチングノイズを回避する回路を組むことになる。



予想される問題は、FETの抵抗値の変動によるノイズの発生だが、これはGateに設定する時定数次第で回避できるかもしれない。　Gate入力にC11を追加して、時定数を設けた。　諸々の抵抗値には100kΩ前後の値を配置することになるだろう。　抵抗値を測り直すと、実測値でオン時が260Ω、オフ時が1MΩオーヴァーと理屈通りの反応だった。



ノイズの影響が気になる場合はOptical系の素子を組み込めば良いので、設計時にオプションとして回路を組んでもよい。



ということで、基板にフォトカプラを追加した。　結線はバラック配線対応で、アナログスイッチ同士の直結で問題が発生しなければ、デバイスを使用しないで済む設計とした。　スイッチング・スピードが極低速なので、配線を引き回しても殆ど問題は発生しないが、このデバイスの追加は安全対策のおまけみたいなものなので、これ以上は凝ったことをする気はない。

さて、今回DACの選定を失敗したことから得た教訓は、「製作記事を見掛けないデバイスの採用は控えるべき」ということで、そういえば参考にしたAL1201の製作記事は１０年程前に日本の音響エンジニアが書いたものだったが、それ以外の記事は他言語を含めて見たことがない。　

確かにスペック上は遣い易いデバイスのはずなのだが、不良率が高すぎる。　また、その手の不具合のレポートに辿り着けず、トラブルの原因を判定できないのがかなり不便だ。

adatのデコーダICがBurnoutした件は、端子の腐食による天ぷらハンダが原因でラッチアップ現象が発生した可能性がある。　これは、ICを取り付けていたボードを分解していた時に発覚したのだが、組立時のことを思い起こすと、変換ボードとICのハンダのノリが悪く、フラックスを塗布して取り付けを行っていた。

その後、事故で壊れたICを再加熱して基盤から取り外す際に、普通は頑固に固着している筈のハンダが、妙にあっさりと外れたことから類推しているのだが、旧い部品はこの手の腐食の問題が内部に至るレベルで発生していることがあって、油断ができない。

もちろん、新調する予定のデバイスを正常に動作させられるかどうかは別の話で、基盤の発注は評価用のキットを使って動作の確認を行った後になる。　

FPGAに至るデータラインのEMI対策について

今日は、朝から継続してデータトランスファーの波形を観測しているのだが、やはり周辺機器の状況によって伝送路の状態が左右されるようで、朝方は掌シールドで対応できていた高速伝送ラインのご利益が昼過ぎの現在にはほぼ解消される状態に陥っていた。

これは、熱ダレ等の原因が想像されるが、特にパソコン接続のオシロスコープはノイズの発生源なので、この辺りの機器の影響を無視できない。

そこで、毎度お馴染みの "dsb" をlatch信号の立ち上がりから送信データを確定するforループの間に挿入して様子を見るのだが、今回はいきなり前回行った実験の2倍にあたる"32発分のdsb"を投入してようやくシールド無しで動作が安定する状況を確認できた。



データの送信によって専有される時間は若干増えて、サンプリングレートは1ch辺り410kHz程度、



2chで220kHzとなった。



このことから、実用域はやはり4ch運用で、6chはチャレンジ、7chは論外と思われる。奇数chを運用する場合は、データ送信のパターンを変更して、波形の演算が行われるタームに2ch分を、裏側に3chを分配することになる。

ただし、この値は考え得る最悪の状況と思うべきで、基盤に回路を実装した状態ではそこそこのレベルで状況の改善が見られると予想している。



forループ内の設定は現状の組み合わせが鉄板で、



これ以上のダイエットは許されなかったが、これも基盤に実装した段階で状況が変わることになるだろう。

MSBのデータが欠損する原因を探る

MCUの送出側でMSBのステイタスをオーディオクロックのタイミングで変化させた信号を、FPGAに入力して反応を観察した。



出力される（概念上の）波形はフルスイングする矩形波なので、エラーを判別し易い筈だ。

視認性を上げるために、ロジック・アナライザを手動クリックしてランダムにΔｔの状況を切り取り、入力と出力を比較してみたが、FPGAがMSBのステイタスを正常に取り込んでいることが判明している。

では、あの妙なドリフトは何処で発生しているのだろう？
バラック配線に生じたインピーダンスの影響なのだろうか？

次にオシロスコープを使って、波形を観察してみたが、、、



やはり、エラーが発生する原因の1つに、EMIの影響があるようだ。

まず、通信速度との相関を探るために、カウンタのデータを更新する速度を1/4096まで落としてみたところ、頻度は少ないもののエラーが生じていた。

次に通常の通信速度と1/4096倍の信号を並列して観測したが、その際に掌シールドといった野蛮な方法で、PCにオシロのハードウエアを接続しているUSBケーブルとブレッドボード上の配線を遮断したところ、全くのノーエラーを記録することになった。

MCUの送出側で対処できる点は、latch信号を発した後のタイミングのコントロールで例によってdsbを挿入するのだが、MCUからFPGAまでに至る信号ラインによって変化する寄生容量とノイズの影響によって、そのベストの値が変動するようだ。

ここでもまた折衷案を採ることになるのだが、実測でエラーの頻度を排除できた数値は「dsbを16発」まで増えた。　



結果、1ch辺りのサンプリングレートは420kHzと、それなりに時間を喰われることになっている。



処理速度はこの程度まで低下するが、実質的に問題はない。なお、同期回路の挿入によってFPGAがハンドリングできるシフトレジスタ数の限界を超えてしまったので、扱えるCHが1つ減り、アウトプット数が6chとなった。



実際のところは、プリント配線の寄生容量や隣接する信号ラインの影響を加味して、ch毎にタイミングの調整を行うことになるだろう。

DacHandlerの出力波形を確認する

オシロスコープでFPGAの出力波形を観測した。



実際に出力されている信号を見る限り、正常な形でデータが送信されているように見えるのだが、、、。

信号の桁が激しく変わり出すポイントはバグではなく、LCDでモニタリングしている出力波形が「画面センターの仮想ゼロクロスポイント」を越えた辺りに差し掛かった時の反応だが、２の補数のマイナス表現は直感的に理解し難く、何時まで経っても慣れることが出来ない。

ここに至るまでには紆余曲折があり、FPGAが読み出すデータにはMSBの欠損によって桁代わりのエラーが頻発していた。



まずは、オシロスコープでFPGAのアウトプットを観測した時にWCKのエッジのタイミングで出現するスパイク状の波形が気になった。　ロジック・アナライザで信号を確認すると、WCKのエッジに掛かる直前のタイミングで謎の信号が出力されている。



FPGA側では、MCUから出力されたLATCH信号（ChipSelectみたいなもの）の立ち上がりとともに、書き込みクロックに合わせてデータの受信が開始される。　この辺りのタイミングがシビアなので、FPGAの遅延時間を織り込む形で、データ送信のルーティンを調整する必要がある。



これは、MCUからFPGAに送られる音声のバースト信号を拡大したものだが、送信されてきたスパイク状のデータの状態を同期出力されたクロックのアップエッジで確定することは難しいかもしれない。



FPGAは高速に動作するが、FPGAのインプリメンテーション時に動作を保証しない旨のアラートが出ている手前、、、



MCU側で出力信号にある程度の幅を持たせて、タイミングのマージンを稼いだ方が良いだろう。

この時点では、データ送信を行うルーティン内に、M4時代の名残で複数のNOP命令を仕込んでいたのだが、これがM7では作用していない感があり、"nop"を作動実績のある"dsb"に書き換えて様子を見ることにした。



送信側の波形を観測すると、確かにLatch信号の立ち上がり直後のクロッキングのタイミングがタイト過ぎるようなので、



Latch信号の送信後にdsbを配置して、書き込みパルスCKWの立ち上がるタイミングを遅らせる手当を行った。



CKWに幅を持たせることで、FPGAの書き込み動作を安定させることを目論んで32bit分のデータを扱う送信ルーティン内に配置したdsbの効果は絶大で、2ch送信分の実質的なクロックレートが200kHz台まで落ちてきたのだが、、、



ここまでやってもFPGAの出力に現れる不具合は解消されず、原因はFPGA側にも存在することが確定した。

FPGAの出力にスパイク状のノイズが発生する原因として、シフトレジスタからデータを読み出すタイミングの不一致が推測される。

まず、データを読み出すタイミングをコントロールするSCK（BCK）の位相が反転していることを発見したので、インバーターを通した反転信号をデータラインのマスク切替に分配し、その他の切り替え動作は非反転信号を使用するように回路を変更した。



インバータによる信号の反転を行った結果、不揃いだったスパイクの形は安定したものの、解消することは出来ない。　どうもこれは切り替えを行うスイッチそのもののタイミングに問題があるようで、対処法として回路の構成を変更するか、WCKのエッジで出現するヒゲをマスクする方法を考えなければならない。

FPGA側の問題で解ってきたことは、クロックの同期が期待したレベルで確立されていない点で、レジスタのデータを読み出すタイミングがズレた結果生じるデータの撹乱によってノイズを出力することになってしまう。

FPGAからDACに送られるデータの波形を観察すると、MSBに欠落が生じてデータビット全体が左側にシフトしてしまう現象が確認できる。　



もちろん、取り込み時に問題が発生する可能性はゼロではないが、書き込みはMCUからデータ送出を確認後に出力されるCKWのアップエッジで行われるので、タイミングそのものに問題はない筈だ。

音声データの保持を行っている「シフトレジスタ」は入力されるクロックのアップエッジのタイミングでトコロテン状に32bit分のデータをリレーしていく回路で、これのペア一組でデータの高速転送を行っているのだが、、、



ReadOut時にクロックのレートを切り替えるタイミングが遅れた結果、先頭のデータが欠損してしまう現象が発生している可能性が高い。

この問題を解決する方法として、

１）記録する媒体の構造をRAMに変更する。
２）終段にD-FFを追加してクロックのタイミングでデータを保持する。

以上の2点が考えられるが、とりあえずは実現が容易な第2案を選択、シフトレジスタの終段にD-FFを追加して、データの同期を行う実験を開始した。

このD-FFは64fs（32bitx2ch）のタイミングでデータを固定するのだが、確かに妙なタイミングで波形が乱れることがなくなり、綺麗なパターンでデータを送出できるようになった。



ただし、MSBの取りこぼしが偶に発生する状況は改善されず、データの桁が上がってしまう現象をクリアすることができない。

ソフトウエア側で行う対応は、送信時のデータストリームをFPGA側で確定が可能なデータの幅を設定することで、当初はdsbを大量に挿入して実質的なクロックレートを落とすことで様子を見たが、そのような手当を行ってもデータの取りこぼしを解消することは出来なかった。

FPGA側のゲート当たりの処理速度はMCUとは桁違いに速い筈で、流石にここまでレートを落とす意味はないだろうと見切りをつけ、送信ルーティン内のタイミング・クロックを生成する過程を検討して、受信側で取りこぼしが発生し難いプロセスを考案した。　



結果、1ch当たりのクロックレートは500kHz程にアップすることが出来ている。



ここからさらにdsbを減らして、ギリギリで安定動作が可能なポイントを探ることになるが、その前にFPGA内の同期を確立しなければならない。

その後、バースト信号のセレクターをD-FFっぽいもの（何故このような構造にしたのか完全に失念しているのが怖い）から単純なD-Latchに入れ替えたところ、



エラーの発生を若干ながらも抑えることが出来た模様。

WCKは全てを同期型に入れ替えているが、



同期クロックを更に細かな128FSに変更した方が良いかもしれない。

偶に発生するMSBデータの「取りこぼし」は同期クロックの位相の問題と思われるが、最適解はいまのところ見つかっていない。　

FPGAの性能それ自体には問題が無さそうで、要するに設計者自身の能力の不足なのであろう。

Teensyから送信されたバースト信号をFPGAで復調した

DACには未接続ながら、ステレオペアのバースト信号をFPGAに送って復調を行った結果、



FPGAのDout1にそれらしき波形を観測できた。　

２の補数フォーマット・24bit幅の音声データを、32bitデータ左詰めにシフトした場合の理屈に概ね合致したデータの流れに見えるが、左右のアンバランスな構成が怪しいポイントだ。　

もし、不具合があるとすればコード側に問題がありそうなのだが、ざっと見たところでは原因となりそうなミスを発見できなかった。　一方、FPGAは単純な回路が並列化されているだけなので、こちらに問題があるとすれば状況は更に深刻になってしまう。

いまのところ、DACからの出音には余り期待が出来そうにないのだが、明日は本格的に接続を行っていく。

FPGAの実験を開始する

ブレッドボード上の変換基盤に配置したFPGAをドライヴする実験を開始しているが、Teensy4.0が出力するオーディオクロックの出力電圧が低いためなのか、分周器が動作してくれない。



念の為にFPGAのテストを行ったが、こちらは問題なく正常に書き込みが行われていた。



Teensy側にプルアップを行うべきか検討中だが、新たにオーディオクロックを出力する専用のデバイスを作るべきなのだろうか。

Teensy側のデータ送信はこんな感じだが、



どうも電圧が足りていないように見える。　FPGA側の閾値の設定を見直すべきなのか。

Teensyからのクロック周波数は思っていたよりも誤差が大きかった。



FPGAに内装したカウンタは、オーディオクロック分周ICからの信号は受け付けていたので、Teensyとの相性の可能性が高い。　ということで、やはりFPGA側のH/L判定を行う電圧の設定を検討しなければならない。

不思議なのは、アナログ測定では電圧が足りているようなので、これはFPGA側に物理で問題が発生している可能性がある。



ちなみに、このFPGAは記念すべきQFNサイズのデバイス実装第一号なので、スキル不足による建付け不良を懸念している。　つまり、JTAG周りがOKでも信号周りがアウトという可能性を否定できず、JTAGでNoErrorを確認出来たとしてもそれが接続の健全性を保証するものではなく、断線の可能性を疑うべきかもしれない。　　全端子の接続を確認するコードを書いて、まずは物理的な接続を確認してもよいのだが、ここで、VHDLの書き方を殆ど忘れているという大問題が発覚した、、、。

多少の手間は掛かっても、オーディオクロック系のデバイスを実装したボードを接続して健全性を確かめるのが良いかもしれないが、その際に事故が起きないように注意なければならない。

試しにSCKの出力端子にプローブを接続したところ、AudioClockが64FSに分周された信号を確認できたことから、トラブルの原因はFPGAの配線という物理面にフォーカスされつつある。



FPGAの端子をルーペで拡大して該当する部分を目視したところ、ハンダの盛りを確認できず、トラブルの原因を物理と推測して復旧作業に入った。　作業を行う過程で端子をフラックスで洗浄しても効果はなく、安全ピンを使ってQFN32の20番端子を磨いた後に、ようやくハンダによる接続が完了した。　



通電後にWCKの分周をオシロスコープで確認、FPGAのディバイダによってTeensyをドライヴすることが出来るようになった。

Daisyの端子表を新調する

新しいpin配列に合わせた表を作成した。



同時にライブラリの自動配列表を更新しているが、ClickEncoderを導入する場合には実際にこれを使うことはなさそうだ。　余りpinは17本とギリギリで、余裕は全く無い。

第一のハードルはClickEncoderの導入で、これが成功すると朧気ながらも先が見えてくる。　ただし、その先に待っているmicroSDとLCDを実装するというハードルも決して低くはない。



念の為、基盤上のランドをチェックしたところ、DebugTrace用のpin、"PG14" が小さなランドで引き出されているのを確認できたので、



USERと表示されている "Lチカ用LED" の端子と合わせて2本の都合が付くことが判った。　

これでフリーのpinは19本となる。　LCDのBKLは何れかの端子に引き出せば良いだろう。



が、、、このままでは机上の空論なので、表に示した「余りピン」にデバイスを接続して近々実証試験を行いたいところだが、その前に FPGA & adat DAC の実験を先にやらなければならない。

KEILのインストールとその活用

Daisyで実験を行うためにCubeMXを起動しているのだが、freescaleのMCUExpressoとは使い勝手が違うのは当前として、根本的な構造が異なるTimerの扱いから学習しなければならない。

Timerの構造それ自体はNXPの方が単純に見えて判り易い雰囲気を纏ってはいるものの、



Timerを網羅するクロックの体系が複雑なために、初期設定の方法がよく解らない、、、。　



あと、Daisyを不便に感じるポイントは、PINOUT表にPWMの扱いを含めたPinに配置が可能な機能の情報が明示されていないところだろうか。



一方、ARMが提供するKEILは遥かに理解しやすいコードを吐いてくれる。　



ただし、このソフトはWindows専用なので、MacにVMを導入しなければならない。

VMは既にParallelsとVMWareを試していて、ParallelsにはVM上でUSB接続のライターを通して実際にFPGAのプログラミングを行えた実績がある。　今回は、フリーのVMを見つけたので実験を行う感覚でこれをインストールすることにした。



Win10をisoイメージからインストールして挙動を観察しているが、



処理速度は実用域ギリギリな雰囲気で、Parallelsとは比較にならなかった。



さて、そのKEILだが、残念ながらBoardSpecificな仕様なために、H750系統の搭載されたBoardがリストアップされていない時点で殆ど参考にはならなかった。　



前回KEILによってコードを参照出来たのはF475関連のボードが存在したためだが、7XXシリーズよりも参照出来る項目が充実していた。この参照コードによって複雑なクロック系の設定を行う上でのヒントが得られそうだったのが、７XXシリーズはRTOS系の事例が多く、何故か基本的なハードウエアに関する情報がリストアップされていない。

これは、必要とされるパッケージの取得に失敗しているのが原因なのだろうが、何れにしても750系統のチップは対象外なのが残念だ。

Board 毎に参照できるExampleの事例を調べている過程で偶々Cube系のコードにも遭遇したが、



例を見ても判るように、羅列されるコードからは内容の判別が難しいように感じる。

その後、Win7が走るThinkpadにDLしていたSTM32系列のチュートリアルを発掘した。　



これをWin10が走るVM環境に移植して、基本的なTimerの構造を確認できるようになった。　VMの解像度は初期設定のままでは狭くて使い難いので、GuestCDからドライバをインストールして解像度を上げている。　ただし、この処置には副作用があって、あからさまに動作が遅くなってしまうのが難点だ。

開発環境が整ってきたので、これからTimerの解析を行っていく。



まず、MCUに搭載されているタイマーのうち、32bit幅のカウンタを持っているTIM2とTIM5を使って、InputCaptureを行うことを考えている。

freescaleとの構造の違いは、InputCaptureの機能が並列化されていることだろう。これは制御が簡単な構造で、歓迎すべきポイントと言える。





InputCaptureの構造はこんな感じ。



Timer同士が複雑なルーティンで接続されているが、今回これは使用しない。



一方、ClickEncoderを使用するためには、定常的にインターラプトを行う単純な構成のTimerを活用する必要がある。



Timer13/14の構造がより単純なので、これを使用するとよさそうだ。





インターラプトの作法などTeensyとは文法が異なるので、初期設定は一からやり直す形になる。

CubeMX上にDaisyのPin配列をマッピングする

CubeMXにDaisyでリザーヴされているPINをマッピングしているのだが、端子の配分に余裕が殆ど無く、DACの追加は厳しいかもしれない。



端子の配列を試しながらアサインが可能な音声出力ポートの検討を行った結果、SAI2_SD_AをSPDIFに設定すれば2ch分の音声信号を送出できるようだが、この場合はDACとの間にSPDIFの復調回路を挿入しなければならない。　SPDIFの信号を直結できるDACがあれば事は簡単に済むのだが、、、。



その他の方法としては、SAI2のMCKをオンボードDACが接続されているSAI1のスレーヴに設定することで、端子の消費を節約出来そうだ。　



WCK=LRCKが出力できれば、AL-1201に音声データの出力を直結できる可能性がある。



アサインが可能な端子の配列を検討する過程で、上記の方法ではSAI2_AのWCKをどうやっても割付けられないことが判明した。　よって、SAI2_Aの使用を諦めて "SAI2_B” に出力を変更せざるを得なくなったのだが、SAI2_SD_B端子にはTIM5とのコンフリクトが発生している。　これを回避するにはTIM5のInputCaptureをCH1からCH4に変更して、SAI2_FS_BとSAI2_SD_Bの出力が可能となるように、端子の構成を組み直さなければならない。　



実のところ、ST系のInputCaptureに関してはまだよく構造が判っていないので、この変更が有効かどうかはいまのところ確かではない。



現時点でリザーヴされた端子の状況は、こんな感じになっている。



喫緊の課題は、PWM端子のアサインと、LCDの接続の可否を確かめることだが、このボードは、どちらかというとギターシンセ向きのデバイスかもしれない。

ギターシンセを構築する場合に、従来設定していたVolumeAntに対応するのが「ペダル入力」と”Envelope”で、InputCapture1ch分を廃止してAD入力から制御信号をサンプリングすることになる。

ちなみに、Envelopeはギターシンセのキモなので、入力端子はPitch/Envelope/VolumePedalの3つに増える。AD2chのみで賄うことも可能だが、InputCaptureは構造が単純な上に性能が一番高いらしいので、いまのところはここに「コンパレータで整形したオーディオ信号」を入力するのがベストの手法だろう。

ギターシンセの運用に関しては、アタックを殺す以外にエンヴェロープは極力いじらない方向で考えている。　楽器の特徴はエンヴェロープによって決まるので、これをADSRにしてしまうとギターでシンセを駆動する意味がなくなる。　ギターでピアノっぽい音を出したい人も居るのだろうが、所詮はキワモノに過ぎず、あまり意味のない行為だったように思う。

DacHandlerの信号ラインを今一度整理する

DacHandlerは、MCU内部のDMAを駆使してオーディオ信号をハンドリングする代わりに、32bitのオーディオデータを定常的に出力するために構成された外部接続のシリアルレジスタで、



WCKのUP&DOWNエッジのタイミングで書き込んだ8ch分の音声データを、ステレオ・ペア4chに加工して出力する。

シリアルレジスタを駆動するクロックは、クロックセレクタによって選択される。　セレクタのステイタスが"0"の場合がCLKRを選択する読み出しモードで、DAC側に64Fsのタイミングでデータを供給する。　



ステイタスが"1"の時は高速の書き込み用クロックCLKWが選択され、MCUから出力されるLATCH信号のタイミングによって超高速でデータの受け渡しが行われる。

FPGAの内部では、ステレオペアのデータを交互に受け渡すためにWCKの反転信号が生成される。



DacHandlerは、この仕掛によってL/Rのオーディオデータを交互に送出している。　



レジスタはMCUから出力された”LATCH”信号のタイミングで、送出されてくるシリアル・データを取り込む。



一方、MCU側では、データを送出するタイミングをWCKの各エッジで判定している。



WCKがHIGHの時に奇数、LOWの時に偶数チャンネルの送出を信号の状態が変化したタイミングで行う。



奇数チャンネルのデータを送出した後に音声の合成を、偶数チャンネルのデータ送出後に映像データのハンドリングを行い、余った残りの時間にLOOP内に配置されたインターフェイス系のタスクを処理している。

M7は超高速で処理が行えるために、MCU内部で信号をハンドリング出来る可能性があり、その場合には信号ラインを従来のLATCH x 8 + DOUT + CKW の10本から、 WCK x 1 + DOUT x 4 の5本まで抑えられるかもしれない。

AutoFade-In Mode の実装を行う

Fade-In を繰り返す　"AutoFade-In Mode"を実装した。



使用を検討していたChronoは使い物にならず、ローカルカウンタをArpeggiatorの設定値でディバイドする方式を採用することになった。



新たに実装したButtonには、シングルクリック・ダブルクリック・ロングプッシュの３モードが設定されているのだが、このうちロングプッシュにフェードインを繰り返すモードをヴォリュームの制御系に挿入する機能を実装することを思い付いた。　

ここで、GUIの描画機能を実証するために追加した「フェードインを繰り返すプログラム」の構造を整理すると、VolumeDetectorがアクティヴェイトされるタイミングでカウントアップを行うローカルカウンタの出力を128分周したクロックを使って、出力エンヴェロープの制御を行うために設定した専用のデータアレイを読み出している。　



当然ながら Fade-In を完了してカットアウトするまでの時間は固定されているので、これをそのままエフェクトとして実装することは、楽器として望ましくない。　

そこで、クロックの分周比を決定するファクタとしてArpeggiatorのパラメータ arpSpd との連携を考えたのだが、



当初はローカルカウンタを廃し、Chronoをマイクロセカンドオーダーで設定することで、より正確なタイミングでカウントを行うクロックを生成する予定だった。

Chronoに入力するValueは、arpSpdC の最小単位 1ms = 1000us をデータアレイのアドレス数 ＝ 4096 で割ればよいのだが、1カウント毎に Fade-In を行うのは流石に忙しないので、arpSpdC に step 数を掛けた数値を4096で割るのが妥当な措置と思われた。　例えば、6stepの フレーズが設定された Arpeggio の場合、最短の1msに arpSpdC を設定すると、(1000 * 6) / 4096　といった計算になる。　問題となってくるのは端数の扱いだが、実質的に聞き取りが不可能な1msで推移する step は無視してよく、結果を round すればある程度は辻褄が合いそうだ。

実際に SceneMemory にセットされている arpSpdC の数値を確かめると、速い方でも 50ms 前後とあり、これに step 数分の "7" を掛けた 350 * 1000 を 4096 で割った数値 "85.44921875" を丸めた 85ms が、1クロックをカウントする時間となるのだが、これでもまだ忙しない感じがする。　フェード・イン時に最初の step は実際には聞き取れないので、Arpeggio のフレーズを2巡する位に尺を設定するのが現実的かもしれない。

その後、暫くの間いろいろと頑張ってはみたものの、残念ながら結果は散々な有様で、Chronoがまともに機能しないことが発覚している。　Chronoではどうやっても VolumeAnt 側のデータが更新されるタイミングとのミスマッチを解消出来ず、全く同一のコードであるにも関わらず「実装を行う場所」によって異なる動作が観測されている。　錯綜する制御系のデータラインをコンパイラが捌ききれなかった感もあるが、このような場合はコンパイラそれ自体の不具合を疑うべきで、一連の作業はこの時点で一旦スタックすることになった。

で、、、結局は振り出しに戻る形で、周波数ディテクタのルーティン内にカウンタ毎機能を内装することになるのだが、もしかするとコンパイラの側としても、単純な機能の解釈を行う方が楽なのかもしれない。

最後に、フラグを読んでスイッチのステートをLEDの点滅速度で表示する機能を追加しておいた。



ダブルクリックで起動する機能としては、Pitchの固定を考えているが、



出音全体を固定せずに「コードを構成するサブオシレーターのピッチを固定する」方式を採るのが実用性の点から正解かもしれない。　



この機能を応用すると、外部入力からコードをドローン（通奏低音）のように制御することが可能になる。

ボタンの多機能化を行う

メモリーコールバック／シーケンス・スタートを行うプッシュスイッチにダブルクリック・長押し対応のオブジェクトを導入した。









いまのところ、シングルクリックのみに従来の機能をアサインしているが、



なにか便利な機能を組み込めないか、考えているところ。

動作に若干のラグが入るのがイマイチだが、テルミン自体が反応の緩い楽器なので、実用上の問題は無いだろう。

ラグを解消する方向に判定の速度を速めるには、このコマンドを使う。



反応速度を速めるにつれて、ダブルクリックの検知がキツくなる問題が発生する。　左手は若干遅れるので甘めの設定にしておかないと動作に支障が出そうだ。

クリックの反応速度を設定する setClickTicks(int) のデフォルトの状態は500msだが、反応を遅く感じたので、試しに200msに設定してみたがこれはクリティカル過ぎた。　300msでも右手に比べて動きが遅れがちな左手では誤動作の回数が増える。　折衷するのは400ms程度だろうか？

信号ラインにバッファを介した状態でLEDのPWM制御を行う実験

先に行ったCortexM4の使用を前提とした既成の基盤上の実験では、タスクの増加によって動作が不安定になった結果、導入を諦めることになった。

が、それ以前の問題として抵抗値のミスマッチが原因で上手く発色できなかったこともあり、回路の評価それ自体が中途半端な結果に終わっている。　このままでは気持ちが悪いので、バラックを組み立ててインバータによるバッファ回路を介してLEDをPWMドライヴする実験を行うことにした。



PWM制御を行う信号ラインには、HC14系統のインバータが挿入されているために、PWMのデューティーサイクルはそれに見合った反転が必要で、例えば「赤」を点灯させたい場合の比率は、

{0, 255, 255};　　// R,G,B

となる。　上の画像は「黒」を表現しているが、MCU直結した場合に漏れ電流の影響で薄っすらと点灯していたLEDが完全に沈黙している。

今回確かめたいのは、紫系統の微妙な表現の可能性を探る思惑で、以下にその例を挙げていく。



これはINDIGOで、青みが強いはずが赤が勝っている感じがする。



LAVENDERも、青みが足りない



MAGENTAは、赤が完全に勝っている。



PINKは白みが足りない。これは緑の出力調整でなんとかなりそう。



CYANは若干緑が強く感じる。



WHITEだが、これも緑が若干強い。



YELLOWも若干緑が強く、赤／緑を輝度が弱い青（実は直結）と相対的に弱める方向で挿入する抵抗値を調整する必要がある。　現状は910Ωで実験しているので、これを1Kに変更することで対処できそうではあるが、LEDの個体差によってこの値は変動する可能性が高い。

Teensy3.6へのダウングレードは失敗に終わる

結論から言うと、Teensy3.6へのダウングレードは不可能と結論した。

まず、最新のTeensyduino1.54ではスケッチをコンパイル出来ない。　旧ヴァージョンのTeensyduino1.52のSmallestCodeWithLTEのみコンパイルが可能で、



他のモードではシステムが立ち上がらない・謎のフリーズ等大量の不具合が発生する。

また、LEDをPWMで制御する場合にはそれなりのリソースが割かれるようで、スタティック点灯に比べて全体の動作が不安定になった。

要するに、今年初めに完成させたヴァージョンはCortexM4の処理能力を限界まで引き出していたということで、今後は周波数検知回路の効率化を行う以外に性能向上の手立ては無さそうだ。

一方のM7だが、現時点では発音の確認を行っていないが、描画される波形が安定しているうえに、如何なる操作を行ってもシステムが落ちないステーブルな状況が保たれている。

ということで、今後はより信頼度の高いTeensy4.1をメインに開発を行っていくことになるだろう。

SDカードにデータを記録する際に”０”を入力すると"56"に変換されてしまう件について

SDカード上のデータをハンドリングするスケッチを精査したところ、過去に発見していたバグが相変わらず解消されていないことが判った。



これは、送出するデータをストアするレジスタに "0" を入力し、それをSDカードに読み込ませる過程で、レジスタ上に入力した "0" が "56" という謎の数字に変換されるバグで、Teensy3.6上で確認した際には何をどうやっても解消できなかった案件だ。　

ちなみにこのバグは、ゼロ以外を記述した場合はそのままの数値がSDカードに入力されるという、よく解らない反応を示す。



今回も同じバグの発生を追認できたのだが、これはSDカードのライブラリ由来のバグと思われる（M4からM7にMCUが変更されてもバグが発生している）ために、今回はデータのトレースをprintlnを使って行ったところ、SDカードの書き込みルーティンが開始される直前の位置で元データの健全性が証明された一方、第一項目の書き込み後には、何故か "56" が、書き込み終了後には "48" という数値に変化することが確認された。

ちなみに、"48" は ASCII コード上で "0" が割り振られている一方、"56" には相関を見つけられなかった。

どうもこれはSDカードのデータを格納するアドレスの送りがそのまま反映されている雰囲気だったので、試しにSDカードにアクセスする順番を変更するという少々野蛮な方法を試したところ、元データに変化は認められず、場所を入れ替えて後回しにした項目がSDカードにアクセスした後に、例の"56"が出現する運びとなった。



ということで、バグの発生を回避できるようになった反面、依然として大元の原因は不明という少々不安になる状況で、楽器はまだしも安全の保証が要求されるレベルの機材への採用は不可と結論することになった。

GNU Octave をMacbookに導入する

先に、一連の作業から得られた「成果」を示す。



今回Octaveをインストールする気になったのは、DMAMEMやEXTMEMのお陰でキャパが広がったWavetableの枠に本来搭載する予定だった波形を揃えるのに必要になったのと、



音源の構造をやフィルタリングを行う際の思考実験に使えそうだというのが主な理由だが、万が一Windowsマシンがご逝去された場合の保険で稼働の場を広げたいという思惑もあった。

過去、インストールにトライした結果、尽く失敗を繰り返していたのを今更その気になったのは、MacPorts を介してOctaveを導入する方法を見つけたのが理由だ。　ただし、今回もインストールを貫徹できる保証はない。

最初に、GNU Octave を導入するための基礎となる MacPorts をダウンロードしてインストールを行う。　手持ちのPCにインストールされたMacOSのヴァージョン毎に幅広く対応版が用意されているので、適切な対象を選択してダウンロードを開始する。



ダウンロード後はインストーラを立ち上げるだけと、非常にお手軽な印象だ。

次にTerminalを起動して、GNU Octave を対象としたリンクから取得したコマンドを実行する。

Terminalを開いた後は、少々不安になる長さで延々とインストールが続く。



インストールに20分程を費やすことになったが、完了後にApplicationフォルダをチェックすると、MacPortsフォルダの中にOctaveのアイコンが出現する。　これをクリックして、無事GNU Octave が起動した。　



ここまでは、今までになくスムーズに事が運んでいる。

インストールの完了後、まずはお手軽そうな逆相波形を生成しようとしたが、何故か描画を行うことが出来ない。　試しに過去にWindows上のOctaveで作成したプレゼン用のデータを開いてみたが、こちらはまともに描画が行われている。



しばらく不調の理由がわからずに作業が停止してしまったが、Windowsとの互換で揉めることがあったWAVファイルの扱いに問題があると考えて、コメントアウト（％）でラインをパージしたところ、無事描画が行われるようになった。



なにか問題が立ち上がった時点で処理が停止されるようなので、CSVの書き出しポイントと描画の命令がWAVの生成を行う命令よりも手前に記述されていた場合、暫くの間は不具合に気付けなかったかもしれない。

とりあえず、Octaveの稼働を確認できたので、既に記述済の各種波形を生成するプログラムを利用して、逆位相版のCSVデータを出力する。　位相を反転するのは簡単で、

revCos01 = round(((1-cos(2*pi*linspace(0,1, LUT_LENGTH))+1) * 2047) * 0.95) -1945;

波形の反転に必要な要素を書き加えるだけなのだが、出力される数値をレンジ内に収めるには増幅度とオフセット値の関係をカットアンドトライで調整する必要がある。



次に、randを使ってNoiseの生成を行った。　できればPinkやBrownも揃えたいので、フィルター効果をかけようと思って対象となる機能拡張＝パッケージなるものをMacPortsのサイトで検索したところ、使えそうなものが数件ヒットした。　

ところが、この「パッケージ」がどうやってもOctaveにインストール出来ず、作業が暫くその段階でスタックしてしまった。　

参考にするために検索で辿り着いた日本語のサイトによるパッケージ導入に関する解説をざっと眺めてみたが、何れも「スムーズに事が運ぶことが前提」のようななところがあり、余り役には立たなかった。　そんな時はフォーラム（英語）を漁るのが正解なので、Webで検索を掛けたところ、「ヘルパーアプリみたいなのをインストールしないと始まらない」なるアドヴァイスを見つけた。

確かに、フォーラムに記述された文言の流れには、

error: the following dependencies were unsatisfied:
signal needs control >= 2.4.5
signal needs general >= 1.3.2

と、それっぽいことが書き出されているのだが、手元のCommandWindowにも同様の文言が確認できる。



このようなネイティヴが戸惑うレベルの表現は、英語の苦手な一見さんにとっては意味を汲み取れない文字列に過ぎず、その辺りの陥り易い問題点をちゃんと指摘してくれるのが「英語圏の強み」なのであろう。

ちなみに、Arduinoの互換を謳ったよく解らないパッケージをインストールしてみたが、CommandWindowで一杯怒られて使えそうにない雰囲気なのが残念だった。



インストールが完了したパッケージは、　pkg list で確認することが出来る。



さて、プログラム独特の作法を理解するのに時間を要したが、今回インストールした"signal"というパッケージに内包されたButterworthFilterを使って、



なんとなくではあるが、ピンクとブラウン風なノイズ波形を生成することが出来た。　



スペクトルの散り具合は、アップロードしたヴィデオの後半、登録波形のアドレス＃27〜＃29を選択するシーンで確認することが出来る。　

アドレス＃27はフィルタなし、



＃28がピンク、



＃29がブラウンのWavetableを呼び出している。



以下に、Octave上でプロットしたフィルタなしの画像を示す。



それにしても、ソフトウエアを起動するごとに pkg load signal のように、使用するパッケージのLoadが必要な仕様が初心者に対する罠となっていて、割としょーもないところに落とし穴が存在するアプリなのだなあ、、、といった感想を持たざるを得ない。

Terminalでpkgのインストールを行う際は、先ず "octave" を呼び出した後にコマンドを入力すること。



ちなみに、窓関数の実証試験を行って、ノイズからピッチを抽出する方式の音源を楽器に実装するのが最終目標だが、このタイプの音源はプロセッシングパワーを過大に消費する構造なので、実現は難しいだろう。

Threshold Point の設定を行うGUIを改良する

搭載している3種類のエフェクトモードには起動ポイントの設定が可能だが、



これらの数値を調整するGUI、ThresholdModeの改良を行った。



各エフェクトに配される Threshold Point の設定値は、画面上方の表示エリアに数値とバーグラフで表示される。



エフェクトの起動と同時にPitchBendとLFOはUpperKnobのLEDが、



Chopping Modeと動作を連携させているChromaticはLowerKnobのLEDが、



設定された閾値を超えたところで反応する。

PitchBendとLFOに関しては、状態を監視するプライオリティーがChoppingEffectよりも高く、特にLFOは事実上 muting それ自体を出力に対して行うエフェクトなので、ArpeggiatorによるMute動作＝Violet色の表示を控えることにしている。

Choromaticのみが、UpperKnobのLEDが設定値に対応していて、



入力された値に比例する間隔でLEDが点滅する（設定値が大きくなると点滅速度が遅くなる方向に変化する）仕様となっている。