IoT MCUのHappyTech

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コアの対応版も開発予定です。

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

2021年6月18日2021年11月6日 WithHappy

今年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です。

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

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画面

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

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

左端Reportクリックで、アプリケーション動作時の消費電流シミュレーション波形と平均値が表示されます。ピーク時3mA、平均600μA程度で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日間自動保存されますので、途中から開発継続することも容易です。

まとめ

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

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基礎固めに最適です。

21H2 Sun Valleyは大規模更新

2021年6月4日2021年11月6日 WithHappy

5月19日に手動更新したWindows 10 21H1は、その後も安定して動作中です。この21H1と次回大型更新で「この10年間で最も重要なWindowsアップデートの1つ」と言われるSun Valleyこと21H2 の2記事を紹介し、今秋21H2大規模更新失敗時の対処案を示します。

秋21H2は大規模更新、春21H1機能追加はわずか

今秋のWindows 10大型更新は、Microsoft CEO) Nadella氏よると「この10年で最も重要なWindowsアップデートの1つ」で、スタートメニュー、アクションセンター、ファイルエクスプローラー、タスクバーなどの見慣れたユーザインタフェース（GUI）が新しいデザインへ変更、新機能追加の可能性もあるそうです（CNET Japan、2021/06/03）。

6月24日のオンラインイベントで次世代Windowsの詳細が発表されそうです。開発コード名Sun Valleyこと次期Windows 10バージョン21H2は、大規模更新になりそうです。

一方、今春の“21H1の機能追加はわずか（日経クロステック、2021/05/31）”の記事で、Windows 10大型更新と更新規模、その更新プログラム配布方法について解り易い図が掲載されていますので、抜粋し21H2の予想を追加しました。

Windows 10バージョン	大型更新開始時期	更新規模	更新プログラム配布方法
20H1	2020年上期	大規模？	通常（一括ダウンロード）
20H2	2020年下期	小規模	有効化パッケージ
21H1（今春：現状）	2021年上期	小規模	有効化パッケージ
21H2（今秋予定）	2021年下期	大規模？	通常（一括ダウンロード予想）

更新プログラム配布方法の有効化パッケージとは、大型更新開始前に、更新内容を無効化した状態でPCへ段階的に更新プログラムをパッケージで配布しておき、大型更新時にそれらを有効化する方法です。小規模更新の場合には、更新プログラムダウンロード時間が短くなるなどのユーザメリットがあります。

大規模更新では事前配布パッケージ自体もおそらく大きくなるため、Windows7から8/8.1への更新と同様、事前配布無しに一括して更新プログラムをダウンロードする通常方法になると予想します。

OSクリーンインストール歴史

Windows 10初版リリースが2015年なので、ここ10年の範囲にはWindows 7や8/8.1なども含まれるでしょう。筆者は、Windows 7や8の時代は、新OSリリースに合わせて、または、PCの調子が悪い時は、リカバリよりもOSクリーンインストールを行っていました。

既存アプリケーションの再インストールや再設定も必要で、手間と時間がかかる作業でしたが、リカバリよりも新OSをクリーン環境で使うメリットが大きいと判断したからです。

Windows 10へアップグレート後は、クリーンインストール回数は減り、20H1以降は、全てのPCで問題なく大型更新が成功しています。クリーンインストールの手間を考慮すると、少々のトラブルは、自己修復してきたとも言えますが、それでも旧OSに比べ、安定度や安心感は高いと評価しています。

Windows 21H2大規模更新失敗対策案

今秋21H2は、操作性も含めた大規模更新で、開発中止したWindows 10X機能などを含める噂もあり、共通コアOSに比べ、更新失敗の可能性は高くなります。関連情報を収集分析しますが、所有PCは、最終的には3つの更新結果になると予想しています。

21H2手動更新成功
21H2手動更新失敗➡21H2クリーンインストール
21H2手動更新失敗➡21H1へリカバリし継続使用

更新成功を期待しますが、失敗時は、21H2をクリーンインストールする案と、21H1へリカバリして継続使用する2案があります。

現在使用中の21H1は、20H1から続く共通コアOSのWindows 10です。21H1サポート終了の2022年12月（2022年5月という記事もあり）までは、継続使用でも安心して運用ができます。またGUIも、現状のままでも不満はありません。

最新21H2をクリーンインストールするか否かは、発表される次世代Windowsの内容次第です。

魅力的なOSであれば、手間をかけてもクリーンインストールするでしょう。次世代Windowsの内容は、本ブログでも適宜取上げていきます。

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

21H1手動更新成功

2021年5月21日2021年11月6日 WithHappy

5月19日、2021年春のWindows 10 21H1手動更新に成功しました。更新方法は、関連投稿：20H2の時と同じです。

2日経過した現在、トラブルは無く、Microsoft Office/LibreOfficeやブラウザなどの主要アプリケーション、FreeRTOSアプリケーションテンプレート開発に使用中のMCUXpresso IDEも正常に動作しております。1世代前の20H2と特に変わった点は見当たらず、今回もまた小規模更新でした。本稿も最新21H1で作成しました。

要点と春21H1手動更新用USBメディア作成

前回の20H2との違いは、21H1用のMediaCreationTool21H1.exeをダウンロードし、USB/DVDメディアを作成する点です。どなたでもダウンロードできます。

21H1ビルド番号は、19043.985です。コチラの記事のMicrosoft表明から、既に何回か更新されています。

手動更新の要点は、「旧Windows 10 20H2起動状態」で、作成したUSBのsetup.exeを実行すること、トラブルに備えた「バックアップ＆リカバリーができる」ことです。これらを注意すれば、個人用ファイルと既存アプリを引き継いだまま、手動でWindows 10 21H1へ更新できます。

その他の留意事項

手動更新メリットは、ユーザ主体でWindows更新ができることです。デメリットは、Windows 10レジストリがデフォルト値に戻ること、一部の既存アプリ設定が引き継がれない場合があることです。

弊社の場合、今回の手動更新で、Dynamic Theme、EaseUS Todo Backupに引き継がれていない設定がありました。特に、EaseUS Todo Backupは、バックアップアプリで重要です。このように、重要なアプリは、Windows更新完了後、ユーザ自身で動作と設定確認をすることをお勧めします。

※OS更新後の既存アプリ動作と設定確認は、手動更新以外の方法でもユーザ自身で行う必要があると思います。細かい話をすると、ローカルアカウント画像が引き継がれていないPCもありました😅。この程度は、更新トラブルに含めません。

秋21H2：大規模更新リスク対処

各種Windows記事によると、次回秋の21H2は、スタートメニューなど操作性も含めて大規模更新になるそうです。

今回春の21H1は、従来OSコアと共通の小規模更新でした。そこで、弊社所有Windows PC 3台全てを19日に手動更新し、2日経過した現在、いずれも安定動作しております。更新に要した時間は、0.5日/3PCでした（バックアップ時間除く）。

大規模更新が見込まれる次回21H2は、更新トラブル有無を1PC当たり2～3日かけて慎重に確認後、段階的に手動更新する予定です。

小規模更新との差は、動作確認を3PC並列に行うか、1PCずつ直列に行うかです。直列確認中に1台でもトラブルが発生した時は、以降のOS更新を止めます。これにより、作業中の業務停止を防ぎ、Windows大規模更新へのリスク対策とします。

今秋のMCU開発業務が一段落付いた頃を見計らって、21H2大規模更新に1週間/3PCを費やす予定です。

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

IoT新汎用RL78/G23調査

2021年5月7日2021年11月6日 WithHappy

ルネサスエレクトロニクスが、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シリーズ位置づけ

ルネサス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よりも動作電流が少ないため、低電力動作になります。

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

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

30％低消費電力化

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

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

従って、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データ送受信

2021年4月28日2021年12月12日 WithHappy

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

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

FreeRTOSアプリケーションテンプレート構想
FreeRTOS新規プロジェクト作成からアプリケーションテンプレートまで
テンプレートベース：freertos_generic前半（ソフトウェアタイマ関連）

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

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

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

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

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

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

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

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

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

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

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

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とベアメタル、それぞれで開発した2つのプロジェクトを添付します。

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

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

LPCXpresso54114 150MHz動作設定方法

2021年4月23日2021年12月12日 WithHappy

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

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

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

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

開発ツール

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

そこで、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への変更手順が以下です。

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に掲載中）。

あとがき

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

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

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