IoT MCUのHappyTech

Rapidus（ラピダス）

2022年11月18日 WithHappy

Rapidusロゴ 2022年11月11日、経産省キモ入りの日本国内8社（キオクシア、ソニー、ソフトバンク、デンソー、トヨタ自動車、NEC、NTT、三菱UFJ銀行）から成る次世代半導体（Beyond 2nm）製造会社：Rapidus設立（ITmedia）の記事は、世界と国内の半導体製造「10年遅れ、先端ロジック分野後進国」を取り戻すには、「異次元の取組みが必要」と報じています。

RapidusとLSTC体制で2030年までに市場規模100兆円目指す

次世代半導体プロジェクトはRapidusとLSTCの2本立て（出展：経産省サイト）

年内に半導体技術の研究開発拠点：LSTC（Leading-edge Semiconductor Technology Center）も立上げ、研究開発はLSTC、製造はRapidusの2社体制で2030年までに市場規模100兆円を目指すそうです。

過去との差分

Rapidusが過去の半導体ファウンドリー設立と異なる点は、半導体ユーザ企業（ソフトバンク、デンソー、トヨタ自動車、NTT）が各10億円出資して参加している点と、Rapidus経営陣メンバーの本気度が高いことだそうです（2022年11月11日、日経xTECH）。

上記記事は、新会社への期待と不安も示しています。弊社も、RapidusとLSTCに注目していきたいと思います。

周回遅れの日本国内ワクチン産業との類似性

世界と国内の「10年遅れ」と類似する事象に、COVID-19国内ワクチン開発が「周回以上の遅れ」と指摘している記事があります。この記事も、対策には「抜本改革が必要」としています。

先端半導体研究開発とCOVID-19国内ワクチン開発、全く別分野ですが、両者の日本状況は良く似ています。

ワクチン不足から類推する先端半導体不足

ワクチン接種は、現在無料です。これは、政府が海外メーカからワクチンを買上げ、無料で国民に接種しているからです。

仮に、変異型ウイルス対応ワクチンが不足し、入手困難ならどうなるでしょう？旧型ワクチンでは変異型に対して効果が期待できない場合などは、国内パニックになるでしょう。

これと同じことが、先端半導体不足でも生じます。多くの製品や車は、半導体が性能、製品差の決め手です。先端半導体を使えないことは、日本製の新製品や新車の魅力が無いのと同等になるでしょう。

この事態を避けるためRapidusとLSTCの異次元取組みに期待し、日本の10年遅れを挽回してほしいです。

海外最新半導体製造ニュース

TSMC米国アリゾナ工場、3nm製造の可能性（2022年11月15日、EE Times）
独）Infineon、アナログ/ミックスドシグナル/パワー半導体を新工場で製造計画（2022年11月15日、EE Times）

海外半導体製造の最新ニュースを2件示します。この分野は、Rapidusの強力ライバルが着実に進出中です。

先端IoT MCUはRTOS開発

個人レベル開発スキルもまた、Rapidusや国内ワクチン産業と同様、異次元の取組みや抜本改革無しの方法では、海外との開発競争にすらなりません。

景気後退が懸念される今、個人の開発スキルを磨き、先端技術人材になりましょう！

IoT MCU分野では、RTOS開発が先端技術だと筆者は思います。JACOB’S BLOGの5 RTOS Design Best Practicesが、とても参考になります。

関連投稿：RTOSテンプレート骨格、クリエイタ的エンジニア

本稿主旨は、「危機感は大切だが、あせりは禁物。お互い切磋琢磨しましょう」です。

64ビットMCU得失

2022年11月11日2022年11月12日 WithHappy

今年春の3月2日、ルネサスが64ビットRISC-Vコア搭載の汎用MPU：RZ-Fiveを発表しました（!=MCU）。

本稿は、RISC-Vの簡単な紹介と、MCUの64ビット化得失についてまとめました。

RISC-V

リスクファイブ（RISC-V）は、2010年にカルフォルニア大学バークレイ校（2022年世界大学ランキング第4位）で開始されたプロジェクト。オープン標準命令セットアーキテクチャ（ISA）でオープンソースライセンス。使用料無料。用途に応じた32/64/128ビット対応アーキテクチャで、RISC-Vチップや派生成果物の作成も許可。（Wikipediaより）。

ルネサスなどのMPU/MCUチップ製造側にとっては、ARMコアベースに比べ、ライセンス料が無く競合他社差別化や独自性も出し易いのがRISC-Vコアと言えそうです。※RZファミリには、ARMコア（Cortex-A55とCortex-M33ディアルコア）のRZ/G2ULもあるため、ArmベースMPUが最初の右グラフに記載。

日経xTECH記事（2022-09-13）によると、ルネサス以外にも、既に多くのRISC-V利用MPUや32ビットMCUが発表されています。RISC-V CPU搭載ノートPCも販売中です。

IoT MCU要件

CPUやMPUは、64ビット化が進んでいます。Windows 11は、32ビット対応版がありません。また、ルネサスRZ-Five同様、NXPやSTマイクロでもMPUは全て64ビットです。

これは、CPU/MPUに要求されるセキュリティ機能や性能を満たすには、先行するサーバやデータセンタで開発したソフトウェア資産の移植が、64ビットの方が容易だからです。

一方、MCUは、性能・機能の向上と消費電力増加のバランスが、MPUに比べ重視されます。MCU設置個数は、MPUよりも桁違いに多いため既存MCU資産を活かすバイアスが働くためです。最初の右側グラフで、16ビットRL78が低消費電力の代表として表示されていることからも解ります。

このバランスのため現状のIoT MCU主流は、32ビットMCUです。

しかし、MCU製造プロセス改良や、電力供給の世界情勢、自動車ADASと半導体供給状況などにより、IoTセキュリティ機能への要求や、低消費電力への要求バランスは大きく変わる可能性もあります。場合よっては、CPU/MPU同様、64ビットMCUがIoTに適すかもしれません。

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

関連投稿：ルネサスのMCU新製造プロセス SOTB

また、IoT必須のRTOSをMCUへ適用する場合には、32ビットカウンタでは、タイマー満了周期が短い問題も指摘されています。

結論：64ビットMCU見通し

既存MCU資産（特にソフトウェア）をそのまま活かしMCU性能を上げるには、同一コア高速化が適します。一方、サーバやデータセンタのセキュリティ機能移植を考えると、64ビットMCUも有力です。また、IoT MCUのRTOS開発時は、32ビットカウンタの短さに注意が必要かもしれません。

ビット幅を意識することは、Cなどの高級言語でMCU開発する限り稀です。しかし、RTOS開発時や更なる性能・機能向上（例えばエッジAI）、効率的セキュリティ導入を求める時は、32ビットMCU限界が現れることもあり得ます。

アーキテクチャ変更で得るものと失うものバランス、トータル開発コスト、これらが次世代IoT MCUを決めます。今後主流のIoT MCUが32/64ビットいずれになるかは、流動的です。だからこそ、最新IoT MCUやMPU、RISC-V動向を注意深く観察する必要があるというのが結論です。

クリエイタ的エンジニア

2022年11月4日 WithHappy

エンジニアには、「作業的な人」と「クリエイタ」の2種類が存在。クリエイタ的エンジニアが、New Worldを作っていく。（その３より）

2030年向け先進テクノロジとの正しい付き合い方について、元ソニーCIO（最高情報責任者）、現在はガードナージャパン）エグゼクティブプログラムシニアアドバイザーエグゼクティブパートナーの⻑⾕島眞時⽒と、ガードナージャパン）アナリストの亦賀忠明⽒の全3回対談記事（2022-10-28、ZDNET Japan）で、筆者が最も印象に残った箇所です。

ごく簡単に内容を抜粋し、クリエイタ的エンジニアへと成長するための記事提言をまとめました。

対談は、マネジメントとエンジニア双方への提言です。本稿は、読者の多いエンジニアに絞って抜粋しました。対談全文は、その１、その２、その３をご覧ください。

2030年のNew WorldとスーパーパワーAPI

2022年のテクノロジは江戸時代。2030年のテクノロジは、スーパーパワーを持つNew Worldへ劇的変化。

2022年令和4年の現在を、手作業、企業論理中心の江戸時代と呼び、テクノロジ変化がもたらす2030年は、ハイブリッド・ワーク、メタバース、スーパーパワーAPIの新しい時代、これがNew Worldです。

わずか8年間で、テクノロジは、江戸時代から劇的に進化し「全く別のNew World」になります（その１）。

スーパーパワーとは、進化により想像を絶する能力をデジタルテクノロジが持つこと、そして2030年以降は、このスーパーパワーを使いこなせる企業と、そうでない企業が、明確に別れると予想しています（その２）。

スーパーパワーAPIを使ったモノづくりができるエンジニアと企業がNew Worldを作る、と結論しています（その３）。

※スーパーパワーAPI：多様化、高度化した進化テクノロジ境界がAPI（application programming interface）。様々なテクノロジ個々の深い理解は困難だが、API経由での利用は可能。つまり、1つのテクノロジ領域スキルを磨けば、他領域スーパーパワーを利用することは、比較的容易。

自分事、主体的に考える

短期間で劇的変化するNew Worldへは、人も、金も、時間も、他人事、もしくは当事者意識に欠けていては対応できません。

初めから完璧にやる必要はなく、これまで以上にアンテナの感度を上げ、注意深く、主体的に探索し、自ら的確にアクションすることが重要です（その２）。

作業的とクリエイタ的エンジニア

これまでは、決められた作業を的確にこなせる作業的エンジニアが求められました。これらの作業は、自動化やAI、さらにハイパーオートメーションが、とって代わります。

New Worldでは、いろいろな想像・発想ができ、創造ができる「クリエイタ的エンジニア」が活躍する時代です（その３）。

まとめ：クリエイタ的エンジニアは1日にしてならず

2030年向け先進テクノロジとの正しい付き合い方の記事は、対談形式のため長文です。盛りだくさんな内容の中から、エンジニア向け提言を抽出しました。

テクノロジが急変、高度化、多様化する時代は、初めから完璧を目指すより継続的改善を行い、主体的に2030年New Worldスキルを持つクリエイタ的エンジニアになれ、と提言しています。

「ローマは一日にして成らず」、クリエイタ的エンジニアも同じです。

2030年はすぐそこです。あせりは禁物ですが、できない理由を考える暇があるなら、できることを認識・判断・実行し、クリエイタ的エンジニアへの第1歩としましょう。

筆者個人は、IoT MCU RTOSテンプレート開発を最初の目標とします。

Windows 11ペイント改善など

2022年10月28日2022年11月13日 WithHappy

Win11デフォルトペイント（上）とWin10 Classicペイント（下）の違い

最新Windows 11 22H2（OSビルド：22621.755）は、エクスプローラーにタブ機能、タスクバーにオーバーフローメニューなど、多くの機能が月例アップデートとは「定例外（Out-of-band）」のKB5019509により追加されました。このような随時Win11の新機能追加に異論はありません。

しかしながら、新機能を好まない時は、旧機能へ戻すツールや対策を知っていると役立ちます。そんな情報をまとめました。

リボン最小化なしWin11ペイント

現状のWin11デフォルトペイント（11.2201.22.0）は、リボン最小化ができません。

従来のペイントは、リボン表示/非表示が、右上∧クリックで可能でした。この従来ペイント（Classic Paint for Windows 10）は、コチラからダウンロード可能です。

Classic Paintは、Winaero Tweaker機能の一部です。Classic Paintインストールに失敗する時は、何回か繰り返すと成功します。

お勧めは、Win11デフォルトペイントを規定アプリのまま残し、インストールしたClassic Paintをタスクバーへピン止めすることです。これにより、通常はWin11デフォルトペイント、リボン最小時はタスクバーClassic Paintクリック、両アプリの使い分けができます。

タスクバーへピン止めしたClassic PaintとWindows 11デフォルトペイント

エクスプローラータブ機能

エクスプローラーへタブ機能が追加されました。この新機能の効果的な使い方は、現在模索中です。旧エクスプローラーと比べると、起動やナビゲーションウインド表示が遅くなるなど、不満な点もあります。

そんな方は、タブ機能を無効化するViVeTool（GitHub配布フリーソフト）があります。

インストールや使い方は、Windows 11 22H2エクスプローラータブを無効化する方法記事を参考にしてください。

なお、同じKB5019509で配信されたタスクバー上の右クリックでタスクバーの設定とタスクマネージャーが同時表示される機能は、弊社3PCともにタスクバーのみ表示です。タスクマネージャーは非表示ですが、数週間のうちに順次展開されるとのこと。

但し、タスクマネージャーは、Win＋Xで表示でき、この使い勝手も良いので不便は感じません。

ビデオカード最新Win11ドライバ更新

Win10からアップグレードしたWin11ユーザ（筆者）が忘れがちなのが、ビデオカードのドライバ更新です。最新Win11対応ドライバは、ビデオカードの性能をより引き出します。

例えば、2022年10月17日にAMD Software Adrenalin EditionのWin11対応最新ドライバがリリースされました。Win11 21H2から22H2へアップデートされた方も、最新ドライバへの更新をお勧めします。

Visio（*.vsdx）形式保存

Win11 22H2は、Visio 2003-2010図面（*.vsd）形式での保存ファイルが、Visio 2019で一部正常に表示されません。新形式（*.vsdx）保存ファイルなら、問題なく表示できます。

この問題は、Win10にはありませんでした。今後のWin11月例アップデート等で改善されるかもしれませんが、Visioユーザは少数のため期待できません。

新たなVisio図面を保存する場合は、（*.vsdx）形式での保存をお勧めします。

※対策は、正常表示できない*.vsdを、レイアウト崩れが生じますがLibreOffice Drawで開き、*.vsdx形式で保存。Visio 2019で崩れたレイアウトを修正すると解決します。

まとめ

大規模アップデートを年1回に変更したためか、Win11は随時新機能追加が行われます。

追加新機能が生産性を下げるなど、ユーザが好まない場合もあるでしょう。旧機能の復活、新機能無効化など様々な無償改善ツールがWindowsにはありますので紹介しました。

※アップデートなどのWindows重要パラメタは関連投稿をご覧ください。
※個人の生産性向上基盤がPC OSです。万人向け新機能追加もOKですが、個人要望を満たす無償ツールが多いのもWindowsの魅力です。

RTOSテンプレートの骨格

2022年10月21日2022年11月18日 WithHappy

IoT MCU RTOSは、FreeRTOSとAzure RTOSの2種類。接続クラウドAmazon AWSやMicrosoft Azureに応じて選択する必要があります。各RTOSそれぞれにRTOSアプリケーションを開発するのは非効率です。

そこで、アプリケーション開発の基になるRTOSテンプレートの骨格を検討しました。APIはFreeRTOSとAzure RTOSで異なるものの、同一の骨格から開発するとメリットがあるからです。

結論は、単体タスク/スレッド試験も容易なメニュー表示形式RTOSテンプレート骨格とします。

RTOSアプリケーション例

Data flow diagram for a smart thermostat（出展：JACOB’S Blogに加筆）

RTOSアプリケーション例が上図です。複数のタスク/スレッドと各タスク/スレッドを制御するアプリケーション本体から構成されます。

アプリケーション本体とタスク間は、同期（S：セマフォ）/排他（M：ミューテッスク）/メッセージキュー（Q）などのRTOS処理待ちに応じたRTOS APIが用いられます。

FreeRTOSとAzure RTOSで処理待ちRTOS API記述が異なるものの、どちらも機能的には同じです。

また、センサやタッチスクリーン、Wi-FiなどMCU内蔵/外部回路間の制御API、いわゆるドライバ部分は、各MCUベンダ提供のAPI生成ツールで開発します。このAPI生成ツールは、ベアメタル開発で使うものと同じです。RTOS開発だからと言って別のドライバAPI生成ツールがある訳ではありません。

ベアメタル開発とRTOSとの差分は、灰色部分です。1無限ループ内で全ての処理を行うのがベアメタル、RTOSアプリケーション本体と複数のRTOS処理待ちタスク/スレッドで並列多重を行うのがRTOS、ここだけです。

メニュー形式アプリケーション特徴

メニュー 1-5 を選択してください。
(1) Process Input処理
(2) Network Manager処理
(3) 出力処理
(4) メモリ処理
(5) 印刷
(6) 処理自動実行

最初の図のような複雑な処理をベアメタル開発する時は、例えば上のようなメニュー表示形式アプリケーションがしばしば用いられます。メニューの表示は、USART接続のPC、Tera Term利用が一般的です。

このメニュー表示形式アプリの特徴は、(1)から(5)の各処理を単体デバッグできることです。

また、単体デバッグ後、(1)から(5)の処理を自動で結合する処理(6)を開発すれば、開発が完成する点も優れています。

(6)完成後は、メニュー表示をスキップし、PCを使わずにMCU単体で(6)を実行すれば、ベアメタル組込み完了です。

メニュー形式RTOSテンプレート骨格と開発手順

RTOSアプリケーション開発でもメニュー表示形式を採用します。

メリットは、単体タスク/スレッド開発、デバッグが容易な点です。RTOS開発は、タスク/スレッドの独立性がベアメタルよりも高いため、メニュー形式で開発したタスク/スレッド流用性も高く、開発ソフトウェア資産化も可能です。

弊社RTOSテンプレートは、FreeRTOSでもAzure RTOSでもメニュー形式のテンプレート骨格とします。テンプレートが用意するデフォルトメニュー数は7個、タスク/スレッド優先度もデフォルト7レベル（1から7）設定とします。優先度初期値は、どれも同一優先度（真ん中の4）とします。

※FreeRTOSは値が大きいと高優先、Azure RTOSは値が小さいと高優先で真逆に注意

RTOSテンプレートを使って、単体のタスク/スレッドを開発し、単体タスク/スレッド完成後、並列多重の結合動作へステップアップします。多重時、各タスク/スレッドの高/低優先度変更や、タスク合併などを検討します。

もちろん、メニュー数や優先度数の増加も容易です。しかし、弊社がお勧めするIoT MCUは、低価格評価ボード搭載の汎用IoT MCUです。RTOSオーバーヘッドが少ない7程度が適当だと思います。

RTOSテンプレートを使って、第1段階ではタスク/スレッド分割と単体タスク/スレッド開発に集中し、第2段階でタスク/スレッド並列多重に関連する優先度などのRTOSパラメタ調整に集中します。段階を踏んだ集中開発ができるため、複雑なRTOSアプリケーションの早期開発に役立ちます。

弊社RTOSテンプレートは、FreeRTOSまたはAzure RTOS個別対応済みのバージョンを販売予定です。但し、RTOSテンプレートの骨格がFreeRTOS/Azure RTOSで同じことをご購入者がご理解済みなら、FreeRTOS APIとAzure RTOS API変換も、比較的容易だと思います。

ベアメタルテンプレートとの違い

弊社ベアメタルテンプレートは、主に開発初心者から中級者が対象です。メニュー表示形式など、複雑な構成のテンプレートを提供するよりも、シンプルで解り易いソースコードの方が適しています。

一方、RTOSテンプレートは、ベアメタル開発経験者、つまり中級以上の開発者が対象です。

テンプレート付属説明資料も異なります。ベアメタルテンプレート付属説明資料は、各ベンダのIDEやAPI開発ツールの基本的使い方、開発つまずき回避のTipsなどを記述しています。具体例は、RAベアメタルテンプレート説明資料をご覧ください。

RTOSテンプレート付属説明資料は、既知のベアメタル関連説明は省き、ベアメタルとRTOSの差分や、実践的なRTOS Tipsの説明を加えます。具体例は、NXP版FreeRTOSテンプレート説明資料をご覧ください。

まとめ

FreeRTOSとAzure RTOS同一のメニュー形式RTOSテンプレート骨格構想を示しました。

弊社RTOSテンプレートを使えば、単体タスク/スレッド開発に集中でき、効率的、段階的なRTOSアプリケーション開発が可能です。開発単体タスク/スレッドは、独立性が高いので、ソフトウェア資産化も容易です。

また、接続クラウド変更に伴うFreeRTOSとAzure RTOSのAPI変更も、同じテンプレート骨格利用のため容易です。

本構想に基づいたAzure RTOSテンプレート、FreeRTOSテンプレートは、本年度末発売予定です。現在販売中のNXP版FreeRTOSテンプレートも、本構想用に改版を予定しております。

弊社RTOSテンプレート骨格について、皆様のご意見などを現在募集中です。お気軽にinfo@happytech.jpへお寄せください。

効率的MCU開発ディスプレイサイズ

2022年10月14日2022年10月28日 WithHappy

MCU開発Eclipse IDE画面の表示情報量は多く、ディスプレイサイズや解像度が小さいと非効率です。効率的MCU開発ディスプレイサイズと解像度を検討し、Windows 11ノートPCに適したディスプレイサイズと要件を考察しました。

Eclipse IDE表示情報

Eclipse IDEとしてNXP社のMCUXpresso IDE 11.6.0を例にします。IoT MCU開発時は、どのViewにも重要な情報が表示されます。

例えば、上から解像度（1920×1080）、（1920×1200）、（2560×1440）、（3840×2160、150%テキスト表示）4つの表示例です。どれも筆者が頻繁に利用するネットカフェの同じ31.5型4Kディスプレイを用いました。

ちなみに、（1920×1080）が弊社所有14型ノートPC、（1920×1200）が24型デスクPCの表示サイズです。

解像度が大きくなると、各Viewへ一度に表示できる情報量が増えることが判ります。

2560x1440 100％のIDE View表示例 — 2560×1440 100％のIDE View表示例

ディスプレイサイズとテキスト表示サイズ

各Viewのタブをクリックすれば、そのViewだけを表示できます。ソースコード記述時など1点だけに集中する時は、この方法も使います。

しかし、多くの場合、複数Viewを参照しながら作業を行います。大きいディスプレイへ複数Viewを表示しながら作業する方が、効率的に開発が進むのは明らかです。

その結果、弊社は、14型ノートPCは主に確認用、24型デスクPCが開発用となります（ノートPCのマルチディスプレイ利用は次章説明）。

では、ディスプレイサイズが大きければ大きい程効率的かというと、そうでもありません。筆者の場合は、24型～27型位に最適値があります。

ディスプレイと目の距離を40cmとすると、27型よりも大きい31.5型ディスプレイは、圧迫感があるためです。また、テキスト表示サイズも150%へ変更しないと、小さすぎます。

100%テキスト表示で、A4用紙が実物と同じ大きさに表示されるのは、24型です。

つまり、24型～27型で40cm配置に、MCU開発効率が良いディスプレイ選択肢がありそうです。この時は、テキスト表示サイズは、100%でOKです。

ディスプレイと目の距離は、ノートPC、デスクPCどちらも同じ40cm以上（出展：富士通パソコンを使う時の姿勢）

効率的MCU開発のWindows 11ノートPC要件

ノートPCには、可搬性が求められます。ノートPCディスプレイに、14型や15.6型を用いるのは可搬性実現のためです。

しかし、ディスプレイ外枠を極力少なくし、16型や17型でも従来ノートPCに近い筐体を実現するノートPCも最近発売中です。

また、ノートPCは、マルチディスプレイでの使い方が前提です。Windows 11では、このマルチディスプレイ操作性が改善されました。

外付けマルチディスプレイの左右上下物理配置に応じた本体ディスプレイ１との再配置が可能です。ディスプレイ間のマウス移動時、違和感が旧Windowsに比べ無くなりました。さらに、外付けディスプレイの大きさを自動認識し、大きいディスプレイをメインとするタスクバー配置も行います。

従って、効率的MCU開発のWindows 11ノートPC要件は、

(1) 可搬性を犠牲にしない範囲で、できるだけ大きい本体ディスプレイ
(2) MCU開発効率の良い100%テキスト表示24型～27型マルチディスプレイ出力インタフェース

これら2つになります。

また、ノートPC本体ディスプレイと、外付けマルチディスプレイとの目の距離は同じ方が良いはずです。もし、外付けディスプレイとの距離が40cmよりも遠い場合には、27型よりも大型のディスプレイと100%よりも大きなテキスト表示が必要になります。

つまり、4K大型高解像度ディスプレイは、この外付けディスプレイの配置が、40cm以上遠くに設置した時の対応策が予め機能として備わっていると考えられます。

まとめ

効率的なMCU開発に適したWindows 11ノートPCディスプレイサイズを検討し、16型ディスプレイ、マルチディスプレイ出力インタフェース1本、の必須要件を示しました。

具体的な製品例を示すと、DELL)Inspiron 16 Intel（1920×1200、Core i7-1255U）、余裕があれば高性能CPU搭載のDELL）Inspiron 16 Plus プラチナ（3072×1920、Core i7-12700H）などです。

DELL）Inspiron 16 Plus プラチナ（3072x1920、Core i7-12700H） — DELL）Inspiron 16 Plus プラチナ（3072×1920、Core i7-12700H）

あとがき

本稿は、MCU開発ノートPCに焦点を絞っています。また、マルチディスプレイと言っても、外付けは1台だけです。このサイズが大きい外付けがメインディスプレイで、ノートPC本体は、補佐的な表示になります。やはり、大きなディスプレイは、開発効率化に直結します。

その結果、外付けディスプレイ2を、目から40cm距離の最適正面へ配置、ノートPC本体ディスプレイ1は、ディスプレイ2の左右、つまり脇役配置になります。

最近、低価格化が進む4K大型ディスプレイやノートPC（円安で価格上昇中）に、どの程度コストをかけるべきか、これは筆者個人の問題です。その問題解決・整理のために、本稿を作成しました。

もちろん、解像度が上がれば表示文字も綺麗に見易くなります。しかし、ネットカフェで31.5型3840×2160 150%テキスト表示ディスプレイを40cm位置で利用しMCU開発を何回か行った結果、4K大型ディスプレイ追加コストに見合うMCU開発効率化は得にくいと現状は思いました。

メタバース空間でWordやExcelが使え、MCU開発業務もVR空間でできることも、そう先の未来ではないかもしれません。それでも、ここ数年は、本稿結果が活きるはずです。

RAファミリprintfデバッグ3方法

2022年10月7日2022年10月21日 WithHappy

ルネサス公式RAファミリ開発お役立ち情報ページがあります。本稿は、このページの中から、ソースコードを変更せずにprintfデバッグができるDymanic Printfを説明し、他の2方法と比較します。

printfデバッグ2方法

ソースコード変数値を出力し、デバッグする方法をprintfデバッグと呼びます。RAファミリ評価ボードにも、printfデバッグを容易にするツールや、外部ハードウェア（USART-USB変換）が実装済みのものもあります。

例えば、RAファミリのPFB-RA6E1（Cortex-M33/200MHz）、FPB-RA4E1（Cortex-M33/100MHz）の場合は、SEGGER J-Linkエミュレータサーキット経由でprintfデバッグできる無償J-Link RTT ViewerをPCへ追加すると、変数やユーザへの説明がPCへ出力できます。

競合他社の例では、STM32G071RBやLPCXpresso54114などは、評価ボードプログラミングとUSART-USBレベル変換機能を兼ねたハードウェアが実装済みのため、これを利用してVirtual COM経由でprintfデバッグが可能です。この場合も、Tera TermなどのPCコンソール表示フリーウェアが追加で必要になります。

Dynamic Printf

Dynamic Printfの特徴は、J-Link RTT ViewerやTera TermなどのPC追加ソフトウェア不要、e2studioなどEclipse IDEのDebug Console Viewへ、printfフォーマット変数数値を直接出力できることです。

Debug Console Viewへの出力設定は別途必要（Dynamic Printf動画30秒付近）ですが、前述のデバッグ2方法と比べると、ソースコードの記述変更も不要です。

Dynamic Printfは、ブレークポイントの一種です。一旦プログラムを停止し、設定変数をDebug Consoleへ出力後、自動的にプログラムを再開します。

例えば、センサAD変換値をDebug Consoleへ連続出力し、正常動作を確認する時などに重宝します。

RAファミリprintf 3方法まとめ

printf方法	J-Link RTT Viewer	Virtual COM	Dynamic Printf
ソースコード記述例	APP_PRINT(“\r\n> Current FSP version is v%d.%d.%d.”, version.major, version.minor, version.patch);	VcomSndMsg(uint8_t *String, uint32_t Size);	不要 (Debug Console設定要)
追加ソフトウェア	J-Link RTT Viewer SEGGER_RTT common_utlils.h	Tera Term	不要
追加ハードウェア	不要	TTL-USBレベル変換要	不要
特徴	手軽にPC出力可能色付き出力不可	競合他社標準PC出力色付き出力可能	ソースコード不変変数連続出力容易
出力例

RAファミリ評価ボードのprintfデバッグに使える3方法を説明、特徴などをまとめました。

printfデバッグは、デバッグの最も基本テクニックです。確認したい変数出力だけでなく、プログラムや操作方法の説明出力などにも使います。

Virtual COMの方法は、Tera Term追加が必要ですが一般的なMCU開発でよく用います。

J-Link RTT Viewerの方法は、TTL-USBレベル変換非搭載の低価格RAファミリ評価ボードで使います。

Dynamic Printfは、Eclipse IDE搭載機能です。ブレークポイントを設定し、変数のprintfフォーマット出力後、自動的に再実行します。センサAD変換値を連続表示する時など、ソースコード変更なしに手軽に変数出力とセンサ動作確認できるので便利です。

最初に示したルネサス公式RAファミリ情報ページには、本稿printf以外にも多くのTipsが掲載中です。説明や動画が短く纏まっているので、隙間時間のチェックに都合が良く、開発ヒントも得られます。

Windows重要パラメタ

2022年9月30日2022年10月14日 WithHappy

現時点でWindows ユーザが押さえておくべき重要パラメタ、お役立ちツールをまとめました。

参考にしたのは、2022年9月23日PC Watch記事：“Windows 11へのアップグレードはいつまで無料？”、窓の杜記事：“「Windows 11 2022 Update」のサポートは基本2年” などです。

Windows重要パラメタ

項目	Windows 11 22H2 Pro/Home	Windows 10
サポート終了（残りサポート期間）	2024年10月14日（約2年）	2025年10月14日（約3年）
大規模アップデート	年1回（今年9月21日済み）	年1回（今年10月予定）
小規模月例アップデート	第2水曜（日本時間）は適用必須、その他は月数回、適用任意
Win11無償アップグレード	2022年10月5日以降、無償アップグレード変更の可能性あり
Windows 12	3年毎の新Windows開発、2024年リリースの可能性あり

重要パラメタ説明とWindowsユーザお勧めアクション

Win10からWin11無償アップグレードが、今年10月5日以降変更の可能性がある点は、注意が必要です。これは、Microsoftが今年5月20日、公式発表済み（4.アップグレードQ&A参照）です。

Win11無償アップグレードが、10月5日に即日終了にはならないと思います。それでも、現行の無償アップグレードが、Microsoftビジネスの都合でいつ有償に変っても不思議ではありません。

また、9月21日に大型更新された最新Win11 22H2でも、途中、年1回の大規模アップデートを含む2024年10月14日までの約2年サポートです。つまり、ユーザがアップグレードを遅らせると、その分だけ残りサポート期間も短くなる訳です。

大・小アップデートが適用できるのは、サポート期間中のみです。期間を過ぎると、セキュリティや不具合対策がインストールできず、安心・安全なWindowsになりません。例えると、「賞味期限切れの食品」です。

Win11 22H2に追加された新機能の評価は、様々です。普通のWin10ユーザなら、新機能を全く知らなくても2021年のWin11 21H2よりも安定した最新Win11 22H2を、大きな違和感なく使えると思います。

3年毎の新Windows開発と、それに基づいた2024年Win12リリース情報もMicrosoftにはあります。

これらWindowsパラメタ状況から、Win10継続利用の必要がないユーザは、無償期間内に「早期Win11 22H2アップグレート」をお勧めします。

Windowsお役立ちツール

名称	機能
Rufus 3.20	ISOイメージファイルのUSBインストールメディア変換 Win11アップグレードツールMediaCreationTool代用
Winaero Tweaker-1.40.0.0	メニュー表示やタスクバー位置（上/下）変更ツール
Open-Shell-Menu	スタートメニューカスタマイズツール

Win11アップグレード要件を満たさないPCのアップグレード対策、Win11の新しいGUIを改善したいユーザには、上記Windowsツールをお勧めします（詳細は、次章の前投稿内容を参照してください）。

弊社全PC Windows 11 22H2アップグレード完了

前投稿で、弊社所有3PC全てをWin11 22H2で運用できる目途が立ちました。

そこで、23日（金）からの3連休中に、お勧めしたユーザアクションを弊社全PCへ適用し、Win11 22H2へのアップグレードを完了しました。2PCは、Win11アップグレード要件を満たし、1PCは、TPM 2.0要件のみ満たしません。この1PCが、先行Win11 21H2でした。

アップグレード要件を満たす2PC、対、TPM要件を満たさない1PC、これら3PCを同じWin11で運用することにより、PCトラブルや不具合が、差分のTPM起因か否かも明確になるはずです。

現在、3PC共に、Win11 22H2として問題なく動作中です。MCU開発ツールなどのアプリケーション/ツールも正常動作します。

弊社は、今後最新Windows 11 22H2にてPC運用し、IoT MCU開発を続けます。

Windows重要パラメタ深読み？

新発売のPCは、Mac以外、全てWin11搭載です。それでも、景気後退などによりPC売行きが全般的に低下すれば、Win11売上げも下がるでしょう。アップグレード有償化は、Windowsビジネスの売上げ低下打開策です。3年毎の新Widows開発には、資金も必要です。

メタバース普及やCOVID-19の影響で、Office 365やAzureなどのMicrosoftクラウドビジネスの方が、高いROI（Return On Investment）を期待できそうです。

Windowsパラメタは、Microsoftビジネスの変化、今後を物語っているのかもしれません。

あとがき：Win11セキュリティデフォルト強化に注意

弊社は、最新Win11で3PC運用を開始しました。Win11 22H2は、再起動時の変な日本語、“あなたはそこに～％です”が、普通の日本語に修正され、個人的には嫌いなタスクバー下位置も、だんだん慣れてきました。

Win11 22H2新機能情報は、ネット上に多くあります。操作性に関しては、慣れの問題です。セキュリティに関しては、Win10よりもデフォルト強化されています。アップグレードは、各種設定が引き継がれるはずですが、BitLockerなど要注意です。

アップグレード要件未達PCに、TPM起因トラブル/不具合が判明した時は、Win11からLinux へOSを変えます。IoT MCU開発アプリは、Win/Linux/Macマルチプラットフォーム、OS変更後も開発は継続可能です。アプリクラウド化になれば、ローカルPC OSは、セキュリティブラウザ提供だけです。

本ブログも、Linuxカテゴリを時々投稿します。Linux環境でIoT MCU開発を目指すユーザは、ご覧ください。

Windows 11 22H2大型更新成功

2022年9月22日 WithHappy

本稿は、Windows 11 22H2大型更新成功の速報です。

日本時間2022年9月21日、Microsoftは、Windows 11 22H2大型更新を一般公開しました。Windows 11初の大型更新です。弊社先行Win11は、Rufus 3.20を使い今回の大型更新に成功し、正常動作中です。

Win11 21H2 → 22H2

先行Win11 21H2は、TPM 2.0アップグレード要件のみを満たさないWindows 10 21H2 PCでした。

このPCを今年4月15日、Win10アプリケーションとデータ維持のまま、Rufus 3.18を使ってWin11 21H1へ無理やりアップグレードし、Win11として使えるかを3か月間評価しました。

結果は、タスクバー位置に不満が残るものの、GUIカスタマイズツール利用で使用感をかなり改善でき、Win11運用に問題はありません。

残る課題は、このTPM要件未達Win11 21H2が、22H2へ大型更新できるか否かでした。本稿で、この課題も解決しました。

※先行Win11詳細やRufusの使い方は、本稿末の関連投稿リンク参照。

Rufus利用Windows 11 22H2更新方法

最新版Rufus 3.20利用のWin11 21H2から22H2手動大型更新手順が下記です。

Windows 11 22H2手動大型更新手順
準備	①21H2バックアップ（更新失敗リカバリ対策） ②22H2インストールメディアダウンロード ③Rufusで22H2インストールUSB作成
更新	①21H2起動状態でインストールUSB setup実行 ②Rufusダイアログに従い数回クリック ③22H2大型更新完了

注意点は、準備②ダウンロードです。Windowsインストールメディア作成からダウンロードする点、DVD作成を選ぶ点です。

ダウンロード後、MediaCreationToolの代わりに③Rufusを使ってインストールUSBを作成します。USB作成時のWin11インストールスキップ項目は、全項目にチェックを入れました。

このチェック設定は、お好みで変えてください。全チェックを外すと、MediaCreationTool利用インストールと同じになります。アップグレード要件を満たすPCなら、全チェックを外しても良いでしょう。

また、手動更新のメリットは、ユーザの好きなタイミングで大型更新が開始できることです。

まとめ：Windows 11 22H2大型更新成功速報

Rufus 3.20を利用したTPM要件未達Windows 11 21H2の22H2大型更新に成功しました。Win11初の大型更新も、MediaCreationToolの代わりにRufus を使えば問題なく成功し、正常動作します。

ポイントは、インストール条件が厳しいMicrosoftツール：MediaCreationToolの代わりに、Rufus を使う点です。

今回の成功が、将来も続くかは不明です。しかし、「強力ツール：Rufusのおかげで、多くの要件未達Win10 PC延命が可能」となりました。本Win11 22H2状況は、適宜ブログでレポートします。

弊社残りの2PCは、どちらも厳しいMicrosoft公式Win11アップグレード要件を満たします。本稿の結果、弊社3PC全てをWin11運用できる目途が立ちました。

Windows 11 22H2新しい追加機能は、コチラの記事などを参照ください。

あとがき：Windows 11かLinux Mint

正式なWin11アップグレード要件を満たさないPCは、機能追加の少ないWin10のまま2025年10月まで使い続けるか、または、Linux Mintなどの別OSへ載せ替えるかの2択です。Win10サポート終了の2025年10月以降は、別OS搭載かPC廃棄の運命です。

アップグレード要件を満たす/満たさないに関わらずWin10の次期OSとして、先行Win11とLinux Mintの両方を試行した結果、Win11アップグレード運用の可能性が高まりました。理由は、本稿の結果、筆者のWin利用経験が長いこと、ブログ読者にWinユーザ数が圧倒的に多いことの3つです。

ちょっとしたトラブルや不具合の前兆のようなものが、PCには発生します。その発生の検出と対応に長い利用経験が活きます。Linuxの場合、筆者はこの検出の勘が未熟なため、動作異常に至った時は、正常状態へリカバリするよりも簡単な再インストールを活用しました。

Mintは、Winに比べユーザ追加アプリを含む再インストールが簡単な点も、本試行の収穫です。

PCの主要アプリケーションは、マルチプラットフォーム化が進行中です。各ベンダのMCU開発ツールもまた、Win/Linux/Mac対応済みですので、OS依存性はありません。

PC OSは、以上の状況です。アップグレード要件未達PCをWin11にするか、あるいは、Linux Mintにするかの最終決定は、2025年10月の予定です。但し、複数PC運用の都合上、現実解としてはWin11になりそうです。

RA用e2studio 2022-07リリース

2022年9月16日2022年9月30日 WithHappy

2022年8月31日より、FSP v4.0.0同梱RAファミリ最新開発環境e2studio 2022-07が、ダウンロード可能です。

FSP for RA MCU Family, version 4.0.0. (2022/08/31)

FSP同梱インストーラ利用指示

RAファミリはFSP同胞インストーラ利用指示 — RAファミリはFSP同梱インストーラ利用指示

RAファミリ以外の単体e2studioバージョンアップは、7月20日でした。

RAファミリのアップデートは、上記リリースノートのようにFSP（Flexible Software Package）同梱インストーラ利用指示があるため、RA用のe2studio 2022-07リリースは、単体から1.5ヶ月遅れの8月31日になりました。同梱インストール理由は、不明です（単体e2studio+単体FSPインストールも可能ですが、指示に従う方がBetter）。

また、e2studio 2022-04以降、Windows 11-64bitに正式対応しました。弊社の先行Win11 21H2も、最新FSP同梱RA用e2studio 2022-07の正常動作確認済みです。

但し、ルネサス半導体セミナーやリリースノート、サンプルコードの説明書きなどは、未だWin10です。

Win11への移設は、今秋予定の22H2発表後でも良いと思います。Win11 22H2は、9月20日リリース情報があります。仮に9月20日なら、次回投稿は、弊社Win11 21H2の22H2大型更新レポートになるでしょう。

Example Project Bundle

弊社推薦RA6/4ファミリ評価ボード：FPB-RA6E1、FPB-RA4E1サンプルコード：FPB-RA6E1/FPB-RA4E1 Example Project Bundleも、最新版がリリースされました（2022/08/11）。

最新Example Project Bundleでも、多くのベアメタルサンプル、FreeRTOSサンプルは1個（下線）、Azure RTOSサンプルは0個です。

Cortex-M33コア採用のRA6/4は、IoT MCUでFSPもRTOS対応済みです。先ずは、ベアメタル開発でFSPに慣れてもらうという意図でしょうか？

RA開発環境まとめ

9月16日時点の最新RA開発環境バージョンアップ状況をまとめたのが下図です。

RA用の開発環境は、FSPバージョン版数が不揃いです。例えば、FSP同梱e2studioのFSP版数は、v4.0.0なのに、最新Example Project BundleのFSP版数は、v3.8.0で1世代前です。

しかし、v3.8.0のExample Project Bundleは、下図のようにFSP ConfigurationのBSPタブで最新FSP version 4.0.0へ変更が可能です。変更後、Generate Project Contentをクリックすれば、FSP v4.0.0でのAPIコードやひな型コードが生成されます。

また、直にIoT MCU RTOS開発を始めたいベアメタル開発経験者には、FreeRTOSやAzure RTOSサンプルコード数が少ないことも問題です。

対策案として、前投稿説明のベアメタルサンプルコードからRTOSコードを自作する方法をお勧めします。

RTOSの目的や機能を教科書から学ぶよりも、自作サンプルコードから理解していくベアメタル起点のRTOS習得方法は、RTOSスキルを磨きベアメタル補完RTOS開発の面白さを知る良い方法だと思います。