100mHzサンプリング試験が無事終わった

(2016.09.30)
時間の掛かるOscilogi410の24時間連続計測試験ですが、不具合無く動いてくれればサクサク進みます。500mHzサンプリングと100mHzサンプリングの連続計試験が無事終了しました。100mHzサンプリングだと24時間で反復回数は４回ですが、まぁ十分なんじゃないかと思います。

500mHzサンプリング試験の最初の反復で新しい不具合が見つかりましたが、動作停止するような重大なバグではなく、対策もすぐ出来たので再試験の必要は無いと判断しました。これでデータ・ロガー関連のノウンバグに対する対策は全て完了しました。
パチパチパチ～

実は1mHzサンプリングの計測試験がまだ残っています。しかし、始めると23日掛かる試験なので、（いつかはヤルつもりですが）当面は実施を見合わせます。

いよいよ、Oscilogi410は懸案事項の改善に取り組みます。
（１）ログ・ファイルのフォーマット変更
（２）グリッドの見直し
（３）2ndカーソル導入
（４）Horizontalカーソルの導入<==やるかどうかまだ迷っている

何だか、とっても楽しみです！

Oscilogi410のプロセスを調べてみた

(2016.09.29)
Raspi上で走るOscilogi410のプロセスについて調べてみました。

$ ps －C java -o pid,ppid,psr
 PID PPID PSR
1952 1950 2

$ ps －C bcm2835_for_java -o pid,ppid,psr
 PID PPID PSR
1968 1952 3

bcm2835_for_javaの親はOsci_logi_Console.jarを実行しているjavaプロセスです。
二つのプロセスは走っているコアが異なるので、プロセス間のContext切り替えで問題を生じたという考え方は変な気がしてきました。

プロセス間のコーディネーション、砕いて言えばring_bufferのempty対策が不十分だったために起きた（<==それが全てでは無いとしても）不具合だったのではないか？と思い始めました。

ーーーーーーーーーーーーーーーーーーーー
そこに重点をおいた対策は既に施しました。
ーーーーーーーーーーーーーーーーーーーー
まぁ、動いているのだから良しとしましょう。

Oscilogi410の不具合対策で苦労した

(2016.09.28)
24時間連続計測試験について、『連続計測試験に失敗して・・・何とか対策を施して・・・』と記しましたが、”エラーで通信が途絶えたら、それを修復して計測試験を続行する”という対策でした。充電器の充放電試験を出来るだけ早く行いたいという事情を抱えて、苦肉の策でした。

少し余裕が出来たので、そもそも通信が途絶えてしまう原因は何なのか調べてみることにしました。

Oscilogi410は次の三つのプログラムで構成されています。
（１）Osci_Logi_Console（JAVA Swing）
（２）BCM2835_FOR_JAVA（C）
（３）Oscilogi2（XC32）

通信が途絶えてもOscilogi2の計測動作は継続していて、BCM2835_FOR_JAVAを再起動すると停止した通信が回復するので、Osci_Logi_ConsoleとBCM2835_FOR_JAVA間で問題が発生していることが推察されました。しかし、計測データとコマンドの送受を何千回も繰り返すことが出来るのですから、基本的な動作に問題は無く、ある特定条件下で回復出来ない不具合が発生していると考えました。つまり、どこか拙いタイミングでOsci_Logi_ConsoleとBCM2835_FOR_JAVA間のContext切り替えが生じているのではないか？ということです。しかし、その対策のために異なるプロセス間のContext切り替えを望むように操作することなんて出来るんでしょうか？

----------------------------------------------------------------
(2016.09.29)
そもそも、マルチコアのRaspi2Bや3BでContext切り替えというのは間違いです。
buffer-empty対策が抜けていただけだったのかも・・・----------------------------------------------------------------

対策その１
BCM2835_FOR_JAVAのnice値を+1してみる
対策その２
Osci_Logi_ConsoleとBCM2835_FOR_JAVAのContext切り替えを意識して行う
==>切り替わっても良いと考える所にusleep(5000)を入れてみる

この二つの対策で通信が途絶えることは無くなりました。残ったのはPICのデータ・ポインタが時折変な値を示すという不具合でした。どうやら一連の計測を終えて再計測を開始する辺りで、何かが起きているようです。

ここはPICkit3の出番です。データ・ポインタが異常値を示したときのOscilogi2の状態は・・・COMMAND_NULLになっています。これでデータポインタを読みだすと数値ではなく"NULL"という文字列が出力され、受け取った異常値（1314212940）と一致します。このとき受け取ったコマンド文字列は・・・”RCV 3”で正しく受信している。ということは・・・一旦設定されたCOMMAND_RCV_3が、その後でCOMMAND_NULLに書き換えられた？

ビンゴ～
一連の計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理が見つかりました。

データポインタを読みだす部分はこんなプログラムです。
i2c_write("RCV 3");
ope_sync();
idle_10ms();
i2c_read(buff,8);

”RCV 3”を出力してから、８バイトのデータを読み出すまでの僅かな時間に、偶々計測を終了してコマンド・ステータスをCOMMAND_NULLに書き換えていたという訳です。

計測終了時にコマンド・ステータスをCOMMAND_NULLにする処理は必要ないことが判ったので、これを削除して一連の不具合対策は

『これにて一件落着～』 チョン（<==拍子木の音です）

------------------------------------------------------------------------------

このブログを読んで、自分もやってみたいと思ったあなたへ
是非、組み込み系の世界に飛び込んで下さい。
マルチコアのぐちゃぐちゃしたデバッグ作業があなたを待っています。

うへ～と思ったあなたへ
その反応は正常です。組み込み系（特にマルチコア・プログラミング）には近づかない方が身のためです。

動作テストでOscilogiを壊した

(2016.09.25)
机の脇にPIC32MX250F128Bが二個転がっています。充電器の動作テスト中に交換したものです。Oscilogi410の信号入力端子に保護回路は付いていないので、０～３．３Vを越える電圧を掛けるとPICに異常電流が流れて壊れてしまいます。Oscilogi410に接続する箇所の電圧はチェックしてあったのですが・・・

充電器の動作テストは、こんな回路で行いました。OUT+とBAT+、IN-とOUT-は基板上で接続されていて、IN-とOscilogi410のGNDを接続しました。IN+とBAT+は3.3Vを超えるので、抵抗分割（半分に）した電圧を計測しました。それとBAT-とOUT-の間に入っている過放電保護回路の影響を見るため、BAT-端子を計測する（<==これが誤りだった）ことにしました。

充放電試験を１回行い、さらにもう一回行おうとしたところで異変に気付きました、コマンドの送受が行えなくなっています。調べてみるとPICが熱くなっていました。orz

どこかで（USB電源を接続する時とか？）3.3Vを超える電圧が発生したのでしょうか？
やむを得ずPICを交換して再試験に臨みました。試験前に計測箇所の電圧を再確認してから計測に臨みました。

充電試験・・・無事完了。放電試験・・・無事完了。えっ！
PICが熱くなっています。あっ！

ようやく気付きました。放電試験終了時に過放電保護回路が働いてBAT+端子の電圧が0Vに落ちます。するとBAT-端子は-3.5Vになるのです。その結果PICから異常電流が流れて・・・

という訳でBAT-端子の計測は止めて、３個目のPICで計測した結果がこれです。

充電試験の結果。グラフの縦軸は単位換算した電圧（V)で、横軸は時間（秒）です。

放電試験の結果。同じく縦軸は電圧（V)で横軸は時間(秒）です。

凡そ１Aの電流が4200秒流れていて、最後に過放電保護回路が作動してバッテリー電圧（BAT+端子）が0Vに落ちています。

充電完了時のBAT電圧は4.0Vで満充電には達しないようです。その結果、１A放電時の電池容量は1000mAhと、公称値の1/3程度しかありませんが（<==自分にはこれでも十分なので）、取りあえずO.K.です。

連続充放電試験の準備がもうすぐ整う

(2016.09.12)
（これ↓）の動作テストを行うため、Oscilogiにデータ・ロガー・モードを組み込みました。

https://www.amazon.co.jp/gp/product/B010FJTEFC/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

データ・ロガー・モードの24時間連続計測試験に失敗して暫くジタバタしましたが、何とか対策を施して24時間連続計測試験を終えました。Oscilogiはメモリの許す限り、何日でも計測を続けることが出来るようになったものと思います。

今日はDS18B20を使った温度計測機能を組み込みました。
この（↓）辺りの情報を参考にして、カーネル・モジュールで温度計測を行い、
http://blog.livedoor.jp/victory7com/archives/33399310.html
その結果をJAVAから読み取るという方法でOsco_Logi_Consoleに温度計測機能を組み込むことにしました。

秋月電子に注文した部品（5Wのセメント抵抗他）が届いたら、いよいよ充電器+18650の連続充放電試験です。

Oscilogiの連続計測試験に失敗した

(2016.09.07)
9月4日にOscilogiのknown bugが無くなり、反復計測機能の組み込みを終え、最終テストに臨みました。

データ・ロガー・モードで反復計測します。データが一杯になったら計測値をファイルに書き出し、再びロガー・モードで計測を続けると言う動作を延々と繰り返します。２４時間以上連続計測出来れば、最終テストに合格！ということだったんですが・・・

凡そ１時間ほど経過したところでOsci_logi_Console（JAVAプログラム）がダウンしました。orz

一体何が起きたのでしょう？

計測プログラムのあちこちにデバッグ文を書き込んで、動作を追いかけました。

そして、読み取る計測データのサイズがi2c_readの最大サイズ（1024バイト）を超える場合があることが判りました。データ・ロガー・モードでは高々数１０バイトだったので、受信データ・サイズのチェックを入れていませんでした。
（将来的にはbcmlib_for_javaの方でチェックする予定です）

取りあえず、受信データ・サイズを1024バイト以下にして、再度連続計測試験に臨んだのですが・・・

今度は計測コマンドの送信でI2Cエラーを起こして止まりました。orz

読み取る計測データのサイズ異常の原因は何か？
I2Cエラーの原因は何か？

さらに、詳細なデータを取るためにデバッグ文を追加して、テストに挑みます。

12時からテストを始めて、1時間経過しました。今の所、ログ・ファイルには異常は記録されていません。

さて、このあとどうなるのか？

ドキドキ

---------------------------------------------------------

追記（2016.09.07）

14時前に、データ受信でI2Cエラーを起こして止まりました。
I2Cエラーを起こしたときにI2Cをリスタートする機能を組み込んで試験を再開します。
ただ今の記録は1時間52分です。

Oscilogiのデータ・ロガー・モードが動き出した

(2016.08.30)
読み取りデータを指定するコマンドに読み取り開始位置を追加して、部分データの読み取りはすんなり実現しました。

一画面分のデータ表示が毎秒１回可能（Raspi2Bで700mS掛かる）ということが判ったので、部分データの表示は止めて従来の表示のままで行く（画面左端から全部書き直す）ことにしました。

データ・バッファが一杯になった後も計測を継続して、データ・バッファを上書きする部分（従来のOscilogiには無かった処理）で、暫く手こずりましたがなんとか不具合箇所を見つけました。

1mHzサンプリングだと4CH計測でも２０日を超える計測が可能になります。
充電器とバッテリーの動作テストには十分な機能が実現したんですが・・・

自分が必要としている最低限の機能が実現すると、急速に開発マインドが低下していくのを感じます。（^_^;）

しかし今回は、何とか完成を目指して開発を続けようと思います。
良い加減Oscilogi410の開発はお仕舞いにして、Oscilogi1616（既に基板はできている）、Oscilogi32EF（10MSPSに挑む）に取りかからなければなりません。

敢えてこの場で宣言して、自分を追い込む作戦です。￥（＾_＾）