IoT MCUのHappyTech

ソフトにバグは付き物です。CubeSuite+のコード生成にも、このバグがあります。自作ソフトのバグと、純正ツールが生成したバグ、両方に対処する必要があるのは残念ですが、やむを得ません。今回は、2013年2月15日にリリースされたコード生成バグで、RL78/G13とG14に関するものを2点紹介します。

ここ1年のCubeSuite+、CA78K0Rの更新履歴を診ると、2～3か月でバージョンアップされていることが判ります。CA78K0Rは、純正ビルド・ツールで、コード生成もこのツール出力です。各版フォルダ内にDocフォルダがあり、この中にリリース・ノートがあります。

リリース・ノートには、変更点と注意事項があり、使用前に必ず読むようにありますが、初心者は読まないでしょう。ツール更新が自動化され、更新完了すると、なるべく早く開発を継続したいからです。そうすると、自作バグと純正ツールバグの切り分けができず、ハマッテしまいます。経験者は、このハマッタ経験があるから、ツール更新時は、落ち着いてリリース・ノートを読みます。

RL78/G13とG14の注意点：スタートアップ・ルーチン

初心～中級者は、スタック領域サイズを変更することはないと思います、が、念のため読んでおきましょう。コード生成が出力するr_systeminit.cのhdwinit関数は、main関数前に処理されるので、デバッガダウンロード時、デフォルト設定なら自動実行されます。また、r_systeminit.cは、コード生成に問題がない時は、全く気にしないファイルです。従って、かなり見つけにくいバグになるでしょう。この場合には、デバッガのデフォルト設定（指定シンボル:_main）を変更し、コード生成出力に、回避策を手動で追加する必要があります。

RL78/G14のタイマRD/RJの注意点：

RL78/G14の特徴に、高速オンチップオシレータ64MHz対応のタイマRD PWMモードがあります。この特徴を使ったタイマRDの、コード生成出力のデューティ比が、正しくない不具合があります。また、ポート割当てとの競合を示す！マークも正しく表示されません。

タイマRJのパルス周期計測モード使用時、コード生成の計測計算に、誤りがあります。

これらの不具合には、リリース・ノート記載の回避策に沿って対処します。根本的には、次回2013年4月頃予定のCubeSuite+次期バージョンで改善されるそうです。しかし万一、これらが原因でハマッテしまった場合、切り分けや、抜け出すのが困難であることが判るでしょう。ツール更新時は、リリース・ノート一読をお薦めする理由です。

組込みマイコンのIDEが出力するmain()には、普通while文の無限ループによるアプリ起動処理が一か所記述されます。CubeSuite+のコード生成出力にもこれがあります。このアプリ起動処理を、起動されるアプリ側から検討します。

起動されるアプリには、割込みの確認/応答などのようにリアルタイム処理が必要なものから、スイッチチャタリング処理などの数ミリsec～数10ミリsec程度の処理間隔時間が必要なものまで様々です。このように処理時間が異なるアプリを、一か所の処理から起動すると、問題点がアプリ側に生じます。

スイッチチャタリング（以下SWと略す）処理を例に示します。1回目に起動されたSW処理で、スイッチのOn/Offを検出し、2回目に起動された時に再検出して1回目のOn/Offと同じであれば、スイッチの値を確定するような処理です。使用するスイッチにもよりますが、1回目と2回目の検出には、数ミリsec～数10ミリsecの時間間隔が必要です。この間は、On/Off値がハード的にバタついて安定しないからです。もし、起動処理が一か所の場合には、アプリのSW処理側でこの時間間隔分の検出処理をしない、“飛ばし”が必要になります。この“飛ばし”をｎ回とします。ｎ回起動されるまで2回目のOn/Offを調べない訳です。

起動処理は一か所ですので、他のアプリも起動します。起動側のアプリにもSW処理と同様、処理を“飛ばす”場合があると、結果として、SW処理の起動間隔は別アプリの“飛ばし”有無により変わってしまいます。SW処理は、他のアプリの“飛ばし”有無は判りませんので、このままではSW処理プログラムが書けません。

これを解決する方法の1つは、SW処理アプリが、“他のアプリ処理に係らず、常に例えば10ミリsecの一定間隔で起動“されることです。これならSW処理に“飛ばし”は不要です。このように本来は、アプリの要求時間に応じて、複数の起動処理が必要なのです。ここが、初心者が見落としがちな箇所です。アプリケーションノートには、説明を簡単にするため、1アプリ起動例しか載せないことが多いことが原因です。

複数の起動処理としては、1msec/10msec/100msec/1secの4つの時分割起動で、起動側のアプリ例は、表のようにした場合に経験的に上手く機能しました。この時分割は、マイコン内臓タイマを使い、CubeSuite+のコード生成に追加します。これが、前回紹介した追加コードです。そして、このコードを追加したものがテンプレートです。

アプリ起動間隔	起動されるアプリ例
1msec	割込み確認、割込み応答処理など、リアルタイム性が要求される処理
10msec	スイッチチャタリング処理、LCD初期設定など
100msec	LED処理、LCD表示など
1sec	人間相手の処理、ウオッチドックタイマのリセットなど

 

テンプレートの時分割起動部分ソースを示します。これなら、たとえ10ミリsecでSW処理以外に複数アプリが起動されても、アプリ側で“飛ばし”が不要ですので、他のアプリ処理有無に係らずSW処理のプログラミングができます。

 

CubeSuite+は、設定項目が多く、コード生成ツールも、利用する周辺ハードのAPIを自動生成しますが、プロジェクト作成の度にこれらを設定する必要があり、この段階で設定忘れやミスなどが発生しやすく、本来のアプリ開発をする前の手間や時間がかかります。

効果的な対策は、各種の設定済みのプロジェクトを再利用することです。生成ソースの指定エリアに、コードを追加記述していれば、設定を変更して再コード生成しても、追加分はそのままマージされるからです。これで設定ミスなどは減らせます。

追加するコードは、アプリを時分割起動する処理にします。そして、このアプリ起動処理追加済みのプロジェクトをテンプレートにします。アプリ開発は、このテンプレートをコピーし、別名、例えば、アプリ名で保存した後、始めます。アプリを起動する処理は、既にテンプレートに記述済みなので、即アプリ開発に着手できます。

この追加コードの詳細は、近日中に明らかにします。

CubeSuite+のコード生成では、クロック発生回路の“端子割り当て設定タブ”で、“はじめに必ず設定してください。この設定は1度行うと変更できません”と、赤コメントが表示されます。今回は、この理由とコード生成の周辺機能の設定順序について示します。

RL78マイコンは、1つのピンに複数の周辺機能のI/Oピンを割付け可能です。これらI/Oピンには、再配置が可能なものもあります。例えば、64ピンパッケージのRL78/G13の割込みINTP10ピンは、P52かP76のどちらかにでも割付け可能です。コード生成ツール（以下Cgと略す）は、GUIで周辺機能を簡単に設定できますが、対象となる周辺機能がどのピンを使うかが決まっていないと、ピンの競合判断ができません。そこで、最初に、周辺機能ピンの確定が必要になります。これを行うのが、“端子割り当て設定タブ”で、はじめに必ず…が表示される理由です。

Cgのクロック発生回路の次には、上から順にポート、割り込み、シリアル…と続きます。これは、使用頻度の高い機能順だろうと思います。しかし設定する時は、ポートを最後にすることをお勧めします。理由は、Cgが競合判断を行うからです。

ポートでは、各ポートの入出力や内臓プルアップの設定などができます。但し、デフォルトでは、全て“使用しない”となっています。この“使用しない”とは、“単純なI/Oポートとしては使用しないという意味”です。例えば、端子割り当てタブでPIOR0ビット=1にして、INTP10をP76に確定したとしましょう。ポートの“ポート7”タブでのP76は、他のポートと同じ表示です。しかし、割り込みを先に設定した場合には、P76に赤！マークが付きます。このマークにカーソルを合わせると、「P76はINTP10で使われています。」というメッセージが表示されます。Cgが競合ありと判断したのです。

このように、ポート設定を周辺機能の後に行うと、既に使用済みのI/Oピンには、赤！マークが付きますので、デフォルトのままにできます。このマーク付きのピンを、どうしてもI/Oポートとして使いたい場合には、周辺機能を無効にするか、または最初のピン確定を変える必要があります。ピン確定は1度しかできませんので、新たなプロジェクト作成となります。

コード生成（設計ツール）の設定順序をまとめます。

（１） クロック発生回路＞端子割り当て設定タブで、再配置可能な周辺機能の使用ピンを確定。

（２） ポート以外の使用周辺機能を設定。未使用周辺は、デフォルト無効なので、そのままでOK。

（３） ポート＞ポートnタブで、競合なしピンを設定。競合ピンをI/Oピンとして使う場合は、使用周辺機能を無効にするか、新プロジェクト作成が必要。

他の周辺機能に比べ、ポートは、ピン配置の自由度が高いので、最後に設定するのが良いでしょう。Cgでは、クロック発生回路のすぐ下にありますので、先に設定しがちですが、これを先にすると、周辺機能に赤！マークが付いて設定できなくなります。

CubeSuite+のコード生成（以下Cgと略す）の目的は、以前このブログで記載しました。今回は、ユーザ処理の追加方法を示します。

Cgは、使用周辺機能に応じたAPIと、メイン関数を含むテンプレートを生成します。ユーザは、このCg生成ファイルに必要なユーザ処理を追加すれば、プログラムが完成する仕組みです。この仕組みを使って完成したプログラムは、Cg指定のユーザ処理追加部分に記述していれば、RLマイコンの機種やピン数が変わって再コード生成しても、そのままファイルマージされ使えます。APIが、機種やピン数のハード依存部分を隠ぺいするからです。

では、どのようにCubeSuite+へユーザ処理を追加すれば、良いのでしょうか？大別すると、2つあります。１つは、Cg生成ファイルに直接追記する方法、もう1つは、別ファイルで追加する方法です。

APIを活かしてユーザ処理を追加するなら、別ファイルで追加する方法を用いましょう。CubeSuite+のファイルカテゴリ追加機能を使って、コード生成とは別カテゴリを作り、この中にユーザ処理ファイルを追加することをお勧めします。これにより、バグの可能性のあるユーザファイルと、（おそらくバグのない）APIファイルを分離でき、メンテナンス性が向上します。また、ユーザファイルは、機種依存しないハズですから、そのまま別機種マイコンへ移植できる可能性も高まります。

 

CubeSuite+には、5種類のRL78デバッグツールが使えます。今回は、これらのうち、E1、EZ Emulator、シミュレータの解析機能を比較します。

デバッグツールは、バグ取りが主目的です。これに加えて、ツールタイマを使ってプログラム解析もできます。以下に各ツール接続時の解析内容と、画面右下に表示される各ツールのステータス情報を示します。

解析機能	E1	EZ Emulator	Simulator
制御品質解析（変数やパラメタの時間変化）	あり	あり	あり
実行性能解析（関数処理の時間割合）	なし	なし	選択可能
パフォーマンス解析（特定区間の実行時間計測）	なし	なし	選択可能
カバレッジ解析（実行網羅率測定）	なし	なし	選択可能

 

ステータス情報（CubeSuite+画面右下）

 

E1とEZ Emulatorは、CubeSuite+以外に専用ハードウエアが必要です。シミュレータは、CubeSuite+のみで実行できます。E1とEZ Emulatorの違いは、ありません。シミュレータの解析内容が一番豊富です。シミュレータでは、ステータス情報の足/時計/タイルアイコンクリックで解析機能の“あり/なしの選択も可能”です。RL78のカタログに記載されている実行性能解析は、シミュレータでのみ可能です。

しかし、シミュレータ解析は時間がかかります。専用ハードを使うE1とEZ Emulatorは実時間処理なので、実行時間1秒の間に解析結果が得られます。同じ時間をシミュレータで解析すると、制御品質解析に加えて実行性能/パフォーマンス/カバレッジ解析ができますが、トレースメモリを2Mフレーム使用して、1分以上かかります。シミュレータは、トレース範囲の設定とトレース・メモリ・サイズに注意が必要です。E1/EZ Emulatorとシュミレータの使い分けが必要でしょう。

現在入手可能なRL78/G13の評価ボード：QB-R5F100LE-TB、RL78/G13 Stick スターターキット、RSK　for RL78/G13には、どれも外付け20MHz発振器が実装されており、メインクロックを供給しています。

RL78/G13性能は、内臓32MHzをメインクロックとして使った時に最高となるので、なぜ外付け20MHzがこれら評価ボードに実装されているかが疑問でした。

考えられるのは、プログラミングに必須となる可能性です。R8C/25でも同じ経験がありました。そこで、最もシンプルなQB-R5F100LE-TBを使って、プログラミング時に20MHz供給の必要性を検証します。

 

QB-R5F100LE-TBは、ショートパッドのパターンカットでクロック供給/停止を変えられます。結果は、外付け20MHzなしでも問題なくプログラミングでき、プログラミング後、内臓クロックで動作しました。

コスト重視の評価ボードで外付け20MHzの実装の理由は、未だはっきりしません。この疑問が解けましたら、本ブログに記載する予定です。

CubeSuite+がアップデートされると、設計編～メッセージ編のPDFユーザマニュアルも更新されます。ツールニュースでの更新通知で、これら最新マニュアルをダウンロードし、参照される方が多いと思います。このマニュアルのもっと簡単な参照方法を示します。

CubeSuite+ヘルプを使う方法です。ヘルプは、大きく分けて2種類のドキュメントを含みます。チュートリアルと、起動編～メッセージ編までのマニュアルです。後者の内容は、最新ユーザマニュアルと同じです。ヘルプファイルなので、追記はできませんが、PDFマニュアルのダウンロードは不要で、簡単に参照できます。

もう一つのTipsとして、CubeSuite+の出力ウインドのエラーメッセージ番号の上にカーソルを載せて、F1：ヘルプを押すと、メッセージ編の記載場所へジャンプします。出力ウインドよりも詳細なエラー内容や、対処方法が記載されています。頻繁に使いますし、しかも便利な機能です。

 

CubeSuite+は、APIやテンプレートの生成、エディタなど、IDEとして優れた基本機能以外に、“解析機能”を持ちます。この解析機能理解のため、CubeSuite+付属のチュートリアル一読をすすめます。

 

Officeソフトのように、ヘルプを理解するためにヘルプが必要な場合もありますが、このCubeSuite+のチュートリアルヘルプは、中級者であれば理解必須です。以下に、チュートリアルの注意点と記載重要事項を示します。

注意点：

チュートリアルでは、「リセット＆実行ボタン」で結果を出力しています。しかし、同じ結果となるハズの「リセットボタン」＋「実行ボタン」を押した場合と、結果が異なることがあります。チュートリアル実行中に記載と異なる結果の場合には、後者（リセットボタン＋実行ボタン）を試してください。

チュートリアル記載の重要事項：

・静的情報とは、ビルド完了後に表示できる項目。動的情報とは、デバッグ・ツール接続後，プログラム実行後に表示できる項目。

・実行性能の解析目的は，関数単位のCPU使用率を把握し，CPU負荷を軽減する関数を探すこと。

・解析対象の実行時間に対して，トレース取得期間が十分かどうかを判断する事が必要。デバッグ・ツールのプロパティで「トレース・メモリを使い切った後の動作」の設定を「停止する」設定もその一つ。

・解析範囲に対して，解析データ（デバッグ・ツールのトレース・メモリ）が適切か確認することが重要。　

・解析対象に対して，トレース取得期間と実行回数が十分でない場合，解析結果を正しく判断できないことがある。対策として、対象関数が何回実行されたかを関数パネルで把握する事。

・性能解析は、解析対象に応じて，適切な手段を選択する必要がある。解析グラフは，便利なツールだが、使用方法を誤ると適切な判断ができない。

・動的情報が表示できるかは，デバッグ・ツールに依存。RL78/G1xとE1の組合せでは、トレースとパフォーマンス測定はできない。対策は、シミュレータを使うこと。

・パフォーマンス解析目的は、システム性能を満足するために，特定の処理速度が十分かどうかを判断すること。

いかかですか？　中級者は、これらを理解して、作成プログラムの性能改善に活用しましょう。ちなみに、このヘルプファイルは、下記にあります。

C:\Program Files (x86)\Renesas Electronics\CubeSuite+\Help\Tutorial-Analysis.chm