FreeRTOS新規プロジェクト作成方法からアプリケーションテンプレートまで

NXP)LPCXpresso54114(Cortex-M4/100MHz、Flash/256KB、RAM/192KB)で動作するFreeRTOSアプリケーションテンプレート開発に着手しました(関連投稿:FreeRTOSアプリケーションテンプレート構想)。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

この開発で用いる新規FreeRTOSプロジェクト作成方法、新規作成プロジェクトとMCUXpresso SDK付属FreeRTOSサンプルプロジェクトとの違いを示し、FreeRTOSアプリケーションテンプレートのベースプロジェクトを解説します。

まとめ:新規FreeRTOSプロジェクト作成方法とFreeRTOSベースプロジェクト

新規NXP FreeRTOSプロジェクト作成方法をまとめました(詳細は、次章サンプルプロジェクト留意点の後に説明)。

Step1:MCUXpresso SDKで評価ボード選択
Step2:FreeRTOS選択(デフォルト:ベアメタル)
Step3:FreeRTOSドライバ選択(デフォルト+ユーザ追加ドライバ)し、新規プロジェクト作成
Step4:新規プロジェクトへ、サンプルプロジェクトのfreertos_generic.cとFreeRTOSConfig.hを上書き
Step5:アイドルタスクへ低電力動作WFI()を追記し、FreeRTOSベースプロジェクト完成

Step3までが、一般的なFreeRTOSプロジェクト作成方法、Step4と5が、弊社FreeRTOSアプリケーションテンプレート向け工夫箇所です。

弊社FreeRTOSアプリケーションテンプレートは、Step5で作成したFreeRTOSベースプロジェクトへ、例えばADC.cやLCD.cなど制御対象毎のソースファイルを追加して開発します(最初の図)。LCDを使わないアプリケーションの場合は、LCD.cをベースプロジェクトから除外すればそのまま使えるなどポータビリティも考慮しています。

Step3で、ユーザ未追加ドライバ、例えばFreeRTOSメールボックスドライバを、SDKを使わずにベースプロジェクトへ手動で追加するのは、手間やケアレスミスが発生します。

最初から全てのドライバをベースプロジェクトへ追加しておくのも1つの方法ですが、弊社は、必須ドライバでアプリケーションを開発し、追加が必要な時には、再度SDK新規プロジェクト作成からドライバを追加する方法を推薦します。

必須ドライバは、SDKサンプルプロジェクト:freertos_genericで使用中のドライバとADC、VCOMです。これらドライバを追加したベースプロジェクトであれば、FreeRTOSアプリケーションテンプレート構想3章で示したアプリケーション動作に必要十分だと現時点では考えています。

※サンプルプロジェクト:freertos_genericの詳細は、後日、別途投稿を予定しています。freertos_generic名称から判るように、キューやセマフォなど汎用FreeRTOS処理実装のサンプルプロジェクトです。サンプルプロジェクトの概略は、関連投稿を参照してください。

SDK FreeRTOSサンプルプロジェクトと新規作成プロジェクトの違い

MCUXpresso SDK付属のFreeRTOSサンプルプロジェクトと、前章の新規作成FreeRTOSプロジェクトは、ファイル構成が異なります。

FreeRTOSサンプルプロジェクトと新規作成プロジェクトの構成差(FreeRTOSConfig.hの場所が異なる)
FreeRTOSサンプルプロジェクトと新規作成プロジェクトの構成差(FreeRTOSConfig.hの場所が異なる)

構成が異なる理由は、サンプルプロジェクトがFreeRTOS個別技術の説明に重点を置いており、これに都合が良いファイル構成になっているからです。

つまり、左側のsourceフォルダ内にあるfreertos_サンプル.c とFreeRTOSConfig.hの2ソースコードさえ読めば、提供処理が判るように全てのサンプルプロジェクトが作成されています。
※FreeRTOSConfig.h は、FreeRTOS全体動作を決める最重要ファイルです。後日freertos_generic投稿時に説明を加えます。

右側新規作成FreeRTOSプロジェクトと比べると、ポータビリティなどは犠牲になっています。SDKやFreeRTOS自身もバージョンアップしますので、開発済みアプリケーションのポータビリティは重要です。

新規作成ファイル構成で開発したアプリケーションであれば、バージョンアップした環境でも開発済みアプリケーションの移設は容易です。

FreeRTOSサンプルプロジェクトは、機能理解専用と考えれば良いでしょう。なお、FreeRTOS基本機能は、弊社特集サイトを参照ください。

Step1:評価ボード選択

以降は、1章:まとめで示した新規FreeRTOSプロジェクト作成方法とFreeRTOSベースプロジェクトの詳細を示します。

Step1:評価ボード選択
Step1:評価ボード選択

MCUXpresso IDEのNew projectをクリックし、SDK Wizardで評価ボード:lpcxpresso54114を選択、Nextをクリックします。

Step2:FreeRTOS選択

Step2:FreeRTOS選択
Step2:FreeRTOS選択

ComponentsウインドのOperating Systemタブで、デフォルトbaremetalをFreeRTOS kernelへ変更します。

Step3:FreeRTOSドライバ選択

Step3:FreeRTOSドライバ選択
Step3:FreeRTOSドライバ選択

Driversタブでデフォルトドライバに加えadcとusart_freertosを追加します。Components selection summaryウインドのDriversを開くと、実装ドライバが一覧表示されます。Finishクリックで新規FreeRTOSプロジェクトを作成します。

Step4:freertos_generic.cとFreeRTOSConfig.h上書きコピー

Step4:FreeRTOS_generic.cとFreeRTOSConfig.hの上書きコピー
Step4:FreeRTOS_generic.cとFreeRTOSConfig.hの上書きコピー

作成した新規FreeRTOSプロジェクト(Project0)のsource>Project0.cとfreertos>template>ARM_CM4F>FreeRTOSConfig.hを、サンプルプロジェクトlpcxpresso54114_freertos_genericのsource>freertos_generic.cとFreeRTOSConfig.hで上書きします。

Step5:FreeRTOS低電力動作追記

Step5:FreeRTOS低電力動作
Step5:FreeRTOS低電力動作

FreeRTOSアイドル時に低電力動作させるため、上書きしたProject0.cのvApplicationIdelHook()へ、WFI()を追記します。BuildしFreeRTOSベースプロジェクトが完成です。

あとがき:ダークモードと日本語コメント

Step4と5の図は、MCUXpresso IDEのAppearanceをデフォルト:ClassicからDarkに変更しています。

流行のDarkの方が、コード自体は見易いがコメントの方は今一歩に感じます。弊社FreeRTOSアプリケーションテンプレートは、Colors and Fontsにメイリオ11Pを使い、追記日本語コメントを文字化け無しに表示する方針で開発します。ClassicかDarkかは、お好みで選択してください。

Windows 10更新中断、μT-Kernal、IoTマイコン

Windows 10 1809更新によりユーザファイルが消失するトラブルが発生しています。このためMicrosoftは、Windows 10 1809への更新を一時中断しました。

Windows 10更新でマイドキュメントフォルダ消失!

消失フォルダは、よりによってC:\User\[user name]\Documentsだそうです。マイコンIDEのプロジェクトファイルをマイドキュメントフォルダへ設定している方(私がそうです)は、1809更新を待った方が良いかもしれません。

幸い私の3台のPCは、全て問題なく1809更新に成功し、Documentsフォルダも無事でした。

よく言われる最悪を避けるには、個人データのバックアップです。しかし、Windows機能更新時に、最も守るべきユーザデータを壊す/消すという不具合は、OSとしては許されません。Fast/Slow リングで検証できなかったのでしょうか?

μT-Kernal

OSと言えば、マイコン向けのリアルタイムOS:μT-Kernalの解説がトランジスタ技術2018年10月号の組込みOS入門という別冊にあり、第2章~第6章にリアルタイムOS(RTOS)の説明があります。

また、トロンフォーラムへの登録が必要ですがルネサスRL78/G14向けにポーティングしたμT-Kernalを無料でダウンロードできます。

※μT-Kernalは、ITRONベースに2003年公開の32ビットマイコン向けオープン・ソースRTOS。

本ブログではこれまでRTOSとしてFreeRTOSを紹介してきました。μT-Kernalと比較するとより理解が進むと思います。

関連投稿:マイコンRTOS習得

IoTマイコンとRTOS

IoTマイコンにRTOSを使うと、今回のWindows 10のようなトラブルを招く可能性が生じます。ただIoT通信手段が何になるにせよ、高度なセキュリティや公共リソース利用のための通信処理をマイコンで行うには、RTOSが必要になると思います。

この状況ならいっそのことIoTマイコンには、Cortex-M4(または同等クラス)とCortex-M0/M0+マルチコアを導入し、Cortex-M4でIoT関連処理、Cortex-M0/M0+で従来のMCU処理に2分割、さらにIoT関連処理はMCUベンダーが全て無償提供してくれればIoT MCUの爆発的普及が進むと思います。

つまり、Cortex-M4のIoT関連処理がWindows 10に相当する訳です。これならIoT通信手段やセキュリティが変わってもCortex-M4部分のソフトウェアをOTA(Over The Air)で変えれば対応できます。我々開発者は、本来のマイコン処理に集中できます。
理想的な空想ですがね…。

関連投稿:OTAについてIoT端末の脆弱性対応はOTA:Over The Air更新が必須の章参照

ARMが考えるIoTの3課題と4施策

ARMはMCUコア開発会社ですが、製造はしません。開発したコアのライセンスをMCUメーカーへ供給し、このコアに自社周辺回路を実装し各メーカーがMCUデバイスを製造販売します。コア供給元のARMが考えるIoTの3つの課題記事を紹介します。

ARMの課題と施策

本ブログ掲載MCUでは、NXP、STM、CypressがARMコア、ルネサスがNon ARMコアです。いまやARMコアがMCU世界のデファクトスタンダードです。つまりARMの考えは、MCUメーカー各社に多大な影響を与えると言うことです。

ARMが考えるIoTの課題が、「デバイスの多様性」、「エンドツーエンドセキュリティ」、「データの適切な利用」の3つです。そしてこれら課題に対して、「Cortex」、「Mbed OS」、「Mbed Cloud」、「PSA:Platform Security Architecture」の4つの施策で対応します。
課題と施策の内容は、Arm、IoTプラットフォーム「Arm Mbed Platform」アピールの記事に説明されています。

上記記事で、最も印象に残ったのが、ARM)ディペッシュ・パテル氏の下記コメントです。

「専門知識がないユーザーでも、デバイスメーカーが提供するデバイスを購入して、Mbed OSを使えばすぐに利用できる。重要なことはシンプルであることだ。」

MCU開発者の課題と施策

さて、これらARMの施策に対してエンドポイントMCUソフトウェア開発者である我々の課題と施策は何でしょうか?

ARMの課題「デバイス多様性」や「セキュリティ」には、Cortexコア習熟や、セキュリティ理解などが必要です。また、最近更新が盛んなMbed OS習得も加わるでしょう。

記事記載の市場規模は大きくなっても、開発時間はこれまで以上に短く、また、顧客要求も多様化、複雑化するハズです。

従って、従来のような開発方法よりむしろ、スピード重視のプロトタイピング開発が求められると思います。これには、既存ライブラリやサンプルソフト流用、活用技術を磨く必要があるでしょう。前々から言われるソフトウェアの部品化開発手法です。

流用する中身に多少不明な点があっても気にすることはありません。パテル氏コメントの「シンプルであること」を常に念頭に置きながら開発を進めることが重要です。シンプルであれば、様々な状況変化へも対応できます。開発が終わった時に振り返ると、不明内容はおぼろげながら見えるものです。

具体的な手段

弊社は、プロトタイピング開発への具体的な実現手段として、ARMコアのNXP、STM、Cypress各社、およびNon ARMコアのルネサスに対してマイコンテンプレートを提供中です。テンプレートと評価ボードを使えば、早期開発着手と汎用開発部分の使いまわしも簡単で、プロトタイピング開発に最適です。

汎用処理が出来上がったテンプレートへ、顧客要求実現の開発部分を組込めばソフトウェア全体がほぼ仕上がる仕組みです。

また、Mbed OSの仲間であるFreeRTOSを例に、マイコンRTOS習得ページもテンプレートサイトに掲載しております。ご活用ください。

解説:マイコン評価ボード

マイコン開発には、各社が低価格で提供している評価ボードは必須です。
弊社マイコンテンプレートも、各ベンダの評価ボードで開発しています。この評価ボードを解説します。

採算度外視の低価格、高信頼ハードウエア

ソフト開発者に「確実に動くハードウエア」を「低価格」で提供する、これが評価ボードです。

マイコン開発には、「専用」のソフトウエアと「専用」のハードウエアの両方が必要です。そして片方のデバッグには、もう片方にバグが無いことが必須です。つまり、ソフトデバッグには、バグなしのハードが必須なのです。そこで、バグなしで確実に動作する「汎用」ハード、これが各ベンダ提供の評価ボードです。

但し、専用ハードがいずれ開発されるので、汎用の評価ボードは低価格とならざるをえない運命です。高ければ誰も買ってくれないからです。しかし開発者にとっては、以下のように優れた教材と言えます。

  1. ソフト開発者が、専用ハードが出来上がる前にソフトデバッグ可能な環境を自由に構築できる
  2. ハード開発者が、そのまま専用ハードにも使える高信頼ハード設計を学べる
  3. マイコン初心~中級者が、ベンダ標準のデバッグ技術で低価格な開発環境を使って自習できる
  4. 評価ボードは、各ベンダフォーラムで多くの情報が記載されており、適用サンプルソフトも多い

ターゲットMCU、デバッグインタフェース、拡張コネクタの3構成

評価ボードは、ターゲットMCU、デバッグインタフェース、拡張コネクタの3つから構成されます。

NXPの評価ボード:LPCXpresso LPC812とルネサスのRL78G13-Stick、CypressのCY8CKIT-042 の例を示します。

LPCXpresso LPC812構成
NXP LPCXpresso LPC812構成
RL78G13-Stick構成
Runesus RL78G13-Stick構成
CY8CKIT-042構成
Cypress CY8CKIT-042構成

ターゲットMCU

ターゲットMCUとは、開発MCUそのものの部分です。残りのデバッグインタフェースと拡張コネクタは、ターゲットMCUが異なっても同一です。

拡張コネクタ

最近はArduino用シールドコネクタを拡張コネクタに用いる評価ボードが多いです。これは、市販Arduinoシールドの種類が増えたため、上手く探せれば汎用の評価ボードに複数のArduinoシールドを拡張コネクタで接続し、専用ハードに近い、いわば「疑似専用ハード」を市販品のみで作れます。ボード単位のハード部品化がもたらした結果と言えます。

個人的には、シールドよりも、mbed – Xpresso Baseboardの方がより低コストで疑似専用ハード実現ができると思っています(こちらに詳しく記載しました)。

デバッグインタフェース

デバッグインタフェースは、IDEデバッグ機能を使うために必要な部分で、ターゲットMCUのシリアル入出力とパソコンUSBを変換する機能もここに含みます。この機能専用のマイコンが実装されることが多くなりました。このマイコンでデバッガ機能も代行するので、別途デバッガを購入せずにソフトデバッグが可能です。

MCUがARM Cortex-M0/M0+の場合には、ARM標準のCMSIS-DAPでMPUコアをデバッグできるインタフェースも実装されます。CMSIS-DAPはこちらの記事も参照してください。

CMSIS-DAPは、ターゲットMCUとデバッグインタフェースを切り離した後に、ソフトデバッグする時、別途ARM専用デバッガが必要ですが使えます。このように、1つの評価ボードで複数のデバッグ方法が使えるのも特徴です。

ARM系コアの場合は、ベンダ評価ボードもほぼ同じ構成で、ARM専用デバッガを1台持っていれば、ベンダ各社の評価ボードをまたがっても使えるのがメリットです。マイコン開発のデファクトスタンダートになりつつあります。

一方、デバッグインタフェースをE1コネクタでしか持たないルネサスのCPUボードをデバッグする際は、別途E1デバッガを接続しないとデバッグができません。この点は、Cortex-M0/M0+コアのMCUと比べるとコスト的に劣ると言えるでしょう。

Runesus QB-R5F104LE-TB構成
Runesus QB-R5F104LE-TB構成

デバッガ機能なしの統合開発環境:IDEの背景

シールドなどのボード単位の部品化が進んだ結果、専用ハードは、もはや既存ハードを組み合わせて、その小型化のみを行う設計、つまり専用基板化が主な開発内容と言えるかもしれません。

同様に、ソフト開発もベンダが、多くのライブラリを提供することで、専用ソフトをライブラリの組合せで完成できるレベルを目指しているようです。IDEにデバッガ機能がないArduino IDEなどは、この現れのような気がします。

ハードとソフトのオープンソース

ハード版オープンソースとしてArduinoシールドコネクタを持つ既成基板は、増えつつあります。

オープンソースを活用したソフト開発は、Unix系では当たり前です。この流れがマイコンソフトへも徐々に浸透する可能性を感じています。この場合、ハードの専用基板化開発に相当するのは、RTOS適用や弊社のマイコンテンプレートになるかもしれません。

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 サンプルソフトを提供すべく開発中です。

IoT向けの無償ARMマイコンOS

弊社、販売中のLPC8xxテンプレートLPC111xテンプレートのライバルが、ARMから無償提供されます。ARM mbedの組込みOS「mbed OS」がそれです。

mbed OSとは

mbed OSに関する記事、「ARMがIoT向けにOSを無償提供開始」と、「ARMは「mbed」フラットフォームでIoT時代を実現させる」によると、ARM社が提供し(つまり、CMSISのOS版になるかも…)、

Cortex-M0/M0+向け、モジュラー構成で必要に応じて選択組込み可能、セキュリティ機能あり、イベントドリブン型OS、mbed Device Server(こちらは有償)との通信によりクラウドサービス利用可能、現在はα版で2015年10月に正式版の予定、NXP/freescaleなどのmbedベンダも参加、オープンソース開発、などなどIoTデバイス開発コスト低減化に効果あり。

かなり強力ライバルです(勝手にライバル視しましたが、ARM社様、ご容赦を…)。今後、ウオッチを続けたいと思います。

組込みマイコンのマルチタスク化

確かに組込みマイコンに多くの機能を実装する時、OSがあれば楽だと思うことがしばしばあります。Windowsデスクトップアプリ開発などを経験すると、より一層感じられることで、IoT時代のマイコンにはmbed OSなどの組込みOSが、必須プラットフォームになるでしょう。

ただ、OSを利用しようとすると、それなりの基礎知識が必要になります。有名な組込みマイコンOS:FreeRTOSなども、使い始めのステップが結構高く、大規模/多人数ソフト開発なら便利でしょうが、普段使いには躊躇します。

さらに、ベンダや機種毎に異なる基礎知識、商用Windowsの例では、OS更新時の手間など、実アプリ開発着手の前段階、メンテで労力を使い果たしてしまいます。これらに関しては、mbed OSで統一されれば、明るい見通しはあります。

マイコンテンプレートの市場

そんな背景で開発したのが、マイコンテンプレートです。簡易マルチタスク化、デバッグ容易、サンプルソフト流用得意、などの特徴があります。イメージ的には、以下の範囲での適用が市場です。

テンプレート市場と対応マイコン
テンプレート市場と対応マイコン

先の記事に、ARM mbedとIntel市場の違いをKris Flautner氏が説明されていましたが、(勝手に無断)引用させて頂くと「mbed OSは非常にハイエンドのモノで、それに対して弊社テンプレートがフォーカスするのは、無償IDEで開発できるプログラムサイズの低価格な組込みマイコンの市場。両者は全く異なる。」と言えます。

販売中のテンプレートの骨格説明と、一覧はコチラをご覧ください。

サンプルソフトの構造

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テンプレート(近日発売予定)は、もっと手軽に複数処理を実現するものです。

テンプレート使用法(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使用量で、高速マイコンの特徴を活かした多重処理を、簡単に実現できることが判ると思います。