CubeSuite+ Windows8.1 Pro動作確認(最終報告)

トラブル続きであったWindows8.1 Pro上でのCubeSuite+動作が正常に戻りました。

ウイルス誤検出は、定義ファイルが更新されたお蔭か、または、プログラム自身が更新されたかは不明ですが、問題なく動作しております。やはり、OS更新は、発売後2~3日待ってから更新した方がリスクが少ないようです。

これとは関係しませんが、Windows8 Proマシンで1台のみ8.1更新ができない64ビット自作機があります。調べてみると同じようなマシンが結構あるようです。もちろん、Microsoft記載のトラブルシューティングは全て試しましたが、結果はNGでした。

クライアントデスクトップ環境は、Windows7で完成の域に達したと感じていますが、8更新以降、環境劣化していると思うのは私だけでしょうか? ハイブリッドOSで二兎を追うのは判りますが、モダンUI環境だけでなく、デスクトップ環境もアップグレードしてくれないと、新OS導入を控える人が多くなること、圧倒的に多いWindowsデスクトップアプリ資産の今後が多少不安です。

コード生成ひな型出力とユーザ追加ソースファイルの分離メリット

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…*/の間に書き加えた処理は、そのままコード再生成出力ファイルにマージされますので、追加分は、保持されます。これが、コード生成の一般的な使い方です。この場合は、ユーザ追加処理は、コード生成ファイル内に入ります。

r_main.cの中身
r_main.cの中身

提案は、このユーザ追加処理とコード生成のひな型を分離し、別ファイルにすることです。メイン無限ループに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マイコンなどにも適用してみたいと考えています。

CubeSuite+ Windows8.1 Proで動作確認(続報)

先に報告した動作確認の続報です。

21日より突然、コンパイラがウイルスに感染しているとして、ウイルス対策プログラム(Avast:2014.9.0.2006)が動作し、ビルドができなくなりました。Avastチェストから削除プログラムを元に戻しても、一度チェストへ入れられたコンパイラは、残念ながら動作しません。

コンパイラ動作停止
コンパイラ動作停止

Windows8.1は、Windows8よりも、余計なセキュリティが強化されていますので、これかと思い、Windows8 Proへリカバリしても、同様です。

仕方がないので、一度、CubeSuite+を全てアンインストールし、再度インストールし、Avastを停止させて起動したところ正常にビルドできました(コンパイラのみの再インストールでは、解決しません)。原因は、Avast側にあると思いますが、同じようなことが他のセキュリティソフトでも起こる可能性がありますので、注意してください。

CubeSuite+ Windows 8.1 Proで動作確認

17日20時より配布されたWindows 8.1 Pro 32/64ビット版でのCubeSuite+の動作、E1によるデバッグ動作を確認しましたので、速報します。

Windows 8 から 8.1への無償アップグレードは、簡単でした。CubeSuite+やE1もあっけないほど問題なく動作します。個人的には、デスクトップ環境は、Windows 7時代で完成の域に達したと思います。チャームやモダンUIなんか、気分転換に使えるぐらいですものね。

RL78コンパイラコーステキスト要旨(3回目)

RL78コンパイラコーステキスト、2013年5月22日Rev.1.06版の要旨、最後の3回目は、コンパイラ設定です。

コンパイラは、ユーザ記述ソースからロードモジュールを作成します。この時、使用するマイコンに応じて、いろいろなコンパイル・オプションの設定が必要になります。このオプション設定がまずいと、「良いモジュール」ができないからです。もう1つ記述時に重要なことは、ソースプログラムの書き方です。

コンパイラ設定の要旨

本対象マイコンでは、コンパイル・オプションのメモリ・モデルを、「スモール・モデルに設定」することが必要です。デフォルトが、ミディアム。モデルになっているからです。

CubeSuite+は、良いモジュールを作るために9個のコンパイル・オプションを組合せて、標準、サイズ優先、速度優先、詳細設定、いいえの5種類の作成方法(最適化)を予め用意しています。オプションと最適化の関係は、以下になります(テキストの抜粋表に追記)。

コンパイル・オプション設定

最適化の種類

標準 サイズ優先 速度優先 詳細設定 いいえ
1 演算式の実行順序入替え

×

2 自動変数をレジスタまたはsaddr領域に割当

×

3 レジスタ変数をレジスタに加えsaddr領域に割当

×

×

×

×

4 char演算の符号拡張なし

×

5 char型をunsigned charとみなす

×

×

×

×

6 分岐命令を最適化

×

7 定型コードをライブラリに置換え

×

×

8 相対分岐でswitch分岐テーブル生成

×

×

×

×

9 デバックに適した最適化

×

×

×

×

◎:強力に実施、○:実施、×:実施なし、△:カスタム(自由設定)

最も標準的なオプション設定の組合せが「標準」で、デフォルトになっています。サイズと速度ともに効果がある1、2、4、6オプションなどは、○:実施に設定です。「標準」、「サイズ優先」と「速度優先」の差は、オプション7の定型コードをライブラリに置換えるか否かのみです。つまり、「標準」でかなり最適なモジュール作成ができていて、さらにモジュールサイズを圧縮するなら「サイズ優先」、速度を上げるなら「速度優先」に変更すれば良いことが判ります。

「詳細設定」は、全オプションを自由に設定するモードで、この時のみ9個のコンパイル・オプションが画面表示されます。他の最適化の時は、個々のコンパイル・オプションは表示されません。「詳細設定」ではオプション設定が自由ですので、各オプションの差分評価などの用途と思われますが、サイズ大で速度も遅いモジュールが生成されたりもしますので、使うことはないでしょう。また、「いいえ」は、全オプションを設定しないモードで、これも使わないでしょう。

結局、最適化は、デフォルトの「標準」のままで良く、どうしてもサイズや速度を改善したい時は、「サイズ優先」か「速度優先」を選択します。但し、差分は、定型コードのライブラリ化のみで、記述ソースにもよりますが、効果は期待できないかもしれません。

オプション3のレジスタ変数をレジスタに加えsaddr領域に割当は、何の効果もないので設定不要、オプション8の相対分岐でswitch分岐テーブル生成は、対象マイコン外なので設定不要、オプション9のデバッグ最適化は、内容不明でした。

ソースプログラムの書き方要旨

オプション5のchar型をunsigned charとみなすは、ソースプログラムの書き方に関連します。RL78マイコンで使う整数型変数は、「符号なしの8ビットまたは16ビットが最も効率的」にコンパイルされます。型宣言にcharやint、shortのみを記述すると、デフォルトでは「符号つきのsigned変数」になります。このオプション設定で、char型変数は符号なしにみなされますが、int、shortはそのままです。対策は、「整数型宣言は、必ずsignedかunsigned を付け、符号の有無を明記する」ことです。

RL78マイコンの汎用レジスタは、16ビットです。従って、32ビットのlong変数は避け、「できる限り8ビットまたは16ビット変数を用いると、効率的」な結果が得られます。

#pragma以降のキーワード(例えば、EI、DI、NOP、HALTなど)は、大文字でも小文字でも記述可能ですが、関数内で使う時は、大文字記述時のみ有効なので、「大文字で統一」した方が混乱は避けられます。

呼出される関数にcalltを付けると、通常よりも短いコードで関数呼出しができます。つまり、サイズ優先の書き方です。但し、速度は遅くなります。calltが使える関数は、最大32個です。対象マイコンは、64KBの大容量ROMですので、この「callt記述を使う可能性は低い」と思います。

saddr領域とコンパイラ固定使用領域

第1回のRAMメモリマップで示したように、saddr領域とは、マイコンRAM内:FFE20~FFEB3の148バイトのことです。コンパイル・オプション2の自動変数をレジスタまたはsaddr領域に割当が、○:実施されていることから、最適化に有効な領域であることが判ります。

saddr:ショート・ダイレクト・アドレッシング領域は、8ビットコードでアクセスできるので、サイズ、速度ともに向上します。レジスタとほぼ同じと考えて良いでしょう。「標準」最適化で、コンパイラにより、関数内の自動変数はこのsaddr領域へ割付けられます。また、コンパイル・オプションのデータ制御項目で、static/外部変数をsaddr領域へ自動的に割付けることもできます。この自動割付けが嫌なら、ソース内でユーザが明示的にsregを付けた外部変数、関数内のstatic変数の割付けも可能です。非常に有用な領域で、RL78マイコンを使いこなす技を生むポイントですが、148バイトしかありません。148バイトを超えて使用すると、コンパイルエラーが発生します。

この少ないsaddr領域の対策として、コンパイラ固定使用領域:FFEB4~FFEDEの44バイトのうち、FFEB4~FFED3の32バイトをsaddr領域へ変更することができます。これで、合計148+32=180バイトがsaddrユーザ領域になります。但し、制限として、標準ライブラリのsetjmp、longjmp、sprintf、sscanf、printf、scanf、vprintf、vsprintf、ldiv関数を使わないことと、コンパイル・オプション3のレジスタ変数をレジスタに加えsaddr領域に割当てを、×:実施しないことが条件です。もちろん、「標準」最適化では、このオプションは、×:実施なしですので、printfなどの標準ライブラリ関数を使わなければ、条件を満たします。

CubeSuite+は強力なデバッグ・ツールを持ちますので、printfを使う機会は少ないと思います。ビルド・ツールの変数/配置オプションタグのROM/RAM使用量を、はい:表示へ変更すると、saddr領域の使用量も表示されますので、148バイトよりも大きくなった時は、コンパイラ固定使用領域をsaddr領域へ変更すれば、32バイトの追加ができます。

 

以上

3回にわたって、RL78コンパイラコーステキスト、2013年5月22日Rev.1.06版の要旨を解説しました。このテキストは、非常に有用な事項を記述していますので、ぜひ、ご自身で精読されることをお勧めします。セミナに参加すれば、記述内容だけでなく、その背景や行間/ページ間の意味、重要度などいろいろなことも把握できるでしょう。残念ながらテキストのみでは、書かれてないことは推測するしかありません。本要旨では、テキストの要旨だけでなく、いろいろ推測を加えた部分もあります。また、解説もコンパイラとリンカに絞り、対象マイコンも絞って説明しました。別側面からテキストを観た結果であり、ご参考になれば幸いです。

RL78コンパイラコーステキスト要旨(2回目)

RL78コンパイラコーステキスト、2013年5月22日Rev.1.06版の要旨、2回目の今回は、スタック設定です。

スタック設定の要旨

スタックとは、RAM内にある特別な領域のことです。関数の呼出し時に、最低限必要なデータを、このスタック領域へ積み重ねて一時保存し、呼出された関数の処理が終わったら、そのデータを使って呼出し側の関数へ戻ります。使い終わったデータは、積み重ねから取り除きますので、スタック領域は、関数呼出し毎に使用サイズが増えたり減ったりします。

最低限必要なデータとは、1.関数の引数で汎用レジスタに割り付かないもの、2.関数の戻り番地、3.使用する汎用レジスタの退避領域、4.関数の局所変数で汎用レジスタに割り付かないもの、5.コンパイラ処理上必要になったワーク領域、などです。

関数を呼ぶだけで、これらデータの一時保存や、このような複雑な処理をしているのです。しかも、関数呼出し経路や、割込み順位に応じて使用サイズが変わるので、最大スタックサイズを求めるのも大変です。しかし、CubeSuite+では、スタック見積もりツールが用意されていて、自動的に(コンパイラ設定でアセンブル・ファイル出力の「はい」変更は必要)関数毎の使用サイズが求まります。このツールを使えば、プログラマが意図した関数の呼び出し経路かどうかの確認もできます。

マイコンソフトの出荷時には、「必ずスタックサイズを求め、必要サイズ分を1回目で説明したリンク・ディレクティブを使って確保すること。この確保値は自動的に更新されないので、スタックサイズを反映させるのは、プログラマの責任」とテキストには明記されています。例えば、再帰呼出し関数などを使ってスタックが不足するような場合は、異常終了などを引き起こしますので、スタック領域の不足は避けなければなりません。テキストには、スタックサイズを削減する方法も記載されています。

では、出荷時前のデバッグ時はこのスタックサイズがどのように確保されているかというと、リンカがRAM領域の一番大きいGap(空き領域)を見つけ、自動的にスタック領域を確保しています。確保領域は、ビルド・ツール生成ファイル:*.symファイルの、@STBGN~@STEND間です。@STBGN>@STENDなので、スタック領域が上位アドレスから下位側へ使われることが判ります。一方、コンパイラ領域は、下位アドレスから上位側へ使われます。RAMに両方の領域が隣り合わせに配置されても、領域侵犯の可能性が少ない方法です。

対象マイコンのスタック領域確保の必要性

RAM 4KB/5.5KBの対象マイコンを、シングル・チップで動作させるシステムでは、ここで解説したスタック領域確保は不要と思います。スタック見積もりツール算出のスタックサイズよりも大きければ、リンカが確保する最大Gapの場所が、スタック領域としては最適で、リンカ任せでも大丈夫と考えるからです。

システム拡張/変更に対して内臓RAMの空きが少なくなりスタックサイズを削減する場合、リンカの代わりにプログラマ自身でセクション配置をする場合の方法として知っておけば十分でしょう。対象マイコンでRAM空き領域が少なくなった時には、経験上、このような対処療法より、より大容量RAMを持つ機種への変更の方が安全、かつ、費用対効果も高いのでお勧めです。

RL78コンパイラコーステキスト要旨(1回目)

RL78コンパイラコーステキスト、2013年5月22日Rev.1.06版の要旨を3回に分けて解説します。

このテキストは、 ルネサス半導体トレーニングセンターの2日間セミナ「RL78 コンパイラコース」用に作成されたもので、RL78/G14を対象に、コンパイラとリンカ、周辺機器、割込み処理という盛りだくさんの内容です。セミナ参加が困難な私のような地方技術者にとっては、テキスト公開だけでもありがたいです。テキスト内容が濃いので、初心者向けにここでは、リンカとコンパイラに絞って解説します。

今回はリンク・ディレクティブ、2回目は、スタック設定、これら2回がリンカ関連、3回目がコンパイラ関連です。入手が容易で、評価キットにも良く使われる以下2種マイコンの具体例を示します。

対象マイコン

  RAM容量 ROM容量 データ・フラッシュ容量
RL78/G13:S2コア

4KB

64KB

4KB

RL78/G14:S3コア

5.5KB

 

リンク・ディレクティブ要旨

先ず、リンカとコンパイラを簡単に説明します。コンパイラは、ユーザ作成のプログラムを、変数や定数、プログラムコードなどの「種類別に1つのかたまり」にまとめ、リンカに渡すロードモジュールを作成します。この「かたまりをセクション」と呼び、変数のかたまりをデータセクション、プログラムコードのかたまりをコードセクションなどと呼びます。リンカは、コンパイラが作成した各セクションのロードモジュールを、マイコンのROMやRAMに割付け、オブジェクトを生成します。今回と次回は、このリンカ関連の説明です。

リンク・ディレクティブとは、リンカへのセクション単位の「追加ユーザ割付指示ファイル」のことです。「ユーザ」とわざわざ但し書きしたのは、CuiteSuite+のデフォルトのリンク・ディレクティブ:r_lk.drは、別のところ(場所は不明)にあり、このデフォルト指示に従ってリンクすれば、問題なくオブジェクトが生成できるからです。このため、CubeSuite+のプロジェクト・ツリーには、r_lk.drが表示されません。ユーザが指示を追加する場合は、「追加分のみを記述した」user.drを作成し、プロジェクト・ツリーに追加します。

追加ユーザ指示が必要になるのは、1.スタック領域の設定、2.saddr領域拡張の設定、3.データ・フラッシュ使用時、専用ライブラリ使用領域の確保、の3つの場合です。1と2については、2回目以降にそれぞれ解説します。

3のデータ・フラッシュは、RL78ファミリマイコンならば実装済みの周辺機能です。RL78/G13にはデータ・フラッシュ無しのデバイスもありますが、電源なしでもデータ保持ができる一種のROMです。プログラムで書き換えができるのでRAMでもあり、重要なパラメタなどを記録するのに便利な機能です。

データ・フラシュを使うには、ルネサス提供の専用ライブラリ:データ・フラッシュ・ライブラリ  Type04 Ver.1.05が必要で、このライブラリ動作のためにRL78/G13ならFEF00h ~ FF2FFh、RL78/G14ならFE900h ~ FECFFhのRAM下位アドレスから1KBを専有します。さらに、データ・フラッシュ利用に関係なくRAM上位アドレスは、汎用レジスタ、コンパイラ固定使用領域、saddr領域が合計で224バイトを専有します。そのため、RL78/G13とRL78/G14の全RAM容量から、これらの専有領域を引いた残りの2848/B20hバイトと4384/1120hバイトが、コンパイラにとって自由に使えるコンパイラ領域になります。つまり、ユーザ作成プログラムの変数などは、コンパイラがデータセクションにまとめ、リンカがこのRAM領域へ配置します。

RAMメモリマップ RL78/G13 RAM4KB(右)とRL78/G14 RAM5.5KB(左)
RAMメモリマップ RL78/G13 RAM4KB(右)とRL78/G14 RAM5.5KB(左)

従って、データ・フラッシュ利用時は、ユーザが、追加リンク・ディレクティブで、このことを追記する必要があります。データ・フラッシュ実装マイコンでも、これを使う/使わないはユーザまかせですので、使わない場合をデフォルトとして記述がないからです。このユーザ追記は、以下のようになります。

【 データ・フラッシュ利用時の追記リンク・ディレクティブ 】

MEMORY RAM : ( 0FF300H, 000AA0H ) ; RL78/G13 RAM4KB、ROM64KB、データ・フラシュ4KB

MEMORY RAM : ( 0FFD00H, 001020H ) ; RL78/G14 RAM5.5KB、ROM64KB、データ・フラシュ4KB

但し、上記は、さらにSTACK領域に128/256バイトを割当てた例で、これをuser.drファイルとしてプロジェクト・ツリーへ追加すれば、データ・フラッシュ・ライブラリが使えるようになります。

RL78/G13、G14の割込み処理設計

RL78/G1xの割込みは、様々なアプリに対応できるように設計されています。しかし、そのハード構成などから、最も適した使い方があります。ここでは、その使い方を解説します。

割込み処理は、マイコン開発にとって重要ポイントです。しかし、機種特定の解説書は、見あたりません。RL78/G1xのアプリケーション・ノートにも、2013年8月時点では無いようです。あまりにも当然の事として、ルネサスは、解説不要と考えているのかもしれません。

そこで、ハード構成やレジスタ・バンク個数などから、素直な、おそらく最もスジが良い割込み処理の設定について考察します。開発当初から、この設定でソフト開発していれば、後々のトラブル回避にも都合が良いと思います。

結論を示します。ハード構成から、多重割込み処理の最適なパラメタ設定は下図です。赤字は、デフォルト以外の設定値を示します。

最適な割込み処理パラメタ設定
最適な割込み処理パラメタ設定

割込み優先レベルとデフォルト・プライオリティ

マスカブル割込みには、各割込み要因に対して0から53までの、「デフォルト・プライオリティの割込み順位がハードで設定済み」で、0が最高位、53が最低位です。これとは別に、「プログラマが設定可能な割込みの順位が、優先レベル0/1/2/3」です。レベル0が最高、レベル3が最低ですが、CubeSuite+のコード生成ツールでは、レベル0を高、レベル3を低、レベル1/2はそのまま表記します。

デフォルト・プライオリティは、複数の割込み要因が、同じ割込み優先レベルで発生した場合に、優先する順番のことで、通信関連の要因は高く、次がAD、タイマ関連が低いなど、マイコン機種に依存せず大体同じ順番です。一方、割込み優先レベルは、CubeSuite+のコード生成ツールで、「低にデフォルト設定」されています。何も考えずに、コード生成すると、「割込み処理は、全てレベル3に設定」されます。割込み優先レベル、次にデフォルト・プライオリティの順番で優先判定しますので、結局、デフォルト・プライオリティ順位がそのまま割込み受付順位となります。

多重割込み

割込み処理中に、より高い優先レベルの割込みを受け付けるか否かを決めます。デフォルトは、「多重割込み禁止」なので、割込み処理内でEI();により明示的に許可が必要です。最高レベルのレベル0でも許可は可能ですが、レジスタ・バンクが4個のため、避けるのが得策です。

レジスタ・バンク

RL78/G1xの汎用レジスタ格納場所がレジスタ・バンクで、RB0/1/2/3の4個あります。スタートアップで「RB0がデフォルト設定」されており、通常プログラムは、RB0を、割込みプログラムが、残り3個のRB1/2/3を使えます。割込みプログラムでの、レジスタ・バンクの使い方は任意です。コード生成出力は、「全ての割込みプログラムのレジスタ・バンクをデフォルトのRB0に設定」します。

このように、割込み処理のパラメタデフォルト設定値は、全処理で割込み優先レベル3、多重割込み禁止、RB0のみ使用となります。この設定では、本来のハード実力を活かした割込み処理はできません。

割込み優先レベル、多重割込み、レジスタ・バンク、それぞれがともに4個の選択肢があることには、関連があり、最大で4レベルの多重割込みを処理できることを示しています。但し、その最高レベルの0だけは特別で、通常の割込み処理には、レベル3~1を使うのがハード構成に適した使い方です。

レベル0は、最低限の処理を実行後、リセットするような特別な割込み処理用で、例えば、電圧低下を検出して、低下直前の動作状態を保持する用途などが考えられます。従って、専用レジスタ・バンクも不要ですし、多重割込みもなしです。処理後は、リセットするからです。万一、EI();で多重許可した場合には、割込み処理中に、受付けた割込みを再受付するようなトラブルに見舞われます。このトラブルは、結構ありがちです。最優先レベル0の多重割込み処理は、避けるべきです。

割込み優先レベル3~1は、多重割込みを許可し、専用レジスタ・バンクを設定しさえすれば、簡単に、しかも高速に3レベルの多重割込み処理が可能です。スタックを使っても同じ事ができますが、レジスタ・バンクの方が高速ですし、その分スタック節約にもなります。3レベルの処理なら、割込みレベルの割当ても容易です。最高優先処理をレベル1、最低優先処理をレベル3に割付け、それ以外は、レベル2に割付けても問題が発生したことは経験上ありません

まとめ

割込み処理のトラブルは、処理ソフトのバグ以外にも、優先順位に起因するものもあり、難しいデバッグになりがちです。ソフト設計当初に、ここで示したハード構成に適した多重割込みパラメタを設定することがトラブル回避に役立ちます。

時分割処理切換えタイマの考察

販売中のRL78/G1x用のテンプレートは、タイマを使って、タイムシェアリング:時分割でタスク切換えを行います。RL78/G1xは、8チャネルのタイマ・アレイ・ユニットを最大2個持つので、8x2=16個のタイマの中から、どのタイマが時分割切替え処理に適すかを考察します。

※RL78/G13は、タイマ・アレイ・ユニットあたり8チャネル、RL78/G14は、4チャネルを持ちます。各チャネルは、同じ機能なので、ここでは、RL78/G13の場合で記述します。

タイマ・アレイ・ユニット1は、80ピン以上のパッケージで実装されます。テンプレートは、全パッケージで共通にしたいので、現在販売中の全パッケージに実装済みのタイマ・アレイ・ユニット0の中からから使用タイマを選びます。

次に、タイマ・アレイ・ユニット0の割込み要因デフォルトプライオリティ順位は、チャネル0が一番高く、チャネル7が最低です。時分割切換え処理のプライオリティは、低い順位の方が良いでしょう。より緊急度の高い処理などを先に実現できるからです。

また、チャネル0から2は、全パッケージでタイマ入出力端子があります。この端子がないと、インターバルタイマとして動作しますが、端子がある場合は、外部ペリフェラルとの同期動作が可能となります。

※RL78/G14は、全パッケージでチャネル0から3の入出力端子があります。

まとめると、1)全パッケージ実装のタイマ・アレイ・ユニット0、2)低いデフォルトプライオリティ順位、3)外部同期動作可能、以上の要求を満たす、タイマチャネル02が、時分割処理の切換えタイマに適すことが判ります。また、タイマチャネル02なら、RL78/G13とRL78/G14でテンプレートを共通にすることも可能です。

RL78ファミリ用ライブラリリビジョンアップ制限事項とは?

2013年8月8日、RL78ファミリ用EEPROMエミュレーションライブラリ Pack01がVer.1.13へ、データフラッシュライブラリ Type04がVer.1.05へリビジョンアップされました。目的は、RL78/G1xデータフラッシュ機能の読出し制限事項への対策です。この制限事項を解説します。

RL78/G1xには、プログラムを格納するコードフラシュと、データを格納するデータフラシュの2種類のフラッシュがあり、それぞれに以下のライブラリが提供されています。

対象 ライブラリ名 最新バージョン 解説
データフラッシュ EEL (Pack01) V1.13 FDLを利用してデータフラッシュを外付けEEPROMと同じように使えるライブラリ
FDL (Type01) V1.12 データフラッシュにアクセスするライブラリ。ライブラリのサイズにより、Type01/04の2種類がある。サイズが小さいのは、PicoバージョンのType04。
FDL (Type04) V1.05
コードフラッシュ FSL V2.20 プログラムをCPU動作中に書換えるライブラリ

EEL: EEPROM Emulation Libraries, FDL: Flash Data Libraries, FSL: Flash Self-Programming Libraries

今回のリビジョンアップは、テクニカルアップデート:TN-RL*-A009A/Jによると、DMA利用の場合と、旧ライブラリのあるCPU命令の組合せ、この2つの場合に発生する問題へ対応したそうです。FDLでは、シーケンサと呼ばれる(おそらく)ハードウエアで処理の一部を代行します。CPU以外に並行動作するハードウエア(この場合、DMAやシーケンサ)と、CPU処理のアクセス競合を避けるための工夫がライブラリに加えられました。

1000円で販売中のRL78/G1xテンプレートにもFDL(Type04)が使用中です。今まで、上記問題発生は確認しておりません。しかし、掲記の問題発生を避けるためにも、ライブラリをリビジョンアップして提供する予定です。