ADC10のチャネル・スキャンで悩む [oscilogi32]
(2014.07.13)
Oscilogi32の開発をぼちぼち進めています。
”ActionPerformedイベントハンドラで設定したスクロールバーの位置が、Swingによって上書きされている”という見立ては、正しかったようです。50msインターバルでスクロール・バーの位置をコンソールに表示する機能を組み込んだところ、ActionPerformedイベントハンドラからメイン・ループに戻って暫くしてから（500ms以内）スクロール・バーの位置が書き換わる様子が観測されました。（Swingでは500msインターバルで表示をコントロールするタスクが走っている？）
他にも時折”TextAreaの表示が壊れる”という症状も現われているのですが、操作し直せば復旧するので、ペンディングにしています。RaspiのJAVAは色々問題を抱えているようです。
なんとかコマンド送受が出来るようになったので、いよいよ計測動作を試すことにしました。
CH0だけ動かしてみると・・・（ムフフ）動きました。
DMAによるADC1BUFの読み取りも良さそうです。
CH1に変えると・・・・（ムフフ）先ほどとは少し異なる値に変わり、こちらも期待した通りの結果になりました。
で、２チャネル動作に切り替えると・・・？！駄目です。CH0の計測結果しか記録されません。
ここから長いデバッグ作業が始まりました。
JAVA側の送信コマンドが正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
PIC側の受信コマンド処理が正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
PIC側のADC設定が正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
（実はここに問題があった）
PIC側のDMA設定が正しくないのか？
==> そもそもADC1BUFにCH1の計測結果が記録されないのだから、DMA以前の問題な筈
（しかし、DMA設定が大丈夫とも言えない）
ADC10のチャネル・スキャン機能を試したことはあるので、どこかに問題が潜んでいる筈です。
う～ん何処だ？
一頻り悩んで、ADC_SAMPLES_PER_INT_1をADC_SAMPLES_PER_INT_2に代えて見ると・・・
ビンゴ～！
チャネル・スキャンが動きました。
”2チャネルをスキャンしてAD変換ごとに割り込みを掛ければ、ADC1BUF0にはCH0の変換結果が、ADC1BUF8にはCH1の変換結果が入り、2CHのDMAを使ってデータを転送できる”と目論んだのです。
何故、変換終了ごとに割り込みを発生させると、入力チャネルのスキャンが止まってしまうのか？
理由は判りませんが、そういう仕様のようです。お陰で親族SNS管理人の目論見が破綻してしまいました。
選択肢は三つ。
（１）チャネル・スキャンは止め、プログラムで入力CHとキックするDMAを切り替える。
（２）プログラムで2CH分の変換結果を４バイトのバッファ領域に書き込み、DMA（1CH）をキックする。
（３）ADC_BUF_8をADC_BUF_16に代えて、DMA（2CH）をADC割り込みでキックする。
プログラム処理負担が最も軽い三番目の案（<==実は選択肢三つと書いてから思いついた）が良さそうです。ただし、次のAD変換が始まっているので、まごまごしているとADC1BUF0が書き換わってしまいます。そのあたりのタイミングがどうなのか？
う～ん、悩ましい！
---------------------------------------------
＜ご参考まで＞
使用しているADCの設定パラメータは以下の通りです
Oscilogi32の開発をぼちぼち進めています。
”ActionPerformedイベントハンドラで設定したスクロールバーの位置が、Swingによって上書きされている”という見立ては、正しかったようです。50msインターバルでスクロール・バーの位置をコンソールに表示する機能を組み込んだところ、ActionPerformedイベントハンドラからメイン・ループに戻って暫くしてから（500ms以内）スクロール・バーの位置が書き換わる様子が観測されました。（Swingでは500msインターバルで表示をコントロールするタスクが走っている？）
他にも時折”TextAreaの表示が壊れる”という症状も現われているのですが、操作し直せば復旧するので、ペンディングにしています。RaspiのJAVAは色々問題を抱えているようです。
なんとかコマンド送受が出来るようになったので、いよいよ計測動作を試すことにしました。
CH0だけ動かしてみると・・・（ムフフ）動きました。
DMAによるADC1BUFの読み取りも良さそうです。
CH1に変えると・・・・（ムフフ）先ほどとは少し異なる値に変わり、こちらも期待した通りの結果になりました。
で、２チャネル動作に切り替えると・・・？！駄目です。CH0の計測結果しか記録されません。
ここから長いデバッグ作業が始まりました。
JAVA側の送信コマンドが正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
PIC側の受信コマンド処理が正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
PIC側のADC設定が正しくないのか？
==> 不具合は見当たらない（しかし、大丈夫とも言えない）
（実はここに問題があった）
PIC側のDMA設定が正しくないのか？
==> そもそもADC1BUFにCH1の計測結果が記録されないのだから、DMA以前の問題な筈
（しかし、DMA設定が大丈夫とも言えない）
ADC10のチャネル・スキャン機能を試したことはあるので、どこかに問題が潜んでいる筈です。
う～ん何処だ？
一頻り悩んで、ADC_SAMPLES_PER_INT_1をADC_SAMPLES_PER_INT_2に代えて見ると・・・
ビンゴ～！
チャネル・スキャンが動きました。
”2チャネルをスキャンしてAD変換ごとに割り込みを掛ければ、ADC1BUF0にはCH0の変換結果が、ADC1BUF8にはCH1の変換結果が入り、2CHのDMAを使ってデータを転送できる”と目論んだのです。
何故、変換終了ごとに割り込みを発生させると、入力チャネルのスキャンが止まってしまうのか？
理由は判りませんが、そういう仕様のようです。お陰で親族SNS管理人の目論見が破綻してしまいました。
選択肢は三つ。
（１）チャネル・スキャンは止め、プログラムで入力CHとキックするDMAを切り替える。
（２）プログラムで2CH分の変換結果を４バイトのバッファ領域に書き込み、DMA（1CH）をキックする。
（３）ADC_BUF_8をADC_BUF_16に代えて、DMA（2CH）をADC割り込みでキックする。
プログラム処理負担が最も軽い三番目の案（<==実は選択肢三つと書いてから思いついた）が良さそうです。ただし、次のAD変換が始まっているので、まごまごしているとADC1BUF0が書き換わってしまいます。そのあたりのタイミングがどうなのか？
う～ん、悩ましい！
---------------------------------------------
＜ご参考まで＞
使用しているADCの設定パラメータは以下の通りです
#define PARAM1 ADC_FORMAT_INTG16 | ADC_CLK_TMR
| ADC_AUTO_SAMPLING_ON
#define PARAM2_SCAN_OFF ADC_VREF_AVDD_AVSS
| ADC_OFFSET_CAL_DISABLE | ADC_SCAN_OFF
| ADC_SAMPLES_PER_INT_1 | ADC_BUF_8
| ADC_ALT_INPUT_OFF
#define PARAM2_SCAN_ON ADC_VREF_AVDD_AVSS
| ADC_OFFSET_CAL_DISABLE | ADC_SCAN_ON
| ADC_SAMPLES_PER_INT_2 | ADC_BUF_8
| ADC_ALT_INPUT_OFF
#define PARAM3 ADC_CONV_CLK_PB | ADC_CONV_CLK_Tcy2
#define PARAM4 ENABLE_AN10_ANA | ENABLE_AN11_ANA
#define PARAM5_SCAN_OFF SKIP_SCAN_ALL
#define PARAM5_SCAN_ON ~(SKIP_SCAN_AN10 | SKIP_SCAN_AN11)
SCAN設定の場合
SetChanADC10( ADC_CH0_NEG_SAMPLEA_NVREF | ADC_CH0_POS_SAMPLEA_AN10 );
OpenADC10( PARAM1, PARAM2_SCAN_ON, PARAM3, PARAM4, PARAM5_SCAN_ON );
---------------------------------------------
 |
 |
 |
コメント 0