IoT MCUのHappyTech

ツイッター買収

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アップグレート方法開示と同様、タスクバー上下左右配置の復活、是非お願いします。

第2のRAサンプルコード

2022年3月18日2022年3月25日 WithHappy

ルネサスRAファミリ開発に評価ボード毎のサンプルコードが重要であることは、過去何回か投稿済みです。今回は、これとは別の、「Stacks毎」に提供される第2のサンプルコード利用方法を説明します。

RAプロジェクトソースコード開発手順

ごく簡単にRAプロジェクトのソースコード開発手順を説明すると、

1) 利用「Stack」をFSPパースペクティブへ追加
2) Generate Project Contentクリック
3) 生成されたDeveloper AssistanceのStack API群から、利用APIをソースコード上へコピー&ペースト

という3手順の繰返しです。Stackとは、MCU周辺回路のことです。

評価ボードサンプルコードは、あらかじめ1)～3)をエキスパートが行い、サンプルで利用するStackとStack APIは、エキスパートが選択済みの実動作プロジェクトです。

一方、開発者自らが、1)～3)手順でソースコード開発する時は、どのStackを追加するか、利用するAPIは何か、を検討する必要があります。この検討に必要な情報は、全てFSPパースペクティブへ配置したStackのℹ️から得られます。

ℹ️をクリックすると、Stack PropertiesのAPI infoタブ相当の英文解説が読めます。内容は、Function、Overview、Exampleなどです。API info表示内容と同じですが、より詳しい説明が得られます。

「Stack毎」に提供される第2のRAサンプルコードとは、このExampleのことです。

Low Power Modes (r_lpm)の例

MCUアプリケーションに、低電力動作は必須です。RAファミリには、スリープ/ソフトウェアスタンバイ/スヌーズ/ディープソフトウェアスタンバイの4低電力動作モードがあります。例えば、RA6E1グループユーザーズマニュアルハードウェア編の10章を参照ください。

電力消費の最も大きいMCUを停止するのが、スリープモードです。スリープからの復帰時間も短く、簡単で効果的な低電力動作が可能です。

RAファミリで低電力動作を行うには、FSPパースペクティブへ、最初の図に示したLow Power Modes (r_lpm)スタックを追加します。

Stackのℹ️とサンプルコード

追加Stack ℹ️クリックで表示されるのが、LPMの詳細説明です。LPMスタック追加で増える5個全てのLPM APIが解ります。また、スリープモードプロパティがデフォルト設定済みなのも解ります。

このスリープモードのExampleが、下記LPM Sleep Exampleです。

利用APIは、R_LPM_Open()とR_LPM_LowPowerModeEnter()の2個のみです。assert(FSP_SUCCESS == err)は、次章で説明します。

注意点は、この「Stacks毎」に提供されるサンプルコードは、一般的なサンプルコード構成、つまり、初期設定と無限ループ内処理の記述形式ではないことです（一般的サンプルコード構成については、コチラの関連投稿参照）。

ここで示されているのは、LPMスリープモード時に利用するAPIとその利用順序です。

つまり、最初にR_LPM_Open()でスタックAPI利用可否を判断し、次に、R_LPM_LowPowerModeEnter()でスリープ動作OKの判断をしているだけです。

LPM以外のStack Examplesでも同様です。繰返しになりますが、Stack Exampleは、利用APIとその利用順序を示します。

従って、自分のソースコードへ取込むには、Developer Assistance内に生成された5個のLPM APIから、R_LPM_Open()を初期設定へ、次に、R_LPM_ LowPowerModeEnter()を無限ループ内の適当な個所へ、コピー&ペーストすれば、LPMスリープモードのソースコードが完成です。

assert(FSP_SUCCESS == err)

assert()は、()内が真の時は、何もしません。偽の時は、発生場所や関数名、ファイル名などをコンソール出力し、プログラムを停止します。API利用後の結果判断に活用しています。

「Stacks毎」に提供されるサンプルコードでは、多くのStack API利用箇所で使われています。

lpm_fpb_ra6e1_wpと比較

lpm_fpb_ra6e1_wpのFSPパースペクティブとhal_entry.cのMain loop部分

評価ボード毎のサンプルコードにも、低電力動作サンプルがありますので、前章Stack Exampleと比較します。

RA6E1の場合は、lpm_fpb_ra6e1_epです。このFSPパースペクティブとhal_entryのMain loopの一部抜粋が上図です。多くのLPM関連スタックが追加済みで、Main loopの低電力動作を解読するのも大変です。

これは、評価ボードサンプルコードが、初めに示した4低電力動作モードの状態遷移を示すプロジェクトだからです。スリープ動作のみを実装する時は、前章LPM StackのExampleを参照した方が簡単に理解できます。

勿論、評価ボードサンプルコードとStack Example、両方を参考にしてソースコードを開発する方が良いことは言うまでもありません。

Stack Exampleが、評価ボードサンプルコード理解を助ける第2のサンプルコードとして役立つことを示したかった訳です。

追加Stacks一覧

本稿は、LPM Stackを例に第2のサンプルコードを説明しました。

FSPパースペクティブへ追加可能なStackは、Stackタブを選択後、右上のNew Stack>をクリックすると一覧表示されます。

まとめ

RAファミリのソースコード開発は、FSPパースペクティブへStackを追加後、一括生成されるDeveloper Assistance内の多くのStack API群の中から、利用APIを適切な順序でソースコードへコピー＆ペーストすることで進めます。

利用Stackに複数動作モードがあるなど評価ボードサンプルコードが複雑な場合や、開発者自らが利用Stack APIを検討する場合は、第2のサンプルコードとして、追加Stackのℹ️クリックで得られるExampleに示されるStack APIとその利用順序を参考に、ソースコード開発をする方法を示しました。

Windows 10、11、12

2022年3月11日2022年3月23日 WithHappy

Windows 11リリース後、数か月が経過しました。早くもMicrosoftは、次期Windows 12開発着手の情報もあります。そこで、Windows PCの使い方をまとめます。何をどう対処すべきかの指針を、整理するためです。

Windows 11問題

筆者PCの使い方では、TPM以外のWindows 11問題は、タスクバーとMicrosoftのユーザカスタマイズを拒む姿勢です。Windows HelloやBitLockerは、使いません。が、今後セキュリティ比重は増しますので、TPM 2.0導入は我慢できます。

しかし、利用頻度が高いタスクバーがWindows 10のようにカスタマイズできない点と、それを強要するMS姿勢は、OSシェア断然トップのWindowsらしくありません。

過去アップグレード後のWindowsは、各種カスタマイズが容易でした。ところが、アップグレード時、MSアカウント必須に変われば、Hello利用やOneDrive接続、ユーザフォルダ名などもMS推薦設定になります。

10とコア共通のWindows 11リリース後、上記以外にもブラウザEdge、検索エンジンBing設定などにユーザカスタマイズを拒む姿勢変化が見られます。いずれも、Chrome、Google検索に比べ低シェアのためでしょう。

例えると、Macはクリエイター向けオートクチュール、従来Windowsはユーザがカスタマイズ容易なプレタポルテでした。ところが、Windows 11は、カスタマイズを許容しません。MSが想定した通りのメガネ（検索エンジン）と上着（タスクバー）を着なさい、と言っているようなものです。

従来Windowsユーザの生産性向上に反したMSの姿勢です。うがった見方をすれば、これはWindows 12の布石かもしれません。つまり、12は過去Windowsしがらみを切った全く新しいOSへ変わる可能性です。

解決DeadlineとOS利用形態

上記のようにカスタマイズを拒むWindows 11と10の混在利用は、効率を下げるため避けたいです。OS検討Deadlineは、Windows 10サポート終了の2025年10月です。

それまでのOS状況を整理すると、3利用形態があり得ます。

形態1：Windows 10を2025年10月まで利用

2025年10月14日まで、いかに上手くWindows 10を活用するかの特集が公開されました。

年1回へ減ったWindows 10大型更新さえ行えば、殆どのユーザが、従来の基本的OSメインテナンス実施でDeadlineまで安全に使えます。

Windows 10をサポート終了まで使う意味で、重要な記事です。Windows 10の手動による大型更新方法は、コチラの関連投稿を参照ください。

形態2：Windows 11アップグレード

未完成OSがWindows 11です。ユーザ反応をMSが見たうえで機能変更や追加を随時行っていきます。この方法も、従来新OSに無い新しいMS姿勢です。

悪評タスクバーが、改善されるかがポイントです。年1回のWindows 11大型更新は、Windows 10からのアップグレード採否を見極める機会にします。

また、使用中PC買換えタイミングもこの3年半に重なります。故障前に新PC購入が必要です。日本では、春と年末商戦時が、時期的に良いと考えています。

形態3：Windows 12アップグレード

現在のWindows 11は、Windows MeやVistaになるかもしれません。MSのWindows 12開発着手が、従来比、早いのか遅いのかも不明です。

しかし、11が不評で、中途半端なOSであることは確かです。Windows 12は、当然OSコア刷新、セキュリティもメタバース向けに強化した新世代OSになると思われます。インターネット進化版メタバースは、コチラの関連投稿を参照ください。

PCハードウェア仕様が許せば、11を飛ばして、12へアップグレートする可能性もあり得ます。

Plan B：Linux PC乗換え

Windows 10は、Deadline後は使えません。11や12アップグレートが困難な時は、WindowsからLinuxへ乗換えます。

現行PCのハードウェア仕様は、Linux化に問題ありません。詳細は、専用Linux Mint 20.3を使って評価します。Linux上でWindowsソフトを動作させるWine 7.0なども活用予定です。

まとめ：OS対策3指針

Deadline は、Windows 10サポート終了2025年10月14日、残り3年半です。PC OS対策は、保守的か革新的かで、指針が別れると思います。筆者は、以下3指針で臨みます。

指針1：11見極め･･････2022年秋、23年秋、24年秋、25年秋
Windows 11初回大型更新の今秋まで現行Windows 10 21H2利用、11アップグレード採否は、大型更新内容で判断。この判断は、年1回の11大型更新毎に再検討。

指針2：12情報取集とLinux乗換リスク評価
Deadlineまでに11アップグレードを行わない場合は、Windows 12に期待するか、または、Linux PCへ乗換え。実務移行問題洗い出し専用Linux PC：Linux Mint 20.3/4/5で乗換リスク評価。

指針3：11 カスタマイズ性見極め
DeadlineまでにPCハードウェア新規購入の場合は、最新ハードウェア（Microsoft Plutonプロセサなど）搭載Win 11機とし、使い慣れたWin10カスタマイズがどの程度可能かを探る。

予定より少し早く新PCを調達し、指針3の11 カスタマイズ性の見極めを行う予定です。

RAアプリケーション開発の骨格

2022年3月4日2022年3月11日 WithHappy

ルネサスRAファミリ評価ボードの動作テストプログラムと、周辺回路サンプルコードから判るRAファミリアプリケーション開発Tipsを示し、このTipsで開発したアプリケーション:App0を公開します。

評価ボードは、RA6E1を用いましたが、他のRAファミリ評価ボードでも同じです。

hal_entry.cとuser_main.c分離

RAファミリは、評価ボード毎にサンプルコードが提供されます。例えば、RA6E1の場合は、FPB-RA6E1 Example Project Bundleがそれで、この中にADCやタイマなどの周辺回路サンプルコードがあります。また、評価ボードテストプログラム：TP（quickstart_fpb_ra6e1_ep）も含まれており、他の周辺回路サンプルコード：EP（Exampleプログラム）とは少し違うファイル構造になっています。

違う原因は、EPが、コード判り易さのため、メイン処理をhal_entry.cに集中して記述するのに対し、TPは、様々な評価ボードへも対応するため、いわば汎用アプリケーション構造となっているからです。

簡単に言うと、FSPが生成するメイン処理：hal_entry.cと、ユーザ追記のメイン処理：user_main.cをファイル分離し、ユーザ開発部分の可搬性を上げた構造を持つのがTPです。

開発したMCUアプリケーションに可搬性があると効率的で生産性もあがります。TP同様、RAアプリケーションも、hal_entry.cとuser_main.cを分離した構造で開発する方法をお勧めします。

※FSP（Flexible Software Package）やサンプルコードの詳細は、コチラの関連投稿を参照ください。

SEGGER RTT Viewer利用

TPとEPには、もう1つ違いがあります。それは、EPには、PC入出力マクロが実装済みの点です。

例えば、gpt_fpb_ra6e1_ep（最初のgptが汎用PWMタイマ、fpb_ra6e1が評価ボード、epがExample Programを示す）ならば、タイマ利用例をPCへ出力し、その設定値をPCから入力できます。

対PC通信にはUSB経由Virtual COMポートを利用する評価ボードが多いのに対し、ルネサスRAファミリは、評価ボード実装デバッガのSEGGER RTT Viewerをこの役目に使います。USARTなどのMCU資産を消費しないメリットがあります。

PCでRTT Viewerを使うには、コチラからJ-Link Software and Documentation Packをダウンロードし、PCへインストール後、J-Link RTT Viewer起動で評価ボードとPC通信ができます（最初の図）。

但し、RA6/4などCortex-M33コアファミリ開発の場合は、ビルド後生成されるmapファイルからRTT Control Block Addressを探し、Viewer起動ダイアログへ入力する必要があります。

プログラム変更やFSP版数が変わると、このBlock Addressも変わるので、生成mapファイルAddress値の再入力が必要です。

RAアプリケーション開発時にも、このPC通信マクロが使えるとprintf/scanfの代用になり便利です。FSP生成プロジェクトでPC通信マクロを利用するには、生成プロジェクトのsrcフォルダへ、SEGGER_RTTとcommon_utili.hの両方を手動で追加します。

追加元のSEGGER_RTTとcommon_utili.hは、どのEPのものでも構いません。

App0特徴

以上から、RAアプリケーション開発時は、FSPが生成するオリジナルファイルに

①HAL生成メインhal_entry.cとユーザ追記メインuser_main.cを分離したファイル構造
②srcへSEGGER_RTTとcommon_utility.hの手動追加

を行うと、ユーザ開発ソースコードのRAファミリ間での可搬性が高く、PC通信も容易なアプリケーションの骨格（Skelton）が完成します。

この方法で開発したアプリケーション：App0を示します。タイトルをPCへ出力するだけのアプリケーション骨格です。この骨格に、開発ソースコードを肉付けしていけば、肉付けソースコードのRAファミリ間可搬性が高く、デバッグ効率も高いアプリケーション開発ができます。

開発したApp0プロジェクト圧縮ファイルは、コチラよりダウンロード可能です。ご自由にご利用ください。

e2 studioへのインポート方法は、インポート>既存プロジェクトをワークスペースへ>アーカイブ・ファイルの選択で、App0.zip指定です。

App0開発手順

以下にApp0プロジェクトの作成手順を示します。

1）FSPで新規Bare Metal – Minimalプロジェクト生成
2）App0 FSPパースペクティブでGenerate Project Contentクリック
3）他の周辺回路サンプルコードのsrc>SEGGER_RTTとcommon_utility.hをコピーし、App0プロジェクト>srcフォルダへペースト
4）src>hal_entry.cのL3へextern void UserMain(void)追記、L19へUserMain()追記
5）src上で新規>ソース・ファイルをクリックし、UserMain.c追加
6）src上で新規>ヘッダー・ファイルをクリックし、UserDefine.h追加
7）UserMain.cとUserDefine.hへ、前章ソースコード追記
8）ビルドし、Debug>App0.mapファイルから_SEGGER_RTTを検索、そのアドレスを、RTT Viewer起動ダイアログのRTT Control Blockへ入力後OKクリック
9）評価ボードへApp0をダウンロード、実行
10）PCのRTT Viewerで図1のタイトル出力確認

4、5、6の追加ファイル名は、UserMain.c、UserDefine.hなど先頭大文字のPascal形式を用いています。これは、プロジェクト・エクスプローラーでオリジナルのFSP生成ファイルとユーザ追加ファイルの識別が容易になるからです。

また、筆者は、Cソース・ファイル毎にヘッダー・ファイルを追加するより、ソース・ファイル内にプロトタイプ宣言を追記し、個別ヘッダー・ファイルを追加しない方が好みです。4のhal_entry.cへUserMainプロトタイプ宣言を追記したのも、このためです。

UserMain()は、初期設定と無限ループに分け、初期設定にRttInit()とUserInit()を追加しています。RttInit()でタイトルをPCへ出力し、UserIint()は、内容が何もありません。骨格ですので、利用する周辺回路に応じて、ここへ初期設定コードを追記することを想定しています。

まとめ

RAファミリ評価ボードテストプログラムと周辺回路サンプルコードから、hal_entry.cとuser_main.cの分離ファイル構造と、RTT Viewer利用の対PC通信マクロ実装済みのアプリケーションスケルトン（骨格）：App0を示しました。

この骨格へ、開発ソースコードを追加していけば、ユーザ追加部分のRAファミリ間可搬性が高く、デバッグ効率も高い、RAファミリアプリケーションが開発できます。

もちろん、3月末を目標に開発中のRAファミリテンプレートも、このApp0へ評価ボード実装LED点滅やチャタリング対策済みSW機能などを追加します。RAファミリテンプレート構想はコチラの4章、RAテンプレートの仕組みはコチラの関連投稿を、参照ください。

最近の組込みCコード書き方

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

RAファミリFSP生成のBare Metal Blinkyサンプルコードの書き方が、筆者のCコード書き方と違っていて驚いた点を示します（FSP：Flexible Software Packageとは何かは、コチラの関連投稿を参照）。

変数宣言位置

筆者のC変数宣言は、関数の冒頭、実行文の前に全ての変数宣言を行います。しかし、Bare Metal Blinkyサンプルコードは、変数が必要になった直前で変数宣言をしています。こちらの方が、コードが読み易いですね。

これは、使うC言語規格が異なるからです。筆者は、古いC90（1990年版）、FSPは、C99（1999年版）以降の規格、書き方を採用しています（参考文献：C言語の仕様）。

C言語規格も改良や改版が進み最新規格は、C11（2011年版）です。更に、C17やC2xなどへ進化中だそうです。下位（旧版）互換性は、コンパイラが賢いので保たれています。エッジAIが導入されると、古い書き方は止めなさいとアドバイスが出たりするかもしれません😅。

IoT MCU開発では、従来比、他者が開発したコードやライブラリを読み、理解・利用する機会も格段に増えます。

独立行政法人情報処理推進機構から、組込みソフトウェア開発向けコーディング作法ガイド［C言語版］ESCR Ver. 3.0（2018年）のPDF版がダウンロード可能です。

ガイド想定利用者は、プログラマやレビュー者（P3参照）とありますので、本ブログ読者は目を通しておくのも良いと思います。

新しい規格に縛られる必要は、コンパイラのおかげでありません。しかし、FSP生成サンプルコードに習い、今後はC99以降の書き方を採用します。

いわゆるLチカサンプルコードであっても、なおざりにできない例です。そこで、基になったFSP生成のBare Metal BlinkyとMinimalスケルトン（骨格）の差をまとめます。

Bare Metal Blinky生成方法

各種周辺回路サンプルコードは、FSPとは別に評価ボード毎に提供されます。しかし、Bare Metal Blinkyだけは、FSPで生成可能です（FSPと評価ボード毎の周辺回路サンプルコードは、コチラの関連投稿を参照）。

その狙いは、筆者のような古いC記述者へ新しい記述法を知らせる、または、Blinkyと周辺回路無しのMinimalなスケルトンとの差分を知らせる、などが考えられます。

FSP生成Bare Metal Blinkyは、通常の新規プロジェクト作成方法と同じ、ファイル>新規>Renesas C/C++ Project>Renesas RAクリックが最初の手順です。ダイアログに従って手順を勧めると、最後にBare Metal – BlinkyかMinimalかの選択が可能です。

Blinky選択とFinishクリックで、g_ioport I/O Portスタックだけが配置済みの［Blinky］FSP Configurationパースペクティブが開きます。

念のため、Generate Project Contentをクリック後、src>hal_entry.cを開くと、1章で示したC99以降の書き方で記述したBlinkyサンプルコードが生成されます。

Bare Metal BlinkyとMinimalの差分

BlinkyとMinimalスケルトンの差は、hal_entry()のTODO: add your own code hereの下にBlinkyコードが有るか無いかだけです。FSP Configurationも全く同じです。

つまり、IOPORT未使用のアプリケーションは無いので、例えMinimalと言えデフォルトでg_ioport I/O Portスタックは配置済みで、そのスタック利用例がBlinkyという訳です。

FSP生成Bare Metal Blinkyに習い、筆者も今後はC99以降の新しい書き方でCソースコード記述をしていきます。