スマートコンフィグレータとFITについて

ka.makiharaさん、こんにちは。NoMaYです。

＞ もちろん設定の不備などはあるとは思いますが、例えばSCI2 を使用したい時に r_sci_rx でASYCNに設定した場合は通信できなくて、SCIFの2(Config_SCI2)を使うと通信ができる。どのように判断して使い分けるのがよいのでしょうか?

これは設定間違いがある筈ですから、その状況にてFITとCGの使い分けについて思案するのは良くないような気がするのです。動いてしまえば、総じて/概ね、FITの方が楽チンなのではないでしょうか。ただ、FITのドキュメントにて未対応となっていることをしなければならなくなった時など、FITの多品種対応/多機能ゆえにFITのソースを改造するのは大変であることも少なくない筈であり、CGの簡素なソースの方が改造し易い(というかそもそも簡素なものなので増築し易いというか)こともあろうかと思うのです。

また、多品種対応の為の冗長さ/多機能であることそれ自体、によりROMサイズへの影響はCGより大きいですので、ROMサイズが64Kとか、それより小さいとか、そのあたりだと楽チンさよりコードサイズを優先しないといけないというような選択が必要になることもあろうかと思うのです。例えば以下のスレッドでは、センサからデータを読むだけで(BSPモジュール込みですが)24Kとかなってました。(もっとも、いろいろな要因が絡んでいますので、今後改善されると思いますけれども。)

RX MCUのROM/RAM usage sizeがRenesas QuickConnect IoTのsample programでボロ負け(very worse than)している件(RA MCUやRL78 MCUに比べて)
japan.renesasrulz.com/cafe_rene/f/analog/7575/rx-mcu-rom-ram-usage-size-renesas-quickconnect-iot-sample-program-very-worse-than-ra-mcu-rl78-mcu

でも、ひとつ思い出しましたけれど、FITは端子設定回りや割り込み回りでスマートコンフィグレータとの結合が弱かったような気がします。そちらでSCI2が動かないのも端子設定回りの問題かも知れません、、、

＃ ちなみに、私の好みは、ソースの簡素さ、ゆえのCGの方です。自分が遊ぶ分には、それで事足りるというか。

[追記]

FITとCGの違いに関しては、CGの生い立ちの話をするのが良いかも知れません。CGの起源は、NECの78K0Sファミリという、ファミリ内で最大のROMサイズのものでも僅か8KバイトというマイコンのAppliletというツールだったと思います。そして、例えばUART通信であれば、ボーレートやらビット数やらの設定を動的に変えられるマイコン向けライブラリは普通に考え付くものだったのですが、何しろROMサイズが小さかったので、実際のユースケースでは動的に変えるということは余り無いことであり、ライブラリ内部に変更機能を持たせてライブラリサイズを大きくしてしまうよりも、コンフィグレーションGUIを用意しておいて変更する(そうしてソース上ではレジスタ設定決め打ちする)ことによりライブラリサイズ(というよりもプログラムサイズ)を小さくするようにしたツールでした。初期化関数の引数でのコールバック関数登録というスタイルでなく、直接ソースにユーザ記述部を用意してユーザに処理を記述させるスタイルなのも、その為です。(だと思います。関数ポインタを知らなかった、というのでは無いと思います。)

怪我の功名というか、動的な自由度が無い/少ないデメリットの反面、GUIでの設定でほぼ確実に(基本機能が動作する)プログラムを作れるようになったもの、であったように思います。(だったと私は思っています。もっとも、不具合のせいで、そうは問屋が卸さなかった、ということはあったでしょうけれども。)

FITは(悪い意味では無いのですけれども)一般的なマイコン向けライブラリですね。対して、CGは上のような感じですね。

ルネサス マイクロコンピュータ 8ビット All Flash 78K0S, 78K0 マイクロコントローラ - パンフレット
www2.renesas.cn/jp/ja/document/bro/8-bit-all-flash-78k0s-78k0-microcontrollers-pamphlet-r01cl0004ej0200
　

ka.makiharaさん、こんにちは。NoMaYです。

＞ もちろん設定の不備などはあるとは思いますが、例えばSCI2 を使用したい時に r_sci_rx でASYCNに設定した場合は通信できなくて、SCIFの2(Config_SCI2)を使うと通信ができる。どのように判断して使い分けるのがよいのでしょうか?

これは設定間違いがある筈ですから、その状況にてFITとCGの使い分けについて思案するのは良くないような気がするのです。動いてしまえば、総じて/概ね、FITの方が楽チンなのではないでしょうか。ただ、FITのドキュメントにて未対応となっていることをしなければならなくなった時など、FITの多品種対応/多機能ゆえにFITのソースを改造するのは大変であることも少なくない筈であり、CGの簡素なソースの方が改造し易い(というかそもそも簡素なものなので増築し易いというか)こともあろうかと思うのです。

また、多品種対応の為の冗長さ/多機能であることそれ自体、によりROMサイズへの影響はCGより大きいですので、ROMサイズが64Kとか、それより小さいとか、そのあたりだと楽チンさよりコードサイズを優先しないといけないというような選択が必要になることもあろうかと思うのです。例えば以下のスレッドでは、センサからデータを読むだけで(BSPモジュール込みですが)24Kとかなってました。(もっとも、いろいろな要因が絡んでいますので、今後改善されると思いますけれども。)

RX MCUのROM/RAM usage sizeがRenesas QuickConnect IoTのsample programでボロ負け(very worse than)している件(RA MCUやRL78 MCUに比べて)
japan.renesasrulz.com/cafe_rene/f/analog/7575/rx-mcu-rom-ram-usage-size-renesas-quickconnect-iot-sample-program-very-worse-than-ra-mcu-rl78-mcu

でも、ひとつ思い出しましたけれど、FITは端子設定回りや割り込み回りでスマートコンフィグレータとの結合が弱かったような気がします。そちらでSCI2が動かないのも端子設定回りの問題かも知れません、、、

＃ ちなみに、私の好みは、ソースの簡素さ、ゆえのCGの方です。自分が遊ぶ分には、それで事足りるというか。

[追記]

FITとCGの違いに関しては、CGの生い立ちの話をするのが良いかも知れません。CGの起源は、NECの78K0Sファミリという、ファミリ内で最大のROMサイズのものでも僅か8KバイトというマイコンのAppliletというツールだったと思います。そして、例えばUART通信であれば、ボーレートやらビット数やらの設定を動的に変えられるマイコン向けライブラリは普通に考え付くものだったのですが、何しろROMサイズが小さかったので、実際のユースケースでは動的に変えるということは余り無いことであり、ライブラリ内部に変更機能を持たせてライブラリサイズを大きくしてしまうよりも、コンフィグレーションGUIを用意しておいて変更する(そうしてソース上ではレジスタ設定決め打ちする)ことによりライブラリサイズ(というよりもプログラムサイズ)を小さくするようにしたツールでした。初期化関数の引数でのコールバック関数登録というスタイルでなく、直接ソースにユーザ記述部を用意してユーザに処理を記述させるスタイルなのも、その為です。(だと思います。関数ポインタを知らなかった、というのでは無いと思います。)

怪我の功名というか、動的な自由度が無い/少ないデメリットの反面、GUIでの設定でほぼ確実に(基本機能が動作する)プログラムを作れるようになったもの、であったように思います。(だったと私は思っています。もっとも、不具合のせいで、そうは問屋が卸さなかった、ということはあったでしょうけれども。)

FITは(悪い意味では無いのですけれども)一般的なマイコン向けライブラリですね。対して、CGは上のような感じですね。

ルネサス マイクロコンピュータ 8ビット All Flash 78K0S, 78K0 マイクロコントローラ - パンフレット
www2.renesas.cn/jp/ja/document/bro/8-bit-all-flash-78k0s-78k0-microcontrollers-pamphlet-r01cl0004ej0200