Darkside(https対応しました)

2021年11月27日(土) 22:07

全く実用にならない

 Jetson Nano のC言語プログラムが、まっとうに GPIO を読めているのかどうか確認する。
 23番ピンよりもカメラ切り替えに使っている19番ピンの方が、試験には便利。そこで、21番ピンもついでに有効化する。
 gpio16 と gpio17 を有効にし、/sys/class/gpio を確認。すると、gpio16 と gpio17 は確かに存在するが、昨日作成した gpio18 がない。え!もしかしてリセットしたら消えるの!?

 だとすれば、gpio18 が読めなくなったのも当然だ。

 そこで、再度 gpio18 を作成し、すぐにカメラ表示プログラムを動かす。すると、明らかにエラー頻度が激減した。しかし、反応も鈍い。コンマ数秒のループに入ってしまっている。dsPIC 側も、反応が悪くなっている。
 とは言え、恐らく基本戦略は成立しそうだ。ここから改良しよう。

 python だと圧倒的に遅いとは言え、0.1ミリ秒のオーダーでポーリングできるはず。それならば、十分に処理速度は間に合う。
 GPIO の初期化も python 任せにすれば楽だし、C言語の方ではチェックせず python のメインルーチンでチェックするようにしてみよう。
 やってみると、なかなか調子が良い。時々エラーは出るが、エラーが出た時は値を利用しない、という程度の処理で実用上は問題がない。dsPIC 側でもリセットは発生するが、これなら dsPIC 側でタイムアウトを検出するよう修正すれば合格だろう。

 さっそくタイムアウトを検出しようとして、間違いに気付いた。マスター専用であるソフトウェアI2Cでは、タイムアウトという概念がない。送り出すクロックに従って機械的に読み書きしているだけで、決まった時間で必ず処理は完了する。無限ループに入るような可能性は、どこにも存在しないのだ。
 ならば、なぜリセットが掛かるのだ?
 WDTに引っ掛かっている訳ではないのか?

 WDTが実は有効になっていない、というのを疑ってMCCを確認すると、設定1秒で有効になっている。

 何が問題なのか、分からない。そこで、I2C同期信号のマージンを3ミリ秒から5ミリ秒に増やし、挙動が変化するかどうか試してみる。その結果は、何も変わらない。
 Jetson Nano でのI2Cエラー発生頻度も、dsPIC のリセットも、何ら改善されない。液晶表示の乱れからも、I2Cバスが干渉しているのは明白。時分割は一定の効果があるものの、干渉を完全には防げていない。それでも実用的ならまだいいが、dsPIC が何十秒も沈黙を続ける場合もある。
 WDTが効いてくれずに、何十秒も受信不能に陥るのだ。dsPIC は受信機やってるので、止まると送受信できなくなる。

 現状では、全く実用にならない。

written by higashino [Sタンク 1/16] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

Comments

TrackBacks

Darkside(https対応しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4