Darkside(https対応しました)

2021年11月26日(金) 21:30

時分割してる?

 I2Cのクロック100KHzの場合、大雑把に1バイトをアクセスするのに0.1ミリ秒を要する。
 dsPIC では1軸しか読まないので、0.5ミリ秒で読める。この0.5ミリ秒の開始でGPIOをHにし、終了するとLにする。Jetson Nano ではGPIOがLの期間に傾斜センサーを読む。しかしそうすると、読み始めたとたんに dsPIC の読み取りが始まってしまう可能性もある。それを避けるには、まずHになるのを待ち、それがLに変化する瞬間を待てば確実である。だが、それでは待ち時間が無駄である。
 Jetson Nano でも読み出しに2ミリ秒は要しないので、dsPIC は3ミリ秒先行させてGPIOをHにする。

TO_PIN23_SetHigh();
__delay_ms(3);
signed long x = ADXL355_readAcc(ADXL355_ADR_X);
TO_PIN23_SetLow();

という感じだ。Jetson Nano では、とにかくピン23がLだったら傾斜センサーを読み始める。23番ピンは GPIO18 なので、仕込みをする。管理者権限で、

cd /sys/class/gpio
echo 18 > export

これで謎のファイル /sys/class/gpio/gpio18/value が出現する。このファイルを読めば、GPIOの状態が文字列の "0" と "1" として取得できるという謎の実装になっている。たかがGPIOのアクセスに擬似ファイルを使っているせいで、恐ろしく遅い。

 そこで、少しでも高速アクセスすべく、傾斜センサー読み取りルーチンの先頭でGPIOをチェックするようにする。遅い中でも、やはりC言語によるアクセスが断然速いことは、以前確認済みだ。

 こうして dsPIC と Jetson Nano による時分割I2Cアクセスを試すと、それなりに動作する。

 カメラ映像は、時々乱れるが乱れは少なく、実用可能。
 dsPIC の方も、ほぼまっとうに値を拾っている。

 しかし、Jetson Nano 側では時々I2Cのエラーを検出しているし、dsPIC 側も時々WDTに引っ掛かってリセットが掛かっている。
 dsPIC のソフトウェアI2Cはタイムアウト検出していないため、I2Cバスの衝突などで状態が狂って無限ループに入ると、WDTでリセットが掛かる。また、そもそも受信機 dsPIC は処理が重く、更新頻度は秒間10回ぐらいしかない。つまり、時分割しなくても衝突頻度は低いはずなのだ。

 要するに、Jetson Nano 側がGPIOを読めておらず、時分割が機能していないのではないか?という疑いが出ている。

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