MCUXpresso Config Toolsの使い方

前稿に続きMCUXpresso SDKベースのMCUソフトウェア開発に欠かせないMCUXpresso Config Toolsの使い方を説明します。SDKサンプルプログラムに少しでも変更を加える時には、Config Toolsが必要になります。

MCUXpresso IDEクイックスタートパネルのConfig Tools
MCUXpresso IDEクイックスタートパネルのConfig Tools

Config ToolsとSDK

MCUXpresso IDEのSDKサンプルプロジェクトは、そのままコンパイルして評価ボードで即動作可能です。ユーザが変更を加える箇所は、sourceフォルダ内に限られています。sourceフォルダ以外は、ライブラリフォルダです(詳細は、前稿を参照してください)。

Config Toolsは、このSDKライブラリに変更を加えるツールです。

SDKサンプルプロジェクトは、MCU内蔵周辺回路の動作例ですが、逆に言うと、「その周辺回路しか動作させない例」です。低電力動作が必須のMCUでは、しごく当然のこのソフトウェア作法、つまり無用な回路は動作させない方針で開発されています。

ところが、SDKサンプルプロジェクトにユーザが変更を加える場合、サンプルプロジェクトで動作中の回路以外の周辺回路動作を新たに加える時があります。

この時には、MCUXpresso Config Tools>>をクリックし、MCU内蔵の眠っている(=Inactive)周辺回路の目を覚ます(=Activate)必要があります。

周辺回路をActivateした結果、サンプルプロジェクトのSDKライブラリに対して、相応の変更をConfig Toolsが自動生成(上書き)します。これが、Config ToolsとSDKの関係です。

Config Toolsの使い方

具体的にFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose)評価ボードのSDKサンプルプロジェクト:gpio_led_outputを例に、Config Toolsの使い方を説明します。このサンプルプロジェクトは、いわゆるLチカサンプルで、評価ボード上の赤LEDを点滅させます。

ここでは、赤LEDの代わりに緑/青LEDを点滅させる変更をユーザが加えると想定します。

※他のサンプルプロジェクトも、殆ど赤LED(BOARD_RED_LED)1個のみを動作させますので、この緑/青LED変更方法は、多くのサンプルプロジェクトにも流用できます。

MCUXpresso SDKのgpio_led_outputソースコード(一部抜粋)
MCUXpresso SDKのgpio_led_outputソースコード(一部抜粋)

先ずConfig Toolsを使わずにL40とL41のRED_LEDをGREEN_LEDへ変更後、Buildします。その後、DebugでFRDM-KL25Z評価ボードを動作させても緑LEDは点滅しません。もちろん、ブレークポイントをL92に設定して動作は確認済みです。

LEDが点滅しない理由は、評価ボードの緑/青LEDに接続済みのgpioピンが、Inactiveだからです。

対策にMCUXpresso Config Toolsをクリックすると、Develop画面がPins画面へ変わります。

MCUXpresso Config Toolsクリックで現れるPin画面
MCUXpresso Config Toolsクリックで現れるPin画面

Routed Pinsタブ①に、GPIOB:LED_REDがリストアップされています。このリストは、Activate済みの全ピンを示します。

そこで、Peripheral Signalsタブ②で緑/青LEDのGPIOB、19とGPIOD、1に✅を入れると、リストに両ピンが加わります。Identifierは、LED_GREENとLED_BLUEにします。

MCUXpresso Config ToolsでActivateした緑と青LEDのgpioピン
MCUXpresso Config ToolsでActivateした緑と青LEDのgpioピン

この状態で、「緑色」のUpdate Codeボタン③をクリックすると、Update Filesダイアログが開き、上書き対象のSDKライブラリが一覧表示されます。この場合は、ライブラリ:board>pin_mux.c/hとboard>clock_config.c/hが上書き更新されます。

MCUXpresso Config Toolsが生成(上書き)するファイル一覧
MCUXpresso Config Toolsが生成(上書き)するファイル一覧

ダイアログのOKクリックで最終的にSDKライブラリへ変更が加わり、自動的にDevelop画面に戻ります。上書きされるライブラリのソースコードは、Pins画面上のCode Previewタブ④でも更新前に確認ができます。

戻ったDevelop画面で、RED_LEDをGREENやBLUE_LEDへ変更し、Build を再実行、Debugすると、今度は評価ボードの緑/青LEDが点滅します。

Config Toolsが、緑/青LED接続のgpioピンをActivateしたSDKライブラリに上書き更新したからです。

このようにSDKサンプルプロジェクトは、必須周辺回路とクロックルートのみをActivateした例で、その周辺回路単体でのMCU消費電力も判ります。この時のクロック周波数は、MCU最高動作周波数です。周波数を下げることで消費電力も減らせますが、その分ソフトウェア開発の難易度は上がります。

機能的には似た周辺回路がある場合や、特に電力消費が大きい回路を比較・最適化し、MCUトータル消費を改善する手段としてもサンプルプロジェクトは利用できます。

MCU電力低減方法は、SDK/Config Toolsデフォルトの最高周波数でソフトウェアを開発し、次に周波数を下げるアプローチが適すと言えるでしょう。

Config ToolsのUpdate Code

SDKサンプルプロジェクトに何も変更を加えずに、Config Toolsをクリックしても、Update Codeボタンが「緑色」になる場合があります。Update Codeボタンの灰色は、上書きするSDKライブラリが無いことを示します。この場合は、変更を加えていないので、本来「灰色」のハズです。

これは、元々のSDKライブラリが手動生成、または旧Config Toolsで生成していて、IDE付属の最新Config Toolsの上書き版と(機能的には同じでも)異なる場合があるからです。例えば、ライブラリコメントが変わる場合などが相当します。

気になる方は、SDKサンプルプロジェクトを最初にIDEへImport後、直にConfig Toolsを起動し、Update Codeを一度実行しておけば、次回からユーザ変更が無ければ、灰色でボタン表示されます。

新規プロジェクトのConfig Tools

Config Toolsの使い方に本稿では、SDKサンプルプロジェクトのLチカサンプル点滅LED変更を例にしました。この使い方は、MCUXpresso IDEで新規プロジェクト作成時でも同じです。

新規プロジェクト作成時、初めからMCU内蔵周辺回路のSDKドライバを全て実装したとしても、消費(浪費)されるリソースはFlash/RAM容量のみです。周辺回路やクロックルートのほとんどは、Inactiveが初期値で、ActivateはUART0程度です。

そこで、IDE新規プロジェクト作成後、先ずConfig Toolsで使用予定の周辺回路やクロックルートをActivateし、それらに対応したSDKライブラリをUpdate Codeで上書き更新、最後にユーザ処理を記述するという順番になります。

MCUXpresso IDEソフトウェア開発要点

NXPのMCUXpresso IDEは、SDKベースのMCUソフトウェア開発を行います。

SDKには、多くのサンプルプロジェクトがあり、これらを上手く活用すると、効率的で汎用的なMCUソフトウェア開発が可能です。

SDKサンプルプロジェクトは、対象周辺回路とクロックルートのみを動作させる基本に忠実な作法で開発しているため、ユーザがプロジェクトへ変更を加える時、新たな周辺回路のActivateが必要な場合があります。

Config Toolsは、MCU全内蔵回路とクロックルートを、GUIで簡単にActivate/Inactive変更ができ、その結果として、更新の必要があるSDKサンプルプロジェクトのライブラリを上書き更新します。

NXPのMCUソフトウェア開発は、MCUXpresso IDEに備わったSDKとConfig Tools両方の活用が必須で、前稿と本稿の2回に分けてその使い方を説明しました。

MCUXpresso SDKの使い方

NXP MCUXpresso IDEを使ったFRDM-KE02Z40Mテンプレートv2開発にあたり、MCUXpresso SDKベースのMCUソフトウェアの開発方法を示します。

MCUXpresso SDK全般の使い方

MCUXpresso SDKの全般的な使い方は、IDE付属のGetting Started with MCUXpresso SDKコチラの動画で判ります。どちらも初めてSDK:Software Development Kitを使う時には役立ちますが、具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はありません。

「導入説明だけで活用説明がない」典型例です。

MCUXpresso SDK構造

本稿はソフトウェア開発初心者が、一番知りたいハズだと思うSDKの具体的な使い方:活用の説明をします。SDK全般の使い方:導入説明に関しては、上記リンク先を参照してください。

OpenSDA接続問題

現時点では、FRDM-KE02Z40M(Cortex-M0+/40MHz、5V Robust)のOpenSDAとIDEデバッガ間が接続できない問題があり、代わりにFRDM-KL25Z(Cortex-M0+/48MHz、General Purpose)も使います。FRDM-KL25Zには、接続問題はありません。

※FRDM-KE02Z40MのOpenSDA接続問題は、内容とその解決策を次回以降投稿予定です。

SDK Version

Installed SDK Version (2020-07)
Installed SDK Version (2020-07)

投稿時点のSDK_2.x_FRDM-KE02Z40M(Version 2.7.0)とSDK_2.x_FRDM-KL25Z(Version 2.2.0)が上図です。MCUXpresso IDEへインストールされたSDK Versionが異なることには注意が必要です。

Versionが異なると、SDK提供サンプルプロジェクトやその中身が異なることがあるからです。多くの評価ボードの最新SDK Versionは2.7.0ですので、テンプレートもSDK Version 2.7.0を前提とします。

Hello_worldサンプルプロジェクトと新規作成プロジェクト

Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)
Hello_worldサンプルプロジェクト(左)と新規作成Templateプロジェクト(右)

FRDM-KE02Z40Mのhello_worldプロジェクトが上図(左)です。CMSISやboardなど多くのフォルダがあり、その中にcソースファイルと、hヘッダファイルが混在しています。sourceフォルダ内にhello_world.cとmain関数があります。

このsourceフォルダが、ユーザの開発するc/hファイルを格納する場所で、他のboardフォルダなどは当面無視して構いません。New Projectをクリックし新たなプロジェクト(プロジェクト名:Template)を作成すると、この理由が判ります。

上図(右)が新規作成したTemplateプロジェクトです。sourceフォルダ以外は、hello_worldと同じ構造です。sourceフォルダ内のTemplate.c内に、コメント:/* TODO: inset other… */が2か所あることも判ります。この青色TODOコメントのソース位置は、ソースウインド右端の上下スライダに青で明示されています。

青色TODOコメントは、ソースコードのユーザ追記場所を示します。

最初のTODOコメントの下にユーザ追記インクルードファイルを、次のTODOコメントの下にユーザ宣言や定義を追記し、main関数内にユーザ処理を追記すればTemplateプロジェクトが完成します。

※main関数内にユーザ処理を追記するのは当然のことですので、main関数内にあるべき青色TODOコメントは、省略されています。

MCUXpresso SDK活用のMCUソフトウェア開発方法

前章までのSDK構造をまとめます。

  • ユーザが新規に開発(追記)するソース/ヘッダファイルは、全てsourceフォルダ内に配置
  • IDEが生成したsourceフォルダ>プロジェクト名.cのユーザ追記場所は、目印として青色TODOコメントがあり、上下スライダにも明示される
  • sourceフォルダ以外は、IDEがSDK Versionに応じて自動生成するライブラリフォルダ
  • ライブラリフォルダの中身は、ユーザ編集は不要

SDK付属のサンプルプロジェクトは、SDK構造に基づいてNXPが作成した周辺回路の利用例です。
※サンプルプロジェクトでは、青色TODOコメントは全て省略されています。

MCUが異なっても、同じ処理を行う場合は、sourceフォルダ内のユーザ追記処理も同じハズです。例えば、FRDM-KE02Z40MとFRDM-KL25Zのhello_worldプロジェクト>sourceフォルダ>hello_world.cは、全く同じソースコードで実現できています。

MCU差やSDK Version差は、sourceフォルダ以外のSDK構造部分で吸収されます。導入説明:Getting Started with MCUXpresso SDKの図1は、このことを図示したものです。

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK)

もちろん、旧SDK Versionで未提供なAPIが、新SDK Versionで新たに提供される場合もあります。ただ基本的なAPIは、新旧SDKで共通に提供済みです。

FRDM-KE02Z40MのSDK VersionとFRDM-KL25ZのSDK Versionは現時点で異なるため、IDEが自動生成するフォルダ数は異なります。しかし、ユーザ開発(追記)処理が、sourceフォルダ内で全て完結するSDK構造は同じです。

これが、hello_worldサンプルプロジェクトのようにFRDM-KE02Z40MとFRDM-KL25Z両方に共通で記述できるユーザ処理(Application Code)がある理由です。

SDK構造に沿ったsourceフォルダへのユーザ処理追記と、基本的API利用により、汎用的で効率的なMCUソフトウェア開発が出来ることがご理解できたと思います。

あとがき

2章で、「具体的にSDKを使ってMCUソフトウェア開発をするにはどうすれば良いのかの説明はない」と書きました。しかし、本稿で示したSDK活用説明は、ソフトウェア開発者は当然知っていること・・・だから説明がないとも言えます😅。

このように組込みMCU関連の資料は、前提とするソフトウェア知識・経験をどの読者も既に持っており、本稿記述の当たり前の活用説明は省略する(≒すっ飛ばす)傾向があります。

弊社マイコンテンプレートは、初心者~中級レベルの開発者を対象としており、提供テンプレートも本稿で示したSDK活用方法で開発します。ご購入者様が、なぜこのようなテンプレートになったのか疑問を持った時、それに答えるため、このすっ飛ばした省略部分を補う説明を本稿ではあえて加えました😌。

ARM Cortex-M4とM0+アプリケーションコード互換

NXP MCUXpresso SDK利用を利用すると、LPC845 Breakout board用に開発した1秒赤LED点滅アプリケーションコードが、そのままFRDM-KL25Zへ流用できることを前回投稿で示しました。ただ、どちらも同じARM Cortex-M0+コアのMCU評価ボードなので、読者インパクトは少なかったかもしれません。

そこで、LPC845 Breakout board(Cortex-M0+/30MHzコア)のLED点滅アプリケーションコードが、そのままCortex-M4/100MHzコアのLPCXpreosso54114へ流用できることを示します。異なるARMコア間でのアプリケーションコード互換の話です。

ARMコアバイナリ互換

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

ARMコアのバイナリ上位互換を示す図です(関連投稿:Cortex-M0/M0+/M3比較とコア選択の2章)。このバイナリコード包含関係は、Cortex-M0バイナリコードならCortex-M4でも動作することを示しています。

但し、この包含関係を理解していても、Cortex-M0バイナリコードをそのままCortex-M4へ流用する開発者はいないと思います。

ARMコアアプリケーションコード互換

Cortex-Mxのアプリケーションコード互換性
Cortex-Mxのアプリケーションコード互換性

MCUXpresso IDEのARMコアアプリケーションコード互換を示す図です。左がLPC845 Breakout board(Cortex-M0+/30MHzコア)の1秒赤LED点滅アプリケーションコード、右がCortex-M4/100MHzコアのLPCXpreosso54114の1秒赤LED点滅アプリケーションコードです。

コード差は、L59:LPCXpreosso54114評価ボード動作クロック設定:48MHz動作のみです。例えば、96MHzなどの他の動作周波数へ設定することも可能です。コード上で動作周波数を明示的に表示するために異なりましたが、機能的には両者同じコードと言えます(L59をマクロで書き換えれば、同一コード記述もできます)。

図下のInstalled SDK Versionが、どちらも2019-06-14で一致していることも重要です。Versionが異なると、例えばGPIOのAPIが異なることがあるからです。各SDKリリースノートでAPI差の有無確認ができます。※LPCXpreosso54114 SDKのMCUXpresso IDE設定方法は、コチラの投稿の5/6章を参考にしてください。

1秒赤LED点滅という簡単なアプリケーションですが、Cortex-M0+とCortex-M4の異なるARMコア間でコード互換性があることが解ります。

動作周波数の隠蔽とIO割付

評価ボード動作周波数が異なれば、無限ループ回転速度も異なります。従って、互換性を持たせるコード内に、無限ループ内の回転数でLED点滅させるような処理記述はできません。コードに時間要素は組込めないのです。

1秒点滅の場合は、L77:SysTick_DelayTicks()でループ回転数をカウントし、1秒遅延を処理しています。これにより、GPIO_PortToggle()が時間要素なしとなり、異なる動作周波数のARMコアでもアプリケーションコード移植性を実現しています。

SysTick_DelayTick()と1ms割込みによりカウントダウンする処理コードが下記です。ここも、割込みを利用することでコード移植性を実現しています。

動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現
動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現

左のLPC845 Breakout boardと、右のLPCXpreosso54114のコード差は、L16:赤LEDのIO割付のみです。評価ボード毎に異なるIO割付となるのは、やむを得ないでしょう。L12からL16のDefinition箇所を、別ファイル(例えばIODefine.hやUserDefine.h)として抽出すれば、同一コード記述も可能です。

ARMコアアプリケーションコード互換メリット

以上のように、ARMコアアプリケーションコード互換を目的にした記述や工夫も必要です。しかし、一旦互換コードを開発しておけば、開発資産として他のARMコア利用時にも使えます。その結果、開発速度/効率が高まります。

IoT MCUは、センサ入力やLED出力などのメイン処理以外にも、日々変化するセキュリティ処理への対応は、必須です。メイン処理が出来上がった後での、セキュリティ処理追加という手順です。

セキュリティ対策は、セキュリティライブラリ等の使用だけでなく、いつどのようにライブラリを活用するか、その時のMCU負荷がメイン処理へ及ぼす影響等、検討が必要な事柄が多くあります。

少しでも早くメイン処理を仕上げ、これら検討項目へ時間配分することがIoT MCU開発者には要求されます。この検討時間稼ぎのためにも、ARMコアアプリケーションコードの開発資産化は必須でしょう。

※プロトタイプ開発は、初めから厳しい条件で開発するよりも、最速のCortex-M4で行い、全体完成後Cortex-M0+/M3などへアプリケーションコードを移植するコストダウンアプローチも名案だと思います。

P.S.:2019年9月4日、MCUXpresso IDEがv11.0.1へ更新されました。旧MCUXpresso IDE v11.0.0 [2516]利用中の方は、Help>Check for Updatesではv11.0.1へ更新されません。新にMCUXpresso IDE v11.0.1 [2563]のインストールが必要です。新MCUXpresso IDEインストール方法は、コチラの4章を参照ください。