CubeSuite+のコード生成は、マイコン周辺機能を制御する「デバイス・ドライバ」と「ひな型ソース」を出力します。ユーザは、このデバイス・ドライバをAPI関数としてコールする処理をひな型へ追加すれば、所望動作プログラムが完成します。今回は、このひな型とユーザが追加する処理を分離すると、マイコン依存性が少なくなり、移植性が高まることを示します。
コード生成の「端子割当て設定」は、はじめに必ず設定する必要があることは、以前示しました。そこで、この端子割当てのみを設定し、後は何もせずにコード生成（G）をクリックすると、10個のファイルが生成されます（「r_」は、ルネサス、「r_cg_」は、コード生成が作成したことを意味すると思います）。
1～4がひな型、5～10がデバイス・ドライバです。クロック発生回路とウオッチドック・タイマは、デフォルトで利用する周辺回路です。ユーザが使う周辺回路をコード生成のGUIで設定すれば、それに応じてr_cg_周辺回路.c、r_cd_周辺回路_user.c、r_cg_周辺回路.hの3ファイルがこれらに追加されます。
r_systeminit.cは、周辺回路の初期設定が生成されていて、r_main.cの実行前にスタートアップで処理されます。r_cg_macrodrive.hは、システム定義のマクロで、r_cg_userdefine.hは、中身なしのスケルトンです。必要に応じて、ここにユーザ定義を追加すれば、全ファイルに自動的にインクルードされます。
起動処理のr_main.c中身を示します。R_MAIN_UserInit()でメイン無限ループ実行前のユーザ追加処理があれば追記し、なければそのまま割込み許可EI()した後、メイン無限ループに入ります。通常は、この無限ループにユーザが処理を書き加えます。
何らかの都合で、コード再生成した場合にも、/* Start user…*/と/* End user…*/の間に書き加えた処理は、そのままコード再生成出力ファイルにマージされますので、追加分は、保持されます。これが、コード生成の一般的な使い方です。この場合は、ユーザ追加処理は、コード生成ファイル内に入ります。
提案は、このユーザ追加処理とコード生成のひな型を分離し、別ファイルにすることです。メイン無限ループにuser_main()を付け加えた例で説明します。user_main();は、別ファイルmain.c内に作成します（「r_」が無いので自作ファイルであることが判ります）。
このmain.cファイル内のuser_main()でコード生成出力のAPI関数を使うので、使用するr_cg_周辺回路.hをインクルードする必要がありますが、user_main()は、多数のAPI関数のコールを使う単純なプログラムとなります。API関数名は、R_CGC_Set_CRCOn ();などのように長い記述になりますが、その分、ソース可読性は向上します。また、RL78/G13とRL78/G14で周辺回路のハードが異なるものがあっても、API関数名は同じものがコード生成されるので、制御するユーザ側は、同じものが使えます。
このように、コード生成出力のひな型とユーザ追加処理を分離すると、移植性が良くなります。最近のマイコン統合開発環境は、CubeSuite+のようにAPI関数を自動生成するものが増えてきました。この場合も、API関数名は、同じか、または近い意味のものが生成されますので、ユーザが追加した処理ファイルがそのまま使える可能性が高まります。API関数を使う側と、API関数を生成する側を分離すると、マイコンの製品依存性も少なることが判ります。
販売中のG1xテンプレートは、この考え方で開発しました。RL78/G13とG14で共通に使えます。他シリーズは試していませんが、使えると思います。また、他社製品、例えばARM Cortex-Mマイコンなどにも適用してみたいと考えています。