Cortex-MとRISC-V

NVIDIA買収先で成立見通しが未だに不透明なARM社Cortex-Mと非営利団体運営のRISC-V、両MCUコアの顧客利用動向記事が公開されました(2022年1月14日、ITmedia)。

極簡単に要約すると、ARM顧客の多くが現在NVIDIAと競合関係にあるため、買収成立時、Cortex-M利用の顧客将来製品の代替コア用意(=Plan B)が必要で、代替コアにRISC-Vが急浮上している、という内容です。

ARM顧客とは、エッジAIや車載半導体製品を供給中のMCUベンダ(Renesas、NXP、STマイクロなど)を指します。Plan Bは、代替案と訳されます。これは、実行案Aのトラブル時、Aの次のBが、第2の案という意味です。

半導体業界は常に変化し、これに伴い案A達成に何らトラブルが無くても、その将来性に変化が生じる可能性もあります。“Backup”としてのPlan B必要性を感じた記事です。

オープンアーキテクチャRISC-V

Cortex-M代替として急浮上のRISC-V
Cortex-M代替として急浮上のRISC-V

RISV-Vは、カルフォルニア大学バークレイ校開発のオープンアーキテクチャMCUコアで、Cortex-MのようなCISC(Complex Instruction Set Computer)命令系を、より縮小した命令系(Reduce Instruction Set Computer)へ変え、低電力動作に適すなどの特徴を持ちます。

Cなどの高級言語ソフトウェア開発者にとっては、CISC/RISC差はあまり気になりませんが、コンパイラを開発するMCUベンダにとっては、他社差別化を生む重要なパラメタです。

MCU性能の支配項は、

・MCUコア(CISC or RISC)
・コンパイラ
・製造プロセス(≒最高動作周波数)
・内蔵周辺回路

の4項目で、ARM Cortex-M使用中ベンダなら、MCUコアとコンパイラはARM供給品なので各社共通です。つまり、製造プロセスと内蔵周辺回路でしか他社差別化手段がありません。

NVIDIAがARMを買収した場合、競合他社へのMCUコアやコンパイラ供給に、自社利用品と差を付ける可能性もあります。Cortex-M使用中のMCUベンダ各社が、ARM買収成立を嫌う理由が、これです。

そこで、オープンアーキテクチャでコンパイラ開発自由度も高いRISC-Vコアが、競合他社のCortex-M将来製品コアのPlan Bとして急浮上した訳です。

ARMコアMCU開発で出遅れたRenesasは、早々とRISC-V対応MCU開発を発表しました。NXPやSTマイクロのRISC-Vコア利用は不明ですが、Renesas同様、Plan Bを持っているのは確実です。

我々開発者が、今すぐRISC-V開発を始める必要性は低いと思います。むしろ、Cortex-M代替に、低価格高性能無線機能付きESP-WROOM-32を習得した方が役立つと個人的には思います。RISC-VESP-WROOM-32の関連投稿は、リンク先を参照してください。

MicrosoftのOffice、Windows分離売却可能性

Microsoftが買収を発表した大手ゲーム会社Activision Blizzard
Microsoftが買収を発表した大手ゲーム会社Activision Blizzard

半導体業界の大きな一角を占めるMicrosoftの大手ゲーム会社Activision Blizzard買収ニュースが1月19日発表されました。買収理由は、コチラの記事が示すメタバースです。COVID-19が大きく影響しているコンタクトレス・テクノロジのメタバースは、関連投稿の3章を参照してください。

Microsoft動向で気になるのは、確定内容ではありませんが「OfficeとWindowsを売却すべき」という1月17日発表記事です。Microsoftは営利団体です。Windows 11不具合の多さ、新機能の魅力無さなど、最近のWindowsに対するMicrosoftの力の入れようの低下とも符合します。

OfficeやWindows(特にGUI)は、既に製品完成の域に達しています。手間暇が掛かるDOS-VベースのコンシューマーOS企業と、最新コンタクトレス・テクノロジやAzure、高度セキュリティ投資との親和性も高いパブリッククラウド企業とは、別会社の方が、利用者、投資家にとっても判り易いと思います。

エンタープライズ顧客重視で将来性も高いパブリッククラウド企業地位を、MicrosoftがAmazonやGoogleよりも高めたいなら、足枷の可能性もあるOffice、Windows分離売却も可能性ありと思います。

Plan B評価の違い

M&A:Mergers(合併)and Acquisitions(買収)は、半導体業界では当たり前です。激変する半導体業界のMCUベンダとMicrosoft動向記事を紹介しました。

日本社会では、Plan B評価がまだ低いのですが、MCU開発者として、「個人レベルのPlan B必要性」を感じた記事でした。日本人と外国人上司のPlan B評価の違いは、コチラの記事を参照してください。

組込み開発 基本のキ:RTOS vs. ベアメタル

RTOS vs. BareMetal
RTOS vs. BareMetal

2022年最初の投稿は、RTOSとベアメタルを比較します。RTOSを使わないベアメタルMCU開発者が多いと思いますので、RTOS開発メリット/デメリットをベアメタル側から評価、RTOSデバッグツール紹介とベアメタル開発の意味を考えました。

RTOS目的

Flexible Software Package構成
Flexible Software Package構成

ルネサスRAファミリのFlexible Software Package構成です。左上Azure RTOSやFreeRTOSの中に、ConnectivityやUSBがあります。これらMCU共有資源を管理するシステムソフトウェアがOSで、PCのWindowsやMac、Linuxと機能的には同じです。

Real-Time性が必要な組込み用OSをRTOSと呼び、FreeRTOSやAzure RTOSが代表的です。これは、IoT MCU接続先が、Amazon Web Services(AWS)クラウドならばFreeRTOSライブラリ、Microsoft AzureクラウドならAzure RTOSライブラリ(図のConnectivity)利用が前提だからです。

※2021年のIoTクラウドシェアは、コチラの関連投稿からAWS>Azure>GCPの順です。

RAファミリに限らず、クラウド接続のIoT MCUは、これらRTOSライブラリを使ったRTOS開発になります。

RTOSメリット/デメリット

例えば、ベアメタルでUSB制御を自作する場合は、USB 2.0/3.0などの種類や速度に応じた作り分けが必要です。ライブラリがあるRTOSなら、USBポートへの入出力記述だけで利用可能です。RTOSが共有資源ハードウェア差を吸収し、アプリケーションが使い易いAPIを提供するからです。

RTOSの資源管理とは、MCUコア/Flash/RAM/周辺回路/セキュリティなどの共有資源を、アプリケーション側から隠蔽(≒ブラックボックス化)すること、とも言えます。

RTOSアプリケーションは、複数タスク(スレッドと呼ぶ場合もあり)から構成され、タスク間の優先制御もRTOSが行います。開発者は、単体処理タスクを複数開発し、それらを組み合わせてアプリケーションを構成します。RTOSアプリケーション例が下図、灰色が開発部分、コチラが関連投稿です。

Data flow diagram for a smart thermostat(出展:JACOB'S Blog)
Data flow diagram for a smart thermostat(出展:JACOB’S Blog)

RTOS利用メリット/デメリットをまとめます。

メリットは、

・RTOSライブラリ利用により共有資源活用タスク開発が容易
・移植性の高いタスク、RTOSアプリケーション開発が可能
・多人数開発に向いている

デメリットは、

・複数タスク分割や優先順位設定など、ベアメタルと異なる作り方が必要
・共有資源、特にRAM使用量がタスク数に応じて増える
・RTOS自身にもバグの可能性がある

簡単に言うと、RTOSとベアメタルは、「開発作法が異なり」ます。

ソフトウェア開発者は、RTOS利用と引換えに、自己流ベアメタル作法を、RTOS作法へ変えることが求められます。RTOS作法は、標準的なので多人数での共同開発が可能です。もちろん、ベアメタルよりもオーバーヘッドは増えます。このため、RTOS利用に相応しい十分なMCUコア能力も必要です。

RTOSタスク開発 vs. ベアメタルアプリケーション開発

最も効果的なRTOS作法の習得は、評価ボードを使って実際にRTOSタスク開発をすることです。弊社FreeRTOSアプリケーションテンプレートは、この例です。

それでも、RTOSタスク開発作法を文章で記述すると、以下のようになります。

開発対象がアプリケーションからタスク(スレッド)へ変わることが、ベアメタルとの一番の違いです。Windowsタスクバーにあるフィルダ表示や、ペイントなどと同様、タスクは、単機能の小さいアプリケーションとも言えます。

このタスクを複数開発し、複数タスクを使ってRTOSアプリケーションを開発します。タスクには、それぞれ優先順位があり、他のタスクとの相対順位で実行タスクがRTOSにより決まります。タスクの状態遷移が、RTOSへの備え:第2回、タスク管理で示した下図です。

FreeRTOS Task States
FreeRTOS Task States

ベアメタルアプリケーションとは異なり、優先順位に応じてタスクが実行(Running)され、その実行も、定期的に実行可能状態(Ready)や待ち状態(Suspended)、停止状態(Blocked)へRTOSが変えます。これは、リアルタイムかつマルチタスク処理が、RTOSの役目だからです。遷移間隔などは、RTOS動作パラメタが決めます。

ベアメタル開発は、開発者が記述した通りに処理が実行されますが、RTOS開発のタスク実行は、RTOS任せです。RTOS開発難易度の上がる点が、ここです。

一般的なIoT MCUは、シングルコアですので、実行タスク数は1個、多くの他タスクは、Not Running(super state)状態です。RTOSがタスクを実行/停止/復活させるため、スタックやRAM使用量が急増します。

これら文章を、頭の中だけで理解できる開発者は、天才でしょう。やはり、実際にRTOSタスクを開発し、頭の中と実動作の一致/不一致、タスク優先順位やRTOS動作パラメタ変更結果の評価を繰返すことで、RTOS理解ができると凡人筆者は思います。

ベアメタル開発者が手早くRTOSを理解するには、既にデバッグ済みの複数RTOSタスク活用が便利で、FreeRTOSアプリケーションテンプレートは、この要求を満たしています。概要は、リンク先から無料ダウンロードできます。

文章でまとめたFreeRTOS解説が、コチラの弊社専用ページにあります。また、本ブログ検索窓にFreeRTOSと入力すると、タスク開発例などが参照できます。

RTOSデバッグツール

percepio tracealyzer
percepio tracealyzer

さて、RTOS作法に則ってタスク開発し、RTOS動作パラメタも適切に設定しても、思ったように開発タスクが動作しない時は、ブラックボックスRTOS自身のバグを疑う開発者も多いでしょう。RTOSのバグ可能性もありえます。

この疑問に対して強力にRTOS動作を解析できるFreeRTOSデバッグツールがあります。資料が無料でダウンロードできますので、紹介します。

※このツールを使うまでもなく、弊社FreeRTOSアプリケーションテンプレートは、正常動作を確認済みです。

まとめ:RTOS vs. ベアメタル

IoT MCUのクラウド接続 → 接続クラウド先のRTOSライブラリ必要 → RTOSライブラリ利用のRTOS開発が必要、という関係です。

RTOS開発は、ベアメタルと開発作法が異なる複数タスク開発です。タスクは、優先順位に応じてRTOSがMCU処理を割当てます。また、MCU共有資源がRTOSアプリケーションから隠蔽されるため、移植性が高く多人数での大規模開発にも向いています。

一方で、RTOSオーバーヘッドのため、ベアメタルよりも高いMCU能力が必要です。

シングルコアMCUでは、RTOSとベアメタルのハイブリッド開発は困難です。開発者がRTOSを利用するなら、慣れたベアメタル開発から、RTOSタスク開発への移行が必要です。

ベアメタル開発経験者が、効果的にRTOSタスク開発を習得するには、評価ボードと複数RTOSタスクが実装済みの弊社RTOSアプリケーションテンプレートの活用をお勧めします。

ベアメタル開発意味

RTOSのタスク処理待ち(セマフォ/Queue)を使うと、ベアメタルよりも排他/同期制御が簡単に記述できます。それでも、全てのMCU開発がRTOSへ移行することは無いと思います。様々なセンサデータをAD変換するエッジMCUは、ベアメタル開発、エッジMCUを複数個束ねクラウドへ接続するIoT MCUは、RTOS開発などがその例です。

MCU開発の基本は、やはりRTOS無しの「ベアメタル開発」です。

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

ベアメタル開発スキルを基にRTOSを利用してこそ、RTOSメリットを活かしたタスクやアプリケーション開発ができます。共有資源ブラックボック化、多人数開発のReal-Time OSは、「ベアメタル開発の補完」が起源です。

PC OSとは全く逆のこの生い立ちを理解していないと、効果的なRTOS利用はできません。近年MCU性能向上は著しいのですが、向上分をRTOSだけに振り分けられる程余裕はなく、IoTセキュリティなどへも配分する必要があります。

この難しい配分やRTOS起因トラブルを解決するのが、ベアメタル開発スキルです。弊社マイコンテンプレートは、主要ベンダのベアメタル開発テンプレートも販売中、概要ダウンロード可能です。

組込み開発 基本のキ:バックナンバー

2022年最初の投稿に、筆者にしては長文すぎる(!?)のRTOS vs. ベアメタルを投稿したのは、今年以降、RTOS開発が急速に普及する可能性があるからです。

クラウド接続からRTOS必要性を示しましたが、セキュリティなど高度化・大規模化するIoT MCU開発には、移植性の高さや多人数開発のRTOSメリットが効いてきます。

また、半導体不足が落ち着けば、RTOS向き高性能MCUの新しいデバイスが、各ベンダから一気に発売される可能性もあります。スマホ → 車載 → IoT MCUが、半導体製造トレンドです。

※現状のMCUコア関連投稿が下記です。
Cortex-M33とCortex-M0+/M4の差分
Cortex-M0からCortex-M0+変化
Cortex-M0/M0+/M3比較とコア選択

IoT MCU開発が複雑化、高度化すればする程、前章のベアメタル開発や、組込み開発の基礎技術:基本のキの把握が、開発者にとって益々重要になります。

組込み開発、基本のキ:バックナンバーを示します。年頭、基本を再確認するのはいかがでしょう?
組込み開発 基本のキ:組込み処理
組込み開発 基本のキ:IoT MCUセキュリティ



IoVとIoT

IoV:Internet of VehiclesやV2X:Vehicles-to-Everything通信により、車載半導体チップとソフトウェア需要が指数関数的に増加、ユーザの自動車選択基準が、エンジンなどのメカから車載ソフトウェアへ移行しつつある、という記事がEE Timesに記載されました。

これらIoV状況が、IoTへ与える影響について考えてみました。

IoVとIoT

IoVでユーザ選択基準が車載ソフトウェアへ変化
IoVでユーザ選択基準が車載ソフトウェアへ変化

車のカタログから、エンジン特性や足回りのメカ説明が消え、スマホ連動性や運転支援など車載ソフトウェアによるサービスの説明に変ったのはここ数年です。記事によると、車の新しいユーザ選択基準になりつつあるカーエレクトロニクスが、半導体業界にとってはスマホ以来の最大チャンスだそうです。

また、「CASE」で車載半導体はどう変わるのか(2021年9月15日、EE Times Japan)でも、自動運転と電動化が今後の車載半導体動向を左右すると結論付けています。
※CASE:Connected(通信機能)、Autonomous(自動運転)、Shared&Services(共有化/サービス化)、Electric(電動化)

年々向上するユーザのソフトウェア指向を満たす車載IoV業界、COVID-19の影響で停滞気味の民生IoT業界とは雲泥の差です。

車載半導体需要予測は初めの記事数値を参照して頂くとして、両記事のポイントは、ソフトウェア差別化や付加価値追加には、カスタムチップまたは、IP(Intellectual Property)などの組込みハードウェアが効果的という点です。これらIPには、セキュリティやエッジAIなどIoTへ流用できるものが数多くあります。

従って、IoVは、結果としてIoTも牽引すると思います。

但し、世界的半導体不足が続く状況では、優先度、調達コスト、多くの数量が確実に見込めるIoVが優勢、IoTはこの影響で、しばらくチップ供給不足や停滞が続くでしょう。

停滞気味のIoT側開発者として今できることは、IoV同様、IoTソフトウェア差別化に備えることだと思います。

IoT MCUのTrustZone、SOTB

IoTの観点から、IoTソフトウェア差別化や付加価値追加のための組込みIPと言えば、ARM TrustZone内蔵Cortex-M33コア、ルネサスの新製造プロセスSOTB:Silicon On Thin Buried Oxideなどが相当します。

アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)
アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)

例えば、TrustZoneが、高いセキュリティ効果を発揮するのはご存知の通りですし、SOTB製Cortex-M0+搭載ルネサスREファミリは、超低スタンバイ電流により太陽光発電環境などのエナジーハーベストでも電池交換不要を実現するなどです。

SOTBは、超低消費電力動作と高速動作を両立する革新的製造プロセスです。全てのルネサスMCUへ採用すれば強力な差別化技術になると思いますが、今のところ出し惜しみなのか(!?)戦略的なのか、REファミリにのみ採用中です。

一見、ASSP:Application Specific Standard Produceのようですが、これら差別化技術は、汎用MCUに採用された時に最も効果を発揮します。

従来のエッジMCUでの単純なアナログデジタル変換に加え、セキュリティや超低電力動作などのIoT化に伴う付加機能がIoT MCUには必須です。IoT付加機能内蔵MCUが、汎用IoT MCUになります。

IoT開発者は、これらIoT付加技術を今のうちに習得しておくことが必要です。

IoVとIoTの最も大きな差は、車載と民生半導体の電源仕様でしょう。IoVは、EV(Electric Vehicle)のモータ高出力要求に伴いバッテリーが12V供給から48Vへ高電圧化しつつあり、万一の耐圧やフェイルセーフが求められます。IoTは、低電圧(≦3.3V)電源で低圧化しつつあります。

RA/REテンプレート構想

残念ながらSOTB製REファミリ評価ボードは、まだ値段が高く、個人レベルでは手が出しにくい状況です。そこで、SOTBプロセスではありませんが、REファミリとソフトウェア互換性があると思われるCortex-M33コア搭載ルネサスRAファミリを、弊社テンプレート対象にと考えています。

RAファミリは、TrustZoneでIoTセキュリティへ対応しています。また、9月22日発売のRAファミリRA4E1グループの評価ボード:RA4E1 Fast Prototype Boardは、20米ドル台と低価格です。ルネサス独自コアではないため、コンパイラFlash容量制限もありません。

FPB-RA4E1 Fast Prototyping Board(出典:クイックスタートガイド)
FPB-RA4E1 Fast Prototyping Board(出典:クイックスタートガイド)

RL78/G1xテンプレートから新しいルネサスMCUをテンプレート対象に出来なかった理由の1つが、この容量制限です。ARMコア他社同様、GNUまたはARM Compiler V6が、e2 studioでRAファミリ開発に無償で使えます。

今のところRAテンプレートは、REへも使えると考えています。ARMコア差は、CMSIS:Cortex Microcontroller System Interface Standard やHAL:Hardware Abstraction Layerで吸収できるハズだからです。

ADC、SW、LED、UART(VCOM)などのIoT MCU基本動作をRA/REテンプレート共通部分でサポートし、TrustZoneや超低電力動作などRA/RE特徴を活かす部分は、共通部分へ特徴サンプルコードを追加する方法で実現できれば嬉しいと考えています。構想段階ですが、詳細は今後投稿します。

PSoC CreatorがModusToolboxへ

米)Cypress(サイプレス)は、2020年4月、独)Infineon(インフィニオン)に買収され子会社になりました。買収の影響かは不明ですが、お気に入りCypress IDEのPSoC Creatorが、ModusToolboxへ移行しつつあります。ModusToolbox v2.3.0.4276(以下ModusToolbox)の特徴、PSoC Creatorからどう変わったのかを示します。

About Eclipse IDE for ModusToolbox
About Eclipse IDE for ModusToolbox

Windows/Mac/LinuxマルチOS、GitHub

PSoC Creator(以下Creator)は、Windowsのみで動作するCypress独自IDEです。ModusToolboxは、Eclipse IDEをベースとし、Windows/Mac/LinuxマルチOS対応となりました。また、最新サンプルコードやライブラリは、GitHub経由でオンライン提供へと変わりました。

ModusToolbox対応PSoC 4/6デバイス

ModusToolbox対応中のPSoC 4/6評価ボードとデバイスを抜粋したのが下図です(全評価ボードとデバイスは、リリースノートを参照してください)。

ModusToolbox 2.3のPSoC 4/6対応デバイス
ModusToolbox 2.3のPSoC 4/6対応デバイス

弊社PSoC 4000S/4100S/4100PSテンプレートで使ったCY8CKIT-145-40XX、PSoC 6 FreeRTOSテンプレートで使用予定のCY8CPROTO-063-BLEともに、ModusToolbox v2.3で開発できます(PSoC 6 FreeRTOSテンプレートは、前稿参照)。前バージョン2.2から新たにPSoC 4が追加されました。

AN228571:「ModusToolboxソフトウェアを使用するPSoC 6 MCU入門」は、全てのPSoC 6アプリケーション開発に、ModusToolbox利用を推薦しています。また、PSoC 4も追加されたことを考えると、ModusToolbox は、PSoC Creatorの後継IDEの可能性大です。

Creator回路図はDevice Configuratorへ

Creatorの特徴は、ソフトウェア開発の最初に、回路図:TopDesign.cyschへPSoCコンポーネントを配置、必要ならコンポーネント間配線を行うことです。ソフトウェア出発点が、多少ハードウェア開発者向きです。

PSoC Creatorの特徴:TopDesign.cysch
PSoC Creatorの特徴:TopDesign.cysch

ModusToolboxはこの回路図配置が、GUIで使用リソースの設定を行うDevice Configuratorへ変わりました。他社Eclipse IDEベースのIDE(例えば、NXP:MCUXpresso IDEやSTマイクロ:STM32CubeIDE)でも同様の周辺回路設定があります。

ModusToolbox のDevice Configurator
ModusToolbox のDevice Configurator(出展:AN228571)

つまり、見た目も操作性も、Eclipse IDEベースの他社IDEと殆ど同じになりました。

PSoCコンポーネントに重きを置いたCreatorプログラミングよりも、Eclipse IDEに慣れた開発者の親しみ易さ、GitHub経由のサンプルコード等の最新版配布による利便性を重視し、よりソフトウェア開発者向きにしたIDEがModusToolboxです。

ModusToolboxソフトウェア構成

ModusToolboxソフトウェア構成
ModusToolboxソフトウェア構成(出展:AN228571)

ModusToolboxソフトウェア構成を見ると、GitHub経由の提供部分が解ります。

下層の各種ドライバ、HAL、BSPsから、ミドルウェアのBluetooth、Mbed OSやFreeRTOS等のライブラリ、これらのサンプルコードも全てGitHubから最新版が取得可能です。

IDE基本部分と、開発ニーズや時節に応じて変化する部分を分け、変化部分はGitHubから最新情報を提供する構成は、優れていると思います。

まとめ

Infineon/Cypressの最新IDE ModusToolboxの特徴を説明しました。Eclipse IDEベースのWindows/Mac/LinuxマルチOS対応で、GitHub経由で最新ドライバやサンプルコードが利用可能です。

PSoC 6アプリケーション開発は、PSoC CreatorからModusToolbox利用を推薦し、最新版ModusToolbox v2.3.0.4276へPSoC 4も追加されたことから、Creator後継のIDEになりそうです。
※ModusToolbox v2.3.1.4663(2021-05-06)はパッチファイルで、v2.3.0.4276の事前インストールが必要です。

なお、PSoC 4/6開発にCreatorも引続き使えます。しかし、今のところ既存CreatorプロジェクトからModusToolboxプロジェクトへの移行ツールは見当たりませんので、新規PSoC 4/6開発は、ModusToolboxで行う方が良いと思います。

ModusToolbox概要は、コチラの英語動画でご覧いただけます。また、丸文株式会社さんの開発ツールページに、インストール方法サンプルコード使用手順などが分かり易く説明されています。

STM32CubeIDE/MX Major Release

2021年7月19日、STマイクロエレクトロニクスのMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へ更新されました。Major releaseです。開発済みMCUのSTM32CubeMX設定を、簡単に別ターゲットMCUへ移植する機能を解説します。

Major Release

STM32CubeIDE(以下、CubeIDE)は、ベースのEclipse IDE 更新に追随し年数回更新があります。今回のCubeIDE v1.7.0更新内容に、特に気になる点はありません。

一方CubeIDE付属コード生成ツール:STM32CubeMX v6.3.0(以下、CubeMX)には、開発済みMCUのCubeMX設定を、別MCUや別シリーズMCUへ簡単に移植する機能があります。移植性の高いHAL(Hardware Abstraction Layer)APIと併用すると、開発済みソフトウェアの再利用が簡単で強力なAPI生成ツールになりました。

STM32CubeMX設定移植機能

CubeMXには詳細な英語ユーザマニュアルUM1718 Rev35(全368ページ)があり、p1に主要機能説明があります。本ブログでもCubeMXコード生成機能の使い方やその重要性、STM32F0からF1へのソフトウェア移植方法などを何度か紹介してきました(検索窓に「STM32CubeMX」と入力すると関連投稿がピックアップされます)。

従来投稿は、MCUのCubeMX設定を、ターゲットMCUへ各項目を見ながら手動移植する方法でした。この方法は、予めターゲットMCUとの互換性が解っている場合や、移植周辺回路が少ない場合には有効です。

しかし、MCUの種類が増え、別シリーズMCUへ、または多くの周辺回路設定を個別に移植したい場合は、事前チェックは面倒です。そんな時に役立つ2機能が、UM1718 p1太文字記載の下記です。

  • Easy switching to another microcontroller
  • Easy exporting of current configuration to a compatible MCU

どちらもCubeMX画面のPinout & Configurationタブ選択、Pinoutプルダウンメニュー>List Pinout Compatible MCUs (Alt-L)をクリックすると、Full Compatible/Need Hardware change MCUが一覧表で表示されます。

List pinout compatible MCUs
List pinout compatible MCUs

STM32G0xテンプレート例

販売中STM32G0xテンプレートで使用中の汎用MCU:STM32G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/36KB)の例を示します。これは、評価ボードNUCLEO-G071RB搭載MCUです。

STM32G071RB Full and Partial match MCU List
STM32G071RB Full and Partial match MCU List

評価ボード搭載のLQFP64パッケージでフィルタ設定すると、青色:完全互換の汎用STM32G0シリーズMCUが12アイテム、黄色:一部ハードウェア変更が必要な低電力STM32L0シリーズMCUが17アイテムリストアップされます。

例えば、FlashやRAMを増量したい場合には、STM32G0B1RBへ開発ソフトウェアがそのまま移植できることが解ります。また、より低電力化したい場合には、STM32L071RBへも移植可能です。あとは、ターゲットMCUを選択し、STM32G0xテンプレートのCubeMXプロジェクト設定を全て移植するか、または一部周辺回路のみを移植するかの選択も可能です。

つまり、開発済みソフトウェアを別MCUへ移植する際に、容易性(完全互換/一部HW変更)と方向性(大容量化/低電力化など他MCUシリーズ適用)を評価でき、かつ、ターゲットMCU選択後は、ダイアログに従って操作すれば、CubeMX設定全て、または周辺回路毎にターゲットMCUへ自動移植ができる訳です。

CubeMX設定の移植後は、ターゲットMCU上で通常のようにコード生成を実行すれば、周辺回路初期設定や動作に必要となる関数群の枠組みが作成されます。その枠組みへ、STM32G0xテンプレートのHAL API開発済みソフトウェアをコピー&ペーストし、ターゲットMCUへのソフトウェア移植が完了です。

汎用MCUとHAL APIプロトタイプ開発

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

CubeMX設定の自動移植が簡単なことは、前章まででご理解頂けたと思います。

前例STM32G0xテンプレート開発ソフトウェアの移植可能なMCU数が12+17=29と大きいのは、汎用MCUとHAL APIを使ったソフトウェア資産だからです。

最新IoT MCU開発でも、STM32G0/G4シリーズなどの移植性が高い汎用MCU(=メインストリームMCU)とHAL APIを使って主要機能をプロトタイプ開発し、CubeMX移植機能を使ってターゲットIoT MCUへ移植すれば、最新IoT MCUの差分機能開発に集中できます。

つまり、「汎用MCUとHAL API利用のプロトタイプ開発は、他MCUへの移植性が高く、汎用との差分開発に集中できる高い生産性」をもたらす訳です。

※STM32G0/G4シリーズは、新プロセスで従来汎用STM32F0/F1/F3シリーズを高速・低電力化・セキュリティ強化した新しい汎用MCUです。コチラの関連投稿や、STM32U5発表と最新IoT MCU動向を参照してください。

STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)
STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)

まとめ

STマイクロMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へMajor Releaseされました。

開発済みMCUのCubeMX設定を、別MCUへ簡単に移植する機能があり、移植性が高い汎用(メインストリーム)MCUとHAL APIによるプロトタイプ開発ソフトウェア資産を、効率的に他MCUへ再活用できる統合開発環境になりました。

補足:NUCLEO評価ボードのユーザLED不足対策

汎用MCUとHAL APIプロトタイプ開発には、低価格で入手性も良いNUCLEO評価ボードが適しています。

但し、NUCLEO評価ボードのユーザ緑LED(LD2)とSW(B1)が、各1個と少ない点が残念です。CubeIDEサンプルプログラムは、単機能サンプル動作なので各1個でもOKですが、少し複雑な例えばRTOS並列動作確認などには、特にLEDが不足します。

お勧めは、赤LED 2個、SW 1個が実装済みのArduinoプロトタイプシールドです。残念ながらNUCLEO評価ボードSW(B1)は操作できないのでシールドSWで代用します。評価ボードArduinoピンとの配線や、付属ブレッドボードへの回路追加も簡単です。ST以外の様々なMCUベンダのArduinoコネクタ付き評価ボードでも使えます。

NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。
NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。

NUCLEO-G474REとArduinoプロトタイプシールドの使用例を示します。ArduinoプロトタイプシールドのLED1は、Lpuart受信、LED2は、SW操作、評価ボードのLD2は、1s/500ms/40ms点滅の動作確認に使っています。

STM版RTOSアプリケーションテンプレート構想もこの環境で検討中です(関連投稿:STM32RTOS開発3注意点(前編)、(後編))。

STM32RTOS開発3注意点(前編)

STマイクロエレクトロニクス)STM32MCUを使ってRTOS開発時のSTM32CubeMX、HAL、CMSIS RTOSの3注意点について示します。前編が、STM32CubeMXとHALについてです。CMSIS RTOSは、別途後編で示します。

STM32CubeMXとHAL の注意点を解説した後、サンプルプロジェクトで実例を示すという順番で説明します。

ソースコード生成ツール:STM32CubeMX

STマイクロのソースコード生成ツール:STM32CubeMX(以下CubeMX)は、MCU内蔵周辺回路の初期設定やAPIを、GUIベースで自動生成する非常に便利なツールです。

※MCUベンダのAPI生成ツールを比較した関連投稿は、コチラをご覧ください。

CubeMX生成APIは、ハードウェアを抽象化し、STM32MCU間で最大限の高いソフトウェア移植性を狙ったHAL (Hardware Abstraction Layer)と、よりハードウェアに近くHALよりも高速・軽量なエキスパート向けLL(Low-layer)の2種類から選択可能です。

HALとLL比較(出典:STM32 Embedded Software Overvire)
HALとLL比較(※説明のため着色しています。出典:STM32 Embedded Software Overvire)

一般的に、HAL APIが好まれます。というのは、このLL APIを利用し開発した2019年6月発売のSTM32G0xテンプレートV1の売上げはゼロでした。対策に、LL APIからHAL APIに変更し再開発した2020年6月発売のSTM32G0xテンプレートV2は、人気があるからです。

これらCubeMXの各種GUI設定や選択APIは、CubeMXファイル(.ico)に構成ファイルとして纏められます。

STM32MCU新規プロジェクト開発時に、この既成CubeMXファイル(.ico)を利用すると、ゼロから着手するのに比べ、効率的かつ間違いなく周辺回路や初期設定ができるため、利用価値の高いファイルです。

特に、ベアメタル比、さらに多くのCubeMX設定が必要となるRTOS開発では、既成CubeMXファイルを再利用するメリットがより高まります。同時に、生成コードの意味も理解しておく必要があります。

HALタイムベース

HALには、他ベンダにない便利なAPI:HAL_Delayがあります。

例えば、10msの待ち処理を行う場合、他ベンダなら、MCUコア速度に応じて適当にループ回数を調整したループ処理で10ms相当の遅延を自作します。しかし、HAL APIならば、HAL_Delay(10)の記述だけで、MCUコア速度に依存しない正確な10ms遅延が実現できます。

これは、HAL自身が、MCU内蔵タイマ:SysTickの利用を前提に設計されているからです。遅延処理を例に説明しましたが、STM32のHAL APIsは、SysTickと強く結びついています。

もちろん、HAL APIをベアメタル開発で利用する場合は、この結びつきに何ら問題はありません。

RTOSタイムベース

FreeRTOSも、タスク(スレッド)状態遷移タイムベースに、SysTickを使います。

これは、FreeRTOSだけでなく他のRTOSでも同じです。SysTickは、その名称が示すようにMCUシステムレベルのタイムベース専用タイマです。

従って、STM32MCUでRTOS開発を行い、かつHAL APIを利用する場合には、RTOS側でSysTickを使うのが、名称に基づいた本来の使い方です。

HALタイムベース変更

そこで、STM32RTOS開発でHAL利用の場合は、HALのタイムベースを、デフォルト使用のSysTickから別のタイマへ変更する必要が生じます。この変更に伴う手動設定も当然必要となります。

*  *  *

ここまでが、STM32RTOS開発におけるSTM32CubeMXとHALに関する注意点です。
これらの注意点が解っていると、次章で示すRTOSサンプルプロジェクトのCubeMXファイルの意味と生成コードが理解できます。

STM32RTOS開発実例

STM32RTOS開発実例に、評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)でRTOS開発する場合を示します。

NUCLEO-G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/32KB)でRTOS開発する時でも同様です。しかも、RTOSサンプルプロジェクトは、STM32G071RBの方が(発売が古いためか?)多いので、NUCLEO-G071RBをお持ちの方は、是非ご自身で試してみてください。

FreeRTOS Example Selector

STM32CubeIDEのFile>STM32 Projectで、新規プロジェクト作成パネルを表示します(最新情報更新のため、表示に少し時間がかかる場合があります)。Example Selectorタブを選択、Middleware>FreeRTOSにチェックを入れ、NUCLEO-G474REのFreeRTOS_Queuesを選択したのが下図です。

NUCLEO-G474REのFreeRTOS_Queues
NUCLEO-G474REのFreeRTOS_Queues

右上欄、Noteの内容が、前半までに示した注意点のことです。参照先UM1722 Rev3は、CMSIS RTOSとFreeRTOSの関係があるのみです。このCMSIS RTOSについては、別途後編で説明します。

Nextをクリックし、FreeRTOS_Queuesサンプルプロジェクトを新規作成します。

さて、FreeRTOS Examples Listが318アイテム(STM32CubeIDE v1.6.1時)もあるので、Exportをクリックし、出力されたExcelファイルをBoardでフィルタリング、NUCLEO-G071RBとNUCLEO-G474REを抽出したのが下図です。

FreeRTOS Example List
FreeRTOS Example List

緑に色付けしたNUCLEO-G071RBの方が、FreeRTOSサンプルプロジェクト数が多いことが判ります。開発予定のSTM版FreeRTOSアプリケーションテンプレートは、Cortex-M4コアが対象ですので、本稿ではNUCLEO-G474REのFreeRTOS_Queuesを実例として使いました。

FreeRTOS_QueuesのSTM32CubeMXファイル

FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoが下図です。グレー文字は変更不可、黒文字は変更可能を示します。

FreeRTOS_Queues.ico
FreeRTOS_Queues.ico

TIM6がグレーなのは、HALタイムベース変更先がTIM6だからです。Kernel settings CPU CLOCK HZのSystemCoreClockがグレーなのは、RTOSタイムベースがSysTickだからです。つまり、本来の名称に基づいたSysTickがRTOS側で使われ、HALの新タイムベースにTIM6が割当済みであることが解ります。

FreeRTOS APIは、変更不可のグレーCMSIS V1です。ここは、後編で説明します。

デフォルトDisabledのUSE IDEL HOOKを、Enabledに変更し、ソースコード自動生成のGenerate Code(Alt+K)を実行してください。

HALタイムベースTIM6変更結果

FreeRTOS_QueseのTIM6とHook関数
FreeRTOS_QueseのTIM6とHook関数

app_freertos.cのL62に、Hook関数:vApplicationIdleHoolのひな型が自動生成済みです。ここへWFIを追記すれば、FreeRTOSアイドル時に低電力動作ができます。コチラのNXP版関連投稿Step5: FreeRTOS低電力動作追記と同じです。

main.cのL289は、TIM6満了時動作です。HAL_IncTick()が自動生成済みです。ベアメタル開発のSysTickからTIM6へHALタイムベースが変更されたことが解ります。

そのTIM6は、stm32g4xx_hal_timebase_tim.cで、1MHz=1ms満了に初期設定済みです。

つまり、STM32RTOS開発でHAL利用時に必要となる変更が、「全てCubeMXで自動生成済み」なのが解ります。

※上図は、USE_TICK_HOOKもEnabledへ変更した例です。Disabledへ戻すなどして、CubeMX自動生成ファイルが変化することを確かめてください。

この実例のように、CubeMX付属RTOSサンプルプロジェクトのCubeMXファイル(*.ico)を再利用すれば、周辺回路や初期設定ミスを防ぎ、RTOS新規アプリケーション開発が容易になることが解ります。

まとめ

STM32MCUでRTOS開発を行う時の3注意点、STM32CubeMX、HAL、CMSIS RTOSのうち、前編としてSTM32CubeMX、HALの2注意点とサンプルプロジェクトを使ってその実例を示しました。

RTOS開発では、既成STM32CubeMXファイル再利用価値が高まること、HALタイムベース変更の必要性がご理解頂けたと思います。3つ目のCMSIS RTOS関連は後編で示します。

あとがき

ベアメタル開発経験者であっても、STM32RTOS開発時、CubeMXのNoteを読むだけで、ベアメタル開発では何の問題も無かったHAL タイムベース変更理由が解り、その結果生じるCubeMXファイルや自動生成ソースコードの中身が理解できる方は、少ないと思います。本稿は、この変更理由と生成コードに説明を加えました。

STM32CubeMXは、STM32MCU開発に必須で強力なAPI生成ツールです。が、時々、説明不足を感じます。問題は、どのレベル読者を相手にするかです。エキスパートなら説明不要ですが、初心者ならゼロから説明しても解らないかもしれません。文章による組込み技術説明が、難しいのが根本原因でしょう😂。

そんな組込み開発ですが、文章だけでなく、「実際に評価ボードと手足を使って慣れてくると、案外すんなり簡単に理解、習得できる方が多いのも組込み開発」です。

販売中のNXP版FreeRTOSアプリケーションテンプレートにも、本稿同様、詳しいFreeRTOS解説を付けています(一部ダウンロード可能)。FreeRTOS開発を手軽に試せ、習得を支援するツールです。

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

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

STM32U5発表と最新IoT MCU動向

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は日本で何をしようとしているのか“からも分かるように、マスメディアは文字や画像で情報を伝えます。受けての我々開発者は、これらノイズを含むと思われるマスメディア情報を、自分の頭で分析・処理し、理解する必要があります。

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

非接触型体温計と放射温度計

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の最重要技術です。ソフト/ハードの垣根を越えた知識や理解が、結局は利益を生む機器開発に繋がることを言いたかった訳です。