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 RTOS対策

2021年6月11日2021年12月12日 WithHappy

IoT MCUクラウド市場は、AWSとMicrosoft Azureがリードしており世界収益の半分以上を占めるという記事に掲載されたのが下図です（EE Times 2021年6月7日、横軸：市場シェア、縦軸：年平均成長率）。Microsoftは徐々にAmazonに迫っており、市場シェア差は、過去1年で2ポイント縮まったそうです。

多様化MCU RTOS

AWSへの接続にはAmazon FreeRTOS、Microsoft AzureにはAzure RTOSを用います。IoTクラウド接続ウェビナーでは、どのMCUベンダでも先行しているAmazon FreeRTOSを使った接続例が主流です。しかし、最近は、Azure RTOS利用の接続資料やウェビナーも見られます。AWSとMicrosoft Azureの差が縮まりつつある証左でしょう。

また、第3勢力として急成長中のGoogleクラウド接続にはARM mbed OSが使われます。IoT MCUに実装するRTOSは多様化してきました。

IoT MCU RTOSとPCブラウザ

この状況は、PCブラウザが現状、複数共存しているのに似ています。

機能的には同じブラウザですが、表示/印刷/広告などの使い勝手が少しずつ異なるため、必要に応じて複数ブラウザを使い分ける方も多いでしょう。記憶容量の大きいPCでは、ブラウザ併用・共存も簡単です。

しかし、限られた容量しか持たないMCUの場合は、複数RTOSの中からMCU搭載RTOSは1つに絞られると思います。

例えば、AmazonやMicrosoft、Google各社の強み（販売/文書/広告）や特徴を活かし、IoT機器制御サービスやAI活用サービスなど魅力的クラウドサービスを各社各様で提供し、その価格、顧客との結びつきの強さなどがサービス選択の決め手となるでしょう。

いずれにせよ顧客が、利用するクラウドサービスを決め、その接続手段として各社RTOS接続ライブラリの使用、加えてRTOS環境での上層MCUソフトウェア開発を行うことになります。

問題は、RTOS環境のMCUソフトウェア開発手法がベアメタルと異なること、各社RTOS仕様が少しずつ異なることです。

多様化RTOS対策

仮に、Cortex-M4/M0+ディアルコアMCUで、クラウド通信処理全てを、Cortex-M0+コア側のRTOSライブラリで行い、通信とアプリケーションが完全分離された構成であれば、問題は解決します。接続サービス毎にRTOS通信ライブラリを変えさえすれば、対応できるからです。

BluetoothやThreadなど複数無線通信規格から1つを選んで処理するなど、この構成に近いベアメタルソフトウェア対応のMCUが既にあります。

しかし、主流ウェビナーで用いられる高性能Cortex-M4シングルコアを使って、クラウド通信とアプリケーションの両方を処理する場合には、接続先のクラウドに応じて「FreeRTOS/Azure RTOS/Mbed OSなど様々なRTOS環境の上層アプリケーション開発」になります。

RTOSの目的は、MCUハードウェア隠蔽と開発ソフトウェア流用性向上なのに、複数RTOS存在で開発アプリケーションが異なるとは、皮肉な結果です。

最初の図は、IoT MCU開発者が、今後急増するクラウド接続IoT MCU開発に、これら複数RTOSを効率的に習得し、かつ、顧客が選ぶ1個のRTOSアプリケーションを早期に開発できるスキルを獲得しなければならない現状や将来を示しているとも言えます。

こういう状況での常套手段は、共通部分と個別部分の分離、共通部分からの段階的習得です。

どのRTOSでもSemaphoreやQueueは、ほぼ共通の基本機能です。先ずは、この2機能をしっかり把握し、より高度なミューテックスやイベントグループなどRTOS毎に特徴があり機能も異なる対象へ発展するのが効率的でしょう。

※RTOSは、複数タスク（AzureはThread）を、優先順位に応じてリアルタイムに実行/待機/状態保存復帰の切替えを行います。タスク間同期手段がSemaphore、データ送受手段がQueueで、この2つはどのRTOSでも共通の基本機能です。

まとめ

IoT MCUクラウド市場シェアから、クラウド接続IoT MCU RTOSもPCブラウザ同様、様々な仕様併存の可能性があります。

顧客が選ぶRTOSに柔軟対応し、そのRTOS上層の様々なRTOSアプリケーションを早期開発するには、先ず、各RTOS共通機能のSemaphoreとQueueを把握し、より高度でRTOS毎に異なる個別機能へ発展する習得アプローチが効率的です。

6Eリリース予定の弊社FreeRTOSアプリケーションテンプレート（税込2000円）は、主流のAmazon FreeRTOSを用い、NXP）LPCXpresso54114（Cortex-M4/150MHz、Flash/256KB、RAM/192KB）にて動作確認済みです。

添付するRTOSプロジェクトは、各RTOS共通機能SemaphoreとQueueを利用しており、上記習得アプローチを満たすツールとして、また、全ての物をつなげる主役IoT MCU RTOS基礎固めに最適です。

FreeRTOSユーザタスクの作り方

2021年5月28日2021年12月12日 WithHappy

ベアメタルサンプルソフトを活用したFreeRTOSユーザタスクの作り方を示します。先に結論を言うと、ベアメタルサンプルソフト無限ループ内に、RTOS待ち処理を挿入するだけでFreeRTOSタスク開発ができます。

RTOS環境のユーザタスク開発

IoT MCUをAWSやAzureなどのクラウドへ接続する時には、FreeRTOSやAzure RTOSなどのRTOSが必須です。クラウド接続用のRTOSタスク集が入ったライブラリを利用するからです。もちろん、このライブラリ内のタスク開発は必要ありません。

問題は、このIoT MCU RTOS環境で、ユーザタスクをどのように開発するかです。

RTOSの目的は、タスク独立性とリアルタイムなタスク並列多重、MCUハードウェア隠蔽です。ベアメタル開発経験者にとっては、ソフトウェア動作環境が著しく異なることが解ります。

RTOS開発障壁を下げるアプローチ

そこで、ベアメタル開発経験者は、先ずこのRTOS環境の理解に努めます。

セマフォやミューテックス、QueueなどRTOS特有の手段を理解します。弊社も各種FreeRTOS機能を説明しましたし、ウェビナー等でも同様です。但し、このアプローチAは、「RTOSの手段」理解が最初に来ますので、障壁が高いと感じる方も多いでしょう。筆者はそうでした。

そこで、お勧めするのは、RTOS手段をざっと読んだら、今度は逆に「RTOSの目的」からRTOS環境で、複数ユーザタスクを並列多重するアプローチBです。

複数ユーザタクスを、どうすればRTOSへ組込むかを検討するこの逆アプローチBは、Aよりもベアメタル開発経験者向きで、しかもRTOS手段は後回しですので障壁が低く感じられます。

ベアメタル処理のFreeRTOSタスク化と並列多重

2個のベアメタル処理をタスク化し、RTOSで並列多重処理する例で考えます。

・処理#1：緑LEDを、1秒毎にトグル点灯
・処理#2：赤LEDを、SW押下げでトグル点灯

ベアメタル開発経験者なら、どちらの処理も簡単に開発できます。処理概要は、最初図1の左側になります。

違いは判断内容で、処理#1が1秒経過、処理#2がSW割込みです。もちろん、両処理を並列に多重するのは、ベアメタル開発では工夫が必要です。処理#1と#2は、別々のプロジェクト、例えば2個のサンプルプロジェクトとして提供されるのが一般的です。

両処理をタスク化して組込むRTOSには、LPCXpresso54114のSDK付属generic_freertosプロジェクトを用います。“generic”が示すように、ハードウェアに依存しない汎用的なFreeRTOSプロジェクトです（generic_freertosの詳細は、コチラの関連投稿を参照してください）。

RTOSへ組込んだ時のタスク処理概要が、図1の右側です。ベアメタルとの違いは、タスク#1は、遅延処理vTaskDelayを無限ループに加えること、タスク#2は、割込みISRからの同期セマフォ受信を無限ループに加えることだけです。

両処理へ追加したのは、どちらも「RTOS処理待ち」です。この処理待ちを、RTOSが解除/待ちに切替えることで、複数タスクが並列に動作します。

RTOSは、複数タスクを処理待ち状態にし、処理待ちタスクの中から優先順位に応じて1個のタスクを実行状態に割当てます。RTOS（Kernel）自身が、順位判断や実行タスクの切替え、タスク実行状態の保存/リカバリのためスタックプッシュ/ポップ処理を行い、それらの処理間隔がTICK_RATEです。

リアルタイムでタスクを切替えるには、高速なKernel動作（AWSによると25MHz以上）と短期間のTICK_RATE（通常1ms）が必要で、タスク数に応じてスタック使用量（AWS RAM 64KB以上）は急増します。
※数値で示したAWS FreeRTOS必須条件の詳細は、コチラのハードウェア最小仕様要件を参照してください。

要するに、RTOSへユーザタスクを追加するには、ベアメタルでユーザ処理を開発し、その無限ループ内にRTOS処理待ちを加えさえすれば、RTOSユーザタスクになります。

ベアメタル開発経験者がデバッグし慣れた処理がそのままRTOSユーザタスク開発にも使え、RTOS処理待ちは、generic_freertosに実装済みのセマフォとQueueのRTOS手段だけでも、リアルタイムタスク並列多重のRTOSアプリケーション開発ができます。

まとめ

本稿は、IoT MCU RTOS環境でユーザタスクを開発し、FreeRTOSへ実装する方法として、ユーザ処理をベアメタルで開発し、無限ループ内へRTOS処理待ちを加えタスク化する方法を説明しました。

RTOS処理待ちは、セマフォとQueueのRTOS手段を理解していれば、プロトタイプ段階のFreeRTOSアプリケーションとしては十分です。ユーザ処理を自主開発する代わりに、ベンダ提供のベアメタルサンプルソフトを活用すれば、豊富なサンプル処理のFreeRTOSタスク化も簡単です。

タスク化処理を組込むRTOSには、NXP）LPCXpresso54114 SDK付属のgeneric_freertosプロジェクトを使います。このプロジェクトは、ハードウェア非依存の汎用FreeRTOSプロジェクトで、セマフォとQueueを実装済みです。そこで、これら2つのRTOS手段を手始めに理解すれば、RTOS開発障壁も低くなります。

あとがき

本稿で示したユーザタスク追加方法により開発したNXP)LPCXpresso54114（Cortex-M4/150MHz、Flash/256KB、RAM/192KB）で動作確認済みのFreeRTOSアプリケーションテンプレートは、6Eにリリース予定です（ADC入力とLCD出力、VCOM入出力処理も追加済み）。

このテンプレートには、FreeRTOSプロジェクトに加え、同じアプリケーション動作のベアメタルプロジェクトも添付します。ベアメタル処理に処理多重の工夫を加えた弊社Cortex-M0+/M3コア向けBaseboardテンプレートを、Cortex-M4コアへも適用したベアメタルプロジェクトです。

FreeRTOS開発とベアメタル開発の、Flash/RAM使用量差、開発難易度、消費電力差などCortex-M4コアMCU開発で実務上知りたい事柄を直接比較・評価することが可能です。また、どちらのプロジェクトも、基本的アプリケーションのテンプレート（＝スタートプロジェクト）としても活用でき、プロトタイプ開発に最適です（FreeRTOS/ベアメタルの2プロジェクト＋説明資料、税込2000円）。

また、STマイクロエレクトロニクス）STM32G4（Cortex-M4/170MHz、Flash/512KB、RAM/96KB）対応版も開発を予定しています。

FreeRTOSアプリケーションテンプレートを使ったプロトタイプ開発の次の段階としては、セマフォやQueue以外のミューテックスやイベントグループなどのより高度なRTOS手段の利用や、高速でRAM使用量も少ないタスク通知手段などのチューニング開発へとステップアップすることです。

NFCを使うLPC8N04のOTA

2018年6月25日2018年6月25日 WithHappy

5/31～6/21の4回に渡り行われたNXPセミコンダクターズ LPC80x WebinarでLPC80xシリーズ概要が解ります（8/16ビットMCUの置換えを狙う32ビットARM Cortex-M0+コア採用のLPC80xシリーズ特徴や商品戦略が解るWebinarスライドは、リンク先からダウンロード可能）。

LPC8xx Family History (Source：Webinar Slides) — LPC8xxは、LPC81x/LPC82xから、2017年高集積LPC84x、2018年価格高効率LPC80xへ展開（出典：Webinar Slides）

LPC8xxファミリは、2016年発売のLPC81x/LPC82xをベースに、2017年にLPC84xで高集積大容量化、2018年はLPC80xで価格効率を上げる方向に発展中です。

関連投稿：LPC80xの価格効率化の方法

ベースとなったLPC810、LPC812、LPC824に対して弊社は、LPC8xxテンプレートを提供中です。このテンプレートは、発展したLPC84xやLPC80xへも適用できると思います。

＊　　＊　　＊

さて、本投稿は、今後IoT MCUの必須機能となる可能性が高いOTA（Over The Air）について、LPC8N04スライドにその説明がありましたので、速報としてまとめます。

NFCを使うLPC8N04のOTA更新

LPC8N04 は、近距離無線通信（NFC）機能を搭載し15MHz動作のLPC802/LPC804よりもコア速度をさらに8MHzへ下げ、NFCアプリケーション開発に適したMCUです。スマホとNFCで連動する温度センサーロガーの動作例がNXPサイトの動画で見られます。

Cortex-Mシリーズはセーフ、他はアウト

2018年1月7日2018年1月9日 WithHappy

新年早々、Intel、AMD、ARMなどの制御デバイス製造各社に激震が発生しました。「CPU投機的実行機能に脆弱性発見」のニュース（Intel、AMD、ARMの対応、 Windowsの対応、 Googleの対応）です。

※投機的実行機能：制御を最適化するためのパイプライン化、アウトオブオーダー実行などの「現代的CPU」ハードウエアに実装済みの機能。

※脆弱性：ウイルスが入る可能性がある箇所のこと、セキュリティホールとも呼ばれる。言わばアキレス腱のような箇所。もっと知りたい方は、総務省サイトの基礎知識が良く解ります。

Cortex-Aシリーズも対象、Cortex-Mシリーズは対象外（セーフ）

パイプラインやアウトオブオーダーなどの最適化機能は、殆どの制御コアに搭載されています。従って、このニュースは深刻です。ハードウエアの深い部分の脆弱性だけに、ソフトウエアのOSやパッチなどで対応できるのか、個人的には疑問ですが、セキィリティ専門家に任せるしかないでしょう。

ARMのリアルタイム系Cortex-RやCortex-Aシリーズも対象：アウト！です。
一方、本ブログ掲載のCortex-Mシリーズマイコンは、これら投機的機能が実装されていないので今回は対象外、セーフでした。

IoT端末の脆弱性対応はOTA：Over The Air更新が必須

昨年12月3日投稿のCortex-Mを用いるIoTマイコンへも、Amazon FreeRTOSなどのRTOSが期待されています。今回のような脆弱性への対応には、無線通信によるソフトウエア更新：OTA機能が必須になるでしょう（ソフトウエアには、OSとアプリの両方を含んでほしいという願望も込みです）。

時々発生する自動車リコールも、ハード起因とソフト起因の両方があります。車の場合は、ディーラーへユーザが車を持ち込めば対応できますが、組込み制御の場合は、開発者自身が動作中の現場で対応するのが現状です。今回は、Cortex-Mシリーズはたまたまセーフでしたが、同様のセキュリティ事案への対策を練る必要があると思います。

と言っても、当面できるのは、現場でIDEやUART経由の直接ソフト更新か、または、コチラの記事のような（多分高価な）パッチ配布手段しか無いかもしれません。