y.nakamura
2025年1月18日 23時42分
久々にお世話になります。中村です。
Armadillo-IoTゲートウェイ A6E(以下"A6E")のRS-485インターフェースの
送受信切換え時間について質問です。
RS-485で接続してデータのやり取りを行う機器(以下"相手機器")の仕様で、
相手機器がリクエストを受け取った後に応答データを送信するまでの時間が
数マイクロ秒と規定されています。
相手機器の仕様書では"N±0.2[usec](typ)"(実際にはNは具体的な１桁の整数)の
ようにきっちり時間が記載されていますが、ここでは「数マイクロ秒」とします。
これにより、A6Eがリクエストコマンドを送信したあと、
この時間（数マイクロ秒）以内に受信できる状態にならなければなりません。
A6EのRS-485の送受信切換えは、この要求を満たすことができますか？
送受切換えの時間の「数マイクロ秒」というのは、A6Eが送信したリクエストの
最後のストップビットの終端エッジから、相手機器が送信する応答データの
スタートビットの開始エッジまでの時間です。
（図で示せばもっとわかりやすいのですが、文字だけでスミマセン）
次の過去記事と、そこに記載があるドライバのパッチ(リンク先)は見ました。
[Armadillo IoT A6Eを使用したRS-485シリアル通信の送受信間隔について]
https://armadillo.atmark-techno.com/forum/armadillo/19573
また最新のA6Eのカーネルソース(linux-at-a6-5.10.232-r0.tar)の
imx.cの該当箇所や周辺コードも読みました。
私の考えでは、数マイクロ秒という短い時間で送受切換えをするのは
無理なのではないかと思っています。
最新カーネルでは上の過去記事のパッチが適用されていないようですが、
それを適用しても、ドライバのプログラムの構造から、「数マイクロ秒」は
無理なのではないかと。。。
よろしくお願いいたします。
--
なかむら
コメント
y.nakamura
中村です。
溝渕さん、
いろいろ説明などをいただき、どうもありがとうございます。
> 上記に関しては、以下のパッチを適用することで改善方向には向かうと思います。
> https://wiki.linuxfoundation.org/realtime/preempt_rt_versions
またこれも、ありがとうございます。
顧客に対して「私は無理だと思う」だけでは説得力がないので、
アットマークテクノ様の見解が欲しく、今回の投稿になりました。
> ただ、先に述べましたように、私も数マイクロ秒以内での切換えを100%保証する事は厳しいかと思います。
お客様に「無理です」と連絡することにします。
今回の質問投稿よりも前にお客様に「A6Eに限らず、すべてのArmadilloで、
さらには、ArmadilloでなくてもLinuxを使っているボードマイコンで、
Armadilloと同様のハードウェア構成のものは全部無理だろう」、
「何か専用の装置(今回の要件を満たせるRS-485変換器など)を
使うしかないのではないか」、というような内容を伝えていました。
最初の私の投稿で
>> ... ドライバのプログラムの構造から、「数マイクロ秒」は
>> 無理なのではないかと。。。
と書きましたが、これは、LinuxがRTOSではないこともありますが、
それだけではなく、ドライバの
> 4. kernelでtx complete割り込み発生時にRS-485を受信状態に変更
の処理が重く（いろいろなことをやっているので）、
割り込み発生から送受切替までに時間がかかりすぎるということです。
ソースimx.cを見ると、割り込みハンドラのimx_uart_int()で、
割り込み処理に必要なすべてのレジスタを読み込んで、
いろいろ前処理をしてから割り込み要因の判定と分岐をしています。
今回のTXDC(送信完了/シフターが空になった)割り込みでは、
imx_uart_int()
=> imx_uart_transmit_buffer()
=> imx_uart_stop_tx()
という流れでimx_uart_stop_tx()の中で送受切替をしています。
この一連の処理だけで数マイクロ秒を消費してしまうような気がします。
（最近のマイコンの処理速度がどのくらいなのかよくわかってませんが）
他に有用な情報がなければ、本件はこれでクローズとしたいと思います。
どうもありがとうございました。
--
なかむら
y.nakamura
中村です。
それほど重要なことではないですが、先ほどの私の投稿で説明不足がありました。
> 今回のTXDC(送信完了/シフターが空になった)割り込みでは、
> imx_uart_int()
> => imx_uart_transmit_buffer()
> => imx_uart_stop_tx()
> という流れでimx_uart_stop_tx()の中で送受切替をしています。
この流れは、delay_rts_after_send=0で、かつ、
delay_rts_after_send=0のときの不具合パッチ
https://github.com/nxp-imx/linux-imx/commit/582e9a24fc139adabb1dc951620…
を当てた場合です。
--
なかむら
at_mizo
溝渕です。
結論としては変わりありませんが、CPUの処理能力について少しだけ、
Armadillo-IoT A6Eに搭載されているi.MX 6ULLのCPUであるCortex-A7のクロックは528MHzです。
RAMアクセスやキャッシュのヒット率にもよるので、当然このクロックの通りとはなりませんが、理想的には1命令当り時間は1/528(0.001893939)usです。
また、Transmitter complete割り込み(uartのshift registerの最後のbitを出力後に入る割り込み)発生後の処理は次のようになり、
Transmitter complete割り込み発生
=> imx_uart_int() //いくつかのレジスタ値のチェックしかしない
=> imx_uart_transmit_buffer() //開始直後のuart_circ_empty()で次に進む
=> imx_uart_stop_tx() //いくつかのレジスタ値の後A6EのRS-485を送受状態に切換え
多く見積もっても数100命令は無いかなという所感です。
なので、この処理だけを行うのであれば数usオーダーで十分かと感じています。
ただ、先述べましたように行儀の悪い(interrupt contextを長時間抜けない等)ドライバが無い事を全てに於て検証できておりませんし、割り込み禁止区間を行時間取るドライバが存在しない事も証明できない現状です。
以上より、どのような環境下に於ても100% 数usオーダーで処理を完了する事を保証できませんが、特定環境下では(たまたまですが)期待通り動作するという事も考えられなくはないかと思います。
私の感想を含む内容なので正確性に乏しい面もありますが、ご参考になりましたら幸いです。
y.nakamura
中村です。
溝渕さん、処理数や速度などについて、
どうもありがとうございます。
> 多く見積もっても数100命令は無いかなという所感です。
命令数にするとそんなもんですかね。
> なので、この処理だけを行うのであれば数usオーダーで十分かと感じています。
数マイクロ秒かかる、という時点で、今回はアウトです。
もう10年くらい前になりますがArmadilloのG2で、
GPIO割り込みで割り込み要因(入力パルスエッジ)からハンドラに
処理が届くまでの時間を実機で計測したことがあります。
ハンドラ入り口にデバッグ用GPIOポートへの出力を追加する方法で、
GPIO入力信号とデバッグ用のGPIO出力信号をオシロで見ました。
このときの実験の計測では数10マイクロ秒もかかっていて
（ハンドラでのGPIO出力処理の時間も含みますが）
「割り込みの反応は遅いなぁ」なんて思っていました。
割り込みハンドラでの命令実行時間だけではなく、
ハードウェア的な応答時間も影響があると思うのですけど、
（他の優先順位が高い割り込みが処理中とか割り込み禁止されている時間があるとか、
そういうことは考えずに、自分だけしかいない、という前提で）
こういう情報はプロセッサのデータシートに記載があるものなのでしょうか？
> 私の感想を含む内容なので正確性に乏しい面もありますが、ご参考になりましたら幸いです。
クローズ宣言後にも関わらず、ありがとうございます。
--
なかむら
at_mizo
溝渕です。
> 数マイクロ秒かかる、という時点で、今回はアウトです。
了解です。もし弊社製品で実現するとしたら、big.LITTLE構成のCPUが搭載された以下を利用して、
https://armadillo.atmark-techno.com/armadillo-x2
https://armadillo.atmark-techno.com/armadillo-x1
https://armadillo.atmark-techno.com/armadillo-iot-a9e
LITTLE(Cortex-M)でベアメタルまたはreal-time OSを動作させる事が必要になるかと思います。
ただ、ソフトウェアの開発が必要になるので工数がネックになりますよね。
> もう10年くらい前になりますがArmadilloのG2で、
> GPIO割り込みで割り込み要因(入力パルスエッジ)からハンドラに
> 処理が届くまでの時間を実機で計測したことがあります。
> ハンドラ入り口にデバッグ用GPIOポートへの出力を追加する方法で、
> GPIO入力信号とデバッグ用のGPIO出力信号をオシロで見ました。
> このときの実験の計測では数10マイクロ秒もかかっていて
> （ハンドラでのGPIO出力処理の時間も含みますが）
> 「割り込みの反応は遅いなぁ」なんて思っていました。
>
> 割り込みハンドラでの命令実行時間だけではなく、
> ハードウェア的な応答時間も影響があると思うのですけど、
> （他の優先順位が高い割り込みが処理中とか割り込み禁止されている時間があるとか、
> そういうことは考えずに、自分だけしかいない、という前提で）
> こういう情報はプロセッサのデータシートに記載があるものなのでしょうか？
以下のように、ARMから公表されているようです。(Cortex-A7については見つけられませんでした...。すみません...。)
https://developer.arm.com/documentation/101550/0001/Memory-system/Real-…
また、ARMの反応以上に、割り込みの応答については他の要因が支配的になるかと思います。以下のようなベージを見つけました。
https://www.jblopen.com/arm-cortex-a-interrupt-latency/
at_mizo
溝渕です。
こちらで動作実績がありませんので案だけで恐縮ですが、FIQ(Fast Interrupt Request)を利用できれば、Linux上でも要件を満たせる可能性があります。
https://bootlin.com/blog/fiq-handlers-in-the-arm-linux-kernel/
上記記事、そもそもi.MX28向けのものですので実現可否さえも不明なので、アイディアとしてお受け取りください。
y.nakamura
溝渕さん、
中村です。
> こちらで動作実績がありませんので案だけで恐縮ですが、FIQ(Fast Interrupt Request)を利用できれば、Linux上でも要件を満たせる可能性があります。
> https://bootlin.com/blog/fiq-handlers-in-the-arm-linux-kernel/
>
> 上記記事、そもそもi.MX28向けのものですので実現可否さえも不明なので、アイディアとしてお受け取りください。
FIQというものの存在すら知りませんでした。
タイマハンドラで50kHzの矩形波をこれだけ綺麗に生成できるとは、すごいです。
今回のRS485の接続相手機器のこととは切り離して、
こういうのもある、という知識として頭に入れておくことにします。
--
なかむら
y.nakamura
溝渕さん、
中村です。
短時間で（私の投稿からわずか30分）で、
有用な情報をたくさん、ありがとうございます。
> https://armadillo.atmark-techno.com/armadillo-iot-a9e
> LITTLE(Cortex-M)でベアメタルまたはreal-time OSを動作させる事が必要になるかと思います。
これ(↓の動画)の14:00あたりからの説明のところですよね。
[Armadillo新製品発表会 2024 [2024.10.16 開催]]
https://www.youtube.com/watch?v=NuHDEruhdmA
A9EはA6Eの後継機という位置付けでもあるようですので、
これも気にはしております。
> ただ、ソフトウェアの開発が必要になるので工数がネックになりますよね。
はい、そのとおり！
> 以下のように、ARMから公表されているようです。(Cortex-A7については見つけられませんでした...。すみません...。)
> https://developer.arm.com/documentation/101550/0001/Memory-system/Real-…
>
> また、ARMの反応以上に、割り込みの応答については他の要因が支配的になるかと思います。以下のようなベージを見つけました。
> https://www.jblopen.com/arm-cortex-a-interrupt-latency/
Chromeブラウザの日本語翻訳を使ってざっと読んでみました。
勉強になります。ありがとうございます。
--
なかむら
at_mizo
溝渕です。
> これ(↓の動画)の14:00あたりからの説明のところですよね。
そうです。
> [Armadillo新製品発表会 2024 [2024.10.16 開催]]
> https://www.youtube.com/watch?v=NuHDEruhdmA
ご覧くださったのですね。ありがとうございます。
> > ただ、ソフトウェアの開発が必要になるので工数がネックになりますよね。
>
> はい、そのとおり！
ほぼそのまま利用できる状態を期待されていると思いますので、恐らくFIQの利用も厳しいかと思いますが、(すごく昔のものですが)サンプル実装を見つけたので展開いたします。
y.nakamura
中村です。
> ほぼそのまま利用できる状態を期待されていると思いますので、恐らくFIQの利用も厳しいかと思いますが、(すごく昔のものですが)サンプル実装を見つけたので展開いたします。
>
> https://github.com/benavrhm/mxs-auart-fiq
ありがとうございます。
--
なかむら
at_mizo
2025年1月20日 9時35分
溝渕です。
> これにより、A6Eがリクエストコマンドを送信したあと、
> この時間（数マイクロ秒）以内に受信できる状態にならなければなりません。
>
> A6EのRS-485の送受信切換えは、この要求を満たすことができますか？
:(省略)
> 私の考えでは、数マイクロ秒という短い時間で送受切換えをするのは
> 無理なのではないかと思っています。
私も数マイクロ秒以内での切換えを100%保証する事は厳しいと思っています。
まず、LinuxはリアルタイムOS(時間制約を保証可能なOS)ではありません。
ただ、リアルタイムOSでない事実はありますが、RS-485の送受信切換えに関しては十分効率的に実装されている事も事実です。おおまかなシーケンスは次の通りです。
1. userlandから送信要求
2. kernelでRS-485を送信状態にしてdma送信要求
3. kernelでdma完了割り込みのcallbackでuartのtx complete割り込みを有効化
4. kernelでtx complete割り込み発生時にRS-485を受信状態に変更
と、kernel内で実行される状態遷移のきっかけとなるのはハードウェア割り込みであり、最もイベントに対する応答が早い実装になっています。
ただ、他の割り込み処理に時間がかかる事も考えられますし、割り込み禁止区間を作っているドライバもあります。恐らくそれら1つ1つを検証するのは困難かと思います。
上記に関しては、以下のパッチを適用することで改善方向には向かうと思います。
https://wiki.linuxfoundation.org/realtime/preempt_rt_versions
ただ、先に述べましたように、私も数マイクロ秒以内での切換えを100%保証する事は厳しいかと思います。