PSoC CreatorがModusToolboxへ

米)Cypress(サイプレス)は、2020年4月、独)Infineon(インフィニオン)に買収され子会社になりました。買収の影響かは不明ですが、お気に入りCypress IDEのPSoC Creatorが、ModusToolboxへ移行しつつあります。ModusToolbox v2.3.0.4276(以下ModusToolbox)の特徴、PSoC Creatorからどう変わったのかを示します。

About Eclipse IDE for ModusToolbox
About Eclipse IDE for ModusToolbox

Windows/Mac/LinuxマルチOS、GitHub

PSoC Creator(以下Creator)は、Windowsのみで動作するCypress独自IDEです。ModusToolboxは、Eclipse IDEをベースとし、Windows/Mac/LinuxマルチOS対応となりました。また、最新サンプルコードやライブラリは、GitHub経由でオンライン提供へと変わりました。

ModusToolbox対応PSoC 4/6デバイス

ModusToolbox対応中のPSoC 4/6評価ボードとデバイスを抜粋したのが下図です(全評価ボードとデバイスは、リリースノートを参照してください)。

ModusToolbox 2.3のPSoC 4/6対応デバイス
ModusToolbox 2.3のPSoC 4/6対応デバイス

弊社PSoC 4000S/4100S/4100PSテンプレートで使ったCY8CKIT-145-40XX、PSoC 6 FreeRTOSテンプレートで使用予定のCY8CPROTO-063-BLEともに、ModusToolbox v2.3で開発できます(PSoC 6 FreeRTOSテンプレートは、前稿参照)。前バージョン2.2から新たにPSoC 4が追加されました。

AN228571:「ModusToolboxソフトウェアを使用するPSoC 6 MCU入門」は、全てのPSoC 6アプリケーション開発に、ModusToolbox利用を推薦しています。また、PSoC 4も追加されたことを考えると、ModusToolbox は、PSoC Creatorの後継IDEの可能性大です。

Creator回路図はDevice Configuratorへ

Creatorの特徴は、ソフトウェア開発の最初に、回路図:TopDesign.cyschへPSoCコンポーネントを配置、必要ならコンポーネント間配線を行うことです。ソフトウェア出発点が、多少ハードウェア開発者向きです。

PSoC Creatorの特徴:TopDesign.cysch
PSoC Creatorの特徴:TopDesign.cysch

ModusToolboxはこの回路図配置が、GUIで使用リソースの設定を行うDevice Configuratorへ変わりました。他社Eclipse IDEベースのIDE(例えば、NXP:MCUXpresso IDEやSTマイクロ:STM32CubeIDE)でも同様の周辺回路設定があります。

ModusToolbox のDevice Configurator
ModusToolbox のDevice Configurator(出展:AN228571)

つまり、見た目も操作性も、Eclipse IDEベースの他社IDEと殆ど同じになりました。

PSoCコンポーネントに重きを置いたCreatorプログラミングよりも、Eclipse IDEに慣れた開発者の親しみ易さ、GitHub経由のサンプルコード等の最新版配布による利便性を重視し、よりソフトウェア開発者向きにしたIDEがModusToolboxです。

ModusToolboxソフトウェア構成

ModusToolboxソフトウェア構成
ModusToolboxソフトウェア構成(出展:AN228571)

ModusToolboxソフトウェア構成を見ると、GitHub経由の提供部分が解ります。

下層の各種ドライバ、HAL、BSPsから、ミドルウェアのBluetooth、Mbed OSやFreeRTOS等のライブラリ、これらのサンプルコードも全てGitHubから最新版が取得可能です。

IDE基本部分と、開発ニーズや時節に応じて変化する部分を分け、変化部分はGitHubから最新情報を提供する構成は、優れていると思います。

まとめ

Infineon/Cypressの最新IDE ModusToolboxの特徴を説明しました。Eclipse IDEベースのWindows/Mac/LinuxマルチOS対応で、GitHub経由で最新ドライバやサンプルコードが利用可能です。

PSoC 6アプリケーション開発は、PSoC CreatorからModusToolbox利用を推薦し、最新版ModusToolbox v2.3.0.4276へPSoC 4も追加されたことから、Creator後継のIDEになりそうです。
※ModusToolbox v2.3.1.4663(2021-05-06)はパッチファイルで、v2.3.0.4276の事前インストールが必要です。

なお、PSoC 4/6開発にCreatorも引続き使えます。しかし、今のところ既存CreatorプロジェクトからModusToolboxプロジェクトへの移行ツールは見当たりませんので、新規PSoC 4/6開発は、ModusToolboxで行う方が良いと思います。

ModusToolbox概要は、コチラの英語動画でご覧いただけます。また、丸文株式会社さんの開発ツールページに、インストール方法サンプルコード使用手順などが分かり易く説明されています。

Cortex-M4評価ボードRTOSまとめ

低価格(4000円以下)、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor NXP STマイクロ Cypress Espressif Systems
RTOS FreeRTOS
Azure RTOS
CMSIS-RTOS FreeRTOS
Mbed OS
FreeRTOS
Eva. Board LPCXpresso54114 NUCLEO-G474RE CY8CPROTO-063-BLE ESP32-DevKitC
Series LPC54110 STM32G4 PSoC 6 ESP32
Core Cortex-M4/150MHz Cortex-M4/170MHz Cortex-M4/150MHz
Cortex-M0+/100MHz
Xtensa LX6/240MHz
Xtensa LX6/240MHz
Flash 256KB 512KB 1024KB 480KB
RAM 192KB 96KB 288KB 520KB
弊社対応 テンプレート販売中 テンプレート開発中 テンプレート検討中 未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです(コチラの関連投稿3章を参照してください)。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS(Amazon Web Services)接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU:STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです(コチラの関連投稿:PSoCプログラミング要点章を参照してください)。

PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図
PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。

STM版CMSIS-RTOSアプリケーションテンプレート構想

販売中のNXP版FreeRTOSアプリケーションテンプレートに続いて、STマイクロエレクトロニクス版CMSIS-RTOSアプリケーションテンプレート構想を示します。

IoT MCU開発者にRTOS開発経験とスキルが必須であること、短期で効率的にRTOSスキルを磨けるSTマイクロエレクトロニクス版CMSIS-RTOSアプリケーションテンプレート構想を示し、汎用性、セキュリティ、広い流用性を持つSTM32G4をターゲットMCUにした理由を示します。

IoT MCU開発者スキル

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

IoT MCU開発者は、ベアメタルMCU開発スキルの上に、FreeRTOSやAzure RTOSなど接続するクラウドに応じたRTOSスキルが必要です。クラウド接続後、顧客要求のIoTサービスを実装しますが、実装時には、競合他社より早い開発スピードなどの差別化スキルも要求されます。

更に、IoTセキュリティや、より高性能なデュアルコアMCUへの流用、顧客横展開など、発展性への配慮も必要です。これらは、図示したようにベアメタルMCU開発スキルを基礎とする階層構造です。
※スキルとは、開発経験に基づいた手腕、技量のことです。

RTOS開発経験とスキル

全てのモノをネットワークへ繋ぐ時代は、従来のMCUからIoT MCUへの変革が必要です。IoT MCU開発者にとってRTOS開発経験とスキルは、近い将来必須になります。理由が下記です。

・RTOSライブラリ利用がクラウド接続に必須  👉①IoT MCU急増への備え
・大規模MCU開発にRTOSが便利(≒必須)   👉②開発規模拡大への備え
・ベアメタル開発よりもRTOS開発が効率的   👉③ソフトウェア資産への備え(補足参照)

つまり、過去何度も提言されたMCUソフトウェア資産化・部品化を、RTOSが実現するからです。逆に、IoT MCU開発では、このソフトウェア資産化・部品化(ライブラリ活用)無しには、実現できない規模・技術背景になります。
※例えば、IoTセキュリティだけでも専門家が対応すべき領域・規模・技術背景になりそうです。

IoT MCU開発の成功には、様々な専門家技術が活用できる土台のRTOSは必須です。IoT MCU開発専門家の一員となるには、RTOS開発経験とスキルは必須と言えるでしょう。

効率的RTOSスキル習得

ベアメタル開発経験者の効率的なRTOS基礎固め、スキル取得を弊社STM版CMSIS-RTOSアプリケーションテンプレートの目的とします。

この目的は、NXP版FreeRTOSアプリケーションテンプレートと同じです。違いは、NXP版がFreeRTOSを用い、STM版は、コード生成ツール:STM32CubeMXが出力するCMSIS-RTOSを用いる点です。

現時点のSTM版CMSIS-RTOS APIは、FreeRTOS APIをラップ(wrapper)したもので、中身はFreeRTOSそのものです。※CMSIS-RTOS詳細は、コチラの関連投稿を参照してください。

ベアメタル開発経験者のRTOS基礎固め・スキル獲得を、短期・効果的に達成するには、

・基本的RTOS待ち手段(タスク同期:セマフォとタスク間通信:Queue)理解
・RTOSプロトタイプ開発にも使える弊社テンプレートプロジェクト活用

が適しています。

既に持っているベアメタル開発経験を活かし、例えば、単独RTOSサンプルプロジェクトでは得られない複数タスク優先順位を変えた時の各タスク挙動や、RTOSセマフォ送受失敗時の挙動などスキルアップに役立つ事柄を、自ら評価・判断できるからです。この評価を助けるために、同じ動作のベアメタルプロジェクトもテンプレートに添付します。

効率的にRTOS開発スキルを習得する方法として、自己のベアメタル開発経験を使ってRTOS習得・スキルアップする本手法は、Betterな方法だと思います。

コチラにFreeRTOS習得に役立つ情報をまとめています。ポイントとなる点をざっと掴んで、実際の開発環境で試し、参考書やマニュアルなどの内容を開発者自ら考える、これにより新技術やスキルを、身に付けることができると思います。

STM版CMSIS-RTOSアプリケーションテンプレート構想

STM版CMSIS-RTOSアプリケーションテンプレートも、NXP版同様、同一動作のベアメタルプロジェクトを添付します。

RTOS/ベアメタルどちらのプロジェクトも、ADC入力、LCD出力、SWチャタリング対策入力、LED出力、VCOM入出力の動作確認済みで、プロトタイプ開発着手時のスタートプロジェクトとしても利用可能です。

付属説明資料には、ベアメタル視点からのCMSIS-RTOS説明を加えます。また、テンプレート利用CMSIS-RTOS APIとFreeRTOS APIの対応表も添付する予定です。

CMSIS-RTOSアプリケーションテンプレートをご購入後、ベアメタル開発経験者が、RTOSプロジェクトとベアメタルプロジェクトの比較・評価がスグに始められる構成です。※比較・評価は、ご購入者ご自身で行ってください。

STM32メインストリームMCU比較(出展:STマイクロエレクトロニクスに加筆)
STM32メインストリームMCU比較(出展:STマイクロエレクトロニクスに加筆)

CMSIS-RTOSアプリケーションテンプレート動作環境は、メインストリームMCUのSTM32G4評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)とHAL APIを用います。

STM32G4は、高性能で汎用性とIoT MCU基本的セキュティ機能を備え、RTOSテンプレートのターゲットIoT MCUとして最適です。

STM32G4のセキュリティ機能を示したのが下図です。

STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)
STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)

また、STM32G4の汎用性、他MCUへの開発ソフトウェア流用性の広さを示したのが下図です(詳細は、コチラの関連投稿3章を参照してください)。

NUCLEO-G474RE搭載のSTM32G474RETx Compatible MCU List。2021年8月時点で98MCU!
NUCLEO-G474RE搭載のSTM32G474RETx Compatible MCU List。2021年8月時点で98MCU!

NUCLEO-G474RE評価ボードの他には、ArduinoプロトタイプシールドとBaseboardを用います。

つまり、販売中のNXP版FreeRTOSアプリケーションテンプレート評価ボード:LPCXpresso54114が、STマイクロエレクトロニクスNUCLEO-G474REにのみ変化した構成です。

CMSIS-RTOS動作もNXP版と同様、Hardware Independent FreeRTOS Exampleを基としますので、(両テンプレートをご購入頂ければ)STMとNXPのRTOSアプリケーション開発の直接比較なども可能です。

STM版CMSIS-RTOSアプリケーションテンプレートのリリースは、今秋のWindows 10 21H2更新後(Windows 11リリース後かも?)を予定しております。時間的に少し余裕がありますので、Cypress版PSoC 6ディアルコア対応FreeRTOSアプリケーションテンプレートも同時リリースできればBestだと考えています。

補足:③ソフトウェア資産への備え

ベアメタル開発でもソフトウェア規模が大きくなると、開発者が悩む点は、複数処理の待ち合わせ/制御順序です。対策は、処理を細かく分割し、優先度を考慮しつつ順次処理を行うのが常套手段です。

ところが、RTOSを使うと、この面倒な待ち処理や制御順序を、RTOSがタスク優先順位に応じて処理します。しかも、処理分割も、RTOSがTICK_RATE_HZ単位で勝手(!?)に行ってくれます😀。

RTOSにより、タスク数やTICK_RATE_HZ、最大優先順位に応じたスタックを大量に利用しますのでRAM使用量の増加、RTOS自身のオーバーヘッドなど副作用も生じますが、「タスク記述は、超簡単」になります。

初期設定と無限ループ、ループ内のRTOS待ち手段、優先順位を検討すれば、文字通り単一処理タスクを開発し、マルチタスク化はRTOSに任せます。

※ベアメタル開発経験者は、セマフォ、Queue、Mutex、イベントグループなどのRTOS待ち手段を、上記実現のためのAPIと捉えると、RTOS理解が早くなります。
※上記手法を使うと、ベアメタルサンプルプログラムもそのままRTOSへ組込めます。
※最も難しそうなのが優先順位検討ですが、ソース上で簡単に変更できます。
※RTOSマルチタスク処理を100%信頼した上での筆者感想です。

Cortex-M4コアでRTOSが使えMCUのFlash/RAMに余裕があれば、ベアメタル開発よりもRTOS開発の方が効率的に開発できると思います。また、この環境で開発したソフトウェアは、資産として別のRTOS開発へも使えるので個人ソフトウェア資産化も可能です。

上記は、RTOSの筆者感想です。弊社RTOSアプリケーションテンプレートをご購入頂き、各開発者でRTOSに対する独自感想を抱き、短期で効率的にRTOS開発経験とスキルを磨いて頂ければ幸いです。

Windows 10と11、365まとめ

結論

現状判っているWindows 10とWindows 11、Windows 365の特性、類似サービスをまとめました。

Windows 10と11、365まとめ
Windows 10と11、365まとめ

Windows 10/11=買い切り型ローカルPC OS、Windows 365=サブスクリプション型マルチプラットフォーム対応クラウドPC OSです。

ハードウェアリスク低下、デバイス非依存の操作性とデータ保存、サイバー攻撃やセキュリティ対策のクラウド自動化など、Windows 365は、個人が従来から行ってきたWindows 10/11の保守・運用処理の殆どをクラウド任せにでき、そのメリットは大きなものがあります。

Windows 365コストは、企業向け300ユーザまでのBusinessプラン、ユーザ数無制限のEnterpriseプランが発表済みです(コチラにBusinessプラン感想記事があります)。

個人向けプランのコスト次第ですが、本来のPC創造へより注力できる環境がクラウドPC OS:Windows 365で提供されると言えそうです。Windows/Mac/Linuxなどのこだわりが不要となり、ローカルPC OSの終焉の始まりを感じます。

Windows 365のMCUクロス開発環境。Mbed開発環境に似ている。
Windows 365のMCUクロス開発環境。Mbed開発環境に似ている。

大好評のためWindows 365無料試用は、1日限りで受付中止となりました。Windows 365で、評価ボードやデバッガを使ったMCUクロス開発環境を実現できるかを受付再開後、試したいと考えています。

買い切り型とサブスクリプション型

PC作業に必須のWord/Excel/PowerPointなどのMicrosoft Officeは、日本だけで主流の買切り型と、欧米で人気のサブスクリプション型の2種類の提供方法があります。

買い切り型は、Windows、Macそれぞれ専用版があり、更新やセキュリティ管理などの運用面は購入者個人が行います。一方、サブスクリプション型は、Windows/Mac共通で、1ユーザ当たり複数異種PCの利用も可能です。運用面は、クラウドが常に最新版へ自動更新します。

現在のWindows 365情報は、企業向けのみで個人向けコストなどは未発表、Windows 11も未知の部分が多いのですが、Windows 10/11=買い切り型ローカルPC OS、Windows 365=サブスクリプション型、かつWindows/Mac/Linux/iOS/AndroidマルチプラットフォームクラウドPC OSと考えて良さそうです。

クラウドPC OSメリット:クラウドPC OS対ローカルPC OS

従来動作していたWindowsアプリケーションは、クラウドPC OS上でも動作します(ゲームアプリを除く筆者予想)。アプリインストは個人が行い、クラウドPCハードウェア構成も金額次第で高性能化可能です。クラウドPCでは、個人によるハードウェア経年変化対応などは不要です。
個人PC環境のハードウェアトラブルリスクは下がると思います。

Mac上でWindowsアプリを動作させるBoot CampやParallels Desktop、Linux上でのwineなどは不要です。クラウドPC OSへインストールしたWindowsアプリを、ブラウザ+RDP(Remote Desktop Protocol)クライアント経由で、手元のローカルPC/スマホ/タブレットで操作でき、アプリ作成データもクラウド内に自動保存されます。
デバイスに依存しない操作性と自動データ保存がもたらすメリットは大きいです。

また、次々に発生するサイバー攻撃やセキュリティ対策を個人が行うのは大変です(Win 10 Cumulative Updatesが例)。OS部分だけでもセキュリティ対策をクラウドが代行すれば、その分、個人は本来の価値創造に注力できます。
個人セキュリティ対策は楽になると期待できます。

最も類似するサービスが、メールです。ローカルメールが、Windows 10/11、クラウドメールがWindows 365に相当します。容量管理やメールアプリ更新の手間が不要、使用場所やデバイス制約もないクラウドメールを使い始めると、ローカルメールは不便で使えなくなります。コスト次第でWindows 365も同様になりそうで、ローカルPC OSもゲーマー以外は終焉かな?と感じました。

速報:IoT MCU RND脆弱性、解決策無し

2021年8月11日、IoT MCU RND脆弱性に解決策なしという記事が掲載されました。脆弱性を指摘したBishop Foxによると、解決策は無くアップデートが提供された場合には迅速に適用することをアドバイスしたそうです。

IoT MCUも、Windows 365のような仮想MCU化を願う記事内容です。

MCUXpresso IDE 11.4.0 Release

MCUXpresso suite of software and tools
MCUXpresso suite of software and tools

2021年7月15日、NXPの統合開発環境MCUXpresso IDEが、11.3.1から11.4.0へ更新されました。
新たに追加されたAzure RTOS、弊社FreeRTOSアプリケーションテンプレートの新環境での動作確認を示します。

Azure RTOS追加

FreeRTOSに比べ未だ12個と少数ですが、LPCXpresso55S06などCortex-M33コアのAzure RTOS 対応評価ボードとSDK v2.10.0が追加されました。Microsoft AzureのAWS追随が、統合開発環境に現れました(関連投稿:多様化MCU RTOS)。

Azure RTOS Boards
Azure RTOS Boards

これに伴い、IDEのRTOSメニューにAzure RTOSの Message QueuesやSemaphoresなどのViewが追加されました。Azure RTOSデバッグユーザガイトは、MCUXpressoIDE_11.4.0_6224インストールフォルダ内にありますので参照してください。

RTOSメニューに追加のAzure RTOS View
RTOSメニューに追加のAzure RTOS View

FreeRTOSアプリケーションテンプレートの新環境動作確認

Config Toolsもv10.0へ更新されましたので、新IDE更新後、旧11.3.1開発プロジェクトのPinパースペクティブで再度Update Codeのクリックが必要です。Updateクリック後、Develop画面に戻り再ビルドします。(Config Toolsの使い方は、コチラの関連投稿を参照してください)。

MCUXpresso Config ToolsのUpdate Code
MCUXpresso Config ToolsのUpdate Code

再ビルドは正常に終了し、新MCUXpresso IDE 11.4.0とFreeRTOS対応評価ボードLPCXpresso54114で、FreeRTOSアプリケーションテンプレートの動作確認をしました。

FreeRTOSアプリケーションテンプレートと付属資料も、11.4.0対応版へ更新します。

新MCUXpresso IDE 11.4.0で旧プロジェクト動作確認。LPCXpresso54114のSDK更新はなし。
新MCUXpresso IDE 11.4.0で旧プロジェクト動作確認。LPCXpresso54114のSDK更新はなし。

補足1:新旧統合開発環境併存

NXPの統合開発環境は、PC上で新旧環境が同時併存可能です。

環境が併存しますのでストレージ容量は必要です。また、ターゲットボードのSDK改版が無くても再度新IDEへのインストールが必要など手間もかかりますが、新環境構築が安心してできます。但し、新環境下でターゲットプロジェクト開くと、新環境用に変更され旧環境に戻せません。

ターゲットプロジェクトは、新旧環境で別々にすることを忘れないでください。

補足2:STM版CMSIS-RTOSアプリケーションテンプレート構想状況

FreeRTOSやAzure RTOSなど開発者が対応すべきMCU RTOSは、今後増える傾向です。RTOSが変わっても同じ開発アプリケーションを活用・流用できるのがCMSIS-RTOSメリットです。STM版RTOSアプリケーションは、このCMSIS-RTOSを使って構想中で、この状況を示します(詳細は、STM32RTOS開発3注意点(後編)などを参照してください)。

FreeRTOSとCMSIS-RTOSのセマフォAPI比較
FreeRTOSとCMSIS-RTOSのセマフォAPI比較

上側がFreeRTOSセマフォ送受、下側がCMSIS-RTOSセマフォ送受ソースです。どちらも殆ど同じです。

IDEにContent Assist機能(Ctrl+Space表示のAPI候補一覧)があるので、ソース記述は簡単で、基本的なRTOS手段(上記はタスク同期セマフォ)を理解済みなら、FreeRTOSに比べ情報が少ないCMSIS-RTOS開発でも、当初思ったより障壁は低いと感じています。

CMSIS-RTOSメリット/デメリットを比較して、メリットの大きさを感じた今回のNXP IDE更新でした。STM版CMSIS-RTOSアプリケーションテンプレート構想は、近日中に投稿予定です。

STM32CubeIDE/MX Major Release

2021年7月19日、STマイクロエレクトロニクスのMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へ更新されました。Major releaseです。開発済みMCUのSTM32CubeMX設定を、簡単に別ターゲットMCUへ移植する機能を解説します。

Major Release

STM32CubeIDE(以下、CubeIDE)は、ベースのEclipse IDE 更新に追随し年数回更新があります。今回のCubeIDE v1.7.0更新内容に、特に気になる点はありません。

一方CubeIDE付属コード生成ツール:STM32CubeMX v6.3.0(以下、CubeMX)には、開発済みMCUのCubeMX設定を、別MCUや別シリーズMCUへ簡単に移植する機能があります。移植性の高いHAL(Hardware Abstraction Layer)APIと併用すると、開発済みソフトウェアの再利用が簡単で強力なAPI生成ツールになりました。

STM32CubeMX設定移植機能

CubeMXには詳細な英語ユーザマニュアルUM1718 Rev35(全368ページ)があり、p1に主要機能説明があります。本ブログでもCubeMXコード生成機能の使い方やその重要性、STM32F0からF1へのソフトウェア移植方法などを何度か紹介してきました(検索窓に「STM32CubeMX」と入力すると関連投稿がピックアップされます)。

従来投稿は、MCUのCubeMX設定を、ターゲットMCUへ各項目を見ながら手動移植する方法でした。この方法は、予めターゲットMCUとの互換性が解っている場合や、移植周辺回路が少ない場合には有効です。

しかし、MCUの種類が増え、別シリーズMCUへ、または多くの周辺回路設定を個別に移植したい場合は、事前チェックは面倒です。そんな時に役立つ2機能が、UM1718 p1太文字記載の下記です。

  • Easy switching to another microcontroller
  • Easy exporting of current configuration to a compatible MCU

どちらもCubeMX画面のPinout & Configurationタブ選択、Pinoutプルダウンメニュー>List Pinout Compatible MCUs (Alt-L)をクリックすると、Full Compatible/Need Hardware change MCUが一覧表で表示されます。

List pinout compatible MCUs
List pinout compatible MCUs

STM32G0xテンプレート例

販売中STM32G0xテンプレートで使用中の汎用MCU:STM32G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/36KB)の例を示します。これは、評価ボードNUCLEO-G071RB搭載MCUです。

STM32G071RB Full and Partial match MCU List
STM32G071RB Full and Partial match MCU List

評価ボード搭載のLQFP64パッケージでフィルタ設定すると、青色:完全互換の汎用STM32G0シリーズMCUが12アイテム、黄色:一部ハードウェア変更が必要な低電力STM32L0シリーズMCUが17アイテムリストアップされます。

例えば、FlashやRAMを増量したい場合には、STM32G0B1RBへ開発ソフトウェアがそのまま移植できることが解ります。また、より低電力化したい場合には、STM32L071RBへも移植可能です。あとは、ターゲットMCUを選択し、STM32G0xテンプレートのCubeMXプロジェクト設定を全て移植するか、または一部周辺回路のみを移植するかの選択も可能です。

つまり、開発済みソフトウェアを別MCUへ移植する際に、容易性(完全互換/一部HW変更)と方向性(大容量化/低電力化など他MCUシリーズ適用)を評価でき、かつ、ターゲットMCU選択後は、ダイアログに従って操作すれば、CubeMX設定全て、または周辺回路毎にターゲットMCUへ自動移植ができる訳です。

CubeMX設定の移植後は、ターゲットMCU上で通常のようにコード生成を実行すれば、周辺回路初期設定や動作に必要となる関数群の枠組みが作成されます。その枠組みへ、STM32G0xテンプレートのHAL API開発済みソフトウェアをコピー&ペーストし、ターゲットMCUへのソフトウェア移植が完了です。

汎用MCUとHAL APIプロトタイプ開発

最新メインストリーム(汎用)プロトタイプ開発イメージ
最新メインストリーム(汎用)プロトタイプ開発イメージ

CubeMX設定の自動移植が簡単なことは、前章まででご理解頂けたと思います。

前例STM32G0xテンプレート開発ソフトウェアの移植可能なMCU数が12+17=29と大きいのは、汎用MCUとHAL APIを使ったソフトウェア資産だからです。

最新IoT MCU開発でも、STM32G0/G4シリーズなどの移植性が高い汎用MCU(=メインストリームMCU)とHAL APIを使って主要機能をプロトタイプ開発し、CubeMX移植機能を使ってターゲットIoT MCUへ移植すれば、最新IoT MCUの差分機能開発に集中できます。

つまり、「汎用MCUとHAL API利用のプロトタイプ開発は、他MCUへの移植性が高く、汎用との差分開発に集中できる高い生産性」をもたらす訳です。

※STM32G0/G4シリーズは、新プロセスで従来汎用STM32F0/F1/F3シリーズを高速・低電力化・セキュリティ強化した新しい汎用MCUです。コチラの関連投稿や、STM32U5発表と最新IoT MCU動向を参照してください。

STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)
STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)

まとめ

STマイクロMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へMajor Releaseされました。

開発済みMCUのCubeMX設定を、別MCUへ簡単に移植する機能があり、移植性が高い汎用(メインストリーム)MCUとHAL APIによるプロトタイプ開発ソフトウェア資産を、効率的に他MCUへ再活用できる統合開発環境になりました。

補足:NUCLEO評価ボードのユーザLED不足対策

汎用MCUとHAL APIプロトタイプ開発には、低価格で入手性も良いNUCLEO評価ボードが適しています。

但し、NUCLEO評価ボードのユーザ緑LED(LD2)とSW(B1)が、各1個と少ない点が残念です。CubeIDEサンプルプログラムは、単機能サンプル動作なので各1個でもOKですが、少し複雑な例えばRTOS並列動作確認などには、特にLEDが不足します。

お勧めは、赤LED 2個、SW 1個が実装済みのArduinoプロトタイプシールドです。残念ながらNUCLEO評価ボードSW(B1)は操作できないのでシールドSWで代用します。評価ボードArduinoピンとの配線や、付属ブレッドボードへの回路追加も簡単です。ST以外の様々なMCUベンダのArduinoコネクタ付き評価ボードでも使えます。

NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。
NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。

NUCLEO-G474REとArduinoプロトタイプシールドの使用例を示します。ArduinoプロトタイプシールドのLED1は、Lpuart受信、LED2は、SW操作、評価ボードのLD2は、1s/500ms/40ms点滅の動作確認に使っています。

STM版RTOSアプリケーションテンプレート構想もこの環境で検討中です(関連投稿:STM32RTOS開発3注意点(前編)、(後編))。

STM32RTOS開発3注意点(後編)

STM32MCUでRTOS開発を行う時の3注意点、前編のSTM32CubeMX、HALに続き、本稿後編でCMSIS-RTOS関連を示します。

※木曜からの東京オリンピック4連休のため、通常金曜を本日水曜日に先行して投稿します。

前編は、STM32RTOS開発実例として、NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのSTM32CubeMX(以下CubeMX)コード出力を使い、HALタイムベース変更の必要性を示しました。後編は、前編と同じ実例を使ってCMSIS-RTOSの注意点を示します。

FreeRTOS_Queues STM32CubeMXファイルのTasks and Queues

NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoを開き、Middleware>FREERTOSのTasks and Queuesタブをクリックしたのが下図です。

FreeRTOS_QueuesのSTM32CubeMXファイルTasks and Queues
FreeRTOS_QueuesのSTM32CubeMXファイルTasks and Queues

2つのタスク:MessageQueuePro(Qプロデューサ:送信タスク)とMessageQueueCon(Qコンシューマ:受信タスク)と、1つのQ:osQueue(深さ1:ワード)を、CubeMXで自動生成するパラメタが設定済みです。関連投稿:NXP版FreeRTOSのQueueデータ送受信と同じです。

全て黒文字パラメタですので、変更も可能ですが、このままソースコードを自動生成(Alt+K)してください。

CMSIS-RTOS APIからFreeRTOS API変換(wrapper)

CMSIS-RTOS APIからFreeRTOS API変換
CMSIS-RTOS APIからFreeRTOS API変換

main.cのL125に、osQueueを生成するAPI:osMessageCreateが自動生成済みです。また、L134とL138に、MessageQueueProとMessageQueueConのタスク(Thread)を生成するAPI:osThreadCreateも自動生成済みなのが判ります。

ここで、API先頭にosが付くのは、CMSIS-RTOSのAPIだからです(L145のosKernelStartも同様)。詳細は、次章で説明します。

さて、L125のosMessageCreateへカーソル移動し、F3をクリックすると、cmsis-os.cのL1040へジャンプし、CMSIS-RTOS APIのosMessageCreateの中身が見えます。その中身が、L1055のxQueueCreateで、これはFreeRTOSのAPIです。

つまり、CubeMXが自動生成したのは、CMSIS-RTOS APIですが、その実体は、FreeRTOS APIであることが判ります。
この例のように、CubeMXが生成したCMSIS-RTOS APIは、cmsis_os.cで全てFreeRTOS APIへ変換されます。

CMSIS-RTOS

CMSIS-RTOSは、Cortex-Mコア開発元ARM社が定めたRTOS APIの規格です。
※CMSIS:Cortex Microcontroller Software Interface Standard

Cortex-Mコアには、FreeRTOS/Azure RTOS/mbed OSなど様々なRTOSが使えます。下層のRTOSが変わるとAPIも変わりますが、そのAPIを変換し、上層アプリケーションへ共通なRTOS APIを提供する、これにより、

  1. RTOSが異なっても、同じ開発アプリケーションが使えること
  2. Cortex-Mコアが異なっても、開発アプリケーション移植を容易にすること

これらがCMSIS-RTOSの目的です。

これをラップ(wrap=…を包む)と呼ぶことがあります。ラップ関数(wrapper)とは、下層API差を隠蔽し、上層アプリケーションへ同一APIを提供する関数のことです。STM32RTOS開発でのCubeMXの役目の1つは、使用するRTOSに応じたwrapperを提供することです。

現在、STM32RTOS開発のCubeMXがラップしているのは、FreeRTOSだけです。今後、FreeRTOSがAzure RTOSなどへ変わっても、開発アプリケーションをそのまま活用するために、今の時点からCMSIS-RTOS APIを使っている訳です。

Cortex-M0/M0+/M3/M4/M7コア向けの共通RTOS APIがCMSIS V1、Cortex-A5/A7/A9と全Cortex-Mコア向けの共通RTOS APIがCMSIS V2です。STM32RTOS開発では、CMSIS V1を用います。

CMSIS-RTOS とFreeRTOSのAPI

UM1722にCMSIS-RTOS APIとFreeRTOS APIの一覧が示されています。抜粋したのが下表です。

FreeRTOSとCMSIS-RTOSのAPI
FreeRTOSとCMSIS-RTOSのAPI

接頭語にx/vなどが付くのがFreeRTOS API、osが付くのがCMSIS-RTOS APIです。

CubeMXが生成するコードは、常にCMSIS-RTOS APIですが、実体はFreeRTOS APIです。FreeRTOSが別のRTOSへ変わっても、CMSIS-RTOS APIは同じです。CMSIS-RTOS APIとFreeRTOS APIのwrapper分のオーバーヘッドは生じますが、下層RTOSに依存しない点は、先進的で優れています。

なおUM1722 Rev3には、単にAPI列記とwrapper、RTOSサンプルプロジェクトの簡単な説明が記載されているだけです。

まとめ

STM32MCUでRTOS開発を行う時の3注意点(前編:STM32CubeMX、HAL)に続き、本稿後編で3つ目のCMSIS-RTOSを示しました。

STM32RTOS開発のSTM32CubeMXが扱うRTOSは、現在FreeRTOSだけです。FreeRTOSが別のRTOSへ変わっても、CubeMXは、開発アプリケーション流用性を高めるためにFreeRTOS APIの代わりにRTOS共通CMSIS-RTOS APIを出力します。

CMSIS-RTOS APIには、Cortex-M0/M0+/M3/M4/M7コア間で開発アプリケーション移植性が高いCMSIS V1を使います。

CMSIS-RTOS API変換オーバーヘッドがありますが、流用性、移植性に優れたRTOSアプリケーション開発ができる点は、優れています。

あとがき

残念ながらCMSIS-RTOS情報は、シェア1位AWSのFreeRTOSに比べ少なく、この少ない情報を使ってSTM32RTOS開発を行うのは、大変です。
※2位がAzureのAzure RTOS、3位がGCP(Google Cloud Platform)のmbed OS。関連投稿はコチラ

例えば、最初の図:CubeMXのTasks and QueuesのGUI設定パラメタが多いにもかかわらず、UM1722サンプルプロジェクト説明が少ない点などです。

RTOSは、複数タスク(CMSIS-RTOSではThread)間の優先順位差とRTOS自身の動作により、開発タスク処理状態が変わります。ベアメタル視点に加え、RTOS視点でのタスク開発と経験が求められます。QueueなどRTOS単独手段理解が目的のサンプルプロジェクトだけでは、RTOS開発経験は積めません。

弊社はこれらの対策として、効率的なRTOS基礎固め、STM32RTOSアプリケーションのプロトタイプ開発早期着手を目的としたSTM版RTOSアプリケーションテンプレート(仮名)を検討中です。その構想は、固まり次第、別稿にて示す予定です。

なお、NXP版FreeRTOSアプリケーションテンプレートは、コチラで販売中です。

Windows 11ショックとTPM

所有3PCのWindows11要件チェック結果
所有3PCのWindows11要件チェック結果

今秋リリース予定のSun Valleyは、新OSのWindows 11でした。TPM 2.0が障壁になり、所有3PCのうち2PC(Note/Backup)はWindows 10からWindows 11へ無償アップグレードができません。アップグレード要件に変更が無ければ、MainのみWindows 11になり、残りはWindows 10のまま・・・、Windows 11ショックです。

このWindows 11ショック原因のTPM、現状の対処法などをまとめます。

TPM (Trusted Platform Module)

TPMは、MicrosoftがWindows 11(以下Win 11)要件にした専用ハードウェアで、PCを起動するBIOS/UEFIのデバイスです。セキュリティキー、暗号鍵や機密性の高いユーザーデータの保護・保管機能を持ち、最新版Version 2が必要です。

このTPM機能を既に持っているPCでも、Win 10では未使用が多かったのが判っています。弊社Main PCもそうで、設定を変更し最初の図のようにWin11対応チェック結果が全てOKになりました。

テレワークでPC需要が高いこの時期に、敢えてTPMをWin 11アップグレード要件にしたMicrosoftの狙いが、もしも新しいPCへの買換え需要喚起だとしたら、残り2PCは、WindowsからLinux MintへのOS乗換も対処法に入れます。

※2021年7月8日、Linux Mint 20.2 MATEがリリースされました。サポート期間は2025年までです。

弊社テレワーク利用中のMCU開発アプリケーションは、マルチプラットフォーム対応なのでOS乗換に問題はありません。

MCUのTPM相当機能

MCUにも暗号鍵などを保管するTPM相当の外付けチップがあります。例えば、関連投稿のNXP)EdgeLock SE050、Maxim)DS28E38などです。これらは、MCU外付けのセキュリティ強化ハードウェアです。

また、これら外付けハードウェアを使わずに、セキュリティ強化内蔵Flashへ機密情報を保存するCortex-M33コアMCUなどもあります。

これらMCUへTPM相当の機密情報保持機能を実装すると、開発工数が増えることが判っています。

Win 11要件のTPMは、IoT MCUがMicrosoft Azure接続時、上記どちらかの機密情報保持機能を持たないMCUは、例え接続中であっても、将来のセキュリティ脅威を理由に接続拒否することに近いと思います。

MCU開発者は、新たな開発案件が増えて喜びそうですが、Azure利用中の顧客は、納得するでしょうか? Azure以外のAWSやGoogleクラウドへの移行にならないでしょうか?

関連投稿:多様化MCU RTOS対策

一方、スマホなどモバイルデバイスのTPM相当:機密情報保持機能も知りたいと思います。今後調査予定です。

TPM効果

  • なぜBIOS/UEFIのTPMハードウェアなのか、OSソフトウェアで代替しない(できない)理由は何か?
  • TPM情報は、PCのバックアップアプリでバックアップ/リカバリできるか?
  • BIOS/UEFI更新時、TPM情報は保持されるのか?
  • TPM不具合発生時、Win 11は起動しないのか?
  • PC廃棄時のTPM情報の完全削除とその確認方法は?
  • TPM搭載Win 11 PCと、非搭載Win 10 PCのサイバー攻撃防衛差は、どの程度か?

など、TPM採用の明確な理由とその効果を示した情報は、今のところ見当たりません。Win 10でTPMをデフォルト未使用としたのも、なんらかの理由や副作用があったからだと思います。

定性的には、セキュリティ対策が重要であることは解ります。しかし、定量的な比較や副作用も知りたいです。

具体的に、TPM無し(未使用)BIOS/UEFI のWin 10 PCと、TPM有効化Win 11 PCで比較し、攻撃防御差が大きいなら費用対効果によりWin 11対応の新PC購入もありえます。

もちろんPCハードウェアも経年劣化します。しかし、パーツ単体交換が容易なのもWin PCのMacやスマホに無い特徴です。最初の図のようにWin 10で快適に動作するハードウェアが、BIOS/UEFI TPMだけでNGになるのは、「足切り」に近いと感じます。

Win 10と同様、Win 11でもユーザ責任でTPM未使用オプションが設定できれば済む話です。Win 11プレビュー版は、TPM無しでも動作します。このオプション相当は既に存在します。

TPM効果、その具体的・数値的な攻撃防御差評価は、必要でしょう。

Windows 11とWindows 10の運用対処法

現在判っているWin 11とWin 10の主な運用面差が下表です。

Windows 11 Windows 10
OSコア 新OS(Cobalt) 旧OS
大型更新 年1回 年2回
サポート期間 大型更新後2年 大型更新後1.5年
サポート終了2025年10月

Win 11の下図のような新GUIに対して、使いなれたWin 10やWin 7に近いGUIへ戻す無償ツールが既にあります。筆者もOSの見た目の新しさは不要です。現行Win 10でさえ、上記ツールを使って効率的なGUIに変えて運用中です。

Windows11の新GUI
Windows11の新GUI

当然ながら新しいOSコア(Cobalt)ですので、旧OS比、見た目以外の性能も改善されるでしょう。

しかし、Win 10の旧OSコアがトラブルなく安定するまで数年を要したことや大型更新回数が年1回に減ったことも考慮すると、最低でもWin 11新OSコア(Cobalt)安定に1年はかかると思います。

従って、次回Win 11大型更新の1年後まで、アップグレードを待つのは、安全策として良さそうです。

Windows 10サポート延長

Win 10のサポート終了は、2025年10月14日となっています。しかし、良い意味で撤回し、「Win 7のようにサポート終了が延長」される可能性は高いと筆者は思います。

その理由は、Win 10 Version 21H1が、20H1からの3世代、2年に渡る同じOSコアの小規模更新をした結果、更新トラブルが減り安定度が増したこと、Win 11へ更新できない多くのWin PCの「最後の受け皿OS」となること、などです。

サポート終了のWin 7、2023年1月10日にサポート終了予定のWin 8.1のPCは、足切りTPMのためWin 11へのアップグレードが不可能です。Win 7/8.1世代のPCは全てWin 10になり、アップグレードしないWin 10を含めて2025年10月までこれらPC群は稼働できます。

4年半後、2025年10月予定のこれらPC群へのWin 10サポート終了は、多くのユーザ反感を買うと同時に、セキュリティ更新無しで稼働するPCを多数生みます。

何らかの方法でWin 10へTPM相当機能を実装するか、または、セキュリティサポートを延長することは、これまで足切りアップグレードを避けることでシェアを伸ばしてきたMicrosoftの宿命だと思います。

まとめ

2025年10月14日のWindows 10サポート終了までは、Windows 11 TPM要件のため、所有3PCをWin11とWin10の2種運用とするか、それとも3PCともWin10運用とするか、今秋のWindows 11リリース後のトラブル状況や、前章までに示した対処法で決める予定です。

ポイントの1つは、TPM未使用のWin 10 PCとTPMを使うWin 11 PCのサイバー攻撃防御差、その費用対効果です。
※ネットカフェのWin PC移行状況でこの評価結果が判ると思います。

ただMCUテンプレートを新たに開発する立場からは、最新PC環境、つまりWin 11で新開発テンプレートの動作確認は必須です。2 OS運用は余分に手間が掛かりますが、Win11とWin10の併用にならざるを得ない、というのがWindows 11ショックの根源です😣。

なおMicrosoftは、Win 11要件の見直しも行っているようです。TPM相当手段や未使用オプションなどに期待しています。また、7月14日発表のWindows 365 Cloud PCも、料金次第ですが気になる存在です。

* * *

速報:Microsoftは、7月15日(米国現地時間)、Windows 11とは別に、次期Windows 10バージョン 21H2 、サポート期間1.5年の提供を発表しました。また、5年サポート期間の Windows 10バージョンLTSC(Long-Term Servicing Channel)も提供するようです。今秋、提供開始予定です。

半導体・デジタル産業とホノルル便パイロット

経産省が2021年6月4日に発表した「半導体・デジタル産業戦略」について、専門家の評価は悲観的です。

我々IoT MCU開発者は、ホノルル便パイロットを見習い、対応策を持つべきだと思います。

経産省半導体・デジタル戦略の評価

今こそ日本の大手電機各社は半導体技術の重要性に気付くべき、EE Times Japan、2021年6月15日

日本の半導体戦略は“絵に描いた餅”、TechFactory、2021年6月16日

日本の半導体ブームは“偽物”、再生には学校教育の改革が必要だ、EE Times Japan、2021年6月22日

専門家が日本政府や経産省の方針を批判するのは、コロナ対策と同様、当然です。また下記、英)Financial Times評価を紹介した記事からも、専門家評価と同様、概ね懐疑的であることが判ります。

半導体製造業の日本の取組みに対する海外メディア評価、Gigazine、2021年7月6日

この戦略結果として生じる半導体・デジタル産業の市場変化の影響を直接受けるのは、我々IoT MCU開発者です。しかも、結果がでるまでの時間は、ますます短くなっています。この分野が、自動車や次世代通信などを含む「全ての産業の要」だからです。

経産省戦略資料は、コチラからダウンロードできます。概要・概略だけでも相当な量があり、対象がMCU技術者ならまだしも、マネジメントや一般技術者が、本当に要点を把握できるか、筆者でも疑問に感じます。

ホノルル便緊急事態対策

かつて護送船団方式ともいわれた日本産業の舵取りは、成功もありますが失敗も多いです。同調圧力に弱い日本人には、この方式が向いていたのかもしれません。

問題は、舵取りの結果生じる市場変化に、どう対応するかです。

対応策ヒントの1つになるのが下記記事です。

太平洋の真ん中でエンジン停止したらどうなるか、東洋経済、2021年6月27日

パイロットは、太平洋上での緊急事態対応のため、60分毎に東京/ミッドウェー/ホノルルの天候情報を集め、燃料残量や対地速度などの機体状況を確認し、180分以内に着陸できる空港を検討するのです。しかも、この緊急事態は、パイロットが入社し定年退職するまでに一度も経験することの無い0.024%の発生確率でもです。

ホノルル便パイロットの緊急事態対応(出展:記事)
ホノルル便パイロットの緊急事態対応(出展:記事)

この東京~ホノルル便エンジン停止などの緊急事態発生確率に比べると、半導体・デジタル産業の国による舵取り失敗確率は、高いと思います。

我々MCU開発者も、ホノルル便パイロット並みとはいかなくても、せめて開発が一段落付く毎に、最新IoT MCU状況を確認し対応を検討することは重要です。一段落が付いた時は、開発に使ったMCUの利点欠点を把握直後なので、他MCUとの比較も精度良くできるからです。

この検討結果をどのように反映するかは、開発者次第です。

お勧めは、もしもの時の「第2候補IoT MCU案:Plan Bを、開発者個人で持つこと」です。Plan Bは、たとえ同じARM Cortex-Mコア利用であっても、ベンダ毎に手間やAPIが異なるIoT MCU開発に、心理的余裕を与えます。Non ARMコア利用ならなおさらです。

個人でなら、同調圧力に関係なく、自分の開発経験や勘を使ってPlan Bを検討できます。

まとめ

2021年6月経産省が発表した半導体・デジタル産業戦略の専門家評価は、悲観的です。国の舵取りが失敗した例は、過去の電機や半導体企業の衰退が物語っています。巨額投資と市場シェアの両方が必要な半導体・デジタル分野は、既に弱体化した国内企業の巻返しにも期待はできません。

舵取り失敗確率は、現役ホノルル便パイロットが、太平洋上で緊急事態に出会う確率よりも高いでしょう。

最先端デバイスを利用するIoT MCU開発者の対応策の1つは、開発が一段落付く毎に、最新半導体・デジタル市場を確認し、もしもの時の第2 IoT MCU利用案:Plan Bを開発者個人で持つことです。

個人で安価にPlan Bを持つため、評価ボード動作確認済み各種マイコンテンプレートはお役に立てると思います。関連投稿:半導体不足とMCU開発案に、Plan B構成案もあります。

STM32RTOS開発3注意点(前編)

STマイクロエレクトロニクス)STM32MCUを使ってRTOS開発時のSTM32CubeMX、HAL、CMSIS RTOSの3注意点について示します。前編が、STM32CubeMXとHALについてです。CMSIS RTOSは、別途後編で示します。

STM32CubeMXとHAL の注意点を解説した後、サンプルプロジェクトで実例を示すという順番で説明します。

ソースコード生成ツール:STM32CubeMX

STマイクロのソースコード生成ツール:STM32CubeMX(以下CubeMX)は、MCU内蔵周辺回路の初期設定やAPIを、GUIベースで自動生成する非常に便利なツールです。

※MCUベンダのAPI生成ツールを比較した関連投稿は、コチラをご覧ください。

CubeMX生成APIは、ハードウェアを抽象化し、STM32MCU間で最大限の高いソフトウェア移植性を狙ったHAL (Hardware Abstraction Layer)と、よりハードウェアに近くHALよりも高速・軽量なエキスパート向けLL(Low-layer)の2種類から選択可能です。

HALとLL比較(出典:STM32 Embedded Software Overvire)
HALとLL比較(※説明のため着色しています。出典:STM32 Embedded Software Overvire)

一般的に、HAL APIが好まれます。というのは、このLL APIを利用し開発した2019年6月発売のSTM32G0xテンプレートV1の売上げはゼロでした。対策に、LL APIからHAL APIに変更し再開発した2020年6月発売のSTM32G0xテンプレートV2は、人気があるからです。

これらCubeMXの各種GUI設定や選択APIは、CubeMXファイル(.ico)に構成ファイルとして纏められます。

STM32MCU新規プロジェクト開発時に、この既成CubeMXファイル(.ico)を利用すると、ゼロから着手するのに比べ、効率的かつ間違いなく周辺回路や初期設定ができるため、利用価値の高いファイルです。

特に、ベアメタル比、さらに多くのCubeMX設定が必要となるRTOS開発では、既成CubeMXファイルを再利用するメリットがより高まります。同時に、生成コードの意味も理解しておく必要があります。

HALタイムベース

HALには、他ベンダにない便利なAPI:HAL_Delayがあります。

例えば、10msの待ち処理を行う場合、他ベンダなら、MCUコア速度に応じて適当にループ回数を調整したループ処理で10ms相当の遅延を自作します。しかし、HAL APIならば、HAL_Delay(10)の記述だけで、MCUコア速度に依存しない正確な10ms遅延が実現できます。

これは、HAL自身が、MCU内蔵タイマ:SysTickの利用を前提に設計されているからです。遅延処理を例に説明しましたが、STM32のHAL APIsは、SysTickと強く結びついています。

もちろん、HAL APIをベアメタル開発で利用する場合は、この結びつきに何ら問題はありません。

RTOSタイムベース

FreeRTOSも、タスク(スレッド)状態遷移タイムベースに、SysTickを使います。

これは、FreeRTOSだけでなく他のRTOSでも同じです。SysTickは、その名称が示すようにMCUシステムレベルのタイムベース専用タイマです。

従って、STM32MCUでRTOS開発を行い、かつHAL APIを利用する場合には、RTOS側でSysTickを使うのが、名称に基づいた本来の使い方です。

HALタイムベース変更

そこで、STM32RTOS開発でHAL利用の場合は、HALのタイムベースを、デフォルト使用のSysTickから別のタイマへ変更する必要が生じます。この変更に伴う手動設定も当然必要となります。

*  *  *

ここまでが、STM32RTOS開発におけるSTM32CubeMXとHALに関する注意点です。
これらの注意点が解っていると、次章で示すRTOSサンプルプロジェクトのCubeMXファイルの意味と生成コードが理解できます。

STM32RTOS開発実例

STM32RTOS開発実例に、評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)でRTOS開発する場合を示します。

NUCLEO-G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/32KB)でRTOS開発する時でも同様です。しかも、RTOSサンプルプロジェクトは、STM32G071RBの方が(発売が古いためか?)多いので、NUCLEO-G071RBをお持ちの方は、是非ご自身で試してみてください。

FreeRTOS Example Selector

STM32CubeIDEのFile>STM32 Projectで、新規プロジェクト作成パネルを表示します(最新情報更新のため、表示に少し時間がかかる場合があります)。Example Selectorタブを選択、Middleware>FreeRTOSにチェックを入れ、NUCLEO-G474REのFreeRTOS_Queuesを選択したのが下図です。

NUCLEO-G474REのFreeRTOS_Queues
NUCLEO-G474REのFreeRTOS_Queues

右上欄、Noteの内容が、前半までに示した注意点のことです。参照先UM1722 Rev3は、CMSIS RTOSとFreeRTOSの関係があるのみです。このCMSIS RTOSについては、別途後編で説明します。

Nextをクリックし、FreeRTOS_Queuesサンプルプロジェクトを新規作成します。

さて、FreeRTOS Examples Listが318アイテム(STM32CubeIDE v1.6.1時)もあるので、Exportをクリックし、出力されたExcelファイルをBoardでフィルタリング、NUCLEO-G071RBとNUCLEO-G474REを抽出したのが下図です。

FreeRTOS Example List
FreeRTOS Example List

緑に色付けしたNUCLEO-G071RBの方が、FreeRTOSサンプルプロジェクト数が多いことが判ります。開発予定のSTM版FreeRTOSアプリケーションテンプレートは、Cortex-M4コアが対象ですので、本稿ではNUCLEO-G474REのFreeRTOS_Queuesを実例として使いました。

FreeRTOS_QueuesのSTM32CubeMXファイル

FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoが下図です。グレー文字は変更不可、黒文字は変更可能を示します。

FreeRTOS_Queues.ico
FreeRTOS_Queues.ico

TIM6がグレーなのは、HALタイムベース変更先がTIM6だからです。Kernel settings CPU CLOCK HZのSystemCoreClockがグレーなのは、RTOSタイムベースがSysTickだからです。つまり、本来の名称に基づいたSysTickがRTOS側で使われ、HALの新タイムベースにTIM6が割当済みであることが解ります。

FreeRTOS APIは、変更不可のグレーCMSIS V1です。ここは、後編で説明します。

デフォルトDisabledのUSE IDEL HOOKを、Enabledに変更し、ソースコード自動生成のGenerate Code(Alt+K)を実行してください。

HALタイムベースTIM6変更結果

FreeRTOS_QueseのTIM6とHook関数
FreeRTOS_QueseのTIM6とHook関数

app_freertos.cのL62に、Hook関数:vApplicationIdleHoolのひな型が自動生成済みです。ここへWFIを追記すれば、FreeRTOSアイドル時に低電力動作ができます。コチラのNXP版関連投稿Step5: FreeRTOS低電力動作追記と同じです。

main.cのL289は、TIM6満了時動作です。HAL_IncTick()が自動生成済みです。ベアメタル開発のSysTickからTIM6へHALタイムベースが変更されたことが解ります。

そのTIM6は、stm32g4xx_hal_timebase_tim.cで、1MHz=1ms満了に初期設定済みです。

つまり、STM32RTOS開発でHAL利用時に必要となる変更が、「全てCubeMXで自動生成済み」なのが解ります。

※上図は、USE_TICK_HOOKもEnabledへ変更した例です。Disabledへ戻すなどして、CubeMX自動生成ファイルが変化することを確かめてください。

この実例のように、CubeMX付属RTOSサンプルプロジェクトのCubeMXファイル(*.ico)を再利用すれば、周辺回路や初期設定ミスを防ぎ、RTOS新規アプリケーション開発が容易になることが解ります。

まとめ

STM32MCUでRTOS開発を行う時の3注意点、STM32CubeMX、HAL、CMSIS RTOSのうち、前編としてSTM32CubeMX、HALの2注意点とサンプルプロジェクトを使ってその実例を示しました。

RTOS開発では、既成STM32CubeMXファイル再利用価値が高まること、HALタイムベース変更の必要性がご理解頂けたと思います。3つ目のCMSIS RTOS関連は後編で示します。

あとがき

ベアメタル開発経験者であっても、STM32RTOS開発時、CubeMXのNoteを読むだけで、ベアメタル開発では何の問題も無かったHAL タイムベース変更理由が解り、その結果生じるCubeMXファイルや自動生成ソースコードの中身が理解できる方は、少ないと思います。本稿は、この変更理由と生成コードに説明を加えました。

STM32CubeMXは、STM32MCU開発に必須で強力なAPI生成ツールです。が、時々、説明不足を感じます。問題は、どのレベル読者を相手にするかです。エキスパートなら説明不要ですが、初心者ならゼロから説明しても解らないかもしれません。文章による組込み技術説明が、難しいのが根本原因でしょう😂。

そんな組込み開発ですが、文章だけでなく、「実際に評価ボードと手足を使って慣れてくると、案外すんなり簡単に理解、習得できる方が多いのも組込み開発」です。

販売中のNXP版FreeRTOSアプリケーションテンプレートにも、本稿同様、詳しいFreeRTOS解説を付けています(一部ダウンロード可能)。FreeRTOS開発を手軽に試せ、習得を支援するツールです。