FSPベアメタルサンプルのRTOSスレッド化

前投稿FSPベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSスレッド化する方法を示します。

多くのルネサスRA公式サンプルコードを活用した効率的なRTOSスレッド開発が本方法で可能です。FreeRTOS、Azure RTOS両方に使えます。

サンプルコードベースRTOSスレッド開発

RTOS開発は、複数スレッドを組合せ全体を動作させます。ベアメタルコードに比べ、個々のスレッドは、独立性や移植性が高い特徴があります。スレッド優先度やセマフォなどのRTOSオブジェクトを適切に設定すると、複数スレッド全体処理としてユーザ所望のシステム動作をします。

スレッドは、勝手に回る歯車、優先度やRTOSオブジェクトは、各歯車をシステム全体で上手く動作させる手段と考えると解りやすいと思います。

スレッドとRTOSの役目
スレッドとRTOSの役目

スレッド設計法は、機能別や処理手順別など様々あり、唯一の方法は無さそうです。しかし、先ずは、歯車となるスレッドを開発し、次に、開発スレッド優先度やRTOSオブジェクトを調整しながら、システム全体動作を仕上げるのがRTOS開発の方法です。

本稿は、スレッド単体開発の1方法として、ルネサスRAファミリ公式FSPベアメタルサンプルコードを活用したサンプルコードベースのRTOSスレッド開発法を示します。複数スレッドを組合せたRTOSオブジェクトの適切な調整や設定に関する内容は、含みません。

公式ベアメタルサンプルコードは、各ベンダエキスパートが開発し、評価ボードで動作確認済みの高信頼ソフトウェアです。また、MCU周辺機能毎に多くのサンプルコードが提供中です。

これらベアメタルコードを活用する本方法は、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えます。

RTOSスレッド化方法

詳細は、後で説明しますが、先ず、ベアメタルサンプルをスレッド化する手順を簡単に示します。方法全体像が判っていると把握しやすいからです。

  1. スレッド無しで空の新規RTOSプロジェクト作成
  2. g_ioport以外のベアメタルサンプルFSPスタックを、RTOS FSPスタックへImport
  3. hal_entry.c以外のベアメタルサンプルsrcファイルを、RTOSプロジェクトsrcフォルダへコピー
  4. 新しいスレッド:MyThreadをRTOSプロジェクトへ追加後、Gegerare Project Contentクリック
  5. MyThread_entry.cへ、初期設定と無限ループ処理を追記

1で新規作成した空のRTOSプロジェクトへ、2と3で対象ベアメタルサンプルから内容を追加、4でベアメタルmain()相当の新しいMyThreadを追加後、FSPを使ってRTOSプロジェクトを自動生成します。

生成後、5でRTOSプロジェクトのMyThread_entry.c初期設定と無限ループを追記します。追記内容は、ベアメタルサンプルの初期設定と無限ループ処理です。

つまり、1~5手順全てFSPベアメタルサンプルからの単純コピーでRTOSスレッド化が可能です。

次章から、前投稿で用いたベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、FreeRTOSスレッド化する具体例を使って、各詳細手順を示します。

1. 空の新規FSP freertos_uartプロジェクト作成

スレッド無しで空の新規FreeRTOSプロジェクト作成
スレッド無しで空の新規FreeRTOSプロジェクト作成

スレッド無し空FreeRTOSプロジェクトを新規作成します。新規RTOSプロジェクト名は、freertos_uartとでもしてください。

2. sci_uart_fpb_ra6e1_epのFSPスタックImport

sci_uart_fpb_ra6e1_epのFSPスタックImport
sci_uart_fpb_ra6e1_epのFSPスタックImport

freertos_uartプロジェクトのFSPスタックへ、sci_uart_fpb_ra6e1_epのg_ioport以外のFSPスタックを全てImportします。Importした各スタックプロパティは、オリジナルプロパティと同じに手動で設定してください。

3. sci_uart_fpb_ra6e1_epのsrcファイルコピー

sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー
sci_uart_fpb_ra6e1_epのsrcフォルダファイルコピー

sci_uart_fpb_ra6e1_epのhal_entry.c以外のsrcファイルを全て、freertos_uartのsrcへコピーします。

4. freertos_uartプロジェクトへ新しいUart Thread追加後、Generate Project

新しいUart_Thread追加
新しいUart_Thread追加

新しいスレッドのSymbolは、Uart_threadとしてください。先頭を大文字にする目的は、FSPが自動生成したファイルやスレッドが使う全小文字表記とユーザ追加のそれらを、大小文字で区別するためです。

Tips:大文字利用は、好みの問題です。RTOS開発は、多数のスレッドやオブジェクトソースが、プロジェクト・エクスプローラのsrcフォルダに表示されます。自分が追加したソース(バグ有り?)と純FSP生成ソースを、一目で区別できるメリットがあります。

最後にGenerate Project Contentをクリックし、FSPによりRTOSプロジェクトを自動生成します。

5. Uart_Thread_entry.cへ初期設定と無限ループ処理追記

RTOSプロジェクトのsrcフォルダ内に、Uart_thread_entry.cが生成されます。

先頭の#include “Uart_thread.h”に、sci_uart_fpb_ra6e1_epのsrcファイルにある#include “common_utils.h”、 #include “uart_ep.h”、 #include “timer_pwm.h”を追記します。
これら4個の#include文は、freertos_uartの全srcファイルに手動で追記します。

Uart_thread_entry.cの初期設定
Uart_thread_entry.cの初期設定

RTOS初期設定は、Uart_thread_entry.c のTODO: add your own code here以下へ、sci_uart_fpb_ra6e1_epの初期設定:hal_entry.cのL41からL93までをコピーします。

sci_uart_fpb_ra6e1_epの無限ループ処理は、コピーした初期設定の後方にあるuart_ep_demo()です。

RTOS無限ループ内には、上図でコメントアウトしたコンテキストスイッチが必要です。そこで今回は、RTOSプロジェクトuart_ep.cのuart_ep_demo()内へ、直接コメントアウトしたFreeRTOSコンテキストスイッチ:vTaskDeley(1)を追記します。

uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ
uart_ep.cのuart_ep_demo()へ追記するコンテキストスイッチ

Tips:#include “Uart_thread.h”が、FreeRTOS関連API:コンテキストスイッチ追記を可能にします。

sci_uart_fpb_ra6e1_epとfreertos_uartスレッド同一動作確認

RTOSプロジェクトをビルドし、評価ボードへダウンロード後、実行してください。前稿のベアメタルサンプルコードと全く同じ処理が、開発したfreertos_uartスレッドで確認できます。

FreeRTOS/Azure RTOSスレッド化差

本稿で示したFreeRTOSスレッド化とAzure RTOSスレッド化の差は、コンテキストスイッチのみです。FreeRTOSならvTaskDelay(1)、Azure RTOSならtx_thread_sleep(1)が、コンテキストスイッチです。

Tips:コンテキストスイッチは、FreeRTOS/Azure RTOS開発手法のRTOS処理フローなどを参照してください。

ベアメタルサンプルコードをAzure RTOSスレッド化する時は、手順1で、新規Azure RTOSプロジェクトを作成し、手順5のvTaskDelay(1)の代わりに、tx_thread_sleep(1)を使えばOKです。

Tips:FSP生成スレッドMyThread_entry.cの無限ループ内には、作成RTOSプロジェクトに応じて初めからvTaskDelay(1)、またはtx_thread_sleep(1)が実装済みです。

本方法が、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えることが分かります。

補足

2023年1月16日、e2 stidioは2022-10のまま、RAファミリFSPがv4.2.0へ更新されました。本稿は、FSP v4.2.0/4.1.0両方で動作確認済みです。



FSP利用RAファミリUARTの使い方

RAファミリ評価ボードFPB-RA6E1PFB-RA4E1FPB-RA2E1などは、MCUのUARTとPCの接続に古いハードウェア知識が必要です。そこで、FPB-RA6E1のUARTとPC接続(USB UART Bridge)を解説し、FSPサンプルコードで動作確認しました。

FSPサンプルコード:sci_uart_fpb_ra6e1_ep

sci_uart_fpb_ra6e1_epのFSP Configuration
sci_uart_fpb_ra6e1_epのFSP Configuration

FPB-RA6E1(Cortex-M33/200MHz、Flash/1MB、RAM/256KB)のUARTとPC接続の公式サンプルコードが、sci_uart_fpb_ra6e1_epです。このFSP (Flexible Software Package)スタックConfigurationが上図です。

簡単に説明すると、FSP UARTスタックを使ってPCとUART(115200bps、8-Non-1)で接続し、Timerスタックを使ってPWMでLED1輝度を変えます。UART受信した1-100値が、PWM設定値です。

つまり、Tera Term経由でPCから1-100を入力すると、評価ボードLED1の輝度がPWM 1-100%で変わります。

sci_uart_fpb_ra6e1_epのreadme.txt
sci_uart_fpb_ra6e1_epのreadme.txt(一部抜粋)

サンプルコード付属readme.txtの上記は、MCUのUARTピンを、どうやってPCのUSBへ接続するかが、開発経験者でも解りにくい箇所です。Windows 7より前の古いMCU開発者なら解るかもしれません。

USB UART Bridge

シリアルポート(出展:ウィキペディア)
シリアルポート(出展:ウィキペディア)

Windows 7以前の古いPCには、RS-232Cコネクタ:シリアルポートが実装済みでした。シリアルポートの用途は、MCUとの通信や、特定アプリのライセンスキーなど多数ありました。

しかし、Windows 7以降、RS-232Cコネクタは消えUSBへと変わりました。

消えたRS-232Cの代わりにUSB経由でMCUと通信を行うのが、USB UART Bridgeです。実績あるデバイスとして、FTDI社のFT232RLが有名でした。

つまり、MCU UART入出力ピンをPCへ接続するには、USB UART Bridge(=USBシリアル変換アダプタ)が必要なことを知っている古いMCU開発者のみreadme.txtが判る訳です。

最近のMCU評価ボードは、USBシリアル変換アダプタとMCUプログラム/デバッグを、1本のUSBで共用しているものが多く、USB UART Bridgeを別途追加し開発する例は稀です。PCのUSBポート数が少なくなってきたからでしょう。

お勧めUSBシリアル変換アダプタ

「FTDI USBシリアル変換」で検索すると、USB 2/3.1や5/3.3V対応など様々なアダプタが、様々な価格で現れます。

殆どの5Vデバイスは、3.3V入力を5V High入力と認識します。それでも、MCUと接続する電圧は、5Vと3.3Vを選択できる方が無難です。High誤認識を防ぐことや、5V耐性が無いMCUピンでも接続できるからです。

低価格で入手性も良く、5/3.3V選択ができるお勧めのUSB UART Bridgeが、FTDI FT232RL USB-TTLシリアル変換アダプタ3個セットです。基板上にスルーホールがあるため、MCU UARTピンとの直接接続も簡単です。

お勧めハードウェアループバックテスト

低価格で3個入り品質に不安な方は、購入後、ハードウェアループバックテストをお勧めします。

ハードウェアループバックテストとは、デバイスの送信:TXDと受信:RXDを結線し、送信データが受信データに現れるかをハードウェア的にテストすることです。このテストにより、購入アダプタが、正常動作することを確認します。

Tera Termを接続すれば、TXD LED、RXD LED動作も確認できます。また、Windows 11 22H2は、お勧めFTDI FT232RL USB-TTLを、追加ドライバなしでUSB Serial Portと認識することも分かります。

ハードウェアループバックテスト
ハードウェアループバックテスト

sci_uart_fpb_ra6e1_ep動作確認

前章までのハードウェア知識を使って、評価ボード:FPB-RA6E1(搭載RA6E1 MCUは、VCC:2.7~3.6 V動作)とシリアル変換アダプタ:FTDI FT232RL USB-TTL(3.3V選択)、PC USBを接続しました。

サンプルコード:sci_uart_fpb_ra6e1_epが示すMCU UART入出力ピンとUSB UART Bridge TXD/RXD接続、PC Tera Termの1-100入力による評価ボードLED1の輝度変化動作が確認できます。

sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epの動作確認
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのTera Term入力(橙)と出力(白)
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線
sci_uart_fpb_ra6e1_epのFPB-RA6E1とシリアル変換アダプタの結線

Tips:上記ArduinoコネクタのD1 TX (P109)、D0 RX (P110)へMCU UART使用ピンを変えるには、FSP UARTスタックの利用Channel 0をChannel 9へ変更すればOK。

ルネサスRAファミリ評価ボードは、本稿で示したMCU UART用にUSB 1本、e2 studioプログラム/デバッグ用に別のUSB 1本、合計2本のUSBが必要です(PC側もUSB 2ポート必要)。

このe2 studio プログラム/デバッグ用USBの通信ツールが、J-Link RTT Viewerです。sci_uart_fpb_ra6e1_epでは、FSPバージョンやsci_uart_fpb_ra6e1_ep操作方法が示されます。

sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer
sci_uart_fpb_ra6e1_epのJ-Link RTT Viewer

次投稿:ベアメタルサンプル → RTOSタスク化

サンプルコード:sci_uart_fpb_ra6e1_epは、FSP UARTスタックのベアメタル利用例で、良くできています。ベアメタルに限らず、RTOSへの応用範囲も広いです。

そこで次回は、ベアメタルサンプルコード:sci_uart_fpb_ra6e1_epを、RTOSのタスク化する方法を投稿する予定です。この方法により、多くの公式サンプルコードを活用し、効率的にRTOS開発が行えます。

FSP利用関連投稿:FSP利用FreeRTOSアプリの作り方FSP利用FreeRTOS/ベアメタルアプリ起動方法



Surface Pro 4 Windows 11 22H2手動アップグレード

Microsoft Surface Pro4(出展:www.comptoir-hardware.com)
Microsoft Surface Pro4(出展:www.comptoir-hardware.com)

知人のMicrosoft Surface Pro 4 (第6世代Core m3、RAM/4MB、SSD/128MB、解像度/2736×1824、Windows 10 22H2)を、Rufus 3.21を使って最新Windows 11 22H2へ手動アップグレードしました。

アップグレード後のWin11 22H2で、Word/Excel、ブラウザ、動画視聴など快適に動作中です。

Surface Pro 4

2015年11月発売のSurface Pro 4は、2-in-1。いわゆるノートPCとタブレット端末を一体化し、自宅、職場など、あらゆる場面に適応するようにMicrosoftが開発した12.3型ノートPCです。

スペックから判るように、Word/Excelと動画視聴が知人の主な用途です。公式Win11アップグレード要件を満たさないため、Windows 10のまま利用中でした。

現状ハードウェアやWin10利用に何ら問題がないものの、Win11アップグレートできれば嬉しいので可能か?と相談を受けました。

Win11要件未達PC手動アップグレート

Microsoft Media Creation Toolの代わりにRufusを使うと、Win11要件未達PCを手動でアップグレードできます。

前回投稿は、Rufus 3.20を使いました。今回は、2022年11月28日更新のRufus 3.21を使います。投稿済み更新手順を再掲します。

変更点は、Win10/11共に最新版22H2へ変わったこと、アップグレート前のSurfaceは、Win10 22H2へ更新済みであることです。

Windows 11 22H2手動大型更新手順
準備 1. Win10 22H2バックアップ(更新失敗リカバリ対策)
2. Win11 22H2インストールメディアダウンロード
3. RufusでWin 11 22H2インストールUSB作成
更新 1. Win10 22H2起動状態でインストールUSB setup実行
2. Rufusダイアログに従い数回クリック
3. Win11 22H2大型更新完了

Rufus 3.21

Rufus 3.21のWindows 11 22H2インストールUSB作成
Rufus 3.21のWindows 11 22H2インストールUSB作成

準備3.のRufus 3.21によるWin 11 22H2インストールUSB作成の様子です。USBは、8GB容量でOKです。

Rufus 3.21のWindows 11インストールスキップ画面
Rufus 3.21のWindows 11インストールスキップ画面

更新2.のRufus 3.21 Win11インストールスキップダイアログです。全項目スキップしました。

Win11インストールスキップ内容が、Rufus 3.20に比べより判り易くなりました。また、Rufus 3.21では、Win10のusernameが自動的にダイアログへ設定されます。

このusernameローカルアカウントで、Win10アプリケーションとユーザデータ保持のままWin11へアップグレードができます。

ネットワーク速度によりますが、準備・更新含め半日程度でWin11手動アップグレードが完了します。

Windows 11 22H2 Surface Pro 4

Win11アップグレード後のSurface Pro 4は、搭載メモリが4MBと少ないため動画再生時8割程度の使用量、CPU/GPU使用率も高いです。

しかし、Word/Excelやブラウザ、動画視聴などの知人想定用途では快適に動作します。筆者は、特に不満や性能不足は感じません。解像度2736×1824の動画再生は、字幕エッジが綺麗に見えます。また、2-in-1のため、モニタが持ち方により縦横に変化しますので、Win11デフォルトタスクバー中央配置も便利です。

本手動アップグレートにより、ご要望どおり知人自身でWindows 11 22H2 Surface Pro 4を試せます。不満ならば、バックアップを使ってWin10へも戻せます。

また、弊社Win11 PCの2ヶ月実績投稿から、本SurfaceをWin11のまま継続利用しても、Windows Updateなどの運用問題は生じないと思います。

Windows Security Update Bリリース配布

Windows Security Update 1月11日Bリリース
Windows Security Update 1月11日Bリリース

2023年最初のWindows Security Update Bリリース配布が、1月11日(水曜)に始まりました(再起動必要)。Bリリースは、適用必須です(関連投稿:3種の累積更新プログラム)。現在、弊社PCは、特に問題なく適用済みです。



持続可能MCU開発

半導体不足やサプライチェーン変化など様々な外部要因により、やむをえず開発中のMCUデバイスが変わる場合があります。MCU開発を持続可能にする1案を示します。

MCUと制御対象分離

MCUデバイスが例え変わっても、MCUと制御対象間のインタフェースが同じなら開発の持続は可能です。

もちろん開発ツールや制御APIは、MCUベンダやデバイスで異なります。しかしながら、開発した制御シーケンスや注意点などの取得済み開発ノウハウは、そのまま新しいMCUデバイスへも適用できます。

簡単に言うと、頭(MCU)と手足(制御対象)、目などのセンサ入力を分離し、万一の際に、頭(MCU)交換が可能な分離インタフェースを使ってMCU開発することです。

本稿はMCU互換性に主眼を置きますが、分離インタフェース採用で制御対象やセンサも交換可能です。

つまり、機能単位の高性能化、低価格化も分離インタフェース導入で容易になります。

分離インタフェース多数派

PMODインタフェースとPMODモジュール(出展:RS DesignSpark)
PMODインタフェースとPMODモジュール(出展:RS DesignSpark)

MCUと制御対象を分離するインタフェースも色々あります。例えば、PMODです。

センサやアクチュエータから成る既製PMODモジュールを、Lego™ブロックのように連結し制御対象の機能追加ができます。連結実現のため、I2CやSPI利用が基本です。

別例が、Arduinoです。

多くの主要ベンダMCU評価ボードにArduinoコネクタが採用中です。右下に示すように、デジタル入出力ピン、アナログ入力ピンなど、ピンが物理的に機能分離しています。

ArduinoコネクタコンパチブルMCU評価ボード例
ArduinoコネクタコンパチブルMCU評価ボード例

既製Arduinoモジュールも多く、しかも安価に入手できます。また、機能別ピンのため、手持ちセンサなどを接続し動作を試すのも簡単です。

元々はArduinoやRaspberryなどのMPU(Micro Processor Unit)向け分離インタフェースでしたが、シンプルで使い易いためMCU評価ボードにもArduinoコネクタ適用例が多く、分離インタフェースの多数派となりました。

Tips:MCU端子は、複数機能から選択が可能です。そこで、Arduinoピン機能を優先して選択し、この選択した端子から先に使用すると、MCU交換時の互換性が高まります。

Arduinoプロトタイプシールド

Arduinoモジュールは、別名シールドと呼ばれます。シールドを複数スタック接続し機能追加も可能です。

MCU評価ボードのArduinoコネクタにスタック接続し、付属する小型ブレッドボード上で簡単な回路も追加できるプロトタイプ向けのシールドが、Arduinoプロトタイプシールドです。

Arduinoプロトタイプ シールド
Arduinoプロトタイプ シールド

このシールドには、2個のLEDと1個のSWが実装済みです。MCU評価ボードへ、LEDやSWを簡単に追加でき、手持ち部品などを使ってプロトタイプ開発する場合に最適だと思います。

評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中
評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中

まとめ:持続可能MCU開発

世界平和やサプライチェーン変化などの外部要因により、開発中のターゲットMCUデバイスやベンダが変わる場合がありえます。

万一MCUデバイスが変わっても、MCU開発を持続可能にするため、各ベンダMCU評価ボードに多数採用のArduinoコネクタを使ったMCUと制御対象分離構成を示しました。

Arduinoプロトタイプシールドを、プロトタイプMCU開発に適す使用例として示しました。



技術者と世界平和

2022年最後の投稿、つまり、週番号が追加されたMint 21.1 MATE Week 52の金曜投稿です。

Mint 21.1 MATEはカレンダに週番号が追加
Mint 21.1 MATEはカレンダに週番号が追加

ロシアのウクライナ侵略から始まった2022年は、世界平和と技術者の関連性を強く感じました。Rapidusなどの半導体新会社設立や、クリエイタ的エンジニア米中対立も根底には平和への危機感があると思います。

技術者の役割も、セキュリティやフィッシング詐欺など攻撃対策の比重が増すかもしれません。インターネットでさえ、グローバルオープンからブロック化の兆しが見えます。IoT MCUやMPU/CPU、Windowsなどの技術者開発基盤もまた、セキュリティがトリガになり発展しそうです。

個人的には、ケアレスミスの多い年でした。何らかの追加対策(?!)が必要と感じています。

さて、本年も本ブログ、および、弊社テンプレートをご利用頂きありがとうございました。
また、各位から頂いた様々なアドバイス、この場を借りてお礼申し上げます。ありがとうございました。

皆様、よいお年をお迎えください。



FSP利用FreeRTOSアプリ起動動作

ルネサスFSPの役目、RTOSアプリ起動動作
ルネサスFSPの役目、RTOSアプリ起動動作

前回FSP利用FreeRTOSアプリの作り方で、ルネサス公式サンプルコードを流用・活用した実践的RTOSアプリ開発方法を示しました。今回は、前回開発したアプリを使ってFSPの役目、RTOSアプリがどのように動作開始するかを説明します。

これからRTOS開発を始めるベアメタル開発経験者に役立つと思います。

前回のおさらい

FPB-RA6E1評価ボードのLED1点滅速度を、SW1プッシュ割込みで変える1スレッドのみを持つRTOSアプリの開発方法を、新規FreeRTOS Blinkyプロジェクトへ評価ボード実装済みベアメタルサンプルコードを移植することで説明したのが、前回のfreertos_blinkyプロジェクトでした。

※12月9日投稿時、FSP Importした割込みコントローラ初期化の記述を忘れていました。翌日10日に追記済みです。お詫びします<(_ _)>。

本稿の目的

ルネサスFSP(Flexible Software Package)は、ベアメタル、FreeRTOSとAzure RTOS、これら3者に対応した周辺回路API とMCU起動ファイルを自動生成するツールです。

※MCU起動ファイルは本稿ではstartup.c、main.c、ユーザファイルの3つを指します。

従って、初めてFSPを利用する時は、戸惑う部分もあります。例えば、ベアメタル開発には無関係のスレッドやオブジェクト設定エリアがあること、FreeRTOS開発時でもタスクではなくスレッドへ統一された説明やパラメタ設定があるなどです。

つまり、1つのFSPでベアメタル、FreeRTOS、Azure RTOSの3者に同時対応したため、FSPパラメタ設定や説明に解りにくい点があります。

※本稿も、FSPに習ってタスクではなくスレッドを用います。

また、当然ですが、ベアメタルとRTOSでは、FSP生成のMCU起動コードも異なります。何度か開発すれば、ベアメタルとRTOSでどこが違うかが判ります。しかし、初めからハッキリ区別した説明があるとFSPとRTOS理解が早くなります。

そこで本稿は、FSP生成MCU起動ファイルとベアメタル/RTOSユーザファイルまでの動作差を説明します。

FSP自動生成MCU起動ファイル(startup.cとmain.c)

startup.c:リセット後のMCU動作開始には、動作クロック設定やRAMゼロクリアなど、様々な前処理が必要です。これら前処理を行うのが、startup.cです。startup.cは、ベアメタル/RTOSともに同じ処理です。

main.c:ベアメタルでは、startup.c→main.c→user_main.cと処理が進みます。RTOSは、startup.c→main.cだけです。main.cの処理内容がベアメタルとRTOSで異なります(次章の図参)。

ベアメタルのmain.cは、実質のメイン関数であるuser_main.cへの橋渡しファイルで処理はありません。なぜ橋渡しファイルを使うかは、後で説明します。

RTOSのmain.cには、ユーザがFSP Configurationで追加したスレッドやオブジェクトの生成関数が、FSPにより自動追加されます。例えば、前回のfreertos_blinkyプロジェクトのmain.cなら、下線部分です。

freertos_blinkyプロジェクトのmain.cファイル
freertos_blinkyプロジェクトのmain.cファイル

FSP生成のmain.cは、スレッドやオブジェクトを生成し、最後に橙色で囲ったRTOSタスクスケジューラを起動してリターン(終了)します。

つまり、RTOSのmain.cは、「全てのRTOS処理を開始するための前処理、準備」を行います。

因みに、FSP生成startup.cやmain.cは、ユーザが勝手に変更を加えにくいようプロジェクトファイル階層の深い部分や、ユーザフォルダ:srcとは別フォルダ内にあります。

FSP生成ベアメタルまたはRTOSユーザファイル(user_main.cまたはuser_thread_entry.c)

ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容
ベアメタル(左)とRTOS(右)のユーザファイル:srcフォルダ内容

逆にユーザファイルは、変更を加え易いよう最上位のユーザフォルダ:srcの中にFSPが生成します。ベアメタルならuser_main.c、RTOSならuser_thread_entry.cです。

ベアメタルでは、実質のメイン関数:user_main.cがmain.cから起動します。user_main.cは、周辺回路の初期設定と、無限ループの2構成から成るごく普通のメイン関数です(関連投稿:組込み開発 基本のキ 組込み処理)。

一方、RTOSは、main.c内でFSPが追加した生成関数user_thread_createによりuser_thread_entry.cが起動します。前章のfreertos_blinkyプロジェクトで示すと、blinky_thread_createとblinky_thread_entry.cです。

ユーザが複数スレッドを追加した場合は、各スレッドが下図のようにmain.c内で生成され、RTOSによる複数スレッド並列動作となります。

ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)
ルネサスFSP生成のベアメタル起動動作(右)とRTOSアプリ起動動作(左)

それぞれのスレッドは、優先度やセマフォなどのRTOSオブジェクトに従って、つまりRTOS環境で制御されます。

FSP利用のRTOS開発は、main.cまでがベアメタル動作、これ以降はRTOS動作環境になります。

ベアメタルのmain.cがuser_main.cへの橋渡しファイルなのは、右側のRTOS動作環境の形に無理やり(?)合わせたためだと思います。FSPは、Azure RTOS>FreeRTOS>ベアメタルの順位で設計されたからでしょう。

まとめ:FSP利用FreeRTOSアプリ起動動作

ユーザ設定のFSP Configurationを基にFSPは、周辺回路APIを生成し、同時に、MCU起動ファイル(startup.cとmain.c)とユーザファイルを分離して生成します。

FSP自動生成ファイルやAPIには、ユーザが手動変更しないようわざわざ下記注意コメントが先頭に付いています。

/* generated XYZ source file – do not edit */

また、FSP生成ユーザファイルにも下記コメントが付いています。

/* TODO: add your own code here */

これらFSPコメントに従って、ユーザがコメントの後へユーザコードを追加すればアプリが開発できます。ただ、開発にはFSPが生成するファイル内容や、FSPが想定しているベアメタル/RTOSアプリ動作の理解が必須です。

そこで本稿は、FPB-RA6E1 FreeRTOSアプリ(freertos_blinky)を使ってFSPが生成したMCU起動ファイルとRTOSユーザファイル動作を説明しました。

その結果、ベアメタルでは橋渡し役のmain.cが、RTOSでは全てのRTOS動作開始の前処理、準備を行うことを示しました。

ルネサスMCU開発は、FSP理解が鍵です。FSPが自動生成するベアメタルとRTOSユーザファイルまでの起動動作が判ると、FSP理解とベアメタル開発経験者のRTOS開発が容易になります。



今年最後のWindows Update Bリリース

2022年最後のWindows Update Bリリース
2022年最後のWindows Update Bリリース

今年も残すところ約2週間となった12月14日(水曜)、今年最後のWindows Update Bリリースが公開されました。早急な適用が必須です(Windows 10/8.1なども同様)。

今年最後のBリリース、12月Cリリース配布は休み

例年Cリリースの12月配布は、Xmas休暇のためありません。

従って、定例外(Out of Band)リリースが無ければ、今回のBリリースが、今年最後の再起動(!マーク)付きWindows Updateです。

4段階深刻度で最も高い “緊急” 修正も、本Bリリースに含まれますので早急な適用が必要です。

関連投稿:3種類の累積更新プログラム:B、C、定例外(Out of Band)

年末年始PCセキュリティ対策

次回のBリリースは、年明け1月11日(水曜)です。

年末年始休暇中は、多くのフィッシング詐欺メール、あるいは、普段アクセスしないサイトアクセスなど、セキュリティリスクが高まる時期です。1月11日も今回同様、重要なBリリースになるでしょう。

Windows OSのUpdateだけでなく、ブラウザや主要アプリケーションの更新、可能ならば正常時のバックアップを行い、年末年始のPCトラブル、セキュリティ対策をお勧めします。

Windows 11 22H2見た目の違い

タスクバーからタスクマネージャー起動可能
タスクバーからタスクマネージャー起動可能

セキュリティ対策は重要ですが、見た目の変化は特にありません。

見た目変化と言えば、今回のBリリース起因ではないかもしれませんが、タスクバー右クリックからタスクマネージャーが起動できるようになりました。

関連投稿:Windows 11ペイント改善では、タスクバーの設定のみが起動できました。

インテル13世代とAMD 7000番CPU

さて、年度末にかけては、Windows 11 22H2インストール済み新規PC購入を検討する方も多いと思います。

そこで、MCU開発用ノートPCの第1弾(画面サイズ)に続き、第2弾(CPU)についての私見を示します。

情報源は、第12世代Coreシリーズは何が違うか(日経XTECH)、Ryzen 7000対13世代(ASCII)、第13世代65Wモデルベンチマークリークなどです。

ノートPC CPUまとめ

ノートPC用CPUをまとめると、Intel最新13世代は、現状12世代に比べ電力消費を抑えるようノートPC向きに正常進化したと捉えます。対抗機のAMD 7000番CPUは、Intel 13世代比、低消費電力で低価格です。

新規ノートPC選択ポイント

新規Windows 11 22H2ノートPC選択ポイント
新規Windows 11 22H2ノートPC選択ポイント

年度末商戦では、最新13世代/7000番CPU搭載のWindows 11 22H2ノートPC販売が開始されます。現状12世代/6000番搭載ノートPCとの差は、販売価格とUSB Type Cによる充電能力に現れると思います。

GPU機能内蔵最新CPU自身の処理能力向上は、Intel/AMDでも現状CPU比、大差ありません。このため、在庫処分などで現状12世代/6000番ノートPCの販売価格が下げれば、13世代/7000番比、コストパフォーマンスのお得感があります。

一方、最新13世代/7000番ノートPCのUSB Type C充電能力が65W以下でもOKなら、多くの既存充電機器にも適応でき応用範囲も広いと思います。65Wを超えると、対応機器価格が上がり、対応数も減ります。

USB Type-Cは、2024年以降、欧州連合(EU)でスマホやカメラの共通充電ポートに決まりました。ノートPC充電も同様です。

高性能と低電力消費のバランス、USB Type-C充電65W以下、為替レート変動による取得価格、これらが、年度末にかけて最新13世代/7000番か、現状12世代/6000番のノートPC CPU選択ポイントになると思います。



FSP利用FreeRTOSアプリの作り方

ルネサスFSP(Flexible Software Package)とサンプルコード利用の「実践的FreeRTOSアプリの作り方」を示します。下記の最新開発環境を用いました。古い環境や別評価ボードでも同じ結果が得られると思います。

 全体流れ説明

先ず本FreeRTOSアプリ開発の全体の流れを説明します。というのは、組込み開発で良くあるサンプルコード付属説明:readme.txtとソースコード動作が不一致など、少々込み入った内容を含むからです。

  1. FPB-RA6E1購入時インストール済みサンプルコード:qiuckstart_fpb_ra6e1_epは、ベアメタルソフト。readme.txt記載のSW1プッシュでLED1/2点滅速度変化とは不一致。
  2. SW1プッシュでLED1/2点滅速度変化へFSP改造(1と2は、ベアメタル開発)。
  3. FPB-RA6E1で、新規LED1/2点滅FreeRTOSアプリ作成(3以降は、FreeRTOS開発)。
  4. 作成FreeRTOSアプリのLEDスレッドへ、2.のベアメタルのSW1プッシュLED1/2点滅速度変化改造FSPと、ソースコード移植。
  5. LED2は、FreeRTOSアプリエラー表示用とするため、点滅処理から削除。

本稿の背景

ベアメタル開発者は1と2、RTOS開発者は3以降が実行できれば、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリを開発できます。

「実践的FreeRTOSアプリ開発」としたのは、0からアプリを開発するのではなく、豊富に提供される公式サンプルコードを流用・活用し、所望アプリを早く効果的に開発する例を示したかったからです。

RTOSのメリットを説明した資料は多く見かけます。しかし、具体的なRTOSアプリ開発方法を示す資料が少ないことも背景にあります。

以下、1~5の説明を加えます。細かい説明は後回しにし、まとめ章を先に読むとより全体が解り易いと思います。従って、まとめ章を先に記述します。また、最後の章に、RTOS開発の基盤となるRAベアメタルテンプレート宣伝(?)もあります。

まとめ:実践的RTOSアプリ開発方法

評価ボード実装済みLED1とSW1は、いわば開発アプリ正常動作中を示すインジケータです。開発したFreeRTOSアプリをテンプレートとし、所望機能のスレッドを追加していけば、最終的に様々なFreeRTOSアプリを早期に開発できます。

FreeRTOSをRAファミリFSP利用例としましたが、Azure RTOSでも同様です。

つまり、本稿のアプリは、RTOSテンプレート骨格で説明した内容を、より具体化したものです。

もちろん複数スレッド追加時は、スレッド優先度やスレッド間制御(セマフォ/キュー/ミューティックスなど)の検討も必要になります。これらは、追加スレッドがほぼ完成した後の検討項目です。

先ずは、必要な個々のスレッドを単体・単独で開発し、その後、複数スレッド結合へと段階的に進める方法がRTOS開発には適していると考えます(関連投稿:FreeRTOS/Azure RTOSソフトウェア開発手法)。

複数スレッドの検討方法は、文章量が増えるため割愛しました。別途改めて、投稿する予定です。

1:qiuckstart_fpb_ra6e1_ep動作とreadme.txt

サンプルコードzip内のqiuckstart_fpb_ra6e1_ep
サンプルコードzip内のqiuckstart_fpb_ra6e1_ep

評価ボードに初めからインストール済みのサンプルコードが、quickstart_fpb_ra6e1_epです。zip内に収められています。e2 studioは、zip内にあるサンプルコード説明書:readme.txtをIDE内にインポートしません。

Tips:zip解凍後のreadme.txtを、サンプルコードプロジェクト内へ手動でコピーしておくと、いろいろ便利。
Tips:quickstart _fpb_ra6e1_epのfpb_ra6e1が評価ボード名、epはexample projectの略。別評価ボード利用時は、fpb_ra6e1部分が異なる。

quickstart_fpb_ra6e1_epのreadme.txtが下記です。

quickstart動作とreadme.txtの不一致箇所
quickstart動作とreadme.txtの不一致箇所

下線部:評価ボードSW1でユーザLED1/2点滅制御とありますが、この動作はFPB-RA6E1にはありません。しかし、quickstart_fpb_ra6e1_epソースコードには、SW1割込み処理:callback_irq1ds_buttonでLED1/2点滅delay変更処理が記述済みです。

これは、RAファミリのソースコードがHAL(Hardware Abstraction Layer)記述で、MCUが変わっても同じソースコードを使えるからです。別評価ボードのソースコードとreadme.txtを、そのままFPB-RA6E1へコピー流用している訳です。

組込み開発ではMCUの種類が多いため、このように既存資産をコピーして当該MCUコードや資料を作ることは良くあります。その結果、今回のようにreadme記述内容とサンプルコード動作が不一致なことも多々あります。

Tips:逆に上記は、MCUソフトウェア開発の本質が「サンプルコードやFSPなどの既存資産を上手くコピー活用すること」を示しているとも言えます!

2:SW1プッシュ割込みでLED1/2点滅速度変化へFSP改造

readme.txt記述とサンプルコード動作不一致の原因が、FSPです。

そのままコピーできるreadmeやサンプルコードと異なり、FSPは、当該MCU毎に設定が必要です。不一致の原因は、FPB-RA6E1のFSP設定にミス(忘れ)があるからです。

動作一致のためには、外部割込みコントローラ(External IRQ)とFPB-RA6E1のSW1(P205)の接続が必要です。下記のようにP205ピン設定を変更後、Generate Project Contentをクリックします。

quickstart_fpb_ra6e1_epを再ビルドし、評価ボードへダウンロードすれば、readme内容と同じSW1プッシュでLED1/2点滅速度が変わります。

外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定
外部割込みコントローラ(External IRQ)とS1(P205)を接続するピン設定

3:LED1/2点滅新規FreeRTOSアプリ作成

新規FreeRTOSアプリ作成は、ベアメタルアプリ作成と同じ方法です。そこで、本稿は、ベアメタル作成との差分のみを示します。

LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)
LED点滅の新規FreeRTOSアプリ作成(ベアメタル作成との差分)

新規作成FreeRTOSプロジェクト名は、freertos_blinkyとでもしてください。FSP Summaryが下記です。

FSP Summary
FSP Summary

このfreertos_blinkyを評価ボードへダウンロードすると、LED1/2が1秒毎に点滅します。生成したLEDスレッド:blinky_thread_entry.cのvTaskDelay(configTICK_RATE_HZ)が、1秒点滅の仕組みです。

4:LEDスレッドへ、2:SW1プッシュLED1/2点滅速度変化改造FSP移植

2:で改造したSW1割込みでLED1/2点滅速度を変える機能を、3の新規FreeRTOSアプリへ移植します。

freertos_blinkyのFSP Stacksタブを選び、画面上で左クリックしImportを選択します。From fileにquickstart_fpb_ra6e1_epを選び、configuration.xmlを開きます。Stack ImportでExternal IRQを選ぶとquickstart_fpb_ra6e1_epの割込みコントローラ設定がfreertos_blinkyへ移植できます。

Tips:移植するFSPスタック数が多い時は、Import機能が便利。

FSP Import
FSP Import

しかし、割込みコントローラとSW1(P205)間の接続はImportできません。そこで、1:と同様にP205ピン設定を割込みコントローラと接続し、Generate Project ContentクリックでFSP移植は完了です。

Tips:FSP Importは簡単便利だが、上記のように同一MCUであっても、ピン設定はImportされない。また、ピン設定が無くてもエラー表示もない。代替方法に、New Stackクリックでスタック群から追加機能を選ぶ方が、ピン設定忘れが少ないかもしれない。

次に、SW1割込み処理:callback_irq1ds_buttonを移植します。

callback_irq1ds_button処理は、e2studioのDeveloper Assistanceを開き、callback_function_definitionをクリックし、blinky_thread_entryの後へペーストで追記します。今回は、TODO:add your own code hereコメント後へ、quickstart_fpb_ra6e1_epのSW1割込み処理をコピー&ペーストし移植します。

コピー後エラーが表示される箇所は、全て定数未定義部分ですので、quickstart_fpb_ra6e1_ep定数部分もコピー&ペーストします。

Tips:e2 studioは、デフォルトではソースコード変更後、このように即コンパイルエラーを表示。

最後に、vTaskDelay(configTICK_RATE_HZ)のconfigTICK_RATE_HZ を、割込み処理で作成したg_delayへ変更します。

以上で、割込み処理の移植完了です。ビルドし、SW1でLED1/2点滅速度が変わることが確認できます。

SW1割込み処理:callback_irq1ds_buttonの移植
SW1割込み処理:callback_irq1ds_buttonの移植

12月10日追記:FSP Importした割込みコントローラ初期化の移植記述を忘れていました。追記します。

Importした割込みコントローラの初期化:icu_initializeも、下図のようにblinky_thread_entry.cへ移植します。

割込みコントローラの初期化処理の移植
割込みコントローラの初期化処理の移植

5:LED2点滅処理削除

LED2は、FreeRTOSアプリのエラー表示に使います。例えば、追加したスレッド初期設定に失敗した時のインジケータなどです。そこで、下記のようにLED2をLEDスレッドの点滅処理から外します。

LED2点滅処理削除
LED2点滅処理削除

以上で、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリ完成です。

このFreeRTOSアプリへRTOSテンプレート骨格で投稿した7メニュー形式表示、LED2エラー表示などの機能を更に追加しFreeRTOSテンプレートとします。

FreeRTOSテンプレートは、全てのFreeRTOSアプリ開発の出発点となり、所望スレッド機能を追加していけば、効率的に様々なRTOSアプリ開発が可能です。

Tips:本稿はFreeRTOSテンプレート開発方法に重点を置き投稿。実FreeRTOSテンプレートは、もっと解り易い構造とソースコードで提供。

RTOS開発はベアメタル開発スキル必須

前章1~5から「RTOS開発には、ベアメタル開発スキルが必須」であることがお解り頂けたと思います。

組込み開発は、説明不足の事柄が非常に多いです。また、サンプルソフトとreadme.txtなどの説明不一致も多々あります。説明対象を初心者/中級者の誰にするか、どこまで説明するか、などなど読者を絞り難いこと、説明側にとっては、自明の理の内容が多いことがその理由です。

本稿で追記したTipsや背景となる技術スキルが無いと効率的に先へ進めないと思います。ベアメタルを補う目的のRTOS開発ではなおさらです。

RAファミリで、FSP利用の効率的なベアメタル開発スキルを身に付けるには、弊社RAベアメタルテンプレートがお勧めです。ソースコードに豊富な日本語コメントを付加し、付属説明資料にはTipsやFSPノウハウなども記載しています。RAベアメタルテンプレート説明サイトは、コチラをご覧ください。

ルネサス以外のベアメタル用テンプレートも多数ご用意しております。また、NXPのFreeRTOSアプリケーションテンプレートも販売中です。



次世代ネットワークIOWN(アイオン)

What's IWON(出展:NTTサイト)
What’s IOWN(出展:NTTサイト)

IOWN(Innovative Optical and Wireless Network)は、2030年実現を目指すNTTの次世代ネットワークです。

IOWN技術

大容量、低遅延の光伝送路。ネットワーク遅延や揺らぎ無し。データドリブン将来社会のデータ量や消費電力増加を解決。キーテクノロジが「光電融合デバイス」、などなど実現技術に興味がある方は、コチラの記事で解ります。

IOWNサービス

IOWNが提供するサービスの一例が、コチラの遠隔医療記事です。IOWNは、ネットワーク本来の目的、離れた場所との距離を感じさせない通信を提供します。

既存ネットワークで遅延や揺らぎが生じるのは、電気信号と光信号の変換回数が多いためです。電気に比べ減衰が少ない光伝送と、光と電気を融合した光電融合デバイス、これらにより電気と光の変換回数を減らし、IOWNのオールフォトニックス・ネットワーク(APN)を実現します。

APNは、低消費電力で大容量、高品質、低遅延で揺らぎの無い理想的な伝送サービスを提供します。

さらに、WirelessのIOWNは、宇宙空間や海中でも接続します。低軌道人工衛星を用いた宇宙RAN(Radio Access Network)や、地上IoT端末と衛星を接続する宇宙センシング、さらに、海中での高速無線通信による水中ドローンなども2030年頃のIOWN 4.0で可能になります。

早くもAMDは、宇宙空間でAI処理ができる宇宙グレードSoCの信頼性評価を完了しました。

宇宙統合コンピューティング・ネットワーク(出展:SKY Perfect JSATサイト)
宇宙統合コンピューティング・ネットワーク(出展:SKY Perfect JSATサイト)

TRONプロジェクトリーダ:坂村健氏も注目

2022年11月25日の記事では、TRONプロジェクトリーダ:坂村健氏が、多くのIoTセンサを組込んだスマートホームなどのICTインフラに、電力効率100倍、伝送容量125倍、レイテンシ200分の1のIOWNが大きなインパクトを与えると語ったことが記載されています。

スマートホームでこれほど高速、大容量の公衆ネットワークが安価に使えると、個人のPCストレージは、もはや全てクラウド上に置くことも可能な気もします。

IWON特徴(出展:NTTサイト)
IOWN特徴(出展:NTTサイト)

IOWNと2030年

2030年まであと8年。リモートワークや移動時、遠距離でも低電力、大容量、低遅延、遅延揺らぎ無しの通信ニーズは、今後益々高まります。

IOWNが、これらニーズを満たし現状ネットワークの様々なボトルネックを解消した新たなサービスの実現、開発インフラになりそうです。IoT MCU開発者もまた、IOWNと2030年に向けた進化が必要です。

関連投稿:2030年のエンジニア



Windows 11 22H2更新2ヶ月

最新Windows 11 22H2大型更新の一般公開は、2ヶ月前の2022年9月21日。弊社3PCを手動にてWin11 22H2へ更新後、2か月経過状況を示します。

Win11 3PC状況

Windows 11 22H2大型更新後、2ヶ月間に配布されたUpdateと現在のPC状況
Windows 11 22H2大型更新後、2ヶ月間に配布されたUpdateと現在のPC状況

Win11更新後、2ヶ月間に配信された9件のWin11 Updateと、現在のPC状況です。

3PC中、1台はWin11アップグレード要件を満たしていませんが、3PCとも上記状況です。また、3PCともWin11に、今日現在不具合はありません。

他のPCと同様、TPM要件未達PCでも、Win11にアップグレードできUpdateも2ヶ月間の更新の履歴から正常に適用できたことが判りました。

関連投稿:Win11 22H2手動大型更新方法

3種の累積更新プログラム:B、C、定例外(Out of Band)

Windows Updateは3種類あり、この2ヶ月間に提供されたWin11 Updateは、これら3種類全てを含みます。

  • Bリリース:毎月第2水曜(日本時間)配布。適用必須。
  • Cリリース:Bリリース以外の月例配布。適用任意。
  • 定例外(Out of Band)リリース:B/C以外の緊急配布。適用必須。

最初の図のKB5019509が定例外、KB5019980/KB5020622/KB5018427がBリリース、それ以外がCリリースです。弊社は、Cリリースでも配布時に即適用する方針です。

Microsoftは、2023年のBリリース配布スケジュールを公開しています。Bリリース内容が重要だからです。

2023年1月11日、2月15日、3月15日、4月12日、5月10日、6月14日、7月12日、8月9日、9月13日、10月11日、11月15日、12月13日(全て日本時間)。

PCを運用していれば、定期的にPC自身がWindows Updateチェックを行います。従って、これら日程のカレンダー登録までは不要だと思います。

但し、Bリリース重要性、適用必須はお忘れなく!

関連投稿:Windows重要パラメタ

結論:Win11 22H2更新後2ヶ月実績

Windows11無償アップグレード完了
Windows11無償アップグレード完了

Win11要件を満たすPCと同様、アップグレード要件未達PCであっても、Rufus利用で最新Win11へ手動更新でき、Updateなども問題なく適用できることが、この2ヶ月間で判りました。

OSコアがWin10と同じWin11の操作性は、Win10と大差ありません。Win10アプリケーションも、Win11で動作します。新しいOSに慣れる目的なら、Win10との機能差が少ないWin11は適しています。

関連投稿:Rufus利用Windows 11要件未達PCアップグレード方法Windows 11ペイント改善

新PC購入はWindows 12発表後

Win11アップグレード要件、特にセキュティ関連が厳しくWin10のまま使い続けるユーザも多いと思います。

Win10は、2025年10月14日にサポート終了、残り3年です。ちなみにWin10 22H2でも、2024年5月14日までの18ヶ月サポートです。残り3年の間にWin11対応新PC購入が、多くのユーザアクションでしょう。

ただ、Win10比セキュリティ強化のWin11は、関連投稿Rufus利用の無理やりアップグレードでも本稿で示したように十分に使えます。無理やりアップグレードの不安は、累積更新プログラムの適用、万一に備えたバックアップなど、基本的PC運用で小さくできます。

要件を満たすWin11 PC2台と無理やりアップグレードWin11の3PC 2ヶ月間運用実績、Win11無償アップグレード終了の可能性なども考慮すると、Win10継続利用にこだわる必要はないと思います。

新PC購入は、2024年予定のWindows 12発表後が良いかもしれません。Win12では、セキュリティ強化だけでなく、新たなWindows魅力機能が提供され、その魅力に見合う新しいPCハードウェアが必要になると思うからです。

関連投稿:TPM 2.0の古さWindows 12