こんにちは。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％高速化します。」
こんにちは。NoMaYです。以前に投稿した以下の件で思ったのですけれども、今のBSPモジュールには以下の定義がありますので、割り込み関数先頭で多重割り込みを許可した後、PSWのIPLフィールドの値を以下の定義の値に変更してやれば、FITモジュール相互間での多重割り込みは起きませんので、それなりにトラブルも無く運用出来そうな気がしました。(もっとも、同一のマクロで良いのかどうか吟味は必要かなぁ、とは思いますけれども。)r_bsp_config.h
/* For some BSP functions, it is necessary to ensure that, while these functions are executing, interrupts from other FIT modules do not occur. By controlling the IPL, these functions disable interrupts that are at or below the specified interrupt priority level. This macro sets the IPL. Range is 0x0 - 0xF. Please set this macro more than IPR for other FIT module interrupts. The default value is 0xF (maximum value). Don't change if there is no special processing with higher priority than all fit modules.*/#define BSP_CFG_FIT_IPL_MAX (0xF)
＞ FIT/CGの割り込み処理は、関数先頭で多重割り込み許可を設定される、ということを想定されて設計とか設計レビューとかされていないと思いますので、無理矢理そういうことをすると誤動作するリスクはもちろんあると思っています。＞＞ (1) CGコンポーネントの場合＞＞ 割り込み処理のコード全体を容易に見渡せますので、そういうことをしたら誤動作するかどうかも気付きやすいと思います。他方で、たとえ通信コンポーネントなどでも、１チャンネルずつ独立したソースになっていて、チャンネル間で何かしらの管理データを共有する、ということもありませんので、もともとトラブルを起こす可能性は少なそうに思われます。(ただ、全てのCGコンポーネントを触ったわけでは無いので、たぶん共有は無さそう、というところですが。)＞＞ (2) FITモジュールの場合＞＞ 1つの通信モジュール(のソース)で複数のチャンネルをサポートしていたりしますので、チャンネル間で何かしらの管理データを共有しているかも知れず、チャンネル間で割り込み優先度を変えたりすると、そういったデータの操作が破綻して、トラブルを起こす可能性は想定されることです。他方で、チャンネル間で割り込み優先度を変えたりしなければ、関数先頭で多重割り込みを許可するということを無理矢理やってもトラブルを起こす可能性は少なそうに思われます。こちらは、割り込み処理のコード全体を容易に見渡せるというわけでも無く、それなりに気合を入れてソースを追ってからでないと、誤動作してしまうのかどうか分からないと思います。[メモ]考察が必要な事項(1) 既に自前で、コールバック関数内で多重割り込み許可にして、FITモジュール相互間の多重割り込みを運用中のユーザ(2) うっかり多重割り込みの優先度設定を間違えて、発生した割り込みよりIPLの値を小さくしてしまうというトラブルの防止策