2018年06月12日

Open.Theremin@attatchInterruptの項目を追加する

DACの読み出しを行うタイミングの制御に関して思いついたこと。

プログラムの基本的な構造は、アンテナのセンシングやロータリーエンコーダーの読み出しを行っているメインループと、そこにWCKが立ち上がるタイミングでDACへのデータ送信を行った後に波形データを読みだす一連のタスクが割り込む仕組み。

現状ではadat等のWCKの表裏でデータを扱うタスクの実現は難しく、当初はその対策としてメインループの先頭に音声データをDACに出力する仕掛けを追加していたが、データラインの波形を観測した結果、インターラプトからの復帰後に行われる筈のデータ転送のタイミングが安定していないことが判った。

当初、ズレの原因は波形読み出しのタスクの重さから発生する遅延の影響と仮定していたのだが、インターラプトから復帰するタイミングによってズレのバラつきが生じる可能性に思い至った。

この変動するズレの問題を解決するには、WCKの立ち下がりで発動する別のインターラプトを追加して強制的にDACにアクセスするタイミングを固定する方法が有効と思える。(波形を読み出す際のタスクの重さは無視して)とりあえずはこの機能を実装してみたところ、コンパイルだけは通せたのが現時点での状況。

前述したように、この機能はタスクの重さに因って破綻する可能性があり、まずは実験による観測が必要だ。

adatフォーマットの取り扱いに関しては、外部にFPGAによるデータラッチを追加し、WCKの裏面でバースト信号を受信/表でフォーマットに準拠したタイミングで送信を行わせている。

基板にadat系のチップを実装してはいるが、データのハンドリングを行うFPGAの有効性は実証されていない。データ送りのタスクに要する時間(1サイクルでクロックを40余りも消費する)の制限は大きく、実質的には4〜5chの送信が限界と思われる。

既に波形の観測によってattatchInterruptによる遅延が可視化されているが、タイミング的にはWCKに同期していれば問題はない。ただし、この遅れによってシステム全体の処理に要する時間的余裕が削られてしまうのはマズいので、直接的にピンの状態を参照する仕掛けを探る必要がある。

ダイレクトアクセスのアドレスとして既にSAMPCLK_STATEを仕込んであるので、ひとまずattatchInterruptにこれをアサインしてみよう。
posted by Yasuski at 10:42| open.Theremin

2018年05月31日

Open.Theremin@WCKのエッジのタイミングでDACへのデータ転送処理を行う

DAC周りのコードの検証を行う過程で徐々に判明して来ている問題は、データ出力のタイミングが相当にルーズだったことで、WCKのアップエッジで波形読み出しのタイミングを図っていた筈が、場合によってはクロックのダウンエッジを超えたところまで処理を引きずっているケースを観測できた。

例えば、Pitch/Volumeの値を観測する処理ループの先頭に設置したマーカーの出力端子D01から、予想外のタイミングでヒゲが発生している。 これは、WCKのアップエッジを切欠にattatchInterruptによって開始されたWavetableの処理がWCKのダウンエッジよりも早いタイミングで終了し、アンテナの状態をセンシングするループにルーチンが移行したことを示している。

Screen Shot 2018-05-31 at 18.39.12.png

このままの状態では、WCKのタイミングで出力信号を取り込むadatEncoderへの安定したデータストリームを確保することが難しく、プログラムが予想外の挙動を示す可能性がある。 問題の解決法として考えられるのは、WCKのアップエッジだけではなくダウンエッジのタイミングに合わせて処理を固定する手法で、これによりDACへのアクセスに必要な処理を分散出来るようになるはずだ。 

Screen Shot 2018-05-31 at 19.45.54.png

同様に、wavetable読み出しのルーチンの先頭にDACへのデータ送信ルーチンを配置する。

Screen Shot 2018-05-31 at 19.46.28.png

こちらは、コードを書き換えて、WCKのエッジのタイミングで各DACにデータ転送処理を行うルーチンを配置した後に観測した波形。 D01にはMAX5717に出力するLDAC信号をアサインしている。 MAX5541への送信ルーチンにはNOP命令を追加して、処理のタイミングに余裕をもたせた。

Screen Shot 2018-05-31 at 19.35.22.png

これはMAX5717へのデータ送信ルーチン。

Screen Shot 2018-05-31 at 19.36.05.png

こちらがMAX5541へのデータ送信ルーチン。MAX5717への送信ルーチンと比較すると、CSクロックの幅が広いことが判る。

Screen Shot 2018-05-31 at 19.36.18.png

MAX5541のデータ送信のタイミング。

データが確定した後、それを取り込むSCKのアップエッジまでのタイミングを40ns超に調整している。

Screen Shot 2018-05-31 at 19.40.01.png

これがMAX5717のデータ送信ルーチン。 高速で運用するクロックがスパイク状に見える。
SCKのデューティーサイクルはもう少し改善する余地がある。

Screen Shot 2018-05-31 at 19.43.44.png

posted by Yasuski at 21:13| open.Theremin

OpenThereminOnTeensy@テストベッドの調整とコードのデバッグを行う

ソフトウエア評価用に作ったテストベッドにMCUを組み込んだところ、静電容量が変動した影響でリファレンス側オシレーターのチューンが狂ってしまった。 

IMG_7957.JPG

変動はPitch/Volume双方ともが20kHz程上にズレていて、これは最大で8pFが限界のGiga-Trimの可変範囲を超えている。

ということで、チューニングのやり直し。

まさかMCUがここまで影響するとは思わなかったが、ダミーでもよいのでMCUと同程度のマスのものを基板に搭載してチューンを行う必要がありそうだ。

確認のために数回の通電を行ったが、立ち上げ時の動作も怪し気な雰囲気だ。観測ポイント設定用に伸ばした結線が悪さをしている可能性もあって、原因の判定が難しい。

能動的な対策としては、外乱による変動をキャンセルするためにオシレーター部を電磁シールドで覆うのが正道で、通信機器の基板でよく行われている手法ではあるが、これは一寸大げさだろう。 実験機に搭載したオシレーターの回路構成がアンテナ側とリファレンス側で異なる(片方はVariCapによる補正が効く)のが情況を余計にややこしくしている。 手元にある最新の基板(ただし修正箇所が存在する)ではVari-Cap搭載型を組み合わせているので、調整が少しは楽になるかもしれない。

いろいろと挙動が怪しいMCU搭載DACでVari-Capを駆動する方式だが、手動で補正を行う形式に変更したほうが良い感触がある。

結局、20pFコンデンサの値を追加することでオシレーターのチューニングを完了したものの、依然としてMCUの挙動が怪しい。 試しにロジック・アナライザで特定箇所の波形を測定したところ、オーディオ関連の信号処理が全く行われていないようだ。 LEDのドライヴに関しては問題なく行えているので、プログラム全体のおおまかなステップはこなされているようだ。

稼働実績のあるコードとの差分を中心に精査したところ、まずは不要なFTM3を稼動状態にしているのを発見したため、これを停止した。 構成をシンプルにするために、チューニング機構はフル手動に変更し、不必要な条件分岐を極力減らすことにした。 不具合の発生は変数宣言の段階で何かポカをやらかしている所為なのだろうか? 特に基板独自の仕様を定義した部分が疑わしい。

システムに通電しながらシリアル信号を読む手法はMCUの破壊を誘発する可能性があるため、LEDのマーカーを使ってモード切り替えの推移を観察することにしたが、この部分に問題はなさそうだ。 次に、DACのサブルーチンにマーカーを組み込んで出力を観察してみたが、LEDが点灯せずアクセスを確認できない。

念のため、ロジック・アナライザでMCUの各デジタル出力を計測すると、こちらも出力を確認できず。 コードを再検討してクロックソースに同期させてデータを出力する為の条件分岐を行う箇所が怪しいと判断し、ここに動作検証用のフラグ出力を追加して波形を観測しながら判定を行う構造をよりシンプルに改装した結果、チップセレクトの出力を確認できるようになった。

ところが、DACにデータを送信するためのシリアルクロックの出力が認められない。データストリームの波形も平坦なままで、これは何かがおかしい。 そこで、不具合が予想されるDACへのデータ送信ルーティン内のクロックとデータの記述を調べ直したところ、ADAT系のデータラインとの混同を発見した。 

これは、稼動状態にあるシステムからコードを移植する際にピンアサインが異なる部分の記述を間違えたのが原因で、混同したデータラインを修正することで、問題を解決できるはずだ。

コードを修正した後にロジック・アナライザでDAC出力のデータ・ストリームを確認した。

Screen Shot 2018-05-31 at 9.24.20.png

一番上の信号がD18に入力されているMCK/44.1kHzで、現状は半波長の間にオーディオ出力の処理を行っている。

残りの半波長では、アンテナのセンシングをループで行っているが、この間に何回処理が行われているか現時点では不明。 アンテナのセンシングを行うループ内に、オーディオ出力の処理を割りこませることは可能だが、何れにしてもadat出力(現時点では機能をキャンセルしている)とDACとの併用は難しいと思われる。

16bitシングルCHのオーディオストリームに費やされる時間を計測した画像。

Screen Shot 2018-05-31 at 9.21.14.png

二発目の処理はOverDriveモードを有効にした時点で稼動状態となる。

和音設定の変更で全体の処理が重くなると、WCK半波長分の処理スペース後半にDACへのデータストリームが追いやられることを確認している。

処理に余裕を持たせるため、OverDriveモードのデータストリームををWCK後半に移すことも考えるべきか。

こちらは、データストリームとSCK(シリアルクロック)との関係を測定したもの。

Screen Shot 2018-05-31 at 9.23.21.png

データ確定からSCKのアップエッジまでのマージンは約10nsと出た。 処理ステップの消化時間からクロックをフリーランさせた結果がこれで、MAX5717/5719ではギリギリのタイミングとなるが、、、

WS001293.JPG

MAX5541に至っては明らかに速過ぎる、、、。

WS001289.JPG

辻褄を合わせるためには、 __asm__ volatile ("nop");  等を使用した遅延処理が必要で、最終的には現物合わせで調整することになる。
posted by Yasuski at 13:24| open.Theremin

2018年05月30日

TeensyでWDTを試す

WDTに関する記事を見つけたので、これを参考にしてクロックソースをテストベッドに組み込みたい。

https://bigdanzblog.wordpress.com/2017/10/27/watch-dog-timer-wdt-for-teensy-3-1-and-3-2/
posted by Yasuski at 05:58| AudioElectronics

2018年05月20日

Open.Theremin@テストベッドに基板を移植するも断線が疑われる

基板を移植後に、MCUを搭載しない状態でテストベッド用の基板を装着してみたが、

IMG_8041.JPG

WCKをアサインしているはずの端子に信号が上がってこない。

Screen Shot 2018-05-20 at 20.34.58.png

信号ポートのch0/1にディテクターアウト、ch2にWCKをアサインしている筈なのだが、、、。

断線の可能性が高いので、再度バラして道通をチェックすることになった。

追記:


FPGAから出力されるクロックソースは、MCUからの起動信号("H"で起動)が必要なことを失念していた。確か、前にも別基盤で勘違いをやらかした記憶があるが、確認したところ端子の断線も無くひとまず問題は解決した模様。
posted by Yasuski at 21:06| open.Theremin

2018年05月19日

Open.Theremin@今更ながら回路の配線ミスを発見する

基板設計時の思惑を忘れてポカをやってる案件がまたもや発覚した。

リファレンス側のオシレーターを使ってディテクターとして使用するD-FFのクロックをチョッピングしているのを忘れて、そこにアンテナを繋ぐという無茶をやらかしていた。

実験の結果、10回転VRを用いてもチューニングのスイートスポットが狭い感触だった。 製品化する場合はクリティカルなポイントを探した後に上下の変化幅を調整することになるが、機械的な構造によって調整幅に影響が出ることになりそうだ。

ロータリーエンコーダーの切替え機構の不備もそうだが、異なるプラットフォームのために設計した基板の機能を切り貼りしてたのが仇になってる感じ。

試しにリファレンスとアンテナに対応するオシレーターを入れ替えてみたが、これが何故かメタメタな波形で使いものにならない。 

原因はアンテナ端子の接続ポイントを間違えるという凡ミスだったが、全てのVari-Cap駆動系オシレーターの配線をミスっているので、既存の基板には修正が必要。

WS001269.JPG

修正箇所はプリントパターンを2箇所ルーターで削って、コイルとアンテナ端子を接続するだけ。 リファレンス側にはアンテナを繋がないので、問題は発生しない。

WS001270.JPG

誤配線を修正後、

WS001276.JPG

正常な発振を確認した。 



最新版の基板にも修正を反映しておいた。

antPortPitch.png

antPortVol.png

otot409e.png
posted by Yasuski at 16:13| open.Theremin

2018年05月18日

Open.Theremin@Vari-Cap調整用のVRを装着したケースに基板を移し替える

MCUの死亡を機にデジタル信号検証用に作ったトリマー用のVRを実装した筐体に基板を移し替え、素の状態でオシレーターの再チューニングを行うことにした。 予想通りリファレンス側の周波数が高めに出ていたので、これを下げる方向で再調整を行うことになる。

今回は再分解の手間が掛かってしまうが、予め基板裏にコンデンサーの時定数を調整するためのポートを設定しておけば、リード付きのコンデンサーを取り替えて気軽にチューニングを行える。 該当するSMDコンデンサーのランドには予めリード線用のスルーホールを設置してあるので、基板裏側のランドに丸ピンタイプのソケットを追加する。

一連の不毛な作業で思わぬ寄り道をしてしまったが、ここは一旦仕切り直してMCUが未実装な状態でアナログ側のチューニングに臨むのが正解だろう。
posted by Yasuski at 23:35| open.Theremin

Open.Theremin@新型基板の開発が頓挫中

新型テルミン開発の現状を箇条書きでまとめると、、、

1)アナログ部は概ね正常に動作している模様だが、D-FFによるディテクターの働きが正常かどうかはオリジナルの回路を実際に測定して確認する必要がある。

2)オーディオクロックの発振は正常に行われているが、MCUの動作を検証するシリアルモニターによる検証方法が、MCUに入力するクロックソースが別電源なために実行できないという問題がある。

3)起動時に音声が出力されない。テルミン以前の純粋な音声再生ルーティンが機能していない。

4)キャリブレーションモードへの移行を判定するモードスイッチは正常に動作している模様。

5)ただし、モードの移行をスイッチの押し時間で判定するタイマーがオーディオクロックによってドライヴされているため、ソフトウエア開発時の検証が出来ない。

6)実際に電源を投入して運用を行った状況ではロータリーエンコーダーの切り替えが出来ておらず、DACの出力電圧が変化しない。

7)オシレーターがチューン不能なため、ピッチ判定機能の検証が行えない。

8)手動でオシレーターをチューンした場合も、Volume側のLEDドライヴ(音声出力を判定している)が行えていないことが判る。音声が出力されない問題も絡んでくるのがポイントで、チューンの状態を確認できない。

9)電源とUSB通信端子の併用は、MCUの破壊をもたらす。

以上、判明している不具合をまとめてみたが、稼働までの道程は遠そうだ。

追記:


MCU2個目が死亡。

もう呪われているとしか思えないが、どうも通信の途中にUSBケーブルを引っこ抜いて死亡させるという愚を犯していた気がする。

毎度、書き込み時の情況はモニターしていた筈なのだが、偶に通信が遅延してそれを認識せずにやらかしていた感あり。

で、モードの切り替えだが、LEDの表示のみが働いていたようで、モードの切り替えを確認するLEDマーカーを追加しても反応しないことから、理由は判らないがなんらかの機能不全が発生している模様。

基本的には稼動状態だった旧システムからコードを移植しているだけなんだが、何故不具合が発生しているのか全く見当がつかない。
posted by Yasuski at 17:15| AudioElectronics

Open.Theremin@またもやMCUをぶっ壊してしまう

テルミンの筐体を乗り換える前に、MCUに内装されているDACのコントロールを暫定的に復活させて、オシレーターの可動域を再チェックすることにした。

とりあえず、リファレンス側の周波数が修正されたが、肝心のロータリーエンコーダーが動作不良っぽく、トリムが全く効かない。

マイコン独立で動作確認したところ、ロータリーエンコーダーの機能は生きているようだ。電源を並立駆動させてMCUを飛ばす不手際を再度やらかさないようにしなければならないが、LEDの点灯には外部電源が必要なのとMCKの供給がFPGA経由なのでクロックを噛ませた状態でソフトウエアの検証を行えない。

で、外部電源とUSB経由のプログラミング&シリアル通信でソフトウエアの状態を監視する作業を半日やってみたが、先ほどまたもやMCUをぶっ壊してしまって今日の作業は終了。 どうもTeensyはMacと相性が悪いのではないかという疑惑が頭をもたげてくる。

今日明らかになった問題点はキャリブレーションモードに入れない状況で、モードの切替が出来ないために、チューニングが一切効かなくなるという重篤な状態なのだが、MCUがRGBエンコーダーのクリックを受付けなくなった矢先にご逝去されたという状況がヒントになるかもしれない。 つまりプログラム単体ではなくハード由来のバグの可能性をも示唆しているのだが、現時点では有効な解決策が見えてこない。

ちなみに、RGBエンコーダーの機能を切り替える条件判定の部分でstatusを読んでいたが、ここでプログラミングをミスっていることが判明。 modeを読んで条件分岐を行わないとpotは切り替わらないのだが、この部分では本来は追加したキャリブレーション専用のスイッチを押してチューンを行うつもりだったことを思い出した。
posted by Yasuski at 01:02| open.Theremin

2018年05月17日

Open.Theremin@スケッチを専用基板に対応させる

昨晩からスケッチの精査を開始しているが、まずはプッシュスイッチの状態を判定するために設定した時定数にミスが発覚、これを修正する。

WS001267.JPG

次に、ロータリーエンコーダの2面設定を廃止し、単純化を行った。 以降、キャリブレーションは純アナログ方式で行うことになる。

WS001266.JPG

続けてコードの検討を行っていくと、Wavetableの参照後にローカルで音源のミックスを行っている箇所が怪しい。 ローカルの音声処理は、後々のことを考えて24bit幅に統一することが望ましい。 中間出力のデータはノーマル系とサチュレート系の処理を個別に行っておく。

WS001265.JPG

ミックス時の非線形リミッターは16bit幅から24bit幅に処理幅を広げているが、最終的にはこれをDACに合わせてbitshiftを行い辻褄を合わせる。 こちらも、サチュレート系の音声は分離して処理を行っている。

WS001268.JPG

その後、ソフトウエアをMCUに書き込んで通電したところ、無事キャリブレーションモードに入ることが出来た。

ただ、DACへの電圧供給を止めた影響でリファレンス側のオシレーターに周波数変動が発生してしまった。 ここでアンテナ側のチューンをやり直してもVRTを接続した時点で調整が無効になりそうなので、VRTが装着された別のシャシに回路を積み替えてチューンを行ったほうが良いだろう。

posted by Yasuski at 06:46| open.Theremin