Processor Expertの解析

以前示したKinetis Eソフト開発の最重要要素、Processor Expert: PE、これがテンプレート開発の大きな障壁です。今回は、簡単なPE適用例を示し、PE利用指針とテンプレートに自作PEサンプルソフトを添付する経緯について示します。

3レベルのProcessor Expertコンポーネント

PEは、マイコン周辺回路パラメタのGUI設定、パラメタ整合性チェック、デバイスドライバ生成、ユーザソース所定位置へのドライバ自動挿入を行うアドオンツールです。CodeWarrior: CWとKinetis Design Suite: KDSで同じものが使われています。これらの機能は、ルネサスRL78マイコンのコード生成と同じです。PEは、さらにOperating System: OSへの適用と移植性を強く意識した設計になっています。

このためPEコンポーネントには、3つのレベルがあります。LDD(論理デバイスドライバ)レベルコンポーネント、Highレベルコンポーネント、Lowレベルコンポーネントの3つです。レベルは、コンポーネント抽象度を示し、LDD>High>Lowの順に高く、移植性も高くなります。

コンポーネントレベル 説明
LDDレベル OS利用が前提で、マイコンハードウエアとOS分離が目的のHAL: Hardware Abstraction Layerを適用したデバイスドライバ。OSや機種が変わっても、移植性が高いソースコード生成が可能。
Highレベル OSを使わない一般的マイコンのデバイスドライバ。機種が変わっても、移植性が高いソースコード生成が可能。
Lowレベル 使用マイコンに依存したデバイスドライバ。周辺回路毎の初期化コンポーネントとメソッド/イベントAPIを提供。

PE想定OSは、freescale無償提供のMQX Liteですが、FreeRTOSなどにも適用できそうです。

Highレベルコンポーネントは、LDDコンポーネントを流用

HighレベルコンポーネントとLDDコンポーネントは、別物ではありません。LDDコンポーネントのパラメタの一部を自動設定し流用しています。ツール開発の立場から言えば、当然でしょう。

Processor Expartコンポーネント使用例

LDDレベル

GPIO処理例を示します。無限ループを回る度にGPIO出力ピンに接続したLEDが点滅する例です。

LDDレベルコンポーネント使用例
LDDレベルコンポーネント使用例

面倒なのは、全LDDレベルのAPIに1行目で定義したパラメタが必要なことです。10行目のトグル動作でさえこのパラメタが必要です。4行目の初期化は、ピン初期値がHighかLowか、出力方向か入力方向かなどのGUIで設定したパラメタが自動設定されます。

Highレベル

LDDコンポーネントの代わりにHighレベルコンポーネントを使うと、10行目のパラメタが不要になります。但し、これは、別のところで下記マクロが追加されたために不要になったようにソース記述ができるだけです。
#define Bit1_NegVal()       (Bit1_NegVal(LDD_TdeviceData))

結局、PEコンポーネントは、LDDレベルもHighレベルも同じものを使っていて、ソース記述時にパラメタ1個分簡素になるだけです。多くのパラメタを使ってAPI移植性を高めているのです。ルネサスのコード生成と比べると、APIパラメタが多く、回りくどく感じます。

Lowレベル

Lowレベルのコンポーネントを使用すると10行目のトグル動作は、下記になります。
GPIO_PDD_TogglePortDataOutputMask(FPTB_BASE_PTR, (1<<18));

Lowレベルは、周辺回路毎にメソッド/イベントAPIが提供され、パラメタで具体的な処理位置を指定する必要があり、初期化処理にも多くのLowレベルAPIコールが必要になります。

Processor Expert の課題と利用指針

PEユーザガイドに各レベルコンポーネントの機能説明はありますが、具体的な使用例、つまりサンプルソフトがありません。使用例が無いと機能理解が困難になります。特にLowレベルの記述は、LDDやHighレベルに比べ少ないです。LDDかHighレベルのコンポーネントを使うことがPEの前提条件で、Lowレベルは、LDDレベルでカバーできない部分のみに使用するのだと思います。

以上から、LDDレベルコンポーネントを使ってテンプレートを開発する方針とします。そこで、開発に使えそうなサンプルソフトを調査しました。

FRDM-KE02Z40MのCW、KDSサンプルソフト一覧

2014年11月時点で、テンプレート開発評価ボード:FRDM-KE02Z40Mに使えるサンプルソフトを示します。NonPEとは、Processor Expertを使わない従来タイプのデバイスドライバのことです。因みに、NonPEでGPIOトグルを記述すると、PEのLowレベルに近い記述で、下記になります。
GPIO_Toggle(GPIOB, GPIO_PTE7_MASK);

サンプルソフト(2014/11E現在) サンプル数 概要
CW10.6付属 PE Examples 1 評価ボードの3軸加速度センサプロジェクト。使用コンポーネントのデフォルト設定値からの変更箇所が判らない問題あり。
CW10.6付属 NonPE Examples 29 最も多くのサンプルソフトがあるが、CW専用ドライバでKDSへ移植できない。
KDS1.1.1付属PE Examples 0 KDS1.1.1付属サンプルソフト無し。自作PEサンプルソフトをKinetis Eテンプレートに添付予定。
KDS1.1.1付属NonPE Examples 0 KDS1.1.1付属サンプルソフト無し。
Kinetis SDK1.0.0 0 FRDM-K22Fボードなど5種対応中だが、評価ボード対応版無し。

この一覧表から、現時点のFRDM-KE02Z40Mサンプルソフト状況を纏めると以下となります。

  • CW PEサンプルソフトは、KDS PEサンプルソフトへのポーティング可能
  • CW NonPEサンプルソフトは、KDS NonPEサンプルソフトへのポーティング不可能
  • KDSとPEを開発環境に選ぶと、テンプレート開発評価ボードで使えるPEサンプルソフトは、CW版をポーティングして得られる3軸加速度センサプロジェクト1個のみ

CWのPEサンプルソフトは、KDSへ移植が可能ですが、一部手直しが必要です。また、一番サンプル数が多いCWのNonPEサンプルソフトは、CW専用ドライバで開発されていてKDSへ移植できません。

KDS Processor Expert サンプルソフトをKinetis Eテンプレートへ添付

販売予定のKinetis Eテンプレートも従来テンプレートと同様、シンプルテンプレートとメニュードリブンテンプレートの2構成です。さらに、現在のPEサンプルソフト状況を考えると、KDSのPEで動作する自作サンプルソフトをテンプレートと同時提供すれば、テンプレート付加価値が上がります。つまり、KDS1.1.1付属PE Examplesのサンプル数0を補完する試みです。

次バージョンKDSでは、freescaleからKDS PE付属サンプルが提供されるかもしれません。しかし、少なくともそれまでの間は、KDS1.1.1のProcessor Expertを使ってFRDM-KE02Z40Mで動作するサンプルソフトは有りません。自作サンプルソフトが目的でテンプレートを購入して頂ける方がいるかもしれません。

繰り返しになりますが、PEのユーザガイドには、十分な機能説明はあります。しかし、サンプルソフトが無いと、せっかくの機能説明も上級者以外には意味不明になります。また、コンポーネントのデフォルトパラメタ設定値のどこを変えたサンプルなのかも明示すると、より解りやすいものとなるでしょう。テンプレート説明資料では、この部分も明らかにします。

テンプレート対象のKinetis KEマイコンは、低価格で非常に良くできたARM Cortex-M0+マイコンです。統合開発環境は、CWからKDSに変わります。KDSでは、OS使用有無にかかわらず、PEを習得しているほうが、KEシリーズだけでなく、全Kinetisマイコン開発のために有益です。

FRDM-KE02Z40M評価ボードで動作するKinetis Eテンプレートと、多くのKDS Processor Expert サンプルソフトを提供すべく開発中です。

LPC8xxの2種類のAPIライブラリ

LPC8xxのサンプルコードには、2014年2月現在、2種類の既成APIライブラリ(ドライバ)があります。

1. LPCClose:LPCXpresso_7.0.0_92付属のNXP_LPC8xx_SampleCodeBundle.zip

2. LPCOpen:LPCOpenサイトのLPCOpen-LPCXprersso LPC812, LPC800-MAX/LPCXpresso, Keil_IAR

両者の違いは、2が3階層ライブラリ(私は下図のように理解)、1は、従来からある階層なしのライブラリです(詳しくは、コチラ)。LPCCloseは、LPCOpenに対して、私がかってに付けた名前です。

LPCOpenの目的

LPCOpenの構造
LPCOpenの構造

 私は参照してもLPCOpen理解度はイマイチなのですが、目的は周辺回路のライブラリ汎用化、ひいてはCライブラリのような標準化とOpen開発によるAPIバグ取り、CMSISのドライバ版と理解(想像?)しています。

既成API利用のプログラミング

一方、LPCClose側のライブラリ評判は、良くありません。既成API利用のプログラミングは歴史が浅く、ドライバ側の改版も順次進むでしょう。また、いずれのサンプルもLPC8xxの最大特徴、スイッチ・マトリクス・ツール(ver1 20130602版):SMTの出力を使ったコードはありません。SMT完成が2013年6月なので、サンプルコード開発に間に合わなかったのが原因と思います。が、現状でもSMT出力をLPCOpenソースへ代入するとコンパイルエラーが生じるなど、新しい製品なのでしかたがないのでしょう。ソフト開発を複数人で行うと必ず生じる副作用だと思います。

LPCOpenの選択

ポイントは、既成ドライバの改版時、ユーザ開発部分に影響が少ない(理想はゼロ)構成にしておくことです。LPCOpenヒストリーを観ると、現在のv2.01までに5回改版されています。

このような状況ですが私は、LPCOpenライブラリを使います。バグ取りの進み具合がOpen開発なので早そうなのと、Cライブラリの雰囲気があるからです。その分、LPCCloseに比べ、解読しにくい箇所もありますが、組込みマイコン標準周辺回路ライブラリを夢見て活用したいと思います。

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

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マイコンなどにも適用してみたいと考えています。

テンプレート使用法(2):分析とテンプレート組込み

第2回は、LCDアプリ分析とテンプレートへの追加方法の説明です。

ドライバとアプリ分離:先ず、LCD制御ソフトを、ドライバ処理とアプリケーション処理(以後アプリ処理と略す)に分けて考えます。ドライバ処理とは、制御対象がLCDコントローラのソフトです。アプリ処理は、ドライバ処理を使ってLCDに出力する文字列を設定するソフトのことです。

LCDドライバ処理:LCD表示を行うには、マイコンピン初期設定、LCDコントローラのパワーオン処理、LCDコントローラ初期設定、LCD表示データ書込みの4種の処理が必要です。そこで、各処理をそれぞれ関数化し、条件によりこの4ドライバ関数に分岐します。これらのドライバ処理をテンプレートへ組込むと、下図(左側)のようになります。

LCDアプリ処理:ドライバ処理で準備が完了したLCDコントローラに対して、LCDで表示する文字列を設定する関数です。コンローラ準備完了判断や、通常表示と、エラーを表示する場合などの条件で分離することを考慮すると、下図(右側)のようになります。

ポータル関数の構成
ポータル関数の構成

ドライバ処理もアプリ処理も、テンプレートへ組み込む形は同じです。ポータル関数でインタフェースRAMの値によって条件分離し、各イベント処理を実行します。各イベント処理後にインタフェースRAM値を変更し、次回の条件分岐に備えます。

インタフェースRAM:関数間の変数をRAMに展開したものをインタフェースRAMと呼びます。RL78/G13やG14には、アクセス頻度が高い変数は、ショート・ダイレクト・アドレッシングsreg領域(FFE20~FFEB3 の147バイト)へ配置すると高速化が図れます。引数で記述する場合に比べ、関数単体デバックが簡単になるメリットがあります。

処理が遅い周辺回路の対処:最近のマイコンは高速動作です。しかし、LCDコントローラなどの周辺回路は、マイコン動作に比べ、とても遅いという問題があります。この遅さに対して、マイコンのポーリングや割込みを使う方法で解決できます。しかし、今回のLCD接続は、リード動作ができないので、これらは使えません。第2の方法は、周辺回路動作完了まで、マイコン側の処理に待ち時間を入れる方法です。サンプルプログラムなどでは、この方法を多く用います。マイコン処理は簡単ですが、無駄に時間を消費しますので、高速マイコンに効果的な方法とは言えません。

第3の方法が、タイムシェアリングを使う方法です。周辺回路の動作を設定した後は、マイコンに別処理を行わせ、周辺回路の処理が完了したころを見計らってさらに追加処理をする方法です。第2の方法より、効率的にマイコンを使えますが、処理完了のころあいを見積もることが大切です。見積もりが上手くいけば、多重処理ができるので、高速マイコンの特長を活かせたソフトができます。リアルタイムOSも、簡単に言うとこの方法を使っています。プログラマの処理完了の見極めが不要で、タスク切換えをOSが行ってくれます。が、それなりの大容量RAMが必要で、4MB程度のRAMでは足りませんし、使いこなしの知識や経験も必要です。また、無料OSもありますが、有料版はコストアップになります。

タイムシェア間隔固定:提供テンプレートは、タイムシェアリング間隔が、予め決まっています。ドライバ処理起動用に、250ms/1ms/10ms/100ms/1s、アプリ処理起動用には、1ms/10ms/100ms/1sです。つまり、この間隔で、遅い周辺回路の処理完了を見積もって、割り振れば良い訳です。間隔が決まっていますので、リアルタイムOSよりは効率が下がりますが、オーバーヘッドは少なくなります。

LCDコントローラの場合は、パワーオン処理に5ms、表示クリアに1.64ms、その他の処理に40us(いずれも最大値)が必要です。そこで、ドライバ処理のポータル関数は10ms間隔、アプリ処理のポータル関数は1s間隔に割り振りました。40usの処理待ちは、タイムシェアリングせずに、時間消費で対応しました。テンプレートに組込んだドライバポータル関数を下図に示します。

テンプレートへ組込んだドライバポータル関数
テンプレートへ組込んだドライバポータル関数

リアルタイムOSに比べれば効率が低下しますが、テンプレートは、少ないRAM使用量で、高速マイコンの特徴を活かした多重処理を、簡単に実現できることが判ると思います。