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

FreeRTOSアプリケーションテンプレート動作中
FreeRTOSアプリケーションテンプレート動作中

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アプリケーションテンプレートです。

MCU RTOS多様化対策のFreeRTOSアプリケーションテンプレート
MCU RTOS多様化対策の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)
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コアの対応版も開発予定です。

WebシミュレータのRL78/G23開発

今年4月に発表されたばかりのルネサスIoT向き新汎用RL78/G23が、RL78 Webシミュレータを使うと手間暇かけずに開発できます。このWebシミュレータの使い方と、RL78/G23シミュレーション結果を示します。

IoT新汎用RL78/G23特徴は、コチラの関連投稿を参照してください。

RL78 Webシミュレータとは?

評価ボードやIDE無しに、Webブラウザだけで対象MCUのアプリケーションを開発でき、その消費電流が判ります。バッテリー寿命予測などに好都合です。

対象MCUは、RL78/G1xシリーズでしたが、早くもG1x後継MCUのIoT向き新汎用RL78/G23が追加されました。ログイン必須ですが、無料で利用できます。

また、Webシミュレータ上で開発したソフトウェアは、CS+やe2 studioとも互換性があるので、そのまま実際のIDE/評価ボードへエクスポートして使うこともできます。

つまり、初期費用ゼロでRL78/G23が開発でき、その開発資産も活かせます。コロナ過の今こそ役立つツールと言えます。

競合他社32ビットCortex-M0+クラスのeclipseベースIDEにも、消費電流シミュレータが付属しています。RL78/G13比、30%低消費電力化したRL78/G23の低い消費電流と比較可能です。

RL78/G23 Webシミュレーション結果

RL78/G23の評価ボード:Fast Prototyping Boardを使って、基本的なA/D変換アプリケーションをシミュレーションする例で、Webシミュレータの使い方を示します。

MCU Simulator Online (Web IDE)

Webシミュレータ初期画面のアプリケーションから選択メニューのA/D変換機能をクリックし、対象デバイスRL78/G23のMCU Simulator Online起動をクリックします。ガイドツアー利用有無を聞いてきますが、後回しOKです。

Webシミュレータ初期画面からA/D変換機能をクリックした画面
Webシミュレータ初期画面からA/D変換機能をクリックした画面

RL78/G23 Fast Prototyping Board上で、A/D変換アプリケーション(サンプルアプリケーション)がインポートされたMCU Simulator Online画面が表示されます。

RL78/G23 A/D変換アプリケーションのMCU Simulation Online画面(Web IDE)
RL78/G23 A/D変換アプリケーションのMCU Simulation Online画面(Web IDE)

ビルド、リセットや実行などアプリケーション開発に最低限必要となるボタンが用意されたWeb IDEがMCU Simulator Onlineです。

ビルドをクリックするとConsole窓にビルド結果が表示されます。オリジナルサンプルアプリケーションのまま無変更なので、ビルドは成功します。

RL78/G23 Fast Prototyping Board

左端Boardクリックで、RL78/G23 Fast Prototyping Boardが表示されます。アプリケーション動作確認に必要な外部部品:ポテンショメータは、P22/ANI2に接続済みです。

RL78/G23 A/D変換アプリケーションのFasr Prototyping Board画面
RL78/G23 A/D変換アプリケーションのFasr Prototyping Board画面

実行をクリックすると、ポテンショメータのスライドバーに連動して、赤7セグ表示(変数値表示パネル)が変わります。これが、アプリケーション実行時のFast Prototyping Board動作状態です。

RL78/G23 A/D変換アプリケーション消費電流

左端Reportクリックで、アプリケーション動作時の消費電流シミュレーション波形と平均値が表示されます。ピーク時3mA、平均600μA程度でA/D変換を実行することが判ります。

RL78/G23 A/D変換アプリケーションの消費電流画面
RL78/G23 A/D変換アプリケーションの消費電流画面

Webシミュレータ終了

Webシミュレータで、RL78/G23とA/D変換アプリケーションを選んでビルド、評価ボードで動作確認、消費電流シミュレーション波形とその平均値を得るまで、わずか2~3分です(ガイドツアーは除く)。

実機で同じことを行えば、半日~1日は掛かります。しかも、実際のIDE設定や評価ボードとの接続、測定装置準備など全てが上手く出来た上での話です。実機ではこの段階で、つまずきを経験した方も多いでしょう。

手間暇かけずにWebシミュレータ上でRL78/G23開発を試すことができることがお解り頂けたと思います。

また、Web IDEでサンプルアプリケーションに変更を加えステップ実行、SWやLEDなどの外部部品をBoardへ追加することもできます。詳しくは、左下Info.クリックで表示されるガイドツアー、オリジナルプロジェクト作成を試すクリックで判ります。

ガイドツアー開始画面
ガイドツアー開始画面

Webシミュレータ終了は、MCU Simulator Online右上ハンバーガーメニューのサインアウトクリックです。プロジェクトは、90日間自動保存されますので、途中から開発継続することも容易です。

Web Simulator Online終了ダイアログ
Web Simulator Online終了ダイアログ

まとめ

RL78 Webシミュレータは、ブラウザだけを使って、誰でも簡単に初期費用ゼロでRL78/G1x/G2x開発が試せます。予め多くのサンプルアプリケーションがWeb IDEに用意済みで、仮想評価ボード上でアプリケーション動作確認、消費電流波形、平均消費電流計算が、僅か数分でシミュレーションできます。

Webシミュレータで開発したソフトウェアは、CS+やe2 studioへエクスポートできます。実機開発前、または、開発中であっても並行利用によりRL78/G1x/G2x開発に役立つツールです。

汎用RL78/G1x後継となったIoT向き新汎用RL78/G23のFast Prototyping Board上で、A/D変換アプリケーションシミュレーション例を示し、Webシミュレータ使用法、平均600μA低消費電流計算結果を得ました。

多様化MCU RTOS対策

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ブラウザ

IoT MCU RTOSとPCブラウザ比較
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ユーザタスクの作り方

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

図1 ベアメタル処理とFreeRTOSタスク処理並列多重
図1 ベアメタル処理と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 Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

このテンプレートには、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使用量も少ないタスク通知手段などのチューニング開発へとステップアップすることです。

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

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

JACOB's Blog
JACOB’s Blog

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に限らず組込み関連全般の卓越した問題再構築能力は、掲載図を見るだけでも良く解りますよ😄。

IoT新汎用RL78/G23調査

ルネサスエレクトロニクスが、2021年4月13日、新世代の汎用MCU RL78/G23を発表しました。RL78/G23は、弊社RL78/G1xテンプレートデバイスRL78/G13やRL78/G14の製造プロセスを改良し、IoT向き機能を強化した汎用MCUです。

新しいRL78/G23と従来RL78/G13を比較し、ルネサスIoT Edge MCU機能強化点と評価ボードを調べました。

新汎用RL78/G2xシリーズ位置づけ

汎用RL78MCU変遷(出展:RL78 ファミリパンフレットに加筆)
汎用RL78MCU変遷(出展:RL78 ファミリパンフレットに加筆)

ルネサスRL78ファミリパンフレット2021.04のp1記載RL78ロードマップから汎用MCUファミリを抜粋し、加筆したのが上図です。RL78/G23は、RL78/G13とG14性能の大部分をカバーした新しい汎用MCUであることが判ります(縦軸:性能、横軸:年代、橙色囲み:テンプレート対象RL78/G1xシリーズ)。

新汎用RL78/G23は、従来汎用RL78/G1xシリーズへIoTエッジ向き機能(製造プロセス、Snoozeモード・シーケンサ、高速オンチップオシレータ高速起動、中速オンチップオシレータ搭載など)を追加し、RL78/G1xシリーズと互換性があります。

RL78/G23のIoT Edge MCU機能強化点

RL78/G23は、RL78/G1x比、主に下記機能が強化されています。

  • Snoozeモード・シーケンサ搭載
  • RL78/G13比、30%低消費電力化
  • IoTエッジMCUセキュリティ強化

Snoozeモード・シーケンサ

Snoozeモード・シーケンサ(SMS)は、Snooze中のMCUを起動することなく、演算、分岐、周辺回路制御の順次処理が可能なMCU内蔵ハードウェアです。SMSはMCUよりも動作電流が少ないため、低電力動作になります。

Snoozeモード・シーケンサによる低電力動作効果(出展:ルネサスRL78ファミリ)
Snoozeモード・シーケンサによる低電力動作効果(出展:ルネサスRL78ファミリ)

従来のRL78/G13も、低電力動作用Snoozeモード(上図)を持っていました。Snoozeモード・シーケンサ(下図)は、周辺回路制御(Analog/Port settings)や、データ・トランスファー・コントローラ(DTC)の直接起動(USRT transmission)など、従来MCUの代わりに、予め設定した最大32個のシーケンシャル処理実行が可能です。

このSMSを活用すると、点線部分のMCU動作が不要となり、従来のRL78/G13よりも更に低電力処理が可能です。

30%低消費電力化

RL78/G13比、30%少ない低消費電力動作のRL78/G23(出展:ルネサスサイト)
RL78/G13比、30%少ない低消費電力動作のRL78/G23(出展:ルネサスサイト)

前述のSMSや新製造プロセスなどにより、RL78/G13(64KB)比、30%の低消費電力化を達成しています。ROM容量が128KBと2倍での比較になる理由は、次章セキュリティ強化で説明します。

なお、RL78/G23最高動作周波数は32MHzで、従来RL78/G13と同じです。

IoTセキュリティ強化

RL78/G23新追加のSecure update and secure boot(出展:ルネサスRL78ファミリ)

IoTエッジMCUセキュリティ強化のため、RL78/G23には、RL78/G1xには無かったセキュア・ブートとセキュア・アップデート機能が実装されています。セキュア・アップデートには、実行中ROM領域に加え、書換え用ROM保存領域も必要になるため、従来比2倍のROM容量が必要です。

2倍詳細は、関連投稿:STM32G0/G4のRoot of Trust (1)~(3)、または、セキュア・ファームウェア更新:タグなどを参照してください。

RL78/G23 Fast Prototyping Board

RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)
RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)

従来のルネサス評価ボード(QB-R5F100LE-TBなど)は、開発時、別途E1/E2エミュレータが必須でした。新しいRL78/G23(32MHz、64ピン、ROM/128KB、RAM/16KB) Fast Prototyping Board(2590円)は、USB-シリアル変換器が搭載され、USB経由でデバッグとプログラミングが可能です。

RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)
RL78/G23 Fast Prototyping Board(出展:ユーザーズマニュアル)

従って、micro USBケーブルでPCと接続しさえすれば、エミュレータ無しでもプロトタイプ開発に着手できます。また、Arduinoコネクタも実装済みで、各種Arduinoシールドをスタック装着できる評価ボード形状になりました。

まとめ

RL78/G23は、RL78/G13互換性を重視し、IoTエッジ向き低電力性とセキュリティを強化した新世代の16ビット汎用MCUです。

エミュレータ不要でArduinoコネクタ実装済みRL78/G23評価ボード(32MHz、ROM/128KB、RAM/16KB)は、制御系載せ替えモジュール化が可能となり、競合他社MCUとの比較も容易です。

載せ替え制御系モジュールの詳細は、コチラの関連投稿3章:半導体不足時のMCU開発対策案を参照してください。

あとがき

久しぶりのRL78マイコンカテゴリ投稿でした。32ビットARM Cortex-M0+コア対抗のため、低消費電力化と評価ボード改善を図ったのが、RL78/G2xシリーズ第一弾:RL78/G23です。

その特徴を活かすには、新追加Snoozeモード・シーケンサ活用、つまり、ルネサスSxコア動作の休止に磨きをかけたソフトウェア開発(従来ソフトの一部SMSハード化)が必須です。

これは、Cortex-Mxコア低消費電力アプローチ:より高周波数の動作+コア休止時間幅拡大とは、方向性が異なると感じました。ルネサスは、RL78/G1x顧客サーベイの結果、製造プロセス進化アドバンテージを、高周波数動作よりも、SMS追加や2倍メモリ増量へ配分したのでしょう。

このSMSを、ルネサス供給中のCortex-MxコアMCUへも搭載すると、差別化できるかもしれません。

FreeRTOSアプリケーションのQueueデータ送受信

FreeRTOSアプリケーションテンプレートのQueue利用タスク間データ送受信を説明します。これは、テンプレートのベースとしたMCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_generic解説の後半に相当します。

FreeRTOSアプリケーションテンプレートのベースプロジェクト(まとめ図参照)は、本稿で全て説明済みとなります。下記1~3が、関連投稿です。1~3の順にお読み頂くと、内容が解り易いと思います

  1. FreeRTOSアプリケーションテンプレート構想
  2. FreeRTOS新規プロジェクト作成からアプリケーションテンプレートまで
  3. テンプレートベース:freertos_generic前半(ソフトウェアタイマ関連)

freertos_genericのQueueによるデータ送受信

freertos_genericのQによるデータ送受信
freertos_genericのQによるデータ送受信

FreeRTOSでは、送信タスクと受信タスクの2つに分離しデータ送受信処理を開発します。

送信タスクは、自分の都合の良いタイミングで、いつでもデータ送信を始めます。受信タスクは、いつ始まるか判らないデータ送信に対し、常時受信できるように待機中です。但し、受信タスクの受信開始タイミングは、その他のタスク優先度により変動します。

この受信開始変動があっても送信データを取りこぼし無く受信するために、送受タスク間で一時データを格納するFIFOバッファが必要で、これがQueue(以下Q)です。マルチタスクによる副作用と言えます。

もちろん、データ溢れが生じないようQには複数データを蓄える深さも必要です。受信タスクは、データのQ完了イベントで、FreeRTOSが受信開始を起動します。また、送信タスクよりも、受信タスクの方が優先度が高いのは、Qデータ溢れ防止策です。

1データ長、データ送信タイミング、その他のタスク数やその優先度にも影響されるQの深さは、十分な検討が必要です。

freertos_genericでは、Qの深さを1データ、送信タスク優先度を1、受信タスク優先度を2とし、データを100固定値にして1バイトデータ長の送受信を行い、送信開始タイミングは、vTaskDelayUntil(後述)で作成しています。その他のタスクが、freertos_generic前半で説明したソフトウェアタイマタスク、この優先度が4です。

同一優先度のタスクが無く、他のタスク数もタイマタスク1個で高優先、1バイトデータ長のため、深さ1のQでも送受信データは溢れません。

少ないタスク数と同一優先度無しのシンプルなサンプルプロジェクトですが、簡単に説明しても上記のように長くなります。

ベアメタル開発経験者であれば、RTOS個々の文章説明(=Serial or Sequential動作)は、理解できます。しかし、RTOSによりシングルコアMCUであっても各タスクが時分割Parallel動作しますので、途端に解り難くなります。

BareMetal/SerialからRTOS/Parallelへ、従来の設計手法をステップアップする必要がありそうです。

vTaskDelayUntil対vTaskDelay

vTaskDelayUntilとvTaskDelay比較
vTaskDelayUntilとvTaskDelay比較

freertos_genericは、データ送信タイミングの作成に、他のサンプルでよく見かける待ち処理:vTaskDelayではなく、vTaskDelayUntilを使っている点に注意が必要です。

vTaskDelayは、指定待ち「時間」後、RTOSにより優先度に応じて次処理が実行されます。ゆえに、高優先の他タスクやその状況により、次処理実行までの待ち時間が変動します。

vTaskDelayUntilは、指定待ち「周期」後、次処理が実行されます。仮に2周期よりも長い待ちが発生した時は、次処理はスキップされます。つまり、vTaskDelayよりもデータ送信の(スキップも含めると)定間隔、周期性に優れています。

サンプルプロジェクトの場合、Qの深さが最小の1のため、vTaskDelayUntilの方が、Q溢れ対策として効果があります。vTaskDelayだと、変動を考慮し、より深いQが必要になりそうです。但し、vTaskDelayUntilのRAM使用量は、vTaskDelayよりも増えます。

つまり、vTaskDelayUntil 利用か、それとも、vTaskDelayとQの深さ利用か、どちらにRAM資源を割当てる方が、よりQ溢れ対策として効果的か、これが検討ポイントの1つです。freertos_genericでは、前者を選択した、と筆者は解釈しました。

参考資料:Kernel > API Reference > Task ControlのvTaskDelayUntilとvTaskDelay

本稿まとめとFreeRTOSアプリケーションテンプレート目的

FreeRTOSアプリケーションテンプレートのQ利用タスク間データ送受信を説明しました。Qにより、送信タスクと受信タスクを分離して開発できますが、Qの深さは、送受タスク以外の他タスク優先度など多くの要因にも関係するため、設計に注意が必要です。

FreeRTOS利用メリットは、ベアメタル開発に比べ、独立性や流用性が高いタスク開発ができることです。反面、優先度に応じたマルチタスク環境では、ベアメタル開発には無かったスキルも必要になります。

本稿説明のSDK付属FreeRTOSサンプルプロジェクトfreertos_genericをベースにした、Cortex-M4コア最高速150MHz動作LPCXpresso54114対応のFreeRTOSアプリケーションテンプレートは、6E目標に開発中です。

FreeRTOS Application Template (NXP Version)
FreeRTOS Application Template (NXP Version)

同じ動作のアプリケーションを、FreeRTOSとベアメタル、それぞれで開発した2つのプロジェクトを添付します。

FreeRTOSアプリケーションテンプレートの目的は、FreeRTOS特有スキルを、ベアメタルと比較し、具体的に理解・習得すること、基本的なFreeRTOSアプリケーション開発テンプレート(=スタートプロジェクト)としても使えること、の2点です。

なお現行のLPCXpresso54114開発SDKツールデフォルトコア速度100MHzを150MHz動作へ変える方法は、前稿を参照してください。

LPCXpresso54114 150MHz動作設定方法

MCUコア動作速度設定は、一般的にプログラミングの冒頭、main関数の各種初期設定よりも前で行い方法は2つあります。

LPCXpresso54114の150MHz動作
LPCXpresso54114の150MHz動作

1つがソフトウェアで明示的にコア速度を設定する方法(左側の橙下線)、もう1つがConfig ToolsでGUIを使って設定する方法(右側の橙囲い)です。ソフトウェア設定方法は、代表的な設定値のみがAPIで提供され、GUI利用方法は、細かな速度設定や周辺回路毎へのクロック供給設定ができるなど柔軟性があります。

弊社は、アプリケーション開発後の低消費電力チューニング時にもソースコード不変で柔軟性メリットがあるConfig ToolsのGUI利用方法を推薦します。

現状の開発ツールでは、コア速度がデフォルト96MHzですので、これを150MHzへ変える方法を示します。

開発ツール

前稿最後に示したLPCXpresso54114最新データシートで発見(!)したCortex-M4コア最大動作周波数150MHzは、最新SDKの新規プロジェクト作成時でも旧データシート記載の100MHz(=96MHz)のままです。

そこで、2021年4月2日投稿の新規FreeRTOSプロジェクト作成方法のStep1~Step5に、本稿の動作クロック150MHz化をStep6として追加します。

本稿で示す開発ツールは、本日時点の最新版で以下です。

・MCUXpresso IDE v11.3.1 [Build 5262] [2021-04-02]
・LPCXpresso54114 SDK Version 2.9.0
・LPC5411x データシートRev. 2.6

これを示した理由は、今後の開発ツール更新によりデフォルト動作クロック値が150MHzへ変わる可能性もあるからです。

Config Tools利用MCU動作速度150MHz設定

新規プロジェクト作成直後のConfig Tools Clocks Diagramが下図です。コア速度のSystem clockは96MHzです。150MHzへの変更手順が以下です。

SDK新規プロジェクト作成直後のClock Diagram
SDK新規プロジェクト作成直後のClock Diagram

1. PLL Modeを、Fractional/Spread spectrumからNormalへ変更。
2. クロック選択肢をクリックすると、下図のように供給クロックのルート変更ができます。最初に示したクロックルートになるよう各選択肢やPLL設定を変更し、System clockを150MHzにします。

クロック選択肢をクリックして供給クロックルート変更
クロック選択肢をクリックして供給クロックルート変更

3. Config ToolsのUpdate Codeをクリックし、GUI変更結果をソースコードへ反映させます。

※全般的なConfig Toolsの使い方は、コチラの関連投稿を参照ください。

初期設定後に下記のようなソースコードを追加しておくと、コア動作クロックが設定値に変わったか確認ができます。

コア動作クロック速度を示すソースコード
コア動作クロック速度を示すソースコード

Config Tools MCUコア速度設定メリット

例えば、初期設定したusart通信速度115200bpsやMRT:マルチレートタイマ満了時間は、コア速度を変えたとしても不変です。各ドライバ内で、コアから独立した速度/満了時間設定を行うからです(※厳密には、設定誤差などが多少変わります)。

MCUの中で消費電力が最も大きいコアの動作速度を下げるのは、アプリケーション開発後の低電力動作チューニングに最も効果があります(※アプリケーション開発中にコア速度を下げるのは、より厳しい動作条件で開発することに相当しますのでお勧めしません)。

ソフトウェアで直接コア速度を記述した場合、この低電力化検討時に記述変更が必要になります。しかも、代表的な速度のみ設定可能なため、変更幅が大きくなる欠点があります。

一方、本稿で示したConfig Toolsによるコア速度設定の場合は、ソフトウェア設定に比べ細かな設定が可能で、記述ソフトウェアも不変です。更に、周辺回路動作も個別に制御できるため、コアだけでなく電力消費が大きい周辺回路の特定などにも役立ちます。

つまり、Config Toolsコア速度設定方法は、より効果的できめ細かいMCU低電力動作チューニングが可能でメリットが大きいと言えます。

評価ボード消費電流測定方法

評価ボードLPCXpresso54114には、0Ωチップ抵抗:JS11の取外しが必要ですが、消費電流測定用の端子:JP4が用意されています。これを使うと、前章で示したコア速度変更や周辺回路を動作停止した時の実消費電流が測れます(測定誤差ガイドラインもデータシートFig. 5に掲載中)。

LPCXpresso54114消費電流計測回路
LPCXpresso54114消費電流計測回路

あとがき

LPC5411x データシートRev. 2.6は、コア速度96MHzまでのCoreMark消費電力しか記載されておらず、しかも、96MHz以降急激な上昇傾向があるなど、気になる点もあります。

CoreMark power consumption
CoreMark power consumption

現在のSDK新規作成プロジェクトがデフォルト96MHzなのは、この辺りが妥当なクロック速度のせいかもしれません。今後のデータシート改版で状況を見たいと思います。

但し、開発中のCortex-M4 LPCXpresso54114向けFreeRTOSアプリケーションテンプレートは最高動作周波数の150MHz動作、比較用ベアメタルアプリケーションも150MHzで開発します。

半導体不足とMCU開発案

3月26日投稿で危惧した半導体供給不足が深刻化しており、MCU開発者へも影響が出始めています。コチラの記事が、具体的な数字で深刻さを表していますので抜粋し、MCU開発者個人としての対策私案を示します。

半導体不足の深刻さ

今回の半導体不足は、通常時に比べ2倍以上のリードタイム増加となって現れています。

通常時と現在(半導体不足時)のリードタイム比較
発注から納品までのリードタイム 通常 現在
MCU、ワイヤレスチップ、パワーIC、Audio Codec、

パワーモジュール、GPUチップ

8~12週 24~52
ロジックIC、アナログIC、ASIC、電源用MOSFET、受動部品 8~12週 20~24週
LCDパネル 6~8週 16~20週
CPU 8週 12~20週
メモリ、SSD 6~8週 14~15週
PCB(基板)製造 2~4週 8~12週

記事によると、特にMCUとワイヤレスチップのリードタイムが長くなっており、52週!ものもあるそうです。

表記した第1行目の部品で半導体不足が語られることが多いのですが、PCB(基板)製造へも影響しているのは、MCU/ワイヤレスチップ供給不足により、基板作り直しが生じるため、またロジックIC以下の部品も同様に製品再設計の影響と推測します。

MCU、ワイヤレスチップの供給不足がリードタイム激増の主因、それ以外の部品リードタイム増加は、主因の影響を受けた結果と言えるでしょう。

半導体供給の意味

日本では半導体は、別名「産業のコメ」と言われます。世界的には、「戦略物資」という位置付けです。半導体で米中が対立するのは、政治体制だけでなく、近い将来の経済世界地図を大きく変える可能性があるからです。

半導体製造は、国際分業化が進んできましたが、今回の半導体不足の対策として、国や企業レベルでは全て自国や自社で製造を賄う動きもでてきました。持続的経済成長には、食糧と同じように半導体の自給自足が必須だということです。

MCU開発対策案

MCU開発者個人レベルでの半導体不足対策は何か、というのが本稿の主題です。

MCU開発者は、半導体を使った顧客要求の製品化が目的です。半導体不足の対策は、「代替MCUの開発能力と製品化方法の見直し」だと思います。例えると、COVID-19収束のため、複数ワクチンの中から入手しやすいものを利用するのと同じと言えば解っていただけるかもしれません。目的と手段を分けるのです。

製品化方法の見直しとは、評価ボード活用のプロトタイプ開発により製品完成度を上げ、最終製品化直前まで制御系の載せ替えを可能とすることです。CADやIDE消費電力シミュレーションなどを活用し、プロトタイプの製品完成度を上げます。

製品完成度を上げる段階で、更なるMCU能力の必要性や低消費電力性などが判明することも多々あります。載せ替え可能な制御系でこれら要求に対応します。プロトタイプ開発着手時に、候補となる複数ベンダのMCU評価ボードを事前準備しておくのも得策です。

MCU評価ボード載せ替えプロトタイプ開発案
MCU評価ボード載せ替えプロトタイプ開発案

現在も様々なMCU新製品が発表されています。評価ボードは、これら新MCUの販売促進ツールですので、個人でも比較的安く、早く調達できます。また、ワイヤレスチップ搭載済みでArduinoなどの標準インターフェースを持つ評価ボードならば、この標準インターフェースで独自開発ハードウェアと分離した製品設計ができるので、制御系を丸ごと別ベンダの評価ボードへ載せ替えるのも容易です。

つまり、第2 MCU開発能力と評価ボードを標準制御系とし、自社追加ハードウェアと分離したプロトタイプ開発により、第1 MCU供給不足と顧客製品化の遅れを少なくすることができます。標準インターフェース分離により、PCBを含めた自社追加ハードウェア開発部分の作り直しは無くすことも可能です。少なくとも、1章で示した半導体不足主因(MCUやワイヤレスチップの不足)に対して対処できます。

複数ベンダのMCU開発を経験すると、ソフトウェアやハードウェアの作り方も変わります。

ソフトウェア担当者は、万一のMCU載せ替えに備え、共通部分と個別部分を意識してソフトウェア化するようになります。ハードウェア担当者は、自社追加ハードウェアの単体試験をソフトウェア担当者に頼らずテストプログラム(TP)で自ら行うようになり、次第にソフトウェア開発能力も身に付きます。

このプロトタイプ開発の最終製品化時は、制御系評価ボードの必須部品のみを小さくPCB化するなどが考えられます。制御系は、他の部分に比べ故障率が高く、制御系のみを載せ替え可能な製品構成にしておけば、故障停止時間の短縮も図れます。

MCU評価ボードの制御系のみを小さくPCB化するイメージ(出展:マルツ超小型なRaspberry Pi)
MCU評価ボードの制御系のみを小さくPCB化するイメージ(出展:マルツ超小型なRaspberry Pi)

最新MCU情報

上記プロトタイプ開発でも通常時は、第1 MCUで開発完了でしょう。実際に第2 MCU制御系へ載せ替えるのは、半導体供給リスクに対する最後の手段です。そこで、最新MCU情報をピックアップし、第2 MCUを選ぶ参考にします。

・2021年3月31日、ARMv9発表

Cortex-M33などのセキュリティ強化コアARMv8発表から約10年ぶりに機械学習やデジタル信号処理能力強化の最新コアARMv9をARMが発表。MCUベンダ評価ボードはこれから。

・2021年4月6日、STマイクロエレクトロニクスSTM32G0で動作するエッジAI

AIによる推論だけでなく学習も行えCortex-M0+コアでも動作する新アルゴリズムMST:Memory Saving Tree搭載のSTM32G0により既存機器のエッジAI実現可能性が拡大。販売中の弊社STM32G0xテンプレートは、コチラを参照。

・2021年4月15日、MCUXpresso54114の150MHz動作:

開発中のFreeRTOSアプリケーションテンプレートで使うMUCXpresso54114評価ボード搭載のCortex-M4コア最高動作周波数は、旧データシートでは100MHzでした。しかし、MCUXpresso SDKベアメタルサンプルプログラム診ると、追加ハードウェア無しで1.5倍の150MHz動作例が多いのに気が付きます。

LPCXpresso54114の150MHz動作
LPCXpresso54114の150MHz動作

動作クロックを上げるのは、MCU処理能力を上げる最も簡単な方法です。そこで、最新データシートRev2.6(2020年9月更新)を確認したところ、Maximum CPU frequencyが100MHzから150MHzへ変更されていました(Table 44. Revision History)。

データシートも最新情報をチェックする必要がありました。製造プロセスが新しいMCUXpresso54114やSTM32G4(170MHz)などの最新Cortex-M4コアMCUは、どれも150MHz程度の実力を持つのかもしれません。

FreeRTOSサンプルプロジェクトfreertos_generic詳細

前稿の弊社FreeRTOSアプリケーションテンプレートのベースとなったMCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_genericの詳細、主にソフトウェアタイマ関連とその用途を説明します。

freertos_genericのHook関数とFreeRTOSConfig.h

Step5:FreeRTOS低電力動作
Step5:FreeRTOS低電力動作

前稿Step5でOSアイドルタスクの「Hook関数」にWFI()を追記し、FreeRTOSに低電力動作を追加しました。ベアメタル開発者には馴染みの少ないHook関数とは、MCU開発者がOSに独自処理を追加する仕組み(Wikipedia)です。ハッカーに悪用される危険性もありますが、元のOSソースはそのままで動作を変更できる便利な機能です。

freertos_genericは、このアイドルタスクの他に、スタックオーバーフロー、マロックエラーと、ソフトウェアタイマの周期割込みに後述のHook関数を用いています。スタックオーバーフローやマロックエラー発生時は、Hook関数内でMCUが動作停止しますので、対策検討の手始めになります。

これらソースコード内に記述したHook関数を有効にするには、FreeRTOSConfig.h内のマクロ設定が必須です。試しに、Step5で追記したWFIへブレークポイントを設定し、FreeRTOSConfig.hのconfigUSE_IDLE_HOOKマクロを1以外に設定するとWFIでブレークしません。configUSE_IDLE_HOOKを1に戻すと、当然ですがブレークします。

このように、ソースファイル記述よりも「FreeRTOSConfig.hのマクロが優先」されます。これが、前稿でFreeRTOSConfig.hを最重要ファイルとした理由です。

万一FreeRTOSConfig.hに記述ミスがあると、開発者が所望処理をソースへ加えても、何も無かったかのようにFreeRTOSは処理します。

そこで前稿新規プロジェクトのStep4で示したfreertos_genericのFreeRTOSConfig.hを上書きコピー後、オリジナルと内容一致を確認するのが良いと思います。但し、MCUXpresso IDEのColors&Fontを、例えばメイリオ11Pへ変えると、インデントやタブ表示なども変わるため見易く修正を加えた場合、Consolas利用のオリジナルと完全一致では無くなります。

Notepad++のCompareプラグイン実行結果。スペースが異なっても内容同じなら黄色、異なれば赤表示。
Notepad++のCompareプラグイン実行結果。スペースが異なっても内容同じなら黄色、異なれば赤表示。

そんな時に役立つツールが、Notepad++のCompareプラグイン機能です。コード内容が一致していれば挿入スペース数などが異なっても黄色、内容自体が異なれば赤で表示されるので、一目でソースコード内容差が判ります。筆者は、この機能を使ってFreeRTOSConfig.h記述ミスを回避しています。

freertos_genericソフトウェアタイマISRのHook関数

ソフトウェアタイマは、tick間隔2msの周期割込みを発生し、このISRがvExampleTimerCallback関数、このHook関数がvApplicationTickHookです。

vApplicationTickHookで2ms割込み発生を500回カウント後、イベントセマフォをprvEventSemaphoreTaskへ送出、イベントセマフォを取得したprvEventSemaphoreTaskが1秒毎に”Event task is running”をコンソールへ出力します。

freertos_genericソフトウェアタイマ処理の流れ
freertos_genericソフトウェアタイマ処理の流れ

vExampleTimerCallbackへのコード記述を少なくするのは常套手段で、ベアメタル開発でもFreeRTOSでも同じです。通常は割込みフラグクリアなどを行いますが、リロードタイマですのでvExampleTimerCallbackはカウンタインクリメントのみを行っています。

Hook関数vApplicationTickHookの500回カウント判断を変更すれば、2ms分解能で任意間隔のイベントセマフォ送出が可能です。これは、SWチャタリングやADCノイズ対策などの周期処理同期に最適です。

イベントドリブンが基本のFreeRTOSですが、割込み処理によりSWチャタリング対策を行うよりも、ソフトウェアタイマとそのHook関数を利用した周期ポーリング処理で行う方が簡単なのが判ります。

freertos_genericの原本

freertos_genericは、FreeRTOS DemoのHardware Independent FreeRTOS exampleがその原本です。原本には、より詳しい英文解説が付いています。また、前章のイベントセマフォによるタスク同期に比べ、45%高速でRAM使用量も少ないタスク通知方法など、FreeRTOS機能強化やTipsなど開発者向け情報も満載です。

6E販売開始予定の弊社FreeRTOSアプリケーションテンプレートを入手後、この開発者向け情報を活用し、FreeRTOSの更なる基礎固めと習得をお勧めします。

なお原本とfreertos_genericには、異なる動作箇所もあります。例えば、FRO:Free Run Oscillator=12MHz、System Clock=96MHzなどです。これはHardware Independentな原本を、LPCXpresso54114動作用にポーティングした結果、生じた箇所です。この部分が、freertos_genericに明記されていない場合もありますので、参照時には注意してください。

弊社は、NXP以外のMCUベンダCortex-M4クラス向けFreeRTOSアプリケーションテンプレートにも、このベンダ非依存のHardware Independent FreeRTOS exampleをベースとして使う予定です。

同一アプリケーションによるベアメタルとFreeRTOS比較が出来る特徴に加え、同一ベース利用によりベンダ間(例えば、STマイクロエレクトロニクスやCypressとNXP)のFreeRTOSアプリケーション開発比較も可能となると考えています。

freertos_genericソフトウェアタイマまとめ

開発中のNXP)LPCXpresso54114向けFreeRTOSアプリケーションテンプレートのベース、MCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_genericのソフトウェアタイマを説明しました。

ソフトウェアタイマのISRフック関数により任意周期イベントセマフォ送出が可能で、イベントドリブンが基本のFreeRTOSにおいて、SWチャタリングやADCノイズ対策などの周期ポーリング処理を行うのに適しています。

ソースコードに記述したフック関数は、FreeRTOSConfig.hのマクロ設定で有効になります。設定ミスを避けるため、オリジナルとの設定内容比較にNotepad++のCompareプラグイン機能を使いました。

なお、freertos_genericのQによるデータ送受信機能は、後半部分として別稿で説明する予定です。

あとがき

MCU開発初心者~中級の方が対象の販売中Cortex-M0/M0+/M3コアMCUテンプレートとは異なり、本稿Cortex-M4コア利用FreeRTOSアプリケーションテンプレートは、ベアメタルMCU開発経験を既にお持ちの方を対象としています。
※投稿内容と対象MCUは、コチラの一覧表を参照してください。

そこで本稿は、ベアメタルとFreeRTOS開発の差分などに関する説明は加えますが、ベアメタルは既知の内容として説明を省略しています(筆不精で、すいません😌)。

投稿内容が判りにくい場合やご質問などは、customerservice@happytech.jpへお寄せください。