2019年12月26日木曜日

アプリのテストをどうするか

こんにちは

ソフトな道をほのぼのと今日も歩きます。


linux アプリを作る上でテストをどうしていこうかと考えてみました。


そのメモ書きになります。


[結論]

  1. testディレクトリを作成する。

  2. “#define TEST”をhファイルに作る。

  3. test処理、呼び出し処理を”#ifdef TEST”でくくる。


[環境]

私の使用環境は VMware 上でUbuntu14.04を使用して、

ビルド環境は gcc(arm-linux-gnueabihf-gcc)です。


アプリのディレクトリ構成は、アプリトップディレクトリの直下に下記のディレクトリがある構成です。


bios(cソース格納用)、include(hファイル格納用)、lib(ライブラリファイル格納用)


まず、ここにtestディレクトリを作りました。


このtestディレクトリ内に”test_main.c”を追加しました。


次にincludeディレクトリにtest.hを追加します。


biosディレクトリにあるmain.cに呼び出し元を追加します。


makeファイルをごりごり変えてビルドを通るようにしました。


例えば以下のようなソースを作りました。


<div style="padding: 10px; margin-bottom: 10px; border: 1px dotted #333333;">

    

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

[main.c]

void main(void)

{

・・・

#ifdef TEST   

    TEST_main();

#endif

・・・

}


[test.h]

#define TEST

void TEST_main(void);


[test.c]

#ifdef TEST

void TEST_main(void)

{

    TEST_test();

}

#endif

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



</div>

こうしておけば、#define TESTをコメントアウトするだけで、

テストコード全体がビルドされなくなり、

テストしたい時だけ復活させることができるので、

容量的にもこの方法で試していこうと思います。


他に良い方法あったら教えてくれませんか。

2019年12月18日水曜日

Uart通信のデータ抜けの問題

こんにちは

linuxアプリ作成における注意点が見つかったのでメモします。

Uart通信のデータ抜けの話です。

---

linuxアプリケーション内で、UART通信の処理を行っているのですが、

対抗機からデータを受信し続けていると、データが抜けてしまうことがありました。

色々調べてみたところ、/dev/ttySxをopen、closeを何度も行っていると

現象が発生するようです。

デバッグして最終的に、

staticでファイルディスクリプタを保持してからは、

closeしないようにしたところ、データの抜けは発生しなくなりました。

現象から考えると、closeってことは、通信自体マスクされているってことなのか。。

以下、必要なところだけ載せます。

#include <termios.h>

#define SERIAL_PORT "/dev/ttyS0"

#define BAUDRATE    B9600


static int Serial_Port_Fd= 0;


void main(void)

{

    unsigned long length;

    char buff[0x1000];

    unsigned long maxsize;

    int rtc= 0;

   

    Init();

   

    while(1)

    {

        rtc= UART_Receive(&length, buff, sizeof(buff));

    }

}


int Init( void )

{

    struct termios tio;

    int ret;

    int size;

    // バッファ関連クリア

    memset(&tio, 0, sizeof(tio));

    Serial_Port_Fd= open(SERIAL_PORT, O_RDWR| O_NOCTTY);

  ・・・

    return NORMALEND;

}



int UART_Receive(ULONG *length_p, BYTE *data_p, ULONG maxsize)

{

    int i;

    int len;

   

    while(1)

    {

       len = read(Serial_Port_Fd, data_p, maxsize);

        if (0 < len) {

            for(i = 0; i < len; i++) {

                printf("%02X ",*(data_p+ i));

            }

            printf("len: %d \n",len);

            printf("\n");

            break;

        }

    }

    *length_p= len;

    return 0;

}



2019年12月12日木曜日

デバッガによるミドルウェア再起動について

こんにちは、


組み込み系Linux アプリをデバッグしている時、


ブレークポイントからpassステップ(ステップオーバというものもあります。)すると、


突然アプリ先頭(main())から始まるような動きになりました。


何かやらかしたか?


考えられた事は以下でした。


  1. ウォッチドッグによって再起動

  2. メモリ破壊により再起動

  3. その他。何か


“1.””2.”を調査しようと、main()文の先頭で無限ループさせるようにしてみました。


以下のようなイメージです。

main()

{

    printf("(main.c %d) \n", __LINE__);

    while(1);

}


期待していたのは、printf(“”)に記載していた内容が多量に出てくることです。

実際には1回だけでてきました。


あれっ、と思いデバッガでwhile(1);をパスステップを何度かやってみました。


すると、main()の先頭から始まりました。


ターミナル上に、何やら文字が


“BUG: soft lockup - CPU#0 stuck for 28s! “


調べてみたところ、


“CONFIG_LOCKUP_DETECTOR=n”にすればよいとのことです。


検索系コマンドで何処で定義しているのかを調べてみます。


“$ sudo grep -ir CONFIG_LOCKUP_DETECTOR .”


組み込み用linuxだと、カーネルディレクトリのトップに”.config”ファイルがあり、

そこに記載されているようです。


上記の記述に変更することにより、パスステップしても本現象にならなくなりました。