sudohayato
2017年11月17日 22時48分
お世話になっております。須藤と申します。
RS485アドオンモジュールを搭載したArmadillo-x1同士を接続し通信を行っているのですが
下記問題が発生しております。原因などわかりますでしょうか。
【確認環境】
通信周期：2msec
※CON8_25のPWM02_OUTから2msec周期でpwm信号を発信し、
CON8_24のGPIOに折り返して割り込みをひろっています
通信速度：4Mbps
使用ＨＷ：Armadillo-x1＋RS485アドオンモジュール ×２
【シーケンス】
Armadillo① Armadillo②
｜ ｜
｜epoll_waitで割り込みを検知 ｜
｜ ｜
｜24byteのwrite → ｜24byteのread
｜ ｜
｜52byteのread ← ｜52byteのwrite
｜ ｜
｜epoll_waitで割り込みを検知 ｜
｜以降繰り返し ｜以降繰り返し
｜： ｜：
Armadillo①側でのみ以下の問題が発生しているようです。
１．pwmからの割り込みをepoll_waitで監視しているが、
検知できない(遅れる)ことがある
selectを使用しても同様
※Armadillo②は単純にread/writeを繰り返しているだけ
２．RTSの制御信号がwriteが終わっているのにHighのまま、
writeをコールしているのにLowのままという状態に
なることがある
３．回線上のデータは想定通りのサイズが流れてきているが
readで取得すると回線上のデータよりも小さいサイズとなる
なお、/proc/imx-driverで送受信データを確認すると
ドライバとしてはデータをロストはしていないように見える
以上、よろしくお願いします。
コメント
sudohayato
溝渕さん
お世話になっております。須藤です。
コメントありがとうございます。
> 割り込みの遅れや、RTS制御信号の論理反転遅延についてはリアルタイムOSで
> はないLinuxを利用しているため、発生する可能性は考えられます。
>
> 特に、v3.14.x-at14より前のLinuxカーネルを利用している場合は、無線LANド
> ライバが長期間(実測でおよそ2ms程度)の割り込み禁止区間を作る可能性があ
> るためより顕著に出ます。
★カーネルはv3.14.x-at15を使用しております。
なお、下記パッチを適用することで上記課題について改善される
可能性があるかどうかなどの情報はお持ちでしょうか？
https://marc.info/?l=linux-serial&m=150005865213531&w=2
https://git.congatec.com/arm/imx6_kernel_3.14/commit/f3c7b8348d0528c111…
また、FIQの利用方法についてGPIOの割り込みFIQに登録して割り込み優先度をあげて
処理をしたいのですが、FIQの使用方法のサンプルソースなどはありますでしょうか？
参考にさせていただきたいと考えております。
> > ３．回線上のデータは想定通りのサイズが流れてきているが
> > readで取得すると回線上のデータよりも小さいサイズとなる
> > なお、/proc/imx-driverで送受信データを確認すると
> > ドライバとしてはデータをロストはしていないように見える
>
> アプリケーションに問題はありませんか?
>
> 問題が再現可能な最小限の処理を行うソースファイル等を見せてもらえると、
> アドバイスできるかもしれません。
★ソース開示が難しいため、別手段での提供とさせてください。
以上、よろしくお願いします。
at_mizo
溝渕です。
> ★カーネルはv3.14.x-at15を使用しております。
> なお、下記パッチを適用することで上記課題について改善される
> 可能性があるかどうかなどの情報はお持ちでしょうか？
> https://marc.info/?l=linux-serial&m=150005865213531&w=2
> https://git.congatec.com/arm/imx6_kernel_3.14/commit/f3c7b8348d0528c111…
不明です(試したことはありません)が、恐らく改善されないと推測します。
特に、RTS制御信号の論理反転遅延の主な原因は、RTS制御をプロセスコンテキ
ストで行っているためです。RTS制御をプロセスコンテキストで行なわなけれ
ばならない理由は、LinuxカーネルのRS485フレームワークに含まれる
delay_rts_[before|after]_sendを実装するためです。
delay_rts_[before|after]_sendを利用しないのであれば、(uartドライバをカ
スタマイズして)RTS制御を割り込みコンテキストで実行することにより遅延を
最小にできるかと思います。
> また、FIQの利用方法についてGPIOの割り込みFIQに登録して割り込み優先度をあげて
> 処理をしたいのですが、FIQの使用方法のサンプルソースなどはありますでしょうか？
> 参考にさせていただきたいと考えております。
すみませんが、私は把握しておりません。
sudohayato
shkoga
こんにちは。サムシングプレシャスの古賀と申します。
須藤さん：
> また、FIQの利用方法についてGPIOの割り込みFIQに登録して割り込み優先度をあげて
> 処理をしたいのですが、FIQの使用方法のサンプルソースなどはありますでしょうか？
> 参考にさせていただきたいと考えております。
i.MX 7 (Cortex-A7, GICv2) ではなく i.MX 6 (Cortex-A9, GICv1/PL390) ですが、NXP 社のフォーラムにある、以下のパッチが、とっかかりとして参考になるのではないかと思います：
https://community.nxp.com/docs/DOC-95578
https://community.nxp.com/thread/448188
これらのパッチのソースと、PL390 および Cortex-A9 & ARM-v7A のリファレンスマニュアルを照合しながら読み、そのうえで、GICv2 のリファレンスと PL390 のリファレンスを読み比べるというのが、他に情報がない場合のアプローチになるかと思います。
sudohayato
at_mizo
2017年11月20日 9時48分
溝渕です。
> １．pwmからの割り込みをepoll_waitで監視しているが、
> 検知できない(遅れる)ことがある
> selectを使用しても同様
> ※Armadillo②は単純にread/writeを繰り返しているだけ
>
> ２．RTSの制御信号がwriteが終わっているのにHighのまま、
> writeをコールしているのにLowのままという状態に
> なることがある
割り込みの遅れや、RTS制御信号の論理反転遅延についてはリアルタイムOSで
はないLinuxを利用しているため、発生する可能性は考えられます。
特に、v3.14.x-at14より前のLinuxカーネルを利用している場合は、無線LANド
ライバが長期間(実測でおよそ2ms程度)の割り込み禁止区間を作る可能性があ
るためより顕著に出ます。
> ３．回線上のデータは想定通りのサイズが流れてきているが
> readで取得すると回線上のデータよりも小さいサイズとなる
> なお、/proc/imx-driverで送受信データを確認すると
> ドライバとしてはデータをロストはしていないように見える
アプリケーションに問題はありませんか?
問題が再現可能な最小限の処理を行うソースファイル等を見せてもらえると、
アドバイスできるかもしれません。