IoT MCUのHappyTech

TI.comの新しい購入機能

2020年3月13日2020年4月30日 WithHappy

米）半導体大手テキサスインスツルメンツのサイト：TI.comに追加された新しい製品購入機能を紹介します。

TIは、アナログICやDSP（Digital Signal Processor）、本ブログ掲載の低電力動作Cortex-M4マイコンMSP432など多くの半導体デバイスや製品を開発・販売しています。ただ、競合他社と比べると、従来は個人調達に便利な通販のDigiKeyやMouserの取扱いTI製品品揃えが少ない傾向がありました。新しいTi.com購入機能は、これを改善できます。

TI.comの新しい購入機能

DigiKeyやMouserと同じように、TI.comで直接TI製品やデバイスを購入できます。違いは、TI製品のみを扱う点。もちろん価格は多少違いますが、品揃えは豊富です。下図のように、試作から生産に至るまで調達できます。

他社MCUベンダサイトのカートは、DigiKeyやMouserなどの外部通販へのリンクが一般的です。TIは、一律配送などのサービスも含めてTI自らが通販を行うという点が他社と異なる新しい機能です。

最大30個までという制限は設けていますが、個人購入や試作レベルの調達なら十分利用できます。通販会社にとっては脅威でしょう。TIは、手数料を通販会社に払うよりも、全製品の通販を自社で行う方法を選択したのだと思います。

MSP432デバイス品揃え豊富、低価格

本ブログ掲載の低電力動作MSP432評価ボード：MSP-EXP432P401R（ARM Cortex-M4F/48MHz、256KB/Flash、64KB/RAM、浮動小数点ユニット、DSPアクセラレーション）も、もちろんTI.comから購入できます。

さらに、評価ボードでの開発後、実機で利用するFlash/RAM容量が異なる様々なMSP432デバイスも購入できます。

評価ボード：MSP-EXP432P401Rは、CCS Cloud IDEやArduino IDEに似たEnergia IDEが使えるなど、他社MCU開発にないユニークなソフトウェア開発環境が特徴です。

CCS DesktopとCCS Cloud、Energia IDE比較（出典：TIサイト）

※Energia IDEの詳細は、関連投稿：MSP432オープンプラットフォーム開発環境を参照してください。
※CCS Cloud IDEの使い方は、関連投稿：CCS Cloud IDEを参照してください。

Energia IDEは初めてソフトウェアを開発する方に、CCS Cloud IDEはいつでも何処でも場所を選ばずにブサウザだけでソフトウェアを開発したい方に向いています。

また、パンデミック表明となったCOVID-19収束宣言がWHOからでるまでは当分の間、在宅勤務やMCU開発の自己研鑽時間、または数人でのテレワークMCU開発などの機会も増えるでしょう。これらにもCCS Cloud IDEは、活用できると思います。

評価ボードを使ったプロトタイプ開発は、最終的に実機で使うMCUデバイスの選択が的確にできます。つまり、実機でよりFlash/RAM容量が必要になるか、それともより低価格デバイスで製品や製品改良などにも十分賄えるかなど、製品実装MCUの選択が、プロトタイプ結果に基づいて具体的にできる訳です。

新しいTI.com購入機能は、MSP432デバイスの品揃えが豊富です。プロトタイプ開発の選択結果を反映した実機MCUデバイス調達が、直接Ti.comから低価格で可能です。通販DigiKeyやMouserの代替になりえます。

STM32CubeIDE更新、文字化け解決

2020年3月6日2020年7月18日 WithHappy

STマイクロエレクトロニクスの統合開発環境：STM32CubeIDEがv1.3.0に更新されました（2月28日、更新自動通知メールにて把握）。デフォルト設定のWindows版STM32CubeIDEは、エディタで追記した日本語コメントに文字化けが発生します。これは、昨年投稿したSTM32CubeIDE v1.1.0やv1.2.0と同じで、最新版でも解決されません。

そこで、対策にデフォルト設定を2か所変え、日本語文字化け解決を確認しました。また、Linux Debian版STM32CubeIDEとSW4STM32は、最新環境でもデフォルトで文字化けが無いことも確認しました。

Windows版STM32CubeIDE日本語文字化け発生箇所

2019年4月新登場STマイクロエレクトロニクス統合開発環境：STM32CubeIDE-Winの日本語コメント文字化けは、

SW4STM32プロジェクトのSTM32CubeIDEインポート後
プラグイン版STM32CubeMXでのコード再生成時

に、エディタでソースコードに追記した日本語コメントに文字化けが発生します。
※Windows版は、Windows 10 Pro 1909の話です。

STM32CubeIDE-Win v1.3.0日本語文字化け対策

数回のメジャー更新を経て登場後約1年のv1.3.0でも、この文字化けはデフォルトのままでは未解決です。そこで、ネット検索したところ、コチラの対策を得ました。

STM32CubeIDEのデフォルト設定を、2か所変更します。

フォント設定を、デフォルトConsolasからメイリオなどの日本語文字セットへ変更（ワークスペース毎）
Text file encoding設定を、デフォルトUTF-8からShift-JISへ変更（プロジェクト毎）

※1は、STM32CubeIDEのWindowタブ＞Preferenceダイアログ検索窓へ”font”入力＞Colors and Font選択>C/C++選択＞Editor選択＞C/C++ Editor Text Fontを選択し、Edit…クリックで左図表示
※2は、プロジェクト選択＞Propertiesクリックで右図表示

右図のようにプルダウンメニューにShift-JIS選択肢が無い時は、Shift-JISと直接入力し、Apply and Closeをクリックします。

1はワークスペース毎、2はプロジェクト毎に設定が必要です。

これら2か所の変更で、SW4STM32プロジェクトインポート後とSTM32CubeMXコード再生成時、どちらもエディタ追記日本語コメント文字化けは解決できました。

以上で、従来のSW4STM32から新しいSTM32CubeIDEへ、日本語コメント文字化け無しにSTM32MCU開発環境を移行できます。

STM32CubeIDE特徴

STM32CubeIDEは、コード生成ツール：STM32CubeMX、開発デバイスファームウェア（弊社ならFW_F0/F1/G0/G4）全てを1パッケージ化し、全て最新版のみを提供する特徴があります。投稿時のSTM32CubeIDE v1.3.0が下図です。

簡単に言うと、開発ソフトウェアが全てSTM32CubeIDEへプラグインされた形式です。

STM32CubeIDE起動時、またはCheck for Updatesにより、IDEを含めた各プラグイン更新を確認し、常に最新開発環境となります（悪名高いWindows Updateに似ているような…😅）。

これは、プラグイン版STM32CubeMX v5.6.0に、旧ファームウェア選択機能が無いことからも解ります。

最新ファームウェアを使うSTM32CubeMXプラグイン版（左）とファームウェア選択可能なスタンドアロン版（右）

例えば、顧客先で稼働中ソフトウェアへ変更を加えるなど旧ファームウェアのまま開発希望の場合は、スタンドアロン版STM32CubeMX v5.6.0を使えば、右図のように旧ファームウェア選択も可能です（関連投稿：v1.2.0の開発環境更新リスク、ファームウェア更新リスク回避策の章に背景説明があります）。

純正STM32Cubeツール

STM32MCUソフトウェア開発に使えるIDEは、下図中央のようにIAR：Embedded Workbench、ARM：Keil、AC6：SW4STM32、etc.などサードパーティ製も数多くあります。しかし、純正STM32CubeツールのSTM32CubeIDEが、STマイクロエレクトロニクス一押しの統合開発環境だと思います。

STM32 Software Development Tools（出典：STMサイトに加筆）

もちろん、従来からあるSW4STM32もまだ現役（Active）です。ST Communityには、今も多くのSW4STM32事例があります。

そこで、Windows版STM32CubeIDE以外の、SW4STM32とLinux Debian版STM32CubeIDEの現状を調べました。

STM32CubeIDE-DEB

64ビット版のみですが、STM32CubeIDE v1.3.0のLinux Debian版インストーラが、Windows版STM32CubeIDEと同じ純正ソフトウェア入手サイトにあります。

筆者は、DebianよりもMintが好きなので、STM32CubeIDE-DEBをLinux Mint 19.3 MATE (64-bit)へインストールし、デフォルト設定でも日本語文字化け無し、評価ボードで正常動作することを確認しました。

Mintへのインストール方法が下記です。途中で長いライセンス同意を求められます。

chmod +x st-stm32cubeide_1.3.0….sh
sudo ./st-stm32cubeide_1.3.0….sh、または、sudo bash st-stm32cubeide_1.3.0….sh
※NXP：MCUXpresso IDE v11.1.0のInstallation Guide, Appendix A – Linux Installationを参考にしました。

STM32CubeMXやデバイスファームウェアは、Windows版と同様全てプラグインです。Linux版SW4STM32既成プロジェクトが手元に無いのでインポートは試せませんが、問題無いと思います。

リリースノート：RN0114のLinux動作テスト環境にMintは有りません。自己責任でNXP：MCUXpresso IDE v11.1.0 Linux版ともども、Mint上でSTM32CubeIDE-DEBが正常動作したことをお知らせします。

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0

SW4STM32とスタンドアロン版STM32CubeMX v5.6.0で開発環境を構築する場合は、デフォルトでも日本語文字化けは発生しません。従来環境に慣れた方は、SW4STM32もそのまま使えると思います。

お知らせ：STM32FxテンプレートとSTM32G0xテンプレート改版予定

STM32CubeIDE-Win v1.3.0に加えた本稿2か所変更が、次版以降のSTM32CubeIDEにも必要かは判りません。ただ、いまさらShift-JIS設定？という気はします。WindowsでShift-JIS継続利用の弊害は、コチラの記事がよく解ります。

しかし、懸案であった日本語コメント文字化けが解決、新登場後1年経過しv1.3.0となったこのタイミングで、従来SW4STM32から新しいSTM32CubeIDEへ開発環境を乗換えるのもチャンスだと思います。SW4STM32更新頻度が減ったことや、他の純正STM32Cubeツールとの相性良さも期待できるからです。

そこで、SW4STM32で開発・販売したSTM32FxテンプレートとSTM32G0xテンプレートを、STM32CubeIDE-Winを使って再開発に着手し、新にVersion 2として販売する予定です。進行状況などは、本ブログでお知らせします。

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

2020年2月28日2020年3月6日 WithHappy

お知らせ

弊社サイト：マイコン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ソースコードにユーザが記述します。

一方、個別ハードウェア設定タイプは、UARTなどのハードウェア動作パラメタは、API生成前にGUI（Graphical User Interface）で設定し、設定後にAPIを生成します。このためユーザが、MCUソースコードの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サンプルコード(5)

2020年2月21日2020年2月28日 WithHappy

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査最終回の本稿は、タスク数=3のプロジェクト、freertos_eventとfreertos_queue、freertos_genericを説明します。

FreeRTOSサンプルコード：タスク数＝3

FreeRTOSプロジェクト：タスク数＝3
Project	Tasks	heap_	Additional FreeRTOS APIs	Additional Comments
freertos_event	3	4	xEventGroupCreate xEventGroupSetBits xEventGroupWaitBits	タスクや割込みなどのイベントをグループ化し、他タスク制御。セマフォと似ているがイベントの論理演算可能。
freertos_queue	3	4	xQueueCreate xQueueSend xQueueReceive vQueueAddToRegistry	タスク間メッセージ通信デモ。キューは、順序維持FIFO構造。
freertos_generic	3	4		キュー、ソフトウェアタイマ、セマフォの組合せデモ。 FreeRTOS.orgサンプルコードに基づき作成。

※freertos_genericのAdditional FreeRTOS APIは、これまでのサンプルAPI組合せのため追加分なし。

FreeRTOS Project：freertos_event

イベントによるタスク制御は、セマフォに似ています。複数のセマフォを１つにまとめたイベントグループを作成（xEventGroupCreate）し、このグループ化した個々のイベント間で論理演算ができることが特徴です。

xEventGroupWaitBitsの例（出典：freertos_event.c）

イベント間の論理演算ができるので、シングルイベントのセマフォよりも柔軟なタスク制御ができます。

FreeRTOS Project：freertos_queue

これまで説明してきたプロジェクトのタスク間制御には、ミューテックスやセマフォ、上記イベントなど全てビット単位のシグナルを使ってきました。最後に説明するプロジェクトfreertos_queueは、タスク間でメッセージを送受信します。

メッセージは、キュー＝有限長FIFO（First In First Out）経由で送受信されますので、メッセージの順番は維持されますが、キューが溢れないような使い方が必要です。深すぎるキューはメモリ効率が悪く、浅いキューではメッセージが溢れます。深さ見積もりなどのためにプロトタイプ開発が必要でしょう。

例えば、複数センサ出力をMCUでまとめ、定期的にクラウドへ送信するようなFreeRTOSアプリケーションソフトの素になりそうなプロジェクトです。クラウドサービスにAmazon Web Service（AWS）を使う時には、専用のネットワーク接続ライブラリもFreeRTOSで提供されますので、このアプリケーションとの親和性も良いと思います。

FreeRTOS Project：freertos_generic

MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード11個の説明の最後が、このfreertos_genericプロジェクトです。これまで説明してきた10個のサンプルコードを総合的にまとめたプロジェクトで、出典はhttp://www.freertos.org/Hardware-independent-RTOS-example.htmlです。

筆者の下手な説明よりも、実際にソースコードを見て頂くと丁寧なコメント付きです。このソースコードを読んでFreeRTOSの仕組みがすんなりと理解できれば、ベアメタルからFreeRTOSソフトウェア開発へのステップアップ初期段階は完了と言えるでしょう。つまり、10個サンプルコード習得度の自己評価に使えます。

FreeRTOSサンプルコード：タスク数＝3の調査結果

複数セマフォを1つにまとめたイベントグループタスク制御は、イベント間の論理演算が可能
キュー利用のタスク間メッセージ通信は、深さ設定にプロトタイプ開発が有効
freertos_genericは、SDK付属サンプルコード10個の習得度評価に使える
メモリ使用法は、heap_4を利用

まとめ：MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコード調査

5回に渡ってMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードをタスク数が少ない順に調査しました。基本的なFreeRTOS機能は、解説済み11個のサンプルプロジェクトでカバーされています。

各プロジェクトの追加分FreeRTOS APIのみを表で示し、しかも弊社サイトマイコンRTOS習得2017の内容は既にご存じという前提で説明したので、解りにくい部分もあったかもしれません。
要するに、ベアメタル開発にFreeRTOS APIを追加すればRTOSソフトウェア開発ができることを強調したかったからです。

FreeRTOSのマルチタスク並列動作、タスク間同期/競合回避手段、これらのFreeRTOS APIのみを理解すれば、ベアメタル開発経験がそのまま活かせます。

今回の1～5回の解説は、マイコンRTOS習得2020年版として2017年版サイトへ改版する予定です。改版後にご覧になれば解りにくさが改善されるかもしれません。

調査目的は、開発予定のベアメタルCortex-M4テンプレートへのRTOS機能応用でした。現時点で、応用内容は不明確です。しばらく時間を頂いて明確化します。

ただ、マルチタスクFreeRTOSと異なり、ベアメタルテンプレートは、全て自分の制御下タスクです。タスク間同期やメッセージ送受信も、特別な工夫なく簡単に実現できます。

FreeRTOS利用MCUのAWS接続（出典：Amazon FreeRTOSの開始方法に加筆）

上図のように、AWSへの接続やIoTセキュリティ機能追加など今後必須になるIoT MCUの機能実装は、専用ライブラリベース、特にFreeRTOSライブラリで提供される可能性が高いと予想できます。

これらライブラリは、ベアメタル開発でも利用可能ですが、FreeRTOSソフトウェアの方が親和性も高く開発が容易なことも事実です。

しかも、これら専用ライブラリで実行される処理内容は、本来我々開発者が変更を加えるべきでない定型処理です（もちろんプロパティなどのパラメタは、開発者依存です）。

いずれにしても、MCUXpresso54114を使ったFreeRTOSソフトウェア開発環境と基本機能は習得できたので、ベアメタルCortex-M4テンプレート開発へ活かしていきます。

FreeRTOSサンプルコード(4)

2020年2月14日2020年2月21日 WithHappy

タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの後半2プロジェクト、MutexとSemaphoreを説明します（前半は、前稿参照）。

FreeRTOSサンプルコード：タスク数＝2

FreeRTOSプロジェクト：タスク数＝2（後半）
Project	Tasks	heap_	Additional FreeRTOS APIs	Additional Comments
freertos_mutex	2	4	xSemaphoreCreateMutex xSemaphoreGive	並列動作の共有リソース同期/競合制御。taskYIELDは要注意！ Mutexのセマフォ作成は、　　 xSemaphoreCreateMutex。 Semaphoreのセマフォ作成は、xSemaphoreCreateBinary。
freertos_sem	1+3	4	xSemaphoreGive

※Freertos_semはタスク数4個。実質はproducer_taskとconsumer_taskの2個。

FreeRTOS Project：freertos_mutex

RTOSソフトウェアのメリットは、複数タスクが「完全に並列動作」することです。ただし、副作用として、共有リソースのアクセス競合が生じます。サンプルコードの場合はIDE Console出力で、その他にUARTやIOポートなど多くの共有リソースがMCUにはあります。

この共有リソースへのセクセス競合を防ぐ手段がミューテックスです。共有リソース使用前に他タスクの使用/未使用を検出し、未使用時のみ利用、利用後は、使用権を戻す操作（xSemaphoreGive）をします。

仮にミューテックス機能が無ければ、英字と数字が混ざった出力になり、使い物になりません。
並列動作のRTOSに、Mutexは必須機能です。

注意点は、Consoleへ部分出力後のtaskYIELDです。

F3クリックで調べましたがtaskYIELDの理由は、筆者には不明です。だだし、コメントを読むとFreeRTOSインプリメント依存部分なので、そのまま弄らない方が良さそうです。共有リソース利用中には、taskYIELDが必要と覚えておけば（とりあえず）良いとします。
※本調査の目的は、ベアメタルCortex-M4テンプレート開発へのRTOS機能応用であって、FreeRTOS自身ではないので、この程度で留めていきます👍。

共有リソース使用検出APIは、xSemaphoreTakeです。前稿freertos_ticklessプロジェクトの割込みISRと処理タスク同期に用いたAPIと同一です。差分は、セマフォ自体の作り方が異なります。ミューテックスの場合は、xSemaphoreCreateMutex、セマフォの場合は、xSemaphoreCreateBinaryです。

違いは、初期値です。ミューテックスは、初期値が使用可能（pdTRUE）になりますが、セマフォは、初期値が使用不可です。どちらも、並列動作タスク間の同期/競合制御として、同じAPI：xSemaphoreTakeを使っているということです。

FreeRTOS Project：freertos_sem

前稿freertos_ticklessで示したISRと処理タスクのセマフォ同期とは別の使用例が、freertos_ semプロジェクトです。同期というより、むしろ排他制御にセマフォを使った例です。

このプロジェクトは、これまでのサンプルコードで最も多い４タスク：1（producer_task）+3（consumer_task）を生成し、2個のセマフォ（xSemaphore_producerとxSemaphore_consumer）を使い、1個のアイテムを4タスク間で利用する例です（Doc>freertos_sem_example.txtによるとランデブーモデル同期と言うようです）。

1個の（共有）アイテムは、元々produser_taskが持っており、cunsumer_taskへその使用権を与えます（L119:xSemaphoreGive→xSemaphore_consumer）。

並列動作中の3個cumsumer_taskのどれかがこの使用権を取得します（L143:xSemaphoreTaka←xSemaphore_consumer）。使用後は、produser_taskへ使用権を返却します（L141:xSemaphoreGige→xSemaphore_producer）。

produser_taskは、cunsumer_taskの使用権返却を待っており（L121: xSemaphoreTaka←xSemaphore_producer）、返却後、再び最初に戻ってcunsumer_taskへ使用権を与えます。

cunsumer専用セマフォがxSemaphore_consumer、producer専用セマフォがxSemaphore_producerで、それぞれを図示したようにやり取りしながら4タスクが動作します。

ベアメタル風に、ランデブーモデル同期：synchronized in bilateral rendezvous modelを解説すると上記のようになります。

ソースコード上では、どのcumsumer_taskが共有アイテムを獲得するかは不明ですが、評価ボード実行結果は、常にConsumer 0→1→2→0･･･の順番でした。3個のcumsumer_taskプライオリティが同一の時は、生成順に1個のアイテム共有ができるようです。

FreeRTOSサンプルコード：タスク数＝2（後半）の調査結果

FreeRTOSタスク並列動作副作用の共有リソースアクセス競合回避手段に、ミューテックスがある
MCUXpresso54114 のFreeRTOS共有リソース利用途中には、taskYIELDが必要
初期値（pdTRUE）の有無が、ミューテックス作成とセマフォ作成で異なる
バイナリセマフォの排他制御利用例に、ランデブーモデル同期がある
メモリ使用法は、heap_4を利用

FreeRTOSデバイス依存開発ノウハウ

筆者のOS：Operating System利用アプリケーションソフト開発経験は、Windows PCのみです。Windows OSは、リアルタイム性はありません。そのおかげで、PCアプリケーションソフト開発時に、他タスクへの影響、プライオリティなどは考慮せずに比較的簡単に開発ができました。

ミューテックスやセマフォを利用した覚えもありません。もちろんファイルなどの共有リソースには、それなりのアクセス手順があり、それに従って開発すれば特に問題はありません。

一方MCUでOS利用の場合は、リアルタイム性は無視できません。限られたMCU能力を上手く利用するためのデバイス依存開発ノウハウが、メモリ使用法：heap_4やtaskYIELDだと思います。

これらノウハウは、ソースコード上では解りにくい代物です。また、文章記述できる量も限られます。

これには、評価ボード上でソースコードのパラメタを変えた時の挙動変化を開発者自身がつかんで習得する方法が効率的です。LPCXpresso54114（Cortex-M4/M0+ 100MHz、256KB Flash、192KB RAM）評価ボードは、入手性もよく低価格（約3400円）です。無償LPCXpresso IDEとともにご利用いただければ、本稿やFreeRTOSがより解り易くなります。

PS：FreeRTOSの最新版V10.3.0が2020年2月7日に公開されました。詳細は、リリースノートをご覧ください。

FreeRTOSサンプルコード(3)

2020年2月7日2020年2月14日 WithHappy

タスク数=1の前稿FreeRTOSサンプルコード(2)に続き、本稿は、タスク数=2のMCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードの前半3プロジェクトを説明します。

FreeRTOSサンプルコード：タスク数＝2

FreeRTOSプロジェクト：タスク数＝2（前半）
Project	Tasks	heap_	Additional FreeRTOS APIs	Additional Comments
freertos_tickless	2	4	vTaskDelay xTaskGetTickCount xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	FreeRTOS低電力動作とSW_taskの2タスク並列動作説明。 Tickless_taskは、vTaskDelay、前稿hello_taskは、vTaskSuspend。 SW_taskは、Tickless_taskに何ら影響を与えない。
freertos_i2c	2	4	xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	master_taskとslave_taskの2タスク構成。正常動作結果は、Console窓出力。DoC>readme.txtでも結果が判る。
freertos_spi	2	4	xSemaphoreCreateBinary xSemaphoreGiveFromISR xSemaphoreTake	同上

タスク数=2のサンプルコードは、上記以外にもFreeRTOS特徴のミューテックスとセマフォ利用例がありますが、これらは次回説明します。

FreeRTOS Project：freertos_ tickles

前稿説明のhello_taskは、Console窓に文字を１回出力し、「待ち状態」になりました。
hello_task とよく似たTickless_taskは、文字の代わりにxTaskGetTickCountで得た数字を１回出力し、vTaskDelayで5秒間の「停止状態（＝低電力動作：Sleep）」になります。

低電力動作からの復帰Eventで、Tickless_taskは停止状態から実行可能状態へ移行し、スケジューラによって再実行されます。停止時間5秒間のtick回数がConsole窓に出力されます。
※FreeRTOSタスクの状態遷移図は、マイコンRTOS習得2017の第２部を参照。

このプロジェクトは、Tickless_task が、SW_task動作に全く影響を受けないFreeRTOSの特徴を説明しています。

つまり、Tickless_taskと、SW_taskは、それぞれ別々にあたかも自分のタスクがMCUを占有するように記述されており、かつその通り並列動作します。これがFreeRTOS利用ソフトウェア開発の最大メリットです。タスク開発は、ベアメタルソフトウェア開発に比べ簡単に、かつ流用性も大きくなるでしょう。

※SW3プッシュは、ソフトウェア、ハードウェアで何もチャタリッグ防止策をしていない処理の検証にも使えます。試しにSW3を長く押してチャタリッグが発生することを確かめてください。チャタリッグ防止策の必要性が解ります。

FreeRTOS Project：freertos_ i2cとfreertos_ spi

freertos_ i2cとfreertos_spiプロジェクトは、どちらもMCU内蔵I2C、またはSPIを使った外部デバイスとの通信サンプルコードです。どちらもmaster_taskとslave_taskの2タスクから構成されています。

main.cでslave_taskのみをタスク登録し、slave_task内でmaster_taskを登録しています。このように、FreeRTOSスケジューラ起動後でも、任意の場所で新たなタスク登録が可能です。

動作は、最初master_taskでデータ送信し、それをslave_taskで受信、次にslave_taskがデータ送信し、それをmaster_taskで受信し、両タスクとも正常終了します。

この動作シナリオは、slave_taskに記述されており、master_taskのデータ送信開始は、slave_taskのmaster_task登録の結果、並列実行されます。slave_taskのデータ受信と送信完了は、i2c_slave_callbackからのセマフォを使って判断しています。

評価ボード実装Arduinoコネクタ上の配線で、送受信データをループバック接続しますので、評価ボード1台のみで両タクス動作結果が、IDEのConsole窓に出力されます。

MCUXpresso54114評価ボードをお持ちでない方は、両プロジェクトのDoc>readme.txtのRunning the demoにConsole窓出力と同じ結果があるので解ります。

I2C/SPI通信対象のデバイスは、従来からの外付けEEPROMに加え、最近ではIoTセキュティデバイスなどがあります。

IoTセキュティデバイスは例えば、NXPのEdgeLookやMicrochipのCryptoAuthenticationファミリなどがあり、IoT MCUのクラウド接続には、これらデバイス利用が必須になりそうです。

I2C通信のIoTセキュリティデバイス接続例（出典：NXP SE050データシート）

FreeRTOSサンプルコード：タスク数＝2（前半）の調査結果

FreeRTOS低電力動作（Sleep）は、vTaskDelay（msec）で低電力動作開始と復帰
タスク数が2と少ないので、タスク並列動作が解り易く、プライオリティ設定とその意味も理解容易
I2C/SPI割込みISRとのタスク同期に、バイナリセマフォ利用
割込みcallback関数でセマフォをgive → 割込み処理タスクでセマフォをtake → セマフォ消滅
IoT MCUは、セキュティデバイスとのI2C接続可能性大
メモリ使用法は、heap_4を利用

セマフォ（Semaphore）同期は、マイコンRTOS習得2017の第3部：Semaphoreによるタスク同期の章に、図入り解説していますのでご参照ください。

FreeRTOSサンプルソースコードは、MCUXpresso IDEのみでも御覧頂けます。是非、PCへインストールし本稿をご参照ください。

Office 2010とLibreOffice運用案

2020年2月3日2021年2月8日 WithHappy

1月29日、LibreOffice Fresh（最新版）が6.4.0へ更新されました。Still（安定版）は、6.3.4です。

LibreOffice版数（2020年2月3日現在）
パッケージ	想定ユーザ	2020/1/31版数
Fresh（最新版）	技術マニア、新しいもの好き、パワーユーザ向け	6.4.0
Still（安定版）	ビジネス組織、法人企業、慎重なユーザ向け	6.3.4

Fresh（1か月毎更新）は、新しい6.4系へ、Still（3か月毎更新）は、6.3系のバグ取りがすすんでいます。QRコード生成などFresh 6.4の主な追加機能は、コチラの記事が参考になります。

10月13日、Office 2010全サポート終了

2020年10月13日全てのサポートが終了するOffice 2010の代替アプリケーション候補として、LibreOffice 6.4を試用中です。何回かLibreOffice設定や新規文書作成について、無料Writer/Drawテンプレート配布を含む投稿を行ってきました（関連投稿は、カテゴリ：LibreOfficeを選択してください）。

新規Writer/Draw文書作成に関しては、慣れの問題は除いてLibreOfficeを、Office Word/Visio代替として利用することに問題はありません。機能差はありますが、同等の文書が作成可能です。

残る問題は、LibreOfficeがOffice 100％互換アプリではないことです。

もちろん、新旧Office文書をLibreOfficeで読込み/書込みはできます。但し、100%互換ではないので、場合によっては文字や図形の「レイアウト崩れ」が発生します。フォントの違いに起因しているようですが、それ以外にも色々な要因がありそうです。

これは、同じMicrosoftのOfficeアプリケーション、例えばWord 2003と2010でも100%互換は不可能でレイアウト崩れが生じますので、やむを得ないと思います。

そこで本稿は、これらの状況を踏まえたうえで、Office 2010サポート終了後のOffice 2010とLibreOffice運用に関しての私案を示します。

Office 2010とLibreOffice併用私案

新規文書作成は、全てLibreOffice。Office 2010での新規文書作成は、停止。
Office 2010サポート終了後も、PCからOffice 2010のアンインストールはせずLibreOfficeと併用。
既存Office 2010文書は、Office 2010で閲覧。
既存Office文書の改版時は、Officeの内容を新規LibreOfficeへコピー＆ペーストし新規作成。
文書配布は、PDF化。

私案説明

アプリケーションが異なれば、レイアウト崩れの発生は当然だと諦めます。Office 2016/2019/365でも2010の100%下位互換性は困難で、Office 2010文書レイアウト崩れが発生します。

10月13日以降もPCからOffice 2010をアンインストールしないのは、PC内に「既に存在するOffice文書閲覧」のためのみです。PC外部から「入手したOffice文書は、LibreOfficeで閲覧」し、必要ならLibreOffice形式で保存します。この2つの方法で、更新されないサポート終了後のOffice 2010セキュリティ対策をします。

既存Office文書は、Office 2010での閲覧なのでレイアウト崩れはありません。この文書を改版する時は、LibreOfficeへ内容をコピー＆ペーストし、崩れ無しのオリジナルOffice 2010レイアウトを参照しながら、新たにLibreOffice文書を作成します。

ポイントは、「新なOffice 2010文書作成をしない」ことです。

サポート終了後は、Office 2010セキュリティ対策の更新がないので、10月13日以降の将来、Office 2010に発見される可能性があるセキュリティホールに対しては、新規文書作成をしないことで対処します。もちろん、マクロなどは動作させません。
※Office Viewerという手段もありより安全ですが、2010そのものの方が好みです。

Office 2010をアンインストールし、有料Office 2016/2019/365へ更新しても、私案と「Office 2010の将来セキュリティ」に関する万全さは大差なしと思います。また、Office 2016/2019/365でも、頻度は減るでしょうがレイアウト崩れが発生することを考慮すると、無料LibreOfficeの新旧Office文書読込みとOffice形式での書込み能力は、高く評価できます。

私案では、「追加コストなし」で、既存Office 2010文書閲覧、可能な限りのセキュリティ対策、新規LibreOfficeによるPC文書作成を行います。文書の外部配布は、全てPDF化で対処します。

まとめ

Office 2010サポート終了に伴い、代替アプリケーションとしてクロスプラットフォームでオープンソースのLibreOfficeを昨年の8月から約半年間試用してきました。

その結果、LibreOffice文書の標準保存ファイル形式は、オープンドキュメント形式（ODF）で、国際標準規格であること、また、LibreOfficeで、Office 2010と同等の文書作成が可能であることが判りました。

そこで、今後の文書作成は全てLibreOfficeを使い、Office文書の読込みと書込みができるLibreOffice能力を活かし、Office 2010サポート終了後のOffice 2010とLibreOffice併用私案を示しました。使用頻度の低いバックアップPCなどの文書作成環境としては、効果的だと思います。

この私案は、今後発見される可能性があるOffice 2010セキュリティホールに対して脆弱性があるので、試す方は自己責任で使ってください。また、私案に問題などがございましたらメールでお知らせください😌。

中国製STM32互換MCU

2020年1月31日2020年2月3日 WithHappy

1月28日、EE Times Japanに“互換チップが次々と生まれる中国、半導体業界の新たな潮流”という記事が掲載されました。スイス・ジュネーヴ本社のSTマイクロエレクトロニクス（以下STM）のSTM32互換MCUが、中国で製造プロセス縮小、ローコスト化し販売中だそうです。

STM32F030、STM32F103互換MCU

記事記載の互換デバイスは、STM32F030（Cortex-M0、64KB Flash、8KB RAM）と、STM32F103（Cortex-M3、７2MHz、128KB Flash、20KB RAM）の2種。どちらもSTM純正180nmプロセス製造MCUを、130nmプロセスで製造しており、ローコスト化、低電力化、動作周波数アップが狙いです。

さらに、ARM Cortex-Mコア部分のみをオープン仕様RISC-Vコアへ変えた、STM32互換RISC-V MCUもあるそうです（記事、図４参照）。

記事筆者の清水氏（テカナリエ）は、これら中国製互換デバイスを否定するのが目的ではなく、現状の事実、互換製造ができる高い技術力、STM32MCUが汎用MCUデファクトスタンダードであること、中国半導体業界のこの方向性が、ますます加速する可能性があると報告しています。

日本が見習うべきもの

RISC-Vはオープン仕様ですが、Cortex互換MCU販売には、ARMライセンスフィーなど気になる事柄もあります。但し、本ブログ筆者も清水氏と同じく、その背景にある技術力、ビジネスセンスについて見習うべきものが多いと思います。

STM互換MCUは、純正品よりも安く、しかも高性能です。開発環境や評価ボード、開発ソフトウェアはそのまま互換MCUでも動作します。欧州ベンダのSTM互換MCU開発・販売は、米国ベンダ互換よりもハードルが低いでしょう。世界情勢なども反映された成功事例だと思います。

例え安く高性能な部品（BOM：Bill Of Matrix）が提供されても、それを使って開発できる技術者がいなければ製品化はできません。技術者スキルが最も伸びるのは、開発中です。中国技術者は、高性能製品を低価格で、次々と提供できている事実があります。

もちろん失敗事例もたくさんあるハズです。しかし、技術者にとっては、成功失敗を問わずどんな事例でも開発経験はスキルに直結します。

一方、日本の環境は、時短や効率化など見た目の生産性や成功例のみに注目しがちです。ただ、技術者スキルは世界レベルで評価されるので、このままの環境では、先々の日本開発案件は無くなるのではと危惧しています。

例えば自動車は、日本メーカを選択する人はいても、それが日本開発かは問題にしません。むしろ世界各地で開発されています。
※日産の先進自動運転技術（ADAS）は、米国女性技術者が中心で開発されたと、何かで読んだ記憶があります。

5G、6G世代のネット高速化、自動翻訳やAIなどの環境変化で、日本開発に拘るユーザは、減少の一途となるでしょう。

日本技術者は、次世代の自分自身のため、世界で通用するスキルを身に付ける必要があります。

弊社STM32F0/F1に使えるSTM32FxテンプレートやSTM32G0xテンプレート、その他ベンダのMCUテンプレートは、初心者～中級レベルソフトウェア技術者向きです。初級～中級技術を効率的に習得し、さらに高度なスキル獲得に少しでもお役立てれば幸いです。と、最後は自社広告になってしまいました😌。

FreeRTOSサンプルコード(2)

2020年1月31日2020年2月1日 WithHappy

FreeRTOSデバッグは、ベアメタルソフトウェアデバッグと異なる準備が必要です。

幸いなことに、前稿で示したMCUXpresso54114評価ボードとSDK付属FreeRTOSサンプルコードを使ってMCUXpresso IDEでFreeRTOSデバッグを行う場合は、この準備がサンプルコードやIDEデバッガに予め設定済みです。何もせずに直にデバッグができます。

FreeRTOSデバッグ準備

但し、LPCOpenライブラリFreeRTOSサンプルコードを利用する場合や、FreeRTOSソフトウェアを自作する場合には、この事前準備を知らないとFreeRTOSデバッグができません。
※LPCOpenライブラリと下記MCUXpresso IDE FreeRTOS Debug Guideも前稿参照。

MCUXpresso IDE FreeRTOS Debug Guideの2章に、準備理由や追加設定個所が詳細に記載されています。

デバッグリンクサーバー（CMSIS-DAP）のAll-Stopモードへ切り替え　※デフォルトはNon-Stopモード
FreeRTOSカーネルソースコード修正　※SDK付属サンプルコードは修正済み
メモリ使用法の設定

上2つは、IDEでFreeRTOS本体動作確認のための設定、メモリ設定は、限られたMCUメモリの活用方法でheap_1～5まで5種類あります。

これらは、ベアメタル開発とは異なるFreeRTOS利用オーバーヘッドで、メモリ使用法は、動作するMCU毎に異なりノウハウが必要になると思います。MCUXpresso54114評価ボードSDK付属FreeRTOSサンプルコードのメモリ使用法は、調査します。

FreeRTOSサンプルコード：タスク数＝1

MCUXpresso54114 SDK v2.7.0の11個あるFreeRTOSサンプルコードを、タスク数で並び換えたのが下表です。本稿は、タスク数＝1のFreeRTOSプロジェクトを調査します。

FreeRTOSソフトウェア開発は、タスク数が少ない方が理解し易くタスクプライオリティ設定も不要です。この中では、freertos_swtimerが一番簡単、下方につれて複雑なプロジェクトになります。

FreeRTOSプロジェクト：タスク数＝1
Project	Tasks	heap_	Additional FreeRTOS APIs (Bold)	Additional Comments
freertos_swtimer	1	4	xTaskCreate vTaskStartScheduler xTimerStart	IDE Console出力ユーザ作成Software Timerデモ
freertos_hello	1	4	xTaskCreate vTaskStartScheduler vTaskSuspend	IDE Console出力
freertos_usart	1	4	xTaskCreate vTaskStartScheduler vTaskSuspend	Usart 115200bps 8-Non-1送受信 4B受信後エコーバック

※heap_4：断片化を避けるため、隣接する空きブロックを結合。絶対アドレス配置オプション含む。
※FreeRTOS API接頭語x/v：API戻り値型を示し「v」がvoidを、「x」が結果コードまたはハンドルを返す。

サンプルコード利用FreeRTOS APIと、Doc>readme.txtのProject説明へ付け加える内容をAdditional Commentsに記載しました。太字以外のFreeRTOS APIは、マイコンRTOS習得2017で説明済みのため、本稿では省略します。

xTimerStartは、ユーザ作成ソフトウェアタイマの動作開始FreeRTOS APIです。

IDE Consoleは、ソースコード内へマクロ：PRINTFを挿入すると、IDE下段Console窓へ数値や文字列などの入出力が簡単にできる機能です。

FreeRTOS Project：main()

ベアメタルmain()と同様、初期設定＋無限ループの構造です。
差分は、タスク登録とスケジューラー起動から成るFreeRTOS初期設定が、評価ボード初期設定後に加わることです。

FreeRTOS Project：freertos_swtimer

ユーザ作成の1秒ソフトウェアタイマ割込み（SwTimerCallback）を使って、Console窓にTick文字を出力します。タスク登録直後、xTimerStartでユーザタイマをスタートしています。

例えば、ユーザ入力待ちの開始時にxTimerStartし、ユーザ反応が何もない時のタイムアップ処理などに使うと便利です。

FreeRTOS Project：freertos_hello

タイトル出力など1回限りのConsole窓出力に便利です。hello_taskは、出力後、vTaskSuspendで待ち状態になります。タスク正常終了後は、vTaskSuspend処理が一般的なようです。

FreeRTOS Project：freertos_usart

UART0の115200bps 8-Non-1を使ったVirtual COMポート送受信タスクです。受信リングバッファ利用で4B受信後に受信文字をエコーバックします。4Bまとめてのエコーバックは、1B毎よりも効率的です。

例えば、処理途中で割込みなどの他処理が入っても、受信リングバッファ利用で取りこぼしデータがなく、かつ、RTOSが処理中断/再開を行うので、このような記述がFreeRTOSマルチタスク動作に好都合かもしれません。
ベアメタル開発にはないRTOSソフトウェア開発ノウハウの可能性があります。

※筆者自身RTOSは初心者です。本調査結果は、FreeRTOS APIレファレンス等も参照して記述しておりますが、多分に上記のような推測の域があることはご容赦ください。

FreeRTOSサンプルコード：タスク数＝1の調査結果

FreeRTOS初期設定（タスク登録とスケジューラー起動）が、評価ボード初期設定後に追加
PRINTFを活用したFreeRTOSタスク単体デバッグの手本
タスク正常終了後は、vTaskSuspend処理
UART0利用VCOM送受信タスク（uart_task）は、移植性が高く、流用・応用が容易
メモリ使用法は、heap_4を利用

ここで示したFreeRTOSサンプルコードは、MCUXpresso54114評価ボードがあると動作確認が可能ですが、無くてもMCUXpresso IDEをPCへインストールすれば、どなたでもコストがかからず参照頂けます（インストール方法は、関連投稿：NXPマイコン開発環境更新を参照）。

普段NXPマイコンをお使いでない方も、MCUXpresso IDEをインストールしFreeRTOSサンプルコードをご覧ください。不要になった後は、IDEアンインストールも簡単です。

以降のFreeRTOSサンプルコード関連投稿は、お手元に上記開発環境があるものとして説明いたしますので、よろしくお願いいたします。

FreeRTOSサンプルコード(1)

2020年1月24日2020年1月31日 WithHappy

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

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

Task List：タスク毎のプライオリティ、スタック使用量、動作時間表示
Queue List：アクティブキュー、セマフォ、ミューテックス利用時のリソース表示
Timer List：RTOSタイマー表示
Heap Usage：ヒープ使用量、メモリブロック割当て表示

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

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

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