FreeRTOSのconfigTICK_RATE_HZに1001以上を設定した場合の、USB Host Mass Storage Class(r_usb_hmsc)の動作について

こんにちは、B.Ishiiと申します。

以下の事象について、質問があります。

■現象
FreeRTOSで、FITモジュールのUSB Host Mass Storage Class(r_usb_hmsc)を利用していますが、configTICK_RATE_HZに10000を設定したところ、USBメモリを操作できなくなりました。

■解析
以下のportTICK_PERIOD_MSマクロが0になってしまい、ゼロ除算など、意図しない計算結果を引き起こしているようです。

■対策
以下のソース変更をしたところ、私が利用しているUSB機能部分については、動作するようになりました。


※左は変更後、右は変更前

■質問
※ここまで長々とすみません。

上記は、制限事項か不具合かのどちらなんでしょう?
制限事項の場合、将来的に対策される(制限から外れる)予定などありますでしょうか?

※コミュニティではなく、ルネサスの中の人に聞いたほうが良いですかね。
※portTICK_PERIOD_MSは、他のFITモジュールでも使われています。
 configTICK_RATE_HZが1001以上の場合は、上記同様、意図しない動作が起きそうです。

■環境
・RX72N
・FreeRTOS(with IoT Libraries)
 Ver. afr-v202012.00-rx-1.0.1
・USB basic(low-level) driver(r_usb_basic)
 Ver. 1.40
・USB Host Mass Storage Class(r_usb_hmsc)
 Ver. 1.31

Parents
  • B.Ishiiさん

    こんにちは、シェルティと申します。ルネサスの中の人です。

    私は、AmazonがFreeRTOSを買収した際に、NoMaYさんとタッグを組み、RXマイコンにFreeRTOS(ネットワーク機能込み)を移植し、ルネサスがFreeRTOSに深くかかわるトリガを引いた人です。NoMaYさんはコミュニティのメンバなので他のコミュニティのメンバとざっくばらんな会話をいただき、シェルティは会社の看板を背負ってしまっているので書き込みたい内容も限られてしまうけれどできるだけ公式見解を述べる、というような感じです。

    件のFreeRTOSのtimetickですがデフォルトの1msでソフトウェアの評価をしていて他の条件ではテストを基本的にはしていないので動作しない場合もあるかと思います。1msのtimetickはリアルタイムOSとして「ちょうどよい」timetickとして設定しています。多くのマイコンシステムの処理は1ms周期で処理してやれば良いだろうとの考えですね。一方で組み込み機器の場合は1msよりも速い周期で制御が必要なセンシティブな部品(すごく速い周期でセンシングするセンサーや、すごく速い周期で制御が必要なモーターなど)をマイコンに取り付ける場合もあると思いますが、こういった場合は、ITRON用語だと「OS管理外割込み」としてOSに割りこむ形で1ms以下の周期・イベント処理が必要な処理を実行するのがセオリーと考えます。こういった処理が割りこんでくると当然OSの周期処理開始がちょっとだけ遅くなったりしますが、そもそもが1ms周期で動いているものなのでusオーダですこしズレたくらいで問題は大きくならないだろう(問題になる場合はOS管理外として速やかに処理できるようシステムを組むべし)という考えです。

    FreeRTOSの割込み周りについては以下記事が参考になるかもしれません。https://qiita.com/azuki_bar/items/7f31eb80e8b6b2eff17f

    以上です

  • B.Ishiiさん

    こんにちはシェルティです。

    ↑の書き込みはジェネリックなもので「timetickは1ms固定にすべし」という回答です。

    この上で、B.Ishiiさんが実装したい処理を頭に入れて再考してみました。たぶん、以下をポーリングではなく割込み駆動(OS管理割込みとして扱う)にすればよいかと思います。

    >>(3-3)は、UART送受信と同じタスクで、TaskDelay(1 /* tick */)しては、起きたらデータが届いてないか周期監視しています。

    UARTで受信があるとRX72NのSCIが1バイト受信毎に受信完了割込みを発生させることができます。SCIの割込み優先度を

    configMAX_SYSCALL_INTERRUPT_PRIORITYより小さくしておくことで、割込み内でFreeRTOSのAPIを実行することができます。
    受信タスクを設けておきキューで待ち状態を作っておき、割込み内で1バイト受信毎に受信タスクのキューに1バイトデータと共に受信イベント通知を送ってやればtimetick=1msのままUART受信処理が割込み駆動でできて、かつ、2msのタイムアウトともうまく折り合いがつくのではと思います。
    割込み内でFreeRTOSのAPIを呼ぶときは、API名の最後に ...FromISR() とついているものを呼ぶと良いです。今回の場合は xQueueSendFromISR()ですね。 https://www.freertos.org/a00119.html

    以上です

  • こんにちは。シェルティさん

    思想の説明、参考サイトの紹介、代替案など、有用な情報ありがとうございます。

    1msのtimetickはリアルタイムOSとして「ちょうどよい」

    私も関わったOSなしの組込みシステムでは、大抵1msソフトウェアタイマーが用意してあったり、作ったりしました。おっしゃる通り、ちょうど良く、一番需要が高いと思います。

    ITRON用語だと「OS管理外割込み」としてOSに割りこむ形で1ms以下の周期・イベント処理が必要な処理を実行するのがセオリー
    > ポーリングではなく割込み駆動(OS管理割込みとして扱う)にすればよい

    Tick Rate以下の処理を扱うには、上記のやり方がセオリーなのですね。

    > FreeRTOSのtimetickですがデフォルトの1msでソフトウェアの評価をしていて他の条件ではテストを基本的にはしていない

    ルネサスさんの太鼓判も捨てがたいです。
    他にも要求仕様は色々ありますので、システム全体を考えて、どの方式が良いか検討続けようと思います。

Reply
  • こんにちは。シェルティさん

    思想の説明、参考サイトの紹介、代替案など、有用な情報ありがとうございます。

    1msのtimetickはリアルタイムOSとして「ちょうどよい」

    私も関わったOSなしの組込みシステムでは、大抵1msソフトウェアタイマーが用意してあったり、作ったりしました。おっしゃる通り、ちょうど良く、一番需要が高いと思います。

    ITRON用語だと「OS管理外割込み」としてOSに割りこむ形で1ms以下の周期・イベント処理が必要な処理を実行するのがセオリー
    > ポーリングではなく割込み駆動(OS管理割込みとして扱う)にすればよい

    Tick Rate以下の処理を扱うには、上記のやり方がセオリーなのですね。

    > FreeRTOSのtimetickですがデフォルトの1msでソフトウェアの評価をしていて他の条件ではテストを基本的にはしていない

    ルネサスさんの太鼓判も捨てがたいです。
    他にも要求仕様は色々ありますので、システム全体を考えて、どの方式が良いか検討続けようと思います。

Children
No Data