SolenoidBell＠i2cからBellUnitへの出力を複線化する

i2c0 の出力に掛かる負荷の低減を目指して、出力ラインの複線化を試みている。



既に出力に設定している i2c1 に、Midi/NoteNumber 64 以上の発音をアサインして、動作確認を行った。



アドレス設定はこのようになっていて、連番ではなく変則的な構成になっている。



これは、i2c で接続する増設ポート用のデバイスの仕様に基づいたもので、

slave_address01 からは PCF8574 が、、、



slave_address09 からは PCF8574A が、



Power MOS-FET への制御信号をハンドリングしている。

青い輝線が新たに設定した i2c1、黄色は i2c0 の SDA の出力波形で通信量の多い i2c0 のデータ・パケットが混雑していることが判る。



追記：

STOP 時に All Note Off (cc# 123 / 01111011 / 7B) を吐きまくっていたので、





これを単発出力に修正した。



MCU の処理系が超高速で Loop しているので、AllNoteOff といえどもコマンドの連打はシステムクラッシュの原因になりかねない。

追記２：

Velocity に対応させる NoteOn1 / Off1 の実装を忘れていたので、該当する箇所に記述を行った。





コンパイル後に i2c1の波形表示で NoteOff 分の制御波形が出力されていることを確認した。



データパケット先頭の 4bit は PCF8574A のアドレス "HHH" で、後半にデバイスに割振った固有アドレスが送信される。　この状態はスイッチ基板が未接続なので、完全な通信は行われていない。



送信データパケットの末尾に出力されているパルスは Acknowledge Clock 。

SolenoidBell@外部クロックによる制御は失敗に終わる

SMF のより安定した再生を目指して、外部クロックによる制御を考えた。

外部クロックといいつつ、まずは プログラムでクロックを生成し、それを GPIO 22/23 の間でやり取りする方式で動作の確認を行った。　

クロックは AnalogWrite と Ticks の2方式を、受け側は attatchInterrupt の BothEdge のタイミングで SMF の読み出し・MIDI 信号の受信タスクを切換えて様子をみたところ、何れの方式もデータの取り零しが激しく、採用を諦めることになった。

一方、未了だった MOS-FET のスイッチ基板の通電試験を行ったところ、5V を供給するラインの断線を発見、修正を行なった後、I2C チップへの正常な電源の供給を確認している。

スイッチ基板を接続する前に MCU の入出力信号の観測を行う。組み立て前に、まずI2C0の信号を確認、



フロントパネルの接続後に、USB_HOST と MIDI 入出力をテストする。

SolenoidBell＠Loop再生時に発生していたSongPositionの不具合に対応する

元々、SMF の Loop 再生は想定されていなかった運用形態なので、ここはあまり拘るポイントではないのだが、SongPosition の開始位置の表示が徐々にズレていくのは流石にマズいということで、ファイルの読出しを開始するタイミングで SongPosition のカウンタにリセットを掛けるコードを追加した。



また、TopSwitch から Pause を行った時に元のモードに戻らない「仕様」が使い難そうだったので、直前の状態を記憶する復帰用のレジスタを追加した。



通常の再生モードで、偶に発生する SongPosition が過大にカウントされる不具合には、リセット回路を追加して対応しているが、



リセットを行うことで SMF の初回再生時に行うシーケンスのステップ数の記録機構を無効化してしまう弊害が発生する。　この問題には、SongPosition をカウントするレジスタを並列化することで対処している。



参照している SMF の作りに問題がある可能性が高いとはいえ、全般的に挙動が荒っぽい感触がある。　正確な評価を行うにために、そろそろ単純な構成のファイルを用意する頃合いだろう。

追記：

PAUSE の選択時に起動していた pot01(a) は使用目的が謎なポットで、どうやら開発の初期段階に EEPROM の初期化を行うことを目的に設定されたレジスタと思われるが、SMF Reader が仕様の変更を繰り返した結果、実際にはアクセスできない状態になっていた。　



無駄な機能はバグの原因になりかねないので、今回このポットを削除して、Tempo 設定を行う pot3 に入れ替えることにした。



同時に関連する表示系の内容を精査して、修正を行っている。



また、これも開発の初期段階に設定していた MOS-FET のスイッチ動作を監視する LED のポート・アサインを確認したところ、後日追加した機能とのコンフリクトが認められたので、関連する GPIO の指定を pin# 40 に修正している。



追記２：

トップページで感じた扱い難さと数値表示の問題を解消する作業を行った。

先ずデフォルトで読み出したファイルのテンポが表示されない問題を解消し、、、



読みだした数値の桁合わせを行った。



また、ファイル選択を行った場合の視認性を上げるために、上部表示エリアの背景色を操作している。



追記３：

発色が怪しかった TopSwitch 左の LED 緑の GPIO 33 番がロータリーエンコーダの LED 端子と重複していることを確認、これを空き端子 38 番に振り直した。

追記４：

Loop モードで長時間運用した場合に、１シーケンス当たりに発生する SongPosition の誤差が積算された結果、大幅にステップのカウントが狂って、初期状態へのリセットが効かなくなることが判明した。

追記５：

ライブラリを精査して getNextEvent() の解釈を再検討した結果、Loop を行っている時に発生するカウントの誤差を解消できたかもしれない。



追記６：

残念ながら Tempo を変更した際に発生する誤差を吸収しきれないことが判明したので、判定基準値 +1 step を追加して誤差を 1 step まで圧縮する方法を採った。　



この方式だと、常に 1 step の誤差が交互に発生してしまう(最初の１発目が発音するタイミングが 1 step ズレたり戻ったりする)のだが、リセットが掛からずにカウンタが暴走する状態よりはマシなうえ、1 step 程度の誤差によって「実用上の問題」は発生しないので、暫定でこの誤差解消法の採用を決定した。

理想は、SMF.restartと連動してフラグを立ててカウンタをリセットする方法だが、ライブラリ本体をいじるのが手間なので、この件はペンディングとする。

追記7：

結局、ライブラリに手を加える形で問題を解決できた。

まず、本体側は isEOF フラグに連動するシンプルな形に戻し、、、



ライブラリの方は、bool MD_MIDIFile::isEOF(void) の中の restart(); の直後に songPos = 0; を記述して、カウンタをリセットしている。



追記8：

テンポを速く設定した場合に、リズムがヨレる現象に対応するために、トリガーの長さを 10ms に設定した。



また、起動後に立ち上がる最初のシーケンスのテンポを読み出せないバグに対応した。



追記9：

MCU 側に複数の midi port の実装が可能なので試してみたところ、PC 側で Teensy が認識されなくなった。仕方なく 1port に戻しているが、原因は不明。



音飛びが気になったので念の為に PC 側で midi 入力信号を確認すると、このシーケンスは 1/16ch の 2 track 分のデータを送信していて、音源側に設定していた同時発音数のキャパを超えていたのが不調の原因だった。

SolenoidBell＠TopSwitchの挙動を調査する

挙動が怪し気な TopSwitch の LED 周りのコードを精査したところ、GPIO のコンフリクトが発覚、端子の配置をコンフリクトが解消される形に修正した。



使用を試みた OneButton はこれも挙動が怪しかったのだが、既にスクラッチ版のスイッチ制御コードを組んで対策を済ませていた。　混乱を避けるために OneButton 関連のコードを全て削除したが、PIT に絡んだ何らかの競合が発生していることは明白だ。　オーヴァークロックされた MCU の処理速度によって影響が薄められてはいるが、競合がテンポの乱れを誘発している可能性が考えられる。　現在は Loop でフリーランさせているタスクの処理をオーディオクロック等でドライヴされた「厳密な時間制御下」に移す必要があるかもしれない。



Tempo の表示は、ローカルで一旦フラグを立てる形に改め、



スイッチとLEDを管理するサブルーチンにタスクを流した。

時定数を組んだ、LEDの発光コントローラーも同様にフラグを立てる形にコードを変更した。



スイッチの動作はこんな感じになった。　右が、Load/Stop で左が Start /Pause を受け持っている。



早速作業中に断線事故を一回やらかしているので、早急にMCUを筐体に組み込みたい。

追記：

取り敢えず MCU 基板の組み込みは出来た。



残るはスイッチ基板の実装だが、予め分離した状態で動作確認を行うべきだろう。

追記２：

テンポの設定が減数方向に行えないバグを解消した。



テンポを±して基準値から調整を行う場合に、エンコーダの急な増減を緩和する目的で取得したデータにBitShiftを行ってしまうとMSBの符号が無効になることを失念していた。

追記3：

テンポの増減を行った時にテンポがヨレる現象の原因となった 「ロータリーエンコーダの使用時に、LCD の表示にアクセスするサブルーチン」を廃止した。



attatchInterrupt を使用して、SMF Reader の処理を行えば解決しそうな問題だが、残念ながら PIT による駆動を失敗している。 外部からの信号（AudioClock 等）によるドライヴを行うべきなのかもしれない。

SolenoidBell@TopSwitchへの配線を完了する

SMF File の Play / Stop / Pause / Select の操作を行う Top Switch に接続するコネクタを MCU 基盤に取り付けた。

白/黒の配線は MCU の pin# 31/32 に、残りのピンは pin# 3/4/5/6 から引き出されている。　何れも Top Switch 関連の配線だが、実装がタイトなので分解時には細心の注意が求められる。



コネクタの 9/10 番ピンには、左側面に配置した Midi_In ポートへの配線（手前の丸ピンポートに接続された緑/青の配線）が行われている。



配線に余裕は無くかなりギチギチな状態なので、分解時にコネクタをリリースする順番を間違うと配線を引き千切ってしまう危険がある。　MCU 基板を引き出すには、まず最初に手前の白/黒 3 ピンと柿/黄/緑 x2 の 6 ピンコネクタの順に外す必要がある等、分解を行う時のステップを解説するマニュアルを書かなければならなくなった。　



残るはスイッチ基板との接続だが、これはハードルの高い作業になりそうだ。

追記：

後日、発色の様子に異常が見られた Led を接続した端子 GPIO 31 に、機能指定の重複を発見した。　　再度空き端子を確認した結果、 GPIO 32/38 に再指定を行っている。

SolenoidBell＠スイッチ類の配線を始める

懸念していた通り、スイッチ端子の接続部で断線していた配線を繋ぎ直した後、



有線リモコン用にリザーヴした 3,5φ/4p フォンジャックの配線を行った。



この部分はスペースに余裕があるので、i2c 系のような曲芸を行う必要はない。



残る配線は MCU とスイッチのブリッジだが、結線を行う前に GND ラインの取り扱いを詰めなければならない。

あと、プログラム上の不備を発見（端子 5/6 の出力設定を忘れていた）しているので、これも対処しなければならない。

LaVoixski@出力波形の記録

癖のない LPF12 を介した波形の記録。



先月から一連の更新を行っているが、LPF12 に変更はなかった。

SolenoidBell@引続きi2c周りの配線に手を焼く

問題となっているのは、FET スイッチ基板の i2c0 端子と



MidiOut 用の Mini-Din ジャックとの干渉で、



本来はあまり必要とは思っていなかった MidiOut を "MidiMarger" として設定した無理が祟ったということになる。



とはいえ、レガシーな通信環境への配慮は必要で、物理 MidiOut 端子の採用は出来れば切り捨てたくはない装備だ。　苦慮の末（現状で十分に酷いと言える）サービス性の悪化には目を瞑り、スイッチ基板の中心方向に向けて丸ピン端子をスラントさせる形で干渉を回避することになった。



フロントパネルに装備された i2c2 に信号ラインを引き出すため、新たなリボンケーブルを MCU 基板に追加した。



本来は WiFi からの受信を担当するポートではあるが、有線からの受信経路を並列化することに意義があると判断した。



残る作業は、MCU 周りの配線の追加で、プッシュスイッチ類と MCU の接続や、midi_in 端子の配線を行わなければならないが、寒さに負けて今日はここまで。

SolenoidBell@配線が予想以上に難航する

試作品故に生じている混乱とはいうものの、予想外のレベルで配線に手間取っている。

現在、i2c 関連の配線を行っているのだが、タイトな寸取りが仇となった配線の取回しに苦労している。　かといって単純に延長するわけにもいかない。　配線の長さや取り回しが送信するデータの品質に影響してしまうのが厄介なところだ。　この部分はメインの i2c0 で、内装するスイッチ基板に直結する。　

丸ピンコネクタの背後に伸びているリボンケーブルは、フロントパネルに配した USB-C 端子に接続されている。 SolenoidBell では USB-C ケーブルを i2c の信号の分配に流用しているが、i2c 規格の信号をデータラインのペアとGNDに 割当てている。

背後のポートには、USB_HOST に至るリボンケーブルが接続される。



サービス時に、i2c0 のみピンの配置が内装する FET スイッチ基板の規格に合わせて、グランド端子が 3pin の中央に配列されている点に注意しなければならない。



これはノイズ対策を末端の基板まで行った結果だが、外部供給のラインは USB-C 端子を流用しているために、直結する場合にはグランドピンの配置が 3pin の3番目となっている。 画像ではオレンジの配線がグランドで、赤が SDA、黄が SCL に接続されている。　

出力端子に直結する i2c1 の配列は、USB-C のポートに合わせてピンの並びを SDA/SCL/GND としている。



こちらは、USB_HOST 端子の配線で、フロントのパネルに直結される。



内部に配列した基板との干渉を避けるため、接続端子にはフラットなものを自作している。



i2c2 の配線は WiFi 通信を担当する ESP32/S3 に接続される。　i2c2 は midi 規格の信号を乗せる目的で配線をフロント基板の接続端子まで伸ばしているが、ノイズの影響を考慮するとこれは微妙な選択となる。

SolenoidBell＠midi送信回路の構成を間違う

今まで発覚しなかったのが謎だが、midi 送信回路周りに重大なミスを発見した。

本来は、接続先のフォトカプラを駆動するための電源を抵抗を介して midi 端子4番に接続しなければならないところを何故か抵抗をグランドに落としていて、これでは送信が行えない。



修正は簡単で、一旦抵抗を取り外して電源ラインに接続をやり直した。　



有線 midi の製作にあまり馴染みがなかったとはいえ（ほぼ Wireless 環境で済ませていた）考えられない失敗だ。

その後配線を開始しているが、基盤の配置がトリッキーになった結果として配線材の長さに余裕をもたせられないのは試作品故に生じた試練でもある。



この状況で、配線にあと 20mm の余裕を持たせられなかったセンスの無さを反省している。



I2C＃2 は ESP32/S3 に接続して Wireless 通信に対応するのだが、これの端子を引き出すかどうかで悩んでいる。



バックパネルを基盤で構成する設計故に配線が難しくなってしまうのだが、パネルの加工を考えるとこの方法がベストに思える。



明日は、I2C と補機類の配線を行う予定。