RL78マイコン,MCU:マイコンRL78/G13,RL78/G14,IoTマイコン,RL78/G10,IoTエッジMCU,セキュア・ファームウェア更新,RL78/G23,Snoozeモード・シーケンサ

ルネサスエレクトロニクスが、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へも搭載すると、差別化できるかもしれません。


MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,FreeRTOS,LPCXpreosso54114,LPCXpresso SDK,queue,freertos_generic

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動作へ変える方法は、前稿を参照してください。

MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,FreeRTOS,LPCXpresso54114,MCUXpresso IDE,MCUXpresso SDK,LPCXpresso Config Tools,低電力動作

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で開発します。

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアRaspberry Pi,Arduino,LPCXpresso54114,半導体不足

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程度の実力を持つのかもしれません。

MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,FreeRTOS,LPCXpreosso54114,LPCXpresso SDK,freertos_generic,FreeRTOSConfig.h,周期処理

前稿の弊社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へお寄せください。

MCU:マイコン,LPCマイコン,Cortex-M4コアテンプレート,アプリケーション,リアルタイムOS,IoTマイコン,FreeRTOS,LPCXpresso SDK,LPCXpresso54114,freertos_generic,FreeRTOSConfig.h

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step1:評価ボード選択

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

Step1:評価ボード選択
Step1:評価ボード選択

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

Step2:FreeRTOS選択

Step2:FreeRTOS選択
Step2:FreeRTOS選択

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

Step3:FreeRTOSドライバ選択

Step3:FreeRTOSドライバ選択
Step3:FreeRTOSドライバ選択

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

Step4:freertos_generic.cとFreeRTOSConfig.h上書きコピー

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

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

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

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

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

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

MCU:マイコン,PC:パソコンIoTマイコン,ルネサスエレクトロニクス,半導体,ニーズ,製品化サイクル

3月19日発生のルネサスエレクトロニクス半導体工場火災により、半導体不足が更に深刻になりつつあります。MCU開発者向け弊社ブログの2月記事は、半導体に関するものを4件投稿しましたので、半導体とMCU開発者の関係を整理してみました。

半導体の歴史

半導体の歴史(出典:日立ハイテクサイト)
半導体の歴史(出典:日立ハイテクサイト)

日立ハイテクサイト掲載の半導体の歴史を見ると、半導体が人々の生活を実質的に変え始めたのは、1980年以降、今から僅か40~50年前に始まったのが判ります。テレビゲームなどがMCU開発者数を急増させ、同時に開発環境の高速・高度化も必要となりPCやRAMも発展しました。

数学、物理学、化学などに比べると半導体の歴史は浅いのですが、これら学問を基礎として急激に発展します。そして、その原動力は、顧客ニーズの実現です。

半導体集積チップ製造とルネサス工場火事

顧客ニーズをかなえる第一歩が、より集積度を向上した半導体集積チップの製造です。より小さく低消費電力で高速な最先端半導体チップが求められ、これを製造できる最先端ファウンドリーが世界で数社しなないため半導体不足が発生します(関連投稿:2月5日、開発者向けMCU生産技術の現状)。

火災発生のルネサス工場は最先端半導体ではないものの、自動車MCU関連が多く「1か月以内の再生産開始を目指す」発表も危惧されています。

ルネサス火災の影響を受ける半導体製品(出典:ルネサス発表)
ルネサス火災の影響を受ける半導体製品(出典:ルネサス発表)

自動車を運転する半導体

数年毎にモデルチェンジする自動車は、半導体のショールームです。例えば、新車で目立つデイライトとウインカーを兼ねるライト制御やサイドブラインドモニターなどの運転支援機能は、半導体の機能高度化により実現されます。他社差別化に、半導体が提供する機能が大きく寄与する訳です。

自動運転が実現すると、自動車を運転するのは人ではなく半導体です。つまり、顧客シェアを決めるのは、半導体だとも言えます。

最先端半導体の供給が滞れば、現状の半導体に機能を押込んででもシェアアップを目指すのはどの会社も同じです。需要(ニーズ)と供給(製造)、調達価格が、市場に出回る半導体チップを決めます。自動車半導体の供給不足は、自動車産業だけに留まらず産業・インフラ・IoTなど全てに影響を与えるのは自明の理です。

半導体とMCU開発者

あくなき顧客ニーズを、ソフトウェアやハードウェアに変換し半導体に実装するのが、我々開発者です。実装には時間が必要ですので、顧客ニーズと製品提供機能にタイムラグが生じます。このタイムラグを少なくするために、製品化サイクルはどんどん短くなります。

ニーズを満たす製品提供タイミングは、重要です。僅か1か月のターゲットMCU供給遅れでも、製品化は1ヶ月遅れでは済まず、売れない製品となります。

一旦高機能化した半導体を使うと、たとえ価格を下げても元に戻ることを顧客は好みません。常に最新製品を求めるのが顧客です。開発者が高速・高性能なPCを使った開発環境を味わうと、従来PC環境に戻れないのと同じです。

歴史が示すように「半導体ビジネスは、顧客ニーズを満たす半導体が、タイミング良く供給されて初めて成り立ち、短い製品化サイクルに苦労するMCU開発者が報われる」ものです。

世界的半導体不足や今回の火災が、我々MCU開発者に与える影響が少ないことを祈るのみです。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M23コア,Cortex-M4コアARMマイコン,Cortex-M0+,IoTマイコン,Cortex-M4,TrustZone,プロトタイプ,Cortex-M33,STM32U5

STマイクロエレクトロニクス2021年2月25日発表の先端性能と超低消費電力動作両立のSTM32U5を紹介し、STのIoT MCU開発動向をセキュリティ、MCUコア、製造プロセスの観点から分析しました。

先端性能と超低消費電力動作のSTM32U5

STM32U5ベンチマーク(出典:公式ブログ)
STM32U5ベンチマーク(出典:公式ブログ)

公式ブログから抜粋したSTM32U5のベンチマークです。従来の超低消費電力MCU:STM32L0~L4+シリーズと、Cortex-M33コア搭載STM32L5、今回発表のSTM32U5をメモリサイズとパフォーマンスで比較しています。

STM32U5は、従来Cortex-M0+/M3/M4比、Cortex-M33搭載により後述のセキュリティ先端性能と、従来Cortex-M33搭載STM32L5比、230DMIPS/160MHzと大幅向上した超低消費電力動作の両立が判ります。STM32U5の詳細はリンク先を参照ください。

本稿はこの最新STM32U5情報を基に、STのIoT MCU開発動向を、セキュリティ、MCUコア、製造プロセスの3つの観点から分析します。

セキュリティ

STM32マイコンセキュリティ機能一覧(出典:ウェビナー資料)
STM32マイコンセキュリティ機能一覧(出典:ウェビナー資料)

昨年10月27日ウェビナー資料:ARM TrustZone対応マイコンによるIoTセキュリティのP17に示されたSTM32マイコンセキュリティ機能一覧です。セキュリティ先端性能のTrustZoneは、Cortex-M33コアに実装されています。

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

今回の超低消費電力STM32U5発表前なのでSTM32L5のみ掲載されていますが、STM32U5もL5と同じセキュリティ機能です。STM32WLは、後述するワイヤレス(LoRaWAN対応)機能強化MCUです。

この表から、後述する最新メインストリーム(汎用)STM32G0/G4も、STM32U5/L5と同じセキュリティ機能を実装済みで、STM32U5との差分はTrustZone、PKA、RSSなど一部であることも判ります。

STM32U5のSTM32L5比大幅に動作周波数向上と低消費電力化が進んだ背景は、セキュリティ機能に対するより高い処理能力と40nm製造プロセスにあることが2月25日発表内容から判ります。

STM32ファミリMCUコア

STM32ファミリMCUコア(出典:STサイトに加筆)
STM32ファミリMCUコア(出典:STサイトに加筆)

STM32ファミリMCUコアは、ハイパフォーマンス/メインストリーム(汎用)/超低消費電力/ワイヤレスの4つにカテゴライズされます。前章のSTM32WLがワイヤレス、STM32U5/L5は超低消費電力です(STM32U5は加筆)。

STM32WLとSTM32WBの詳細は、コチラの関連投稿をご覧ください。

STM32U5と同様、従来の120nmから70nmへ製造プロセスを微細化して性能向上した最新メインストリームが、STM32G0/G4です。

新しいSTM32G0/G4は、従来汎用STM32F0/F1/F3とソフトウェア互換性があり、設計年が新しいにも係わらずデバイス価格は同程度です。従来メインストリームのより高い処理能力と低電力動作の顧客ニーズが反映された結果が、最新メインストリームSTM32G0/G4と言えるでしょう。

製造プロセス

製造プロセスの微細化は、そのままの設計でも動作周波数向上と低電力消費、デバイス価格低減に大きく寄与します。そこで、微細化時には、急変するIoT顧客ニーズを満たす機能や性能を従来デバイスへ盛込んで新デバイスを再設計します。STM32U5やSTM32G0/G4がその例です。

MCU開発者は、従来デバイスで開発するよりも製造プロセスを微細化した最新デバイスで対応する方が、より簡単に顧客ニーズを満たせる訳です。

関連投稿:開発者向けMCU生産技術の現状

まとめ

セキュリティ、MCUコア、製造プロセスのそれぞれを進化させた最新のIoT MCUデバイスが、次々に発表されます。開発者には、使い慣れた従来デバイスに拘らず、顧客ニーズを反映した最新デバイスでの開発をお勧めします。

また、短時間で最新デバイスを活用し製品化する方法として、最新メインストリーム(汎用)デバイスSTM32G0/G4を使ったプロトタイプ開発もお勧めします。

最新メインストリーム(汎用)プロトタイプ開発イメージ
最新メインストリーム(汎用)プロトタイプ開発イメージ

前章までで示したように最新メインストリームSTM32G0/G4は、他カテゴリデバイスの機能・性能を広くカバーしています。メインストリームプロトタイプ開発資産は、そのまま最新の他カテゴリデバイスへも流用できます。

従って、他カテゴリデバイスの特徴部分(セキュリティ、超低消費電力動作やワイヤレス)のみに注力した差分開発ができ、結果として短期製品化ができる訳です。

ちなみに、プロトタイプ開発に適したSTM32G0テンプレートは、コチラで販売中、FreeRTOS対応のSTM32G4アプリケーションテンプレートは、6E目標に開発中です。

あとがき:文字伝達

ソフトウェア開発者ならソースコード、ハードウェア開発者なら回路図が、最も直接的・正確に技術内容を使える手段です。文字は、記述者の理解を変換して伝える間接的手段です。両者に違い(文字化ノイズ)が生じるのは、やむを得ないと思います。

報ステのTSMCのニュースに頭の抱えてしまった”、“TSMCは日本で何をしようとしているのか“からも分かるように、マスメディアは文字や画像で情報を伝えます。受けての我々開発者は、これらノイズを含むと思われるマスメディア情報を、自分の頭で分析・処理し、理解する必要があります。

と言うわけで本稿も、筆者が文字化ノイズを付けて分析した例です……、という言い訳でした😅。

MCU:マイコン,Kinetisマイコン,STM32マイコン,Cortex-M4コアテンプレート,アプリケーション,IoTマイコン,mbed OS,FreeRTOS,Amazon Web Service,Azure,μITRON

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

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

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利用方法、③クラウド接続例など盛りだくさんの内容です。

  1. FreeRTOS基礎知識で、セマフォなどのFreeRTOS関連技術やタクス分割、ユーザタスクプライオリティ、RAM使用量増加などが理解できますが、サンプルコード以外の具体的なアプリケーションでもFreeRTOSを動作させたいと欲求不満になります。
  2. FreeRTOSのIDE利用時、特にコード生成ツールをIDEと併用する場合、①で使ったFreeRTOSサンプルソースコードに、更にベアメタル開発が前提のコード生成ツール出力コードも加わるため、追加分がFreeRTOS理解の邪魔になります。
  3. 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に変る)
ベアメタル開発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へお寄せください。

MCU:マイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアIoTマイコン,ADC,温度,非接触型体温計,放射温度計

COVID-19の影響で、どこの入口でも見かける非接触型体温計は、遠赤外線センサとLCD温度表示で1000円台から購入できます。一方で、「体温計ではありません」と明記した放射温度計も見た目は同じですが、価格は2倍程度違います。

同じ温度センシング機器でも、価格が異なる理由を探ります。

温度センシング設計ガイド

エンジニアのための温度センシング設計ガイド
エンジニアのための温度センシング設計ガイド

アナログセンサの老舗、Texas Instrumentsのホームページから“エンジニア向け温度センシング設計ガイド”が無料でダウンロードできます。体温、システム温度、周囲温度、液体温度の4種類の温度センシング設計上の課題とその解決方法、センサ利用のアナログデジタル変換(ADC)基礎知識が記載されています。

主にハードウェア設計ガイドですが、MCUソフトウェア開発者も、各種センサ特徴、線形性、第7章の温度補償などが参考になると思います。

温度検出テクノロジーの比較(出典:エンジニアのための温度センシングガイド)
温度検出テクノロジーの比較(出典:エンジニアのための温度センシングガイド)

価格と利益

ビジネスは、利益の上に成立します。低価格でも大量に開発機器が売れれば利益も増えます。機器の価格は、様々なパラメタから成る関数ですが、ここではごく単純化し下式と仮定します。

価格=f(実装機能、想定利用者(≒販売数量))

同じ温度センシング機器でも価格が異なるのは、実装機能が異なるからです。

そこで、TI温度センシング設計ガイド第4章、体温監視から課題と解決方法をピックアップします。

実装機能と想定利用者

想定利用者を疾患患者やアスリートとすると、国際標準に準拠した医療体温計要件である校正後、精度±0.1℃以内、35.8℃~41.0℃の読取りと表示が必要です。但し、アプリケーションの温度読取り間隔は、電池節約のため10秒~60秒でも十分です。

これら機能を非接触型体温計へそのまま実装すると、開発に時間がかかるだけでなく、価格も上がるのは当然です。

CODIV-19の現状では、入口対象者の多くはコロナ患者ではない可能性が高いので、医療体温計レベルの要件は不要でしょう。また、計測機器に必須の測定値校正処理も、一般向けには無理な作業です。

このように、機器使用者/利用者を限定すれば、開発機器への実装機能も絞ることができます。

例えば、電源投入時にのみセンサ校正をソフトウェアで行い、温度読取り間隔は数秒以内に早くし、販売価格を2000円前後に目標設定すれば、一般向け非接触型体温計としてベストセラーになるかもしれません。

開発速度

目標設定が適切でも、開発が遅れれば先行他社に利益を取られます。早く開発できるスキルは、日頃の自己鍛錬が必要です。最新の開発手法やその試行も、通常の開発と並行して行うとスキルに磨きがかかります。

弊社マイコンテンプレートは、複数の公式サンプルソフトウェア流用・活用が容易で、アプリケーションの早期開発ができるなど、自己鍛錬にも適しています。

まとめ

Texas Instrumentsの温度センシング設計ガイドを基に、非接触型体温計と放射温度計の機器価格差は、ADC実装機能、想定使用者が異なるためと推測しました。利益を得るには、開発速度の向上努力も重要です。

ソフトウェアとハードウェアのインタフェースさえ解れば機器開発は可能です。しかし、ADCは、IoT MCUの最重要技術です。ソフト/ハードの垣根を越えた知識や理解が、結局は利益を生む機器開発に繋がることを言いたかった訳です。