カテゴリー: LPCマイコン

NXP社のLPCマイコンに関する情報、Tipsなどをまとめています。

LPCXpresso54114 150MHz動作設定方法

WithHappy

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

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開発案

WithHappy

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詳細

WithHappy

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

FreeRTOS新規プロジェクト作成方法からアプリケーションテンプレートまで

WithHappy

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

最初から全てのドライバをベースプロジェクトへ追加しておくのも１つの方法ですが、弊社は、必須ドライバでアプリケーションを開発し、追加が必要な時には、再度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の２ソースコードさえ読めば、提供処理が判るように全てのサンプルプロジェクトが作成されています。
※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かは、お好みで選択してください。

IoT MCUとAI

WithHappy

ARM Cortex-Mコア利用のIoT MCU現状と、次のムーア則を牽引すると言われるAI（人工知能）の関係についてまとめました。

Cortex-Mコア、IoT/組込みデバイス主要ポジション堅持

ARMベースチップ累計出荷個数は1,800億個以上（出展：ニュースルーム、February 16, 2021）
ARMベースチップ累計出荷個数は1,800億個以上（出展：ニュースルーム、February 16, 2021）

2021年2月16日、英）ARM社は、ARMチップの2020年第4半期出荷が過去最高の67憶個、累計出荷個数1800憶個以上、Cortex-Mチップも4半期最高44憶個出荷で「IoT/組込みデバイス主要ポジション堅持」と発表しました（ニュースルーム）。

Cortex-Mチップの出荷内訳は不明ですが、Cortex-M4やCortex-M0+などコア別の特徴が解るARM社の解説は、コチラにあります（フィルタのProcessorファミリ＞Cortex-Mを選択すると、提供中の全10種Cortex-Mコア解説が読めます）。

筆者は、セキュリティ強化コアCortex-M23/33/35P/55を除く汎用IoT/組込みデバイスでは、Cortex-M4/M0+コア使用数が急増していると思います。

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

半導体ムーア則、牽引はチップレット

ムーアの法則 次なるけん引役は「チップレット」、2021年2月16日、EE Times Japan

次のムーア則を牽引するAI処理能力（出典：AI Hardware Harder Than It Looks）
次のムーア則を牽引するAI処理能力（出典：AI Hardware Harder Than It Looks）

半導体製造プロセスを牽引してきたのは、PCやスマホでした。しかしこれからは、人工知能：AIで急増するAIデータ処理能力を実現するため、レゴブロックのようにコアの各モジュールを歩留まり良く製造・配線するチップレット手法が必要で、このチップレット、つまりAIが次の半導体ムーア則を牽引するというのが記事要旨です。

このチップレット手法で製造したIoT MCUやMPUへ、主にソフトウェアによるAI化は、シンギュラリティ後のAI処理量変化にも柔軟に対応できると思います。

関連投稿：今後30年の半導体市場予測

ルネサス：ハードウェアアクセラレータコアCNN（Convolutional Neural Network）

ルネサスのCNNアクセラレータ（出典：ニュースルーム）
ルネサスのCNNアクセラレータ（出典：ニュースルーム）

2021年2月17日、ルネサスは、世界最高レベルの高性能/電力効率を実現するディープラーニング性能を持つCNNアクセラレータコアを発表しました（ニュースルーム）。これは、主にハードウェアによるAI化の例です。

ADAS実現に向け、性能と消費電力を最適化した車載用コアです。このコアに前章のチップレット手法を使っているかは不明です。3個のCNNと2MB専用メモリの実装により、60.4TOPS（Tera Operations Per Second）処理能力と13.8TOPS/W電力効率を達成しています。

車載で実績を積めば、IoT MCUへも同様のハードウェアアクセラレータが搭載される可能性があります。

まとめ

凸版印刷社は、画像認識AIを活用し、古文書の“くずし字”を解読支援するツールを開発しました（2021年2月16日、IT media）。このように、AIは、半導体技術のムーア則だけでなく、IoT MCUアプリケーションや人間生活に浸透し、牽引しつつあります。

エッジAIをクラウド接続IoT MCUへ実装する理由は、クラウドAI処理とクラウド送信データ量の両方を軽減することが狙いです。AI処理をエッジ側とクラウド側で分担しないと、チップレット手法を用いて制御チップを製造できたとしても、コスト高騰無しに急増するAIビックデータ処理を実現することが不可能だからです。

IoT MCUのエッジAIが、ソフトウェアまたはハードウェアのどちらで処理されるかは判りませんが、必須であることは確実だと思います。実例を挙げると、STマイクロエレクトロニクスは、既にSTM32Cube.AIにより汎用STM32MCUへAI/機械学習ソフトウェアの実装が可能になっています。

今後30年の半導体市場予測とルネサス動向

WithHappy
Runesas

半導体不足が騒がれています。これがCOVID-19の一時的なものか否かが判る下記記事と、最新のルネサスエレクトロニクス動向を関係付け、今後のMCU開発について考えました。

2050年までの半導体市場予測～人類の文明が進歩する限り成長は続く、2021年1月14日、EE Times Japan

今後30年の半導体市場予測

本ブログ読者は、殆どが現役の「日本人」MCU開発者です。定年退職が何歳になるかは分かりませんが、上記記事の2050年まで、つまり、今後30年の半導体市場予測は、在職中のMCU開発を考える上で丁度良い時間の長さです。

予測ですので、大中小のシナリオがあります。我々開発者にも解り易い結論だけをピックアップすると、概ね下記です。

  • 今後、先進国と新興国中間層人口は、COVID-19で人類滅亡しない限りそれぞれ5億人/10年で増加し、2050年に先進国が30億人、新興国中間層が40億人、貧困層が20～30億人の人口ピラミッド構成へ変遷
  • 1人年間の半導体消費量は、先進国が150ドル、新興国中間層が75ドル
  • 2050年の半導体市場は、2010年比2.5倍の7500憶ドルへ成長

ルネサス動向

英）Dialog買収、車載半導体改良「AI性能を4倍に」など、SoCアナログ機能増強、ADAS実現やIoTに向けた動きが、2021年になってからのルネサス最新動向です。

これら動向の結果が出るまでには、年単位の時間が必要です。しかし、前章の2050年半導体市場2010年比2.5倍へ向けての行動の1つとすると、なぜ今か（！？）という疑問に対して、理解できます。

2倍化MCU開発

2倍化MCU開発

MCUも半導体の1つです。半導体市場が増えれば、それらを制御するMCU量も増えます。2010年比2.5倍なら、現在の2倍程度MCU開発も増えると思います。

従来と同じ人員と開発方法では、量が2倍になれば、2乗の4倍の労力が必要になります。新しい手法やその効率化なども導入する必要がありそうです。ルネサス同様、今スグに着手しなければ乗り（登り）遅れます。

使用した半導体の貴金属部分はリサイクルされますが、搭載ソフトウェアやハードウェアパターンは回収されずに消費されます。開発物の資産化、最新プロセスで大容量Flash搭載の新開発MCU、新開発手法にスグに対応できるMCU開発者が生き残るかもしれません。

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

MCU利用者

先進国だけでなく、新な対象として新興国中間層へもMCU利用者が広がります。新興国中間層は、先進国よりも10億人も多い予想で、1人当たりはより低コスト半導体（＝MCU開発）が求められます。

この新興国中間層向けのMCUアプリケーションを検討するのも良いかもしれません。

2045年のシンギュラリティ

Singularity：和訳（技術的特異点）は、人類に代わって人工知能：AIが文明進歩の主役になることです。

最初の記事にも、2045年と言われるシンギュラリティは、一層半導体市場を広げる可能性があるとしています。IoT MCUにもエッジAIが組込まれるなど、今後のMCU開発もAI化は必然です。



開発者向けMCU生産技術の現状

WithHappy
先端半導体の供給不足
先端半導体の供給不足

COVIC-19の影響で自動車、ゲーム機、PC、5Gスマホに搭載される先端半導体の供給不足が発生中です。自動車は生産調整、ゲーム機も品薄のため販売中止のニュースが流れています。一方で、任天堂やSonyは、ゲーム機好調で、業績上方修正も発表されました。

本稿は、これら先端半導体とMCUに使っている半導体の違いを、筆者を含めたマイコン開発者向けにまとめました。

先端半導体供給不足

AppleやQualcommなどの半導体ベンダの多くは、設計・開発は行うものの、生産は台湾TSMCやUMCなど世界に数社しかない先端半導体受託生産会社（ファウンドリー）へ製造依頼するファブレス企業です。このファウンドリーの先端半導体生産量がボトルネックとなり供給不足が発生しています。

需要に追いつくよう生産設備も増設中ですが、スグには対応できません。その結果、価格競争が起こり、ゲーム機など高パフォーマンスで高価格でもＯＫなデバイスが優先、一方、コスト要求の強い自動車向けデバイスなどは後回しになった結果が、最初のニュースの背景です。

MCU半導体と先端半導体の差

半導体の製造や生産技術は、ムーアの法則に則り、年々微細化が進みます。これは、MCU半導体でも先端半導体でも同じです。違いは、「製造プロセスの世代」と「大容量フラッシュ搭載の有無」です。

最先端半導体の微細化技術は、28nm→14nm→7nmと製造プロセス世代が進み現在5nmなのに対し、MCU半導体は、現在28nmの1つ手前、40nmです。

※微細化の指標は、いかに細いロジック配線を実現できるかで表されnm：nanometerは、1 nm = 0.001 µm = 0.000001 mm：10億分の１メートル。

MCU半導体の微細化が遅れる理由は、MCUデバイスには簡単に微細化できない大容量Flashメモリの内蔵が必須だからです。

つまり、我々が開発するアプリケーションは全てMCUに内蔵される訳で、ここがPCやゲーム機の外付けメモリ＋キャッシュ内蔵の制御系と根本的に異なる点です。

最新MCU微細化技術

上記の難しい大容量Flash微細化にも、技術革新が起きつつあります。詳細を知りたい方は、世界最小のメモリセルで最先端マイコンの低価格化を牽引する相変化メモリの記事を参照してください。

IoT MCU開発には、エッジAIや無線通信、高度セキュリティ、OTA：Over The Air更新など従来MCUに無い多くのIoT機能追加が必要です。これら機能実装には、更なる大容量Flash搭載が必須です。

IoT MCUの将来
IoT MCUの将来

大容量Flashの低価格実装と製造プロセスの世代が進めば、MCUデバイスの開発アプリケーション適用幅は大きくなると筆者は思います。つまり、より汎用化すると思います。

現在のMCUは、アプリケーション毎に内蔵周辺回路やFlash/RAM容量が異なるなど多品種でデバイス選択時、開発者を悩まします。しかし、近い将来、IoT MCUデバイス選択に開発者が悩むことも無くなるかもしれません。

関連投稿：無線STM32WBと汎用STM32G4比較の6章

MCU大手ベンダは自社製造中

NXP/ST/Renesas などの大手MCUベンダもファウンドリーを利用しますが、どこも自社工場でも製造を行っています。各社の会社紹介パンフレットには、必ず自社製造拠点の図がありますし、販売後10年間のデバイス供給保証も謳っています。

ARM社提供のCortex-Mコア設計図は同じでも、それを活かす実装設計・開発・製造がベンダ毎に異なるので他社差別化ができる訳です。

また、これらMCUベンダは、自社デバイスと並行して自動車向けデバイスの設計・開発・製造も行っています。ADASやMCU微細化技術の進化、ファウンドリーの供給不足状況などが、MCUベンダ各社に今後どのように影響するかは注目して行きたいと思います。

関連投稿：5G、Wi-Fi6、NXP、STマイクロエレクトロニクスの3章：NXP対応

まとめ

  • MCU半導体と先端半導体には、製造プロセス世代と大容量Flash搭載有無に差がある
  • 現状のMCU半導体は、大容量Flash搭載の40nmプロセス、先端半導体は、5nmプロセス
  • IoT MCUの更なる大容量Flash実装に向け、MCU微細化技術革新が起こりつつある
  • 大容量Flash低価格実装と製造プロセス進化によりIoT MCUはより汎用化する
  • COVID-19による先端半導体供給不足がMCU半導体ベンダへ影響するかは、要注目

Blogテーマ変更とMCU開発顧客満足

WithHappy

本Blogテーマを、今週～来週にかけて変更中です。期間中は、画面表示が乱れる可能性もありますがご容赦ください😌。Blogツール：WordPressにご興味が無い方は、最後の章：MCU開発顧客満足をお楽しみください。

オープンソースCMSのWordPressによるBlog投稿

Blogテーマ変更理由

本Blogは、WordPressというオープンソースCMS（Contents Management System）を使って投稿しています。テーマとは、Blog表示の見た目を変える、着せ替え洋服のようなものです。テーマ変更理由は、2つです。

  1. 約2年前に導入されたWordPressの新しいGutenbergエディタ対策
  2. 昨年後期から続くサイトマップトラブル対策

Gutenbergエディタ

従来のWordPress標準エディタは、Classicエディタと呼ばれ、Web版無償Microsoft Wordのようなものです。基本的な文章エディタ機能を提供し、使い方も簡単でした。これに対し、新しく標準となったGutenbergエディタは、ブロック単位の編集・加工を行うなど操作性や使い方が大きく変わりました。

※Gutenbergエディタは、15世紀に活版印刷技術を発明したヨハネス・グーテンベルクにちなんで命名されました。WordPressの記事投稿に際し、活版印刷登場ほどインパクトがあると言うことです。

旧Classicエディタを使い続けたい多くのブロガーのために、標準Gutenbergエディタを無効化し、Classicエディタを復活するプラグインが提供され、筆者もこれを使い続けてきました。

但し、Gutenbergエディタは、毎年改良され機能や使い方も進化、この進化系Gutenbergエディタ対応の新しいテーマも増えてきました。

xmlサイトマップ

xmlサイトマップは、GoogleやYahoo、Bingなどの検索エンジンへ、弊社Blogの投稿内容等を知らせる手段です。

原因不明ですが、昨年後半から投稿数は週一で増やしているにも係わらず、サイトマップの有効ページ数が減り続けています。検索エンジンにマップされなければ、投稿しても読者に発見されず苦労が報われません。

ネット情報によると、プラグイン間の相性など様々な原因がありえますが、解決しません。いわゆるPCとアプリケーションとの相性問題と同じようです。

そこで、1のGutenbergエディタ対策時に、新テーマ導入と同時にプラグインを変える/減らすなどして対処しようと考えました。

Blogテーマ変更結果

今回のBlogテーマ変更の結果、WordPressの新Gutenbergエディタは習得しました。

しかし残念ながら、サイトマップトラブルは、更に悪化しました。プラグイン相性だけでなく、新導入テーマにも関係している可能性もありますが、依然として原因不明です。

算定措置として、Gutenbergエディタと新テーマ利用へ変更し、追加プラグインは最小にします。サイトマップトラブルは、継続検討とします。

MCU開発顧客満足

MCU開発でも課題に対し期待する成果が得られない等は、筆者には日常茶飯事です。費やした時間やコストは、戻ってきませんが、実際にやってみなければ本当は判らない事だらけなのがMCU開発業務です。

MCU開発業務は、以下2点の配慮が必要です。

  1. スケジュール立案時は、マージンを織り込む
  2. 成果に直結しない結果でも、今後に活かす

※織り込んだマージンを使わず成果が出た時は、未消化マージンをリフレッシュ休暇に替えます😁。

今回の対策も、年末年始の予定でした。しかし、新テーマの多さやその理解に時間がかかり、結局マージンを使い果たし1月末実施、そして少ない成果となりました。顧客は、自分自身ですが顧客満足は低いです。

しかし、成果に直結しなくても得た（貴重な！？）結果もある訳です。これを今後に活かす事が、費やした時間やコストを無駄にしない唯一の策で、しかも長い目で見れば、顧客満足にも繋がると信じます😤。

MCU開発は、日々の努力が、即成果に結びつかなくても、将来必ず顧客を満足させる結果・スキルになると自分を信じて続ける心構えが重要です（日本では、周囲になかなか理解してもらえないと思いますが😭、欧米開発者は、これがあたりまえの文化でした）。

2020マイコンテンプレート案件総括

WithHappy

COVID-19パンデミックの2020年も残すところ2週間になりました。2020年の金曜ブログ投稿は本日が最後、次回は2021年1月8日（金）とし休暇に入ります。

※既存マイコンテンプレートは、年中無休、24時間販売中です、いつでもご購入お持ちしております。

2020マイコンテンプレート案件総括

  1. 🔴：Cortex-M4コア利用のマイコンテンプレート開発（2020年内）
  2. 🟡：FRDM-KL25ZとIoT汎用Baseboard利用のKinetis Lテンプレート発売（12月）
  3. 🟢：IoT MCU向け汎用Baseboard開発（10月）
  4. 🟢：STM32FxテンプレートV2発売（5月）
  5. 🟢：STM32G0xテンプレートV2発売（5月）

1のCortex-M4テンプレート開発は、STM32G4のRoot of Trustと、NXP LPCXpresso54114のRTOSサンプル解説で、Cortex-M4テンプレート化には程遠い状況です（赤ステータス）。

2のKinetis Lテンプレート（FRDM-KL25Z、Cortex-M0+/48MHz、Flash:128KB、RAM:16KB）は、添付説明資料作成が未着手です（黄ステータス）。

3のArduinoプロトタイプシールド追加、IoT MCU汎用Baseboardは完成しました（緑ステータス）。

4と5のSTM32FxテンプレートとSTM32G0xテンプレート発売までは、ほぼ順調に進みました（緑ステータス）。

対策としてブログ休暇中に、2のKinetis Lテンプレート完成と、これに伴うHappyTechサイト変更を目標にします。
１のCortex-M4テンプレート開発は、2021年内へ持越します。

ブログ記事高度検索機能（1月8日までの期間限定）

休暇中、ブログ更新はありません。そこで、読者の気になった過去の記事検索が、より高度にできる下記Googleカスタム検索機能を、1月8日までの期間限定で追加します。

上記検索は、WordPressのオリジナル検索（右上のSearch…窓）よりも、記事キーワード検索が高度にできます。少しでもキーワードが閃きましたら、入力してご活用ください。

あとがき

激変の2020年、テンプレート関連以外にも予定どおりに進まなかった案件や、新に発生した問題・課題も多数あります。例年より少し長めの休暇中、これらにも対処したいと考えております。今年のような環境変化に対し、柔軟に対応できる心身へ変えたいです（ヨガが良いかも？ 3日坊主確実ですが…😅）。

本年も、弊社ブログ、HappyTechサイトをご覧いただき、ありがとうございました。
今後も、引き続きよろしくお願いいたします。よいお年をお迎えください。

IoT MCUの無線LAN

WithHappy

IoTに適した無線LANの条件とは？（TechTarget、2020年11月27日）記事を紹介し、IoT MCU関連のプライベート網無線LAN規格を説明します。

IoT向き無線LAN条件と規格

纏まった良い記事なので、一読をお勧めします。

記事を要約すると、IoT向きの無線LANの選定には、3つの検討ポイントがあります。

  1. 省電力性：バッテリーだけで長時間無線LAN通信ができる
  2. 長距離伝送性：アクセスポイント（AP）から1km以上離れる場合がある
  3. 国より異なる利用周波数の空き状態確認

各ポイントを満たす無線LAN規格として下記3つを挙げ特徴を説明しています。

  • IEEE 802.11ah（別名Wi-Fi HaLow）：Target Wake Time（TWT）により通信タイミングを調整しAP通信競合を防ぐと同時にスケジュールタイムまでスリープし電力消費を抑える
  • IEEE 802.11ba：TWTに加えWake-Up Radio省電力機能を利用しAPからの通信要求に対応
  • IEEE 802.11af： 54MHz～698MHz利用で900MHz～1GHzの802.11ah/802.11baより長距離伝送可能
    ※11afは、テレビ用ホワイトスペースのVHF/UHFバンド（54 MHz～790 MHz）利用なので空き状態により耐ノイズ注意

IoT向き無線LANとBluetooth

無線LANには、2.4GHz利用、数m～10m程度の「近距離無線通信規格」：IEEE 802.15.1（別名Bluetooth）もあります。コイン電池で1年以上動作できるなど超省電力動作ですが、低速です。PCやスマートフォンでは、マウス/キーボード/ヘッドホンなどの周辺機器との接続に使われます。

より高速、より長距離（400m程度）、より高スループットを目指し、Bluetooth v4.2、Bluetooth 5などと規格が変化しています。

IoT MCUへの実装は、Bluetooth 5内蔵MCUやBluetooth 5モジュールとMCUを接続する方法があります。

IoT 向き無線LANとPC/スマホ向き無線LAN

2020年12月時点のPC/スマートフォン無線LAN規格が下表です（出展：NTT西日本公式ホームページ）。

規格 周波数帯 最大通信速度
IEEE 802.11b 2.4GHz 11Mbps
IEEE 802.11g 2.4GHz 54Mbps
­­­­IEEE 802.11a 5GHz 54Mbps
IEEE 802.11n 2.4GHz 600Mbps
5GHz
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ad（WiGig） 60GHz 6.8Gbps
IEEE 802.11ax 2.4GHz 9.6Gbps
5GHz

IoT向き無線LANと異なるのは、周波数帯がより高周波の2.4GHz/5GHzを利用する点と、新規格11ac/11ad/11ax、従来規格11b/11g/11a/11n、ともにデータ伝送速度が速い点です。スマホのAPは、家庭や店舗に設置された無線LANルータで、高周波利用のため伝送距離は精々100m程度、60GHzの11adでは10m程度です。公衆網5G高速化に伴い新無線LAN規格：11ac/11ad/11axが普及しつつあります。

動画再生などの利用形態も多いPC/スマホ向き無線LANは、「高速大容量化」が求められます。IoTの「長距離省電力」要求とは、異なる無線LAN規格となっています。

まとめ：IoT MCUプライベート網の無線LAN規格

無線LANアクセスポイントからの伝送距離変化
無線LANアクセスポイントからの伝送距離変化

プライベート網無線LAN規格は、APからの伝送距離により、

  1. 「近距離（10m以下）超省電力」規格（周辺機器向き）：Bluetooth（IEEE 802.15.1）
  2. 「短距離（100m程度）高速大容量」規格（PC/スマホ向き）：IEEE 802.11a/11b/11g/11n/11ac/WiGig（11ad）/11ax
  3. 「長距離（1km以上）省電力」規格（IoT向き）：Wi-Fi HaLow （IEEE 802.11ah）/11.af/11.ba

の3種類があります。

IoT MCUには、最新のBluetooth 5や屋外や1km半径の広い敷地内でも使える長距離省電力規格のWi-Fi HaLowが望まれるようです。

但し、普及済みのPC/スマホ向き無線LAN規格が使えると、屋内の既存PC/スマホ無線LANルータをインターネット空間へのAPに利用でき、常時電力供給も可能なため、低コストIoT MCUを実現する方法になりうると思います。