RTOSアプリケーションIoT MCU能力推定

2024年1月4日2024年1月4日 WithHappy

RTOSアプリケーションのIoT MCUにはどの程度のハードウェア能力が必要か?
この答を IEEE標準RTOS のμT-Kernelプログラミングコンテスト対象評価ボードから考察しました。

RTOSコンテスト対象評価ボード

MCUベンダ大手4社：インフィニティ、STマイクロ、NXP、ルネサス協賛のRTOSプログラミングコンテストが開催中です。RTOSは、IoT MCU世界標準のμT-Kernel 3.0利用がコンテスト条件です（関連投稿：前投稿）。

但し4社評価ボードは、μT-Kernel以外にもFreeRTOSやAzure RTOSでも動作可能です。そこで、これら評価ボードスペックを分析すると、RTOSアプリケーションのIoT MCUに、どの程度のMCUハードウェア能力が必要か、その目安が判ると思います。

コンテスト対象評価ボードは、ベンダ4社評価ボードと英BBC開発micro:bit、合わせて5種です。

インフィニティ：KIT_XMC72_EVK
STマイクロ：Nucleo_H723ZG
NXP：MCX N94x評価ボード（１月４日現在Coming Soon）
ルネサス：EK-RA8M1
BBC：micro:bit

評価ボードMCUコアとROM/RAM量

各評価ボードは、どれもARM Cortex-M系コアを用いています。

インフィニティとSTマイクロは、ハイパフォーマンスMCU Cortex-M7、NXPは、Trust Zone搭載MCU Cortex-M33、ルネサスは、AI/ML性能向上のArm Helium搭載MCU Cortex-M85、BBC開発micro:bitは、ベーシックなMCU Cortex-M4です。

評価ボードのCortex-Mコアと最高動作速度、ROM/RAM量が下表です。

ベンダ	Cortex-Mコア/速度	ROM（KB）	RAM（KB）
インフィニティ	M7/350MHz	8192	1024
STマイクロ	M7/550MHz	1024	564
NXP	M33/150MHz	1024	1024
ルネサス	M85/480MHz	2049	1024
BBC	M4/64MHz	512	128

BBC開発micro:bitは、他に比べスペックが劣っています。
これは、μT-Kernel 3.0学習教材用でコスト最優先のためと思います。

ベンダ4社評価ボードは、RTOSコンテスト参加ハードウェアなので、どれも汎用RTOSアプリケーション開発ができるハズです。コンテストエントリー時に、応募者が第3希望まで評価ボードを選べます。

IDEはRTOSもベアメタルも同じ

ベンダ4社は、ベアメタル開発用の統合開発環境：IDEを利用し、FreeRTOSやAzure RTOS開発環境を提供中です。

例えば、STマイクロは、ベアメタル開発で使うSTM32CubeIDEに、ミドルウェアのAzure RTOS開発ツールを追加し、Azure RTOS開発環境を、ユーザ自身で構築します（関連投稿：STM32 Azure RTOS開発ツール拡充）

コンテストは、μT-Kernel 3.0 RTOS開発です。筆者は、μT-Kernel 3.0をベンダ4社評価ボード上で動作させる作業、いわゆるポーティング処理は、把握していません。

しかし、本稿主題は、RTOS IoT MCUに必要なハードウェア能力の推定です。従って、評価ボードへのμT-Kernel 3.0ポーティングは、無視します。

一方、micro:bitは、μT-Kernel 3.0で動作するEclipse IDEが提供されます。従って、どなたでも直ぐにmicro:bit上でμT-Kernelを動かすことができます。この点も、教育用に適しています。

RTOS IoT MCUハードウェア能力推定

最初の表に戻り、RTOS IoT MCUに必要なハードウェア能力を推定します。

ベンダ	Cortex-Mコア/速度	ROM（KB）	RAM（KB）
インフィニティ	M7/350MHz	8192	1024
STマイクロ	M7/550MHz	1024	564
NXP	M33/150MHz	1024	1024
ルネサス	M85/480MHz	2049	1024
BBC	M4/64MHz	512	128

先ず、MCUコア能力は、micro:bitスペックから最低でもCortex-M4以上、RTOSアプリケーションを実用的に開発するには、Flash ROMは1024KB以上が必要そうです。教育用micro:bitの512KBは、排除しました。

また、RTOSは、動作タスク数に比例し使用スタック量が急増します。これは、RTOSが実行タスクを別タスクへ切替える毎に、実行タスク変数やレジスタ等の状態をスタックにプッシュするためです。タスク再実行の際には、RTOSがスタックからポップし、実行前タスク状態へ戻します。

仮に、このRTOSポップ/プッシュに対してスタック量が不足した場合は、再現し難いバグになります。このバグを避けるには、必要十分な量のスタック領域が、RAM上に必要となります。スタック量を見積もるツールは、各社のIDEに付属しています。

表から、RTOSアプリケーション開発には、RAMは、最低でも512KB、安全側評価なら1024KB程度が必要そうです。

Summary：RTOS IoT MCUハードウェア能力

RTOSアプリケーションが動作するIoT MCUに必要なハードウェア能力を、μT-Kernelプログラミングコンテスト対象評価ボードから考察した目安が下記です。

MCUコア：ARM Cortex-M4以上、Flash ROM 1024KB以上、RAM 512KB以上

RTOSアプリケーション開発時には、MCUデバイスコストと発展性の検討が必要です。

機能拡張や横展開が期待できるRTOSアプリケーションなら、IDE付属スタック見積ツールを活用し、RAMに余裕があるデバイスが、効率的で安全な開発ができそうです。

Afterword：2024年もよろしくお願いします

日本時間の毎週金曜日、MCU話題を中心に、その開発環境のWindowsや比較対象にMPU/SBCなども混ぜながら、IoT MCU開発お役立ち情報を投稿します。

「開発スピードと成果」この2つを強く求められるのが、MCUに限らず開発者の宿命です。

激変MCU環境で背反するこの2つを両立する手段の1つが、MCUテンプレートだと筆者は考えています。開発初期立上げをスムースにし、全体像の視点を持ちつつ個々の機能追加もできるからです。
RTOS MCU開発も同様だと思います。

但し、全て自作するベアメタル開発と異なり、RTOSと協調動作するのがRTOS MCU開発です。RTOSを活かすMCUタスク作成や本稿のMCUハードウェア能力を、弊社RTOSテンプレートへ反映したいと考えております。

本年もどうぞよろしくお願いいたします。

※FreeRTOS version 11.0.0は、マルチコアMCU動作が可能になりました。

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

2022年2月25日2022年3月4日 WithHappy

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

変数宣言位置

筆者の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かの選択が可能です。

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

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

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ソースコード記述をしていきます。

FreeRTOSアプリケーションテンプレート発売

2021年6月25日2021年12月12日 WithHappy

ARM Cortex-M4コア動作のFreeRTOSアプリケーションテンプレート第一弾、NXP）LPCXpresso54114対応版（税込2000円）を本日より発売します。概要、要点、FreeRTOSアプリケーションテンプレートとは、に関する説明資料は、コチラから無料ダウンロードできますのでご覧ください。

開発背景

IoT MCUのクラウド接続には、AWSならAmazon FreeRTOS、Microsoft AzureならAzure RTOSなどのRTOSが必要です。クラウド側からは、1つのRTOSライブラリを使って様々なMCUハードウェアを接続するための手段、これがRTOSです。

一方、IoT MCU側からは、接続先サービスに応じたRTOSライブラリ利用に加え、従来のベアメタル開発からRTOS上でのアプリケーション開発へ発展する必要もあります。IoT化に伴うこのような変化に対し、開発者個人が手間なく対応するためのツール、これが弊社FreeRTOSアプリケーションテンプレートです。

目的

FreeRTOSアプリケーションテンプレートの目的は、「RTOS基礎固め」と「FreeRTOSプロトタイプ開発のスタートプロジェクトとなること」の2点です。

RTOS開発は、ベアメタル開発とは異なります。

RTOS Kernelが、開発した処理（タスクやThread）と他タスクの優先順位により、処理実行/待機を決めます。開発タスク単体の流用性は高まりますが、タスク間同期や通信に、セマフォやQueueなどのRTOS独特の手段が必要です。

IoTにより全てのモノ（MCU）がクラウドへ接続する時代の基盤は、RTOSです。

ベアメタル開発経験者が、このRTOSの早期基礎固め、Kernelと自身で開発したタスクの並列処理を理解するには、個々にRTOS手段を説明するサンプルソフトよりも、具体的なRTOSアプリケーションの方が実践的で役立ちます。

RTOSアプリケーションがあれば、優先順位を変えた時のタスク動作変化や、その他経験に基づいたRTOS実務開発で知りたい事柄を手間なく試し、新たな知見・見識を得られるからです。これらは、サンプルソフトや、説明文から得ることは困難で、実際のRTOSアプリケーションで開発者自身が試行するのがベストです。

そこで、各FreeRTOS手段を説明した弊社MCU RTOS習得ページを理解した次の段階として、最初の図に示したプロトタイプ開発着手に必須となるADC/LCD/SW/LED/VCOM処理を、NXP）LPCXpresso54114（Cortex-M4/150MHz、Flash/256KB、RAM/192KB）とBaseboard、Arduinoプロトタイプシールドに実装し、動作確認済みRTOSプロジェクトが、FreeRTOSアプリケーションテンプレートです。

FreeRTOS Application Template (NXP Version)

※上記プロジェクトは、クラウド接続は行っておりません。RTOS基礎固めとFreeRTOSプロトタイプ開発に適すことが目的ですので、クラウド接続RTOSライブラリは未実装です。

FreeRTOSを選んだのは、現在MCU RTOSシェア1位だからです（関連投稿はコチラ）。RTOS手段は、各RTOS共通技術であるSemaphoreとQueueの2つを用いております。LPCXpresso54114のFlashやRAM使用量にはまだ十分余裕がありますので、より高度なミューテックスやイベントグループなどの手段を適用するのも容易です。

特徴

本テンプレートには、上記FreeRTOSプロジェクトと同じ動作確認済みのベアメタル開発プロジェクトも添付しております。これは、ベアメタル開発に慣れた方が、FreeRTOSとベアメタルの差分をより明確に理解し、比較や評価をするためです（比較・評価は、ご購入者ご自身で行って頂きます）。

本テンプレート付属説明資料は、主にベアメタル開発者視点から見たFreeRTOSプロジェクトを解説しており、ベアメタルプロジェクトに関する説明は、ソースコードを読めばご理解頂けるとして省略しております。

従って、FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者を対象といたします。ベアメタル初心者の方は、先ずは各MCUベンダCortex-M0+/M3コア対応の従来マイコンテンプレートをご購入ください。従来テンプレート付属説明資料には、ベアメタル動作の詳しい説明が付いています。

※本テンプレートのベアメタルプロジェクトは、従来テンプレートCortex-M0+/M3コアをCortex-M4コア対応へ発展させたものです。ベアメタルプロトタイプ開発着手時に適すプロジェクトです。

FreeRTOSアプリケーションテンプレートは、ベアメタル開発経験者が、手間なく直にRTOSとベアメタルの差を理解・実感し、かつ、IoT基盤RTOSの効率的な基礎固めができるツールです。

なお、既に従来マイコンテンプレートご購入者様は、50％OFF特典があり、税込1000円にて本FreeRTOSアプリケーションテンプレートをご購入頂けます。弊社での確認ミスを防ぐため、ご購入時に従来テンプレート購入者様である旨、お知らせください。

勿論、従来テンプレートとFreeRTOSアプリケーションテンプレートの同時購入でも、この特典は適用されます。

まとめと今後

ベアメタル開発経験者が、IoT MCUクラウド接続に必要となるRTOSの効率的な基礎固め、FreeRTOSプロトタイプ開発着手プロジェクトとして使えることを目的に、NXP）LPCXpresso54114、Baseboard、Arduinoプロトタイプシールドを使ったFreeRTOSアプリケーションテンプレートを発売しました。

本テンプレートは、Amazon FreeRTOSのHardware Independent FreeRTOS Exampleを原本としています。第1弾はNXP）LPCXpresso54114へ適用しましたが、今後、STマイクロエレクトロニクス）STM32G4やCypress)PSoC 6など他社Cortex-M4コアの対応版も開発予定です。

組込みMCU開発お勧めブログ

2021年5月14日2021年12月12日 WithHappy

組込み開発全般に参考となる英語ブログを紹介します。特にRTOS関連記事は、内容が濃く纏まっていて、実践開発時の示唆に富んでいます。

RTOSカテゴリー

組込み開発コンサルティングも行うBeningo Embedded社は、高信頼の組込みシステム構築と低コスト・短時間での製品市場投入を目標としています。この目標に沿って、複雑な組込み開発概念を、シンプルに解り易く解説しているのが、同社ブログです。

特に、RTOSカテゴリーは、FreeRTOS開発方法を整理する時、参考になります。最新RTOSの3投稿をリストアップしたのが下記です。

2021年5月4日、A Simple, Scalable RTOS Initialization Design Pattern
2020年11月19日、3 Common Challenges Facing RTOS Application Developers
2020年10月29日、5 Tips for Developing an RTOS Application Software Architecture

Data flow diagram for a smart thermostat（出展：JACOB'S Blog） — Data flow diagram for a smart thermostat（出展：JACOB’S Blog）

開発中の弊社FreeRTOSアプリケーションテンプレートは、「ベアメタル開発経験者が、FreeRTOS基礎固めと、基本的FreeRTOSアプリケーション着手時のテンプレートに使えること」が目的です。従って、必ずしも上記お勧めブログ指針に沿ったものではなく、むしろ、ベアメタル開発者視点でFreeRTOSを説明しています。

弊社テンプレートを活用し、FreeRTOSを理解・習得した後には、より実践的なRTOS開発者視点で効率的にアプリケーションを開発したいと思う方もいるでしょう。もちろん、弊社FreeRTOSアプリケーションテンプレートからスタートすることを弊社は推薦しています。

しかし、Windows上でアプリケーション開発する時は、初めからWindows作法やGUIを前提として着手するように、RTOS上でMCUアプリケーションを開発する時も、従来のベアメタル開発に固執せず、RTOSオリエンテッドな手法で着手するのも1方法です（ベアメタル経験が少ないWindows/Linux世代には、親和性が高い方法かもしれません）。

推薦ブログは、この要望を満たすRTOS手法が豊富に掲載されています。

また、上記RTOS関連3ブログを（掲載図を「見るだけでも良い」ので）読んで、ピンとこなければ、RTOS理解不足であると自己判断、つまり、リトマス試験紙としても活用できます。

問題整理と再構築能力

ベアメタル開発経験者が、RTOSを使ってMCUアプリケーション開発をするには、従来のBareMetal/Serial or Sequential動作からRTOS/Parallel動作へ、考え方を変えなければなりません。弊社FreeRTOSアプリケーションテンプレートは、この考え方を変えるための橋渡しに最適なツールです。

橋を渡りきった場所が、RTOSの世界です。RTOS環境での組込み開発問題を整理し、シンプルに解決策を示すには、知識や経験だけでなく、問題再構築能力が必要です。JACOB’S Blogをご覧ください。RTOSに限らず組込み関連全般の卓越した問題再構築能力は、掲載図を見るだけでも良く解りますよ😄。

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

2021年4月2日2021年12月12日 WithHappy

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

この開発で用いる新規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を使わずにベースプロジェクトへ手動で追加するのは、手間やケアレスミスが発生します。

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

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

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

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

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

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

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

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

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

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

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

Step1：評価ボード選択

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

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

Step2：FreeRTOS選択

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

Step3：FreeRTOSドライバ選択

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

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低電力動作追記

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

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

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

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

FreeRTOSアプリケーションテンプレート構想

2021年3月12日2021年3月19日 WithHappy

2021年6E目標に、FreeRTOSアプリケーションテンプレート新発売（税込価格2000円予定）を目指しています。このFreeRTOSアプリケーションテンプレート構想を示します。

FreeRTOSアプリケーションテンプレート構想骨子

実務利用可能なFreeRTOSアプリケーションテンプレート提供
FreeRTOS開発とベアメタル開発のアプリケーション直接比較可能
第1弾はNXP）LPCXpresso54114のSDK（Software Development Kit）で開発、次回STMのコード生成ツールなど利用予定

FreeRTOSソフトウェア開発は面白いです。従来ベアメタル開発手法が使える部分と、新たにFreeRTOS向きの工夫が必要な部分、つまり差分があるからです。

弊社FreeRTOSアプリケーションテンプレートは、この面白さや差分を開発者に味わって頂き、IoT MCUのRTOS普及期に備えることを目的に開発しようと考えています。

対象者は、既にMCUベアメタル開発ができ、新たにFreeRTOSを習得したい開発者とします。過去に弊社テンプレートのご購入者様は、50%割引特典の1000円で購入できます。MCUコアは、FreeRTOS能力を十分引き出すCortex-M4クラスを利用します。

FreeRTOS講座問題点

MCUベンダによるFreeRTOS講座は、①FreeRTOS基礎知識、②FreeRTOSのIDE利用方法、③クラウド接続例など盛りだくさんの内容です。

FreeRTOS基礎知識で、セマフォなどのFreeRTOS関連技術やタクス分割、ユーザタスクプライオリティ、RAM使用量増加などが理解できますが、サンプルコード以外の具体的なアプリケーションでもFreeRTOSを動作させたいと欲求不満になります。
FreeRTOSのIDE利用時、特にコード生成ツールをIDEと併用する場合、①で使ったFreeRTOSサンプルソースコードに、更にベアメタル開発が前提のコード生成ツール出力コードも加わるため、追加分がFreeRTOS理解の邪魔になります。
IoTクラウド接続にFreeRTOSは必須です。しかし、主流のAWS（Amazon Web Services）以外にもMicrosoftのAzureなどもあり、FreeRTOS以外の様々な知識（例えばMQTTプロトコルなど）がクラウド接続のためだけに必要です。

FreeRTOS本体とユーザ追加タスク、この「両方の動作」をしっかりと把握しないとFreeRTOS開発のメリットが享受できないこと、これがベアメタル開発との最大の差です。

FreeRTOSとベアメタルとの違いを理解することが最優先、2. はSDK利用で回避、3. は時期尚早です。

ベンダ講座の主旨は、①FreeRTOS基礎知識に加え、自社製品へのユーザ囲い込みも目的のため、②や③は必然です。しかし、現段階ではFreeRTOSそのものを知り、IoT MCUのRTOS普及期（FreeRTOS、Mbed OS、μITRONなど）に備えるためのツールが欲しいと思い、ネット検索しましたが見当たりません。

そこで、開発するのが弊社FreeRTOSアプリケーションテンプレートです。

FreeRTOSアプリケーションとベアメタル比較

FreeRTOSサンプルコードは、セマフォなどのFreeRTOSで使う技術解説が目的です。従って、サンプル付属タスクはシンプルで解り易く作られています。

サンプルコードは、実務アプリケーションとは乖離しており、タスク分割やユーザタスクが複数ある時の優先順位設定、RAM使用量がベアメタル比どれ程増加するかなど肝心のFreeRTOS実務利用時ノウハウは、サンプルコードからは判りません。

そこで、弊社が過去提供してきたベアメタル開発のIoT Baseboardテンプレートと同じ動作のアプリケーションを、FreeRTOSを使って開発します。つまり、同じ評価ボードで同じアプリケーション動作を、FreeRTOSとベアメタルの両方で開発します。

ベアメタル開発IoT Baseboardテンプレート（評価ボードはFRDM-KL25Z、これがLPCXpresso54114に変る）

FreeRTOS/ベアメタル両アプリケーションの比較により、複数実務タスクでの優先順位設定やRAM増加量が具体的に判ります。また、優先順位やRAM使用法などのFreeRTOS重要パラメタを変えた時の動作変化も判ります。

もちろん一例にすぎませんが、FreeRTOS/ベアメタルのアプリケーション差、開発困難/容易、消費電力差など、実務開発時に知りたい事柄を評価でき、かつ、基本的なFreeRTOSアプリケーションのテンプレートとしても利用可能です。
※FreeRTOS/ベアメタル評価は、ご購入者様ご自身で行ってください。

FreeRTOSアプリケーションテンプレートは、下記動作を予定しています。

評価ボード搭載LED周期点滅とVCOMメッセージ入出力
Arduinoプロトタイプシールド搭載ユーザSWプッシュによる搭載LED点滅
Baseboard搭載LCDメッセージ出力とポテンショメータADC変換値のLCD出力

FreeRTOS/ベアメタル両アプリケーションは、評価ボード＋Arduinoプロトタイプシールド＋Baseboardで動作確認済みです。FreeRTOSアプリケーションテンプレートには、FreeRTOS/ベアメタルそれぞれの動作プロジェクトファイルがあり、FreeRTOSアプリケーション詳細説明を付属資料へ添付します。
※ベアメタルアプリケーションの説明は、紙面が多くなり、過去弊社テンプレートご購入者様には不要ですので省略予定です。

SDKとコード生成ツールのAPI比較

FreeRTOSアプリケーションテンプレートの第一弾評価ボードは、NXPのLPCXpresso54114 (Cortex-M4/100MHz、256KB/Flash、192KB/RAM）を使います。

弊社MCU RTOS習得（2020年版）の解説にも使っていること、FreeRTOSサンプルコードが11種類と多く、かつSDKで提供されていることが理由です。

SDKとコード生成ツールのAPI比較は、コチラの関連投稿の3章をご覧ください。SDK利用を、関連投稿ではMCU設定タイプと記載しています。

APIパラメタが多いのがSDKです。このパラメタをFreeRTOS側でも使う可能性があること、コード生成ツールの使い方を別途説明しなくてもFreeRTOSサンプルコードのみに集中できること、これらも第一弾評価ボードにLPCXpresso54114を選定した理由です。

STマイクロエレクトロニクスのコード生成ツール：STM32CubeMXも、FreeRTOSアプリケーション開発に適応済です。第1弾はSDK利用ですが、STM32G4（Cortex-M4/170MHz、512KB/Flash、96KB/RAM）評価ボードなど、コード生成ツール利用のCortex-M4クラスMCUも、順次FreeRTOSアプリケーションテンプレートを開発したいと考えています。

クラウド接続はブラックボックスライブラリ利用

IoT MCUと接続するクラウドは、無償ではありません。接続には、クラウド側から有償接続ライブラリを取得し、これをIoT MCUのFreeRTOSへ組込んだ後、必要な接続APIを利用します。

有償ライブラリ自身は、ユーザがその内容を変える必要は無く、ブラックボックスとして利用するだけです。IoTクラウド接続時には必須ですが、FreeRTOS理解・習得時には不要です。

まとめ

Cortex-M4クラスのIoT MCUへFreeRTOSを利用するメリットは、独立の単体タクス設計ができ開発タスク資産化も容易なことです。

しかし、複数タスクをFreeRTOSで上手く動作させるには、タスク間の優先順位設計やRAMメモリ使用法などベアメタル開発には無かったFreeRTOS向けの新スキルが必要になります。

これらスキル習得とFreeRTOS基礎固め、FreeRTOS/ベアメタル比較評価のため、開発者個人で低価格購入できるFreeRTOSアプリケーションテンプレートを6E目標に開発予定です。これは、基本的なFreeRTOSアプリケーションのテンプレートとしても利用可能です。

発売時には、FreeRTOSアプリケーションで実際に使用した実務FreeRTOS技術、優先順位設計結果なども付属資料で示します。

本FreeRTOSアプリケーションテンプレートに関するご意見などは、info@happytech.jpへお寄せください。

IoT MCUとAI

2021年2月19日2021年12月12日 WithHappy

ARM Cortex-Mコア利用のIoT MCU現状と、次のムーア則を牽引すると言われるAI（人工知能）の関係についてまとめました。

Cortex-Mコア、IoT/組込みデバイス主要ポジション堅持

ARMベースチップ累計出荷個数は1,800億個以上（出展：ニュースルーム、February 16, 2021）

2021年2月16日、英）ARM社は、ARMチップの2020年第4半期出荷が過去最高の67憶個、累計出荷個数1800憶個以上、Cortex-Mチップも4半期最高44憶個出荷で「IoT/組込みデバイス主要ポジション堅持」と発表しました（ニュースルーム）。

Cortex-Mチップの出荷内訳は不明ですが、Cortex-M4やCortex-M0+などコア別の特徴が解るARM社の解説は、コチラにあります（フィルタのProcessorファミリ＞Cortex-Mを選択すると、提供中の全10種Cortex-Mコア解説が読めます）。

筆者は、セキュリティ強化コアCortex-M23/33/35P/55を除く汎用IoT/組込みデバイスでは、Cortex-M4/M0+コア使用数が急増していると思います。

関連投稿：Cortex-M33とCortex-M0+/M4の差分

半導体ムーア則、牽引はチップレット

ムーアの法則次なるけん引役は「チップレット」、2021年2月16日、EE Times Japan

次のムーア則を牽引するAI処理能力（出典：AI Hardware Harder Than It Looks）

半導体製造プロセスを牽引してきたのは、PCやスマホでした。しかしこれからは、人工知能：AIで急増するAIデータ処理能力を実現するため、レゴブロックのようにコアの各モジュールを歩留まり良く製造・配線するチップレット手法が必要で、このチップレット、つまりAIが次の半導体ムーア則を牽引するというのが記事要旨です。

このチップレット手法で製造したIoT MCUやMPUへ、主にソフトウェアによるAI化は、シンギュラリティ後のAI処理量変化にも柔軟に対応できると思います。

関連投稿：今後30年の半導体市場予測

ルネサス：ハードウェアアクセラレータコアCNN（Convolutional Neural Network）

2021年2月17日、ルネサスは、世界最高レベルの高性能/電力効率を実現するディープラーニング性能を持つCNNアクセラレータコアを発表しました（ニュースルーム）。これは、主にハードウェアによるAI化の例です。

ADAS実現に向け、性能と消費電力を最適化した車載用コアです。このコアに前章のチップレット手法を使っているかは不明です。3個のCNNと2MB専用メモリの実装により、60.4TOPS（Tera Operations Per Second）処理能力と13.8TOPS/W電力効率を達成しています。

車載で実績を積めば、IoT MCUへも同様のハードウェアアクセラレータが搭載される可能性があります。

まとめ

凸版印刷社は、画像認識AIを活用し、古文書の“くずし字”を解読支援するツールを開発しました（2021年2月16日、IT media）。このように、AIは、半導体技術のムーア則だけでなく、IoT MCUアプリケーションや人間生活に浸透し、牽引しつつあります。

エッジAIをクラウド接続IoT MCUへ実装する理由は、クラウドAI処理とクラウド送信データ量の両方を軽減することが狙いです。AI処理をエッジ側とクラウド側で分担しないと、チップレット手法を用いて制御チップを製造できたとしても、コスト高騰無しに急増するAIビックデータ処理を実現することが不可能だからです。

IoT MCUのエッジAIが、ソフトウェアまたはハードウェアのどちらで処理されるかは判りませんが、必須であることは確実だと思います。実例を挙げると、STマイクロエレクトロニクスは、既にSTM32Cube.AIにより汎用STM32MCUへAI/機械学習ソフトウェアの実装が可能になっています。

無線STM32WBと汎用STM32G4比較

2021年1月15日2021年10月28日 WithHappy

STマイクロエレクトロニクスの近距離無線通信機能付きSTM32WB（Cortex-M4/64MHz）と、汎用メインストリームSTM32G4（Cortex-M4/170MHz）を比較します。

Bluetoothなどの超省電力無線通信は、IoTデバイスに好適です。無線機能付きSTM32WBのIoTアプリケーション開発方法を調査し、汎用STM32G4を使ったSTM32WBのIoTアプリケーション開発の可能性とメリットを検討しました。

ディアルコアSTM32WBとシングルコアSTM32G4

STM32WBとSTM32G4、どちらもARM Cortex-M4コアを持つMCUです。違いは、STM32WBが、無線処理専用Cortex-M0+コア/32MHz内蔵のディアルコアMCUという点です。

Cortex-M4とM0+コア間のアプリケーションは、プロセス間通信コントローラ（IPCC）によりノンブロックイングで割込み利用のメッセージ交換が可能です。IPCCは、コアをSleep/StopモードからRunモードへ復帰させることもできますので、両コアは別々に低消費電力動作ができます。

STM32WBシリーズの紹介スライドP2から抜粋したSTM32WBとSTM32G4の位置づけが下記です。ワイヤレスマイコンのSTM32WLとSTM32WBの違いは、WLはLoRaWANなど、WBはBluetoothなどのサポート無線規格が異なる点ですが、Cortex-M4とM0+のディアルコア構成は同じです。

無線コプロセッサ：Cortex-M0+コア

STM32WBのCortex-M0+コアは、Bluetooth 5、ZigBee、OpenThreadなど2.4GHz帯無線通信処理専用です。ユーザ（開発者）は、利用する無線規格（BLE⇋ZigBeeなどのブリッジも可能）を選択し、STマイクロエレクトロニクス開発の無線専用ファームウェアをCortex-M0+へダウンロードします。但し、このファームウェアに手を加えることはできません。

言い換えれば、Cortex-M0+側の無線処理はSTの動作保証付きで、ファームウェアバージョンアップなどのメインテナンスは必要ですが、ユーザ変更などは不必要、ブラックボックスとして扱える訳です。

つまり、見た目はディアルコアですが、STM32WBのCortex-M0+は無線コプロセサで、外付け無線モジュールと同等です。従って、ユーザが開発するSTM32WBのIoTアプリケーションは、シングルコアのSTM32G4と同じ手法で開発が可能です。

Bluetooth 5（BLE含む）とサンプルプログラム

STM32WBの無線規格は、Bluetooth5やZigBeeなど複数プロトコルをサポートしています。このうち、IoTセンサの少量データ収集アプリケーションに好適なBluetooth5とBLEの詳細は、Bluetooth Low Energyプロトコルの基礎知識に説明があります。BLEを利用するIoTセンサ・アプリケーションを開発する場合には、最低限必要となる知識です。

STM32WBには、開発環境STM32CubeWBとP-NUCLEO-WB55評価ボードで動作する様々なBLEサンプルプログラムがあります。サンプルプログラムの解析やこれらを応用したIoTアプリケーション開発時、BLE基礎知識が役立ちます。

また、P-NUCLEO-WB55評価ボードとスマートフォンをBLE接続し動作するサンプルプログラムもあります。

FSU： Firmware Upgrade Services

ディアルコアSTM32WBのCortex-M4アプリケーション開発時は、Cortex-M0+ファームウェアも同時にFlashへ書込みます。この点が、シングルコアSTM32G4開発と異なる部分です。

このFlash書込みには、STM32CubeProgrammmerのコマンドライトツール（CLI）で提供されるFSU：Firmware Upgrade Servicesを使います（動画説明はコチラを参照してください）。

簡単に言うと、Cortex-M4とCortex-M0+でメモリ共有中のFlashへ、ユーザ開発Cortex-M4アプリケーションを書込む時に、同時に通信Cortex-M0+ファームウェアも更新する仕組みで、手順さえ守れば通常のSTM32CubeIDEを使ったシングルコアSTM32G4のFlash書込み同様簡単です。

Flash書込み後は、STM32G4と同じ方法でアプリケーションデバッグを行います。

無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4比較結果

P-NUCLEO-WB55とNUCLEO-G474RE — STM32WB評価ボードP-NUCLEO-WB55（左）とSTM32G4評価ボードNUCLEO-G474RE（右）

本稿で示したSTM32WB関連情報は、昨年末に行われたSTマイクロエレクトロニクス日本語ウェビナー資料から抜粋したもので、STM32マイコン体験実習（Bluetooth^®編）でオリジナル動画とスライドが公開中です。また、STM32WBトレーニング資料とCortex-M4トレーニング資料も参考にしました。

前章までで、無線通信機能付きディアルコアSTM32WBと汎用シングルコアSTM32G4を比較し、下記を得ました。

ディアルコアSTM32WBのCortex-M0+側は、通信コプロセサでブラックボックとして扱える。
例えば、IoTセンサデータ収集などのCortex-M4側IoTアプリケーションを、HAL（Hardware Abstraction Layer）APIで開発すれば、通信部分は異なるがデータ収集部分はSTM32WBとSTM32G4で共通開発できる。
STM32WBとSTM32G4で異なる点は、評価ボードへのFlashプログラミングだが、手順は簡単。
STM32WBのFlashプログラミングで用いたSTM32CubeProgrammerは、STM32G4のRoot of Trustで用いたもので、STM32WBでもSTM32G4と同様のRoot if Trustを実現できる。

HAL APIはコチラの関連投稿などを、STM32G4のRoot of Trustはコチラの関連投稿を参照してください。

STM32WBのIoTアプリケーションを汎用STM32G4で開発

最初の図に示したCortex-M4動作最高周波数の64MHzと170MHz、デバイスFlash/RAM容量差に注意すれば、STM32WBのIoTアプリケーションを汎用STM32G4で開発することは、可能でメリットもあると思います。

前提条件として、HAL API開発であること、STM32WBのIoTアプリケーション用Flash/RAM容量が、無線通信コプロセサCortex-M0+が使っても十分残ること、無線通信の代用としてUSARTなどの有線通信を使うこと、などです。FreeRTOS利用が良い場合があるかもしれません。

無線コプロセサCortex-M0+使用容量は、かなり少なく（ウェビナーでは使用量が公表されましたが数値未取得）Cortex-M4 IoTアプリケーション用空き容量は十分あります。また、汎用STM32G4の方が高速動作のため開発制約条件も緩いです。無線では、通信断時のエラー処理検討が必要ですが、有線ですのでエラー処理なしで本来の通信処理は開発可能です。

つまり、STM32WBの無線通信エラー処理以外は、ほぼ全て汎用STM32G4で代用開発が可能です。

Cortex-M4クラスMCUは、どれも高速で大容量Flash/RAMを実装し高いポテンシャルを持っています。つまり、IoTプロトタイプ開発とその評価には、最適なデバイスです。

汎用STM32G4で代用開発済みアプリケーションをSTM32WB/STM32WLへ移植し、IoTプロトタイプ開発をスピードアップするメリットは、差分開発、つまりIoT特有機能の差分を開発ができることです。

ある程度MCU開発経験を持つ開発者が、従来MCU開発では少なかった無線通信や高度なIoTセキュリティなどのIoTアプリケーション特有の重点ポイントに注力でき、即座にIoTプロトタイプ開発（代用開発含む）とそれを評価するツールとなること、これが弊社Cortex-M4テンプレートの目標です。

評価の結果、仮にMCUやIoTセンサ、無線機能の再選択が必要となっても、開発部分の多くが次に即座に流用できるソフトウェア資産となるには、汎用STM32G4によるIoTプロトタイプ開発が有効だと思います。

具体的には、従来テンプレートとは「対象者レベルと目的を変える」ことを検討中です。

従来Cortex-M0/M0+/M3テンプレートは、対象者が初心者/中級レベル開発者で、MCU基本動作（Simpleテンプレート）とADC/LCD動作（IoT汎用Baseboardテンプレート）を提供し、基本的なMCU理解と開発が目的のテンプレート
Cortex-M4テンプレートは、対象者が中級レベル以上の開発者で、MCU基本動作などは省き、IoTプロトタイプ開発高速化が目的のテンプレート

本稿説明がすんなりとご理解頂ければ、中級レベル以上の開発者、Cortex-M4テンプレート対象者だと思います。

News

2021年1月12日、STM32CubeとMicrosoftのAzure RTOSが統合、STM32マイコン開発環境で協力というニュースが発表されました。STのCortex-M4テンプレートは、FreeRTOSとAzure RTOSの両方が必要かもしれません。

STブログに、上記の詳細情報があります。

ARM MCU変化の背景

2019年12月13日2019年12月20日 WithHappy

“昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章：Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者：大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

ハイエンドMCU動作周波数高速化、マルチコア化
RTOS普及
セキュリティ対応
RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1．ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI：Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2．RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3．セキュリティ対応

PAS：Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やＭ4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4．RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも？

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS（先進運転支援システム）が引っ張る車載MCU＋NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM：Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が（無く!?）少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。

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

2019年9月6日2019年9月13日 WithHappy

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+）トレーニング資料）

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

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

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

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割込みによりカウントダウンする処理コードが下記です。ここも、割込みを利用することでコード移植性を実現しています。

左の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章を参照ください。