第2のRAサンプルコード

ルネサスRAファミリ開発に評価ボード毎のサンプルコードが重要であることは、過去何回か投稿済みです。今回は、これとは別の、「Stacks毎」に提供される第2のサンプルコード利用方法を説明します。

RAプロジェクトソースコード開発手順

FSPパースペクティブへ追加するLPM Stack
FSPパースペクティブへ追加するLPM Stack

ごく簡単にRAプロジェクトのソースコード開発手順を説明すると、

1) 利用「Stack」をFSPパースペクティブへ追加
2) Generate Project Contentクリック
3) 生成されたDeveloper AssistanceのStack API群から、利用APIをソースコード上へコピー&ペースト

という3手順の繰返しです。Stackとは、MCU周辺回路のことです。

評価ボードサンプルコードは、あらかじめ1)~3)をエキスパートが行い、サンプルで利用するStackとStack APIは、エキスパートが選択済みの実動作プロジェクトです。

一方、開発者自らが、1)~3)手順でソースコード開発する時は、どのStackを追加するか、利用するAPIは何か、を検討する必要があります。この検討に必要な情報は、全てFSPパースペクティブへ配置したStackのℹ️から得られます。

ℹ️をクリックすると、Stack PropertiesのAPI infoタブ相当の英文解説が読めます。内容は、Function、Overview、Exampleなどです。API info表示内容と同じですが、より詳しい説明が得られます。

「Stack毎」に提供される第2のRAサンプルコードとは、このExampleのことです。

Low Power Modes (r_lpm)の例

RAファミリの4低電力動作モード(出展:RA6E1ユーザーズマニュアル)
RAファミリの4低電力動作モード(出展:RA6E1ユーザーズマニュアル)

MCUアプリケーションに、低電力動作は必須です。RAファミリには、スリープ/ソフトウェアスタンバイ/スヌーズ/ディープソフトウェアスタンバイの4低電力動作モードがあります。例えば、RA6E1グループユーザーズマニュアルハードウェア編の10章を参照ください。

電力消費の最も大きいMCUを停止するのが、スリープモードです。スリープからの復帰時間も短く、簡単で効果的な低電力動作が可能です。

RAファミリで低電力動作を行うには、FSPパースペクティブへ、最初の図に示したLow Power Modes (r_lpm)スタックを追加します。

Stackのℹ️とサンプルコード

追加Stack ℹ️クリックで表示されるのが、LPMの詳細説明です。LPMスタック追加で増える5個全てのLPM APIが解ります。また、スリープモードプロパティがデフォルト設定済みなのも解ります。

このスリープモードのExampleが、下記LPM Sleep Exampleです。

LPM Sleep Example
LPM Sleep Example

利用APIは、R_LPM_Open()とR_LPM_LowPowerModeEnter()の2個のみです。assert(FSP_SUCCESS == err)は、次章で説明します。

注意点は、この「Stacks毎」に提供されるサンプルコードは、一般的なサンプルコード構成、つまり、初期設定と無限ループ内処理の記述形式ではないことです(一般的サンプルコード構成については、コチラの関連投稿参照)。

ここで示されているのは、LPMスリープモード時に利用するAPIとその利用順序です。

つまり、最初にR_LPM_Open()でスタックAPI利用可否を判断し、次に、R_LPM_LowPowerModeEnter()でスリープ動作OKの判断をしているだけです。

LPM以外のStack Examplesでも同様です。繰返しになりますが、Stack Exampleは、利用APIとその利用順序を示します。

従って、自分のソースコードへ取込むには、Developer Assistance内に生成された5個のLPM APIから、R_LPM_Open()を初期設定へ、次に、R_LPM_ LowPowerModeEnter()を無限ループ内の適当な個所へ、コピー&ペーストすれば、LPMスリープモードのソースコードが完成です。

assert(FSP_SUCCESS == err)

assert()は、()内が真の時は、何もしません。偽の時は、発生場所や関数名、ファイル名などをコンソール出力し、プログラムを停止します。API利用後の結果判断に活用しています。

「Stacks毎」に提供されるサンプルコードでは、多くのStack API利用箇所で使われています。

lpm_fpb_ra6e1_wpと比較

lpm_fpb_ra6e1_wpのFSPパースペクティブとhal_entry.cのMain loop部分
lpm_fpb_ra6e1_wpのFSPパースペクティブとhal_entry.cのMain loop部分

評価ボード毎のサンプルコードにも、低電力動作サンプルがありますので、前章Stack Exampleと比較します。

RA6E1の場合は、lpm_fpb_ra6e1_epです。このFSPパースペクティブとhal_entryのMain loopの一部抜粋が上図です。多くのLPM関連スタックが追加済みで、Main loopの低電力動作を解読するのも大変です。

これは、評価ボードサンプルコードが、初めに示した4低電力動作モードの状態遷移を示すプロジェクトだからです。スリープ動作のみを実装する時は、前章LPM StackのExampleを参照した方が簡単に理解できます。

勿論、評価ボードサンプルコードとStack Example、両方を参考にしてソースコードを開発する方が良いことは言うまでもありません。

Stack Exampleが、評価ボードサンプルコード理解を助ける第2のサンプルコードとして役立つことを示したかった訳です。

追加Stacks一覧

本稿は、LPM Stackを例に第2のサンプルコードを説明しました。

FSPパースペクティブへ追加可能なStackは、Stackタブを選択後、右上のNew Stack>をクリックすると一覧表示されます。

まとめ

RAファミリのソースコード開発は、FSPパースペクティブへStackを追加後、一括生成されるDeveloper Assistance内の多くのStack API群の中から、利用APIを適切な順序でソースコードへコピー&ペーストすることで進めます。

利用Stackに複数動作モードがあるなど評価ボードサンプルコードが複雑な場合や、開発者自らが利用Stack APIを検討する場合は、第2のサンプルコードとして、追加Stackのℹ️クリックで得られるExampleに示されるStack APIとその利用順序を参考に、ソースコード開発をする方法を示しました。

最近の組込みCコード書き方

RAファミリFSP生成のBare Metal Blinkyサンプルコードの書き方が、筆者のCコード書き方と違っていて驚いた点を示します(FSP:Flexible Software Packageとは何かは、コチラの関連投稿を参照)。

変数宣言位置

FSP生成Bare Metal Blinkyサンプルコードの変数宣言
FSP生成Bare Metal Blinkyサンプルコードの変数宣言

筆者のC変数宣言は、関数の冒頭、実行文の前に全ての変数宣言を行います。しかし、Bare Metal Blinkyサンプルコードは、変数が必要になった直前で変数宣言をしています。こちらの方が、コードが読み易いですね。

これは、使うC言語規格が異なるからです。筆者は、古いC90(1990年版)、FSPは、C99(1999年版)以降の規格、書き方を採用しています(参考文献:C言語の仕様)。

C言語規格も改良や改版が進み最新規格は、C11(2011年版)です。更に、C17やC2xなどへ進化中だそうです。下位(旧版)互換性は、コンパイラが賢いので保たれています。エッジAIが導入されると、古い書き方は止めなさいとアドバイスが出たりするかもしれません😅。

IoT MCU開発では、従来比、他者が開発したコードやライブラリを読み、理解・利用する機会も格段に増えます。

独立行政法人情報処理推進機構から、組込みソフトウェア開発向けコーディング作法ガイド[C言語版]ESCR Ver. 3.0(2018年)のPDF版がダウンロード可能です。

ガイド想定利用者は、プログラマやレビュー者(P3参照)とありますので、本ブログ読者は目を通しておくのも良いと思います。

新しい規格に縛られる必要は、コンパイラのおかげでありません。しかし、FSP生成サンプルコードに習い、今後はC99以降の書き方を採用します。

いわゆるLチカサンプルコードであっても、なおざりにできない例です。そこで、基になったFSP生成のBare Metal BlinkyとMinimalスケルトン(骨格)の差をまとめます。

Bare Metal Blinky生成方法

各種周辺回路サンプルコードは、FSPとは別に評価ボード毎に提供されます。しかし、Bare Metal Blinkyだけは、FSPで生成可能です(FSPと評価ボード毎の周辺回路サンプルコードは、コチラの関連投稿を参照)。

その狙いは、筆者のような古いC記述者へ新しい記述法を知らせる、または、Blinkyと周辺回路無しのMinimalなスケルトンとの差分を知らせる、などが考えられます。

FSP生成Bare Metal Blinkyは、通常の新規プロジェクト作成方法と同じ、ファイル>新規>Renesas C/C++ Project>Renesas RAクリックが最初の手順です。ダイアログに従って手順を勧めると、最後にBare Metal – BlinkyかMinimalかの選択が可能です。

Bare Metal Blinky生成方法
Bare Metal Blinky生成方法

Blinky選択とFinishクリックで、g_ioport I/O Portスタックだけが配置済みの[Blinky]FSP Configurationパースペクティブが開きます。

[Blinky] FSP Configurationのスタック
[Blinky] FSP Configurationのスタック
念のため、Generate Project Contentをクリック後、src>hal_entry.cを開くと、1章で示したC99以降の書き方で記述したBlinkyサンプルコードが生成されます。

Bare Metal BlinkyとMinimalの差分

Bare Metal Blinky(左)とMinimal(右)の差分
Bare Metal Blinky(左)とMinimal(右)の差分

BlinkyとMinimalスケルトンの差は、hal_entry()のTODO: add your own code hereの下にBlinkyコードが有るか無いかだけです。FSP Configurationも全く同じです。

つまり、IOPORT未使用のアプリケーションは無いので、例えMinimalと言えデフォルトでg_ioport I/O Portスタックは配置済みで、そのスタック利用例がBlinkyという訳です。

FSP生成Bare Metal Blinkyに習い、筆者も今後はC99以降の新しい書き方でCソースコード記述をしていきます。

RAテンプレート仕組み

ルネサスRAファミリテンプレート(ベアメタル編)を3月末目標に開発中です。サンプルコード活用・流用によるアプリケーション開発が容易なことが、弊社テンプレートの特徴です。このテンプレート仕組みを “少しだけ(!?)” 説明します。

全部説明すると、読者ご自身でテンプレートを開発し、購入者数が減るかもしれないからです😂。

仕組みまとめ

MCU開発者の最初の壁に穴をあけるテンプレート
MCU開発者の最初の壁に穴をあけるテンプレート

テンプレートの仕組みを “少し” しか説明しないので、まとめを最初に示します。

MCUアプリケーション早期開発は、ベンダ提供の公式サンプルコード活用・流用が王道です。しかし、単機能の利用例を判り易く示すことが目的のサンプルコードでは、複数機能の並列実装が困難です。

MCU開発の最初の壁が、この「サンプルコードを、どのように実開発へ利用するか」です。

既に弊社テンプレートの購入者様、または上級者は、この壁を突破し効果的サンプルコード活用アプリケーション開発方法を知っています。Know-how(ノウハウ)です。

サンプルコード利用時の課題は、「無限ループ」です。

この課題に、弊社テンプレートは時分割で対応しました。説明を更に加えると、読者がご自分でテンプレート相当を開発される危険性がありますので、仕組み説明はここまでにします。

以降の章は、サンプルコード課題の具体例を示します。また、この課題が生じる原因、特にRAファミリ開発でFSPサンプルコードが重要である訳を説明、最後にテンプレートのメリットを示します。

RAファミリに限らずプロトタイプ開発や早期アプリケーション開発が目的の弊社テンプレートにご興味がある方は、テンプレートサイトに主要ベンダテンプレートが各1000円で販売中、概要は無料ダウンロード可能です。

※RAファミリテンプレート(ベアメタル編)も1000円予定。FreeRTOS対応アプリケーションテンプレートのみ2000円。RAファミリテンプレートもV2以降でRTOS対応予定。

販売テンプレートには、本稿で説明できない多くの工夫も実装済みです。ダウンロード概要を読んで、自作されるよりも、弊社から是非ご購入ください😌。

サンプルコード課題の具体例

評価ボードテストプログラム構造(FPB-RA6E1の例)
評価ボードテストプログラム構造(FPB-RA6E1の例)

サンプルコードを実開発へ利用する時の課題、具体例を示します。

RAファミリ評価ボードのテストプログラム:TPです(プロジェクト名:quickstart_fpb_re6e1_ep)。電源投入後、搭載LEDが点滅し、SW押下げで点滅間隔が変わり、評価ボードの正常性をテストします。

このTPのuser_main部分を抜粋しました。評価ボードにより多少異なりますが、基本動作は同じです。

LED点滅間隔は、無限ループ内のR_BSP_SoftwareDelay(g_delay)が決めます。このR_BSP_SoftwareDelay処理中は、MCUを独占するため、他の処理はできません(割込み処理は除く)。

MCUの並列処理は、RTOS利用が常套手段ですが、RTOS理解やベアメタル比大きな処理能力とRAMが必要です。

そこで、RTOSを使わずにベアメタルで並列処理をするため、LED点滅を時分割処理し、空き時間に別処理を実行するのが、テンプレートの仕組みです。

テンプレートの仕組み
テンプレートの仕組み

サンプルコード課題の原因

サンプルコードの構造は、基本的な「初期設定」+「無限ループ処理」です(基本のキ:組込み処理参照)。

この構造で、①内蔵周辺回路の初期設定 → ②周辺回路の監視(時間消費も含む)→ ③監視結果の処理実行を行います。②と③を、無限ループ内で繰返します。

①初期設定と③結果処理は、開発アプリケーションへそのまま流用ができます。問題は、結果処理以外の無限ループ内が全て監視(時間消費)になる点です。監視中は、他の処理はありません。

つまり、周辺回路のMCU「専用」利用例という訳です。専用ですから、監視結果の処理実行が有ろうが無かろうが問題はありません。

ところが、1つの無限ループ内へ、単純に別周辺回路の「②監視と③結果処理」を入れると、無限ループは、周辺回路「専用」から「共用」へ変ります。

共用する他の周辺回路の監視結果処理の実行有無に応じて、もう1つの周辺回路の監視結果起動間隔も変わります。起動間隔が変わっても問題ない場合もありますが、多くの場合、問題でこれが課題です。

例えば、ウオッチドックタイマ定時リセットや、前章のLED点滅間隔などです。

共用無限ループ内の別サンプルコード処理有無により、当該サンプルコード処理間隔が変わるという問題は、開発初心者には簡単に解決できない大きな壁:課題です。

FSPサンプルコードが重要な訳

FSP構成とGUI設定の様子
FSP構成とGUI設定の様子

RAファミリ共通のHAL API生成ツールがFSPです。FSPのBoard Support Package (BSP)とHardware Abstraction Layer (HAL)Driversが、評価ボードとRA MCU差を隠蔽し、RAファミリ共通APIをGUIで生成します。

Boardは、評価ボードを指しますが、ユーザ独自開発ボードでも、BSPだけを変更すれば、評価ボードを使って開発したソフトウェアが、そのまま独自開発ボード上でも動作します。

つまり、FSPは、プロトタイピング開発に適したツールです。RAファミリアプリケーションの早期開発ポイントは、FSP活用です。但し、FSPソフトウェア開発者は、知っておくべき作法があります。

例えば、2章で示したGPIO制御前後のR_BSP_PinAccessEnable()やR_BSP_PinAccessDisable()などです。これらは、BSP GPIOレジスタの電圧レベルアクセス制御許可/禁止を設定します。

仮に、R_BSP_PinAccessEnable()をコメントアウトすると、ビルドは成功しますがLEDは点滅しません。ワーニングなどもありませんから、作法を知らないと点滅しない原因は、まったく不明になります。

これらは、GPIOアクセスとセットで知るべき作法です。このような作法は、分厚いFSPユーザマニュアルのどこかに記載されているハズですが、ルネサスエキスパートが提供するサンプルコードからセットで抜き出し、そのまま利用する方が簡単です。

※BSP GPIOアクセスの代わりに、上記許可/禁止追記不要なHAL GPIOアクセスもあります。コレも作法の1つです。

また、ルネサス独自内蔵周辺回路:イベントリンクコントローラのサンプルコードなども、同一MCUコア利用の競合他社差別化に役立つかもしれません。
※イベントリンクコントローラは、MCUを介さずに周辺回路間の連携動作が可能なハードウエア。

マニュアルよりもサンプルコードを読み、評価ボードで試す、“習うより慣れよ” です。

FSPサンプルコードは、このような作法や差別化ヒントが詰まった宝庫です。RAファミリアプリケーション開発には、必読書です。

FSP開発例はコチラ、評価ボードサンプルコードは、コチラの関連投稿も参照ください。

テンプレートメリット

本稿では、しばしば “そのまま” という太字キーワードがでてきます。MCUアプリケーション開発は、ベンダ公式サンプルコードが、そのまま利用・活用する部分と、開発者が “工夫を加える部分” とを、素早く見極める目:Know-howも必要です。

Know-how獲得には、弊社テンプレートとMCU評価ボード+Baseboardが、お役に立てると思います。テンプレートもアプリケーションの1つなので、テンプレートへ追記した豊富な日本語コメントで、そのまま流用している部分と、工夫を加えた部分がソースコード上で確認できるからです。

テンプレートを活用し、アプリケーションをプロトタイピング、次ステップでプロトタイプアプリをチューニングし、完成度を上げます。

プロト目的は、アプリ早期開発、この目的に、ベンダ公式サンプルコード流用・活用と弊社テンプレートを利用します。

既製品の流用・活用・利用は、物足りなく感じる方もいるかもしれません。しかし、弊社テンプレートは、チューニング時、開発者が工夫を追加できる余地がいくらでもあります。アプリ完成度向上には、ご購入者独自の工夫も大切ですので、ご安心ください😁。

MCUベンダAPI生成ツール比較

お知らせ

弊社サイト:マイコンRTOS習得を2020年版へ改版しました。前稿までのFreeRTOSサンプルコード(1)~(5)結果を、2017年版へ反映させた結果です。是非、ご覧ください。

MCUベンダAPI生成ツール一覧

FreeRTOSサンプルコード(1)で予告したベンダ毎に異なるAPI生成ツールやその違い、サンプルコードとの関係を説明します。本ブロブ掲載MCUベンダ5社のAPI生成ツール一覧が下表です。

MCUベンダトップシェア5社のMCU API生成ツール一覧
ベンダ API生成ツール ブログ掲載MCU API生成方法
Runesas CS+ RL78/G1x 個別ハードウェア設定
NXP SDK LPC111x/LPC8xx/Kinetis E/LPC5411x MCU設定
STM STM32CubeMX STM32Fx/STM32Gx 個別ハードウェア設定
Cypress PSoC Creator PSoC4/PSoC4 BLE/PSoC4000/PSoC6 個別ハードウェア設定
TI CCS STM432 MCU設定

IDEとは別のAPI生成ツール専用名があり、ツール単独で更新するのが、NXP)SDK、STM)STM32CubeMXです。Runesas)CS+、Cypress)PSoC Creator、TI)CCSは、IDEにAPI生成ツールが組込まれていますので、IDE名称をAPI生成ツール欄に記載しています。
※CS+のAPI生成ツールは、単独でコード生成と呼ぶこともあります。

さて、これらAPI生成ツールには、2種類のAPI生成方法があります。

  • MCU設定:利用MCUを設定し、内蔵ハードウェアAPIを一括生成…NXP)SDK、TI)CCS
  • 個別ハードウェア設定:利用内蔵ハードウェアを個別設定し、APIを生成…Runesas)CS+、STM)STM32CubeMX、Cypress)PSoC Creator

MCU設定タイプのAPI生成ツールは、全内蔵ハードウェアAPIを、ユーザ利用の有無に係わらず一括生成するため、規模が大きく、SDK(Software Development Kit)などパッケージ化してIDEへ提供されます。但し、コンパイル時に利用ハードウェアのみをリンクしてMCUへダウンロードするので、少Flashサイズでも問題はありません。

MCU設定タイプの特徴は、例えば、UART速度設定などのハードウェア動作パラメタは、APIパラメタとしてMCUソースコードにユーザが記述します。

MCU設定タイプのNXP)SDKのUART API例
MCU設定タイプのNXP)SDKのUART API例

一方、個別ハードウェア設定タイプは、UARTなどのハードウェア動作パラメタは、API生成前にGUI(Graphical User Interface)で設定し、設定後にAPIを生成します。このためユーザが、MCUソースコードのAPIに動作パラメタを追記することはありません。

個別ハードウェア設定タイプのSTM32CubeMXのUART API例
個別ハードウェア設定タイプのSTM32CubeMXのUART API例

API生成ツール比較

MCU設定タイプのAPI生成ツールは、使い方がMCU設定のみで簡単です。また、ハードウェア動作パラメタがMCUソースコード内にあるため、動作変更や修正もIDE上で行えますが、人手によるバグ混入の可能性も高まります。

個別ハードウェアタイプAPI生成ツールは、MCUソースコード内のAPI記述が簡素です。生成されたAPI内部に動作パラメタが含まれているからです。但し、ハードウェア動作変更には、IDEから一旦API生成ツールに戻り、APIの再生成が必要です。この場合でも、MCUソースコードは不変ですので、GUI設定にミスが無ければバグ混入は少ないでしょう。

どちらにも、一長一短があります。敢えて分類すると、ソフトウェア開発者向きが、MCU設定タイプ、ハードウェア開発者向きでTP:Test Program応用も容易なのが、個別ハードウェア設定タイプです。

個別ハードウェア設定タイプであっても、Cypress)PSoC Creatorなどは、通常パラメタはBasicタブ、詳細パラメタはAdvanceタブで分け、誰でも設定を容易にしたツールもあります。

MCUソフトウェアは、C言語によるMCU API制御です。MCU API生成ツールの使い勝手が、ソフトウェア生産性の半分程度を占めていると個人的には思います。

サンプルコード/サンプルソフトウェア

各社のサンプルコード/サンプルソフトウェアは、上記API生成ツールのMCUソースコード出力例です。

従って、サンプルコードには、出力例と明示的に判るよう多くのコメントが付加されています。初めてサンプルコードを見る開発者は、注意深くコメントを読んで、そのMCU開発の全体像を理解することが重要です。

全体像が理解済みであれば、より効率的な開発手法、例えば、(推薦はしませんが)個別ハードウェア設定タイプであっても、IDEからAPI生成ツールに戻らずに、直接MCUソースコードでハードウェア動作パラメタを変更するなどのトリッキーな使い方も可能です。

MCU開発とCOVID-19

新型コロナウイルス:COVID-19が世界的に流行しつつあり、工場閉鎖や物流への影響も出始めています。現状は治療薬が無いので、「個人の免疫力と体力」が生死の決め手です。

同時にMCU供給不足/停止など、開発への波及も懸念されます。これに対し「個人で第2のMCU開発力」を持つことが解決策を与えます。

本稿は、MCUベンダトップシェア5社のMCU API生成ツールを比較しました。MCUシェア評価ボード価格や入手性、個人の好みなど、是非ご自分にあった比較項目で、現在利用中のMCUに代わる第2のMCU開発力を持つことをお勧めします。

第2のMCU開発力は、現行と視点が変わり利用中MCUスキルも同時に磨くことができ、様々な開発リスクに耐力(体力)が付きます。短期で効果的な第2のMCU開発力の取得に、弊社マイコンテンプレートがお役に立てると思います。

FreeRTOSサンプルコード(1)

NXPのCortex-M4/M0+ディアルコアLPCXpresso54114のFreeRTOSサンプルコードを数回に分けて調査します。Cortex-M4クラスのMCUは、処理は高速で大容量Flash、RAMを持つので、ベアメタル利用だけでなくRTOS利用ソフトウェア開発にも適します。

ベアメタルCortex-M0/M0+/M3に適用済み弊社テンプレートを、そのままCortex-M4 MCUに使うのは、テンプレートがMCU非依存なので簡単です。ですが、先ずFreeRTOSソフトウェアをよく知り、新開発ベアメタルCortex-M4テンプレートへ応用できる機能があるか判断するのが調査の目的です。

RTOS習得2017

2017年3月にLPCXpresso824-MAX(Cortex-M0+ 30MHz、32KB Flash、8KB RAM)を使ってFreeRTOSのポイントを調査し、結果をマイコンRTOS習得ページにまとめました。

第1部から第3部で、最低限のFreeRTOSと使用APIを解説し、第4部で、最も優れた解説書と筆者が考えるソースコードと評価ボードを使ってFreeRTOS動作解析と習得を行うという内容です。

ただ、自作FreeRTOSサンプルコードの出来が悪く、第4部の動作解析は不十分でした。

そこで、RTOS利用がより現実的なLPCXpresso54114(Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM)評価ボードとSDK付属FreeRTOSサンプルコードを用いて、不十分だった第4部FreeRTOS動作解析に再挑戦します。平たく言えば、NXP公式FreeRTOSサンプルコードを、不出来な自作コードの代わりに利用します😅。

第1回目は、FreeRTOSサンプルコードの出所、FreeRTOS動作を調べる4ツールを説明します。

LPCXpresso54114 SDK付属FreeRTOSサンプルコード

NXPマイコンの公式サンプルコード取得方法は、3つあります。最も新しいのがSDK:Software Development Kitから、2つ目がLPCOpenライブラリから、3つ目がPE:Processor Expertからの取得です。

NXP社が古くから用いてきたサンプルコード提供方法が、LPCOpenライブラリです。
NXPに買収された旧Freescale社のKinetis MCUなどは、PEと呼ばれるGUIベースAPI生成ツールでサンプルコードを提供していました。同じMCUでも提供方法によりAPIは異なり、サンプルコード互換性はありません。
※ベンダ毎に異なるAPI提供方法やその違い、サンプルコードとの関係は、別投稿で説明する予定です。

Freescale買収後のNXPは、SDKで全MCU(=新旧NXP+買収FreescaleのMCU)のAPIとサンプルコードを提供する方法に統一したようです。その根拠は、最新MCUXpresso IDEユーザインタフェースが、SDKの利用前提でできているからです。

現在も提供中のLPCOpenライブラリ内にあるLPCXpresso54114 FreeRTOSサンプルコードは2個、一方、SDK内のFreeRTOSサンプルコードは11個あります。PE提供はありません。

調査対象としては、FreeRTOSサンプルコード数が最多のSDKが適しています。

LPCXpresso54114 FreeRTOS examples in SDK
LPCXpresso54114 FreeRTOS examples in SDK

FreeRTOS実動作解析ツール

MCUXpresso IDE v11.1.0のHelp>Help Contentsに、MCUXpresso IDE FreeRTOS Debug Guideがあります(PDF文書がMCUXpresso IDEインストールフォルダ内にも有り) 。この中に、FreeRTOSサンプルコードデバッグのみに使えるタスク対応デバッガ4ツール(Task List/Queue List/Timer List/Heap Usage)があります。

MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
MCUXpresso IDE Help ContentsのFreeRTOS Debug GuideのShowing FreeRTOS TAD Views
  • Task List:タスク毎のプライオリティ、スタック使用量、動作時間表示
  • Queue List:アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
  • Timer List:RTOSタイマー表示
  • Heap Usage:ヒープ使用量、メモリブロック割当て表示

これらFreeRTOS専用ツールは、FreeRTOSサンプルコードの評価ボード動作後、デバッガ停止中に表示されます。シミュレーションではなく、評価ボードでの「実動作結果」が判ります。開発ソフトウェアだけでなくRTOS使用量が判るので、デバイスにどれ程リソース余裕があるかが判断できます。

RTOSソフトウェアは、ユーザが開発するタスクの単体、結合デバッグに加え、RTOS動作の確認事項が増えます。FreeRTOS実動作解析4ツールは、これらの確認ができます。評価ボードを使ったプロトタイプ開発の重要度は、ベアメタル開発比より大きくなると言えるでしょう。

次回以降、LPCXpresso54114のSDK付属FreeRTOSサンプルコードを、MCUXpresso IDEのFreeRTOS Debug Guideに沿って調査します。