IoT MCUのHappyTech

効果的なRAMの使い方を2つ解説します。CALLTテーブルとsreg変数です。使い方は、CALLTの場合は、通常の関数宣言の前にcalltを、sreg変数は、通常の変数宣言の前にsregを、修飾子のように付けるだけです。例えば、下記です。

callt static void          MainFuncCaller(void);  // CALLTで高速化

sreg unsigned char    CntTau02Int = 0x00U;   // sreg変数で高速化

ユーザーズマニュアル RL78,78K0Rコーディング編 「図3―2 メモリ空間の利用」を観ると、CALLTテーブルと、sreg変数という用途のアドレスがあることが判ります。CALLTテーブルは、通常の関数CALLよりも高速に呼ぶためのテーブル領域です。呼出し回数が多い関数や、高速起動したい関数に好適です。sreg変数は、通常よりも高速アクセスできるショート・ダイレクト・アドレッシング領域内の変数のことで、これもアクセス頻度が高い変数に向いています。その他にも、いろいろな用途の領域がありますが、これら2つは利用効果が高く、副作用も無いので、安心して使えます。

CALLTテーブルもsreg変数も、CubeSuite+のビルド・ツールのパラメタを設定すると、ツールが自動で選んだ関数/変数に適用できます。しかし、デフォルトでは未使用設定ですし、ツール更新のたびに再設定するのは、忘れるなどのミスを招きます。プログラマが、関数と変数を選んで、これらの高速化の修飾を明示的につける方が良いでしょう。注意点は、利用できるサイズが64/148バイトと小さいので、CubeSuite+のビルド・ツール、変数/関数配置オプションのROM/RAM使用量を表示する（デフォルト：いいえ）を、“はい”に設定して、常に使用量を把握しておくことです。

 

CubeSuite+ V1.02.00の動作環境は、ユーザーズマニュアル起動編によると、32ビット版XP、32/64ビット版Windows7です。5月31日にWindows8 RPがリリースされましたので、この新環境の64ビット版Windows8 RPで、CubeSuite+ V10.02.00が動作するかをレポートします。

結果は、デスクトップアプリとして何の問題もなくWindows8 RP上で動作しました。Windows8 Release PreviewとCustomer Previewとの違いは、より製品版に近いこと、画面描写がカッコ良くなったことなどです。詳細は、いろいろ記事がでるでしょうから、そちらを参照して頂くとして、ここでは、CubeSuite+がWindows8 RP上で、どのように動作するかにフォーカスしてレポートします。

Windows8スタート画面                                 デスクトップCubeSuite+画面（チャーム出現時）

CubeSuite+をWindows8 RPへインストールすると、スタート画面のタイルに、普段はあまり使わない全アプリのタイルが自動的に登録されます。これは、わずらわしいので、不要タイルを右クリックして、「スタート画面からピン止めを外す」を実行し、必要最低限のタイルのみにすることをお勧めします。私は、CubeSuite+タイルのみにしました。

CubeSuite+タイルをクリックすると、デスクトップ画面に切り替わり、アプリが起動します。通常のアプリは、Windows7画面からスタートボタンを消したこのデスクトップ画面で動作します。マウスを右端に持ってくると、チャームと呼ばれる黒い縦帯の「検索」…「設定」の簡易ランチャーと、時計が自動的に表示されます。右端までの長いソースコードは記述すると、このチャームとバッティングするので、程ほどの長さのコード記述が良いでしょう。その他は、特にWindows7との差は感じませんでした。

製品版とほとんど同じと言われるWindows8 Release PreviewでCubeSuite+が動作しましたので、タイルやチャームに気を付ければ、Windows8移行は問題なしと思われます。

CubeSuite+が、V1.01.00からV1.02.00へバージョンアップされました。オートアップデータや、HEWプロジェクトを、CubeSuite+へ変換する機能などが追加されました。

開発ツールのバージョンアップ時には、障害が付き物です。今回も、旧版では何の問題もなく動作していたターゲットボードへ、新版出力をダウンロードすると、何やら怪しげな致命的エラーが発生しました。原因は調査中です。

この原因を追究して復旧する作業と、開発を続ける作業は、全く別物です。開発が切迫している時などは、割り切りが必要です。この適切な割り切りが冷静にできるが否かが、経験者と初心者の一番の違いでしょう。R8C/25のブログで書いたように、ツールが安定している事は、全ての開発者にとって、精神的にも製品にもプラスに働きます。しばらくは、旧版に戻して開発を続けるつもりです。

開発者のみなさん、バージョンアップの際には、リカバリできるようにくれぐれもバックアップを忘れずに！

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

ソフト構造は、タイムシェアリングとイベントドリブンの2つに大別できます。

タイムシェアリング構造のメリットは、初級～中級レベルの相手に説明した時の、相手の判りやすさと、デバッグが容易なことです。イベントドリブンは、デバッグ時にイベントを発生させることが困難なことが多いので、初心者向きではありません。RL78の大容量のROM/RAMを効果的に使うと、シンプル機能の関数でタスク作成が可能となります。

タイムシェアリングソフトは、イニシャル処理、電源断処理、起動処理、UART1処理の4処理から構成します。この構成でテンプレートを作成します。このテンプレートに、タスクを組込み、ソフトを作り上げます。

タスク組込みの時に検討するのは、タスクの処理時間精度と、どの起動処理で起動するかの2点のみです。 

開発環境CubeSuite+の「コード生成」を使うと、周辺機能変更やマイコン機種変更が生じても追加コードをそのまま使え、しかも、初期設定も自動生成します。そこで、このコード生成の使い方を解説します。

ポイント１：出力ソースの、/* Start user code… */から/* End user code… */の間にのみ、追加コードを記述すること。それ以外は、周辺機能パラメタ変更や機種変更時、「コード生成」が自動生成し、上書きするからです。

ポイント２：5か所ある、/* Start user code… */から/* End user code… */の使い方ガイドラインは、

• ①：#pragama指令を追加するエリア（通常、ほとんど無いでしょう）
• ②：追加関数のプロトタイプ宣言エリア（コード生成出力の関数プロトタイプは、周辺名.hで宣言済み）
• ③：定数、グローバル変数、追加関数の記述エリア（このエリア内なら、自由に記述可能です）
• ④：コード生成出力関数に追加記述するエリア（関数名は自動生成されるので、追加分の中身を記述）
• ⑤：機能は③と同じ（③と⑤のどちらか一方を使う方が良いでしょう）

どこに何を記述すべきかのガイドラインがあると、ソース解読が判りやすくなります。

RL78/G13は、R8C/2xの後継機であり、価格、性能、開発環境が向上しました（R8C/25の直系後継機は、RL78/G14ですが、より早くリリースされ、低価格のG13をここでは選びました）。

評価項目	解：RL78/G13、52ピン、10×10mm、0.65ピッチ	従来R8C/25比
入手性の良さと低価格	DigiKeyにて￥350前後で販売中 （2012年4月現在）	22％価格改善
高性能で大容量	32MHz動作 ROM/RAM/データフラッシュ＝64KB/4KB/4KB	160％性能向上 200%容量増大
無償開発環境の良さ	統合開発環境 CubeSuite+	コード自動生成機能追加
汎用性と拡張性	IOピン数が程ほどで、手実装も容易	同左

特筆すべきは、開発環境のCubeSuite+。初期設定を自動生成するので、アプリ開発にすぐ着手できます。従来は、ハードウエアマニュアルを読み、初期設定を自作していました。ソフト処理や手順を文章で記述すると、簡単な事でも冗長になるので、結構厄介でした。アプリ開発に着手したいのに、前段階でつまずく事もしばしばあり、ここが改善されたのは効果大です。