Teensy4.1のSPIについて

どうもTeensy4.1のSPIには個体差があるようで、特定の個体でMCUのクロックを最高周波数に設定した場合に、液晶の表示が正常に行われなくなる現象を確認した。



試しに、液晶の表示が不安定な個体にLCDの動作チェックを行うプログラムを走らせてテストを行ったところ、



MCUのクロックを最高周波数・1008MHzに設定した場合にSPIの動作が追いつけなくなり、データの取り零しが発生することが判明した。

引き続き実験を行った結果、動作が保証されるのはクロックスピードが912MHzまでで、



それ以上のスピードに設定すると、SPIがデータを拾いきれなくなった。



一方、クロックを下げた場合に問題となってくるのは音声信号の処理速度で、こちらの動作が不安定になるようでは本末転倒である。

そこで、試しに健全なMCUでクロックスピードを912MHzまで下げてテストを行ったところ、4ch全ての音声に問題が発生しないことが確認できた。

また、音声ラインから特定のモードを選択した時に発生していたポップ・ノイズが消滅したことから、MCUを1008MHzで駆動していた時に音声関連のデータにも取り零しが発生していたことが判った。

今後は、外れなMCUの動作マージンを見越して、912MHzで運用を行うことになる。

Teensyduino1.54について

久々に更新されたTeensyduino1.54をインストールしたところ、SD関連のライブラリに変更があり、コンパイルが通らなくなった。



該当するファイルのパスを取り除くことで、コンパイルが通るようになったが、削除されたファイルを追加して対応することも可能だった。



一方、遅れている各パート（GPT/PWM/LCD）の稼働試験用に専用のスケッチを書いたものの、LCDとPWMで駆動するRGB_LEDの色味を指定している変数がコンフリクトを起こしてしまった。

コンフリクトを回避するためには、PWMの振幅設定とLCDの色味設定を行う変数のうち、どちらかの名称を変更する必要があるのだが、今回は書き換えに手間が掛からないライブラリ側に変更を行うことにした。



名称を書き換える箇所はArduino_GFX関連のライブラリのうち３ファイルで、色味を設定する変数の末尾に”２”を追加している。





あくまで暫定的な処置ではあるが、コンパイルは通っている。　次は、外部にデバイスを繋いで試験を行っていく。

Teensy4.1にPSRAMを実装する

基板の裏側にあるランドに容量8MBのPSRAMを2個取り付け、チェック用のプログラムを走らせた。





無事16MBを認識している。　これで広大なバッファー領域を確保することが出来た。

GPT2_IRQの扱いに関して

チャンネルが分離されていたFLEXPWMとは違って、GPT関連のIRQはフラグが統合されているようだ。



InputCapture1/2のフラグはランダムなタイミングで発生するため、チャンネル毎に制御信号を分離した方が安全そうなのだが、条件分岐によって判定を行うポイントを設定する場所が問題になりそうだ。

例えば、ひとまず統合されたIRQをそのままサブルーチンに投げる方法と、、、



フラグの条件でIRQが発動した際の分岐先を決定する方法とでは、キャプチャの挙動が変わってくる可能性がある。



GPT系ではイニシャライズからタイマの起動、オーバーフロー、タイマの停止を統一して行うことになるが、



タイマ停止時にはGPIOの属性をALT1からALT5に変更し、InputCaptureに設定した端子を開放している。



キャプチャ・イベントが発生したタイミングでカウンタの値をレジスタに記録し、



値を読み込んだ後に、キャプチャ・フラグのクリアを行う。サブルーチン内でインターラプトの介入をを禁止することで、処理の混乱を回避している。

カウンタの読み出しは、InputCapture1/2 個別のタイミングで行っている。



本来はプライオリティーが設定されたIRQが分離されているGPT1/2を並列に運用するのが筋なのだが、ボードから端子が取り出せないためにGPT2のみの運用で妥協せざるを得ない。　

無理をすれば、ボード裏にあるPSRAMのCSからGPT1のInputCaptureを取り出せるが、



これは最後の手段と考えている。

32bitフルスケールをカウントする時間は7秒程度で、この間にOverFloorによるエラーが１回発生する。



テルミン用のFVCは、パルスのアッパーエッジのタイミングで取得したカウント値の差分を検出するために、実際に取得した値の実効値を調整する必要がある。Teensy3.6で構成した16bit精度のFVCから得られるデータの実効値は14bit程で、ピッチの制御に用いるには微妙な数値だ。　

32bit精度のカウンタからはより柔軟に実効域を切り取ることが出来るので、データエラーによって発生するバウンシング現象を防止できるかもしれない。

死亡したTeensyを復活させる方法

USBによる接続が不可能となったTeensyを復活させる方法を見つけたので備忘録を書いておく。

原因は定かではないが、一種のシャックリのようなものと思えば良いらしく、接続が絶たれただけでMCU自体は死亡していないようだ。

対処法はMAC系のプラットフォームを使用する場合が簡単なようだ。　まずはArduinoを起動して、なんでも良いからスケッチのコンパイルを行い、Teensyの書き込みソフトを起動する。　次に、故障したMCUのリセットボタンを押しながらUSB端子を接続すると、あら不思議、何故かデバイスの認識が行われ始める。

これで、死んだと思って放置していたTeensy3.5と3.6の2個ずつ、計4つのデバイスを復活できた。　ここで断捨離をやらかしていたらこの発見はなかったわけで、とにかくゴミと思われるものであってもある程度は保持する必要があるのだな、、、と痛感させられた次第。

TeensyでWDTを試す

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

https://bigdanzblog.wordpress.com/2017/10/27/watch-dog-timer-wdt-for-teensy-3-1-and-3-2/

Teensy3.6の修理を行う

開発中の短絡事故でオンボードの電源ICが破損したTeensy3.6の修理を行った。　

パワーソースを接続しても反応がなく、パソコンとの通信も行えない。　オンボードの電源ラインには正常な電圧が供給されておらず、電源ICの破損が疑わしい。　



まず、破壊が予想される該当部品を撤去した後、ボードにピギーバックさせる形にユニバーサル基板を敷設し、そこに1117系の電源ICを取り付けた。



改修後はパソコンからのデータアップロードが正常に行えるようになった。　入出力端子が死亡している可能性は残るが、とりあえず基幹部は正常に動作している模様。