組込み開発 基本のキ: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セキュリティ



傾向と対策:日本低下

 

世界第2位から降下傾向の日本
世界第2位から降下傾向の日本

年内最後の投稿に、“日本の半導体産業はどうしてダメになったのか? 今だから分かる3つのターニングポイント”(@IT、2021年12月17日)を紹介し、国際地位低下傾向の日本と、IoT MCU日本開発者の対策を示します。

半導体と通信業界から見る日本低下傾向

半導体の研究・開発者から見た日本地位低下を、3度のターニングポイント失策から分析し、現状の日本半導体は、脇役へ滑り落ちていて、名脇役の存在感を示せるかは、「舵取り」(おそらく政治家や官僚)にかかっていると結論しています。

筆者、Massa POP Izumida氏は、もちろん日本人で、本ブログ筆者と同世代だと思います。80年代に就職、90年代世界第2位の経済大国日本で中堅現役、そして、総合順位31位へ低下した現状日本を実感されている技術者だと推測します。

ATM(Asynchronous Transfer Mode)通信の研究・開発者だった本ブログ筆者も、同じような経験があります。90年代、米国、欧州、日本のATM規格競争が勃発した時、日本案が世界規格になっていれば、現状と異なるネットワーク、通信業界になっていたでしょう。“たられば”の話です。

日本人特性

周囲の意見に「同調意識が強い」日本人の性格や特性は、コチラの記事にまとまっています。「単一民族島国の中」で、上手く生きていくための特性は、必然です。

ただ、舵取りや国際競争の時に、この特性が裏目に出たのが、日本地位低下原因の1つでしょう。現状も変わらない官僚主義は、コチラの記事でも判ります。

一般国民も含めた日本人の特性変化(≒国際化)には、「数世代に渡る長い時間」が必要です。

つまり、今の日本人特性は、「ボーダレスネットワークでワールドワイドに急変した世界の中」の日本低下傾向を、スグに阻止し復帰するには適していない訳です。

日本IoT MCU開発者対策(私案)

IoT MCU日本開発者が生き残るには、「日本人以外の第2の視点とPlan B」が必要です。

日本IoT MCU開発者の対策
日本IoT MCU開発者の対策

日本開発者の現役期間が50年としても、DNAに染み込んだ同調意識もまた簡単には変わりません。

対策は、一時的にせよ、欧米人の特性で自身のIoT MCU状況を捉えることです。欧米人特性は、ネット検索で見つかります。また、欧米に限らず、アジア人特性も日本人とは大きく異なります。

これら日本人外の特性・視点で現状把握を試すと、自分との差分が判り、対策に何をすべきかが見えてきます。これは、個人キャリアプランの中で、Plan Bの1つに相当します。

具体策は、個人により異なります。私の場合は、米語です。幸い、IoT MCU関連ドキュメントやセミナーは、殆どが米語ですので、材料は豊富です。敬語の利用が少ない米語は、効率的情報伝達と取得に優れています。

別策は、国際競争下で最後に生き残っている日本自動車業界の視点を借りることです。自動車業界は、ワールドワイドな視点で、研究開発を実践中です。生き残った主因です。その取組みや視点で、Plan Bを考えるのも良いと思います。

年末年始は、現状から少し距離を取れる時期です。日本人外の視点とPlan B検討は、いかがでしょう。

次回金曜投稿:1月7日

各種メンテナンスのため大晦日投稿はなし、年内は本稿が最後、次回金曜投稿は、来年1月7日です。

弊社サイトは、年中無休です。本年も弊社のご利用、誠にありがとうございました😌。
皆様、良いお年をお迎えください。

RAファミリFSP v3.5.0更新

ルネサスRAファミリのFSP(Flexible Development Package)が、12月9日、v3.5.0へ更新されました。RAファミリの特徴は、コチラの3章に投稿済みです。下記が、抜粋した2項目です。

・ARM Cortex-M33/M23/M4コア採用でIoTセキュリティ強化
・Eclipse IDEベースのKeilやIARなどのARM Ecosystemと無償GNUコンパイラ利用可能

RAファミリヒットの予感!

筆者は、RAファミリが、IoT MCU日本人開発者にヒットする予感がします。

Arduinoシールドコネクタ付き+外付けエミュレータ無しで開発できる低価格評価ボード、コンパイラ容量制限無し、CMSIS開発などは、競合他社に追いついた感じですが、FreeRTOS/Azure RTOS両RTOSへの早い対応、オリジナル内蔵周辺回路や買収各社のフロントエンド化、SOTBなどの製造プロセスは、多くのルネサス開発経験者を引き付ける魅力を持つからです。

この魅力を最大限引出すツールが、FSPです。簡単に言うと、HAL(Hardware Abstraction Layer)API生成SDK(Software Development Kit)です。ルネサスは、Smart Configuratorと呼んでいますが…。

RA開発ポイントFSP構成

FSP v3.5.0の詳細は、ユーザーズマニュアル:UM(英文、全3206ページ)を参照してください(ページ数が多いのは、Chapter 4以降がAPIレファレンスだからです)。FSP構成を示します。

Flexible Software Package構成
Flexible Software Package構成

FSP生成HAL APIを利用すると、RAファミリ共通のアプリケーション開発ができます。また、FSPは、例えばREファミリなど、他のCortex-M系ファミリへ発展する可能性もあります。HALが、コア差を隠蔽できるからです。

※図からRenesas版CMSISと考えると判り易く、CMSISは、コチラの関連投稿3章を参照。

IoT MCUでは、アプリケーションの流用性、移植性は重要です。従来よりも開発規模が大きく、しかも、セキュリティなどのIoT技術適用には、業界標準インターフェースでの機能流用が効率的だからです。既存アプリケーションを出来るだけ流用し、顧客の新規追加開発部分を最小化することで早期開発を実現します。

RAファミリの開発ポイントは、FSPです。

UMの2.3 Tutorial: Your First RA MCU Project – Blinkyと2.4 Tutorial: Using HAL Driversを読んで解る方は、2.5 Primer: ARM TrustZone Project Developmentで、IoT MCUポイント:TrustZoneの理解をお勧めします。具体的なTrustZoneサンプルコードは、検索中です。見つかりましたら、本ブログで投稿します。

2.3や2.4が不明な方は、コチラの関連投稿を参考にしてください。

日本語FSP解説

RAファミリビギナーズガイド
RAファミリビギナーズガイド

日本語FSP解説が欲しい方は、RAファミリビギナーズガイド(全114ページ)の2~3章が役立ちます。但し、掲載サンプルコードは、UMに比べ少数です。

このガイドで注目して頂きたいのが、P98の下記です。

“セキュリティは重要です。また、それは後で追加することはできないため、初期段階から考える必要があります。少なくとも、コストのかかる再設計があれば、それに基づいてアプリケーション全体を破棄することも必要になるかもしれません。これは建物の土台と考えてください。それ自体は……。
それでも、この接続された世界の全てのアプリケーションにはセキュリティが不可欠なのです。”

IoT MCUのセキュリティ土台には、Cortex-M33のTrustZoneが業界標準です。Cortex-M33のRAファミリをプロトタイプ開発に使う理由は、後で追加できないTrustZoneが土台に内蔵のためです。

プロトタイプ開発初期は、TrustZone未使用でも構いません。後でIoTセキュティを追加する際に、プロトタイプ開発で使った土台を変更せずに内蔵TrustZoneを使えること、これがRAファミリをIoTプロトタイプ開発に使う最大メリットです。

FSP活用RAテンプレート構想

RAテンプレートは、FPB-RA6E1とFPB-RA4E1両方で動作確認
RAテンプレートは、FPB-RA6E1とFPB-RA4E1両方で動作確認

FSPには、多くのサンプルコードが掲載されています。弊社は、これら複数サンプルコードを簡単に流用し、早期プロトタイプ開発に使えるRAテンプレートv 1.0を、来年1Q目途に開発、RAファミリ中核MCUのRA6/4シリーズ評価ボードRA6E1/RA4E1の両方で動作確認し、販売を予定しています。

※既に販売中の各種テンプレートは、コチラをご覧ください。

最初にリリースするRAテンプレートv 1.0は、UM 2.3/2.4理解や基礎的なRA習得に役立つ初心者向けベアメタルプロトタイプ開発テンプレートとし、中級以上の開発者向けRTOS関連やTrustZoneは、v2.0以降で対応予定です。

RAテンプレートを使えば、FSP掲載の複数サンプルコードを流用したIoTプロトタイプ開発が、早期にできます。

IoTスキル獲得最適RAファミリ

全てのモノがネットへ接続するIoT時代は、開発対象が増えますが、“競合”開発者も増えます。本ブログ読者には、スキルを活かした更なる効率的開発が求められます。

読者個人によるIoTキーポイントのスキル習得は、自分への先行投資です。キーポイントとは、現行MCU開発スキルに加え、IoTセキュティとRTOSです。

個人レベルでこれらセキュティとRTOSスキル獲得に、Cortex-M33のRAファミリは最適です。前章の低コストの評価ボードと業界標準Eclipse IDEベース“無償”ARM Ecosystem(=e2 studio+FSP)が、ルネサスサイトから簡単に入手でき、入手後、スグに開発着手できるからです。コンパイラ容量制限もありません。

また、初心者はもちろん、中級以上のIoTスキル習得意欲を満たすルネサス公式情報も豊富です。コチラが、公式RAファミリ動画です。短い動画が多数ありますので、すきま時間でのチェックに適しています。

e2 studio日本語メニュー vs. 英語メニュー

e2 studio日本語メニュー化
e2 studio日本語メニュー化

日本語メニューのe2 studioを使うには、インストール時、カスタマイズ機能でJapanese Language Supportコンポーネントの手動追加が必要です。筆者は、英語メニューを愛用していますが、FSP v3.5.0更新を期に、試しに日本語化してみました。

日本語メニューは、横幅が広くなりますがショートカットキー付きです。また、全メニューが日本語訳になる訳ではありません。好みの問題ですが、競合他社Eclipse IDE同様、英語の方が使いやすいと筆者は感じました。

WindowsのTPM使い方

Windows 11アップグレート要件のTPM 2.0の使われ方を調査しました。WindowsがどのようにTPMを使っているかを知れば、11アップグレート足切り要件を筆者が納得し、加えて、IoT MCUセキュリティのTrustZone開発工数を顧客へ説明する時、参考になるかもしれないからです。

WindowsのTPM

Windows 10から追加・変更された現行Windows 11の機能は、生産性や弊社ビジネス向上に直結するものは無いと思っています。対処法などは、最悪Windows 11へアップグレードする際に備え収集中です。

アップグレード要件で最も不満な点が、TPM 2.0です。このTPMで何を行い、なぜ要件になったのかを整理してみます。

TPM機能(出展:PC Watch記事)
TPM機能(出展:PC Watch記事)

その結果、TPM 2.0は、11アップグレード要件というよりも、国際標準規格制定団体:Trusted Computing Group(TCG)が2014年10月にリリースし、TPM 2.0としてISO/IEC標準セキュリティ規格となったPCの普及が目的、と結論しました。

来年秋のWindows 11大型更新後、弊社PCの11アップグレート状況が変わるか楽しみです。

TPM利用Windows HelloとBitLocker

暗号化、乱数⽣成、暗号鍵⽣成と保存、デジタル署名がWindowsのTPM 2.0チップ利用箇所で、MacのBoot CampでもWindows 11が動作しない理由は、コチラに良くまとまっています。

ちなみに、TrustZone対象も、TPM 2.0と同様になる可能性も高く、特に、暗号化アルゴリズム可変の機能は、優れています。アルゴリズムを変更するWindowsのOTA相当にも注目しています。

Windowsは、これらTPM機能を利用し、パスワードを使わずにWindowsへサインインする「Windows Hello」や、内部ストレージ暗号化の「BitLocker」を実行します。また、「Microsoft Azure Attestation」(MAA)などにも使うようです。

WindowsのTPM使い方例(出典:セパゴのITブログ)
WindowsのTPM使い方例(出典:セパゴのITブログ:https://www.sepago.de/)

BitLockerやWindows Helloは、Windows 10でも利用した企業向けノートPCユーザもいるかもしれません。ただ、個人ノートPCや自宅PCユーザは、Microsoftアカウントを使うWindows HelloやPINの代わりに、ローカルアカウントの利用者が多いハズです。手間が掛からないことや、PC使用履歴をクラウド記録されるのが嫌だからです。

Windows 11は、Microsoftアカウント利用が基本ですが、アプリケーション個人認証にスマホ併用も必須になりつつあります。例えば、Googleログインも、スマホ2段階認証が有効に変わりました。

Googleログインの2段階認証プロセス
Googleログインの2段階認証プロセス

従って、例えWindows 11でTPMパスワードレス認証後でも、Googleログイン2段階認証は必要になる訳です。一方、TPM 2.0未搭載Windows 10でも、BitLockerやWindows Helloは利用でき、スマホ2段階認証などで様々なアプリケーションのセキュリティにも対応可能です。

つまり、TPMは、Windows 11の技術的アップグレード要件ではなく、OSセキュリティ強化が目的、というのが筆者TPM評価です。

ちなみに、ローカルアカウントによるWindows 11セットアップ方法は、コチラにまとまっています。

TPM理由

Microsoftが強調するOSセキュリティ強化には、TPMと手間暇、処理能力が必要です。処理能力要件が、Windows11対応CPUです。Windows 10が正常に動作するCPUでも、この能力要件を満たさないCPUも多数あります。理由は不明ですが、今回はTPMにフォーカスするため追求しません。

さて、筆者のようなセキュリティ素人には、TPMセキュリティ強化分と便益(手間暇)比を、ゲーム/個人/企業などのPCユースケース毎に評価、公表してほしいです。現行Windows 11は、最強セキュリティを求める企業向けユーザのみを対象にしている気がします。

仮に、Windows 11普及にTPMセキュリティ強化が障害になっているとMicrosoftが判断すれば、コチラの関連投稿2章のユーザアカウント制御のようなセキュリティを弱める対策を打出すと思います。

ユーザアカウント制御の設定
ユーザアカウント制御の設定

好みのセキュリティレベル設定は、個人ユーザに歓迎されるハズです。既に、TPM回避Windows 11インストール公式発表などがその現れです。これは、Windows 10サポート終了2025年10月14日が近づけば、より効果を発揮します。

しかし、Windows 11の魅力が現行のままなら、2025年10月以降は、Mac/Linuxなどの別OSやWindows 365などに乗換えるユーザも少なくないと思います。11乗換魅力の無さが、普及を妨げているからです。

TPM の理由は、最もセキュリティに敏感で、新PC購入/入替えも容易な企業向けPCユーザへ、ISO/IEC標準セキュリティ規格PCへの買換え動機付けだと思います。

TrustZone Cortex-M33はM4比2倍説明応用

TrustZoneとTPMの類似性
TrustZoneとTPMの類似性

IoT MCU顧客へ、Cortex-M33 TrustZone活用開発工数は、Cortex-M4比2倍となる説明が必要と前稿で書きました。

2倍根拠は、Cortex-M33/M4動作周波数比、Secureと通常の2プロジェクト同時開発必須などです。これらは、目に見える差分です。しかし、セキュリティに関しては、リスクが増減という話ばかりで、数値で表せないセキュリティ差分を、顧客に納得してもらえるかは、正直分かりません。

しかも、TrustZone活用には、通常の開発スキルに加え、セキュリティスキルも必要です。組込み開発は、1人で全て担当することも多いので、セキュリティ知識は持てても、利用スキル:暗号化ライブラリ選択やAPI利用法などに限定したいハズです。

セキュリティの詳細内容は、一般的なIoT MCU開発者には背景知識が少ないため、根本理解は困難でしょう。この状況で、セキュリティ利用スキルも必要となるTrustZone活用開発の差分を、顧客に上手く納得してもらうには、開発者として何らかの工夫も有効かもしれません。

Windows 11のTPMも、上記TrustZoneと全く同じ状況だと思います。そこで、現時点のTPMを整理しました。

今後Microsoftが、どのようにTPMの理由をユーザへ説明(12/4更新)していくかを、IoT MCU顧客へのTrustZone Cortex-M33開発工数が、M4比、2倍の説明にも応用したいと考えています。

実務的には、セキュリティの根本理解よりも、この方法の方が近道の気がします😅

ルネサスRAファミリカタログ2021.11更新

ルネサスRAファミリカタログが、最新版2021.11に更新されました。高度セキュリティTrustZone搭載IoT MCUとして、弊社は、ルネサス)RAファミリとSTマイクロ)STM32L5/U5に注目しています。

本稿は、RAファミリ中核のRA4とRA6両シリーズ特徴、TrustZoneオーバーヘッド処理がM4比2倍を説明し、評価ボードを紹介します。

RAファミリのCortex-M33とCortex-M4

ルネサスRA4シリーズのグループ構成(出展:RAファミリカタログ)
ルネサスRA4シリーズのグループ構成(出展:RAファミリカタログ)

ルネサスオリジナルやARM Cortex-M系など、多種多様なMCUコアを販売しているルネサスのRAファミリ位置づけと開発方法は、コチラの関連投稿にまとめ済みです。Cortex-M系競合他社より出遅れ感もありますが、最新RAファミリカタログを見ると、TrustZone対応Cortex-M33搭載IoT MCUの精力的製品化が感じられます。

Cortex-M33搭載RAファミリの中核MCUが、RA4/6シリーズです。RA2シリーズはCortex-M23搭載、RA8シリーズは未発売です。ターゲットアプリケーションは、カタログP5にまとまっています。

※Cortex-M33 ≒ Cortex-M4後継、セキュティ機能強化コア
※Cortex-M23 ≒ Cortex-M0+後継、セキュティ機能強化コア

Cortex-M33とCortex-M0+/M4差分
Cortex-M33とCortex-M0+/M4差分

RA4/6シリーズには、Cortex-M4搭載MCUもあります。これは、TrustZoneまでの高度セキュリティが不要なアプリケーション向けのMCUだと思います。Cortex-M33のTrustZone活用には、内蔵Flashのパーティション分割やSecureステートとNon Secureステート切替えなど、高度セキュリティ対応オーバーヘッド処理が必要になります。

同一シリーズ内でCortex-M33とCortex-M4の動作周波数が異なる理由は、開発アプリケーション移植を考慮すると、これらオーバーヘッド処理のためにM4比2倍の高速化が必要だからと推測します。これは、コチラの関連投稿で示したCortex-M33とCortex-M4比較や開発工数比評価の内容とも一致します。

つまり、TrustZoneの高度セキュリティは、M4比2倍もMCU能力を消費する可能性がある訳です。

コスト意識が非常に高いIoT MCU顧客に、このM4比2倍を理解してもらえるかは分かりません。前稿では、筆者がWindowsユーザで、TPM足切り要件に不満でした。同様にIoT MCU顧客も、我々開発者が高度セキュリティ内容を丁寧に説明しないと納得してもらえないかもしれません。

以後は、Cortex-M33搭載RA4とRA6評価ボードをそれぞれ紹介します。

RA4シリーズ

RA4シリーズの特徴は、Cortex-M33/100MHz性能と低消費電力動作です。Digi-Key記事が、判り易く特徴をまとめています。記事紹介のRA4評価ボードが、弊社も使用中のRA4E1 Fast Prototype Board (Cortex-M33/100MHz、Flash/512KB、RAM/128KB)です。

※Eは、RA4シリーズ開発エントリポイントを示します。つまり、他RAシリーズやファミリへのアプリケーション移植性に優れた汎用MCUを示しています。

RA4E1 Fast Prototype BoardへFreeRTOSを適用
RA4E1 Fast Prototype BoardへFreeRTOSを適用

弊社は、既にRA4E1 Fast Prototype Boardを使ったFreeRTOSと、統合開発環境e2 StudioでのFlexible Software Package(FSP)の使い方を投稿済みですので参照してください。FSPとは、RAファミリ共通のSDK(Software Development Kit)のことです。

但し、どちらの投稿もTrustZone未使用です。別途投稿予定のTrustZone使用版で、2倍比を評価できればと考えています。未使用のTrustZoneですが、プロトタイプ開発初期から高度セキュリティに配慮すること、顧客がTrustZoneを要求した場合、開発プロトタイプをそのまま活用できるメリットがあります。

※TrustZone使用版は、検討中です。当面の課題は、後の章に示しています。

RA6シリーズ

EK-RA6M4(出展:ユーザーズマニュアル)
EK-RA6M4(出展:ユーザーズマニュアル)

RA6シリーズの特徴は、RA4比、より高速なCortex-M33/200MHz搭載です(カタログには、最大240MHzと記載されていますが、発売製品はどれも200MHzです)。モータ制御などに向いています。やはりカタログよりも、Digi-Key記事のほうが、RA6シリーズ特徴理解がし易いです。

※Mは、モータ制御向けを示します。その他、カタログ記載のWやTなどのサフィックスも、内蔵周辺回路のアプリケーション適合性を示します。

記事紹介のRA6M評価ボードが、EK-RA6M4です。モータ制御先進アナログ回路や大容量Flash内蔵ですが、個人購入するには高価な気がします。顧客モータ仕様変更に柔軟に対応するには、汎用RA6E1で共用部分を早期開発し、先進制御部分のみを差分開発する方法が効果的だと思います。

TrustZoneサンプルコード課題

TrustZone概念は理解しても、実装はどうか? が普通のソフトウェア開発者には判り難い点です。秘密鍵など、何をSecure領域に書込み、いつ読込むかなど、セキュリティ専門家解説付き具体的サンプルコードを探していますが、適当なものが今のところ見つかりません。

TrustZone利用手順と保存対象は、接続クラウド側にも多少依存するでしょうが、ほぼ決まっていると思っています。具体的サンプルコードがあればテンプレート化も可能か、というのが現状です。

Blogテーマ変更

本ブログテーマを変更しました。本年1月変更に続き2回目です。変更理由は色々ありますが、投稿記事の「カテゴリ」と「タグ」が、投稿最後に表示される点が一番の変更点です。

今後とも本ブログ、よろしくお願いいたします。

Windows 10 21H2大型更新成功

2021年11月17日、Microsoftは、Windows 10 21H2大型更新を一般公開しました。数年前から投稿してきたMediaCreationTool21H2を使った手動更新方法で、10月18日に弊社Windows 10 PC 3台を更新し、今日現在トラブルはありません。

21H2大型更新後OSビルド1348から1387へ更新、Windows 11アップグレートも可能
21H2大型更新後OSビルド1348から1387へ更新、Windows 11アップグレートも可能

朗報は、Windows 10大型更新が、年1回へ変更されたこと、また、今回の21H2更新規模は小さく、今後も小規模更新を繰返し、4年後の2025年10月14日サポート終了を迎えるだろうことです。

安心、安全、安定度の高い最新Windowsを望むユーザは、今日現在、Windows 10 21H2が最適です。

Windows 10 21H2手動大型更新方法

Windows 10 21H2大型更新方法と手動更新メリット/デメリットを、簡単にまとめたのが下表です。詳細は、前回前々回と同じですので参照してください。

注意点は、旧21H1を起動した状態で、新21H2 USBセットアップを実行することです。

Windows 10 21H2手動 大型更新手順
準備

MediaCreationTool21H2.exeダウンロード

②USB/DVDインストールメディア作成

③21H1バックアップ(更新失敗リカバリ対策)

更新

21H1起動状態で作成USBのsetup.exe実行

②21H2引継ぎ項目選択後インストールクリック

③21H2大型更新が自動で完了

最大メリットは、ユーザタイミングで大型更新できることです。また、Windows 21H2更新後でもWindows 11アップグレートは、もちろん可能です。

手動 大型更新 メリット/デメリット
メリット

・ユーザがいつ始まるか判らない大型更新を開始できる

・バックアップを取るタイミングが良く、リカバリにも適す

・アプリとユーザデータ両方引継ぎで更新後、即PC利用可能

・USBは複数PC更新に使えWindowsトラブル回復ツール兼務

デメリット ・レジストリがデフォルトへ戻るのでユーザ変更時は再設定必要

Windows 11新機能とWindows 10最適理由

例えば、Windows 11新採用のタスクバーのモニタ中央配置。Windows 10風に左配置へ戻せますが、タスクバー中央配置の必然性は無いと思います。このように、PC本来の生産性や操作性を向上させる新OS機能が、Windows 11には少ない(≒無い)と感じます。

Windows 11アップグレート要件TPM 2.0は、コチラに2021年11月16日のMicrosoft見解があります。PC搭載カメラ/指紋認証/スマホを使った2要素認証など、既に存在する様々な対策に加えてTPM採用の利点は、理解できます。

しかし、重要情報をハッカーなどから守るセキュリティ強化策がTPMで、重要ですが縁の下の力持ち、新しく何かを作り出す訳ではありません。

Microsoftは、当初TPM 2.0をWindows 11足切り要件とし、新PC購入の需要喚起、起爆剤にしたかったと推測します。既にTPMを破る方法も公開されていますので、TPM過信は禁物です。

しかも、欠点もあるハズです。例えば、TPMモジュール故障時PC起動はできるか、TPM再設定は簡単か、TPM認証失敗時の手間は、などなど、セキュリティ根幹強化は使い勝手も良くなるとは限りません。

素人考えですが、効果と失敗を含めた手間など利用形態に応じて、ユーザがセキュリティリスクバランスを設定できるか否かだと思います。ユーザアカウント制御設定に近いイメージです。設定が攻撃対象になると元も子もなくなる訳ですが、既存2要素認証などで攻撃回避して……、抜け穴ありそうですが…😅。

要は、セキュリティは、貴重なユーザPC能力をも消費するということです。

ユーザアカウント制御の設定
ユーザアカウント制御の設定

ネットカフェPC利用も多い筆者は、PCハードウェア依存のアクセス制御は好みません。半導体不足の昨今では、持ち運び可能な高性能ノートPC新規入手は、新車同様、困難になりつつあります。

Microsoftが本当にTPM必須と考えるなら、TPMを回避したWindows 11インストール方法の公式発表やアップグレート要件緩和など、矛盾行動も見られます。半導体不足終息が不明であることから、新PC需要喚起の方針ブレだと思います。

また、次期OSのWindows 365とWindows 11両方に開発リソースを分けるのは、(余計なお世話ですが)Microsoftにとって得策とは思えません(Windows 365/11は、コチラの関連投稿参照)。Windows 11初期トラブルが、来年2022年秋Windows 11大型更新後も続くようなら、Me/Vistaの二の舞もあり得ます。

大規模変更が無いWindows 10へは、セキュリティやバグ修正などPC本来の安心、安全、安定度を高める更新は、2025年10月14日サポート終了まで提供されます。

まとめ

Windows 10 21H2への手動大型更新方法、メリット/デメリットをまとめました。

Windows 11新機能や初期トラブル状況から、今日現在Windowsユーザには、Windows 10 21H2が最適とした理由を説明しました。

Windows 10サポート終了2025年10月14日までに、Windows 365/11、新PC購入、他OS乗換などの対策は必要です。

あとがき:テクノロジー進化リスクと魅力の比

筆者は、MS-DOSからの古いMicrosoft Windowsユーザです。過去、Windowsアップグレートを躊躇った事は、一度もありません。もし、弊社3台PCが、全てWin 11足切り要件OKなら、今回も過去同様アップグレートしたと思います。しかし、現状は11要件緩和後もOKは2台、1台はNGです。

ノートPCは、天寿も近いので新PC購入も検討中ですが、好みのPCは価格高止まりです。さらに、新PCプレインストールOSもWin 11か10選択可能など、マスコミやSNSがバイアスをかけるWin 11が、実ユーザに歓迎されているかも疑問です。Win 11魅力不足と購入後のWin 10→Win 11はいつでも簡単ですが、Win 11→Win 10ダウングレードは大変だからでしょう。

テクノロジー進化は必須です。ただ、進化リスクと魅力の比は、リスクが勝ると現状Win 11には感じます。

COVID-19が、コンタクトレス・テクノロジーを加速中なのは確かですが、同じく加速した半導体不足が、Win 11に追風か逆風かは、MS動向注視とWin 11魅力アップが必要だと思います。22年秋の11大型更新後でも、アップグレートは遅くは無いと思います。

逆に2022年は、最新、高安定Windows 10 21H2でIoT MCU開発に注力できる1年と言えます👍。

Office 2021とLibreOffice 7系

2021年秋は、Windows 11やmacOS MontereyなどPC新OSが登場しました。加えて、Microsoft Office 2021発売やLibreOffice Fresh/Stillが共に7系へ更新するなど、PC文書作成ツールも変化しつつあります。

本稿は、これら文書作成ツールとPCプラットフォームの現状をまとめます。

Microsoft Officeの2025年10月14日

Microsoftの2025年10月14日
Microsoftの2025年10月14日

Microsoft Office 2019と2016のセキィリティ延長サポート終了は、どちらも同じ2025年10月14日で、Windows 10サポート終了と同日です。

つまり、2025年10月14日以降は、Windows 10+Office 2019/2016のローカルPCでの運用は、セキュリティ上、問題です。Microsoftは、Windows 365やOffice 365(=Microsoft 365)などのサブスクリプション型クラウドツールを代替候補として提供します。

新発売の買い切り版ローカルPC向けOffice 2021のサポート終了は、何故かOffice 2019/2016のわずか1年後、2026年10月14日です。日本のみに人気がある買い切り版Officeから、徐々に撤退の兆しを感じるのは筆者だけでしょうか?

新OS Windows 11は、特に企業向けには不評のようです。多くの初期トラブルに加え、Windows 11メリットがビジネスには直結しないため、安定度、完成度の高いWindows 10を使い続けるユーザが多いからです。

さらに、従来Windows 10大型更新の年2回から、Windows 11同様年1回へ変更されたことも朗報、継続プラス材料です。名称もWindows 10 November 2021 Updateへ変わったようですが、大型更新結果は21H2のままでした(21H2更新結果は、来週投稿予定)。

21H2:Windows 10 November 2021 Update結果
21H2大型更新結果

Microsoftのこれら対応は、Windows 11へのアップグレート更新を望まない多くのWindows 10ユーザが、マルチプラットフォーム&クラウドツールのWindows 365へ乗換える可能性を高くします。
※Windows 365とWin 10/11比較は、コチラの関連投稿を参照してください(Win 10大型更新回数は、投稿当時の年2回のままなので注意してください)。

2025年10月14日まで、残り4年です。

この4年間は、「Microsoftが全Windowsユーザへ与えたクラウド提供ツールへの移行検討と猶予期間」とも考えられます。Microsoft戦略を俯瞰した気がします。

クラウド化は、ユーザメリットもある反面、情報漏洩についてコチラの記事を参考に検討が必要です。また、10月発生のNTTドコモ通信障害のように、ネットワーク障害により長時間クラウド利用ができないリスクもあります。

LibreOffice Community 7系

LibreOffice 7系公式資料とContents
LibreOffice 7系公式資料とContents

独)TDF:The Document FoundationのWindows/Mac/Linuxマルチプラットフォーム対応個人向け無償LibreOffice Communityは、Fresh(約1ヶ月更新の最新版)とStill(約3ヶ月更新の安定版)ともにバージョンが7系になりました。
※LibreOffice Communityと企業向けEnterpriseの違いは、コチラの関連投稿を参照してください。

Microsoft Office文書との互換性改善が主な改良点で、従来版との大きな変更はありません。弊社は、Microsoft Office 代替としてLibreOfficeを推薦しており、LibreOfficeの使い方や、Writer/Drawテンプレートなども無料提供しています。

Drawは、Microsoft Office Visio相当の図形描画ツールです。弊社は、超高価なVisio代替にDrawへ移行しつつあります。

初歩的な使い方は、上記テンプレートでカバーしています。英語版ですが、7系の使い方や、Writer/Draw/Clacの詳細な使い方は、PDF公式資料がコチラからダウンロードできます。

残念ながら日本語版(機械翻訳)は、404エラーで使えない状態です。但し、PDF資料の目次(=Contents)が判り易くできているので、不明箇所をピックアップして読めば使用方法が判ります。

注目してほしいのは、ダウンロード資料の出来栄えです。高品質資料が、無償LibreOfficeを使って作成できることが判ります。

文書作成ツールとPCプラットフォーム

ビスネスPCのOSは?
信頼性重視ビスネスPCのOSはWindows、Mac、Unixのどれが良いか?

PC技術の最新ドレンドは、メタバースやアバターです。コンタクトレス・テクノロジーと呼ばれます。MicrosoftNVIDIAなど多くのIT企業が仮想世界の実現に向けて邁進中です。

COVID-19が影響しているこれらトレンド実現には、Windows 11要件、TPM:Trusted Platform ModuleなどによるPCプラットフォーム、つまりクラウドエンドポイントのセキュリティ強化が必要です。アバター本人確認や、なりすまし防止などが必須だからです。

一方、コンテンツ作成を主機能とする文書作成ツールMicrosoft Officeは、既に完成の域に達しています。LibreOfficeは、Microsoft Office文書互換性向上を目指し改版を続けるでしょうが、価格を除く両者の差は、少なくなってきました。要は、ユーザ操作の慣れの問題で、コンテンツ作成機能差は無いと言っても良いでしょう。

経済的理由や各種リスクから、クラウドサービスよりも、ローカルPC処理が筆者は好みです。本稿の文書作成ツール状況を踏まえ、2025年10月14日までに、弊社に適すPCプラットフォーム整備を進めます。

主要ベンダのIoT MCU開発環境は、既にマルチプラットフォーム対応済みです。良質な開発資料を顧客へ提出するのは、開発者の責務です。コンテンツ資料作成の観点から、文書作成ツールとPCプラットフォームを検討する際に、本稿がお役に立てば幸いです。

STM32 Innovation Day 2021の歩き方

メタバース会場Mapとメニュー
メタバース会場Mapとメニュー

11月10日(水)から本投稿日12日(金)17時まで開催中のSTマイクロエレクトロニクス主催、オンライン・コンファレンスとAI、Security&Cloud、Ecosystem展示会場の歩き方を説明します。インターネット仮想空間:メタバースの移動方法です。

メタバース会場Mapと移動方法

ログインし会場入り口はこちらをクリックすると、表示されるのが最初の図、左下が会場Map、右上がメニューです。

Map内●が、現在位置:会場入り口、が、移動可能な6位置を示します。図中央の位置の移動や視点を変える方法は、Google Mapと同じ要領です。左下の+-△▽などでも移動可能です。メニューは、移動ショートカットです。

つまり、STM32 Innovation Day 2021会場が、インターネット上の仮想空間(メタバース:後述)で実現され、このメタバース内をGoogle Mapの方法を使って自由に移動するしくみです。

コンファレンスとバーチャル展示会

メタバース内は、ライブ配信のコンファレンスと、期間中いつでも入れる5か所のバーチャル展示会の2つから構成されます。

毎日13:00から17:00までのライブ配信コンファレンスは、日程の時のみコンファレンス内容が視聴可能です。一方、バーチャル展示会は、開催期間中は、24時間いつでも視聴ができます。

追記:各種資料(※基調講演および一部セッションを除く)は、11月30日(火)17:00までダウンロード可能なので、イベント開催期間中に参加できなかった方や、もう一度ご覧になりたい方は、利用できるそうです!

バーチャル展示会内操作

Product展示会の操作
Product展示会の操作

Product位置へ移動した例が上図です。「製品・デモ」をクリックすると、パネル内容に関する日本語説明員による動画、開発ボード説明やダウンロード資料などが入手できます。

つまり、現実の展示会と同じです。残り4か所の展示会へのGoogle Map移動が少し面倒ですが、各展示会とも同じ構成ですので楽しめます。位置移動は、ブラウザの戻る(履歴)や「MAP」クリックの方が簡単です。

アンケート回答でボードが当たるかも?

右下「退出する」クリックで示されるアンケートに答えると、大量370名に当たる開発ボードプレゼントキャンペーンが実施中です。もちろん、これら開発ボードは、前章の5展示会でその詳細が確認できます。ブラウザ履歴で展示会へ戻り、応募ボード内容を再確認するのも良いでしょう。

メタバース

メタバースとは、メタ (meta-) とユニバース (universe) の合成語です(Wikipediaより)。今回のSTM32 Innovation Day 2021では、アバターは使いませんが、今後は、自分のアバターと会場説明員アバターが登場し、技術解説や質問・回答を行うなど、現実世界をより仮想化した展示会やコンファレンスへ発展するかもしれません。

COVID-19の影響で、人の密集を避ける会議やイベントは、メタバースやアバター活用がトレンドです。一部ゲーマー向けだった高性能GPU搭載PCが、ビジネス分野へも普及するきっかけになります。PCやスマホ超高性能化が、MicrosoftやMeta(旧Facebook)の狙いでしょう。

クラウドベースMCU開発(個人編)

クラウドベースMCU開発お役立ちリンク
クラウドベースMCU開発お役立ちリンク

ARMが、2021年10月19日、IoT関連製品の開発期間を平均5年から最大2年間短縮できるクラウドベース開発環境「Arm Total Solution for IoT」発表という記事(EE Times Japan)は、以下の点で興味深いです。

・IoT製品化に平均5年もかかるのか?

・ハードウェア完成を待ちソフトウェア開発着手するのか?

但し、クラウドがMCU開発に効果的で、GitHubなどのクラウドリンクが今後増えることは、疑う余地がありません。そこで、すきま時間に個人レベルで役立つクラウドMCUリンクを3点示します。

すきま時間お役立ちクラウドMCU開発リンク

クリエイティブなMCUハードウェア/ソフトウェア開発中は、集中時間と空間が必要です。COVID-19の影響で、開発場所や通勤環境に変化はあるものの、ちょっとした待ち時間や出先での2~3分程度のすきま時間は相変わらず存在します。

個人レベルのIoT MCU開発支援が目的の弊社は、このような短いすきま時間にスマホやタブレットを使って、MCU情報を収集、閲覧するのに便利なリンクを紹介します。

すきま時間にMCU関連情報を閲覧することにより、集中時間に凝り固まった開発視点を新たな視点に変える、最新情報を収集するなどが目的です。

STマイクロMCU技術ノート

STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)
STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)

STマイクロのSTM32/STM8シリーズ別に検索できる日本語MCU開発Tips満載リンクです。ログインが必須ですが、わずか数ページで説明されたダウンロードPDF内容は濃く、STユーザに限らず全てのMCU開発者に役立つTipsが得られます。

EDN Japan Q&Aで学ぶマイコン講座

EDN Japan Q&Aで学ぶマイコン講座の一部
EDN Japan Q&Aで学ぶマイコン講座の一部

EDN JapanのMCU情報リンクです。Q&Aで学ぶマイコン講座は、最初の1ページでMCU初心者、中級者からの質問に対する回答要点が示されています。2ページ以降で回答詳細を説明するスタイルですので、短時間での内容把握に適しています。

Digi-Keyブログ

Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)
Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)

日本語タイトルで日本語へ翻訳されたブログ記事が判るリンクです。大手サプライヤーの英語ブログですのでMCUだけでなく、幅広いデバイス情報が得られます。すきま時間でも読めるように記事は短く纏まっています。最新MCU情報やハードウェア開発者向け情報が多いのも特徴です。

IoT製品とプロトタイプ開発

EE Timesの2021年10月8日、半導体製品ライフサイクルの長さと製造中止対策の記事に、20年前、1990年代の事業分野別の製品開発リードタイムとライフサイクル変化が示されています。

事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)
事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)

1998年の値ですが、重電機器を除く製品開発時間(リードタイム)が2.3年以内という数値は、現在でも納得できます(0.5年程度のプロトタイプ開発時間は含んでいない実開発時間だと思います)。

MCUベンダ各社は、10年間のMCU供給保証を毎年更新します。つまり、2021年更新ならば、2031年迄の10年間は販売MCUの供給を保証するということです。

但し、セキュリティが重視されるIoT製品では、最新セキュリティハード/ソフト内蔵IoT MCUによる製品化をエンドユーザは望みます。SoC:System on a Chipによる製造プロセス進化により、IoT関連製品の開発期間は、再開発も含めると1998年よりも更に短くなる可能性もあります。

前章リンク情報を活用し、最新セキュリティ内蔵MCU状況、セキュリティ機能のOTA更新可能性、開発製品がエンドユーザのセキュリティニーズと開発コストを満たすか、などを個人でも常時把握・評価し、万一、開発製品の成功見込みが少なくなった場合には、MCU見直しなども必要でしょう。

IoTセキュリティのライフサイクルは変動的で、かつ、IoT製品の市場獲得に支配的です。短い開発時間中であっても、状況に応じてMCUを変更することは、製品の成功と失敗に直結します。

弊社MCUテンプレートを使ったプロトタイプ開発は、このような激変IoT製品開発のMCU評価に適しています。制御系MCUと被制御系を分離、低コスト、少ない手間でプロトタイプを早期に開発し、プロトタイプ実機によりIoT製品のMCU評価、適正判断ができるからです。

もちろん、最初に示したバーチャルなArm Total Solution for IoTとの併用も有効です。セキュリティ重視IoT製品開発の成功には、IoT MCU選択と開発期間の短さがポイントです。

Bluetooth 5.3 LE対応RA開発中

Bluetooth 5.3対応の開発中RA MCU
Bluetooth 5.3対応の開発中RA MCU

2021年10月21日、ルネサスは、最新規格Bluetooth 5.3 Low Energy(LE)対応のRAファミリ新MCUを開発中と発表しました。RA搭載予定のBluetooth 5.3 LE機能と、ルネサス32ビットMCU におけるRAファミリの位置づけを示します。

搭載予定の最新Bluetooth 5.3 LE機能

PCとキーボード、スマホとヘッドホン間など近距離低消費電力無線通信規格としてBluetooth 5は、広く用いられています。MCU搭載例も多く、本ブログでも何件か投稿してきました(STマイクロのSTM32WB、Cypress/InfineonのPSoC6、NXPのKW41Z、Bluetooth 5規格)。

RAファミリでもBluetooth 5対応RA4W1が発売中です。開発中のRAは、新規格Bluetooth 5.3対応MCUです。

Bluetooth SIGが2021年7月13日に発表した新規格Bluetooth 5.3は、Bluetooth 5に、スループットと信頼性、エネルギー効率向上など様々な機能を追加しました。詳細は、Bluetooth SIG サイトのBluetooth Core Specification v5.3で判ります。

開発中の新RAには、これらBluetooth 5.3機能に加え、Bluetooth 5.1で追加された方向検知機能、Bluetooth 5.2で追加されたステレオオーディオ伝送用アイソクロナスチャネルも対応予定です。また、ソフトウェア無線(SDR)機能の搭載により、後日リリースされる新たな規格への移行も可能だそうです。

つまり、新RAは、Bluetooth 5以降の新Bluetooth機能満載のIoT MCUで、しかも、SDRにより新しい機能追加も可能な、“万能”近距離低消費電力無線通信付きIoT MCUになりそうです。

2022年1~3月サンプル出荷予定

最新規格Bluetooth 5.3 Low Energy対応、開発中RA MCUのサンプル出荷は、2022年第1四半期(1~3月)が予定されています。

RAファミリ位置づけ

独自コア、ARMコア、開発環境など様々なルネサス32ビットMCUファミリ差が一目で判る図が、コチラの記事にあります。

RAファミリ位置づけ(出展:記事に加筆)
RAファミリ位置づけ(出展:記事に加筆)

IoT MCU開発者の立場からRAファミリを分析すると、

・ARM Cortex-M33/M23/M4コア採用でIoTセキュリティ強化
・Eclipse IDEベースのKeilやIARなどのARM Ecosystemと無償GNUコンパイラが使える

などRXファミリやSynergyでは不可能であった、手軽で低コスト、個人レベルでも開発可能な32ビットIoT MCUと言えます。

RAファミリ向けルネサスEcosystemは、Eclipse IDEベースのe2 studioです。また、RAファミリ専用Flexible Software Package(FSP)によるAPI生成ツールは、ピン互換性、周辺回路共通性があるため、RAファミリ内での開発ソフトウェア移行や移植も容易になる特徴があります。

無償GNUコンパイラのFlash容量制限などもありません。

RAファミリ開発方法

開発中のBluetooth 5.3 LEが新たに周辺回路に追加されますが、e2 studioやFSPによるRAファミリ開発方法は、汎用RA MCUのRA4E1 Fast Prototype Boardの使い方や、FreeRTOSの使い方と同じです。

RAファミリ開発の早期着手、習得したい方は、上記リンクを参考にしてください。

Flexible Software Package v3.4.0更新

FSPは、10月7日にv3.4.0へバージョンアップしました。

e2 studio 2021-10のHelp>check updatesではFSP v3.3.0から自動更新しません。FSPサイトから最新v3.4.0をダウンロードし、手動でアップグレート更新する必要があります。

Flexible Software Packageのアップグレード
Flexible Software Packageのアップグレード

v3.4.0を別の場所にインストールすれば、旧v3.3.0との併存も可能です。