IoT MCUのHappyTech

日本とアイルランドのIoT

2022年8月5日2022年8月19日 WithHappy

2022年7月29日ZDNet Japan掲載、アイルランドIoT事情についての記事（前編、後編）と、2022年8月1日MONOist掲載、調査結果からみる日本製造業将来と期待の記事を紹介、両国のIoT開発現状を比較します。

アイルランド

	北海道	アイルランド共和国
面積	8万3,400㎡km	7万300㎡km
人口	530万人	492万人

日本と同じ島国で、面積、人口が北海道より少し小さいアイルランド共和国は、記事によると世界最大の情報通信技術（ICT）サービス輸出国です。

アイルランド国内総生産（GDP）は、世界トップ10にランク（Wikipedia）されます。

アイルランドIoT事情

ごく簡単に記事要旨をまとめます。

アイルランドは、IoTを「データ収集（Collect）」「接続（Connect）」「変換（Transform）」の3カテゴリに分類、さらに3カテゴリをまたぐ形で事業展開する企業をサポート、IoTサービス進化を現実化する研究施設もある。

「IoTビジネスに最適な国」を目指し、行政や大学などの研究機関を整備、世界各国から有力企業とノウハウを集積した結果、2022年経済成長率5.4%､2023年4.4%と予測される高い経済成長に繋がっている。

日本製造業の将来と期待

MONOist日本読者による製造業の将来と期待についてのアンケート結果が、3枚の図にまとめられています。

要旨を簡単にまとめます。

・先が読めないので予想し準備することは不可能。だから、変化に合わせた柔軟性が重要。
・リアル活動制限のコロナ禍、デジタル環境で様々な業務ができることが判明。
・日本製造業将来が明るい/暗い回答はほぼ同数で25%、残り50%はどちらとも言えない。
・AIやロボット、自動運転などの自動車分野、メタバース/ローコード技術に期待。
・日本モノづくりは、世界的に見ると特殊な立ち位置。

最後を除いては、日本に限らずどの国の企業、技術者でもさほど違わないと思います。違いは、日本の国家指針の無さ・見えなさ、変化に対するスピードの遅さだと思います。

まとめ：個人レベルは選択と集中

日本とアイルランドのIoT開発現状を比較しました。

関連分野が広く、しかも、各分野の奥行も深いIoTです。日本の開発者個人にとっては、アイルランドのIoT 3カテゴリ分類は、1つの「指針」になると思います。

例えば、IoTエッジMCU開発者ならば、先ずはデータ収集、次に無線/有線の接続、最後にAI向けのエッジデータ変換というように、アイルランドガテゴリに沿った技術区分と優先順位を付けることができます。

漠然とIoTを捉えるより区分と優先順位があれば、より集中、選択してIoT技術を習得できます。しかも、そのカテゴリ分けは、世界最大のIoTサービス提供実績があるアイルランドカテゴリに基づいているので、「世界的モノづくりへ通用」する可能性も高いです。

ガラバゴス技術の多い日本にいると、自身の技術がはたして世界で通用するかの不安は付きものです。

不安払拭のため、時には開発者個々人が、世界（今回はアイルランド）へと視野を広げ、自身の開発領域へフィードバックをかけ、「選択、集中した技術習得」が効果的なIoTだと思います。

Linux Mintはなぜ良いか

2022年7月29日2022年8月5日 WithHappy

Windows 11へアップグレードできないWindows 10 PCの代替OSに、Linux Mintがなぜ良いかを説明します。また、後半は、選択肢が非常に多い場合の選択方法を示します。

2年前のLinux Mintお勧め理由

2年前、次の2点からMintをお勧めしました。

① Linux MintとUbuntu比較から（2020-08-21）
② Linux MintとWin10大型更新比較から（2020-09-04）

Win10大型更新は、年2回から1回へ変わるなど投稿内容と現状が合わないものが出てきました。また、最新版Ubuntu 22.04 LTS情報も多く出てきました。

そこで、2年間のMint使用経験から、Windows代替OSとしてMintをお勧めする理由をまとめます。

理由1：Windows 10スペックで快適動作

Win11アップグレード要件を満たさないWin10 PCを、無理やりWin11 21H2にしても問題なし、但し、次期Win11 22H2大型更新できるかが課題、これが前稿の内容でした。

この課題は、11アップグレード要件未達PCを使い続ける限り避けられません。対処療法は、見つけるつもりです。

根本対策は、WindowsからLinux MintへのOS載せ替えです。Mint要求スペックは、Win10よりもかなり低いです。

・64bitプロセサ
・2GB RAM (4GB recommended for a comfortable usage)
・20GB of disk space (100GB recommended)
・1024×768 resolution (on lower resolutions, press ALT to drag windows with the mouse if they don’t fit in the screen)
※出展：次期Mint大型更新ベータ版：Mint 21 Cinnamon Edition – BETA Release仕様より

つまり、Win10動作PCなら、現行のMint 20.3はもちろん、次期Mint 21でも快適に動作します。

理由2：Windows 10/11に近い操作性

「Windowsユーザが親しみ易いLinuxディストリビューション」、これがLinux Mintを使って得た所感です。具体例を示します。

・USBから手軽にインストールでき、お試し利用も可能（日本語環境も同時インストール）
・LibreOffice安定版（Still）やWindowsペイントなどのアクセサリ相当も同時インストール
・ブラウザは、Firefoxが同時インストール
・Windowsと同じGUI操作、スタートメニューやタスクバー位置（モニタ下、左側）も同じ

つまり、お試しインストール直後から、Windowsと殆ど同じ感覚でPC操作ができます。OS乗換を意識せず、Windows操作経験をそのまま活かしたLinux Mint操作ができるのが最大の特徴です。

LibreOfficeが使えれば、資料作成なども直ぐに開始できます。しかも、Mintをインストールする前に、実機で試せます。「MintがWindowsからの移設」を目的の1つとしているからだと思います。

数多いLinuxディストリビューションのベンチマーク

Linuxディストリビューションには、Mintの他にもUbuntu、Debianなど多くの種類があります。それぞれに特徴があり、ユーザ数が多く、ネット情報も多いのがUbuntuとDebianです。

但し、UbuntuやDebianは、Linux初心者には「しきい」が高いと思います。例えば、日本語環境やGUIの追加インストールが前提で、使え始める前に多少の手間が掛かります。この追加段階で失敗リスクもあります。

Windowsと同様、失敗などに対応できるOS利用経験があれば、UbuntuやDebianでも問題はありません。Mintは即利用重視、UbuntuやDebianは環境構築重視です。

多くのネット情報は、失敗やトラブル発生時には役立ちます。しかし、OSは安定動作が必然、本来は「トラブル無しの影の存在」のハズです。

マルチプラットフォームアプリケーションが多くなった現在、主役はアプリです。筆者は、MCU開発ツールと資料作成ツールのLibreOfficeが快適に動けば、OSに求めるのは安定性とセキュリティです。

Mintを使っていれば、そのうち不満箇所が出てきます。その時に、UbuntuやDebianの特徴が理解できるハズです。つまり、自分にとってLinuxの何が重要で、何を重視するかがより明確になる訳です。これが、ベンチマーク（水準点、基準）です。

Windowsの好みが個人個人で異なるように、Linuxベンチマークも個人で異なります。

先ずはMintを使ってLinuxベンチマークを持ち、次の段階で、数多いLinuxディストリビューションから要求ベンチマークに合うUbuntu、Debianなどを選べば良いと思います。

まとめ：Linux Mint選択理由

理由1：Windows 10スペックで快適動作
理由2：Windows 10/11に近いGUI操作性

どちらも2年間利用した筆者Linuxベンチマークによる評価です。Mintは、安定指向OSなので、トラブルも無く、大型更新なども成功しています。MCU開発ツールやLibreOfficeも動作します。

Mintには、高機能な方からCinnamon、MATE、Xfceの3種類のGUIがあります（筆者はMATE利用中）。USBお試しインストール（正式名はLive Boot）でお好みのGUIが試せます。掲載図は、英語版GUIの抜粋ですが、雰囲気は判ると思います。

選択肢が多い時の選択方法

選択肢が多いと選びにくいということもあります。

例えば、Linuxディストリビューションや新しいWindows 11ノートPC選びなどです。ブログ読者から多くのベンダMCUからどれが良いですか、などのご質問を頂くこともあります。※この時は、「高性能汎用MCUをお勧め」しています。

このように選択肢が多い時の対策が、ベンチマーク（基準）設定です。

基準があって、その基準より上か下かを判断すれば、選択肢は、おのずと絞られてきます。問題は、ベンチマークは何かです。同僚や先輩にベンチマークを聞くのも1つの方法です。

重要なことは、ベンチマークの上か下かの判断をご自分で行うことです。

この判断も他人に任せると、それは他人の選択肢をそのまま利用したことになります。逆に、ベンチマークそのものは、最初は、適当に選んでも良いと思います。

とりあえずベンチマークを設定し、上下判断を行っているうちに、自分にとって本当のベンチマークが明確になってきます。複数ベンチマークでも同様です。

ベンチマークは、判断結果で変わるものです。ベンチマーク設定よりも、上下判断にこだわっていれば、多くの選択肢からご自分に合った選択ができます。

Windows 11非対応PCアップグレード後3ヶ月

2022年7月22日2022年7月29日 WithHappy

本稿は、Windows 11非対応PCアップグレード後の3ヶ月状況、Win11 GUI変更ツール、次期Windows 12/13情報などをまとめます。

今年の4月15日、Windows 11アップグレート要件を満たさないWin10 PCを、強引にWin11 21H2へアップグレード後、3か月が経過しました。この期間、トラブルも無く安定動作しています。

今秋大型更新Windows 11 22H2の情報も出回ってきました。評判が悪いモニタ下タスクバー固定は、変わりそうにありません。つまり、次期Win 11 22H2もタスクバー右配置は期待できません。

2024年Windows 12

Windows 12開発着手は、コチラで投稿しました。7月15日、Microsoftが、新しいWindowsを3年周期でリリースするかもしれないという情報も入ってきました。つまり、2024年Windows 12リリースの可能性です。

Microsoft は、「最後のWindowsはWindows 10を破棄」しましたので当然の事かもしれません。

Win11は、OSコアがWin10の流用です。メタバースなどの新世代クラウドエッジクライアントOSとして旧Win10コア流用は中途半端、ハードウェアの世代交代が激化する昨今、OSコア進化も必然の気がします。

事実、今年発売のIntel 12世代プロセサは、11世代から大きく性能向上し、新発売のノートPCは、こぞって12世代を採用しています。Microsoftが、プロセサ性能向上分を新コア設計へ適用しWindows 12をリリースしても不思議ではありません。

Windows 11非対応PCアップグレード後3ヶ月状況

Win11アップグレード要件を満たさないPCは、2025年10月14日、Win10サポート終了までがその寿命です。アップグレード非対応PCを、「Win10アプリケーションとデータ維持」の条件で強引にWin11 21H2へアップグレードし、延命可能かの評価が前投稿でした。

前投稿、1週間の評価結果抜粋が、下記です。

・Win10アプリ（MCU開発アプリ含む）は、Win11 21H2でも正常動作
・アップグレード後のWindows Updateは、問題なく動作
・悪評ツールバー下固定など使いにくいGUIは、次期更新22H2で改善期待

3か月経過したPCの状況が、下記です。

・Win10アプリ（MCU開発アプリ含む）更新なども正常動作
・Windows Updateも問題なく動作

つまり、要件未達PCをWin11 21H2に強制アップグレードしても、何ら問題なく運用できています。

残る課題は、このPCが次期Win11 22H2へ更新できるか否かです。これは、今秋結果が判り次第レポートします。なお、本PCは、TPM 2.0が未達要件です。従って、Win11 22H2大型更新時に、TPM足切りがあるかが判明します。

Windows 11 GUIカスタマイズツール

様々なWindows GUIカスタマイズツールがあります。お勧めが下記2ツールで、使用感がかなり改善されます。これらツールを使うと、従来操作性も維持しながら、新しいWin11 GUIへの移行も容易です。

・Winaero Tweaker-1.40.0.0 (Win11対応済み)
・Open-Shell-Menu（Win11未対応、旧名：クラシックスタートメニュー）

OSは、アプリの動作基盤にすぎません。

タスクバー下固定のような操作性悪化Win11 GUI変更に対し、これらツールが役立ちます。

Winaero Tweaker

Winaero Tweakerは、メニュー表示やタスクバー位置変更ができるツールです。1.40.0.0では、タスクバーのモニタ上変更が可能です。左右はまだNGです。

その他、多くのWin11 GUIカスタマイズが可能ですので重宝します。

Open-Shell-Menu

スタートメニューカスタマイズツールが、Open-Shell-Menuです。クラシックスタートメニューからOpen-Shell-Menuへ名称が変わりました。Windows 11未対応ですが、Win11 21H2で動作します。

Windowsボタン＋Shiftで、下記Win11オリジナルスタートメニュー操作も可能です。

まとめ

TPM 2.0要件未達Windows 10 PCを、アプリケーションとデータ維持のままWindows 11 21H2へアップグレード後3ヶ月間運用し、各種Win10アプリ正常動作、Windows Updateも問題なく安定動作中です。

Windows 11の使い勝手は、GUIカスタマイズツールを使うと改善できます。

残る課題は、このPCが今秋予定Windows 11大型更新22H2可能か否かです。TPM要件未達のため、大型更新できない可能性は残っています。

OSコア設計とTPM 2.0の古さ

Win10とWin11は、同じOSコアです。Win11でのWin10アプリ動作は、本稿で示したように当然とも言えます。

一方、セキュリティ対策は、終わりが無く、常に新しい攻撃への防御更新が必要です。

COVID-19で急拡大したテレワークなどの新しいPC環境やメタバースに対し、2014年リリースTPM 2.0と、毎年大型更新したとはいえ2015年基本設計のWin10 と同じOSコアのWin11で、セキュリティ上十分かは疑問です。

プロセサ性能向上が著しい今、ハードウェア的なセキュリティは、2014年のTPM 2.0よりも、例えば、Plutonプロセサ、Intel vProやAMD Proなどの最新セキュリティ強化プロセサが登場しています。これらを活かすOSコア刷新版が、2024年Windows 12かもしれません。

Windows MeやVista経験も持つMicrosoftです。Win11アップグレート要件TPM 2.0は破棄、Win11はWin10からのGUI変更、Win12で抜本的OSコアセキュティ刷新へと段階的リリースを行えば、多くの既存Winユーザにも受け入れられるシナリオになると思います。

筆者推測ですが、通常のWindows Updateが問題なく動作することから、Win11の「OSコア深層を変更しない限りTPM非動作」だと思います。TPM動作更新は、手順が複雑な分、Update失敗リスクも高いからです。

今秋Win11 22H2でTPMのため大型更新できない場合は、TPM回避更新ツールなどを探し対応する予定です。

組込み開発基本のキ：暗号技術の仕組み

2022年7月15日2022年7月22日 WithHappy

デイビッド・ウォン著、⾼橋聡訳、⽇経クロステックの4記事：暗号技術の要旨をまとめました。

組込み開発と暗号技術

暗号技術は、数学が基礎です。暗号を使えば、秘密が守られることを科学的に立証する必要があるからです。しかし、暗号を使う立場の組込み開発者は、数式よりも、暗号の仕組み理解の方が重要です。

仕組み中心の暗号技術解説記事が、下記⽇経クロステック4記事です。組込み開発基本のキ、暗号仕組み理解に丁度良いと思います。各記事の要旨を抜粋します。

内容	発行日
秘密鍵の仕組み	2022年7月7日
ケルクホフスの原理	2022年7月8日
公開鍵暗号の仕組み	2022年7月12日
RSAデジタル署名	2022年7月13日

秘密鍵の仕組み

誰にでも読める平文を、暗号文へ変換する時に使う鍵が、秘密鍵。暗号文を元の平文へ復号する時も「同じ秘密鍵」を使う。

この送受双方の同じ秘密鍵利用が、対称秘密鍵暗号方式。送受参加者が多いと、鍵が漏洩するなど実用性低下の欠点もあるが、古代より使われてきた。

ケルクホフス原理

暗号/複合時に用いるアルゴリズムは、一般に公開しても良い。例えば、ウェブページ閲覧時のAES（Advanced Encryption Standard：⾼度暗号化標準）など。

公開アルゴリズムのセキュリティを保証する手段が、秘密鍵。

公開鍵暗号の仕組み

送受それぞれ「別の秘密鍵」と、「公開できる鍵」の2種類を使うと、送信側の秘密鍵が受信側で計算可能。これが、「非対称」の公開鍵暗号方式で、対称秘密鍵暗号方式の欠点を解消。

記事の公開図形と秘密鍵の計算例が解りやすい。

但し非対称公開鍵暗号方式は、第3者による公開鍵すり替えが可能なので、信頼性の問題は解決されない。

RSAデジタル署名

信頼性問題を解決するのが、デジタル署名。公開鍵を使って、送信者の署名が本物か偽物が検証可能。RSA以外にもデジタル署名方式あり。

このデジタル署名と非対称公開鍵暗号方式の両方を使うのが、現代の暗号化アルゴリズム全体像。

まとめ：仕組み理解でセキュリティ進化へ順応

インターネットに接続するIoT MCUには、通信セキュリティ対策は不可欠です。MCU開発側からすれば、当該セキュリティライブラリを、開発ソフトウェア/ハードウェアへ組込めば完了と思いがちです。

しかしながら、セキュリティ対策には、終わりがありません。新攻撃に対し、新たな暗号方式が登場します。MCU開発者が、複雑・高度化する暗号技術へ対応し、セキュリティ進化に追随するには、その仕組み理解は欠かせません。

本稿は、現代暗号化アルゴリズム、非対称公開鍵暗号方式とデジタル署名を説明しました。古代からの暗号技術は、インターネット出現により高度で複雑化しました。要旨の抜粋で判り難い箇所は、元記事も参照してください。

組込み開発基本のキ：暗号技術の仕組みを理解し、IoT MCUセキュリティ進化へ順応しましょう。

組込み開発基本のキ過去投稿

組込み開発基本のキ：組込み処理
組込み開発基本のキ：RTOS vs. ベアメタル

Azure RTOS習得(6)：低電力動作

2022年7月8日2022年7月15日 WithHappy

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード：Tx_LowPowerは、現在正常に動作しません。原因は、Stop1モード開始/Run復帰処理であることは判りました（下表の青部分）。

そこで、この低電力モード開始/復帰処理を、VCPメッセージ出力へ変更、低電力動作は保留し、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明します。

処理名	処理内容：低電力動作（LD2：評価ボード単体）	優先度	プリエンプション閾値
メインスレッド	1) セマフォ取得を永遠に待つ 2) 取得時LD1 500ms点滅を10回実施	10	10
S1プッシュ割込み	セマフォカウンタ=0時、セマフォ放出	–	–
Enter_LowPower_Mode	Stop1モード開始処理 ➡ VCPメッセージ出力	–	–
Exit_LowPower_Mode	Runモード復帰処理 ➡ VCPメッセージ出力	–	–

まとめ

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード：Tx_LowPowerは、Stop1モード開始/Run復帰に問題があり正常動作しません。

そこで、Stop1モード開始/復帰処理を保留にし、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明しました。

Azure RTOSプロジェクトで低電力動作させるには、STM32CubeMXのConfiguration ThreadXタブLow PowerのEnter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

Enable後、CubeMX生成のApp_ThreadX_LowPower_Enter/Exitの中身：Enter/Exit_LowPower_Modeへ、STM32G4低電力動作7モードの設定/Run復帰処理を記述すれば、Azure RTOS低電力動作ができます。

Tx_LowPower動作

サンプルコード：Tx_LowPower の正常な動作が下記です。

1) S1プッシュでLD1が10回点滅後、Enter_LowPower_Mode実行しStop1停止
2) S1プッシュ割込処理でExit_LowPower_Mode実行しRun復帰

つまり、S1プッシュ毎にLD1が10回点滅し、その後、低電力Stop1モードで待機します。Stop1状態表示はありません。

Stop1モード動作の代わりにVCPメッセージ出力が下記です。S1プッシュでLD1が10回点滅、点滅中はVCPメッセージ出力無しです。違いは、Stop1モード動作有無です。

「非」動作対策の保留（NOP）

STM32CubeMXは、プログラムフレームワーク生成に優れています。Enter/Exit_LowPower_Mode内容のみを変更すれば、Stop1以外のStop2モードやSleepモードへの低電力動作変更が簡単にできます。

ちなみに、筆者は、Sleepモードへも挑戦しましたが、正常動作はしませんでした。
※Enter/Exit_LowPower_Mode正常化をご教授頂ける方は、メールを頂けると助かります。

そこで、このEnter/Exit_LowPower_Mode処理は、一旦、保留（NOP）とします。

Tx_LowPowerが正常化した後、改めて保留にしたEnter/Exit_LowPower_Mode処理を入れ替えれば済むからです。現状は、NOPの代わりにVCPメッセージ出力処理を選びました。

この保留対策で、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れ理解の段階へ進めます。

Azure RTOS低電力動作プロジェクト作成方法

低電力動作有りと無しのプロジェクト作成差は、CubeMXのConfiguration ThreadXタブのLow Powerを開き、Enter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

App_ThreadX_LowPower_EnterとApp_ThreadX_LowPower_Exitは、CubeMXが生成する関数名です。この両関数の中身が、我々が開発するEnter/Exit_LowPower_Mode関数です。

つまり、Enter/Exit_LowPower_Mode中身を変えれば、その他の部分はそのままで、様々な低電力動作、例えばSleepやStop2へ対応できる作りになっています。フレームワーク生成に優れるSTM32CubeMXの利点です。

低電力動作の流れ

全てのスレッドが、待機状態になると、App_ThreadX_LowPower_Enterとその中身Enter_LowPower_Modeが実行されます。その結果、例えば、Sleepが低電力動作の場合には、MCUコアSleep＋周辺回路動作になります。

割込み発生でApp_TreadX_LowPowerとその中身Exit_LowPower_Modeが実行されRun復帰、最優先スレッドが実行されます。

この低電力動作に関して、公式Azure RTOSサイトに記述は有りません。低電力動作は、個別MCU依存のためでしょう。

STM32G4低電力動作モード

STM32G4の7つの主要低電力モード（出典：STM32G4 - PWR） — STM32G4の7つの主要低電力モード（出典：STM32G4 – PWR）

そこで、STM32G4の低電力動作をまとめました。元資料は、STM32G4 – PWRとLPTIMです。

STM32G4は、7種の低電力動作モードをサポートしています。Runウエイクアップ時間が11サイクルと短く、電力低減効果も高いSleepが筆者のお勧めです。

サンプルコードのEnter/Exit_LowPower_Mode処理が複雑なのは、更に効果の高いStop1だからです。

サンプルコード対応

・サンプルコードが無い時は、他の評価ボードから流用。
・サンプルコードに問題ありの時は、当該処理をNOP化、サンプルが示す内容取得。

サンプルコードは、開発TipsやKnow Howの宝庫です。しかし、残念ながら付属説明は、最低限です。説明するとキリが無いからです。そこで、弊社は、ベアメタル開発経験がある方を対象に、少し丁寧に説明を追加したつもりです。

サンプルコードと評価ボードさえあれば、実際にMCU動作が確認ができ、1から10まで記載の分厚いユーザマニュアルを読むよりも、手軽で効率的にMCU開発ができます。

サンプルコードにも、トラブルがあります。STM32G4評価ボード：NUCLEO-G474REを使ったAzure RTOS習得(2)～(5)用のサンプルコード対応をまとめたのが、本章最初の2行です。また、(2)～(5)で使ったサンプルコード名と内容が下表です。

サンプルコード名	サンプル内容（詳細リンク先参照）	備考
AzureRtos0	汎用Azure RTOSプロジェクト作成	NUCLEO-G474RE＋Arduinoプロトタイプシールド動作
AzureRtosEventFlag	スレッド間イベントフラグ同期	STM32G4サンプル流用動作
AzureRtosQueue	スレッド間キューメッセージ送受信	NUCLEO-G0B1RE流用動作
AzureRtosMutexSema	ミューティックス/バイナリセマフォ排他制御	STM32G0C1E-EV流用動作
AzureRtosLowPower	低電力動作プロジェクト作成（本稿）	STM32G4サンプル非動作

最近のMCU開発は、HAL（Hardware Abstruction Layer）API利用のため、サンプルコード流用が簡単です。個別MCUハードウェアに依存しないためです。

便利なサンプルコードを活用すれば、効率的なMCU開発ができます。更に、複数サンプルコードを流用し、プロトタイプの早期開発が容易な弊社MCUテンプレートを使えば、開発効率は上がります。

STM32G4評価ボードとArduinoプロトタイプシールド、LCDやADC動作のBaseboardを使ったST版Azure RTOSテンプレート（仮名）は、年内開発予定です。NXP版FreeRTOSテンプレートは、コチラで販売中です。

Azure RTOSやFreeRTOSは、IoT MCU開発に必要です。ベアメタルLチカ理解に相当するRTOS機能コンポーネントの習得、個人レベルで初めてはいかがでしょう。

日本開発者の視野

2022年7月1日2022年7月8日 WithHappy

昨年2021年のMCUサプライヤトップ5が、2022年6月21日のTech+記事に示されました。

NXP、STマイクロ、Infineon（旧Cypress）など弊社ブログもカバーする欧州3サプライヤが強く、米国マイクロチップ2位、日本ルネサス3位、これら上位5社で82.1%のMCUシェアを独占します。

記事によると、トップ5独占率は、増加中だそうです。

半導体は国家

今年2022年2月に始まったロジアのウクライナ侵略が、半導体ビジネスにどう影響するかのMassa POP Izumida氏の考察が、コチラの記事にあります。

記事を引用すると、“限られた企業のみが先端半導体製品や製造装置を作れ、半導体が戦略物資、国家の運命を左右する”、つまり「半導体は国家なり」です。納得できますね。

日本開発者は多様性

激変する半導体ビジネスで日本人開発者が生き残るには、得意の協調性だけでなく、多様性が必要だと思います。変化しつつある状況を把握し、「個人レベル」で少し先を見据えた行動指針を持つことです。

半導体は国家の著者：Izumida氏が、ARM、RISC-Vのプロセサ潮流を考察しています。MCUの少し先を考えるのにも役立つと思います。もちろん、1指針だけでなく、第2第3の予備指針を持つことも良いでしょう。※本ブログ2021年最後の傾向と対策：日本低下でも、Izumida氏の記事が読めます。

ポイントは、多様性実現へ開発視野を広くしておくことです。

MCU開発中は、視野狭窄に陥りがちです。対策は、開発中に狭まった視野を、意識して自ら時々広げる習慣を持つことです。激変半導体業界でMCU開発者自身のサスティナビリティ（持続可能性）検討は、納期を守ることと同じぐらい重要な事だと思います。

2022ウクライナ侵略影響

ロシアでは、Windows 10とWindows 11ダウンロードが遮断されました。

欧米のウクライナ侵略への報復は、テクノロジーへも及び始めました。Windows以外にも様々な欧米製ツールが、製品開発には必要です。例え半導体を製造できても、その半導体を使う新製品が開発できなければ、本末転倒です。

テクノロジー遮断は、開発者のやる気や元気を無くすのに効果的です。

今回の侵略影響を注視している中国や欧米各国自身も、テクノロジー鎖国化・保守化傾向へバイアスが掛かる気がします。また、より強い開発者育成にも積極的になるでしょう。逆に、1998年以来、約24年ぶりの円安影響を受ける日本企業は、開発者育成などの人的先行投資は、後回し傾向がより強まると思います。

侵略は、極東アジアG7参加国日本が、ビジネスや金融など多くの点で「西側欧米各国とは異質の国であること」を、際立たせる結果を生んでいます。

まとめ

日本国内は、災害級の酷暑です。熱中症対策エアコン、節電対策、コロナ対策マスク、これら3対応が上手くできるでしょうか？

政府やマスコミは、「優先度を付けて」と言います。“優先度”は、各個人で異なります。しかし、日本人は、本来個人主体で決めるべき優先度を、他人と比べ決める傾向が強い民族です。先ず、他人ありきです。日本国内では、これでも良いでしょう。

しかしながら日本開発者は、世界の中で生きていきます。

異質の日本、視野を世界へと広くし、自分で自分を育成していくしか生き残り方法はない状況だと分析します。いかがでしょうか？

日本開発者の英語対策（7月3日追記）

2022年6月29日、経済産業省所管の日本IT国家戦略を技術面・人材面から支援する独立行政法人：情報処理推進機構IPAが、セキュリティエンジニア向け英語教材2点を発行しました。MCU開発者にも役立つ資料ですので紹介します。

英語Reading

セキュリティエンジニアのためのEnglish Reading、これは、英文読解力や英文情報収集力を高めるTips集で、「楽に」「上手く」英文を読む方法が記載されています。

セキュティ英単語集、こちらは、ポイントとなる頻出330英単語の、和訳を示しています。

どちらも形容詞の “セキュリティ” が付いていますが、普通のエンジニア向け資料です（というか、セキュリティ関連のAcronyms：略語集ではありません）。

両資料に目を通しておくと、「あらゆる英文」から効率的、効果的に情報収集が出来そうです！

英語Listening

2022年6月29日、日本ニューズウィークに中学英語をしっかりモノにすれば必ず話せるが掲載されました。英会話の大前提、「大事なことは最初」、「説明や細かいことは後」、が判ります。

英会話の冒頭部分に集中してListeningすれば、おおよその内容が把握できそうです！

日本開発者の英語

英語Readingやウェビナー英語Listeningは、日本人開発者最初のハードルです。しかし、ハードルは倒したとしても、早く走れればOKです。上記の資料、記事は、ハードルの倒し方、上手く早く走るテクニックを解りやすく示しています。

日本人開発者の視野を世界へ広くするには、英語ReadingとListeningは必須です。

クラウド環境進歩で、AI自動翻訳なども期待できますが、ピュアな世界情報に触れるには、原文（英語）から直接内容を理解する方が、脳にとっても良いハズです。

残りの英語Writingは、PCやクラウドの自動翻訳をどんどん使っても良さそうです！

あとがき

最初のEnglish Reading資料にあるように、英語情報は、12億人のため、日本語情報の1.2憶人の10倍です。デマや誤報などの内容妥当性にも注意が必要とあります。納得できます。

人口減少の日本と英語圏との知的情報差は、今後さらに広がります😭。

第2言語、技術者スキルとしての英語、必要性は高まるばかりです。少し長めですが貴重な “日本語表記” の資料、是非目を通してください。

Azure RTOS習得(5)：Mutexとセマフォ

2022年6月24日2022年7月1日 WithHappy

Azure RTOSミューテックスとバイナリセマフォを使ったプロジェクトを作成し、スレッド間の排他制御方法を説明します。Azure RTOSでは、ミューテックスとバイナリセマフォが、同じ機能であることも判ります。

先にまとめ、次に詳細の順で説明します。

まとめ

Azure RTOS排他制御には、ミューテックスやリソースアクセス数1のバリナリセマフォが使われます。

STM32G4評価ボードにミューテックスとバリナリセマフォサンプルコードが無いため、STM32G0C1E-EVのTx_Thread_Syncサンプルコードを流用し、AzureRtosMutexSemaプロジェクトを作成しました。

作成したAzureRtosMutexSema プロジェクトを使い、Azure RTOS排他制御を、STM32G4評価ボードにArduinoプロトタイプシールドを追加し、ミューテックスは、バイナリセマフォと同じ動作結果をもたらすことを示しました。

リソースアクセス数2以上のカウントセマフォは、排他制御だけでなくイベント通知にも使えますが、優先度逆転など注意事項もあります。

本稿説明のAzure RTOS APIは、下記です。

・ミューテックス/セマフォ取得：tx_mutex / semaphore_getと、TX_NO_WAIT
・ミューテックス/セマフォ開放：tx_mutex / semaphore_put
・スレッド処理中断：tx_thread_sleepと、コンテキストスイッチ
・セマフォ優先度の逆転、ミューテックス優先度の継承と、TX_INHERIT / TX_NO_INHERIT

単純なAzure RTOS排他制御は、ミューテックス利用が良さそうです。

STM32G4 Azure RTOSサンプルコード探し

STM32G4（Cortex-M4/170MHz）評価ボード：NUCLEO-G474REへのAzure RTOSサンプルコードは、現在3個、この中にミューテックスやセマフォを使うサンプルコードはありません。

対策は、キューサンプルコードの前稿と同じです。CubeIDEのInformation Centerℹ️でImport STM32CubeMX exampleをクリックし、Example SelectorタブでThreadXにチェックを入れて流用できるサンプルコードを選定します。

選定したSTM32G0C1E-EVのTx_Thread_Suncコードを、STM32G4へ流用します。

STM32G4 Azure RTOSミューテックスとバイナリセマフォサンプルコードの探し方

Tx_Thread_Syncプロジェクト

ミューテックスやセマフォは、スレッド間の排他制御に用います。しかし、サンプルプロジェクト名は、“Sync”：同期となっていて違和感があります。

サンプルプロジェクトのreadme.htmlを読むとミューテックスとバリナリセマフォを使っていますので、ミューテックスとバイナリセマフォの排他制御利用例であることは、間違いありません。

サンプルの2つのスレッドは、それぞれLED点灯の独立した制御です。プロジェクトが示したいのは、LED点灯の直列制御、この直列化のため、ミューテックス、または、バイナリセマフォを同期手段として用いたからと筆者は、解釈しました。

つまり、手段のミューテックスやバイナリセマフォよりも、制御結果からプロジェクト名を付けたのだと思います。

面白いのは、このTx_Thread_Syncは、1プロジェクト内で、ミューテックスとバイナリセマフォをマクロで切替え、両者が同じ結果をもたらすことを示している点です（最初のVCP出力参照）。

しかしながら弊社は、Azure RTOSの排他制御手段でのプロジェクト名や日本語コメントを付けます。

AzureRtosMutexSemaプロジェクト

下表が、Tx_Thread_Syncの処理内容です。STM32G4評価ボード：NUCLEO-G474REとArduinoプロトタイプシールド用に、赤の工夫を加えました。

スレッド名

処理内容：スレッド1/2のLED点灯排他制御

（LD2：評価ボード単体＋
Arduinoプロトタイプシールド）

優先度

プリエンプション閾値

スレッド1

1) 排他オブジェクト取得確認
2) 成功時LED1 500ms/5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち

スレッド2

1) 排他オブジェクト取得確認
2) 成功時LED2 500ms /5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち

排他オブジェクトは、マクロでTX_MUTEX定義済みならミューテックス、未定義ならバイナリセマフォ利用に変更できます。

AzureRtosMutexSemaプロジェクト作成

AzureRtosMutexSemaプロジェクト作成方法も、AzureRtosEventFlagの時と同じです。

汎用テンプレートAzureRtos0をコピー＆別名AzureRtosMutexSemaでペーストし、AzureRtosMutexSemaプロジェクトを作成します。ペースト先のAzureRtos0.icoは、AzureRtosMutexSema.icoへRenameします。

これで、AzureRtosMutexSemaプロジェクトのひな型ができました。

STM32G0C1E-EV のTx_Thread_Syncコードapp_threadx.c/hを流用し、AzureRtosQueueプロジェクトの、app_threadx.cとapp_threadx.h へ追記します。追記コードの一部抜粋が下記です。

app_threadx.c追記例

app_threadx.h追記例

Azure RTOSミューテックスとバイナリセマフォ

サンプルコードは、ミューテックスがデフォルト利用ですので、Azure RTOSミューテックスで説明します。

スレッド1/2は、優先度、プリエンプション閾値ともに同じです。

しかし、スレッド1を先に生成し即実行（TX_AUTO_START）しますので、常にスレッド1が排他オブジェクト：ミューテックスを先に取得（tx_mutex_get）し、LED1トグル点灯を5秒間続けます。5秒経過後、ミューテックスを開放(tx_mutex_put)し、1ティックの10msスリープ（tx_thread_sleep）します。この処理を繰返します。

スレッド2は、開始後オブジェクト：ミューテックス取得を狙いますが、スレッド1取得済みのため待ち無し（TX_NO_WAIT）で取得狙いを繰返します。スレッド1のミューテックス解放で、ミューテックスを取得し、LED2トグル点灯を5秒間続けます。5秒経過後、ミューテックスを開放し、10msスリープするのは、スレッド1と同じです。

ミューテックスオブジェクトにより、スレッド1/2が排他動作します。

ここで、ミューテックス解放後の1ティックスリープは重要です。このスリープが、スレッド1/2のコンテキストスイッチを行います。試しにスリープをコメントアウトすると、排他制御が働きません。

app_thread.x.h L60のマクロUSE_TX_MUTEXをコメントアウトすると、バイナリセマフォ（tx_semaphore_get/tx_semaphore_put）を使ってミューテックスと同じ動作結果が確認できます。

Azure RTOSサイトのカウントセマフォを読むと、カウントセマフォは、排他制御だけでなくイベント通知にも使用可能です（前稿キューイベントチェーンがその利用例）。また、デットロックやスレッド優先度の落とし穴、“優先度の逆転”（Priority Inversion）などの利用時注意事項もあります。

排他制御だけなら、ミューテックス利用がシンプルで良さそうです。但し、“優先度の逆転”対策の“優先度の継承”（Priority Inheritance）オプション:TX_INHERITが必要です。サンプルコードは、TX_NO_INHERITです。

※優先度の逆転、優先度の継承を試すには、スレッド1/2以外の第3のスレッドが必要です。第3スレッドは、スレッド1/2の中間の優先度と、1/2排他制御とは無関係なことも必要です。この逆転、継承もRTOSらしい機能ですが、サンプルコード実装は無く、各自でお試しください、ということでしょう。

ミューテックス/バイナリセマフォ排他制御の結果、ArduinoプロトタイプシールドのLED1とLED2が、交互に点滅を繰返すことが確認できます。

オリジナルプロジェクト名：“Sync”が示すようにLED1/2は同期して交互点滅している、と記述することも可能です。

RTOS文章直列記述→並列動作マッピング

本サンプルコードは、わずか2個スレッドです。それでも、RTOS処理を文章で記述する難しさを感じます。文章は、動作を「直列」で記述することが得意だからです。

RTOS処理は、複数のスレッドが「並列」に動作します。勿論、シングルコアで時分割動作なので、実際に動作しているのは、RTOSを含め1個です。ですが、これを判り易く文章化するのは、結構難しいことです。

例えば、本稿スレッド1/2のtx_thread_sleepです。開発者同士なら、ソースコードを見せれば、それで事足ります。しかし、そもそもRTOS理解レベルが不明の顧客へ、スリープの目的や意味を説明しても、判ってもらえるでしょうか？

RTOS開発は、開発アプリの顧客向け資料作成でも苦労しそうです😭。

RTOS習得には、公式サイト文章記述の各種RTOS機能を、サンプルコードへ変換後、さらに、個々の開発者が、サンプルコードと評価ボードを使って「納得するまで色々変えてみること」が必要だと思います。

この試行で、直列記述の文章で表現されたRTOS動作が、開発者の中でRTOS並列動作へマッピングされます。RTOS習得・開発には、並列動作マッピングの過程が最重要だと思います。

Azure RTOS習得(4)：メッセージキュー

2022年6月17日2022年6月24日 WithHappy

Azure RTOSのキューを使ったプロジェクトを作成し、スレッド間のメッセージ送受信方法を説明します。メッセージキューは、比較的判り易い機能です。先にまとめ、次に詳細の順に説明します。

まとめ

Azure RTOSのスレッド間メッセージ送受信には、キューが用いられます。

STM32G4評価ボードのAzure RTOSメッセージキューサンプルコードが無いため、NUCLEO-G0B1REのTx_Thread_MsgQueueサンプルコードを流用し、AzureRtosQueueプロジェクトを作成しました。

作成したAzureRtosQueueプロジェクトを使い、基本的なAzure RTOSメッセージキュー機能を、STM32G4評価ボードにArduinoプロトタイプシールドを追加し説明、動作確認しました。

本稿説明のAzure RTOS APIは、下記です。

・メッセージキュー作成：tx_queue_create
・メッセージキュー送信：tx_queue_send
・メッセージキュー受信：tx_queue_receiveと、TX_NO_WAIT / TX_WAIT_FOREVER
・メッセージキュー送信時通知：tx_queue_send_notifyと、キューイベントチェーン

複数のQメッセージを受信スレッドで処理し、かつ、メッセージ無しの時、受信処理を中断する場合は、Azure RTOSキューイベントチェーン（Queue Event chaining）機能が効果的です。