IoT MCU開発お役立ち情報満載
RL78/G1x開発用に最適な市販ボードを見つけましたので紹介いたします。
秋月電子通商の、印）NGX社BlueBoard-RL78/G13_64pin、3800円です。LCD、UARTドライバ×2、ADC用ポテンショメータ、LED、ブサー、E1インタフェースなどが実装済みで、単独のRL78/G13CPUボードにブレッドボードなどでLCDやUARTドライバを追加するよりもお得です。また、RL78/G14も同じ基板で動作します。NGXサイトではRL78/G14用BlueBoardも販売中ですが、自信がある方は、ご自分でCPU載せ替えもできるでしょう。
1点だけ残念なのは、LCDインタフェースが、使用頻度の高い4ビットインタフェースではなく8ビットインタフェースになっている点です。実装マイコンが64ピンなので余裕があるためでしょう。弊社RL78/G1xテンプレートは4ビットインタフェースで開発しましたが、この8ビット版へも、sfr設定、LCD初期設定、LCDコントローラへ書込みの3関数の一部のみを変更して対応できました。
スタートアップ処理は、本来変更不要です。但し、唯一変更したい箇所が、デフォルト24MHzのシステム動作クロック設定：SystemSetupClocking()です。テンプレートは、CPU最大速度の30MHz動作にします（目的は、後述）。このシステム動作クロックは、ユーザプロジェクト処理のHdwInit()で再設定も可能です。しかし、一旦設定したクロックを再度設定するのは、なんとも気持ちが悪いです。このクロックはマイコン全ハードの動作を決めるので、SleepやPower_Downで止める以外は、安定発振が無難だからです。
LPCOpenサンプルソフトのシステム動作クロック設定関数SystemSetupClocking()を観ると、API関数に、やたらと1や2などの数値パラメタを代入しています（L103と112）。これは、CubeSuite+コード生成ではGUIで設定するパラメタを、LPCXpressoでは、API関数に直接代入して動作を変えるからです。GUIか、パラメタ代入か、どちらが簡単かは、意見の分かれるところですが、私はGUIが好きです。パラメタの場合は、マニュアルを読みながら値を設定する必要があるからです。
私のようなGUI好きな人向きに、システム動作クロックのパラメタを算出するExcelツールがあります。
Excelツールは、内臓PLLのMain CLKとFinを設定すると、システム動作クロック設定に必要となるMSEL、SPEL、DIVの3パラメタを算出します。２ページ構成で、１ページ目にPLL outのMain CLKとFinの入力セルがあります。ここへ60MHz、12MHzを設定します。するとPLLが安定動作する（緑エリア）MSELとPSELが4，1と判ります。また30MHz のSystem Clockには、SYSAHBCLKDIV＝DIVのラジオボタンで2を選択すれば良いことも判ります。マニュアルを読むよりも簡単です。算出パラメタをAPI関数へ代入して、デバッガでSystemCoreClockをプローブすると、30MHzに変わったことが確認できました。
テンプレートは、システム最大動作速度の30MHzで開発します。これは、最短で処理を行うためです。そして、処理後はCPUをSleep（RL78/G1xはHALT）させます。この時は、周辺回路だけが動作します。Tick割込みでCPUのSleepは解除され、再び同じ動作を繰り返します。CPU最大速度とSleepの時間割合で最終的な消費電力が決まるわけです。つまり、CPUは時分割動作します。
例を示します。表示デバイスとして良く使うLCDの初期化には、数msec以上の待ち時間が必要ですが、この時間をCPUが待つのはムダです。そこで、この間はSleepし、数msec経過後に起き上がってLCD処理を行うなどです。これは、RL78/G1xテンプレートに添付したLCDアプリ例で実施しています。
テンプレートを当該アプリへ適用した後に消費電力を調整します。LPC8xxの場合は、Excelツールを使ってシステム動作クロックを徐々に下げ、時分割処理が達成でき、かつ、消費電力も低くなるシステム動作クロックを探します。システム動作クロックを下げればCPU消費電力は下がりますが、逆に処理時間は長くなりSleepが短くなるので、この方法で、両者のバランスがとれたクロック速度を探します。
RL78/G1xテンプレートの場合も同じです。CubeSuite+コード生成は、GUIで動作クロック速度を選択し、コード生成をクリックすると、ユーザプログラムに上書きされるので、作成ソースをいじることなく簡単安全にクロック速度の変更ができます。やはりGUIの方が楽ですね。
携帯やスマートフォン搭載のマイコンは、バッテリを長持ちさせるために、あらゆる方法を駆使して消費電力を下げる工夫をしています。ここで示したシステム動作クロックを下げるのも、その方法の１つです。
システム最大動作クロックをテンプレートに適用した後にアプリを開発すれば、消費電力を削減する方法が明確になりますし、その方法も簡単です。後は、この方法を成功させるように、CPU時分割処理向きのアプリを開発すれば良いのです。
LPC8xxテンプレート開発時に参考にするサンプルソフトの構造について説明します。
RL78/G1xの無償IDEは、CubeSuite+、GUIで周辺回路のパラメタを設定すると、使用分の周辺回路APIが生成される優れものです。詳しくは、コチラの記事などを参照してください。一方、LPC8xxの無償IDEが、EclipseベースのLPCXpressoです。パソコンへのインストとアクティベーションなどは、トラ技2014年2月号やLPCXpressoサイトを参照してください。LPCXpressoもCubeSuite+と同様、サンプルソフトがIDEに付属しています。
LPCXpressoをインストし、付属サンプルNXP_LPC8xx_SampleCodeBundle.zipをIDEへ展開後、そのソースを読む際のポイントは、サンプルソフトの構造です。構造の解説文が少ない（見あたらない）ので、説明を加えます（付属LPCXpresso User GuideはIDEの使い方解説書です）。
Blinkyを例に示します。組込みソフトは、2つの処理から成ります。「スタートアップ処理」と「ユーザプロジェクト処理」です。スタートアップ処理は、電源ONで自動的に実行されるResetISR()で、メモリなどの初期設定を行います。次にSystemInit()で、動作クロックなどのシステム関連の設定を行います。その後、ユーザプロジェクト最初の関数main()をコールします。
ユーザプロジェクト処理は、無限ループの前に2関数をコールします。HdwInit()で、使用する周辺回路の初期設定を行い、UserInit()でその他の初期設定を行った後に無限ループします（HdwInit()とUserInit()は、説明の都合上作成した関数名です）。
各関数は、NXP社提供のLPC8xxライブラリと、ARM社提供のCortex-M0+コアライブラリを使っています。またユーザが作成する関数も、これらライブラリを使って作成します。つまり、これらのライブラリがAPIを提供しているのです。ライブラリで初めから全てのAPIを提供しているところが、CubeSuite+と違う箇所です。
スタートアップ処理は、全てのサンプルプロジェクトでほぼ共通ですが、ユーザプロジェクト処理は、サンプルにより使う周辺回路が違いますので異なります。普通は、1個のサンプルプロジェクトで、1種類の周辺処理を紹介しますので、無限ループは文字通り簡単な無限ループで終わるものが殆どです。
スタートアップ処理の要は、最低限の動作ができる環境を作成するのが目的で、ブートストラップと呼ばれるゆえんです。パソコンのBIOSに相当する部分と言えば解り易いでしょうか？ IDEのデバッガ動作時には、この部分は飛ばしてメイン関数の入口からデバッグを開始します。つまり、本来は、必要性が無い限り、変更不要と考えても良いでしょう。
ユーザプロジェクト処理も、無限ループ前を「周辺回路の初期設定：HdwInit()」と「その他のユーザ初期設定：UserInit()」に分けて考えると、参考にする部分がより明確になります。HdwInit()は、周辺回路の使い方が同じならそのままコピー利用もできます。但し、CubeSuite+と違って、LPCXpressoの場合はAPIパラメタで回路動作が変わるので、APIソースを解読する必要もあります。
サイズが大きいプログラムも、結局は無限ループ部分が大きいだけで、構造は同じです。大きな無限ループ部分の流用性や可読性を上げるために、ファイル分割などの技術を使っているだけです。
この構造が理解できると、サンプルプロジェクトの見通しが良くなります。そして、せっかく提供されているサンプルを上手く利用し、複数処理を実行するには、「無限ループ箇所を工夫すれば良さそうだ」、ということも判ります。組込み用のリアルタイムOSなども、この工夫の結果できたものと理解しても良いでしょう。但し、リアルタイムOS利用時は、OSの理解や面倒なオーバーヘッドも生じます。販売中のRL78/G1xテンプレートやLPC8xxテンプレート（近日発売予定）は、もっと手軽に複数処理を実現するものです。
組込みマイコンの分類図を、チップワンストップサイトで見つけました。この図は、チップワンストップで販売中のマイコンですので、「入手性が良いマイコン」と言えるでしょう。新規マイコン開発にあたり、どの機種を選択するかの残りの指標は、「入手価格」と「開発のし易さ」、「将来にわたる入手性」です。緑がARMコアマイコン、青がオリジナルコアマイコンを示しています。
8/16ビットマイコンは、過去、現在と各社からいろいろな機種が発売されてきました。全て青のオリジナルコアマイコンで、開発手法やIDEも各社ハラバラでした。より性能の良いオリジナルコアにより、囲い込み戦略がとられていました。これら従来機の製造は、米）ロチェスター社との連帯により、将来にわたる入手性を保証する方法が、ルネサスなどで取られています。
一方、32ビットマイコンは、緑のARMコアが大半です。米）マイクロチップとオン・セミコンダクターを除く各社が、ARMコアのラインアップを提供しています。マイコンは、従来のコア差別から、周辺回路差別戦略へシフトしているといえます。実際、各社の周辺回路は、（少なくとも見た目は）16ビット機でも32ビット機でも同じものを使っています。米）サイプレス社などは、アナログ周辺回路を実装し、同じARMコア機でありながら十分な差別化も達成しています。
全ての機器がネットに繋がるIoT時代のマイコンには、通信制御は必須で、それなりの能力は必要です。これには、既存8/16ビット機で頑張るよりも、32ビット機が適しています。低消費電力と高速化の両方を追求し、IoT要求にマッチするコストパフォーマンスを満たすコアの解として、ARMコアは優れているのでしょう。また開発環境もほぼ同じなので、開発のし易さも（慣れれば）Betterです。さらにARM社は、32ビット機でありながら、8/16ビット市場を狙う低価格なCortex M0+を投入しましたので、新製品マイコンコアは、ARM独占になる可能性もあります。
ARM派にとっては当たり前のことですが、世界標準と言われるCMSISを使ったアクセスやEclipse IDEなど、Non ARM派にとって「？！」を感じる箇所は多くあります。このブログではこの違和感を記載していきます。Non ARM派がARMを知る時、各自の取得技術側からARMを診ると、より効率的にARM習得ができるからです。
2014年1月21日、ルネサスエレクトロニクスは、自動車、産業機器向けの長期安定供給が求められるマイコンなどの製品を対象に、今後10年/15年/20年以上の３パターンで、供給（予定）期間のサイト掲載を始めました。
本ブログ記載のRL78/G13: R5F100LEAFBは、20年以上、RL78/G14: R5F104LEAFBは、15年の予定に属しています。R8C/25: R5F21256SNFPは、10年です。先日のJake Dyson Products LED照明の37年以上のライフに比べると、短い気もしますが…。大手が独り勝ちする半導体の世界では、会社自体がいつ消えるかも判らない状況ですので、ルネサスエレが存続する限りは、安心して使えそうです。
2013/12/16発行のルネサスエレクトロニクス アプリケーションノートに「A/Dコンバータの精度を向上させる方法」:R01AN1843JJ0100がありましたので解説します。
このアプリノートは、Smart Analog内臓のRL78/G1Aを対象デバイスとしていますが、「RL78/G13やG14などの普通デバイス」にも適用できる内容が記載されています。そこで、この普通デバイス：RL78/G1xのADC変換精度向上方法のみを抽出します。
| 精度向上方法 | 内容 |
| ハードウエアのノイズ対策 | アナログ基準電圧端子：AVrefp/AVrefmの使用 |
| アナログ入力端子に10pF～0.1uFのコンデンサ実装 | |
| アナログ信号とデジタル信号の分離、近接回避 | |
| 基板アナログ領域とデジタル領域の分離、両者の1点グランド接地 | |
| ソフトウエアのノイズ対策 | ADC実行中のアナログ端子近傍デジタル入出力の停止 |
| ADC変換直後のHALT実施 | |
| ADCデータ平均化 |
全てA/D入力信号に対するノイズ対策です。アナログ端子に高精度チャネルと標準チャネルがあるRL78/G1Aに対し、（おそらく）全てが標準チャネルのRL78/G1xでも、できうる範囲でこの対策に沿ってADCを使うと精神的には安心できそうです。アプリノートには、定量的な対策実施済みのADCデータ平均化なしと5回平均の精度差、他社マイコンとの誤差比較も記載されています。
販売中RL78/G1xテンプレートでも評価したいところですが、評価設備が無いのと、（おそらく）ハードの依存性が高いでしょうから、定性的にADCを診てみます。AVrefp/AVrefm端子の使用、これらに一番近いANI2端子の使用、100ms周期の2回取得値一致によるアナログ値確定、ADC変換直後ではないがHALT利用など、完璧と言えませんが可～良の判定でしょうか。
仮想お客様開発ボード：BlueBoard-RL78/G13_30pin-Hへのテンプレート移植の3回目は、その２で示した移植手順3以降を解説します。
マイコンで複数処理をシステムとして上手く動作させるポイントの1つが、割込み処理です。この割込み処理を効率的に使うために、レジスタ・バンクの設定をします。詳しくは、コチラをご覧ください。移植ボードで使うレジスタ・バンク設定は、テンプレートの設定をそのまま使います。
移植ボード回路図からテンプレートのuserdefine.hポート番号の論理名定義を変更します。
移植ボードの動作は、1. 電源ON後、uart1へ起動メッセージ出力、2. uart1経由で1文字コマンドを受信し、コマンドに応じてA:ADC値をuart1へ出力、B:ブザートグル出力、L:LEDトグル点滅、3. User SW押し下げでLEDとブザーのトグル動作とします。
テンプレート移植例なので、簡単な動作にしました。関数間の入出力データは、マイコンRAMを使っていますので、関数間の独立性や単体試験は容易です。
Version2テンプレート提供中の全機能と、開発ボードへ移植する機能を示します。User SWは、INTP1に接続しているのでコード生成のINTP1割込み処理、Buzzerは自励式なので、LEDドライバで対応します。
| ファイル名 | 機能概要 | 備考 | ボード移植 |
| main.c | 起動処理 | アプリとドライバ起動 | あり |
| userdefine.h | ユーザ追加マクロ | ハードウエア割付修正 | あり |
| uart.c | uart1ドライバ | 受信コマンド解析修正 | あり |
| sw.c | swドライバ | チャタリング対応済み | なし |
| led.c | ledドライバ | ブザー出力へ修正 | あり |
| adc.c | adcドライバ | ノイズ対応済み | あり |
| lcd.c | lcdドライバ | HD44780互換品対応 | なし |
| pfdl_user.c | データフラッシュドライバ | RL78_FDL_LIB_VERSION_T04_REN: V1.05使用 | なし |
| pfdl.h | ライブラリヘッダ | なし | |
| pfdl_types.h | ライブラリ追加マクロ | なし | |
| pfdl.lib | ライブラリ本体 | なし | |
| LcdTest.c | Lcdテスト用アプリ | 1s周期起動 | なし |
移植ボードをパソコンに接続し、コマンドを送受信して動作中のボードを示します。
BlueBoard-RL78/G13_30pin-Hを仮想お客様開発ボードとし、テンプレートの移植手順と、その方法を説明しました。テンプレート移植が簡単であることがお判り頂けたと思います。殆どがCubeSuite+の再設定と、ハード割付の変更です。ボード動作に関しては、動作に応じた追加や修正は必要になります。しかし、テンプレートで枠組みが決まっているので簡単です。処理の入出力データは、RAM経由なので、他のアプリやドライバの動作タイミングを考えずに、単独の動作タイミングで開発できるからです。
新規ボード開発時には、ボード周辺ハード/ソフトの単体テストソフトを作り、徐々に結合し、最後にシステム全体として動作させます。本テンプレートを開発当初から活用頂けると、関数間データ送受にRAMを使っていること、アプリやドライバ起動が時分割で複数あること、割込み処理効果を上げるバンク・レジスタ設定があること、などの本テンプレートの特徴を活かして、単体テストや結合テストも容易で、かつ、テストソフトそのものも活用できるので、実用プログラムの早期開発に役立ちます。
メリットは、早期開発だけではありません。開発から時間がたってプログラムを見直す時に、プログラム解読が容易です。時間経過するとフローチャートなどに も目を通しますが、結局、動作理解には、ソースの解読が必要です。この時、テンプレートで枠組みが決まっているのと、そうでないのとでは、解読の困難さが 大幅に異なります。枠組がシンプルで、関数間がRAMで分離される本テンプレート方式は、単純なソースで記述できるので解読も簡単です。
RL78/G1xテンプレートの移植手順一覧を示します。今回は、1～2まで解説します。
G13Stick（サブプロジェクト）のテンプレートが移植ボードに最も近いので、これを使い移植します。
移植ボードのマイコンは、R5F100AD(30pin)：RL78/G13 (ROM:48KB)_30pinで、テンプレートのR5F100LE：RL78/G13(ROM:64KB)_64pinと異なるので、マイクロコントローラ変更を行います。R5F100LE上で右クリックすると、マイクロコントローラ変更（M）…メニューが現れますので、R5F100AD(30pin)へ変えます。変更後は、サブプロジェクトのコード生成（設計ツール）が初期化され、「先に端子割り当てを設定してください。」のメッセージが出力ウインドに表示されます。
クロック発生回路の「箱アイコンが開いている」のは使用中を、「閉じている」のは未使用を示します。マイコン変更直後は、箱アイコン横の！マークで端子割当てが必要であることが判ります。また、ウオッチドック・タイマの箱アイコンも開いているので、WDTがデフォルトで使用されることも判ります。
コード生成のパラメタは、全てGUIで設定するのが本来の使い方です。設定箇所が多く、間違いなく設定するのは大変ですが、GUIで変更や修正が簡単にできるのがメリットです。しかし、多くのパラメタをプロジェクト作成毎に設定するのは面倒なので、既成ファイル（xyz.mtudあたり）から必要部分のコピー＆ペーストで作成すべくいろいろ試行しましたが、失敗でした。別の方法として、（サブ）プロジェクト毎コピーしてプロジェクト名を変更する方法を以前に示しました。今回は、仮想開発ボード付属プロジェクトのコード生成GUIを横目で見ながら、真面目（？）にこのパラメタを設定します。
※A/Dコンバータは、移植基板付属のコード生成では未使用です。しかし、初期設定などメインプログラムで設定しており実際は使用しています。私は、コード生成を使って設定しました。
設定した多くのパラメタがオリジナルプロジェクトと同じかを確認する方法に「コード生成レポート」が使えます。このレポートは、コード生成タブの表示中にのみファイル（F）メニューに表示されるコマンドで、全パラメタがHTML形式で出力されます。オリジナルと両方出力して、エディタで比較すれば、パラメタの一致確認が容易です。
移植ボードの付属回路を示します。UART0はD-Subコネクタが未実装なのでUART1を使います。コード生成（G）をクリックして、移植ボードのAPIを生成します。
| BlueBoard Peripheral | Schematic label | CPU pin | CubeSuite+ port |
| User LED | LED | 20 | P16 |
| Buzzer | BUZZER | 15 | P31 |
| User Switch | INTP1 | 17 | P50 |
| Reset Switch | NRST | 6 | RESET |
| ADC | ANI2 | 29 | P22 |
| UART0（コネクタ無し） | RXD0 | 25 | P11 |
| TXD0 | 24 | P12 | |
| UART1（コネクタ有り） | RXD1 | 2 | P01 |
| TXD1 | 3 | P00 |
Version2のRL78/G1xテンプレートは、4種の市販ボードに対応しますので、テンプレートとボード動作の確認がすぐにできます。今回は、この4種対応ボード以外のボードに、テンプレートを移植する例を示します。本テンプレートを、お客様開発のボードへportingする際に参考になることを狙っています。内容が複雑で分量も多いので、3回に分けて解説します。
第1回目は、ボード選定です。RL78/G1xの発売以降、典型的な市販ボードは、テンプレートでサポート済みです。そこで、お客様開発ボードの代わりに選んだボードは、インドNGX Technologies社のBlueBoard-RL78/G13_30pin-Hです。格安で、E1インタフェース、UART、LED、ブザーなどの周辺ハードが実装済みです。日本でも秋月電子通販から2400円で購入できます。このボードを「仮想お客様開発ボード」とし、テンプレートを移植します。
今回porting対象に選んだボードのマイコンは、RL78/G13:ROM:48KB_30pinです。因みに、RL78/G14:ROM48KB_30pin実装ボードも同じボード回路で、違いはマイコンのみ、ピン割付も同じです（詳しくは、NGX Technologies社のHPを参照）。従って、テンプレートをBlueBoard-RL78/G14_30pin-Hへ移植する場合も、ここで示す方法がそのまま使えます。
市販ボードには、ボードをテストするプログラムが付属しますが、あくまでハードテストが主眼です。また、RL78のサンプルプログラムやアプリケーションノートのプログラムは、動作ボードを特定せず、単一機能の実装例が主眼です。これらに対して、実用プログラムは、複数機能で各機能がシステムとして上手く動作する必要があるので、ボード付属ソフトやアプリケーションノートのソフトを、そのまま実用版へ流用したくても、中途半端で役立ちません。RL78/G1xテンプレートは、この両者の隙間を埋めるのが役目です。実用プログラムとしてそのまま使えるひな型を目指しています（テンプレートに対する皆様のご意見、ご要望などが御座いましたらお気軽にinfo@happytech.jpへお寄せ下さい）。
では次回から、RL78/G1xテンプレートの移植方法を示します。
マイコンは、入力データを基に、データを出力する装置です。今回は、入力データのソフト処理について考えます。
入力データには、「ノイズ」が付き物です。例えば、スイッチ入力であれば、チャタリング、AD変換入力であれば、アナログノイズなどです。これらには、ハード的なノイズ対策が行われます。しかし、マイコンに取込むのは最終的にはソフトなので、ソフトの入力ノイズ対策は必須です。
スイッチ入力のソフトノイズ対策
スイッチのチャタリングは、使用するスイッチハードによってチャタリング時間が変わります。タクトSWやトグルSWの場合は、数ms～10ms程度と言われます。スイッチ入力のソフト処理は、入力データをスキャンして、「High」か「Low」のデータ値が連続したらチャタリングが終わった確定データとします。問題は、データスキャン間隔と連続値の比較回数です。スキャン間隔が広く比較回数が多ければ、確定までの時間が掛ります。と、ここまでは、教科書に記載されています。しかし、肝心のソフト調整の記載は少ないようです。
スイッチ入力は、実際のスイッチハードを人が操作して確定データを調整する必要があります。調整ポイントは、スキャン間隔と比較回数です。これらを簡単に調整/変更できるソフトが優れたソフトです。いろいろ方法があるでしょうが、シンプルな方法は、「スイッチスキャン処理を1つの関数として作成し、この関数の実行タイミングをメイン関数で変更する方法」です。これなら、スイッチハードが無い時はシミュレーションでソフト単体のデバッグができますし、ハードが用意できた後は、単体デバッグ済みソフトとスイッチハードを結合してデバッグします。結合デバッグは、メイン関数のスイッチスキャン処理実行タイミングだけを変えて、スイッチハード操作データが正確に取得できるタイミングを探すだけですので簡単です。
このように、ソフトは、ハード無しの状態で単体デバッグができ、かつ、ハード結合デバッグの調整も簡単にできる作りが望ましいのです。この調整を開発の初期段階でどの程度意識したかにより、可搬性の良いソフトができます。
多くの教科書やサンプルソフトは、メイン無限ループからサンプル処理を起動します。これは、サンプル処理の説明に重点を置いているのでしょうがないのです。しかし、ハード結合調整まで考えると、ここで示した方法のように、無限ループからの起動よりも、起動タイミングを変えられるメイン関数の方が良いことが判ります。
販売中のRL78/G1xテンプレートは、1ms/10ms/100ms/1s/無限ループの5種類のアプリ起動タイミングを提供します。特に入力ソフト処理には、このタイミングを変えられることが、ノイズ対策やハード依存性を少なくすることに効果的です。タクトSWでは、10ms間隔のスイッチスキャン関数起動と2回スキャンデータ一致により、操作データが正確に取得できました。また、AD変換の例としては、ポテンショメータのAD変換データスキャン関数は、100ms間隔起動と2回スキャンデータ一致によりデータ入力ができました。同じAD変換ソフトで、室温などの変化が緩やかなAD変換入力なら、スキャン間隔を1sにすれば対応できます。
