RL78/G13のRAMの使い方

R8C/25比、2倍に増えたRL78/G13の4KB RAMの使用方針を示します。RAMは、

• 関数間のインタフェースRAM
• 関数/ライブラリの内部変数
• スタック

として使います。スタックと関数/ライブラリの内部変数は、コンパイラが勝手にRAMへ割り付けます。プログラマは、それらの使用量を知っていれば十分です。関数間のインタフェースRAMとは、自作する関数どうしの入出力変数の入れ物です。

関数は、void main(void)のように、入出力変数が無いものもありますが、一般的には、入力変数を、プログラムで処理し、その結果を出力変数へ変換します。この出力変数が、期待値と異なる場合、プログラムを変えたり、入力変数を変えたりします。この作業が、関数の単体デバッグです。

全ての入出力変数をインタフェースRAMで定義すると、この関数単体デバッグが、格段に簡単になります。RL78/G13の開発ツールCubeSuite+は、RAM値の表示と、その変更がツール上で簡単にできるからです。昔のRAM容量が少ないマイコンを知っているプログラマは、この方法に抵抗があるかもしれません。しかし、今のマイコンには、大容量RAMが内蔵されています。RAMをケチらずに使ってデバッグ効率を上げるのが、最新マイコンに適したRAM使用方法です。

私は、R8C/25（2KB RAM）と開発ツールHEWでもこの方法を使っていますが、これまでRAM容量の不足を感じたことはありません。また、RL78/G13では、アクセス頻度が高い変数を、ショート・ダイレクト・アドレッシング：sreg領域（147バイト）へ配置すると、通常RAMよりもさらに高速動作が可能です。デバッグの容易性と、高速化、この2つを同時にかなえる方法と言えるでしょう。

1関数のソースの長さは、お使いのモニタの縦の長さ以下、が良いでしょう。関数をモニタで表示した時に、初めから終わりまでが、一目で見えるからです。誰かにデザインレビューをお願いする時や、自分でデバッグする時も、この程度のソース長が適当です。プログラムを書いていて、ソースが長くなったら、この目安を守るように、入出力変数を見直して関数化すると良いでしょう。