STM32G071RBとAlexaを繋ぐ

1月9日STマイクロエレクトロニクス(以下STM)公式ブログに、STM32G0とAlexa(アレクサ)を接続する開発キット:Alexa Connect Kit(ACK)モジュールが紹介されました。アレクサに話しかけ、STM32G0評価ボードのNucleo-G071RB 経由でスマートホーム制御が簡単に実現できます。

システム構成

STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成
STM32G071RBとAlexaを接続するAlexa Connect Kit (ACK)のシステム構成

システム構成のブログ掲載が無いので、自作したのが上図右側です(左側出典:STMサイト、Cortex-M7 MCUでアレクサ接続)。

USI MT7697HがACKモジュールで、Nucleo-G071RBとはArduinoコネクタで接続します。スマートスピーカに話しかけると、クラウド内で音声解析→制御コマンド生成を行い、このコマンドがACKへ無線送信され、STM32G0評価ボードNucleo-G071RBへ届き、STM32G071RBがスマートホーム機器などを制御します。

費用とSTM32G0用ACKドライバ、ファームウェア

費用:Nucleo-G071RBが約$10、ACKがUS Amazonで$197、(日本アマゾンで¥38,202)。

STM32G0用ACKドライバ、ファームウェア:公式ブログリンク先は、今日現在、提供されていません。

2018年6月頃は、STM32F7やSTM32H7などの高性能Cortex-M7 MCUでアレクサ接続がSTM公式ブログで投稿されましたが、今回Cortex-M0+のSTM32G0とACKでも簡単に接続可能になりました。

STM32G0特徴

2018年末発売のSTM32G0シリーズは、初の90nmプロセス製造MCUで低消費電力と高速動作、従来のSTM32F0 (Cortex-M0)~F1 (Cortex-M3)性能をカバーする新汎用MCUです。セキュリティハードウェア内蔵、低価格、64ピンパッケージでも1ペアVDD/VSS給電がSTM32G0の特徴です。
関連投稿:STM新汎用MCU STM32G0守備範囲が広いSTM32G0

「STM32G0 シリーズのラインナップ拡充 STM32G041/ G031/ G030 新登場」記事が、STM32マイコンマンスリー・アップデート2020年1月のP4にもあります。

LL APIかHAL API、混在?

残念ながら未提供ですが、筆者は、ACKドライバとファームウェアのAPIに興味があります。

理由は、STM32G0シリーズの高性能を引き出すには、HAL:Hardware Abstraction Layer APIよりもエキスパート向けLL:Low Layer API利用ソフトウェア開発が適すからです。

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

生産性や移植性の高いHAL APIとLL APIの混在利用は、注意が必要です(関連投稿:STM32CubeMXのLow-Layer API利用法 (2)の4章)。

ACKドライバ、ファームウェアが、LL APIかHAL APIのどちらを使っているか、または混在利用かを確認し、ノウハウを取得したかったのですが…😥。

LL API利用STM32G0xテンプレートとHAL API利用STM32Fxテンプレート

弊社は、LL API利用STM32G0x専用テンプレートと、HAL API利用STM32Fx汎用テンプレートの2種類を、それぞれ販売中です(テンプレートは同一、テンプレートを使うAPIのみが異なる)。

STM32汎用MCUラインナップ
STM32汎用MCUラインナップ(出典:STM32 Mainsterm MCUsに加筆)

もちろん、STM32G0でもHAL APIを利用することは可能です(STM32G0x専用テンプレートにもHAL API使用例添付)。LL API利用ソフトウェアは、性能を引き出す代償に対象MCU専用になります。

HAL APIとLL APIの混在は避けた方が無難で、STM32G0はLL API専用でテンプレート化しました。添付資料も、LL APIを中心に解説しています。STM32Fxテンプレート添付資料は、HAL API中心の解説です。

両テンプレートをご購入頂ければ、LL/HAL双方のAPI差が具体的に理解できます。開発するアプリケーション要求性能や発展性に応じて、LL APIかHAL APIかの選択判断も可能になります。

FYI:日本語コメント文字化け継続

STMマイコン開発環境にソースコード日本語コメントの文字化けが発生中であることを、昨年11月に投稿しました。この文字化け発生のSTM32CubeIDE v1.1.0/CubeMX v5.4.0開発環境が、STM32CubeIDE v1.2.0STM32CubeMX v5.5.0に更新されました。

更新後のSTM32CubeIDE v1.2.0/CubeMX v5.5.0でも、旧版同様に文字化けします。
一方、SW4STM32では、STM32CubeMX v5.5.0更新後も日本語コメント文字が正常表示されます。

他社の最新版EclipseベースIDE、NXPのMCUXpresso IDE v11.1.0や、CypressのPSoC Creator 4.2では、ソースコードText Font変更をしなくても文字化けはありませんので、STM特有問題だと思います。

ワールドワイドでの日本相対位置低下、今年から始まる小学校英語教育…、日本ものつくりは、英語必須になるかもしれません。



NXPマイコン開発環境更新

2019年12月20日、NXPマイコン統合開発環境のMCUXpresso IDE v11.1、SDK v2.7、Config Tools v7.0への更新ニュースが届きました。筆者は、Windows 10 1909トラブル真っ最中でしたので、更新対応が遅れ今日に至ります。本稿は、この最新開発環境更新方法と、Secure Provisioning Toolsを簡単に説明します。

NXPマイコン最新開発環境への更新方法

MCUXpresso IDEやSDKの最新版への更新方法は、前版更新方法の投稿:MCUXpresso IDE v11をLPC845 Breakout boardで試すと同じです。

MCUXpresso 4 Tools
NXPマイコン統合開発環境のMCUXpresso 4 Tools

更新方法をまとめると、

  1. MCUXpresso IDE v11.1をダウンロードしインストール(前版v11.0インストール先/ワークスペースともに別になるので、新旧IDEが共存可能)。旧版は、手動にて削除。アクティベーション手順不要。
  2. SDK Builderで旧SDK v2.6を最新版へ更新(旧SDK構築情報はNXPサイトに保存済みなので、ログインで最新版v2.7へ簡単に再構築できる)。
  3. Config Toolsは、他ツールに比べ改版数が大きい(v7.0)のですが、筆者の対象マイコン(LPCXpresso54114/812MAX/824MAX/845Breakout)では、SDKにCFGが含まれており、単独で更新することはありません。
  4. IDE/SDK/CFGの3ツールに加え、新に4番目のSEC:MCUXpresso Secure Provisioning Tool v1が加わりました。が、このSECツールは、Cortex-M7コアを用いるi.MX RT10xxクロスオーバープロセッサ用です。インストールや更新も、筆者対象マイコンでは不要です。

MCUXpresso IDE v11.1更新内容

IDE起動後、最初に表示されるWelcomeページが変わりました。

MCUXpresso IDE v11.1 Welcome Page
MCUXpresso IDE v11.1 Welcome Page

What’s Newアイコンクリックで詳細な更新内容が分かります。

目立つ更新内容をピックアップすると、ベースIDEのEclipse 4.12.0.v201906 / CDT9.8.1とGCC8-2019q3-updateへの対応に加え、ダークテーマ表示が可能になりました。

ダークテーマ利用は、Window>Preference>General>Appearance>ThemeでMCUXpresso Darkを選択し、Apply and Closeをクリックします。Dark Themeは、日本語コメントが読みづらく筆者の好みではありません。Restore Defaultsクリックで元に戻りますので、試してみてください。

マイコンテンプレートラインナップ

前稿の2020年1月のCypress PSoC 4000S/4100S/4100PSテンプレート発売で、弊社マイコンテンプレートの販売ラインナップは、下図に示すように全部で8種類(黄色)となりました。

マイコンテンプレートラインナップ2020/01
マイコンテンプレートラインナップ2020/01

2020年は、ARM Cortex-M0/M0+/M3コアに加え、Cortex-M4コアもテンプレート守備範囲にしたいと考えています。図の5MCUベンダー中、Eclipse IDEベースの最も標準的で、かつ使い易い開発環境を提供するNXPマイコン開発環境が今回更新されたのは、この構想に好都合でした。

Cortex-M7コアのi.MX RT10xxでは、初めからRTOSや高度セキュリティ対策が必須だと思います。Cortex-M4マイコンも高度なセキュリティは必要だと思いますので、SECツールの対応状況も今後注意します。

PSoC 4000S/4100S/4100PSテンプレート発売

HappyTechサイトへCypress PSoC 4000S/4100S/4100PSテンプレートページを追加しました。
PSoC 4000S/4100S/4100PSマイコンの習得、業界標準のCypress第4世代CapSenseコンポーネントを使ったタッチユーザインタフェース(UI)開発に最適なマイコンテンプレート(1,000円税込)の発売開始です。

PSoC 4000S搭載CY8CKIT-145評価ボードで動作中のCapSenseテンプレート
PSoC 4000S搭載CY8CKIT-145評価ボードで動作中のCapSenseテンプレート

PSoC 4000S/4100S/4100PSテンプレート説明資料、ダウンロード可能

PSoC 4000S/4100S/4100PSテンプレート付属説明資料の最初の3ページが、サイトよりダウンロード可能です。

PSoCプログラミングのポイントであるコンポーネント単位ソフトウェア開発を、Cypress第4世代CapSenseコンポーネントを例に具体的に学べます。

Cypress PSoCマイコンの関連テンプレートは、2016年発売:PSoC 4/PSoC 4 BLE/PRoCテンプレートに続いて第2弾目です。前回テンプレートは、一般的なMCU開発で汎用的に使うコンポーネント:液晶表示やADC、SW、BLEなどを使いテンプレート化しました。

このテンプレートご購入者様からは、どうすれば各コンポーネント情報が得られるか、コンポーネントバージョンアップへの対処方法、開発したソフトウェアの他PSoCデバイスへ移植方法など、PSoCプログラミングに関する多くのご質問やご意見を頂きました。

CapSenseコンポーネントに絞ってテンプレート化

そこで、第2弾のPSoC 4000S/4100S/4100PSテンプレートでは、評価ボードへ追加するコンポーネントをCapSenseコンポーネントのみに絞り、よりPSoCプログラミングの要点を掴み易いようにテンプレート化しました。

つまり、CapSenseコンポーネントを利用したテンプレート応用例のPSoC 4000S評価ボードを、別のPSoCデバイス:PSoC 4100S/4100PS評価ボードへ移植する手法を使って、コンポーネント単位のPSoCソフトウェア開発要点を説明しています。
※既に第1弾のPSoC 4/PSoC 4 BLE/PRoCテンプレートをお持ちの方でも、テンプレート本体以外は被る(内容重複)ことが少なく、別視点からのCypress PSoCプログラミングの特徴をご理解頂けると思います。

第4世代CapSenseコンポーネント

PSoC 4000S/4100S/4100PSファミリ内蔵の第4世代CapSenseコンポーネントは、スマホで普及したタッチユーザインタフェース(UI)の業界標準技術です。本テンプレートでCapSenseコンポーネント利用方法を習得すれば、従来の簡単な操作パネルを、より洗練されたタッチHMI:Human Machine Interfaceで実現し、他社差別化ができます。

PSoC 4000S/4100S/4100PSテンプレートで用いた評価ボードは、トランジスタ技術2019年5月号付録基板も含まれます。トラ技5月号記事は、開発環境PSoC CreatorやPSoCデバイスの特徴は良く分かりますが、記事ソースコードがダウンロードできず、実際に付録基板を簡単には動作させられないのが残念です。

本テンプレートをご利用頂ければ、トラ技付録基板でも基板上のLED点滅動作を利用したシンプルなテンプレート応用例や、CapSense動作がご理解可能です。
※トラ技付録基板に、弊社推薦評価ボード :CY8CKIT-145のCapSenseボード部分(CapSenseテンプレート動作時)とKitProgインタフェース(シンプル/CapSenseテンプレート動作時)を別途配線することで動作します。配線は、下図のようなスルーホール間接続のジャンパーワイヤが簡単です(確かハンズマンで購入しました)。

トラ技2019年5月号付録PSoC 4100S基板で動作中のシンプルテンプレートとスルーホール間接続ジャンパーワイヤ
トラ技2019年5月号付録PSoC 4100S基板で動作中のシンプルテンプレートとスルーホール間接続ジャンパーワイヤ

ブログの関連投稿検索方法

ブログ右上の検索窓に「CapSense」か「PSoC 4000S」入力または、カテゴリでPSoC/PRoCマイコンを選択すれば、PSoC 4000S/4100S/4100PSテンプレートに関するブログの関連投稿が一覧で得られます。テンプレート説明資料と、合わせてご覧いただければ、PSoC 4000S/4100S/4100PS マイコンやCapSenseコンポーネントがより解り易くなると思います。

PSoC 4000S/4100S/4100PSテンプレートのご購入をお待ちしております。

モダンPCとPINコード

本稿が2019年最後の投稿です。

前稿Windows 10 2PCトラブルにもめげず、2020年1月6日発売のCypress PSoC CapSenseテンプレートに向けて急ピッチで開発を進めてます。本稿は、Windows 10トラブルで気になったモダンPCと、公開鍵暗号方式PINコードを紹介します。

モダンPC

創造性と生産性を上げるのがモダンPCで、Windows 10とOffice 365がその要素のようです。

Windows 7サポート終了2020年1月14日を前に、MicrosoftはモダンPCへの移行を呼びかけています(Windows 7稼働予測グラフ有り)。今でもネットカフェで稼働中の多くのWindows 7 PCは、果たして安定性・メンテナンス性に問題あるモダンPCへ移行するのでしょうか?

Windows 7並みの信頼性が無ければ、宣伝文句は良くてもPCのOSとしては、どうかな?と個人的には思います。
2023年までのWindows 7有償再延長サポートも選択肢としてあるので、7を使い続け、開発者よりも一般エンドユーザを重視する次期Windows Xに期待する声も少なくないかもしれません。

筆者は最新OSの最重要機能は、セキュリティだと思います。

OS最重要機能はセキュリティ(出典:Pixabay)
OS最重要機能はセキュリティ(出典:Pixabay)

Windows 10付属セキュリティツールだけで安心しているエンドユーザが、どれ程いるかは解りません。しかし、多くのネットカフェが設定するWindows 7+市販セキュリティソフトとのOSセキュリティ能力差が、どれ程あるかも不明です。

2020年以降のWindows 7稼働予測と、モダンPCへの移行状況が、Microsoftの思惑通りになるか気になります。

PINコード

Windows 10インストールで新たに要求されるPIN(Personal Identification Number)コードは、個人識別番号のことです。普通、数字4桁です。

PINコードは、IDとパスワードの代わりに登場してきたセキュリティ用語で、筆者の理解では、PINコードが公開鍵暗号方式、パスワードは秘密鍵暗号方式です。PINコードとパスワードの解り易い違いは、コチラのP1図です。

通信中の鍵が公開鍵なので、秘密鍵パスワードよりも安全で、公開鍵とペアの秘密鍵は、デバイス(Windows 10/MCUなど)内部保存、開発コストや運用コストが低く、強固なセキュリティが実現できるそうです。ペア秘密鍵がデバイス内なので、なりすまし対策にもなります。

PIN、FIDO(ファイドと読む)で検索すると様々な情報が得られます。iPhoneは少し違うようですが、AndroidスマホではPINコードが標準になりつつあるようです。

筆者のWindows 10は、前投稿トラブル回復直後のため、テンプレート開発以外は、今のところあまり手出し(調査)したくない心境です。簡単、安心、低コスト、セキュリティ強固なPINコードなら、MCUへも実装できるかもしれません。

…以上のように今年最後の本稿は、あいまいな推量となりました。
安心してPCが使えるまでは、最高プライオリティ:CapSenseテンプレート開発を優先したいからです。すいません😌。

本年も本ブログをご覧いただき、まことにありがとうございました。
皆さま、よいお年をお迎えください(Ladies and gentlemen, I wish you a happy New Year)。

Windows 10 1909トラブル回復録

年末年始の忙しい時に限って自作Windows PCにトラブルが発生するのは、日頃の行い、またはマーフィーの法則?

Backup PC(Windows 10 1903)のWindows 10 1909アップデートトラブルに続き、Main PC(Windows 10 1909)にもWindows起動トラブルが発生しました。Backup PCトラブルは、暫く様子見でも良いと考えていましたが、Main PC起動トラブルは、即回復が必要です。

Windows 10トラブル内容

Backup PCは、Windows 10 1903から1909への更新プログラムインストールに失敗するトラブルです(0x800F0922)。1903からの新機能追加も少ない1909への更新は、Backup PCのため急ぐ必要はありません。この更新失敗トラブルは少なくないようで、ネットに多くのトラブル対策があります。更新プログラム直接インストール、クリーンブードも既に試しましたが回復しません。

Main PCは、突然起動NGになりました。きっかけは、複数アプリケーション更新と更新履歴消去です。Boot起因ですので、自動修復やコマンドプロンプト手動修復も試しましたが回復しません。唯一の救いは、1909更新成功直後のシステムバックアップがあることです。

トラブル回復策

Main PCは、11月14日の1909更新直後のシステムリカバリで回復しました。但し、今回の起動トラブル発生までの約1か月間のユーザデータ更新とアプリケーションソフト更新が必要で、このために半日がつぶれます。また、Backup PCは、その症状から「最後の切り札」:1909クリーンインストールが必要かな?と感じていました。

そこで、Main PCでつぶれる半日で並列にBackup PCをクリーンインストールしようと決心した訳です。Main PCのアプリケーション更新時、Backup PCへのインストール必須アプリケーションも明確になります。退屈な回復作業ですが、PCの前から離れる訳にもいきません。2PC同時に回復することで、効率向上も狙えるかなと考えました。

トラブル回復作業と時間

ネットに溢れる回復作業内容よりも、作業に要した時間を示します。

もちろんPC性能やネットワーク環境で分単位精度は変わるでしょう。半年毎に繰返されるWindows 10更新トラブル対応の目安と考えてください。作業時間は、2PC回復トータルで丸1日程度です。が、精神的ダメージはかなりあります。Windows10更新トラブルがこのまま続くなら、Mac PCへの乗換を検討する程のダメージです。

Backup PC Windows 10 1909クリーンインストール作業時間

  1. Windows 1909クリーンインストール:10分(Microsoftアカウントに加え、新たにPINコード入力要求)
  2. クリーンインストール後のセットアップ:5分(OSセキュリティ内容などを設定)
  3. セットアップ後の更新プログラム適用:40分

最新Windows 10 1909クリーンインストール自体は、上記1時間程で完了します。これなら、毎回クリーンインストールしても良いと思える程簡単です。が、この後のアプリケーションインストール、ユーザデータ復活に時間が掛かります。

  1. セキュリティソフト、ブラウザ、FFFTP、圧縮解凍などOS必須ツールインストール:1時間
  2. Officeアプリケーションインストールと更新プログラム適用:3時間
  3. ベンダMCU開発ツールインストール:1時間
  4. ユーザデータ復活:1時間(クラウドストレージ経由ではなく回復Main PCより直接コピー)

合計で7時間~8時間(=丸一日)は、モニタ前で待たされます。並列で行ったMain PC回復作業も、システムリカバリと1か月間のユーザデータ復活で3時間程度です。Office(2010)アプリケーションインストールと更新は、LibreOfficeに比べ時間が掛かります。新しいOffice 2019/2016でも、同様に時間が掛かると思います。

※アプリケーションとユーザデータを引継いだままWindows 10 1909上書きインストールも可能です。しかし、Backup PCは、この上書きインストール(1.5時間)も失敗しました。更新プログラム直接インストール、クリーンブードと同様、「最後の切り札」より前の回復手段は、経験上あてになりません😫。

いろいろある回復手段を試して消費する合計時間と、「最後の切り札」で一発回復する上記8時間のどちらを選ぶかは、トラブル種類と回復作業内容・処理時間、個人の性格に依存します。本稿が参考になれば幸いです。

ビジネスPC要件

今回のトラブルで、筆者のWindows PCには、Mac PCへの乗換を妨げる利用アプリケーションは無いことが明確になりました。利用アプリケーション全てMac OS対応、または同等アプリケーションが有ります。

ビスネスPCのOSは?
信頼性重視ビスネスPCのOSはWindows、Mac、Unixのどれが良いか?

Mac PCの方が高性能なのでWindows PCより高価です。従って、このMac PC対Windows PC差額を払う分だけの信頼性が得られるか、費用対効果が乗換課題です(もちろん、経済的余裕と自作PCの楽しさが消えるのもありますが…)。

Backup PC、Main PCともに自作Windows PCですが、今回のようなOS起因トラブル無しで何年も動作し続けたPCです。ネットを見ると、Backup PCと同じ更新トラブルは、2019年最新WindowsノートPCでも発生しているようです。

以前のOS、特にWindows 7に比べ世間を騒がせるWindows 10更新トラブルは、Windows 10完成度・信頼性が低いとエンドユーザに感じさせるだけでなく、Microsoftの狙いは、OS更新毎に毎回Windowsをクリーンインストールさせ、アプリケーション本体は、Office 365のようにクラウド提供することが目的なのでは、という疑いを生じさせます。
OSクリーンインストールが短時間で簡単に終わり、OfficeアプリケーションのローカルPCインストールと更新にやたら時間が掛かることが根拠です。

ビジネスで使うPCは、Mac PC(Unixも含む)への乗換を考えるべき時期かもしれません。今後、Mac PC/OSのトラブルや回復方法も調べたいです。

ARM MCU変化の背景

昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章:Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者:大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

  1. ハイエンドMCU動作周波数高速化、マルチコア化
  2. RTOS普及
  3. セキュリティ対応
  4. RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1.ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI:Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2.RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3.セキュリティ対応

PAS:Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やM4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4.RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも?

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS(先進運転支援システム)が引っ張る車載MCU+NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM:Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が(無く!?)少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。

MCUプロトタイプ開発のEMS対策とWDT

ノイズや静電気によるMCU誤動作に関する興味深い記事がEDN Japanに連載されました。

どのノイズ対策が最も効果的か? EMS対策を比較【準備編】、2019年10月30日
最も効果的なノイズ対策判明!  EMS対策を比較【実験編】、2019年11月29日

EMS:(ElectroMagnetic Susceptibility:電磁耐性)とは、ノイズが多い環境でも製品が正常に動作する能力です。

MCUプロトタイプ開発時にも利用すべきEMS対策が掲載されていますので、本稿でまとめます。また、ノイズや静電気によるMCU誤動作を防ぐ手段としてWDT:Watch Dog Timerも説明します。

実験方法と評価結果

記事は、インパルスノイズシュミレータで生成したノイズを、EMS対策有り/無しのMCU実験ボードに加え、LED点滅動作の異常を目視確認し、その時点のノイズレベルでEMS対策効果を評価します。

評価結果が、11月29日記事の図5に示されています。

結果から、費用対効果が最も高いEMS対策は、MCU実験ボードの入力線をなるべく短く撚線にすることです。EMS対策用のコンデンサやチョークコイルは、仕様やパーツ選定で効果が左右されると注意しています。

MCUプロトタイプ開発時のお勧めEMS対策

MCUプロトタイプ開発は、ベンダ提供のMCU評価ボードに、各種センサ・SWなどの入力、LCD・LEDなどの出力を追加し、制御ソフトウェアを開発します。入出力の追加は、Arduinoなどのコネクタ経由と配線の場合があります。言わばバラック建て評価システムなので、ノイズや静電気に対して敏感です。

このMCUプロトタイプ開発時のお勧めEMS対策が下記です。

1.配線で接続する場合は、特に入力信号/GNDのペア線を、手でねじり撚線化(Twisted pair)だけで高いEMS効果があります。

身近な例はLANケーブルで、色付き信号線と白色GNDの4組Twisted pairが束ねられています。このTwisted pairのおかげで、様々な外来ノイズを防ぎLANの信号伝達ができる訳です。

信号とGNDの4組Twisted pairを束ねノイズ対策をするLANケーブル
信号とGNDの4組Twisted pairを束ねノイズ対策をするLANケーブル

2.センサからのアナログ入力信号には、ソフトウェアによる平均化でノイズ対策ができます。

アナログ信号には、ノイズが含まれています。MCU内蔵ADCでアナログ信号をデジタル化、複数回のADC平均値を計算すればノイズ成分はキャンセルできます。平均回数やADC周期を検討する時、入力アナログ信号が撚線と平行線では、2倍以上(図5の2.54倍より)のノイズ差が生じるので重要なファクターです。従って、撚線で検討しましょう。
平均回数やADC周期は、パラメタ設定できるソフトウェア作りがお勧めです。

3.SWからの入力には、チャタリング対策が必須です。数ミリ秒周期でSW入力をスキャンし、複数回の入力一致でSW値とするなどをお勧めします。
※弊社販売中のMCUテンプレートには、上記ADCとSWのEMS対策を組込み済みです。

4.EMS対策のコンデンサやチョークコイルなどの受動部品パーツ選定には、ベンダ評価ボードの部品表(BOM:Bill Of Matrix)が役立ちます。BOMには、動作実績と信頼性がある部品メーカー名、型番、仕様が記載されています。

ベンダMCU評価ボードは、開発ノウハウ満載でMCUハードウェア開発の手本(=ソフトウェアで言えばサンプルコード)です。

特に、新発売MCUをプロトタイプ開発に使う場合や、MCU電源入力ピンとコンデンサの物理配置は、BOM利用に加え、部品配置やパターン設計も、MCU評価ボードを参考書として活用することをお勧めします。
※PCB設計に役立つ評価ボードデザイン資料は、ベンダサイトに公開されています。

MCU誤動作防止の最終手段WDT

EMS対策は、誤動作の予防対策です。EMS対策をしても残念ながら発生するノイズや静電気によるMCU誤動作は、システムレベルで防ぐ必要があります。その手段が、MCU内蔵WDTです。

WDTは、ソフトウェアで起動とリセットのみが可能な、いわば時限爆弾です。WDTを一旦起動すると、ソフトウェアで定期的にリセットしない限りハードウェアがシステムリセットを発生します。従って、ソフトウェアも再起動になります。

時限爆弾を爆発(=システムリセット)させないためには、ソフトウェアは、WDTをリセットし続ける必要があります。つまり、定期的なWDTリセットが、ソフトウェアの正常動作状態なのです。

ノイズや静電気でMCU動作停止、または処理位置が異常になった時は、この定期WDTリセットが無くなるため、時限爆弾が爆発、少なくとも異常状態継続からは復帰できます。

このようにWDTはMCU誤動作を防ぐ最後の安全対策です。重要機能ですので、プロトタイプ開発でもWDTを実装し、動作確認も行いましょう。

※デバッグ中でもWDTは動作します。デバッグ時にWDT起動を止めるのを忘れると、ブレークポイントで停止後、システムリセットが発生するのでデバッグになりません。注意しましょう!

PSoC Creatorでデバイスファミリが見つからない時の対処

Cypress PSoC Creatorで、開発デバイスファミリが見つからない時の対処方法を示します。

No Target PSoC Family
No Target PSoC Family

開発デバイスファミリがDevice familyリストに無い!?

PSoC 4100PSファミリ評価ボード:CY8CKIT-147を入手、評価ボード付属サンプルコードをPSoC Creator 4.2(以下、Creator)にインポートするためFind Code Exampleをクリックしましたが、対象MCUファミリのPSoC 4100PSがDevice familyリストに見当たりません。

このリストに対象MCUファミリが無い時は、新規プロジェクト作成やサンプルコードインポートができないため、Creatorが全く使えません。お手上げ状態です。

※CY8CKIT-147は、CapSenseテンプレート開発用にトラ技懸賞で当選した評価ボード(前回投稿参照)です。

PSoC Creator対処

CreatorのToolsタブからFind new devicesをクリックします。Device Update Installerダイアログが表示されますので、Installをクリックし完了を待ちます。

PSoC CreatorのFind new devices
PSoC CreatorのFind new devices

Creator再起動でDevice familyリストへ最新MCUファミリが追加されます。勿論、PSoC 4100PSもDevice familyリストにありますので、CreatorでCY8CKIT-147プロジェクト作成ができ開発可能となります。

例としてPSoC 4100PSファミリで説明しましたが、他のデバイスファミリがDevice familyリストに無い場合も同様に解決できます。

Update ManagerはDevice familyリスト更新ができない

Cypress Update Managerは、PSoC Creatorなども含めたインストール済みCypress MCU開発環境の更新状況をチェックし、更新や削除が簡単にできる優れたツールです。Creatorと同時にインストールされます。

Update Managerは、自動で起動し目立つのでご存じの方は多いと思います。しかし、前章で示したCreatorが扱うDevice familyリスト更新はUpdate Managerではできません。Creator 4.2を長く使っている方ほど、Find new devicesを忘れがちですので注意してください。

Creatorが扱うコンポーネントの場合は、同じことは起こりません。理由は、Creatorでプロジェクトを開いた時、右下に黄色の!アイコンが表示されるからです。この!アイコンをクリックすると、プロジェクトで使用中のコンポーネントが最新版へ更新されます。

PSoC CreatorのNew Compornents are available表示
PSoC CreatorのNew Compornents are available時の!アイコン表示

但し、コンポーネント更新は、アプリケーションに対して動作リスクが伴います。更新前プロジェクトArchive作成も忘れずに行いましょう(関連投稿:STM32CubeIDE v1.1.0更新と文字化け対策(その2)の2~3章)。

PSoCプログラミング要点

PSoCプログラミングは、デバイス内蔵コンポーネントのAPI操作です。従って、コンポーネント単位のプログラミングとその開発経験の積重ね/載せ替えが可能です。

想定アプリケーションに必要となる複数コンポーネントをパッケージしたものが、各種デバイスファミリで、Creatorインストール時の図がこれらを示しています。

PSoC Programmingのポイント
PSoC Programmingのポイントは、コンポーネント単位の開発経験の積重ね、デバイス載せ替えが可能なこと。

CreatorのGUIで、コンポーネント更新が新デバイスファミリ追加よりプライオリティが高いのも、コンポーネントプログラミングが理由だと筆者は思います。

多くのPSoCコンポーネントの中でCapSenseにハイライトしたのが開発中CapSenseテンプレートで、動作確認ファミリはPSoC 4000S/4100S/4100PSです。但し、同じ第4世代CapSenseコンポーネント内蔵のPSoC 6などへも流用や応用が簡単にできます。

PSoC Creator 4.3 Beta版リリース

2019年10月31日、新たにPSoC 4500ファミリをサポートするPSoC Creator 4.3 Bate版がリリースされました。PSoC 4500ファミリは、二つの独立したSAR ADCと5個までのOpamp/Comparatorブロックを持つアナログ周辺回路が豊富なデバイスファミリです。

Creatorが4.3へ正式更新された時には、同時にDevice familyリストも最新版へ更新されると思います。Creator 4.2が長く使われた結果、今回のようなデバイスファミリが見つからない事象が発生したと言えます。

同じファミリでも新デバイスが毎年追加されます。半年に一度程度は、CreatorのFind new devicesをクリックすることをお勧めします。

マイコン選択方法2019

MCU:マイコンは、種類が多くどれを自分の開発や製品に使うのが最適か?分りにくいと言われます。この問いに対する回答を示します。具体例として今年5月トランジスタ技術で紹介されたCypress PSoC 4シリーズのMCUを選択します。他ベンダでも同様です。

MCU選択とスマホ選択の差

毎年新機種が発表されるスマートフォン。特にAndroidスマホは、電話の基本機能は同じでも、カメラなどの付加機能やサービス、価格帯が広く、選択に迷います。それでも、何年かスマホを使っていると、どの機能が自分に必須かが分かってくるのと懐具合との兼ね合い、また、古い機種は数年でカタログから消えるので、スマホ選択幅は収束します。

ところが、MCUの場合は、発表後10年以上販売継続されます。スマホとの一番の差です。
古い選択肢も残ったまま新製品が追加され、選択幅が時間とともに広がるのがMCU選択を困難にする要因の1つです。

そこで、広い選択幅からMCUを選ぶ方法を、4段階で示します。

第1段階:適用製品による大枠選択

MCUベンダは、適用製品に合わせてMCUを大分類します。車載とインダストリアル分野では使用温度や内蔵周辺回路などの要件が異なるからです。そこで、第1段階は、この適用製品でMCUを選択します。

例えば、NXPSTマイクロエレクトロニクストップサイトの“アプリケーションタブ”がこの大枠を示します。
ルネサスエレクトロニクスCypressの場合は、“ソリューションタブ”です。

ここまでは、多くの方がご存じと思います。分かりにくくなるのは、ココカラです。

第2段階:MCU名称による中枠選択

同じインダストリアル分野のMCUでも、シリーズやファミリなど細かく名称が分かれています。名称が異なるには訳があるので、その理由を理解するのが、第2段階です。この段階では、ベンダ間の買収や合併などの歴史も知っている方が良いです。ポイントは、選択の決め手となる最新カタログの取得です。

Cypressのスマートアプリケーション分野のMCUで説明します。

スマートアプリケーション分野MCU使用例(出典:Cypressサイト)
スマートアプリケーション分野MCU使用例(出典:Cypressサイト)

PSoC 6/4/FM4などの複数MCUから構成されるスマート洗濯機です。PSoC X(X=4,6)は、元々のCypress MCUの名称で、FM4は、2014年に合併した米Spansion(実はSpansionに買収された富士通セミコンダクター)のMCU名称です。

Cypressは、Spansion合併でARM Cortex-M0+ライセンスを取得し、Cortex-M0利用のPSoC 4に適用、その結果生まれた新製品がPSoC 4Sです。PSoC 4Sは、特許取得済み静電容量式第4世代タッチセンサCapSense内蔵のPSoC 4000ファミリへと発展しました。

PSoC 4サイトトップページへ行き製品タブを見ると、さらに細かくPSoC 4000/4100/4200/4700とファミリが分類されており付加機能も異なります。この中枠の段階で製品セレクターガイドなどへ行くとMCU選択に迷ってしまします。他のベンダでも同様です。

この中枠MCU選択の重要資料:Brochureをダウンロードします。Brochureとは、製品パンフレット、カタログのことで、ほぼ毎年更新されます。

どのベンダでも、この中枠MCUを対象とした製品カタログがあります。この最新カタログを見つけるのがMCU選択での最重要事項です。

第3段階:最新カタログと評価ボードによる開発MCU選択

製品カタログには、ベンダがアピールしたい最新MCU情報が詳しく掲載されます。継続販売中の古いMCUや歴史は(紙面の都合上)無視されます。但し、これで新旧MCUを選択のふるいにかけることができます。

世間の話題にはなりにくいMCUの発展速度も、スマホやPC並みに早いのです。最新MCUは、低電力動作や処理効率に優れ、市場ニーズに即した開発が期待できます。

製品カタログには、中枠に相当するMCUファミリ一名称や概略を示す一覧図が掲載されます。

PSoC 4の場合は、下図です。ファミリ名の差(=意味)をこの図から理解すれば、開発MCU選択は、殆ど(?!)最終段階です。

PSoC 4ファミリ一覧図(出典:PSoC 4 Brochure)
PSoC 4ファミリ一覧図(出典:PSoC 4 Brochure)

殆どとは、例えば、エントリーレベル灰色の四角:PSoC 4000SファミリにもFlashやROM、内蔵周辺回路数により多くのMCUがあります。つまり、開発に適すMCUを各四角の中から選択する必要がある訳です。

これには、ファミリ毎にベンダが用意する評価ボード搭載MCUが適します。カタログにも評価ボードが記載されています。

ファミリ毎に用意される評価ボード(出典:PSoC 4 Brochure)
ファミリ毎に用意される評価ボード(出典:PSoC 4 Brochure)

評価ボード搭載MCUは、ファミリ内で最も標準的かつ応用範囲が広く、しかもサンプルコードが付いていますので、MCUを直に動作させることができます。低価格で入手性が良いのも特徴です。開発着手のMCUとしては最適です。

第4段階:プロトタイプ開発による製品MCU選択

評価ボードのMCUを基準にプロトタイプ開発を行い、製品化時のMCU選択をします。

プロトタイプMCUでFlash/RAM不足が懸念されならより大容量MCU、性能不足や周辺回路数不足が懸念されるならより高性能MCUを製品MCUとして選択するなどです。プロトタイプ開発により、製品MCU評価が高精度でできます。

以上の4段階で開発や製品に適すMCU選択ができます。プロトタイプ開発結果をどう活かすかで最適な製品MCU選択ができます。

Cypress PSoC 4 MCU選択具体例

弊社開発中のCapSenseテンプレートに用いるCypress PSoC 4 MCUを、上記の方法で選択した結果を示します。

CapSense は、PSoC 4000ファミリの他社差別化機能の1つです。そこで、このCapSenseを活かすプロトタイプ開発テンプレートを目指します。

CapSenseテンプレートに用いる3ファミリMCU:PSoC 4000S、PSoC 4100S、PSoC 4100PSの特徴を一覧で示します(縦長の図がウェブでは上手く表示できます)。

CapSenseテンプレート対象3MCUファミリ比較
CapSenseテンプレート対象3MCUファミリ比較

PSoC 4000S評価ボード:CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit搭載MCUは、CY8C4045AZI-S413(48ピン)です(下図左)。

PSoC 4100S評価ボード:CY8CKIT-041-41XX PSoC 4100S CapSense Pioneer Kit搭載MCUは、CY8C4146AZI-S433(48ピン)です。トラ技5月号付録PSoC 4100S基板実装のCY8C4146LQI-S433(40ピン)も同じファミリですが、ピン数のみが違います(下図中央)。

PSoC 4100PS評価ボード:CY8CKIT-147 Prototyping Kit搭載MCUは、CY8C4145LQI-PS433(48ピン)です(下図右)。

Cypressの3ファミリ評価ボードは、どれも48ピンで揃っているので、比較しやすいでのすが、弊社は、予算の都合上、PSoC 4100Sファミリは、トラ技付録PSoC 4100S基板実装MCU(40ピン)を用います。

CapSenseテンプレート評価ボードMCU(PSoC 4000S評価ボード、トラ技5月付録PSoC 4100S基板、PSoC 4100PS評価ボード)
CapSenseテンプレート評価ボードMCU(PSoC 4000S評価ボード、トラ技5月付録PSoC 4100S基板、PSoC 4100PS評価ボード)

CapSenseで最重要なタッチUIハードウェアは、PSoC 4000S評価ボードのCapSense基板を、PSoC4100S/4100PS各基板と接続してテンプレート動作確認をします。PSoC 4000S → PSoC 4100SでFlash/RAM容量増加、PSoC 4000S → PSoC 4100PSでアナログフロントエンド強化などへ発展します。

※CapSenseテンプレート完成は、計画当初は2019Q3でした。しかし、PSoC 4100PS評価ボードは、トラ技懸賞品をあてにしており、運よく当選し11月Mに当選品が入手できました。2019Eを目途にテンプレート完成の予定です。

SW4STM32アプリケーションのSTM32CubeIDE移設

SW4STM32で開発した2017年9月発売STM32Fxテンプレートと2019年6月発売STM32G0xテンプレートを、STM32MCU最新統合開発環境STM32CubeIDE v1.1.0へ移設しました。

移設は成功し、STマイクロエレクトロニクス最新統合開発環境:STM32CubeIDE v1.1.0(以下、CubeIDE)、STM32CubeMX v5.4.0(以下、CubeMX)、最新ファームウェアと弊社テンプレートを使って、効率的で最新のSTM32MCUプロトタイプ開発、アプリケーション開発ができます。

本稿は、STM32CubeIDE v1.1.0更新と文字化け対策投稿(その1)、(その2)のその3に相当します。説明が重複する箇所は、リンク先を参照してください。

移設成功結果

G0AdcTemplateのSTM32CubeIDE移設成功結果
G0AdcTemplateのSTM32CubeIDE移設成功結果

STM32Fxテンプレートは「ひと手間」、STM32G0xテンプレートは「そのまま」で最新統合開発環境へ移設でき、評価ボードにてテンプレート動作を確認しました。G0AdcTemplateのCubeIDE移設後と評価ボード動作例です。

既にSTM32Fx/G0xテンプレートご購入者様は、本稿の方法で最新STマイクロエレクトロニクス開発環境へ乗換えることができます。

※現状のCubeMX v5.4.0でコード生成後、CubeIDE v1.1.0の日本語コメントは文字化けしますので注意してください(詳細は、投稿その2参照)。

最新開発環境ファームウェアとアプリケーション開発時ファームウェア

最新開発環境ファームウェアとテンプレート開発時ファームウェア
最新開発環境ファームウェアとテンプレート開発時ファームウェア

投稿その2で示したように、MCU開発ソフトウェア(=アプリケーション)に最も影響を与えるのは、ファームウェア更新です。

STM32FxテンプレートのF0用ファームウェアFW_F0は、開発当時のv1.8.0からv1.11.0へ、F1用ファームウェアはv1.4.0からv1.8.0へ、G0用ファームウェアFW_G0はv1.2.0からv1.3.0へそれぞれ更新されています。
※STM32G4テンプレートは、これから開発着手しますので最新のv.1.1.0のままです。

次章3から5章までを使って、STM32F1テンプレート:F1BaseboardTemplateを例に、当時の開発環境から最新開発環境への移設作業、ファームウェア変更、トラブルシューティングを「詳細に説明」します。但し、結果として行う処理は、6章まとめに示す簡単なものです。途中の章は読み飛ばしても構いません。

開発済みMCUアプリケーションを暫くたってから更新、または本稿のようにIDE自体が変わり最新開発環境へ移設することはよくあります。F1BaseboardTemplateをお持ちでない方も、(手前みそですが)次章から5章の内容は参考になると思います。

ファームウェア更新でコンパイルエラー発生:3章

先ず、ファームウェア起因のコンパイルエラーが発生するまでを示します。

1.SW4STM32で開発したF1BaseboardTemplateプロジェクトをCubeIDEへインポートします(インポート方法は、投稿その1-3章参照)。インポートソースコードの日本語コメントに文字化けが発生しますので、その1で示したShift-JISからUTF-8へのエンコード変換で解決します。

2.インポート済みのCubeMXプロジェクトファイルを、CubeIDEプラグイン版CubeMXで開き、Project Managerタブをクリックし、Toolchain/IDEがSTM32CubeIDEであることを確認します。インポートIDE変換が成功していれば、SW4STM32から自動的にSTM32CubeIDEへ変わっているハズです。

SW4STM32プロジェクトインポート後、プラグイン版STM32CubeMXで開いたプロジェクトファイル
SW4STM32プロジェクトインポート後、プラグイン版STM32CubeMXで開いたプロジェクトファイル

ファームウェアは、最新版STM32Cube FW_F1 V1.8.0になっています。そのままProject>Generate Codeをクリックし、コード生成を実行します。

3.CubeIDEへ戻ると、(デフォルトの自動コンパイル設定だと)Lcd.cなど数か所に赤下線のコンパイルエラーが発生します。

ファームウェア起因のコンパイルエラー(赤下線)
ファームウェア起因のコンパイルエラー(赤下線)

例えば、L236のLCD_EN_Pinは、CubeMXでGPIO_PIN_8をUser Label付けしたものです。LCD_EN_Pinへカーソルを持っていき、F3をクリックすると、定義ファイルmain.hのL103へ飛び、User Label付けは問題ないことが判ります。この段階では、コンパイルエラー原因は不明です。

4.コンパイルエラーがファームウェア起因かを確認するため、ファームウェアだけをFW_F1 V1.8.0からF1BaseboardTemplate 開発当時のFW_F1 V1.4.0へ戻します。但し、CubeIDE「プラグイン版CubeMX」は、ファームウェアを旧版へ戻す機能がありません。そこで、「スタンドアロン版CubeMX」を使ってファームウェアをFW_F1 V1.4.0へ戻し、再度コード生成を行うと、コンパイルエラーは発生しません。
※スタンドアロン版CubeMXでファームウェアを元の版数へ戻す方法は、4章で説明します。

以上の作業で、コンパイルエラー原因は、ファームウェア起因であることが判りました。

STM32CubeMXコード生成ファームウェア変更方法:4章

トラブルシューティングの前に、CubeMXでコード生成ファームウェア版数を変える方法を示します。CubeMXは、旧版ファームウェアをRepositoryフォルダへ自動保存し、いつでも旧版へ戻せる準備をしています。

1.スタンドアロン版CubeMXのProject Managerクリックで表示されるダイアログ一番下のUse Default Firmware Locationの☑を外し、BrowseクリックでRepositoryフォルダ内の旧版ファームウェア:STM32Cube_FW_V1.4.0を選択します。

スタンドアロン版STM32CubeMXでファームウェア版数を変える方法
スタンドアロン版STM32CubeMXでファームウェア版数を変える方法

2.そのままCubeMXでコード生成を実行すると、ファームウェア版数のみを変えたソースコードが生成されます。

※CubeIDEプラグイン版CubeMX(2つ前の図)は、Use Default Firmware Location自体有りません。つまり、最新ファームウェアでのみコード生成が可能です。
※CubeMXのGenerate Reportは、コード生成時の各種パラメタをPDF形式で出力する優れた機能です。しかし、肝心のコード生成ファームウェア版数が現状では出力されません。PDF出力へ手動で使用ファームウェア版数を追記することをお勧めします。

トラブルシューティング:5章

3章コンパイルエラー発生後、つまり最新ファームウェアFW_F1 V1.8.0でのコード生成後からトラブルシューティングします。

1.CubeIDEのエラーメッセージは、Symbol ‘LCD_EN_Pin’ could not be resolvedです。main.hで定義済みなので、なぜresolveできないのか不可解です。

2.そこで、Lcd.cの#include関連を見ると、#include “UserDefine.h”はあります。
※弊社テンプレートは、UserDefine.hでツール生成以外の全てのユーザ追加定義を記述し、全ソースファイルへincludeする方式を用いています。
※一方、CubeIDEは、CubeMXで生成するmain.cソースファイル1つへ、全ての制御を記述する方式を用いています。小規模なサンプルプロジェクトなどでは、解り易い方法です。
※但し、規模が大きくなると、ソースファイルを機能毎に分離し、ファイル単位の流用性やメンテナンス性を上げたくなり、弊社は、このファイル分離方法をテンプレートに採用中です。

3.UserDefine.hに、#include “main.h”の1行を追加します。

UserDefine.hへ#include "main.h" 追加
UserDefine.hへ#include “main.h” 追加

4.Clear Project後、Build Projectでコンパイルエラーは解消し、コンパイル成功します。評価ボード:STM32F103RBでF1BaseboardTemplate の最新開発環境での正常動作確認ができます。

最新ファームウェアは、全てのユーザ追加ソースファイルに、#include “main.h”が必須なことがトラブル原因でした。

最新開発環境への移設まとめ:6章

2017年9月にSW4STM32で開発完了したSTM32Fxテンプレートは、UserDefine.hに、#include “main.h”追記で、2019年11月STM32MCU最新開発環境:STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_F1 V1.8.0/FW_F0 V1.11.0へ移設できます。

2019年6月にSW4STM32で開発完了したSTM32G0xテンプレートは、なにもせずに、2019年11月最新開発環境:STM32CubeIDE v1.1.0、STM32CubeMX v5.4.0、STM32Cube FW_G0 V1.3.0へ移設できます。
※STM32G0xテンプレートは、初めからUserDefine.hに、#include main.hが追記済みです。

Build Analyzer

SW4STM32からCubeIDEへ移設後、最初に目に付くIDE画面の差分は、ビルド成功時、右下表示のBuild Analyzerだと思います。

STM32CubeIDEのBuild Analyzer
STM32CubeIDEのBuild Analyzer

最初の図で示したG0AdcTemplate移設後のCubeIDE Build Analyzerを示します。RAM、FLASH使用率が一目で解ります。その他のIDE画面や操作は、旧SW4STM32と殆ど同じです。

Serial Console

CubeIDEは、Serial Console画面を持っています。従来環境では別途必要であったVirtual COM Port (VCP)用のTera Termなどのツールが不要となり、IDEだけでVCP入出力が確認できます。高まるVCP重要性が最新IDEへ反映されたと思います(関連投稿:STLINK-V3の4章)。

但し、バックグラウンドが、Tera Termの黒からSerial Console画面では白になったため、テンプレートで用いたVCP出力文字色を、デフォルトの白から黒へ変更した方が見易いです。この色変更後のSerial Consoleが下図右側です。

TeraTerm画面とSTM32CubeIDEのSerial Console画面
TeraTerm画面とSTM32CubeIDEのSerial Console画面

最新開発環境移設の課題と対策、テンプレート改版予定

現状のCubeIDE v1.1.0は、コード生成後、日本語コメントに文字化けが発生します。また、エディタタブ幅が2のまま変更できません。これら以外にも細かな不具合があります。このままでは、筆者には使いにくいIDEです。一方、Build AnalyzerやSerial Consoleは、とても役立ちます。
CubeIDEプラグイン版CubeMX v5.4.0は、Repository旧ファームウェアへの変更機能が無く、最新ファームウェアのみ利用可能です。

これら移設課題に対して、投稿その1から本稿で対策を示しました。

現状は、従来SW4STM32からCubeIDEへの「IDE移設過渡期」です。筆者は暫く両IDEを併用するつもりです。そして、新環境の使いにくい箇所が解消された時点でCubeIDEへ完全移設し、同時に汎用MCU第2位、シェア20%超のSTM32MCU向けテンプレートとしてSTM32FxテンプレートとSTM32G0xテンプレートを、本稿変更などを加え最新開発環境対応へ全面改版する予定です。

既に弊社テンプレートをお持ちの方や全面改版を待てない方は、まとめ6章の方法で移設可能です。但し、投稿その2で示した多くのリスクがありますのでお勧めはしません、自己責任で行ってください。

なお、新開発のSTM32G4テンプレートは、初めから最新CubeIDE、CubeMXで開発着手します。

*  *  *

STマイクロエレクトロニクスのSTM32CubeIDE v1.1.0改版により、旧SW4STM32開発アプリケーションを新環境へ移設する連続3回の投稿、いかがでしたでしょうか? 詳細説明がリンク先となり、筆者にしては長文投稿でしたので、解りづらかったかもしれません😌。

IoTによりMCU開発環境は、より急ピッチで変わります。最新デバイスと最新API利用が、その時点で最も効率的で優れたMCUアプリケーション開発手段です。環境急変にも柔軟対応できる開発者が求められます。

最新開発環境に上記のような課題が多少あっても、従来SW4STM32開発済みアプリケーションの最新STM32CubeIDE移設は、6章で示した1行追記のみで成功しました。

但し、顧客や管理者の方には、開発環境更新、移設の危うさや開発者の心理的負担、何よりもそれらへの対応時間は、あまり表に出てこない部分、また移設してみて初めて判る部分で理解されづらいものです。

本稿がMCUアプリケーション顧客、管理者、開発者の方々のご参考になれば幸いです。

P.S:2019年11月12日、2か月遅れでWindows 10 1909配布が始まりました。年2回のWindows 10大型更新トラブル話は多数あります。MCU開発環境は、年2回どころか度々更新されます。開発者は、その度にトラブル対処をしているのです👍。ちなみに本稿は、全てWindows 10 1903での結果です。