カテゴリー: RL78マイコン

CubeSuite+のコード生成（以下Cgと略）が自動生成するファイルを解説します。

先ず、使用マイコンを、なんでも良いので適当に選んで、新しいプロジェクトを作成すると、コード生成プレビュータグの画面が現れます。この時、プロジェクト・ツリーのクロック発生回路に“！マーク”が付いています。最初に、このマークに対応します。

！マークが付いた、クロック発生回路をダブルクリックして下さい。端子割り当て設定タブに、赤字表記で、“はじめに必ず設定してください。また、この設定は1度行うと変更ができません。”が現れます。PIOR00ビット＝１などを選択すると、端子と機能が自動的に変わります。CubeSuite+のCgを使うには、この端子と機能を確定する必要があります。

ここでは、適当にPIORのチェックボックスを選択して、“確定するボタン”を押し、その後、“コード生成（G）ボタン”を押します。すると、プロジェクト・ツリーのファイル＋コード生成箇所に、自動的にいくつかのCファイルとヘッダーファイルが生成されます。生成ファイル名には、先頭に“r_”が付いたものと、“r_cg_”の付いた2種類があります。

この”r_”は、ルネサスを、“cg_”は、コード生成を意味し、ユーザが独自に作成するファイルと、Cgが作成したファイルを区別する役目を果たします。”cg_”の後は、マイコン内蔵の周辺名と、macrodriver.h/userdefine.hが続きます。

r_lk.drも生成されますが、別の機会に解説します。

まとめると、Cgは、以下の5種類のファイルを生成します。

表01 CubeSuite+のコード生成が作るファイル種類

生成ファイル名	説明	補足
r_main.c	main()を含む	内蔵周辺のAPIヘッダーファイルは、Cgが追加済み。
r_systeminit.c	hwdinit()を含む	内蔵周辺のAPIヘッダーファイルは、Cgが追加済み。hdwinit()は、main()を起動。hdwinit()は、スタートアップ・ルーチンが起動。
r_cg_周辺.cとh	内蔵周辺に応じてCg自動生成	周辺設定に応じてCgが生成したAPI関数を含むcファイルと、そのAPI関連のマクロ、プロトタイプ宣言を含むヘッダーファイル。周辺をユーザがどう使うかを記述するr_cg_周辺_user.cファイル（デフォルト中身は空）。
r_cg_macrodriver.h	システム定義ファイル（#progma sfrなど）	全ファイルに自動追加
r_cg_userdefine.h	ユーザ独自定義ファイル	全ファイルに自動追加（デフォルト中身は空）

 

ソースの起動順序は、スタートアップ・ルーチン→hdwinit()→main()なので、もし、Cgを使わずに、全ソースをユーザが作る場合は、“r_”なしの、main.cとsysteminit.cファイルを最低限記述すれば良いことも判ります。

r_cg_macrodriver.hは、#progma sfrや#progma NOPなどと、最低限の型を定義したファイルで、r_cg_userdefine.hは、ユーザが追加する型や、プロトタイプ宣言を記述するファイルでデフォルトは空です。どちらのファイルもCgが、全てのソースファイルに追加済みです。

このように、Cgを使うと、使用する内臓周辺に応じてファイルが分離されたプログラムの入れ物：スケルトンテンプレートを作ってくれます。後は、このテンプレートへ、周辺をどのように使うかをr_cg_周辺_user.cで追加したり、Cgが生成したAPI関数をどのように使うかをmain()などに記述したりすれば、プログラム完成です。

また、端子と機能を除く、周辺機能は、Cgで再設定ができます。Cgが生成したソースのコメント、/* Start user code for pragma. Do not edit comment generated here */と、/* End user code. Do not edit comment generated here */の間に、ユーザが追加したソースは、そのまま再設定後コード生成したソースへ上書きされるからです。詳しくは、4月14日の“CubeSuite+「コード生成」の使い方”を参照してください。

RL78/G14は、①G13とピン互換性あり、②動作速度はG13と同じ32MHz (Max.)、③G14 44DMIPS@32MHz、G13 40DMIPS@32MHz、④Renesas Starter Kit販売が近いことが解りました。

CPUコアに乗除算命令と積和演算命令を追加し、高性能タイマやELC、DTCなどの違いにより、G13よりソフト構成によっては、3割程度の性能向上が期待できるらしい。RAM容量も増えています。

ピンコンパチなので、G13からG14への置換えも可能なのでしょう。

無料版CubeSuite+ V1.02.00  [12 Apr 2012]以降に追加された、アップデート機能は、これまでライセンス取得版、つまり有料版のみで提供されていました。開発ツールの更新は、基本的に6か月毎だそうです。しかし、CubeSuite+のように多くのツールの組合せで機能するIDEでは、各ツールの更新サイクルを合わせるのは無理です。結果として、2～3か月で一部ツール更新が発生します。

そんな時に役立つのが、このアップデート機能です。アップデートマネジャーを起動すると、ツール更新状況をチェックして、更新分のダウンロードとインストを行ってくれます。“アップデートの選択”は、CubeSuite+で開発できる全機種が設定されていますので、必要分のみを選択してください。インスト時は、一旦CubeSuite+を終了する場合もありますが、成功マークが表示されれば、最新ツールの組合せで開発ができます。

2012年7月30日、ルネサスエレクトロニクスRL78/G14ワークショップ：WS、大阪開催へ参加します。

RL78/G14は、このブログカテゴリRL78/G13の上位機種と思われがちですが、ハード的には、別物です。G14は、旧ルネサスR8Cの後継機、G13は、旧NECエレの78Kの後継機です。G14/G13両機ともに汎用マイコンですが、G14は、64MHz動作のタイマRD内蔵、剰余算命令と積和演算命令がコア部に追加された、より高性能マイコンです。

昨年のG13 WS参加に続いて、今年のG14 WSの参加目的は、R8C/25の置換え検討と、高性能化のポイント、データ・トランスファ・コントローラ；DTCと、イベント・リンク・コントローラ；ELCの習得です。実機Stickボード（RL78/G14 Stick、近日中にルネサスWEB販売予定、4000～5000円程度と推測）での動作と、CubeSuite+とE1によるデバッグができるので、楽しみです。参加者は、このStickを、もれなくもらえる特典もついています。

このように、少し別の機種をスタディすると、ブログ記載のRL78/G13とR8C/25を、より深く知ることができるというメリットもあります。本ブログも、記載カテゴリの機種に限らず、いろいろなマイコンの質問にも積極的にお答えしますので、ご質問は、コチラへお寄せください。

RL78ファミリCubeSuite+のスタートアップ・ガイド編が、2012年6月28日に発行されました。初心者には、煩雑で、肝心の箇所がコチラを参照して、となっているので判りにくいと思います。マニュアル作りは、対象読者の設定がとても難しいです。特に、全ての機能を統合するIDEなどは、その最たるものでしょう。本ブログは、初級～中級者を対象としています。

そこで、この読者向けに、CubeSuite+の設定で、コレダケをすれば動作OKというものを5個リストアップします。いずれも太字の箇所が設定箇所です。

ターゲットボードは、2012年7月7日現在、RL78 G13/G14用のRSKは開発中で入手できませんので、RL78G13 スタータキットStick RL78G13-STICKを想定しました。設定値の内容は、マニュアルを参照してください。

統合開発環境：IDEは、開発ツールの全ての設定を、GUIで変えられることを目的としています。本来はデフォルトのままで、変更必要がないパラメタから、絶対に設定が必要なパラメタまで、これらが全て操作できるので煩雑になります。いろいろIDEを使った経験から、CubeSuite+は、ツールチップ表示やパラメタの解説が下段に表示されることなど、よくできた部類に入ります。

効果的な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点のみです。