Armadilloフォーラム

カーネルモードでのUART制御

sudohayato

2017年2月16日 21時25分

お世話になっております。須藤です。

Armadillo-420を使用しており、下記の書き込みを参考に、
デバイスドライバ内からUART5の制御をしたいと考えております。

 http://lists.atmark-techno.com/pipermail/armadillo/2005-August/000435.h…

上記の書き込みのように"/etc/passwd"に対してオープンした場合は正常に読み取れますが、
"/dev/ttymxc4"に対してオープンした場合はfilp->f_op->readの結果が-512となり処理が停止してしまいます。

デバイスドライバ内からUART制御(別ドライバを制御)するにはどうしたらよろしいでしょうか?
なお、オシロスコープでArmadillo側までデータが届いていることは確認しています。

以上、よろしくお願いいたします。

コメント

お世話になっております。須藤です。

本件、いまだ解決せずに継続調査中です。
気になった点がありましたら何でも良いのでアドバイスいただけたらと思います。

下記URLにあるサンプルを動かし、コンソール(/dev/ttymxc1)からデータを受け取り
read/writeができることは確認しました。
 http://wiki.bit-hive.com/north/pg/kernel_read%B4%D8%BF%F4

シリアル(/dev/ttymxc4)に対しても同様に操作ができると思っておりますが
相変わらずfilp->f_op->readの結果が-512となり処理が停止してしまいます。
#上記URLのサンプルを動かし、openの対象を”/dev/ttymxc1”から”/dev/ttymxc4”に
 変更すると動かなくなってしまいます

フロー制御が影響している可能性があるのではとも思っております。

以上、よろしくお願いいたします。

カーネルの中でやる人は少ないので、情報は中々出てこないかもしれませんね。
ちなみに、なぜカーネルの中でやる必要があるのでしょうか?外ではだめですか?

-512 は -ERESTARTSYS です。 n_tty.cn_tty_read() とかにある ERESTARTSYS でしょうか?

ご返信ありがとうございます。須藤です。

ユーザ空間では、GPIOからの割り込みをトリガーにしてUART5に対してread/writeをしていたのですが、
処理速度が期待通りに出ていなかったためカーネル空間でのread/writeを試みている状況です。

ユーザ空間でGPIOの割り込みをひろった場合、動き出しまでに800μs以上かかっているように見えます。

性能は割り込み受信後、30μs程度で動き出すことを期待しています。

以上。よろしくお願いいたします。

> ユーザ空間では、GPIOからの割り込みをトリガーにしてUART5に対してread/writeをしていたのですが、
> 処理速度が期待通りに出ていなかったためカーネル空間でのread/writeを試みている状況です。

なるほど。
その例でいえば、アプリがスケジュールされるまでに時間がかかるということでしょうか。
たしかに割り込みハンドラーの中でやってしまえば早いですが、システムの他の部分に
しわ寄せが出ることが多いです。

> ユーザ空間でGPIOの割り込みをひろった場合、動き出しまでに800μs以上かかっているように見えます。

GPIO に割り込みが入ったあと、プロセスがその割り込みで blocking wait しているのであれば、すぐに
schedule されそうなものです。他にも色々動いている状態でしょうか?
当該プロセスのプライオリティはどうしていますか?

もしよければ、どのように 800 usec の計測をしているか教えて頂けますか?

> その例でいえば、アプリがスケジュールされるまでに時間がかかるということでしょうか。
ご認識の通りと考えておりますが、該当アプリ以外には意図的に何も動かしていない状況です。
ちなみに割り込み処理は下記URLの図8.1「GPIO sysfs 割り込みサンプルプログラム」を
参考にして作成しています。
http://manual.atmark-techno.com/armadillo-4x0/armadillo-400_series_soft…

> GPIO に割り込みが入ったあと、プロセスがその割り込みで blocking wait しているのであれば、すぐに
> schedule されそうなものです。他にも色々動いている状態でしょうか?
topコマンドの結果を添付いたしますのでご確認いただければと思います。

> 当該プロセスのプライオリティはどうしていますか?
sched_priorityを99に設定してる状態での性能となっています。

> もしよければ、どのように 800 usec の計測をしているか教えて頂けますか?
割り込み(pwmの折り返しをGPIOで検知)発生から、Txピンから波形が出力され始めるまでを
オシロスコープで計測しています。

以上、よろしくお願いいたします。

ファイル ファイルの説明
top.txt

> ちなみに割り込み処理は下記URLの図8.1「GPIO sysfs 割り込みサンプルプログラム」を
> 参考にして作成しています。

poll() から戻ってきて直ぐに、計測できる状態にしているということですよね?

> > GPIO に割り込みが入ったあと、プロセスがその割り込みで blocking wait しているのであれば、すぐに
> > schedule されそうなものです。他にも色々動いている状態でしょうか?
> topコマンドの結果を添付いたしますのでご確認いただければと思います。

たしかに無いですね。
test が 20% 以上も CPU を使っていますが、これは意図した動きですか?
自分のプロセスの Thread とぶつかっていたりはしませんか?

> > 当該プロセスのプライオリティはどうしていますか?
> sched_priorityを99に設定してる状態での性能となっています。

ということは、SCHED_FIFO か SCHED_RR になっているということですよね?

> > もしよければ、どのように 800 usec の計測をしているか教えて頂けますか?
> 割り込み(pwmの折り返しをGPIOで検知)発生から、Txピンから波形が出力され始めるまでを
> オシロスコープで計測しています。

Tx から出るのが遅かったりしますか? (そんな事ないですよね...)

例えば、CPU で GPIO をパタパタすると、どれくらいで変化します?
次に、GPIO の割り込みを待ってから、他の GPIOを動かすとどれくらいかかります?
上記の差分が、アプリの割り込み反応速度だと思うのですが、これが遅い場合、
他の方法を考えないといけないです。

お世話になっております。須藤です。

早急に回答いただいていたにもかかわらず返信が遅くなり申し訳ありません。
コメントいたします(★部)。

> poll() から戻ってきて直ぐに、計測できる状態にしているということですよね?
★はい。そうです。

> test が 20% 以上も CPU を使っていますが、これは意図した動きですか?
> 自分のプロセスの Thread とぶつかっていたりはしませんか?
★CPU使用率は想定内の動きです。
 意図的に作成したスレッドはいないのでぶつかっていることは考えにくいです。。。

> > > 当該プロセスのプライオリティはどうしていますか?
> > sched_priorityを99に設定してる状態での性能となっています。
>
> ということは、SCHED_FIFO か SCHED_RR になっているということですよね?
★はい。そうです。

> 例えば、CPU で GPIO をパタパタすると、どれくらいで変化します?
> 次に、GPIO の割り込みを待ってから、他の GPIOを動かすとどれくらいかかります?
> 上記の差分が、アプリの割り込み反応速度だと思うのですが、これが遅い場合、
> 他の方法を考えないといけないです。
★こちらについては時間のあるときに調べてみます。
 別件で確認したい事項がありますので別途フォーラムに投稿させていただきます。

以上、よろしくお願いいたします。