IoT MCUのHappyTech

Azure RTOS習得(1)：習得方針

2022年5月27日2022年6月10日 WithHappy

Microsoft公式、Azure RTOS ThreadXサイトを紹介します。

前稿最後で示したSTM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解には、Azure RTOS ThreadX基礎知識が必要です。基礎知識獲得には、Microsoft公式サイトが最適です。

本稿は、公式サイトを簡単に説明し、今後のAzure RTOS習得方針を示します。

Azure RTOS習得方針

筆者は、物事を効率的に理解する時、初めはあまり細部に拘らず全体を俯瞰的に捉え、次の段階で不明な点を明らかにする、既に知っている事柄と比較する、などの方法を好みます。

Azure RTOS習得も、この方法でアプローチしたいと思います。

これは、FreeRTOS習得（2020年版）と同じ方法です。その結果、開発したのがNXP版FreeRTOSアプリケーションテンプレートです。

最終的には、STM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解とST版Azure RTOSアプリケーションテンプレート開発、2022年版Azure RTOS習得サイト作成が目標です。

Azure RTOS ThreadX公式ユーザガイド

公式サイトトップページには、Azure RTOS概要と、ユーザガイドのショートカットが掲載されています。概要は、疲れた時や気分転換時に読むとして、肝心のAzure RTOS ThreadXユーザガイドをクリックします。

現れるのが、Azure RTOS ThreadXユーザガイド目次です。

第 1 章：Azure RTOS ThreadX 概要とリアルタイム組込み開発
第 2 章：Azure RTOS ThreadX インストール
第 3 章：Azure RTOS ThreadX 機能動作
第 4 章：Azure RTOS ThreadX API
第 5 章：Azure RTOS ThreadX アプリケーションドライバー作成
第 6 章：Azure RTOS ThreadX デモアプリケーション

第3章が、Azure RTOS ThreadX理解ポイントのようです。

Azure RTOSとFreeRTOS比較：状態遷移図、優先度

RTOS理解に必須なのが、スレッド/タスクの状態遷移です。左が第3章：記載のAzure RTOS、右が弊社FreeRTOS習得記載のFreeRTOS状態遷移です。Azure RTOSは、全5状態ありFreeRTOS比+1、スレッド登録後、即Suspendedになる遷移もあります。

RTOS処理対象を、Azure RTOSはスレッド、FreeRTOSはタスクと呼びます。

優先度は、Azure RTOSは数値が小さい方が高く、FreeRTOSは大きい方が高い、つまり真逆です。

などのAzure RTOSとFreeRTOSの違いが第3章から判ります。

Azure RTOS ThreadXサンプルコードキーワード

・ThreadX、Thread、Event flags、Preemption threshold

前稿最後で示したSTM32G4 Azure RTOS ThreadXサンプルコード付属readme.html記載のキーワードです。サンプルコード理解には、これらが重要であることを示しています。

公式ユーザガイド第3章日本語訳によると、Preemption thresholdとは、プリエンプション閾値のこと。Azure RTOS独特の高度機能です。この部分の要旨を抜粋すると、

・プリエンプション閾値利用で、プリエンプションを無効にする優先度の “上限” を指定可能。上限より高い優先度スレッドは、引き続きプリエンプト可能だが、上限より低いスレッドは、プリエンプト不可。
・優先度20スレッドが、15～20優先スレッドグループやり取りで説明。優先度20スレッドは、セクション処理中、プリエンプション閾値を15 に設定すると、他の全スレッドのプリエンプションを防止。
・これにより、非常に重要なスレッド (優先度 0 から 14 まで)は、クリティカルセクション処理中でもスレッドをプリエンプトでき、応答性が大幅に向上。
・スレッドでプリエンプション閾値を0に設定し、全プリエンプションを無効にすることも可能。また、プリエンプション閾値は実行時に変更可能。

英語原本の機械翻訳だと思いますので、解り難い箇所もありますが、今はOKとしましょう😂。

プリエンプション：Preemptionとは

プリエンプションとは何かを、IT用語辞典から抜粋しました。

・RTOSが、実行中のスレッド/タスクを強制的に一時中断し、他のスレッド/タスク実行に切り替えること。
・このRTOS切り替えを「コンテキストスイッチ」（context switching）と呼び、プリエンプションで停止していたスレッド/タスクを再開させる操作を「ディスパッチ」（dispatch）と呼ぶ。
・殆どの現代RTOSは、「プリエンプションを利用」し処理を時分割多重。
・歴史的には、スレッド/タスク側が自ら決めたタイミングで自発的にRTOSへ制御を返却するノンプリエンプティブマルチタスク、あるいは、協調的マルチタスクもあった。

Azure RTOS/FreeRTOS、どちらもプリエンプションを利用します（FreeRTOSは本稿：状態遷移参照）。違いは、Azure RTOSが、スレッド毎にプリエンプション閾値を持つこと。RTOS任せにせずスレッドが、明示的に優先度制御を行う点です。

STM32G4 Azure RTOS ThreadXサンプルコードは、このスレッドによる優先度変更とイベントフラグが解れば解析できそうです（次回解析予定）。

まとめ

Microsoft公式Azure RTOS ThreadXサイトを利用したAzure RTOS習得方針を示しました。

STM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解に、Azure RTOS ThreadXユーザガイド第3章から、

・Azure RTOSとFreeRTOS状態遷移は異なる
・Azure RTOS優先度は0が最高位、FreeRTOSは値が大きい程優先度が高く、両者は真逆
・Azure RTOSスレッド応答性を向上させるPreemption threshold：プリエンプション閾値機能がある

などが判りました。この方針に則って、Azure RTOS習得を続けます。

STM32 Azure RTOS開発ツール拡充

2022年5月20日2022年5月27日 WithHappy

2022年4月20日、STマイクロエレクトロニクス（以下ST）は、Azure RTOS開発ツールを拡充し、より幅広いSTM32MCU対応を発表しました。拡充したSTM32MCUリストが下記です。

List of STM32 with X-Cube-AZRTOS Package（出典：The ST blog）

弊社販売中STM32G0xテンプレートで使ったSTM32G0や、テンプレート開発中のSTM32G4も、Azure RTOS開発が容易になりました。

CMSIS RTOSからAzure RTOSへ

今回の発表前までは、販売中のNXP版FreeRTOSアプリケーションテンプレートに続き、STM32G4を使ってST版“CMSIS-RTOS”アプリケーションテンプレートを構想していました。

しかし、今回のAzure RTOS開発ツール充実発表を受け、“CMSIS-RTOS”から“Azure RTOS”対応へ変更することにしました。STのAzure RTOSサンプルコードが活用でき、また、Microsoft公式Azure RTOS情報もあるからです。

※ARM社規定のCMSIS RTOSは、FreeRTOSやAzure RTOSをラップ（wrapper）するRTOSです。同じCMSIS RTOS APIでFreeRTOSまたはAzure RTOSが使え、開発アプリケーション流用性は高まります。但し、ラップ関数分のオーバーヘッドが生じます。詳しくは、構想投稿の4章を参照してください。

STがAzure RTOS開発ツールMCUを拡充した背景は、Microsoft Azureクラウド接続IoT MCUの急増だと思います。リストアップした9種のSTM32MCUが、IoT MCU有力候補と言えます。

Azure RTOS開発ツールインストール方法

STM32G4を例に、Azure RTOS開発ツールインストール方法を示します。現在のSTM32G4開発ツールが、下記版数です。

・STM32CubeIDE v1.9.0               （以下CubeIDE）
・STM32CubeMX v6.5.0               （以下CubeMX）
・STM32Cube FW_G4 v1.5.0        （以下FW_G4）
・X_CUBE_AZRTOS_G4 v1.0.0    （以下AZRTOS_G4）

X-CUBE-AZRTOS-G4が、今回発表したSTM32G4のAzure RTOS開発ツールです。

FreeRTOSは、CubeMXのMiddlewareに実装済みです。一方、Azure RTOS は、ExpansionsパッケージのAZRTOS_G4によりCubeMXへ機能追加します。Expansionsパッケージ追加のため、少し手間がかかります。

① CubeIDEのHelp>Manage Embedded Software Packagesクリック
② Embedded Software Packages ManagerのSTMicroelectronicsタブ選択
③ X_CUBE_AZRTOS_G4のAvailable Version 1.0.0を選択し、Installクリック

AZRTOS_G4インストール後、使用コンポーネントの選択が必要です。

④ CubeMXのPinout & Configurationタブ内Software Packsをクリック
⑤ Select Components（Alt+O）を開き、Software Packs Component Selectorで追加Azure RTOSコンポーネント：RTOS ThreadX/File system FileX/USB LevelX…などを選択し、OKクリック

STM32G4評価ボード：NUCLEO-G474REを使う場合は、RTOS ThreadXを選択し、Core/Low Power supportを選択すれば十分です。但し、念のため、Performance InfoやTraceX supportも選択しておきます。

インストールしたAzure RTOS ThreadX版数が、6.1.8であることも判ります。

Azure RTOS ThreadXサンプルコードインポートと動作確認

インストールしたAZRTOS_G4が正常動作するかをAzure RTOS ThreadXサンプルコードと評価ボード：NUCLEO-G474REで確かめます。確認方法が下記です。

① CubeIDEのInformation CenterからImport STM32Cube exampleをクリック
② STM32 Project from STM32Cube ExamplesのExample Selectorタブで、BoardのName：NUCLEO-G474RE、Middleware：ThreadXを選択

STM32G4評価ボード：NUCLEO-G474REのAzure RTOSサンプルコード

STM32G4 Azure RTOS ThreadXサンプルコードは、現在3個です。最も基本的な、

③ Tx_Thread_Creationを選択し、Finishクリック。CubeIDEへTx_ThreadX_Creationサンプルコードがインポート。
④ CubeIDEのTx_Thread_Creation.iocをクリックし、CubeMXで、Generate Code（Alt＋K）を実行
⑤ CubeIDEでTx_Thread_Creationをビルドし、評価ボードへダウンロード
⑥ 評価ボードのLED2が、500ms点滅と200ms点滅を3回繰返し、その後1秒点滅に変わる

以上で、STM32G4 Azure RTOS開発ツールのX_CUBE_AZRTOS_G4インストールを、ThreadXサンプルコードで動作確認しました。

使用したTx_ThreadX_Creationサンプルコードの説明は、次週以降に行う予定です。直ぐ知りたい方は、Tx_ThreadX_Creationフォルダ内readme.htmlを参照してください。

まとめ

STが、STM32G0やSTM32G4、STM32U5などのIoT MCUに対し、Azure RTOS開発ツール拡充を発表しました。

STM32G4を例に、CubeMXへExpansionsパッケージのX_CUBE_AZRTOS_G4でAzure RTOS機能の追加方法、Azure RTOS ThreadXサンプルコードインポート、NUCLEO-G474REでThreadXサンプルコードの動作確認をしました。

STM32G0（Cortex-M0+/64MHz）、STM32G4（Cortex-M4/170MHz）、STM32U5（Cortex-M33/160MHz）は、弊社IoT MCUテンプレートの開発対象です。

今回の発表を受け、STM32G4のRTOSを、CMSIS-RTOSからAzure RTOSへ変更し、ST版Azure RTOSアプリケーションテンプレート開発を計画中です。

RAファミリのRTOS

2022年5月13日2022年5月20日 WithHappy

RAファミリは、FreeRTOSとAzure RTOS、両方に対応しています。このうち、FSP v3.6.0でサンプルコードを提供しているのがFreeRTOSです（プロジェクト名：freertos_評価ボード名_ep）。

本稿は、このFreeRTOSサンプルコードを簡単に解説します。

キューとセマフォ利用サンプルコード

freertos_fpb_ra6ep1_epのユーザ追加部分とFSP生成ソースコード

最新版FSP v3.6.0のRA6E1評価ボードサンプルFPB-RA6E1 Example Project BundleのRTOSサンプルコードが、上図freertos_fpb_ra6e1_epです（freertos_fpb_ra4e1_epも同じ）。

ユーザ追加RTOSタスク：キュー送信タスク、受信タスクと、定期割込みでセマフォ生成し、生成セマフォ取得でRTT Viewerへメッセージ出力するタスクの、合計３タスクを追加（タスクプライオリティ同一）。

ユーザ追加RTOSオブジェクト：キューとセマフォの2オブジェクトを追加。

FSP生成ソースコード：追加タスク毎にFSPが entry.c 生成（中身は、下図右側）。

基本的には、FreeRTOS公式Hardware independent FreeRTOS exampleや、弊社NXP版FreeRTOSアプリケーションテンプレートと同様の処理。

詳細は、FreeRTOSアプリケーションのQueueデータ送受信やFreeRTOSサンプルプロジェクトfreertos_generic詳細などの関連投稿をご覧ください。

RAファミリRTOS現状まとめ

FSPを使ったRAファミリFreeRTOS/Azure RTOSの現状をまとめると、下記です。

・FreeRTOS習得スタートは、キューとバイナリセマフォオブジェクト理解（弊社FreeRTOSアプリケーションテンプレートも同様）。
・ベアメタル開発では使わないObjects窓へ、バイナリセマフォ/ミューティックス/キューなどFreeRTOSの8オブジェクト追加。Azure RTOSは4オブジェクト追加。

・Azure RTOS関連資料は、Microsoft公式のコチラ。
・FSP v3.6.0提供FreeRTOSサンプルコード数は、1個。Azure RTOSサンプルコードは未提供。

あとがき

RAベアメタルテンプレートを先週発売した直後に今回RTOSの投稿をしたのは、ベアメタル/RTOSに関係なく「RAファミリ開発の鍵はFSP」を示したかったからです。

FSPは、RAファミリのMCU資源（MCUコア/内蔵周辺回路など）を対象に、HAL APIを生成するツールです。開発者は、FSPが生成したHAL APIを使ってRAファミリのアプリケーションを開発します。

FSP対象は、ベアメタルの場合は、MCUコアやIOポートなど実際の回路、RTOSの場合は、タスクやスレッド、RTOSが提供するセマフォやキューなどの様々なオブジェクト（≒仮想回路）が、ベアメタル対象に加わるだけと考えると判り易いと思います。

FSPは、ベアメタル開発用をベースにRTOS開発へも対応し、プライオリティなどRTOS独特の設定も、ベアメタルと同様のGUIで設定します。

つまり、ベアメタルとRTOS両方対応FSPを上手く使いこなせるかが、RAファミリソフトウェア開発の鍵です。効率的にFSPを習得する最初のツールが、RAベアメタルテンプレートと言えます😄。

次の段階、つまりRTOS開発へ対応したRAテンプレートも思案中です。ただ、RAベアメタルテンプレートご購入者様からの様々なフィードバックやFSPのRTOSサンプルコード数が増えた後、暫くしてから実現するつもりです。

先ずは、RAベアメタルテンプレートでRAファミリ開発の鍵、FSPを習得してください。ご購入、お待ちしております。

RAベアメタルテンプレート発売

2022年5月6日2022年5月13日 WithHappy

FPB-RA4E1で動作中のBaseboardTemplateとRTT Viewer

ルネサスCortex-M33コア搭載RAファミリ向けRAベアメタルテンプレート（税込1000円）を本日より発売します。概要、仕様、テンプレート提供プロジェクト構成は、コチラから無料ダウンロードできますので、ご検討ください。

RAファミリのポジション

ルネサスのARM Cortex-M系MCUは、競合他社比、発売が出遅れました。RXやSynergyなどの独自32ビットMCUファミリも供給中のルネサスRA位置づけが上図です。詳細は、コチラの関連投稿3章に説明済みです。

まとめると、RAファミリは、外付けE2エミュレータなどが不要の低価格評価ボードと容量制限なし無償コンパイラ利用など、他のルネサス32ビットファミリには無い個人レベルでも開発可能なARM Cortex-M33/M23/M4コア採用IoTセキュリティ強化MCUです。

RAファミリ開発の鍵：FSP

RAファミリ開発の鍵は、FSP：Flexible Software Packageです。一言で言うと、HAL APIコード生成ツール。MCU動作速度、内蔵周辺回路などのパラメタをGUIにより設定後、RAファミリ間で共通のHAL APIを一括生成します。
※HAL：Hardware Abstraction Layer

FSP活用で、RAファミリ間での移植性に優れたソフトウェア開発ができます。しかしながら、多くのパラメタをGUI上で設定するため、煩雑で特に初心者にとっては取っ付きづらい面もあります。

また、競合他社より後発のIoT向けMCUですので、FreeRTOSやAzure RTOS、TrustZoneなどのIoTセキュリティにも対応しています。RAファミリの拡張性、将来性を提供するツールがFSPです。

つまり、FSP習得が、RAファミリを使いこなす鍵です（コチラの関連投稿で詳細が判ります）。

RA6/4E1グループ選択理由

様々なラインナップを供給するRAファミリの中で、汎用性と超低価格な評価ボードも供給済みなのが、RA6E1グループ（Cortex-M33/200MHz）とRA4E1（Cortex-M33/100MHz）グループです。

※RA6E1評価ボード：FPB-RA6E1、RA4E1評価ボード：FPB-RA4E1

RA6/4E1グループとFSPで開発したソフトウェアは、RAファミリ間で共通に使える汎用性を持ちます。また、評価ボードで動作するFSPサンプルコードもありますので、FSP習得にも適しています。

RA6とRA4の分岐点は、最大動作周波数です。

240MHz動作のRA6は、大容量Flashを搭載し、高性能で多機能MCUマーケットを狙い、更に高性能なRA8シリーズへの発展性があります。100MHz動作のRA4は、高性能低消費電力MCUマーケット狙いで、Cortex-M23搭載5Vトレラント性も持つRA2シリーズへ高い親和性を持ちます。

従って、RAファミリ開発を始めるMCUとして、RA6/4E1グループいずれも適していると言えるでしょう。

※RA6最大動作周波数は、カタログでは240MHzとありますが、RAベアメタルテンプレートで用いた評価ボードFPB-RA6E1は、最大200MHz動作です。他RA6シリーズも、同様に現在200MHzです。
※RA8シリーズは、未発売です。

実務直結RAベアメタルテンプレートでFSP習得

近い将来、RTOSやTrustZoneなど、多くのIoT MCU技術を学ぶ必要があります。それでも、MCUの基本技術は、ベアメタルです（コチラの関連投稿参照）。

弊社RAベアメタルテンプレートVersion 1は、RAファミリ中核汎用RA6/4E1グループの超低価格評価ボードを使い、基本のベアメタル開発で、効率的にFSPを習得することが目的です。

FSP習得には、評価ボードサンプルコードが適しますが、サンプルコードは、複数処理が当然の実務応用が簡単ではありません。弊社テンプレートは、複数サンプルコードの活用・流用が簡単で、実務にも使えます。

弊社テンプレートと詳細な説明資料、安価で簡単、拡張性にも優れた推薦開発環境を使えば、誰でも簡単にMCUベアメタル開発の高い障壁を乗越えられ、かつ、FSP習得も可能です。

RAベアメタルテンプレート購入方法は、コチラを参照してください。ご購入、お待ちしております。

ツイッター買収

2022年4月29日2022年5月6日 WithHappy

2022年4月26日、CNN Japanは、米電気自動車大手テスラのイーロン・マスク最高経営責任者（CEO）が、約440億ドル（約5兆6000億円）でツイッター社買収の見通しを報じました。買収には、株主と規制当局の承認が必要になるそうですが、年内買収完了見込みです。

ツイッターはデジタル広場

マスク氏は、「⾃由な⾔論は機能する⺠主主義の要であり、ツイッターは⼈類の未来にとって重要な問題が議論されるデジタル広場だ」と指摘し、「ツイッターには大きな可能性がある。それを解放するために同社やユーザのコミュニティーと協⼒することを楽しみにしている」と表明しています（4月27日、CNN Japan）。

WordPressブログDescription流用

弊社も2021年8月からツイッター投稿を始めました。アカウント自体は、2013年から所有しておりましたが、休眠状態でした。

投稿復活の理由は、ツイッターの最大140文字投稿が、ブログ要約表示に適すと思ったからです。

WordPressブログでも要約：Description（120文字前後）作成が、必要です。このDescriptionは、サイト検索時に表示されます。従って、かなり気を配ってDescriptionを作成します。

この気配り結果を、WordPressだけでなく、ツイッターにも流用すれば、ブログ閲覧数上昇になるかも？と考えた訳です。マスク氏表明とは、雲泥の差です…😅。

ツイッター投稿を始めて8ヶ月程経過しましたが、ツイート効果は、見られません😭。

という訳で、暫くは買収の様子見です。しかしながら、ツイッターが有料にでも変われば、ツイッターアカウントは削除するかもしれません。その際でも、弊社WordPressブログ投稿は、引続きよろしくお願いいたします。

RAベアメタルテンプレート完成、次の金曜詳細投稿

昨年末より開発してきましたルネサスCortex-M33コア採用RAファミリのベアメタルテンプレートが、完成しました。最新開発環境のFSP v3.6.0、e2 studio 2022-04を用いました。FPB-RA6E1とFPB-RA4E1両評価ボードで動作確認済みです。詳細は、次の金曜に投稿いたします。

Windows 10 21H2提供制限解除

2022年4月22日2022年4月29日 WithHappy

2022年4月15日、Microsoftは、最新版Windows 10 21H2提供制限を解除し、広範囲な配布を開始しました。旧Windows 10バージョンのユーザは、GW連休期間に最新版への更新をお勧めします。

Windows提供制限とは？

Windows大型更新の失敗は、ビジネスの遂行停止を招きます。重大インシデントです。

従来の「勝手なWindows更新」で発生する重大インシデント回避のため、Microsoftは、最新版Windows 配布とそのトラブル発生状況を調査しながら提供範囲を少しずつ広げる配布方法を用いました。

この方法により、Windows大型更新は、「ユーザの好きなタイミング」で行う事に変りました。

PCが旧版Windowsのまま運用される原因の1つが、この「ユーザ主体更新」が周知徹底されていないためです。更新とセキュリティを開き、Windows Updateに新しいWindows機能更新通知の有無を確認、更新プログラムがあれば、最新版Windowsへの更新をお勧めします。

Windows 10 21H2手動更新方法

筆者の好きなタイミングで行うWindows 10 21H2手動更新方法が、コチラです。

残念ながら、Windows更新には失敗がつきものです。

失敗原因は、更新プログラム起因の場合や、ユーザ操作ミスなどの場合があります。Windows 10 21H2が広範囲提供になったことは、前者の更新プログラム起因が少なくなったことを意味します。

それでも失敗の可能性はあります。対策は、失敗前へユーザ自身がリカバリできることです。さもないと、最悪のWindowsクリーンインストールを招きます。

Windowsにも標準リカバリツールは、あります。しかし、肝心の失敗時に標準リカバリツールで完全に元に戻った経験が筆者はありません。そこで、別途イメージバックアップツールなどの対策を取っています。

Windows 10 21H2サポート期間と次回22H2大型更新

Windows 10 21H2 Home/Proサポート期間は、リリース後18ヶ月の2023年6月13日、残り約1年です。Windows 10自体のサポート終了は、2025年10月14日、残り3年半です。混同しないよう注意しましょう。

また、Windows 10大型更新は、年1回へ変更されました。次回Windows 10 22H2大型更新は、今秋の予定です。

「ユーザ主体更新」ですので、弊社は、Windows 10 22H2リリース後、タイミングを見計らい早急に21H2からWindows 10 22H2へ手動更新するつもりです。結果は、本ブログで投稿します。

パーソナルなツールのユーザ責任

新車は3年目、それ以外の車は2年毎に車検があります。自家用車の重大インシデントを避けるため、車検は最低限のユーザ義務です。公道での安全走行ができる保証が、車検とも言えます。

同様にパーソナルなPCも、ユーザの責任でメインテナンスは必須です。このメインテナンスの基となるパラメタは頻繁に変更されます。本稿で示した最低限知っておくべきパラメタが下記です。

・最新版Windows 10 21H2供給制限解除：2022年4月15日
・Windows 10 21H2サポート期間：2023年6月13日
・Windows大型更新：年1回、ユーザ主体更新必要
・Windows 10サポート終了：2025年10月14日
・Windows Update：定期的ユーザ確認必要

GW連休は、これらパラメタと最新版Windows 10 21H2更新、PC最新状態の確認に適した期間です。

最新状態は、PCセキュリティも最強です。強いセキュリティは、ネットワークで繋がったサイバー攻撃も防げ、安全なLAN構築、つまり、ネットワークの重大インシデント回避ができます。

ユーザ責任による個々のPC最新状態維持は、もはや「単体ユーザのPCセキュリティ強化だけでなく、ネットワークレベルのセキュリティ強化」に繋がる訳です。

なお、Windows 11アップグレード要件を満たさないWindows PCは、Windows 10サポート終了の2025年10月で寿命を迎えます。寿命を延ばすには、強引にWindows 11へアップグレードするか、または、新しいLinuxへOSを変えるかの2択です。

前稿で、強引にWindows 11アップグレードした評価結果を示しています。ご参考まで。

Windows 11非対応PCアップグレード

2022年4月15日2022年7月16日 WithHappy

Windows 11要件を満たさないWindows PCの寿命は、2025年10月14日までの残り3年半です。Windows 10が快適に動作するPCでも、この寿命は同じです。

延命するには、強引にWindows 11へアップグレードするか、または、Linux載せ替えの2択です。Linux化は、専用機を用いて載せ替えリスクを評価中です。

本稿は、Windows 11要件未達PCのアップグレード結果をレポートします。

下記内容です。
①：結論（Windows 11要件未達PCをアップグレードして使えるか？）
②：アップグレードWindows 11 21H2のWindows 10アプリケーション動作
③：Windows 11 21H2利点と欠点
④：アップグレート方法
⑤：Windows 11要件未達PCアップグレード所感

①：結論（Windows 11要件未達21H2アップグレードのまとめ）

本稿の目的は、Windows 11要件を満たさないPCを、Windows 10アプリケーションとデータを維持したまま11へアップグレードしても使えるか、つまり、Windows PC延命ができるか否かを評価することです。

総括結論が、以下です。
Windows 11要件未達PCをアップグレードしても、Windows 10アプリは正常動作、2022年4月時点では、Windows 11 21H2として運用できる。

＊　　＊　　＊

詳細が、以下です。
Windows 11は、年1回、予定では今秋に大型更新を行います。誰もが入手できる最新機能確定版は、Windows 11 21H2です。本稿もこの21H2で試行しました。

対象は、TPM 2.0実装無し以外は、Windows 10 21H2が正常・快適に動作するPCです。

1週間の試行中、TPM 2.0有無がWindows 11のWindows Updateなど運用上、問題を与えることはありませんでした。また、Windows 10で動作したMCU開発ツールは、Windows 11上でも正常動作しました。

その他、モニタ下側だけのツールバー位置固定などWindows 11に使いにくい点は、多々あります。ただ、慣れの問題で許容範囲内とも言えます。年1回の大型機能更新で、これら欠点は改善されるかもしれません。

追記が、以下です。
Microsoftは、TPM回避Windows 11アップグレード方法を公開するなど、Windows 11要件は、現在曖昧です。しかし、ウクライナ危機により、より強固なセキュリティ要件を設定する可能性があります。曖昧なのは、共産圏へのWindows 11販売に配慮した結果と推測するからです。

従って、あくまで投稿時点のWindows 11 21H2要件未達PCでの結果であることに留意してください。

本投稿と同じ要件未達PCアップグレート評価を、今秋11大型更新後の22H2に再適用する予定です。結果が変わるかは、お楽しみです。

②：MCU開発ツール動作

弊社は、MCU開発ツールの動作環境としてWindows PCを利用します。

各社MCU開発ツールの公式推薦動作環境は、投稿時点はWindows 10です。そこで、アップグレートWindows 11で、MCU開発ツールが正常に動作するかをテストした結果が下記です。

・NXP）MCUXpressoIDE_11.5.0_7232動作
・ST）STM32CubeIDE_1.9.0動作
・Renesas）e2studio_v2022-01_fsp_v3.6.0動作

その他、LibreOffice等のWindows 10アプリも、Windows 11で正常動作しました。

また、アップグレード後、Windows Updateも問題なく動作します。

③：Windows 11 Pros Cons

Windows 10ユーザの立場から、Windows 11 21H2利点と欠点を評価します。

利点は、使い慣れたWindows PC寿命が、とりあえず延びることです。

欠点は、セキュリティ強化以外のWindows 11設計指針が見えないことです。Windows 10の何をどのような目的で改良したかが不明確なので、使いにくいと感じる箇所が多々あります。コチラの記事に対策がまとまっています。

また、従来は真四角のフォルダ表示が、角が丸みを帯びた表示に変わるなど、グラフィック能力を無駄に消費していないかも不安です。

④：要件未達PCアップグレート方法

Windows 11要件を満たさない、つまり、TPM 2.0無し、セキュアブート無しWindows 10のアップグレード方法を示します。Microsoft公式方法以外でも、いろいろな方法があります。簡単なのが、下記ツールの利用です。

使用ツール：Rufus v3.18

ツールの使い方は、リンク先を参照ください。ローカルアカウントのWindows 10起動状態でRufus作成のUSBを実行すると、アプリとデータを維持したままローカルアカウントでWindows 11へアップグレートできます。アップグレード完了までのクリック回数は3回、1～2時間程度で完了します。

Windows 11アップグレート後、再度Windows Updateを実行し、PCを最新の状態にしてください。

タスクマネジャーを見ると、ユーザ処理が無くてもSystemプロセス負荷が20%位とやや高い状態が半日程度続きます。半日後、通常状態に落ち着きます。

⑤：Windows 11要件未達PCアップグレード所感

Windows 11要件を満たさないPCでも、ツールを使うと簡単にWindows 11 21H2へアップグレートできました。アップグレード手順は、Windows 10手動大型更新と殆ど同じです。

Windows 11は、Windows 10と比べると使い辛さがあります。この点を我慢すれば、TPM 2.0など11アップグレード障壁は、投稿時点では思ったより高くなさそうです。

逆に11要件未達PCなら、今すぐリスク覚悟でWindows 11へアップグレートするよりも、最新Windows 10で安全・安心な公式サポート終了2025年10月頃まで運用し、その後11へアップグレードしても良いと感じました。

Windows 11要件未達PCのアップグレートによる「生産性、操作性向上分」対「リスク」では、リスクが上回ると思います。

好奇心とMCU開発

2022年4月8日2022年4月15日 WithHappy

何を楽しい、面白いと感じるかは、人それぞれです。しかしながらMCU開発者の方々は、ソフトウェアやハードウエアを、自分で研究開発することに面白さや好奇心を持つ点は共通だと思います。

MCU開発は、地味です。普通の人からは、動作して当然と見られがち、しかし、その開発には努力や苦労も必要です。MCU開発者は、それら努力を他者へ説明はしません。
専門家へのキャリアアップには、避けては通れないからです。

特に日本のMCU開発者は、他者がどのように自分を見るかを気にし、しかも、同調意識も強いので、面白さを感じる感性を忘れ、自信喪失などに陥るかもしれません。

そんな時は、スマホを生んだSteve Jobs氏の、“Stay hungry, stay foolish” を思い出してください。

“Stay hungry, stay foolish”

様々な日本語訳、その意味解説があります。筆者は、Jobsは、他者の視線や動向より自分の好奇心を忘れるな、と言っているように思います。

2007年発表スマートフォン：iPhoneは、“Stay hungry, stay foolish”のJobsだから生み出せた製品です。

COVID-19、ウクライナ危機

終息が見えないCOVID-19やウクライナ危機による新しい世界秩序は、半導体製造/流通、MCU/PCセキュリティなどMCU開発者が関係する事柄にも多大な影響を与えそうです。今後数年間は、環境激変の予感がします。

既成概念やトレンド、これまでの市場予測なども大きく変わる可能性もあります。アンテナ感度を、個人レベルでも上げて対処しましょう。

MCU開発は楽しい？

行動の源は好奇心です。“Stay hungry, stay foolish”、自分の好奇心は自ら満たし、MCU開発を楽しみましょう。

本稿の目的は、新年度：4月からMCU開発を新に始める方々へのアドバイスと、好奇心に逆らえず、Windows 11要件を満たさないPCをアップグレードした顛末を次週投稿予定という、前振りです😅。

FSP v3.6.0更新

2022年4月1日2022年4月8日 WithHappy

昨年12月、RAファミリ開発ツールFSP v3.5.0更新から3ヶ月後の3月5日、新FSP v3.6.0付きe2 studio 2022-01最新版がリリースされました。3月25日、各種評価ボードサンプルコードもFSP v3.6.0対応版となり、RAファミリ開発環境が新しくなりました。

※FSP v3.6.0付きe2 studio 2022-01は、コチラからダウンロードできます。
※各種RA評価ボードサンプルコード FSP v3.6.0版は、コチラからダウンロードできます。

新RAファミリ開発環境

弊社RAファミリ向けテンプレートは、FSP v3.5.0で開発し、3月末発売を予定しておりました。ところが、本家ルネサスRAファミリ開発環境の主役FSPがv3.6.0へ更新され、評価ボードサンプルコードもこれに対応しました。

従って、弊社テンプレートも、これら新環境への対応を確認した上で発売する方が、テンプレートご購入者様の更新手間などを避けるため、好ましいと判断しました。

新開発環境で再構築した弊社RAファミリテンプレートV1（ベアメタル版）発売は、4月末に変更致します。

3ヶ月開発

RAファミリ開発環境の主役：FSP、脇役：e2 studio、各種評価ボードサンプルコードの関係は、コチラに投稿済みです。また、RAファミリテンプレート（ベアメタル版）構想は、コチラの4章、昨年12月の頃です。

一方、ルネサスFSP更新は、2～3ヶ月間隔で行われます。新発売のRAファミリデバイスが追加されるためでしょう。今回のように、開発製品リリース直前でFSP更新や開発環境が新しくなることは、多々あり得ます。

ルネサスRA6シリーズウェビナーで紹介された、RAファミリロードマップが上図です。今年以降も、圧倒的な製品展開スピードで新デバイスがどんどん追加されます。

殆どの場合、開発製品は、新環境へもそのまま適用できるハズです。が、その確認には、時間と手間が掛かります。

今回発売変更の教訓は、資料作成なども含めた開発開始から終了は、3ヶ月程度で1開発を完了させるスピード開発が必要だと言うことです。

このスピード開発には、開発中のRAファミリテンプレートが役立ちます。0から開発するのに比べ、既に動作確認済みのテンプレートへ実装機能を追加すれば、プロトタイプが出来上がるからです。

このRAファミリテンプレートは、App0を基に開発しています。App0投稿は、コチラを参照ください。

Windows 11タスクバー位置を考える

2022年3月25日2022年4月1日 WithHappy

Windows 11タスクバーの位置は、モニタ下側のみです。Windows 10は、ユーザが上下左右へ位置変更可能でした。この下側のみの訳を考え、Windows 10同様、変更復活を熱望します。

タスクバー下側位置

Windows 11のタスクバー配置は、デフォルト中央揃えで、左揃えには変更可能です。しかし、その位置は、モニタ下側のみです。Windows 11の最も残念な個所です。

理由は、明らかです。

タスクバーがモニタ下側にあると、その分だけ下側の表示領域が減ります。Wordなどアプリによっては、下側へステータスバーなども表示します。モニタ下側は、左右に比べ有効に使いたい領域です。

タスクバーを自動的に隠すのは、有効化に寄与します。しかし、この隠す動作は、集中を妨げます。気が散るため筆者は好みません。

左横書き言語と数字表示

例えば、1920×1080解像度（16 : 9）モニタの場合、アプリ動作中に表示が少ない空白は、左側に集まります。本ブログ本文などもその傾向です。

これは、文字は左から始まり右へ続く左横書き言語、数字も左が高位ですので左詰めだからです。また、モニタ上側には、メニューやアイコンなどのアプリ操作系が左揃えで居座っています。モニタ上/左側は、文字や数字、アイコンが混み合う領域です。

※アラビア語などの右横書き言語、縦書き日本語もあります。が、ここでは割愛致します。

つまり、上/左側は、アプリ操作、下側のステータスバーも含めると、モニタ上/下/左側は、アプリ表示に適した領域と言えるでしょう。

従って、残る右側が、OS Windowsのタスクバー表示場所として最適です。

これは、16 : 9など横長モニタで、左右(16)が、上下(9)よりも表示領域に余裕があること、ウインド最大/最小化などのOS操作や日時表示が右側にあること、これらとも整合します。

右側タスクバー配置が、アプリとは異なるOS操作や視線移動の点からも合理的な理由が上記です。

下側、中央揃えメリット？

Windows 11タスクバーのデフォルトモニタ下側、中央揃えにメリットが有るとすれば、映画再生やゲーム、メタバース利用時などでしょう（Microsoftの大手ゲーム会社Activision Blizzard買収は、コチラの関連投稿2章参照）。

これ以外のメリットは、見た目で直にWindows 11と判る点です。筆者は、これが中央揃えにした理由だと思います。

最近、販売店で目にする21:9や32:9などのウルトラワイドモニタ利用時は、左側よりも中央揃えタスクバーが良いかもしれません。2つ以上のアプリを、左右に同時表示するからです。

店頭や広いワークスペースを持つ欧米ならともかく、例えネットカフェでも狭くスペース制約が多い日本では、設置場所を取るウルトラワイドモニタなど望むべくもありません。個人環境では、尚更です。

要するに、タスクバー「下側固定の意図」が解らない訳です。Win10までのMetroデザインが、新しいFluentデザインに変っても、位置の制約は無いハズです。

デフォルトは下側でOKです。Windows 11は、Windows 10とコア共通です。10同様、上下左右タスクバー位置可変も容易だと思いますが…😥。

Windowsには、様々な無料ツールがあります。しかし、タスクバーを右側へ配置し、Win10同様に正常動作するツールは、現在見当たりません😥😥😥。

タスクバー上下左右配置復活熱望

Windows 11タスクバーは、モニタ活用や合理性、従来Win10ユーザニーズを満たす上下左右配置可能にすべきです。

PCハードウェア要件：TPM回避Windows 11アップグレート方法開示と同様、タスクバー上下左右配置の復活、是非お願いします。