denshikobo’s blog

PICプログラミングやPCの操作で感じた日々の由無し事を綴ります

Oscilogiの新たな課題に取り組むことにした

(2016.08.25)
Oscilogiの開発は『自分が必要となった機能を実現する』という方針で進めてきました。

今やりたいのは、(これ↓)の動作テストです。
https://www.amazon.co.jp/gp/product/B010FJTEFC/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

充電器とバッテリー電圧をモニタしながら、18650リチウムバッテリーを充放電させて、その挙動を調べる計画です。Oscilogiにデータ・ロガー モードを設けて、数時間に及ぶ連続計測を行えるようにしようと考えました。

計測時間の設定単位にmHz(現状はHzとkHzの二つ)を加えれば、データ・ロガーになると簡単に考えていたのですが・・・

Osci_Logi_Console(JAVAプログラム)に設定単位を追加するのは簡単な作業でした。
PICの計測は1秒単位に行い、メモリに格納するときにデータを間引くという方法で、長時間の計測を実現しました。動かして初めて大きな問題に気付きました。

Oscilogiは計測データをPICに蓄え、計測終了時にそれをOsci_Logi_Consoleが読み取って、グラフ表示しています。つまり計測終了までデータ表示は行いません。計測時間が短ければ、何も問題なかったのですが、数時間に及ぶ計測の場合、途中経過が判らないということでは困ります。

そこで、計測中にOsci_Logi_Consoleがデータを読み取ってグラフ表示する機能を組み込むことにしました。

開発手順はこんな感じです
(1)データ・ロガー・モード設定ボタン追加
(2)データ・ロガー計測中のI2Cコマンド送受
(3)DMAポインタの読み取り
(4)計測途中に部分データ読み取り
(5)部分データの表示

『設定ボタン追加』といっても、サンプリング・レートが20Hz以上では無効にするとか、細かなロジックの組み込みが必要です。(3)まで済んで、いよいよ計測中のデータ読み取りと部分データの表示に取り組みます。

何か、とっても楽しい~

 

Oscilogiの大きな課題が解決した

(2016.08.21)
そこそこ動いて、それなりに使えているOscilogi410なんですが、実は大きな課題を抱えていました。

bcmlib_for_javaは1回に送受できるデータ量に1024バイトの制限があります。Oscilogi410の計測データは(オシロとロジアナ合わせて)24kバイトなので、24回に分けて計測データを取り込んでいます。

しかし、1024バイトのデータ読み出しに対して、何故か『PIC側のポインタが1025進んでしまう』という現象を生じていました。やむを得ず、1024バイト読み取る度にOsci_logi_Console(JAVAプログラム)からPICのポインタを一つ戻すコマンドを送って、不具合を回避する処置を講じていたのです。何が悪いのか判らず、少しだけBCM2835ライブラリを疑ったりしていました(ゴメン Mike )。

動き出したOscilogi410を使って、I2Cの動作を調べてみることにしました。
テスト・プログラムはこんな感じです。

(データ受信コマンドを送り、10バイト読み出す)
public class I2c_test {
    public static void main(String args) {
        String send_string = "RCV 0";
        byte
receive_buff = new byte[16];
        
        bcm2835.bi_init(args[0]);
        bcm2835.i2c_begin();
        bcm2835.i2c_setSlaveAddress( (byte)0x31 );
        bcm2835.i2c_set_baudrate( 100000 );
        bcm2835.ope_sync();
        byte ret = bcm2835.i2c_write( send_string, send_string.length() );
        ret = bcm2835.i2c_read( receive_buff, 10 );
        if( ret == 0 )try {
         String rec;
           rec = new String( receive_buff , "UTF-8");
            System.out.print("I2C receive="+rec +"\n");
        } catch (UnsupportedEncodingException ex) {
            Logger.getLogger(I2c.class.getName()).log(Level.SEVERE, null, ex);
            rec = "";
        }
        System.out.print("i2c_read ="+(int)ret+"\n");
        bcm2835.i2c_end();
        bcm2835.bi_close();
    }
}

計測したI2Cの信号は正しく、5バイト送信し10バイト受信する様子を示していました。
つまりBCM2835ライブラリは正しく動作しているのです。(疑ってゴメン Mike )

自分で書いたPIC側のI2Cドライバの動作をdebug_dumpで調べ・・・

 void __ISR(_I2C_2_VECTOR, ipl1AUTO) _IntHandlerDrvI2CInstance0(void)
{
    static unsigned char i2c_single_buff;
    if( !PLIB_I2C_SlaveReadIsRequested(I2C_ID_2) )
    {
       if( PLIB_I2C_SlaveAddressIsDetected(I2C_ID_2) )
       {
         DRV_I2C0_SetUpByteRead();
         DRV_I2C0_ByteRead();
       }
       else
       {
         DRV_I2C0_SetUpByteRead();
          i2c_single_buff = DRV_I2C0_ByteRead();
          if( i2c_single_buff == 'B')
          {
              break_flag = FLAG_ON;
          }
          put_receive_buff(i2c_single_buff);
       }
       status_from_master();
    }
    else if ( PLIB_I2C_SlaveAddressIsDetected(I2C_ID_2) )
    {
        DRV_I2C0_SetUpByteRead();
        DRV_I2C0_ByteRead();
        DRV_I2C0_ByteWrite( get_send_data() );
        PLIB_I2C_SlaveClockRelease(I2C_ID_2);
        status_to_master();
    }
    else
    {
        if( I2C2STATbits.ACKSTAT == 0 )<==これを追加した
        {
          DRV_I2C0_ByteWrite(get_send_data());
          PLIB_I2C_SlaveClockRelease(I2C_ID_2);
          status_to_master();
        }
    }
    PLIB_INT_SourceFlagClear(INT_ID_0, INT_SOURCE_I2C_2_SLAVE);
    PLIB_INT_SourceFlagClear(INT_ID_0, INT_SOURCE_I2C_2_ERROR);
}

1バイト送信した後のI2C割込で、I2C2STATbits.ACKSTATが1になったときは次のデータは読み出さない、という処理に替えてようやくデータポインタが一つ余計に進んでしまうという課題が解決しました。

やれやれ

Oscilogi on Raspi3問題が解決した

(2016.08.16)
Mike McCauleyから”bcm2835_i2c_setClockDivider(uint16_t divider) 関数を使え”と言われ困っていました。つまり、core_freqの値に合わせてClockDivederの値を替えるしかない、ということです。

そのcore_freqのdefault値がRaspi2では250MHz、Raspi3では400MHzというのが今回の不具合の原因です。

--------------------------------
BCM2835ライブラリはcore_freq=250MHzを基準にbaudrateを設定している。400/250=1.6なので、Raspi2でbaudrate=100kHzのClockDivider設定を行うとRaspi3では1.6倍の160kHzになってしまう。
--------------------------------

core_freqの値さえ判れば何とかなりそうなのですが、その値がどこに記されているのか、調べた限りでは見つかりませんでした。

その代わり、動作しているRaspiのModelが/proc/device-tree/modelに記されていることがわかりました。
cat /proc/device-tree/model
Raspi2B==>Raspberry Pi 2 Model B Rev. 1.1
Raspi3B==>Raspberry Pi 3 Model B Rev. 1.2

これを読み取って、core_freqの値を推定して、ClockDivider設定を行う・・・
なんてことを考えたのですが、もっと簡単な方法が見つかりました。

Raspi3Bの/boot/config.txtに”core_freq=250”を追記します。

この設定が他にどのような影響を与えるか判りませんが、OscilogiはI2Cで問題を起こさず、Raspi3上で動作するようになりました。

まずは、目出度し目出度し

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

追記

core_freqの値を調べる方法が判りました。

vcgencmd measure_clock core

これです。

measure_clockって、どうやって計っているんだろう?

他にもこんなパラメータが指定出来るらしい

arm h264 isp v3d uart pwm emmc pixel vec hdmi dpi

 

Mike McCauleyから返事が来た

(2016.08.15)
i2c_set_baudrate関数の件でBCM2835のGoogleグループ(ここです)に質問を投げてみました。(spelling errorは毎度のことなので諦めています)

するとMike McCauley(BCM2835ライブラリの作者)から返事が・・・
Hi,
still unable to investigate this since my scope failed.
A few more days until new one arrives.

Mike McCauley

どうやら彼のオシロスコープが壊れているようです。

『私のOscilogi410を提供できなくて残念』と返しておきました。

少しは彼の役に立てると良いなぁ~

Raspi-3でオシロジが動いた(その2)

(2016.08.11)
Raspi-3でオシロジが動かなかった原因が判明しました。

Raspi2BのオシロジでRaspi3のSDAとSCLをモニタして、baudrateがおかしい(100kHzの設定に対して160kHzで動作している)ことに気付きました。PIC32mxのbaudrateを100kHzに設定しているので、SCLが160kHzでは正しく送受できなかったものと推察されます。

sudo cat /sys/momdule/i2c_bcm2708/baudrateを調べたところ

(2016.08.15 誤り訂正)

sudo cat /sys/module/i2c_bcm2708/parameters/baudrateを調べたところ
Raspi2 ==>100000
Raspi3 ==>0 ????

Raspi2は正しい値(100kHz)を示しますが、Raspi3は何故か0です。

 /boot/config.txtにdtparam=i2c_arm_baudrate=50000を追記しても
Raspi2==>50000
Raspi3==>0 !!!!

やっぱり、Raspi3は0です。

Osci_logi_console(JAVAプログラム)で使っているi2c_set_baudrate関数の引数を100000から50000に変更してみると・・・
ビンゴ~

Raspi2BのOscilogiでモニタしているSCLが80kHzになりました。
そしてようやく、Raspi3でオシロジが動きました。

f:id:denshikobo:20160811152724p:plain

パチパチパチ~

JAVAからbcm2835ライブラリを呼び出しているのですが、bcm2835ライブラリのi2c_set_baudrate関数がRaspi2とRaspi3のクロックレートの違いを上手く吸収できていないために生じた不具合のようです。

/boot/config.txtでI2Cのbaudrateが設定出来ない件は、当面ペンディングにします。

気になるのは、むき出しの状態でvcgencmd measure_tempの指示値が70℃を超えていることです。Raspi3でオシロジを使うためにはcooling fanが必要かもしれません。

 

Raspi-3でオシロジが動いた

(2016.08.03)
暫く前にRaspi-3を入手したのですが、Osci_logi_consoleプログラムが動いてくれません。そのまま暫くお蔵入りしていたのですが、今日は、それを調べてみました。

『コマンド送信は正常動作している(<==ように見える)のに、データ受信が何故出来ない?』
『Raspiの動作が速くなって、読み取りタイミングに問題が生じた?』

しかし、気になっていた箇所に手を加えても状況は全く変わりません。orz

Oscilogi410(PIC32MX250搭載基板)に問題無いことは確認出来たので、Raspi-3に何が問題がある筈・・・

結論から言うと「Raspi-configでI2Cをenableにする」で解決しました。

Raspi-2ではBCM2385ライブラリによるI2C操作でカーネル・ライブラリ(I2Cモジュール)を有効にする必要はありませんでした。その辺りの事情がRaspi-3では異なっていたようです。

 

これでOsci_logi_console(JAVAプログラムj)の開発がサクサク進む?
-------------------------------------------------------------------------

(2016.08.04)

どうやら勘違いだったようです、また動かなくなりました。orz

動いたり、動かなくなったり・・・

挙げ句にi2cdetectの様子もおかしくなりました。Raspi_3のCPU温度を計ると58.0℃です。CPU本体は大丈夫なのですが、ペリフェラルが(I2C)が駄目みたいです。
さて、困った。Raspi-3にOscilogi410を取り付けるのは無理?

 

ヘッダピンの取り付けを間違えた

シングルインラインヘッダピンの取り付けを間違えた。

しかも60pin以上。orz

 

電動式の半田吸い取り機があれば修復も容易なのだが、高価なもの(3万円くらい)なのでなかなか手が出ない。

 

そんな折りにネットでこんなものを見つけた。

www.monotaro.com

初代はんだシュッ太郎(HSK-100)から数えて3代目。
サンハヤトも苦労しているようだが、そろそろ買い時?

 

お、こちらの方が安い!

www.marutsu.co.jp