スマート・コンフィグレータ要望 多重割込

主にRXでスマート・コンフィグレータを使っています。

現状では割り込み設定で多重割込の許可が出来ません。

生成された割込ハンドラに割り込み許可を入れれば良いのですが、個別のファイルを変更する必要があります。

優先レベルや高速割り込みの設定と同様に「割り込み設定」タブから一覧で設定できると、全割り込みの設定が俯瞰できて非常に便利です。

ご検討をお願いします。

Top Replies

Parents
  • 一年以上前の書き込みに返答するも無粋ですが、今やっている開発案件でステッピングモータードライバーに対してパルスを吐き出す部分の制御で優先度を最高にしても割り込みハンドラが遅れて起動するのがわからなくてここに辿り着きました。BLDC+STEPPER+RS485アブソエンコーダ+ECATとごちゃごちゃしていますが、PWMモードのGPTWタイマーの周期を割り込みハンドラで書き換えて制御しているのに計算したパルス数と実際のパルス数(想定している位置よりオーバーするのでなぜ?というところから、Arduinoボードを用いたパルス数の確認ジグまで作りました)が違うことでここに辿り着きました。理由が多重割り込みが許可されていないだけという点でした(てっきりデフォルトは多重割り込みするもんだと思っていたニワカです)。今回の開発で初めてRXマイコンを使用したのでコンパイラの仕様、スマートコンフィギュレータの仕様、マイコンの仕様が全て抜けたところからの開発でしたが、生成コードに多重割り込みの許可を入れてなんとか解決しました。でも、コードが生成されるたびに問題が起こる・・・

    なお、スマートコンフィギュレータのダメだなって感じた点は生成されたコードに出力される定数マクロのマクロ名が私の想定の斜め上な仕様で生成される点です。タイマの設定値をアルゴリズムに反映したいのにマクロ名自体が設定値を組み込んだリテラルになっているのでそれ値の直埋め込みと同じですよね。

  • Yamamotoさん、こんにちは。NoMaYです。

    > てっきりデフォルトは多重割り込みするもんだと思っていた

    > 今回の開発で初めてRXマイコンを使用した

    今まで使用されていたのはSTM32/LPC/Kinetis/SAM/MSP432等のCortex-Mマイコンなのでしょうね。今回のYamamotoさんの書き込みをきっかけとして、Cortex-Mマイコンの多重割り込みに関してGoogle検索してみたのですが、CPUアーキテクチャレベルで多重割り込みを許可した状態で割り込みを受け付けていくアーキテクチャだったのですね。

    実は、RXマイコンもRL78マイコンもRH850マイコンも、成り立ちを辿るとCortex-Mマイコンよりもずっと過去まで遡って行きますが、そのような過去では、割り込みを受け付けたら一旦割り込み禁止にして、(どうしても必要になった場合には)割り込み処理内で自前でソフトウェアで多重割り込み許可の状態にする、ことが一般的でした。(と記憶しています。)

    そして、それらのマイコン向けソフトウェアライブラリやコード生成ツールを立ち上げる場合でも、そういうCPUアーキテクチャでしたので、多重割り込みは後回し(たぶん実情は後回しというより複数の大手ユーザから要求が来ない限りは何もしない)なのだと思われます。そして、多重割り込みに未対応/未検証でライブラリや自動生成コードが膨大な量になっていますので、それらを対応させて検証するのも相当大変になるだろうと思われます。また、ユーザ層も、そのような過去からマイコンを扱っていた人達も少なくなかった筈でしょうから、多重割り込みは後回し、という状況を受け入れている面もあるのかな、と私は思うのです。更には、基本的には多重割り込みは使っては駄目なものである(必要な場合があるという点には理解を示すものの)、という人達もそれなりの割合でいらっしゃいます。(と思っています。)

    ちなみに、たまたまですが、私は別スレッドでRXv3コアで多重割り込みを扱い易くすることは出来ないものかと試行錯誤しているところです。(といっても、個人ブログのようなものレベル、ぐらいなのですけれども。)


    ところで、RXマイコン以外の別マイコンにも詳しいかと思いますが、他に「これでは遅かれ早かれRXマイコンは消えて無くなるかな」といったような点はありましたか?私はルネサスさんの中の人では無いのですけれども、それなりに今まで長いこと、かふぇルネでRXマイコン/RL78マイコンのスレッドにリプライしていましたので、やっぱりちょっと気になってしまうのです。


    あと、以下はどういうことでしょうか?もし可能でありましたら、別スレッドを立ち上げて、少し詳しく教えて頂けないでしょうか?

    > タイマの設定値をアルゴリズムに反映したい

  • 仕事で使うということで私の場合はほとんどがEtherCATがらみ。RXマイコンというよりもRX72Mが手に入るEtherCATスレーブIP付きマイコンの1つとして、また、お客さんがルネサス系がいいという理由で選定したという経緯があります。PIC、PIC24、PIC32、AVR、ARM Cortex-M3、M0、M0+、ESP32、EPS8266あたりを使ってきた経験があります。RINやRZマイコンのEtherCAT付きも触ったことあります。ペリフェラルを覆い隠すようにコード生成するものはルネサスに限らずインフィニオンでも触ったことがありますが、デフォルトが多重割り込み禁止のマイコンの場合、割り込み優先度が設定できるのに優先度が反映されないというのは割り込みレベルが意味を成していないので私の要望としてはRX-CCの#pragma interruptの文法に多重割り込み許可指定のenableの他に許可しない指定を追加、コンパイラオプションで多重割り込み設定が未指定の場合のデフォルト指定が全体でオプション指定できると解決するかなと思います。そうすれば現状のスマートコンフィギュレータのままでもコンパイラのオプションで解決できる。このあたりの歴史的経緯なんてのはルネサスをずっと使っている人にしか理解できないし、スマートジェネレータの仕様として自動的にコードが吐き出されるので出力コードに手を入れないとダメな点がすでにユーザーは許容できないと考えます。

    性能は悪くないと思いますよ。今回はモーター制御ですが、今回の多重割り込みの事が分かって対処したら無事にBLDC(ホール ICベースの120度通電)とSTEPPER(TRINAMICのドライバ ICを使用)が同時に回転制御できるようになりました。STEPPER用のパルスレートも40kHzまでは成り立つのが確認できています。将来性・・・今、使っている人がいなくなったら市場が痩せ細りそうな気がします。少なくとも産業用途ではユーザーは保守的でポンポン新しいの使わないだろうけど、海外まで視野に入れるとビジネスを継続するためにはもっと広く視野を持ってツールの開発をして欲しいなと感じます。使いやすい・入手しやすいというのが最初の一歩の条件ですからね。サンプルコードやツール、揃っているといえば揃っているけど、更新されていなくて組み込みで上手くいかなかったりというのも経験しました(EtehrCAT部分)。

    多重割り込みがデフォルトで許されると困るってのはそもそも排他制御などが元々ちゃんと考慮されていないコードを書いているというのが主たる原因だと考える私がここにいます。

  • CPUコアとコンパイラが多重割込に対応しているのに、コード生成ツールが多重割込を無視しているというとても残念な状況なんですよね。

    対応するのにそれほど大きな工数がかかるとも思えないのがまた残念な所です。

    多重割り込みがデフォルトで許されると困るってのはそもそも排他制御などが元々ちゃんと考慮されていないコードを書いているというのが主たる原因だと考える私がここにいます。

    その通りですね。多重割込は気を付けないと問題になり得るからといって、ツールがその機能を無視するというのは全くおかしな話です。

Reply
  • CPUコアとコンパイラが多重割込に対応しているのに、コード生成ツールが多重割込を無視しているというとても残念な状況なんですよね。

    対応するのにそれほど大きな工数がかかるとも思えないのがまた残念な所です。

    多重割り込みがデフォルトで許されると困るってのはそもそも排他制御などが元々ちゃんと考慮されていないコードを書いているというのが主たる原因だと考える私がここにいます。

    その通りですね。多重割込は気を付けないと問題になり得るからといって、ツールがその機能を無視するというのは全くおかしな話です。

Children
  • 賛同者いますよね。SHの頃もコンパイラの仕様で「へ?」って思う事が多かったし・・・その時は関数ポインタ渡しとその呼び出し時のポインタが自動変数で関数呼び出しと同時にスタックが解放されるという・・・最適化無効すると正常に動くし、最適化有効でも静的確保すると解決するので気がつくのに何度もデバッガで変数値の確認したりして気がつくまでに数日を要したこともあった。最終的にはその関数の後で(void)変数名;とやってスコープをコンパイラに明示してあげたらその意図がコンパイラに伝わったなんてことも。

    脱線しましたが、はっきり言ってこんなヘボいツールの仕様でマイコン自体の良さが台無しになるのは残念なんです。私なら時間はかかるけどなんとか自力で気付けるけど、人によってはこれで諦めてしまって使用者数が伸びなかったらマイコン自体の開発に尽力している連中が報われないと思う。