MCUテンプレート海外販売開始

MCUテンプレート海外販売に向けWordPressサイト多言語化を行ってきました。本日より下記MCUテンプレートの海外販売を始めます。

RA BeaeMetal、STM32G0x、STM32F0/F1、3種MCUテンプレート販売開始

既存日本語テンプレート10種のうち、第一弾は、ルネサス)RA6/4/2ベアメタルテンプレート、STマイクロ)STM32G0xテンプレートSTM32F0/F1テンプレート3種のテンプレート資料を英語化し販売します。

多言語対応ページの使い方

多言語対応ページの使い方
多言語対応ページの使い方

ブログトップを示すHomeから③テンプレート購入手順は、多言語対応済みページです。従って、サイト右上のプルダウンメニューから、お好きな言語を選べば、日本語表示から選択言語へ変換されます。

①Template list掲載の3種テンプレート説明資料の冒頭3ページは、無料ダウンロード可能です。

テンプレート利点やTipsなどは、②Template Benefits & Tipsに、Template購入方法は、③Template purchase procedureをご覧ください。

お好きな言語でテンプレート概要やメリットなどをご覧になり、MCUテンプレートのご購入を検討頂ければ幸いです。

日本語テンプレート販売は従来通り

日本語MCUテンプレート10種は、従来と同じMCUテンプレートサイトから販売中です。

第一弾の多言語MCUテンプレート3種以外をご要望の方は、日本語MCUテンプレートサイトからもご購入が可能です。

但し、テンプレート説明資料は、全て日本語表記です。ご購入後、Google翻訳などを使ってご自分で翻訳してください。なお、テンプレートソースコード内の冗長な日本語コメントは、コンパイル時に全て削除されますので、制御には無関係です。

Google翻訳の感想

Google翻訳は、便利なツールです。しかし、日本語からの英語翻訳時、英単語間に余分なスペースが挿入されます。例えば、「これはペンです。」をGoogle翻訳すると、「This__is__a__pen.」となります。

この英単語間の2スペースは、Wordなどの置換ツールを使って通常の1スペースへ一括変換できます。しかし、余分なスペースがなぜ挿入されるのかが不明です。理由がお解りの方は、弊社に教えてください。

Afterword:テンプレート役割

テンプレート付属資料の英語化は、手間が掛かりました。ただ、第一弾英語化を期に、3種説明内容を横断的に見直す良い機会にもなりました。

その結果、初心者の効率的MCU習得にテンプレートが適す、テンプレート応用例SimpleテンプレートとBaseboardテンプレートは、プロトタイプ着手時のMCUプロジェクトに適す、これらを再確認しました。

MCU習得やプロトタイプ開発に、弊社テンプレートは役立ちます。是非、ご活用ください。



STM32 Developer Zone

STマイクロが、STM32 MCU/MPU開発者向け総合ポータルサイトSTM32 Developer Zoneを開設しました(2023年6月)。ベテラン/初心者ともに開発に役立つページリンクが多数集約されています。

ポータルサイトのリンク構成を解かり易くするため、フォルダ形式の一覧表示にしました。

STM32 MCU Developer Zone

STM32 MCU Zone (Home) MCUプロジェクトを開始
1-MCU製品ポートフォリオ
2-開発ボード&ハードウェアツール
3-ソフトウェア開発ツール
4-組込みソフトウェア
5-ソリューション
6-開発リソース
アプリケーション別ソリューション AIソリューション
ワイアレス&コネクティビティ
セキュリティフレームワーク
コミュニティ&サポート STコミュニティ
ナレッジ共有
パートナ設計サービス
オンラインサポート(要ログイン)

下図マイクロプロセッサ:MPU(STM32MP1/Cortex-A7+Cortex-M4)以外の全マイコン:MCU情報が、このSTM32 MCU Developer Zoneに集約されています。

STM32 MCUとMPU境界(出展:STM32C0シリーズセミナ資料に加筆)
STM32 MCUとMPU境界(出展:STM32C0シリーズセミナ資料に加筆)

MPUに比べ、AIソリューション等のアプリケーション別ソリューション情報も豊富です(関連投稿:AI MCU)。

また、初心者向きMCUプロジェクト開始リンクがあり、Step1で評価ボード選択、Step2でSTM32CubeIDEを使ったMCU開発手順の説明もあります。

STM32 MPU Developer Zone

STM32 MPU Zone (Home) MPU組込みソフトウェアツールの詳細
1-MPU製品ポートフォリオ
2-開発ボード&ハードウェアツール
3-組込みソフトウェア
4-ソフトウェア開発ツール
5-ソリューション
6-開発リソース
コミュニティ&サポート STコミュニティ
ナレッジ共有
パートナ設計サービス
オンラインサポート(要ログイン)

高度なHMIや複雑処理向けのCortex-A7搭載MPUは、現在STM32MP1シリーズだけです。従って、STM32 MPU Developer Zoneサイト構成は、MCU比シンプルです。

2023年第4四半期にこのSTM32MP1に加え、Cortex-A35、Cortex-M33搭載でセキュアIndustry 4.0、およびエッジ・コンピューティング・アプリケーション向けSTM32MP2シリーズが追加予定です。

ポータルサイトHTMLとリンク構成

ウェブサイトの図や文字、ハイパーリンクの表示には、HTMLが使われます。HTMLで記述したリンク集約ポータルサイトは、肝心のリンク構成が読者に解り難い欠点があります。モニタで一度に表示できる領域が限られるため、リンク構成は、読者がサイト全体を把握した後になるからです。

そこで、本稿は、誰でも見慣れたフォルダ形式で、STM32 MCU/MPU Developer Zoneのリンク構成を示しました。

ポータルサイトは随時更新されますが、リンク構成を把握していれば、常に所望最新リンクへのアクセスも容易です。

注)本稿は、2023年6月9日現在のリンク先を示しています。最新リンクへは、MCU/MPU Developer Zoneホームからアクセスしてください。

Afterword:European Chips Act(欧州半導体法)

欧州半導体法は、EU内の製造活動強化、欧州設計エコシステム刺激、バリューチェーン全体スケールアップとイノベーションを支援するもので、これによりEUは、世界市場シェアを2030年に20%倍増させるという目標を目指しています。

STマイクロとGlobalFoundriesは、2023年6月5日、フランス・クロルで両社共同運用の300mmウエハー工場新設計画の合意を締結と発表しました。総投資額は75億ユーロの見込みで、フランス政府が最大29億ユーロを援助します。

生産だけでなく、より開発し易いMCU/MPUへ向けたオランダ)STマイクロの活用、今後も注目が必要です。



AI MCU

AI機能搭載の最新MCUを一覧表にまとめました。人物検出や機器異常検出などのAIアルゴリズム処理には、従来Cortex-M7クラスの高性能MPU(Micro Processor Unit)が必要でした。MPU比、低コストで低消費電力なAI MCUによるエッジAIメリットを示します。

Summary:AI MCUまとめ

AI機能搭載の最新MCU一覧
ベンダ AI MCU、コア AI特徴、AIアプリケーション AI開発ツール
STマイクロ STM32シリーズ
Cortex-M0+他コア対応
コア対応機械学習ライブラリ生成
ポンプ異常検出
NanoEdge AI Studio(専用)
NXP MCX Nシリーズ
Cortex-M33 x2(+NPU)
AI専用NPU処理
顔検出
MCUXpresso IDE(汎用)
ルネサス RAファミリ
Cortex-M85(+Helium)
汎用ベクタ演算Helium処理
人物検知/モータ故障検出
Reality AI(専用)

マイコンでAI」、STマイクロNXPルネサスが競演、2023年5月12日、MONOist記事をまとめたのが上表です。

記事によると、MCU大手3ベンダが、第7回AI・人工知能EXPO(春)2023年5月10~12日、東京ビックサイト会場で、表掲載AI MCUを使って、エッジAI実働デモ展示を行っています。

ChatGPTなどAI利用が一般化し始めました。組込み分野のMCUへもAI搭載の高機能化が始まります。

AI MCUアプローチ

STマイクロは、ソフトウェアでのAI処理、NXPは、専用ハードウェアNPU(Neural Processing Unit)でのAI処理、ルネサスは、汎用ベクタ演算ハードウェアHeliumによるAI処理と、3社3様のAI MCUアプローチです。

また、AI処理開発に、ソフトウェアアプローチのSTマイクロは、STM32コアに応じた専用機械学習ライブラリ生成ツール:NanoEdge AI Studioを使用、同じハードウェアアプローチですが、NXPは、汎用MCUXpresso IDEを使用、ルネサスは、専用Reality AIツール使用、などAI開発ツールも異なります。

NanoEdge AI Studioは、MCU開発者にAI専門知識が無くてもMCUコア性能に合わせたAI実装ができるそうです。

エッジAI MCUアプリケーションとメリット

Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)
Cortex-M85搭載RAファミリによるAI人物検出デモ(出展:ルネサス)

各社のAI実働デモから、上図のような人物・顔検出と機器異常検出が、エッジAI MCUのターゲットアプリケーションのようです(関連投稿:RAファミリ最新情報)。

これらAI処理にMPUは使わず、小パッケージ、低コストの本稿AI MCUを使い、家電や機器内の既存MCUを置換えることで「装置構成はそのままに様々なAI機能を追加実装できる」これが、AI MCUのメリット、更に革命と言われる理由です。

Afterword:新たなMCU開発方法

実装AI機能により、求められるAI MCUコア性能もCortex-M0+からCortex-M85など様々です。それでも、MPUやGPU(Graphics Processing Unit)利用よりは、低コストエッジAIが実現できそうです。

従来MCUの置換えメリットだけでなく、AI MCUを使った新しい装置開発も面白いと思います。

各社AI MCUは、セキュリティ対応も強化されています。AI、IoTセキュリティ、RTOS…などなど、従来のCortex-M系ベアメタルMCU開発に加え、多くの新知識と追加開発がAI MCUに必要です。正直、食傷気味です😣。

従って、専門知識が無くてもAI実装できるツールなどは、大歓迎です。新しいMCUには、各種ツール活用の新しい開発方法を、拘りなく使える柔軟性も必要です(関連投稿:新しいMCUハードソフトの学び方)。

ツールを使っているうちに、専門知識や関連知識は、自ずと身についてくるハズです。



8/16ビットMCU置換えを狙う32ビットMCU

半導体不足が続いています。対策として、8/16ビットMCU置換えを狙った、汎用低コストの新しい32ビットMCUを2種紹介します。

STマイクロ:STM32C0シリーズ

STマイクロ、2023年1月12日、低価格なSTM32C0シリーズ(Cortex-M0+:48MHz、Flash:16K/32K、RAM:6K/12K)を発表。

STM32C0とSTM32G0の位置づけ(出展:STMサイト)
STM32C0とSTM32G0の位置づけ(出展:STMサイト)

ルネサス:RA2グループ

ルネサス、2021年10月13日、省スペース低消費電力向けにRA2E2グループ(Cortex-M23:48MHz、Flash:64K、RAM:8K)を、RA2シリーズへ追加。

RA2E2評価ボードのMCU基板アートワーク
RA2E2評価ボードのMCU基板アートワーク

8/16ビットMCU置換え最新32ビットMCU特徴

  • 少数ピン/小型パッケージ
  • 小容量Flash/RAM
  • 低消費電力
  • 低価格(8/16ビットMCUと同等)

8/16ビットMCU置換えを狙う32ビットMCU特徴です。置換え32ビットMCUと言えば、古くからNXP:LPC800シリーズが有名なので、本稿は省略しました。

動作周波数が高くても、Sleepなどの超低消費電力動作時間も長く、実働消費電力は驚くほど小さくなります。また、古い8/16ビットMCUよりも入手性に優れます。

置換え32ビットMCUメリット

旧MCU開発は、周辺回路ドライバなども自主開発することが多く、ドライバとアプリケーションの境界も開発者毎にバラバラでした。最新MCU開発は、ドライバはベンダHAL API生成ツールが自動生成します。

その結果、開発者は、アプリケーション開発に集中でき、ソフトウェア開発費も安くなります。

※HAL API:MCUハードウェアに依存しない(Hardware Abstraction Layer)API。シリーズ/グループが異なっても開発アプリケーション流用が容易。

既に実装済みの旧8/16ビットMCU機能を最新32ビットMCUへ置換える時も、この最新MCU開発環境が使えるため、効率的なソフトウェア開発が可能です。更に、置換えだけでなく、新機能追加、IoTやセキュリティなど高機能アップグレートも容易です。

最新汎用32ビットMCUは、半導体不足にも有効です。紹介したSTマイクロ、ルネサスいずれも、上位MCUへの置換えが可能な基板アートワークができるピン配置を採用しています。

つまり、IoT時代に合わせた開発スキルやソフトウェア発展性があり、基板ハードウェア持続性も期待できるなど、8/16ビットMCU置換え汎用32ビットMCU採用には、多くのメリットがあります。

STM32G0テンプレート、RAベアメタルテンプレート

STM32C0シリーズ開発には、STM32G0Xテンプレート、RA2グループ開発には、RAベアメタルテンプレートがお役に立てます。



64ビットMCU得失

RZファミリ位置付け(出展:ルネサスサイト)
RZファミリ位置付け(出展:ルネサスサイト)

今年春の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より)。

Cortex-M代替として急浮上のRISC-V
Cortex-M代替として急浮上のRISC-V

ルネサスなどの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も販売中です。

関連投稿:Cortex-MとRISC-V1GHz 64ビットMPUのRZ/A3UL

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プロセス(出典:ルネサスサイト)
アクティブ消費電力とスリープ消費電力両方を減らせる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動向を注意深く観察する必要があるというのが結論です。



クリエイタ的エンジニア

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

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

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

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

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

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

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

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

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

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

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

自分事、主体的に考える

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

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

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

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

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

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

クリエイタ的エンジニアは1日してならず
クリエイタ的エンジニアは1日してならず

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

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

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

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

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



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

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モード動作有無です。

Stop1モード動作の代わりのVCP出力
Stop1モード動作の代わりのVCP出力

「非」動作対策の保留(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低電力動作プロジェクト作成方法

Azure RTOS Low Powerプロジェクト作成
Azure RTOS Low Powerプロジェクト作成

低電力動作有りと無しのプロジェクト作成差は、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 – PWRLPTIMです。

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テンプレートは、コチラで販売中です。

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

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

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

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ミューテックスとバイナリセマフォサンプルコードの探し方
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) 失敗時排他オブジェクト取得待ち
10 10
スレッド2 1) 排他オブジェクト取得確認
2) 成功時LED2 500ms /5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち
10 10

排他オブジェクトは、マクロで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.c追記ソースコード抜粋
app_threadx.c追記ソースコード抜粋

app_threadx.h追記例

app_threadx.h追記ソースコード抜粋
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):メッセージキュー

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

まとめ

Azure RTOSメッセージキュー送受信
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)機能が効果的です。

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

現在、STM32G4(Cortex-M4/170MHz)評価ボード:NUCLEO-G474REへのAzure RTOSサンプルコードは、3個、この中にキューサンプルコードはありません。

そこで、逆にExample Selectorから流用できるキューサンプルコード:Tx_Thread_MsgQueueを探します。選定条件は、利用中のCubeIDE版数(v1.9.0)、評価ボード(Nucle-64)に近いものが良いでしょう。

CubeIDEのInformation Centerℹ️でImport STM32CubeMX exampleをクリックし、Example SelectorタブでThreadXにチェックを入れて選定します。

選定したNUCLEO-G0B1REのTx_Thread_MsgQueueコードを、STM32G4へ流用します。

STM32G4 Azure RTOSキューサンプルコードの探し方
STM32G4 Azure RTOSキューサンプルコードの探し方

AzureRtosQueueプロジェクト

下表が、Tx_Thread_MsgQueueの処理内容です。STM32G4評価ボード:NUCLEO-G474REとArduinoプロトタイプシールド用に、赤の工夫を加えました。評価ボード+Arduinoプロトタイプシールドの目的は、Azure RTOS習得(2)を参照してください。

スレッド名 処理内容:Q1/Q2によるメッセージ送受信

(LD2:評価ボード単体+
Arduinoプロトタイプシールド

優先度 プリエンプション閾値
送信スレッド1 500ms毎にSET_GRN_LEDメッセージをQ1へ送信
Q送信失敗時、LD2点灯+停止
5 5
送信スレッド2 1s毎にRESET_GRN_LEDメッセージをQ2へ送信
Q送信失敗時、LD2点灯+停止
5 5
受信スレッド Q1とQ2、両方からメッセージ受信
Q1受信成功時、LED1トグル点灯+VCP出力
Q2受信成功時、LED2トグル点灯+VCP出力
受信失敗時、LD2点灯+停止
10 10

AzureRtosQueueプロジェクト作成

AzureRtosQueueプロジェクト作成方法は、前稿のAzureRtosEventFlagと同じです。汎用テンプレートAzureRtos0をコピー&別名AzureRtosQueueでペーストし、AzureRtosQueueプロジェクトを作成します。ペースト先のAzureRtos0.icoも、AzureRtosQueue.icoへRenameします。

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

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

app_threadx.c追記例

app_threadx.c追記ソースコード抜粋(橙色は注意箇所)
app_threadx.c追記ソースコード抜粋(橙色は注意箇所)

app_threadx.h追記例

app_threadx.h追記ソースコード抜粋
app_threadx.h追記ソースコード抜粋

Azure RTOSメッセージキュー

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

送信スレッド1/2のtx_queue_sendで、Q1/2へメッセージ送信、受信スレッドのtx_queue_receiveで、Q1/2からメッセージ受信、メッセージ内容を確認し、受信成功ならLED1/2をトグル点灯させます。

送信スレッド1/2は、同じ優先度とプリエンプション閾値です。送信間隔が同じ500msだと煩雑ですので、スレッド2は、1秒送信間隔へ変更しました。

Azure RTOSメッセージキューの送受信は、比較的判り易い機能です。メッセージキューを作り(tx_queue_create)、そのQへの送受、STのKnowledge Baseに判り易いアニメもあります。

しかしながら、受信スレッドが、複数Qからのメッセージ処理を行い、かつ、メッセージ無しの時に無限待ち(TX_WAIT_FOREVER)の場合には、キュー イベント チェーン(Event chaining)が効果的です。

本サンプルは、複数Qからの受信処理を行いますが、待ち無し(TX_NO_WAIT)の例です。

AzureRtosQueueプロジェクトVCP出力
AzureRtosQueueプロジェクトVCP出力

キュー イベント チェーン

Azure RTOS ThreadX 機能第 3 章の中程に、“キュー イベント チェーン”の説明があります。簡単に抜粋すると、

本受信スレッドのようにQ1とQ2の両方からメッセージを受信し、メッセージ無しの時、受信中断もある場合は、Q1/Q2に通知関数を登録(tx_queue_send_notify)し、カウントセマフォを使うキュー イベント チェーンが有効。キュー イベント チェーンなしでの実現は“非常に困難”。

流用サンプルコードのreadme.htmlにもキーワード:Event chainingがあります。しかし、このキュー イベント チェーンは未実装です。

カウントセマフォなしでは非常に困難でRTOSらしい機能ですが、各自でお試しください、ということでしょう😢。本ブログもこの方針に従いました。

Azure RTOS習得(3):新規Azure RTOSプロジェクト

Azure RTOS習得3回目は、新規STM32CubeIDE Azure RTOSプロジェクト作成方法と、STM32CubeMX生成ソースコードの、どこに、何を、追加すれば良いかを説明します。

新規「汎用」Azure RTOSプロジェクト

前稿で、STM32G4(Cortex-M4/170MHz)評価ボード:NUCLEO-G474REへArduinoプロトタイプシールドを追加し、最も基本的なAzure RTOS ThreadXサンプルコードのTx_Thread_Creation動作を解説しました。

このTx_Thread_CreationサンプルコードのTx_Thread_Creation .icoから、新規の「汎用」AzureRtos0プロジェクトを作成します。

汎用の意味は、このAzureRtos0プロジェクトへセマフォやキューなどのRTOS機能を追加し、Azure RTOS習得に使うからです。

残念ながら現時点では、STM32G4用Azure RTOSセマフォやキューのサンプルコードは無いため、これらRTOS単独機能を持つプロジェクトを自作する訳です。

AzureRtos0プロジェクトから自作予定のAzure RTOS機能プロジェクトが以下です。

・AzureRtosEventFlagプロジェクト(本稿)
・AzureRtosQueueプロジェクト
・AzureRtosMutexプロジェクト
・AzureRtosSemaphoreプロジェクト

Tx_Thread_Creation .ico

STM32CubeIDE(以下CubeIDE)の新規STM32プロジェクトは、様々な作成方法があります。

ただ、Azure RTOSプロジェクトは、STM32CubeMX(以下CubeMX)の設定に、ベアメタル開発と異なる注意が必要です。このような時は、既に設定済みのCubeMX Configuration File (.ico)を流用すると、注意事項を含んだ新規プロジェクト作成が簡単にできます。

Azure RTOSプロジェクトのCubeMX設定の注意事項は、別途投稿します。本稿は新規Azure RTOSプロジェクト作成に焦点を置き説明します。

新規汎用AzureRtos0プロジェクト作成

Tx_Thread_Creation .icoを流用したAzureRtos0プロジェクト作成手順が下記です。

① CubeIDEのInformation Centerℹ️でStart new project from STM32CubeMX file(.ioc)クリック
② STM32CubeMX ico fileにTx_Thread_CreationのTx_Thread_Creation .ico選択、Project NameにAzureRtos0を入力しFinishクリック

Tx_Thread_Creation.ico流用の新規プロジェクト作成
Tx_Thread_Creation.ico流用の新規プロジェクト作成

③ PA5ユーザラベルをLD2へ変更、PC4とPC5をGPIO Output、ユーザラベルLED1、LED2に設定、PC7をGPIO Input、ユーザラベルS1に設定(LD2は評価ボード、LED1/2、S1は追加Arduinoプロトタイプシールドのポート)

ユーザラベル変更とArduinoプロトタイプシールドポートLED1/2とS1追加
ユーザラベル変更とArduinoプロトタイプシールドポートLED1/2とS1追加

④ Project>Generate Codeをクリックし、初期設定コードとAzure RTOSプロジェクトファイル生成
⑤ main.c L92へ、下記タイトルVCPメッセージ出力HALコード追記

VCPメッセージ出力HALコード追記
VCPメッセージ出力HALコード追記

⑥ ビルドし、評価ボードへダウンロード
⑦ Tera Termなどのターミナルソフトで追記VCPメッセージを確認し、新規汎用AzureRtos0プロジェクト動作確認

新規汎用AzureRtos0プロジェクト動作確認
新規汎用AzureRtos0プロジェクト動作確認

Azure RTOSイベントフラグ機能追加

AzureRtos0プロジェクトへ、イベントフラグを使ってメインスレッドとスレッド1/2間同期を行う機能を追加し、AzureRtosEventFlagプロジェクトを作成します。

このプロジェクトは、Azure RTOS ThreadXサンプルコードと同じ処理内容です。従って、Azure RTOS ThreadXサンプルコードが、AzureRtos0へ追記するコードの代用に使えます。

始めに、AzureRtos0プロジェクトファイルの、どこに、何を追加するかを説明し、次章で実例を示します。

追記ファイル 追加内容
Core>Src>
app_threadx.c
1) UINT App_ThreadX_Init()へ、イベントフラグ生成関数、追加スレッド生成関数
2) 追加スレッドのエントリ関数(メイン関数)
Core>Inc>
app_threadx.h
追加スレッド優先度、プリエンプション閾値などのマクロ

RTOSであっても、ベアメタル開発で機能追加する時と同じ追記ファイルと追加内容です。

違いは、App_ThreadX_Init()の中でイベントフラグや追加スレッドを生成すると、直にRTOS動作を開始(TX_AUTO_START)する点です。従って、ベアメタル関連main.c/hの変更点は、VCP出力メッセージの変更程度です。

つまり、RTOS関連とベアメタル関連、それぞれのメインエントリー(メイン関数)があり、RTOS動作追加だけなら、main.c/hは不変でも構いません。

筆者は、cファイルとhファイルを一緒に記述したい派です。しかし、CubeMXがこれらを分離してRTOS関連ファイルを生成しますので、このファイル分離に従い追記します。

スレッド優先度やプリエンプション閾値を変えれば、Azure RTOS動作が簡単に変わりますので、分離の方が好ましいのかもしれません(動作変更例は、Azure RTOS習得(2)の4章:メインスレッド参照)。

AzureRtosEventFlagプロジェクト作成

AzureRtos0プロジェクトはテンプレートとして様々なプロジェクトで利用しますので、CubeIDEでAzureRtos0プロジェクトをコピーし、別名のAzureRtosEventFlagプロジェクトとしてペーストして使います。ペースト先のAzureRtos0.icoも、AzureRtosEventFlag.icoへRenameします。

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

AzureRtosEventFlagプロジェクトの追記部分抜粋が下記です。追記コードは、Azure RTOS ThreadXサンプルコードです。

CubeMX生成コメントの、/* USER CODE BEGIN … */、/* USER CODE END …*/が、追記ガイドに役立ちます。

※手抜きご希望の方は、Azure RTOS ThreadXサンプルのapp_threadx.cとapp_threadx.hを、そのままAzureRtosEventFlagのapp_threadx.cとapp_threadx.hへ上書きしてもOKです😅。但し、LED1/2への出力は変更してください。

AzureRtosEventFlagプロジェクトへ追記後、ビルドし評価ボードへダウンロードします。

App_threadx.c追加例

app_threadx.c追記ソースコード抜粋
app_threadx.c追記ソースコード抜粋(下線は要変更)

app_threadx.h追加例

app_threadx.h追記ソースコード抜粋
app_threadx.h追記ソースコード抜粋

AzureRtosEventFlagプロジェクト動作確認

AzureRtosEventFlagプロジェクトは、スレッド1がArduinoプロトタイプシールドのLED1制御、スレッド2がLED2制御を行う以外は、Azure RTOS ThreadXサンプルコードと同じ動作です。

従って、同じ動作を確認しAzureRtosEventFlagプロジェクト作成の成功です。

作成したAzureRtosEventFlagプロジェクトを使って、イベントフラグの制御、スレッド1/2優先度やプリエンプション閾値変更によるArduino LED 1/2動作変化を確認し、イベントフラグ機能を習得してください。

本稿で作成したAzure RTOSイベントフラグの機能は、前稿で説明済みですので、割愛します。

まとめ

Azure RTOS ThreadXサンプルコードのTx_Thread_Creation.icoを流用した、新規汎用AzureRtos0プロジェクト作成方法を示しました。

汎用AzureRtos0プロジェクトに、RTOS機能別プロジェクト例として、イベントフラグ機能を追加したAzureRtosEventFlagプロジェクトを作成し、Azure RTOS ThreadXサンプルコードと同じ動作を、評価ボードにArduinoプロトタイプシールド追加し確認しました。

機能追加したAzureRtosEventFlagプロジェクトにより、汎用AzureRtos0プロジェクトソースコードのどこに、何を追記するかを示しました。

今後、AzureRtos0プロジェクトへセマフォなどの機能を追加し、Azure RTOS機能別習得をすすめます。

付記:日本語文字化け対策

デフォルトのSTM32CubeIDEとSTM32CubeMXを使ってプロジェクト開発時、日本語文字化けが発生します。過去投稿済みの対策を付記します。

STM32CubeMXのプロジェクトGenetate Code実行「前」に、
STM32CubeIDEの設定変更
① Windows>Windows>Prefernces>Colors & font>文字セットを「日本語」へ設定
② Project>Properties>Text file encordhingをOthers:「Shift-JIS」へ設定

以上で、Genetate Codeしソースコードが上書きされても、日本語文字化けは無くなります。