RXv3コアのレジスタ一括退避機能の使い方(Register Bank Save Function Usage)を調べてみるスレッド

こんにちは。NoMaYです。

RXv3コア搭載の120MH動作のRXマイコンも、RX66T以降、RX671、RX66N、RX660と品種が増えてきましたが、RXv3コアのセールスポイントの1つであるレジスタ一括退避機能の使い方が今ひとつピンと来ません。そこで、いつものように、ちょっと好奇心からスレッドを立ててみました。(注: RX66Tは、160MHz動作、レジスタ一括退避機能未搭載、です。) いつものように、ぼちぼちと続きます。

ホワイトペーパー
卓越したMCU性能と電力効率を実現するRXv3コア
2019年10月
www.renesas.com/jp/ja/document/whp/introducing-rxv3-core-superior-performance-excellent-power-efficiency#page=6

割り込み応答時間の改善

モータ制御システムなどは、高速な割り込み処理によるリアルタイム性能が必要となってきます。

RXv3コアには、割り込み処理時にレジスタを高速退避/復帰するために、オプション機能として、レジスタ退避バンクと呼ばれる専用メモリを実装しています。図6に示すように、レジスタ退避バンクを使用することで割り込み応答時間を短縮でき、割り込み処理全体の時間を短縮することができます。 割り込み処理ルーチンの中で、SAVE命令を使用すると汎用レジスタとアキュムレータを1クロックで専用メモリに保存できます。RSTR命令は、保存されたレジスタを3~6cycleで復元します。レジスタ退避バンクは専用メモリを複数面持っており、多重割り込みにも対応することが可能です。

図6.割り込み応答時間の改善

レジスタ退避バンクは、割り込みハンドラだけでなく、RTOSコンテキスト切り替えにも使用できます。 RTOSコンテキスト切り替え時間は、レジスタバンク保存機能により最大20%高速化します。


Parents
  • こんにちは。NoMaYです。

    FIT/CGの割り込み処理は、関数先頭で多重割り込み許可を設定される、ということを想定されて設計とか設計レビューとかされていないと思いますので、無理矢理そういうことをすると誤動作するリスクはもちろんあると思っています。

    (1) CGコンポーネントの場合

    割り込み処理のコード全体を容易に見渡せますので、そういうことをしたら誤動作するかどうかも気付きやすいと思います。他方で、たとえ通信コンポーネントなどでも、1チャンネルずつ独立したソースになっていて、チャンネル間で何かしらの管理データを共有する、ということもありませんので、もともとトラブルを起こす可能性は少なそうに思われます。(ただ、全てのCGコンポーネントを触ったわけでは無いので、たぶん共有は無さそう、というところですが。)

    (2) FITモジュールの場合

    1つの通信モジュール(のソース)で複数のチャンネルをサポートしていたりしますので、チャンネル間で何かしらの管理データを共有しているかも知れず、チャンネル間で割り込み優先度を変えたりすると、そういったデータの操作が破綻して、トラブルを起こす可能性は想定されることです。他方で、チャンネル間で割り込み優先度を変えたりしなければ、関数先頭で多重割り込みを許可するということを無理矢理やってもトラブルを起こす可能性は少なそうに思われます。こちらは、割り込み処理のコード全体を容易に見渡せるというわけでも無く、それなりに気合を入れてソースを追ってからでないと、誤動作してしまうのかどうか分からないと思います。

Reply
  • こんにちは。NoMaYです。

    FIT/CGの割り込み処理は、関数先頭で多重割り込み許可を設定される、ということを想定されて設計とか設計レビューとかされていないと思いますので、無理矢理そういうことをすると誤動作するリスクはもちろんあると思っています。

    (1) CGコンポーネントの場合

    割り込み処理のコード全体を容易に見渡せますので、そういうことをしたら誤動作するかどうかも気付きやすいと思います。他方で、たとえ通信コンポーネントなどでも、1チャンネルずつ独立したソースになっていて、チャンネル間で何かしらの管理データを共有する、ということもありませんので、もともとトラブルを起こす可能性は少なそうに思われます。(ただ、全てのCGコンポーネントを触ったわけでは無いので、たぶん共有は無さそう、というところですが。)

    (2) FITモジュールの場合

    1つの通信モジュール(のソース)で複数のチャンネルをサポートしていたりしますので、チャンネル間で何かしらの管理データを共有しているかも知れず、チャンネル間で割り込み優先度を変えたりすると、そういったデータの操作が破綻して、トラブルを起こす可能性は想定されることです。他方で、チャンネル間で割り込み優先度を変えたりしなければ、関数先頭で多重割り込みを許可するということを無理矢理やってもトラブルを起こす可能性は少なそうに思われます。こちらは、割り込み処理のコード全体を容易に見渡せるというわけでも無く、それなりに気合を入れてソースを追ってからでないと、誤動作してしまうのかどうか分からないと思います。

Children
No Data