T4ライブラリ _process_tcpip 多重割込みについて

いつもお世話になっております。

T4ライブラリ _process_tcpip の呼び出しについて、

疑問点が湧いてきましたので、ご意見をお聞かせください。

現在RX65NへFreeRTOS + FITモジュールを使用してT4ライブラリを導入しています。

T4ライブラリの_process_tcpipについて呼び出し元を調査していたところ、

・CMT1(10ms周期) 割り込み コールバック

・EDMAC0 EINT0 割り込み コールバック  

の2ルートで呼び出されている様でした。

(意図して上記設定としています。)

気になったのは「EDMAC0 EINT0 割り込み コールバック」なのですが、

コールバックにより、t4_driver.cのlan_inthdrという関数が呼び出されいるのですが、

この関数内で多重割込みが許可されています。

T4ライブラリ内を確認すると、


void _process_tcpip(void)
{
~~~~
    if (_process_flag == 0)
    {
        _process_flag = 1;

~~~~~

        _process_flag = 0;
    }
~~~~
 
    return;
}

という実装になっていました。

この場合、


if (_process_flag == 0)
{            ⇐ここで他要因による割り込み
_process_flag = 1;


 1を書く前に多重割込みが入るとフラグが書換えられず、

他要因による_process_tcpipが走ってしまう可能性があります。

こちらが調査して分かりましたので、

現状CMT1の割り込み優先度をEDMAC0の割り込み優先度よりも低くすることで対策していますが、

このような認識で問題ないでしょうか?

(CMT1割り込みの場合は多重割込みが無効状態ですので、上記のような考慮は不要と考えています。)

またT4ライブラリの案内として、上記のような内容はありましたでしょうか。

(見落としていましたら、申し訳ありません。。。)

ご意見いただけますと、幸いでございます。

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

Parents
  • にゃあ少佐さん、こんにちは。NoMaYと申します。

    投稿されていた文面からの印象ですが、実際問題として、トラブルに遭遇されているのではありませんか?(ちなみに、第一印象としては、通常処理と割り込み処理の間の、および割り込み処理間での、排他制御を意図したであろう処理としては、このやり方は危険なやり方だと思います。PUSH PSW、DI ならびに POP PSW にて if (_process_flag == 0) { _process_flag = 1; をサンドイッチするのがセオリーのように思いました。もちろん、最終的な顛末として、そもそも排他制御は不要であった、という顛末の可能性もあります、とも思いますけれども。)

    あと、T4を使うのは(Amazon FreeRTOSプロジェクトでなく)単にFreeRTOSプロジェクトとRXスマートコンフィグレータの組み合わせではFreeRTOS+TCPというものがサポートされていないから、という理由だったりしませんでしょうか、、、

Reply
  • にゃあ少佐さん、こんにちは。NoMaYと申します。

    投稿されていた文面からの印象ですが、実際問題として、トラブルに遭遇されているのではありませんか?(ちなみに、第一印象としては、通常処理と割り込み処理の間の、および割り込み処理間での、排他制御を意図したであろう処理としては、このやり方は危険なやり方だと思います。PUSH PSW、DI ならびに POP PSW にて if (_process_flag == 0) { _process_flag = 1; をサンドイッチするのがセオリーのように思いました。もちろん、最終的な顛末として、そもそも排他制御は不要であった、という顛末の可能性もあります、とも思いますけれども。)

    あと、T4を使うのは(Amazon FreeRTOSプロジェクトでなく)単にFreeRTOSプロジェクトとRXスマートコンフィグレータの組み合わせではFreeRTOS+TCPというものがサポートされていないから、という理由だったりしませんでしょうか、、、

Children
No Data