Linuxでシリアル送信ができない

Question

行いたいこと

Linux(Debian)から外部デバイスに対してシリアル通信を行いたくプログラムを記載しています。
言語はCで、Linux側のシリアルは/dev/ttyS0として認識しています。

症状

外部デバイスに対して"TC\r\n"を送信すると、時刻情報が戻ってくるはずなのですが、どうもシリアル送信できていないようなのです。
なお外部デバイスからデータを手動で送ってもらうと、なぜか受信はできており、送信だけができない状態のようなのです。なお受信確認は別なプログラムで、無限ループの中、readを行っているだけのものです。

確認済み事項

• /dev/ttyS0アクセスに対する権限付与
• ユーザのdialoutグループへの追加
• minicomからの送受信（成功）

ソース（異常処理等割愛）

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <termios.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>

#define SERIAL_PORT "/dev/ttyS0"  // シリアルインターフェースに対応するデバイスファイル
#define BAUD_RATE   B9600			    // RS232C通信ボーレート

int main(int argc, char *argv[])
{
    char rBuf[255] = {'\0'}, sBuf[255] = {'\0'};        // バッファ
    int fd, i, len;
    struct termios tio;               // シリアル通信設定

    fd = open(SERIAL_PORT, O_RDWR);   // デバイスをオープンする
    tio.c_cflag += CREAD;             // 受信有効
    tio.c_cflag += CLOCAL;            // ローカルライン（モデム制御なし）
    tio.c_cflag += CS8;               // データビット:8bit
    tio.c_cflag += 0;                 // ストップビット:1bit
    tio.c_cflag += 0;                 // パリティ:None
    tio.c_cc[VMIN] = 0;
    tio.c_cc[VTIME] = 30;
    // ボーレートの設定
    cfsetispeed(&tio,BAUD_RATE);
    cfsetospeed(&tio,BAUD_RATE);
    ioctl(fd, TCSETS, &tio);           // ポートの設定を有効にする
    strcpy(sBuf,"TC\r\n");
    write(fd, sBuf, 4);                // デバイスへ書き込み
    printf("%s\n", sBuf);
    len = read(fd, rBuf, sizeof(rBuf));   // デバイスから255バイト読み込み
    if (0 < len) {
        for(i = 0; i < len; i++) {
          printf("%s", rBuf[i]);
        }
        printf("\n");
    }
    close(fd);                        // デバイスのクローズ
    return 0;
}

ご教授、賜れましたら幸いです。

Answer 1

少なくとも明らかにひとつコードに問題があって、

    struct termios tio;               // シリアル通信設定

    fd = open(SERIAL_PORT, O_RDWR);   // デバイスをオープンする
    tio.c_cflag += CREAD;             // 受信有効
    tio.c_cflag += CLOCAL;            // ローカルライン（モデム制御なし）
...

とある部分で、struct termios tio;と宣言されただけで、中はゴミのまま、メンバー変数に CREAD等をセットしています。これだとゴミのビットパターンがセットされたままになり、不適切な設定がされてしまう可能性が高いです。memsetなり宣言時の初期化なりで、あらかじめ0クリアしてください。

また、write()などのシステムコール実行時は返り値のチェックと、エラーであればerrnoをチェックしてください。
もし書き込みでBUSY状態のようなことになっていれば、selectで書き込み可となるまで待機した方が良いかと思われます。

あと気になったこととしては、+=でビットパターンをセットしている部分で、ビットパターンを扱う上では良い書き方ではありません。セット(ON)するときは|= 値 、OFFにするときは&= ~値としましょう。(今回の問題のケースに直接関係は無いと思いますが）

Comments

[cafe_takai]

dodox86様

ご回答、ありがとうございます。ご指摘に従い、次の通り追記してみました。

memset(&tio,0,sizeof(tio)); // 初期化

j = write(fd, sBuf, 4); // デバイスへ書き込み
printf("%d, errno=%d: %s\n", j, errno, strerror(errno));

結果としてですが症状としては変わらず、jには4が入り、errno=0: Successの状態でシリアルから電文は送られていないようです。

[dodox86]

minicomでは送受信成功とのことですが、minicomで送信した内容が、デバイス側で正しく受信できている、との意味ですよね。デバイスではなく、対抗のPCの端末にして受信させてみたり、シリアルのクロスケーブルで自PCに折り返して確認したりはできないでしょうか。

[dodox86]

デバイス側が結果としてどう動くか、と言うより、デバイス側（受信側）でどのようなデータを受信できているか（できていないか）を確認するのが先決だと思います。

[dodox86]

連投すみません。もしかしたらデバイスへのwriteでの送信はちゃんと成功していて、デバイス側は受信できているものの、readが早すぎてデバイス側からのレスポンスを受信する前に終わっちゃっているということはありませんでしょうか。9,600bpsは結構遅いです。readの前に少しwaitを入れてみてください。まぁ、readでブロックしているのであればwaitで待機の必要は無いですが。

[dodox86]

readで返り値が0なら恐らくブロックしてないでシステムコールからすぐ戻っているので、readの呼び出しが早すぎといえます。
もうひとつコードの問題を指摘させていただきますと、printf("%s", rBuf[i]);　の部分がバグです。SIGSEGVで落ちると思います。

[cafe_takai]

dodox86様
早速のご回答、ありがとうございます。minicomについては改行コード(\r\n)の都合、本来の電文ではなく、何かしらの送受信はできているとの確認までで、電文内容まで確認できておりません。
ご教授いただいた通り、相手側デバイスをPCに変え、minicomやWindowsのTeraTermなどを使用して、電文がきちんと送受信できてるか、まず確認してみます。
最後に言い訳がましくて恐縮ですが、実機が遠隔にあり、直ぐにご返答できないのですが、色々とご指導賜り、感謝申し上げます。ありがとうございます。

[cafe_takai]

再度のアドバイス、ありがとうございます。
waitを入れ、printf("%s", rBuf[i]);　→　printf("%2X", rBuf[i]);　に変更したうえでチャレンジしてみます。

[dodox86]

> 実機が遠隔にあり、直ぐにご返答できない

いえいえ、今分かる限り、と言うのは仕方無いです。連投したのはこちらの勝手ですのでお気になさらないでください。

> printf("%2X", rBuf[i]);　に変更したうえでチャレンジしてみます。

おそらく当初の意図としてはprintf("%c", rBuf[i])かな、と思いましたが、"%2X"でも良いと思います。（こちらの方が確実）

[cafe_takai]

昨晩、確認させていただきました（私自身ではないのですが…）。結果、次の通りです。
① 送信側はWin10(ホストOS)+VirtualBox(Vagrant)でのLinux（Debian）。
② 相手デバイスから送信するとminicom/自作PGとも受信できるが、共に送信できていない。
　→ minicomから送信可と申しましたが不可のようでした。失礼いたしました。
③ ホスト側をRaspberryPIに変更したところ送受信できるようになった。
　→ プログラムの変更はありません。
アドバイスいただきました通り、プログラムを疑う前に実機にて動作確認が先でした。真の原因究明までには至っておりませんが、プログラムとしてはご指導いただいた内容で問題ありませんでした。
お騒がせし申し訳ありませんことと、適切なアドバイス頂戴しましたこと感謝申し上げます。