STM32CubeIDE v1.1.0更新と文字化け対策(その2)

STマイクロエレクトロニクス(以下STM)の統合開発環境:STM32CubeIDEが、v1.1.0に更新され、前投稿:その1では、従来SW4STM32プロジェクトをSTM32CubeIDEインポート時の日本語文字化け対策と、最新STM32MCU開発環境を示しました。

その2では、最新開発環境での文字化けと、開発環境更新リスク、ファームウェア更新へのリスク対応案について示します。

最新開発環境の文字化け

2019年11月時点のSTM32MCU最新開発環境と、IDEのみ従来のSW4STM32を使ったソフトウェア開発環境が下図です。

STM32MCU最新開発環境
STM32MCU最新開発環境

その1で示したSW4STM32プロジェクトインポート時のSTM32CubeIDEソースコード文字化けは、Shift-JISからUTF-8への手動エンコード変換で解決しました。

今回指摘する問題は、最新環境であってもSTM32CubeMX(以下、CubeMX)でコード再生成すると、STM32CubeIDE(以下、CubeIDE)ソースコードに日本語文字化けが発生することです。

このCubeMX起因の文字化けは、新規CubeIDEプロジェクト作成でも発生します。つまり、CubeIDEでプロジェクトを新規作成しmain.cへ日本語コメントを入力、次に生成済みCubeMXプロジェクトファイルを開き初期化コードを生成、CubeIDEへ戻ってmain.cを見ると日本語コメントに文字化けが発生します。
※スタンドアロン版、プラグイン版両方のCubeMXを試し、また、表示フォントもいろいろ変更しましたが、文字化けが発生します。対策がお判りの方は、教えてください😌。

もちろん、英語でコメント記入すれば問題はありません。日本語コメントの場合のみです。

一方、従来IDEのSW4STM32へCubeMX出力の場合には、文字化け無しです。ソースコードへ日本語コメントを追記する筆者のような方は、文字化け発生が解消されるまでは、SW4STM32とCubeIDE併用が良いかもしれません。

開発環境更新リスク

MCU開発ソフトウェア(=アプリケーション)への影響が一番大きいのは、ファームウェア:FW_F0/F1/G0/G4更新です。統合開発環境:CubeIDEやコード生成ツール:CubeMXの更新は、操作性や見た目へ変化を与えますが、アプリケーションそのものへの影響は、少ないです。

MCUアプリケーション開発は、STM32MCUに限らずベンダ提供API:Application Programming Interfaceのユーザ開発アプリケーションによる操作です。ファームウェア更新は、このベンダ提供APIのバグ取りや、新デバイス追加に関連するものが一般的です。開発済みユーザアプリケーションの場合は、デバイスは変わらないので、ファームウェア更新による影響があるのは使用中APIです。

従って、開発したアプリケーションの使用APIが変わらなければ、ファームウェア更新は問題ないハズです。

ところが、稀にファームウェア更新により正常に動作していたAPIにも影響が生じトラブルが発生することがあります。ファームウェア更新には、このリスクがあることも知っておきましょう。
※このリスク対策としてCubeMXは、旧版ファームウェアをRepositoryフォルダへ保存し、いつでも旧版へ戻せる準備をしています。

ベンダAPI、つまりファームウェア互換性には期待しない方が無難です。

理由は、最新ベンダMCU製造プロセス(=ハードウェア)、WindowsなどのパソコンOS、ベースのEclipse IDE、ARM CMSISなどのアプリケーション下層の更新、などなど様々なバージョンアップの組合せ結果が、ベンダAPI更新や刷新となるからです。

ベンダAPI互換が、既存ユーザにとっては理想です。しかし、元々非力なMCU能力を、従来API互換へ使うよりも、むしろファームウェア更新時点で、MCU能力を最も引き出すAPIへ使い、新規ユーザへアピールしたいとベンダが判断してもやむを得ないと思います。
※高性能MPU/GPUでさえAPI互換が無いことがあります。APIとは、そういうものだと割切って、例えAPIが変わっても柔軟に対応できるソフトウェア開発者が求められるのかもしれません。

ファームウェア更新リリースノートに、このAPI互換性の詳細説明を求めるのは、多分無理です。既存ユーザは、開発環境、特にファームウェア更新に関しては、慎重に対処すべきだと思います。

MCUアプリケーションは、開発完了時の開発環境依存度が非常に高いソフトウェアです。

最新デバイスと、最新APIの組合せが、その時点で最も効率的で優れたMCUアプリケーション開発手段と言えます。
※ルネサスのCS+には、アプリケーション開発完了時の開発環境を、一括圧縮保存する便利機能があります。Eclipse IDEにもプラグインで同様の機能を追加できると思います。

ファームウェア更新リスク回避策

筆者が考えるMCUアプリケーション開発に対するファームウェア更新リスクの回避策が、下記です。

MCUアプリケーション開発に対するファームウェア更新リスク
MCUアプリケーション開発に対するファームウェア更新リスク
  1. ユーザ開発アプリケーションが顧客システムで稼働中、しかもバグなどの問題が無い場合は、あえて前章リクスがあるファームウェア更新はしない
  2. アプリケーション開発が進行中の場合は、旧版ファームウェアで開発継続し、完成後に最新版を試す
  3. 開発済みアプリケーションへ機能追加の場合は、開発時ファームウェアで機能追加し、完成後に最新版を試す
  4. 新にアプリケーション開発を始める場合は、APIバグ可能性のより少ない最新ファームウェア開発環境で着手

開発完了から時間が経ったアプリケーション改版時には、開発当時のファームウェア更新への対策時間も加味しスケジュールを作成することをお勧めします。さもないと、肝心のアプリケーション改版前の段階でつまずいてしまいます。

※弊社販売中テンプレートは、テンプレート応用例として、評価ボード実装済みSWやLEDを制御するシンプルテンプレートと、Baseboardで各種機能を追加したBaseboardテンプレートの2つを添付しています。このうちBaseboardテンプレートは機能豊富な代償として、上記ファームウェア更新リスクに出会うことが稀にあります😫。テンプレートなので、本当は原理を解っていただくシンプルテンプレートのみを添付したいのですが、Baseboardテンプレート付きの方が売れるのでやむを得ない状況です😥。

投稿その1、その2と前振りが長くなりました。次回、汎用MCUシェア第2位の販売中STM32FxテンプレートSTM32G0xテンプレートを使って、最新開発環境への移設実例、トラブル対応を示します。

ARM Cortex-M4プロトタイプテンプレート構想

弊社は、ARM Cortex-M4コア使用のLPC5410x(NXP)、STM32G4(STM)、PSoC 6(Cypress)、MSP432(TI)各社のMCUテンプレート開発を目指しています。本稿は、各社共通のCortex-M4プロトタイプテンプレート開発指針を示します。

MCUプロトタイプ開発ステップ

MCUプロトタイプ開発と製品化へのステップ、支援ツール
MCUプロトタイプ開発と製品化へのステップ、支援ツール

プロトタイプからMCU製品開発へのステップが上図です。

  1. IDEと評価ボードを準備、利用MCUの開発環境構築
  2. サンプルプロジェクトを利用し、MCUや内蔵周辺回路の特徴・使い方を具体的に理解
  3. 製品処理に近いサンプルプロジェクトなどを活用し、評価ボード上でプロトタイプ開発
  4. プロトタイプへ保守点検などの製品化処理を追加、製品時ベアメタルかRTOS利用かを評価
  5. ステップ04評価結果でA:ベアメタル製品開発、または、B:RTOS製品開発へ発展

更に製品化へは様々なステップも必要ですが、プロトタイプ開発に絞るとこのステップになります。

Cortex-M4プロトタイプテンプレート

弊社Cortex-M4プロトタイプテンプレートは、ステップを効率的に上るための開発支援ツールです。

販売中の弊社テンプレートと同様、複数サンプルプロジェクトや開発した処理を、RTOSを使わずに時分割で起動するマルチタスク機能を備えています。
※時分割起動マルチタスク機能:ステップ03と04の課題は、複数サンプルプロジェクトや製品化に必要となる様々な処理を、どうやって1つに組込むか(?)ということです。RTOSを利用すれば解決します。しかし、RTOS利用のためだけに別途知識や理解が必要で、RTOS活用までの階段差が非常に高いという欠点があります。弊社テンプレートは、時分割で複数処理を起動し、初心者でも仕組みが理解できる低い階段差でマルチタスク機能を実現します。詳細は、コチラなどをご覧ください。

販売中の従来テンプレートとCortex-M4プロトタイプテンプレートの違いが、以下です。

  1. ステップ05以降の製品開発へも、ステップ01で構築したプロトタイプ環境をそのまま使える
  2. 下位Cortex-M0/M0+/M3ソフトウェアに対して、Cortex-M4プロトタイプ開発資産が流用できる

Cortex-M4の高性能を、プロトタイプ開発マージン(後述)に使うとこれらの違いが生じます。

Cortex-M4コアMCUの特徴

ARM Cortex-M4は、Cortex-M0/M0+/M3とバイナリ互換です。

簡単に言うと、Cortex-Mコア開発元ARM社が推進するCMSISに則って開発したCortex-M4ソースコードやライブラリは、再コンパイルすればCortex-M0/M0+/M3へ流用・活用ができます。
※CMSIS:Cortex Microcontroller Software Interface Standard関連投稿は、コチラの2章などを参照してください。

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

図から、Cortex-M4バイナリの全ては、下位Cortex-M0/M0+/M3に含まれてはいません。従って、効率的な処理やセキュリティ対策必須の高速演算を行うには、Cortex-M4が最適なのは言うまでもありません。

Cortex-M4を使ったMCUは、Cortex-M0/M0+/M3 MCUに比べ動作クロックが高速で内蔵Flash/RAM容量も大きいため、ベアメタル利用だけでなく、RTOS利用も可能です。

Cortex-M4がプロトタイプ開発に最適な理由:大マージン

Cortex-M4のMCUでプロトタイプ開発すれば、製品化時に必要となる処理や保守点検処理などの実装も「余裕」を持ってできます。
※製品出荷テストプログラム、自動販売機待機中のLEDデモンストレーション点灯などが製品化処理具体例です。

筆者は、このような製品化処理を、おおよそプロトタイプ処理と同程度と見積もります。つまり、製品のFlash/RAM量は、プロトタイプ時の2倍必要になります。

仮に「余裕」がありすぎオーバースペックの場合には、開発したCortex-M4プロトタイプ処理(=開発ソフトウェア資産)を、そのまま下位Cortex-M0/M0+/M3コアMCUへ流用が可能です。

一方、処理が複雑で多い場合には、RTOSで解決できるか否かの評価もCortex-M4プロトタイプなら可能です。更にIoT製品では、セキュリティ関連の(先が見えない)処理や計算量増加にも対応しなければなりません。

安全側評価なら敢えて下位Cortex-Mコアを選ばずに、Cortex-M4をそのまま製品にも使えば、処理増加にも耐えらます。

つまり、プロトタイプ開発には、初めから容量や性能の足かせが無く、製品化移行時の開発リスクも少ない高速高性能・大容量のCortex-M4 MCUが最適なのです。

製品時の処理能力やFlash/RAM量を、Cortex-M4プロトタイプで見積もった後に、製品化にステップアップすれば、適正な製品制御Cortex-Mコアを選択できます。開発ソフトウェア資産の流用性、過負荷耐力、RTOS製品開発評価ができる高性能を兼ね備えたのが、Cortex-M4を使ったプロトタイプ開発です。

問題は、価格です。

各社のCortex-M4評価ボード価格は、Cortex-M0/M0+/M3評価ボードと大差ありません。STM32MCUの評価ボード:Nucleo32シリーズは、Cortex-Mコアが異なっても同額です。プロトタイプ開発マージンを考慮すると、たとえ評価ボードに多少の価格差があったとしても十分納得がいきます。

Cortex-M4デバイス単体価格は、Cortex-M0/M0+/M3よりは高価です。しかし、製品原価全体に占めるCortex-M4デバイス価格比は低いでしょう。IoT製品では、今後増大するセキュリティ対策や計算量増加などを考慮すると、Cortex-M4デバイスを使うメリットは大きいと思います。

Cortex-M4プロトタイプテンプレート開発指針(NXP、STM、Cypress、TI共通)

Cortex-M4の特徴を活かし、下位Cortex-M0/M0+/M3間での開発ソフトウェア資産流用を考慮したCortex-M4プロトタイプテンプレート開発指針です。

  1. Cortex-M0/M0+/M3/M4各コアに用いるテンプレート本体の共通化
  2. プロトタイプ開発ソフトウェア資産流用性を高めるCMSISソフトウェアでの開発
  3. 製品化時ベアメタルかRTOS利用かを評価のため、Cortex-M4最高速動作のプロトタイプ開発

現在CMSISへの対応は、各社足並みが揃っているとは言えません。もしも完全にCMSISへ対応した場合は、異なるベンダ間でも開発アプリケーション互換が実現するからです。ARMコア市場が「攻めに強く、守りに弱い」ゆえんです。そういう状況でも、各社ともCMSISへのソフトウェア対応を進行中です。
※Cortex-M33コアには、CMSISに反して、ベンダ独自のカスタム命令追加の動きも見られます。

本稿で示したCortex-M4プロトタイプテンプレートと異なり、弊社販売中のCortex-M0/M0+/M3テンプレートは、テンプレート利用コアで最適解を与えます。そのため、RTOS利用時や、製品化処理、セキュリティ対策などの処理が増えた時には、元々のコア処理性能や内蔵Flash/RAMに余裕が少ないため、適用デバイスでの製品化に対して、開発を続けにくい状況が発生することもありえます。

この点、Cortex-M4プロトタイプテンプレートなら、プロトタイプで構築した同じ開発環境で、RTOSも含めた製品開発へも余裕を持って対応できます。同時に、プロトタイプ開発資産の流用や活用により、Cortex-M0/M0+/M3ソフトウェア生産性も高めることができます(一石二鳥)。

ATM Cortex-M4テンプレートと開発資産流用性
ATM Cortex-M4テンプレートと開発資産流用性

弊社Cortex-M4プロトタイプテンプレートの発売時期、RTOSへの具体的対応方法などは、未定です。本ブログで各社毎の開発状況をお知らせする予定です。

あとがき:初心者や個人利用は、Cortex-M4テンプレートが最適

ソフトウェア開発初心者にCortex-M4プロトタイプテンプレート利用は、難しい(=階段を上るのが困難)と考える方がいるかもしれません。筆者は、全く逆、むしろ初心者、個人利用に最適だと思います。

理由は、Cortex-M0/M0+/M3/M4と上位になるほどコア設計が新しく、処理性能も上がるからです。初心者が、あまり上手くないコード記述をしても、コア性能が高いため問題なく処理できてしまいます。詳細は、ARM Communityの“An overview of the ARM Cortex-M processor family and comparison”などが参考になります。

ごく簡単に言うと、自動車エンジンが、Cortex-Mコアに相当すると考えてください。

小排気量なCortex-M0より、大排気量のCortex-M4の方が、楽に運転でき、しかも、運転に最低限必要なハンドルやアクセル、ブレーキ操作は全く同じです。車(=評価ボード)の価格が同じなら、殆どの方が、余裕のある大排気量のCortex-M4を選択するでしょう。

しかも、Cortex-M4評価ボード操作の技(=開発ソフトウェア資産)は、Cortex-M0/M0+/M3へも流用できます。経済的に厳しい個人利用のプロトタイプ開発環境としては、流用範囲の広いCortex-M4 MCUテンプレートが最適と言えます。

弊社Cortex-M4プロトタイプテンプレートは、つまずき易い階段を、楽に効率的に上るための開発支援ツールです。ご期待ください。

汎用MCUシェア20%超、第2位はSTM32MCU

シェア2位に躍り出たSTの汎用マイコン事業戦略”が、EE Times Japanに掲載されました。本稿は、この記事を要約し、記事記載のMCU 4ニーズの1つ、セキュリティ強化マイコン:STM32H7の暗号鍵利用によるソフトウェア更新方法(ST公式ブログ10月8日投稿)を示します。

STM32MCUは、汎用MCU世界市場シェア20%超の第2位へ

2019年9月、東京都内でSTマイクロエレクトロニクス(以下STM)による記者会見が開かれ、そのレポートがEE Times Japan記事内容です。ARM Cortex-Mコア採用のSTM32MCUが、2018年には汎用MCU世界市場シェア20%を超え第2位になった要因分析、今後のSTM汎用MCU事業方針が会見内容です。

汎用STM32MCUの世界シェア推移(出典:STM)
汎用STM32MCUの世界シェア推移(出典:STM)

車載用を除くMCUが汎用MCUです。本ブログも、この汎用MCUを対象としており、上図推移は重要なデータです。

以下、マイクロコントローラ&デジタルICグループマイクロコントローラ製品事業部グローバル・マーケティング・ディレクタ)Daniel Colonna氏の記者会見談話を中心に記事要約を示します。

STM32MCUシェア続伸要因

STM競合他社は買収や統合で成長しているが、STMは独自でシェア2位を実現。要因は、民生機器だけに集中せず、産業機器などのインダストリアル分野(=マスマーケット)に主眼を置き製品開発を行ってきたこと。マスマーケットターゲット事業方針は今後も変えず、シェア30%を目指す。

インダストリアル分野の4MCUニーズとSTM対応

演算性能の強化(STM32MP1/STM32H7)、より高度なAI実現(STM32CubeMXのAI機能拡張パッケージ)、多様な接続技術への対応(STM32WB)、セキュリティ強化(STM32Trust)の4点がインダストリアル分野MCUのニーズとそのSTMの対応(カッコ内)。

インダストリアル分野汎用MCUの4ニーズ(出典:STM)
インダストリアル分野汎用MCUの4ニーズ(出典:STM)

より広範囲なマスマーケット獲得策

モノクロからカラーLEDへ置換え(TouchGFX)、8ビットなどから32ビットMCUへ置換え(STM32G0シリーズ)で、より広範囲マスマーケットでのSTM32MCU浸透を図る。

以上が記者会見記事の要約です。

汎用MCU第2位となったSTM32MCU評価ボードは、入手性が良く安価です。コードサイズ制限なしの無償開発環境(STM32CubeIDE /SW4STM32/STM32CubeMX)も使い勝手に優れています。また、厳選された日本語技術資料も活用でき、初級/中級レベルのMCU開発者に最適だと筆者も思います。

この特徴を持つSTM32MCUに対して、弊社はSTM32G0x専用テンプレートSTM32Fx汎用テンプレートを販売中です。今後は、STM32G4テンプレートも開発を予定しています。

これまでNon ARM汎用MCU1位であったRunesasも、ARMコア他社対応か(?)ついに2019年10月8日、Cortex-MコアMCU販売を開始しました。これについては、別途投稿します。

セキュリティ強化STM32H7のソフトウェア更新

インダストリアル分野4MCUニーズのうち、演算性能とセキュリティ強化を満たすのが、STM32H7(Cortex-M7/480MHz、Cortex-M4/240MHzのデュアルコア)です。筆者個人は、MCUというよりむしろMPUに属す気がします。STMも、STM32MCU(下記右)に対して、STM32マイクロプロセッサ(下記左)と区別しています。但し、名称は違っても、そこに用いる技術は同一のはずです。

STM32MCUとSTM32マイクロプロセッサ(出典:STM)
STM32MCUとSTM32マイクロプロセッサ(出典:STM)

丁度最初に示した10月8日のSTM公式ブログに、セキュリティ強化STM32H7のファームウェア書換え手順図を見つけました。関連投稿:総務省:2020年4月以降IoT機器アップデート機能義務化予定の2章で示した3種サイバー攻撃へのウイルス感染対策です。

STM32H7ソフトウェア更新時のSFI、HSM(出典:STM)
STM32H7ソフトウェア更新時のSFI、HSM(出典:STM)

ハードウェア暗号化エンジンを持つSTM32H7は、図右上のSFI:Secure Firmware Installで暗号化、STM32G0やSTM32G4等は、図右下のSMI:Secure Module Installで暗号化し、更新ソフトウェアを準備します。どちらも、セキュリティ認証情報を含むHSM:ST Hardware Secure Module smart cardで鍵を受渡し復号化、ソフトウェア書換えを行います。

我々が開発するMCUソフトウェアの更新頻度は、PCに比べれば低いはずです。しかし、その頻度は、ウイルスの数に比例しますので、サイバー攻撃が増えればその度にこの書換えで対応することを考えると憂鬱になります。
※書換え失敗やワクチン投入による通常処理への配慮も必要で、Windows 10のようにユーザ任せの無責任な対応はMCUソフトウェアでは論外なため、開発者負担は増すばかりです😫。

ARM Cortex-M4とM0+アプリケーションコード互換

NXP MCUXpresso SDK利用を利用すると、LPC845 Breakout board用に開発した1秒赤LED点滅アプリケーションコードが、そのままFRDM-KL25Zへ流用できることを前回投稿で示しました。ただ、どちらも同じARM Cortex-M0+コアのMCU評価ボードなので、読者インパクトは少なかったかもしれません。

そこで、LPC845 Breakout board(Cortex-M0+/30MHzコア)のLED点滅アプリケーションコードが、そのままCortex-M4/100MHzコアのLPCXpreosso54114へ流用できることを示します。異なるARMコア間でのアプリケーションコード互換の話です。

ARMコアバイナリ互換

Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)
Cortex-Mxのバイナリ互換性(出典:STM32L0(Cortex-M0+)トレーニング資料)

ARMコアのバイナリ上位互換を示す図です(関連投稿:Cortex-M0/M0+/M3比較とコア選択の2章)。このバイナリコード包含関係は、Cortex-M0バイナリコードならCortex-M4でも動作することを示しています。

但し、この包含関係を理解していても、Cortex-M0バイナリコードをそのままCortex-M4へ流用する開発者はいないと思います。

ARMコアアプリケーションコード互換

Cortex-Mxのアプリケーションコード互換性
Cortex-Mxのアプリケーションコード互換性

MCUXpresso IDEのARMコアアプリケーションコード互換を示す図です。左がLPC845 Breakout board(Cortex-M0+/30MHzコア)の1秒赤LED点滅アプリケーションコード、右がCortex-M4/100MHzコアのLPCXpreosso54114の1秒赤LED点滅アプリケーションコードです。

コード差は、L59:LPCXpreosso54114評価ボード動作クロック設定:48MHz動作のみです。例えば、96MHzなどの他の動作周波数へ設定することも可能です。コード上で動作周波数を明示的に表示するために異なりましたが、機能的には両者同じコードと言えます(L59をマクロで書き換えれば、同一コード記述もできます)。

図下のInstalled SDK Versionが、どちらも2019-06-14で一致していることも重要です。Versionが異なると、例えばGPIOのAPIが異なることがあるからです。各SDKリリースノートでAPI差の有無確認ができます。※LPCXpreosso54114 SDKのMCUXpresso IDE設定方法は、コチラの投稿の5/6章を参考にしてください。

1秒赤LED点滅という簡単なアプリケーションですが、Cortex-M0+とCortex-M4の異なるARMコア間でコード互換性があることが解ります。

動作周波数の隠蔽とIO割付

評価ボード動作周波数が異なれば、無限ループ回転速度も異なります。従って、互換性を持たせるコード内に、無限ループ内の回転数でLED点滅させるような処理記述はできません。コードに時間要素は組込めないのです。

1秒点滅の場合は、L77:SysTick_DelayTicks()でループ回転数をカウントし、1秒遅延を処理しています。これにより、GPIO_PortToggle()が時間要素なしとなり、異なる動作周波数のARMコアでもアプリケーションコード移植性を実現しています。

SysTick_DelayTick()と1ms割込みによりカウントダウンする処理コードが下記です。ここも、割込みを利用することでコード移植性を実現しています。

動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現
動作周波数隠蔽によるARMコアアプリケーションコード移植性の実現

左のLPC845 Breakout boardと、右のLPCXpreosso54114のコード差は、L16:赤LEDのIO割付のみです。評価ボード毎に異なるIO割付となるのは、やむを得ないでしょう。L12からL16のDefinition箇所を、別ファイル(例えばIODefine.hやUserDefine.h)として抽出すれば、同一コード記述も可能です。

ARMコアアプリケーションコード互換メリット

以上のように、ARMコアアプリケーションコード互換を目的にした記述や工夫も必要です。しかし、一旦互換コードを開発しておけば、開発資産として他のARMコア利用時にも使えます。その結果、開発速度/効率が高まります。

IoT MCUは、センサ入力やLED出力などのメイン処理以外にも、日々変化するセキュリティ処理への対応は、必須です。メイン処理が出来上がった後での、セキュリティ処理追加という手順です。

セキュリティ対策は、セキュリティライブラリ等の使用だけでなく、いつどのようにライブラリを活用するか、その時のMCU負荷がメイン処理へ及ぼす影響等、検討が必要な事柄が多くあります。

少しでも早くメイン処理を仕上げ、これら検討項目へ時間配分することがIoT MCU開発者には要求されます。この検討時間稼ぎのためにも、ARMコアアプリケーションコードの開発資産化は必須でしょう。

※プロトタイプ開発は、初めから厳しい条件で開発するよりも、最速のCortex-M4で行い、全体完成後Cortex-M0+/M3などへアプリケーションコードを移植するコストダウンアプローチも名案だと思います。

P.S.:2019年9月4日、MCUXpresso IDEがv11.0.1へ更新されました。旧MCUXpresso IDE v11.0.0 [2516]利用中の方は、Help>Check for Updatesではv11.0.1へ更新されません。新にMCUXpresso IDE v11.0.1 [2563]のインストールが必要です。新MCUXpresso IDEインストール方法は、コチラの4章を参照ください。

NXP MCUXpresso SDKから見るARMコアMCU開発動向

NXP最新IDE:MCUXpresso v11が、SDK:Software Development Kitを使ってMCUソフトウェア開発をすることは、前回投稿で示しました。MCUXpresso SDKがサポートする評価ボード一覧が、SDKユーザガイド最新版:Rev.10、06/2019付録Bにあり、旧Freescale評価ボード:FRDMが多いですが、NXPの新しい評価ボードも追加されつつあります。

オランダ)NXPが、米)Freescaleを買収完了したのは2015年12月です。

本稿は、旧FreescaleとNXP MCU両対応のMCUXpresso SDKから、ARMコアMCU開発動向を調査し対策を示しました。

MCUXpresso SDK

MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)
MCUXpresso SDK Laysers(出典:Getting Started with MCUXpresso SDK, Rev. 10_06_2019)

ユーザガイド記載のMCUXpresso SDK層構成です。ユーザが開発するのはApplication Code。このApplication Code以外は、評価ボード:MCU Hardwareと、SDKで提供されます。色付き部分:Middleware、Board Support、FreeRTOS、Peripheral Drivers、CMSIS-CORE…がSDKの中身です。

もちろんMCU性能に応じて、初めからFreeRTOSやMiddlewareが無いSDKもあります。例えば、前回のLPC845 Breakout board SDKリリースノートを見ると、Board Support(前回投稿BSPのこと)とPeripheral Drivers(Author: Freescale)、CMSIS-CORE(Author: ARM)だけが提供中です。

CMSIS:セムシイス

CMSIS:Cortex Microcontroller Software Interface Standardは、リリースノートでAuthor: ARMが示すようにMCUコア開発元ARM作成の規格で、MCUハードウェアを上位層から隠蔽します(関連投稿:mbed OS 5.4.0のLチカ動作、LPCXpresso824-MAXで確認の3章)。

Peripheral DriversやBoard Supportは、 このCMSIS層のおかげでMCUハードウェアに依存しないAPIを、ユーザ開発Application Codeへ提供できる訳です。例えば、下記旧Freescale評価ボード:FRDM-KL25Z用SDKのboard.h記述:赤LED初期設定とトグルマクロ関数は、前回投稿で示したLPC845 Breakout boardと同じです。

FRDM-KL25Z用SDK_SDK_2.2_FRDM-KL25Zのboard.h
FRDM-KL25Z用SDK_SDK_2.2_FRDM-KL25Zのboard.h

従って、LPC845 Breakout boardで開発したアプリケーションコードを、そのままFRDM-KL25Zへも流用できます。

つまり、「SDK利用によりARMコアアプリケーションコードが汎用化」したのです。

同一アプリケーションコードでFreescaleとNXP評価ボード動作の意味

旧FreescaleとNXPのMCU評価ボードが同じアプリケーションコードで動作するのは、どちらもARMコアMCUでCMSIS層付きSDKなので、開発ユーザから見れば当然です。

しかし、従来は同じARMコアであってもApplication CodeはMCUベンダ毎に異なり、ベンダが異なれば常に1から開発していました。NXPでさえ、SDKを使った今回の同一コード動作に、Freescaleを買収後、約3.5年かかっています。
※Freescale 旧IDE:Kinetis Design Studioや、NXP 旧IDE:MCUXpresso IDE v11以前に慣れた開発者は、CMSIS付きSDKの新IDE:MCUXpresso IDE v11に違和感があるかもしれません。というのは、新IDEは、どちらの旧IDEとも異なるからです。

もちろんCMSIS利用はメリットだけでなく、デメリットもあるハズです。例えば、他社と差別化するベンダ独自Peripheral性能を極限まで引出すには、直接Hardwareを制御した方がより効率的です。STマイクロエレクトロニクスのSTM32G0x MCUのLL:Low Layer APIなどにその動向が見られます(関連投稿:STM32G0x専用Edge MCUテンプレート開発)。

しかし、CMSIS利用SDKを使ったアプリケーションコード開発は、ARMコア間のアプリケーションコードやベンダ間をも跨ぐ移植性、開発速度の速さ、ソースコード可読性などの点からユーザメリット大と言えます。
※ベンダを跨ぐ移植性とは、FreescaleとNXPのMCUで同一アプリケーションが動作することを意味します。FreescaleはNXPに買収されたので、実はベンダを跨いでいませんが、CMSIS層があればアプリケーションコード移植可能な実例と思ってください。

ARM MCUコアソフトウェアの開発動向と対策

現在MCUコアは、多数派のARMコアベンダと、少数派のNon ARMコアベンダの2グループに分かれています。

多数派ARMコアベンダは、NXPのMCUXpresso SDKに見られるようにCMSIS層利用アプリケーションコード開発、既存アプリケーション資産流用、差別化Peripheral開発に力点を置くと思います。目的は、より早く、より簡単な環境提供によるソフトウェア開発効率/速度の向上です。

我々ユーザは、この環境変化に応じたアプリケーションコード汎用化手法と、もう一方の差別化機能の性能発揮手法を臨機応変、かつ、それらを混同せず、時には組み合わせて開発する必要があると思います。

P.S.:弊社テンプレートで言えば、アプリケーションコード汎用化手法が、STM32Fxテンプレート他の汎用テンプレート、一方の差別化機能の性能発揮手法が、STM32G0x専用テンプレートです。

MCUXpresso IDE v11をLPC845 Breakout boardで試す

まとめ

NXPのMCUXpresso IDE v11.0.0 [Build 2516] [2019-06-05]を使い、LPC845の評価ボードLPC845 Breakout boardの動作を確認し、サンプルプロジェクト赤LED点滅を緑LEDへ簡単に変更できる、SDK:Software Development Kitメリットを示しました。

LPCOpenライブラリなどを使った旧IDEに比べ、SDKを使うMCUXpresso IDE v11は、より早く簡単にソフトウェア開発が可能です。また、IDE更新とSDK更新が別々なため、常に最新ドライバ、BSP:Board Support Packageでの開発ができます。これもSDKメリットの1つです。

SDKは、ソフトウェア開発速度を上げる専用ライブラリ集です。MCUXpresso IDE v11のSDKを習得し、効率的なソフトウェア開発に慣れる必要があります。
これには、実際に評価ボード専用SDKを作成し、サンプルプロジェクトへ変更/修正を加え、SDKメリットを実感するのが早道です。本稿で用いたLPC845 Breakout boardは、SDK習得に好適です。

LPC8xxをアップグレートしたLPC845(64KB Flash、16KB RAM)評価ボード:LPC845 Breakout boardは、タッチパッド+デバッガ付きで低価格(¥697)、少サイズ(65x18mm)です。このサイズならそのまま装置へ実装も容易です。現場での短時間制御系アップデートや修理交換などに応用できます。

LPC845 Breakout board

LPC845 Breakout board
LPC845 Breakout board(出典:LPC84X MCU TECHNICAL OVERVIEWへ加筆)

LPC8xxシリーズは、アップグレートしたLPC84xとコストダウンしたLPC80xの2方向へ発展しました(関連投稿:NFCを使うLPC8N04のOTA)。LPC845評価ボード:LPC845 Breakout board (Cortex-M0+/30MHz)を入手しましたので、最新のLPCXpresso IDE v11を使って動作確認します。

LPCXpresso IDE v11.0.0 [2019-06-05]

最新LPCXpresso IDEは、v11.0.0 [2019-06-05]です。旧IDEからSDK:Software Develipment Kit追加、Pin設定方法が変わりました。既に旧IDEを使い慣れた方は、SDK活用の新LPCXpresso IDE v11に少し驚きを感じると思います。

LPCXpresso IDE v11ダウンロードとインストール

LPCXpresso IDE v11のダウンロードとインストールは、普通のPCアプリケーションと同じです。旧IDEではインストール後、アクティベーション手順が必要でしたが、v11は不要です。

また、デフォルトではプログラム/workspace共に専用フォルダ:MCUXpressoIDE_11.0.0_2516へ展開されます。つまり、旧IDEと共存します。ストレージ使用量は多くなりますが、共存するので安心して新旧IDEを試すことができます。

インストール後、Help>Check for Updatesを実行しIDEの更新有無を確認します。

また、最初のMCUXpresso IDE v11起動時にセキュリティソフトが警告を出すことがあります。お使いのセキュリティソフトに応じて対応してください(筆者Windows 10 Pro 1903のAvastは警告を出しましたので、例外追加で対応しました)。

LPCXprsso IDE v11インストール起動画面
LPCXprsso IDE v11インストール後、最初の起動画面

SDK Builder

SDKは、周辺回路ドライバ、サンプルプロジェクト、評価ボードサポートパッケージ:BSPなどを含む開発支援ツールです(SDKユーザガイドはコチラ)。インストールしたMCUXpresso IDEとは別に、ネット上のSDK BuilderでLPC845 Breakout board専用SDKを作成します(要ログイン)。

SDK BuilderのSelect Development Boardをクリックし、LPC845BREKOUTを選択します。後は、Build MCUXpresso SDKをクリックすると、作成したSDKの圧縮ファイル:SDK_2.6.0_LPC845BREAKOUT.zipがダウンロードされます(2.6.0は版数)。
※評価ボードによっては、Amazon-FreeRTOS、Azure IoTなどのミドルウェアもSDKへ追加可能です。

SDK設定

ダウンロードしたSDK圧縮ファイルを、LPCXpresso IDEのInstalled SDKsビューへドラッグ&ドロップするだけでSDK設定は完了です。

LPC845 Breakout boardの赤LED点滅動作

SDKにはLPC845 Breakout boardの赤LED点滅させる、いわゆるLチカサンプルプロジェクトがあります。このLチカソフトで評価ボードの動作確認をします。

IDEのQuickstart Panelビュー、Import SDK example(s)…をクリックします。Lpc845breakoutを選択後Nextをクリックします。Examplesのdemo_appsを開くとled_blinkyが現れます。これがLチカサンプルです。

Led_blinkyに☑を入れFinishをクリックすると、workspace内にlpc845breakouty_led_blinkyプロジェクトが展開されます。

LPC845 Breakout boardのLED点滅サンプルプロジェクトのインポート
LPC845 Breakout boardのLED点滅サンプルプロジェクトのインポート

何も変更せずに、Quickstart PanelビューのBuildをクリックするとコンパイルが成功します。評価ボードをPCと接続しDebugのクリックでCMSIS-DAPプローブを自動認識し、デバッグモード画面へ変わります。

後は実行などで赤LEDが1秒毎に点滅する動作が確認できます。

SDKサンプルプロジェクトそのものの動作確認は、以上のように簡単です。SDKのメリットは、プロジェクト変更や機能追加が簡単にできることです。例を次に示します。

LPC845 Breakout boardの赤→緑LED点滅の変更

赤LEDへの制御を緑LEDへ変更するには、IDEをDevelop画面からPin画面へ切替えます。切替は、Open Pinsクリック、またはIDE右上のデバイスアイコンのクリックどちらでもOKです。

LED_LED点滅からGREEN_LED点滅変更のPin画面
LED_LED点滅からGREEN_LED点滅変更のPin画面

Pin画面は、プロジェクト使用中のピン名、周辺回路などがハイライト表示されます。

lpc845breakouty_led_blinkyプロジェクトの場合は、PIO1_2とGPIOで、IdentifierにLED_REDとあります。Identifireは、ソースコード中で使えるマクロです。LED_GREENやLED_BLUEが既にあるのも解ります。このように評価ボード実装済みのハードウエアが、あらかじめSDKで定義済みです。

赤LED→緑LED変更は、Pin11のLED_GREENに☑を入れ、表示されるPIO1_0選択肢からデフォルトのGPIO,PIO_1_0を選びます。次にUpdate CodeをクリックすればPin画面の変更がソースコードへ反映されます。

LED_RED点滅からLED_GREEN点滅へのピン変更
LED_RED点滅からLED_GREEN点滅へのピン変更

ソースコード表示のDevelop画面へ切替えるには、右上のDevelopアイコンをクリックし、L16をコメントアウト、代わりにL17の追記で赤→緑LED点滅への変更完了です。ビルドして緑LED点滅動作を確認してください。

LED_RED点滅からLED_GREEN点滅へのソースコード変更
LED_RED点滅からLED_GREEN点滅へのソースコード変更

このようにサンプルプロジェクトの変更は、SDKに評価ボード実装ハードウエアが定義済みなので、ボード回路図を確認せずにすぐにできます(回路図を確認すれば万全ですが…😅)。

さて、緑LED点滅動作が確認できた後にソースコードへ下記3か所の変更を加えてください。

BSPを使った赤LEDの点滅
BSPを使った赤LEDの点滅

これは、board.hで定義済みのBSPを使った赤LED点滅へのソースコード変更です。追記したLED_RED_INIT(0)とLED_RED_TOGGLE()は、board.hに記述があります。L80:GPIO_PortToggle()よりもL81:LED_RED_TOGGLE()の方が、ソースコード可読性が高いことが解ります。

BSPは、評価ボードで使用頻度が高い関数やマクロを定義します。BSP活用でソースコード可読性が高まりケアレスミスも減ります。BSPは、SDK作成時に生成されます。

LPC845 Breakout boardのSDK活用例を示しました。SDKメリットも実感できたと思います。

LPCOpenライブラリを使ったLPC8xxテンプレートも、新しいSDK対応へUpgradeする必要があるかもしれません。SDKは、新しい評価ボードから対応中なので、残念ながら少し待つ必要があるかもしれませんが…😅。

STLINK-V3とは

2019年7月23日STM公式ブログでSTLINK-V3デバッグ/プローブが発表されました。

STLINK-V3は、従来からのST-LINK/V2-1の性能向上と機能追加をしたSTM32/STM8マイコン用の新しいデバッグ/プログラミングインタフェースです。

左側の最新STM32G474(Cortex-M4、512KB Flash)評価ボードはSTLINK-V3、LL API専用テンプレートで使った右側STM32G071(Cortex-M0+、128KB Flash)評価ボードはST-LINK/V2-1インタフェースを使っています。

STLINK-V3とST-LINK/V2-1
STLINK-V3とST-LINK/V2-1を使う評価ボード例

両インタフェースの主な相違点、いつどのような時にSTLINK-V3を使うのかを説明します。

STLINK-V3/SET、STLINK-V3/MINI

STLINK-V3デバッガ/プログラマは、3種類のボードから構成されます。

STLINK-V3SET基本ボード:MB1441と機能拡張ボード:MB1440、これらボードを収納するケース、基板むき出しのSTLINK-V3MINIです。STLINK-V3MINIは3Dプリンタレファレンスファイルを使ってユーザ独自ケースが作成可能です。

STLINK-V3SETは、MB1441とMB1440、ケース込みで$35、STLINK-V3MINIは、$9.75で販売中です。

STLINK-V3SETとSTLINK-MINI(出典:STM公式ブログ)
STLINK-V3SETとSTLINK-MINI(出典:STM公式ブログ)

STLINK-V3とST-LINK/V2-1の主な相違点

STLINK-V3とST-LINK/V2-1の主な相違点
仕様 STLINK-V3 ST-LINK/V2-1
USBスピード 480 Mbps(理論値) 12M bps
Drag & Dropブログラミング 可能 可能
Single Wire Debug(SWD サポート サポート
JTAG サポート なし
Bridge SPI サポート(MB1440) なし
Bridge I2C サポート(MB1440) なし
Bridge CAN サポート(MB1440) なし
Bridge GPIOs サポート(MB1440) なし
STDC14 サポート(VCP付き) なし

※VCP:Virtual COM Port

PC接続のUSB速度が最大480Mbpsと高速となり、STM32G474のような512KBもの大容量Flashでも高速に書込みが可能です。

また、機能拡張ボード:MB1440では、従来からあるUARTブリッジ機能に加え、SPI/I2C/CAN/GPIOのブリッジ機能も使え、PC上で各インタフェースのデバッグ等に活かせます。

STLINK-V3ターゲット接続インタフェース:STDC14

これらSTLINK-V3SET/MINIボードの基本機能(SWD、JTAG、Virtual COM Port)とターゲットMCUボードを繋ぐ仕様がSTDC14です(ハーフピッチ14ピンケーブル)。

STDC14 (STM32 JTAG/SWD and Virtual COM Port)
STDC14 (STM32 JTAG/SWD and Virtual COM Port)

STDC14コネクタをターゲットMCUボードに実装しておけば、STLINK-V3SETかSTLINK-V3MINIを使ってターゲットMCUのデバッグやプログラミングがST-LINK/V2-1よりも高速、効率的にできます。

VCP:Virtual COM Port

従来のST-LINK/V2-1でもVirtual COM Portは使えました。例えば、STM32G071評価ボードでは、ST-LINK/V2-1のVCP機能を使ってSTM32G071RBのLPUART1とPCとを接続し、評価ボードに追加配線なしでSTM32G071RB動作確認や操作ができています。

ST-LINK/V2-1のVCP利用例
ST-LINK/V2-1のVCPを利用し評価ボードとPC接続した例

PC上でTera Termなどのターミナルソフトを使えば簡単手軽にターゲットMCU動作確認ができるVCPが、新しいSTLINK-V3接続インタフェースSTDC14に含まれるので、VCPの重要性は益々高まると思います。

IoTを狙うデュアルコアMCU

CypressのPSoC 6を中心にNXPとSTM、3社のARMディアルコアMCUを調査しました。Cortex-M4とCortex-M0+を使う個人でも低価格で入手できるディアルコアMCUです。ディアルコアMCUの狙い、アプリケーション、シングルコアMCUソフトウェア開発との違いなどを説明します。

Cortex-A7とCortex-M4を使ったもう1つの超高性能ディアルコアMCUも少しだけ登場します。

ディアルコアMCUの狙い、アプリケーション

ディアルコアMCUの狙い
ディアルコアMCUの狙い(出典:Cypress Cortex-M4 PSoC 6サイト)

CypressのCortex-M4コアPSoC 6サイトの上図がディアルコアMCUの狙いを示しています。

つまり、「IoT市場獲得には、右側アプリケーションプロセッサからと左側マイクロコントローラ:MCUからの2つのアプローチがあり、MCUアプローチのPSoC 6は、処理能力とセキュリティ強化を低コスト、低電力で実現した」ということです。

PSoC 6は、実現手段としてメインコアにCortex-M4(150MHz)、補助コアにCortex-M0+(100MHz)のディアルコアを採用しています。このCortex-M4+Cortex-M0+の2MCU構成は、NXP:LPC54102STM:STM32WB55RGでも見られます。CypressとSTMは、Cortex-M0+側にBluetooth Low Energy無線通信機能を実装済みです。

PSoC 6は、実装セキュリティに応じてPSoC 62/63シリーズと3種類のPSoC 64シリーズに別れます。PSoC 62/63は、PSoC 6のセキュリティ機能とユーザ独自セキュリティファームウェア(ソフトウェア)を使うデバイス(次章参照)、最上位プレミアムセキュリティのPSoC 64は、標準的なセキュリティ機能を全て含むデバイスです。

一方、アプリケーションプロセッサアプローチは、NXP:iMX 7アプリケーションプロセサのようにスマホやRaspberry Piでも用いられたCortex-A7(800MHz)がメインコアで、Cortex-M4(200MHz)が補助コアです。このアプローチは、ソフトウェア開発規模が大きく評価ボードも高価で個人開発向きとは言いにくいと思います。Cortex-A7自身がマルチコアでOS利用が前提なので更に複雑になります。

まとめると、低コスト低電力で処理能力とセキュリティ強化目的のCortex-M4+Cortex-M0+ディアルコアMCUの狙いは、IoTアプリケーションです。PSoC 63搭載の評価ボード:CY8CPROTO-063-BLEの価格は¥2,289(Digi-Key調べ)で、個人でも手が出せる価格帯です。

ディアルコアMCUのソフトウェア開発

PSoC 63 Line with BLE (Applications and Freatures)
PSoC 63 Line with BLE (Applications and Freatures)

Cypress Roadmap: MCU Portfolio、P25から抜き出したPSoC 63のアプリケーションとFeaturesです。具体的なIoTアプリケーションや、実装セキュリティ機能が解ります。
※ご参考までにこのMCU Portfolioには、CapSenseテンプレート開発で用いたPSoC 4000S/4100S仕様も解り易く掲載されています。

同じP25記載のPSoC 63ブロック図です。Cortex-M4とCortex-M0+がメモリ結合されています。

PSoC 63 Line with BLE (Hardware)
PSoC 63 Line with BLE (Hardware)

PSoC 6のソフトウェアは、Cortex-M4とCortex-M0+それぞれのソフトウェアが、2つ同時に別々に動作します。簡単に言うと、各シングルコアMCUソフトウェア同士が、同じデバイス内で動きます。メモリ結合なので、同一メモリアドレス同時アクセスの競合回避手段なども多分あるハズです(←調査不足😌)。

つまり、ディアルコアMCUソフトウェア開発と言っても、従来のCortex-M4やCortex-M0+シングルコアMCUソフトウェア開発の経験やスキルがそのまま活かせるのです。

一方のMCUから見ると、片方のMCUはインテリジェントな周辺回路と同じです。

例えば、Windowsソフトウェア開発なら、1つの機能を複数スレッドに分割し、処理効率を上げるなどのマルチコア対応の工夫が必要です。しかし、Cortex-M4+Cortex-M0+デュアルコアMCUの場合は、シングルコアのソフトウェア開発手法がそのまま使えます。

差分は、「2つのMCUに、どの機能を割振るか」です。

FPU内蔵のCortex-M4は、セキュリティなどの計算処理、高速GPIOアクセスのCortex-M0+は、IO処理やBLEモジュール管理、というのが定番(CypressやSTMのディアルコアMCUにみられる)割振りのようです。

まとめると、ディアルコアMCUソフトウェア開発は、シングルコアMCU開発経験がそのまま活かせます。しかも、別々動作の2コアを持つので、RTOSを使わずに処理分離と本当の並列動作ができます。

また、個人入手可能な評価ボード価格も魅力です。

評価ボード搭載のPSoC 63:CY8C6347BZI-BLD43(116-BGA)は、BGAパッケージなので基板実装は簡単ではありません。しかし、このPSoC 63とBLEアンテナをモジュール化したCYBLE-416045-02(14.0 mm x 18.5 mm x 2.0 mm、43-pad SMT with 36 GPIOs、下図)が評価ボードに実装済みで単体購入も可能です。

また、個人利用の場合には、評価ボードを丸ごと基板実装するのも効果的です。

EZ-BLE Creator Modules CYBLE-416045-02
CY8C6347BZI-BLD43搭載のEZ-BLE Creator Modules CYBLE-416045-02

ディアルコアMCUへの対処案

ディアルコアMCUの狙いは、巨大なIoT市場です。

各社がディアルコアMCUを発売する理由は、高度化するセキュリティ機能や、どの規格かが不確定な無線通信機能に対して、現状のシングルARMコアMCUでは、処理能力不足が懸念されるためです。
※近距離無線通信の有力候補が、BLEであることは確かです。

ディアルコアMCUならば、たとえ規格が変わっても、その影響を片方のMCU内に止めることもできます。つまり、ソフトウェア資産が無駄にならない訳です。

IoT市場へは、Cortex-M4+Cortex-M0+と、Cortex-A7+Cortex-M4のアプローチがあります。Cortex-M4を用いる点ではどちらも一致しています。FPU内蔵Cortex-M4ソフトウェア開発や経験が、IoT MCUプログラマの必須要件になるかもしれません。

シングルコアMCU開発経験が活かせ、しかもRTOSを使わずに高速並列処理を実現できるディアルコアMCUのソフトウェア/ハードウエア開発を、評価ボードへの僅かな投資で、IoTが爆発的に普及する前から準備・習得するのは、技術者リスク回避の点からも必要だと思います。

PSoC 4100S CapSenseの使い方(最終回)

Cypress PSoC 4 MCU内蔵タッチセンサ:第4世代CapSenseの使い方、最終回は、これまでの関連投稿全体まとめと、PSoC MCU開発時の留意点を説明します。

6月3日発表のInfineon+Cypressが成立するかは不透明です(関連投稿:InfineonがCypress買収で合意)。但し、買収が成立するとCypressのPSoC 4シリーズはよりメジャーMCUになります。このPSoC 4000S/4100S内蔵の最新第4世代CapSense使ったタッチUIテンプレート開発が関連投稿の目的です。

PSoC MCUのソフトウェア開発は、他社ARMコアMCU開発と比べると少々クセがあります。

但し、このクセさえ知っていれば、他社MCUからの移行も容易で、PSoCの特徴を活かした開発もできます。そこで、このクセに対する個人的な留意点と、開発に使用した評価ボードのTipsを初めに示します。

第1回~今回の投稿を基に、PSoC 4000S/4100S専用タッチUIテンプレート開発を進めます。開発完了とテンプレート発売は、少し時間を頂いて、2019/3Qを予定しております。

PSoC MCU開発時の留意点、評価ボードTips

用語とPSoC Creator

Cypress PSoC MCU資料で用いる用語は、他社が使う一般的な用語と異なります(対応表参照)。また、PSoC CreatorのTopDesign.cyschと呼ぶ回路図へコンポーネントを配置し、開発着手するのも他社に無い手法です。

Cypress PSoC MCU用語 他社ARMコアMCU用語
ファームウェア:Firmware ソフトウェア
コンポーネント:Component ハードウェア、周辺回路、コントローラ
コードサンプル:Code Example サンプルプロジェクト、サンプルソフトウェア
PSoC CreatorのTopDesign.cysch(論理回路図) なし

PSoC Creatorも他社同様EclipseベースIDEです。しかし、PSoC MCUの独特な設計手法(これをクセと表現しました)をサポートする強力かつ良くできたツールです。画面構成が他社Eclipse IDEと異なりますが、注意して画面を観察すると、開発中に知りたいリンクがほぼ100%あります。

Cypressは、PSoC/PRoCをMCU:マイコンというより、むしろ、プログラミングも可能なASIC(PSoCがProgrammable System-on-Chipの略から筆者推測)のように考えているため、これらのクセが生じるのだと思います。

Cypress資料

Cypress資料は、質・量・書き方ともに優れています。英語ですが、日本語版もありますので、是非資料を読むことをお勧めします。内容は整理されており、解り易いので、目次のみ見てもほぼ解ります。

筆者はせいぜい数時間しか集中できません。集中力が持続しない方にお勧めの情報把握方法が、目次のみ → 内容類推 → 内容把握です。コンポーネント習得と同様、焦らず段階的、部分的に把握していけば、そのうち全体が見えてきます。

コンポーネントUpdate

PSoC MCUのソフトウェア開発は、コンポーネントAPIのプログラミングです。想定するアプリケーション用に各種コンポーネントを組み合わせて入れた容器、これがデバイスです。

コンポーネントは、それ自身が更新されバージョンを持ちます。例えば、第4世代CapSenseコンポーネントの最新バージョンは、2019年6月現在6.0です。PSoC Creator起動時に、プロジェクト使用中コンポーネント版数を自動的に調べ、Updateがある場合には、Notice Listに通知されます。

殆どの場合、コンポーネントをUpdateしてもトラブルはありません。しかし、コンポーネントUpdateがデバイスハードウェア/ソフトウェア両方に関係するため、コンパイルNGなどになることも稀にあります。

従って、Update時にはArchivesを作成し、元に戻せるようにしましょう。Archives作成は、PSoC CreatorがUpdate時にダイアログを示しますので従ってください。

コンポーネントCode Example

コンポーネント毎にCode Exampleがあります。PSoC Creatorのコンポーネントカタログ掲載のコンポーネントは、いわば標準的なもので、Code Exampleの中には、巧みな使い方をした派生コンポーネントもあります。

CapSenseのCode Example検索方法
CapSenseのCode Example検索方法

評価ボード:KitProg2

本開発で用いた評価ボード:CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit のKitProg2基板は、2019年5月号トラ技第6章P103~P114のPSoC 5記事のことです。

評価ボードのKitProg2部分
評価ボードのKitProg2部分(出典:PSoC 4000S Prototyping Kit Guide)

筆者はこのPSoC 5搭載KitProg2基板を、トラ技付録基板に接続する予定です。つまり、トラ技記事では別途購入が必要であったUSBシリアル変換アダプタの代わりに、トラ技付録基板へのテンプレートプログラミングやデバッグに活用します。

もちろんKitProg2基板は、トラ技6章記事のような使い方もできます。

KitProg2基板は、「SWD(Serial Wire Debug)を使った“汎用”のPSoC MCUプログラミングインタフェースモジュール」です。

KitProg2とPSoC 6の接続例
KitProg2とPSoC 6の接続例(出典:CY8CPROTO-063-BLE Schematic)

上図はPSoC 6がターゲットMCUの例です。ターゲットMCUとSWD IO/SWD CLK+RST/GND/VTARGの5ピンで接続すれば、USB接続のKitProg2モジュール経由でPSoC Creatorプログラミング/デバッグが可能です。

また、USB ⇔ I2C/シリアル変換アダプタとして利用する場合は、KitProg2裏面掲載のターゲットMCUとの結線追加で可能です(評価ボードI2C、UARTは、基板内で配線済み)。

KitProg2裏面のターゲットUARTとI2Cの結線(中央)
KitProg2裏面のターゲットUARTとI2Cの結線(中央)

USB ⇔ I2C変換アダプタ利用時はPSoC Creator付属Bridge Control Panel、また、USB ⇔ UART変換アダプタ利用時はTera Termなどが接続ツールとして使えます。

開発するCapSense UIモジュールと外部機器、または別MCUとの接続デバッグ時に、上記KitProg2基板のUART、または、I2Cの変換アダプタ機能が活用できます。

その4で示したSCBコンポーネントの3モードのうち、UART/I2Cがこれら変換アダプタ経由でPCとの通信に使えます。従って、SCBコンポーネントを手軽に使うには、接続ツールが用意されているUART/I2Cが適しています。

評価ボード:機能分割と低価格

本開発評価ボードのブロック図です。前章KitProg2とPSoC 4000S、さらにEZ-BLE PRoCの3MCU搭載でわずか$15です。

CY8CKIT-145-40XX_PSoC 4000S_Prototyping_Kit_Block Diagram
CY8CKIT-145-40XX_PSoC 4000S_Prototyping_Kit_Block Diagram

EZ-BLE PRoCは、PSoC 4000SのEZ-I2Cコンポーネント経由で得たCapSenseボタンやスライド・バー位置を、スマホへのBluetooth無線送信する10 x 10 x 1.8mmサイズのモジュールです。スマホのアプリケーションは、Cypressサイトからダウンロードできます。

EZ-BLE PRoC用途
EZ-BLE PRoC用途

IoT MCUは、Bluetoothなどの無線通信やスマホ活用のエッジMCU制御も必要になります。

この開発に、無線機能付き高性能MCUを使って、RTOSやソフトウェア/ファームウェアを駆使し開発する選択肢もあります。が、評価ボードのようにモジュール分割し、複数の低価格MCUで組めば、わずか$15で実現できます。

しかも、機能分割した各MCUのソフトウェア開発も簡単です。EZ-BLE PRoCソースコードは、評価ボードサンプルプロジェクト内に有りますので参照してください。

評価ボードはバーゲンプライスです。しかし、その機能分割方法や評価ボードやモジュール活用のシステム開発も選択肢に入れるべきと感じる低価格と機能分割の上手さが解ります。低価格MCUでも使い方次第という好例が、本開発の評価ボードです。

PSoC 4000S/4100S内蔵、第4世代CapSenseの使い方(最終回:関連投稿)まとめ

ソフトウェア開発者向けPSoC 4000S/4100S第4世代CapSenseの使い方
項目 PSoC 4000S/4100S内蔵第4世代CapSenseの使い方(要点)
タッチUIテンプレート構想

(その1)

タッチUIモジュール
単独タッチUIモジュール利用が可能
タッチUIハードウェア

(その2)

1. タッチUIは、指をパッドに近づけた時に生じる静電容量変化で検出。確実に静電容量変化を生むPCBハードウェア:パッド設計が重要。

2. ソフトウェア開発者向けPCB設計ガイドラインの要旨を示し、評価ボードパッド形状の理由と、自己容量式(self-capacitance)、相互容量式(mutual-capacitance)差を説明。

3. 評価ボードパッド部分をトラ技付録PSoC 4100S基板とも接続。 PSoC 4100Sでもテンプレートを動作させPSoC 4000S/4100S両方対応テンプレート化を図る。

CapSense設定

(その3前半)

1. コンポーネントカタログからCapSenseを選びTopDesign.cyschへ配置。

2. コンポーネントデータシートを参照しCapSenseプロパティ設定。基本動作は、Basicタブ設定のみで十分。

3. CapSenseコンポーネント使用GPIOピン設定は、ピンエディタで実行。

CapSenseプログラミング

(その3後半)

1. 基本動作プログラミング教科書に評価ボードサンプルプロジェクトmian.cは最適。

2. 基本動作は、スキャン開始と終了の間、CPUスリープで低電力動作可能。

3. 高感度動作は、スキャン中別処理禁止のブロッキングスキャンを検討。

4. CapSenseプログラミングは、他コンポーネントとの並列処理より時分割処理の方がリスクは少ない。

5. 基本動作CapSense APIは6個。さらに多くのCapSense APIあり。

EZ_I2C(SCB

(その4)

1. EZ-I2Cは、CapSense出力のリアルタイムモニタ用。

2. リアルタイムモニタは、ユーザ開発パッドのCapSenseプロパティ設定に役立つ。

3. EZ-I2Cは、SCBコンポーネント利用法:I2C通信の1種。

4. CapSenseとEZ-I2C間のデータ送受は、RAM利用。

わずか2個コンポーネント利用の第4世代CapSenseの使い方でも、初めてのPSoC MCU開発者向けに要点をまとめると上記になります。最新CapSense動作確認と、殆ど全てのPSoC MCU開発に必要になるSCBコンポーネントの習得が、評価ボードで手軽にできるので教材としては最適だと思います。

PSoC MCUは、コンポーネント単位の開発経験積重ねができます。

一度PSoC開発を経験しておけば、新しい内容はCapSenseプログラミングだけです。今後は開発アプリケーションに応じて使用するコンポーネントを段階的に増やし、PSoC MCU開発の面白さ、奥深さを実感、習得してください。

但し、新規にプロジェクトを開発する時でも、1からコンポーネントを積重ねるのは非効率です。

PSoC Creatorには、新規プロジェクト開始時にPre-populated schematicというプリセット型プロジェクトもあります。しかし、より実務的でプロトタイプ開発に適し、時分割処理を組込んだプロジェクト、これが弊社テンプレートです。

弊社テンプレートは、プロジェクト開始時に最低限必要なコンポーネントが組込み済みで、プロトタイプ開発スピードを上げる効果があります。また、時分割処理ですので、コンポーネント単位の処理追加・削除も容易です。

関連投稿:テンプレート利用Tips

新開発のPSoC 4000S/4100SタッチUIテンプレート発売は、2019/3Q予定です。

このテンプレートをご購入頂ければ、本稿のまとめ文章だけでなく、豊富な日本語コメント付きソースコードと、開発Know Howなども記載した資料が付属します。より具体的に、しかも初心者・中級者にありがちな開発トラブルを回避した第4世代PSoC 4000S/4100S CapSenseの使い方、PSoC MCU開発が短期で効率的に習得できます。

PSoC 4100S CapSenseの使い方(その4)

Cypress PSoC 4100S/4000S内蔵タッチセンサ:第4世代CapSenseの使い方、4回目は、CapSenseとペアで用いるEZ-I2Cコンポーネントを説明します。

PSoC 4100S/4000S内蔵第4世代CapSenseの使い方第4回内容
PSoC 4100S/4000S内蔵第4世代CapSenseの使い方第4回内容

EZ-I2CはCapSenseリアルタイムモニタ出力

EZ-I2Cコンポーネントは、CapSenseの入力状態をパソコン上でリアルタイムモニタする時に使います。

ユーザが開発したハードウェア:タッチパッドやスライド・バーが所望動作をしているかを確認し、必要に応じてCapSenseコンポーネントのBasicタブ以外の詳細プロパティを設定する時に役立ちます。

※CapSenseコンポーネントのプロパティ設定は、その3前半参照。

本開発の評価ボード:CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit でこのリアルタイムモニタを試すときは、TopDesign.cysch上のCapSenseコンポーネントを右クリックし、Launch Tunerで起動されるSense Tuner画面で動作確認ができます。

Launch Tuner起動時Sense Tuner画面
Launch Tuner起動時Sense Tuner画面。CapSense指位置リアルタイムモニタが可能。

EZ-I2Cコンポーネント

デバイス間シリアル通信:Serial Communication Block(SCB)コンポーネントは、I2C(EZ-I2C含む)/SPI/UARTの3モードで動作します。EZ-I2Cコンポーネントは、このI2Cモード通信の1種で、PSoCデバイス用に簡素化したI2Cです。

PSoC Creatorのコンポーネントカタログの⊞Communicationを開くと、既にSCBの3モードで主要プロパティ設定済みのコンポーネントが見られます(補足:SCBコンポーネント3モード章の図参照)。この中からEZ-I2C Slave(SCB mode)をクリック&ドロップでTopDesign.cyschへ配置すれば、詳細なデータシートが見られます。

EZ-I2Cコンポーネントで追加するプロパティ設定は、CapSenseコンポーネントの時(その3前半参照)と同様で、Basicタブ設定のみで十分です。

CapSense → EZ-I2Cは、RAM利用

CapSenseコンポーネントとEZ-I2Cコンポーネント間は、RAMでデータを渡します。TopDesign.cyschの両コンポーネント間を接続する配線などが無いのは、このRAM経由のためです。

EZI2CのAPIを使って両コンポーネントのRAMを接続します。CapSenseコンポーネントデータシートのP8に記載例があります。

CapSence出力のEZ_I2CへRAMデータ送信記述例
CapSence出力のEZ_I2CへRAMデータ送信記述例

※上記ソースコードは、CapSenseがブロッキングスキャンで記述されていることに注意してください(ブロッキングスキャンについては、その3後半参照)。

CapSenseの使い方(その4:EZ-I2Cコンポーネント)まとめ

PSoC Creatorの第4世代CapSenseコンポーネントとペアで用いられるEZ-I2Cコンポーネントを説明しました。

  1. EZ-I2Cコンポーネントは、CapSenseコンポーネント出力のリアルタイムモニタ時に利用。
  2. リアルタイムモニタは、ユーザ開発タッチパッドやスライド・バーのCapSenseプロパティ設定に役立つ。
  3. EZ-I2Cコンポーネントは、SCBコンポーネント利用法:I2C通信の1種。
  4. CapSenseコンポーネントとEZ-I2Cコンポーネント間のデータ送受はRAM利用。

補足:SCBコンポーネントの3モード

SCBの3モードと残りリソース数
SCBの3モードと残りリソース数

評価ボード:CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping KitのCE210709_CapSense_Linear_Slider_and_Buttonsプロジェクトは、本稿で示したようにSCBをEZI2CとしてCapSenseリアルタイムモニタのTuner出力用に1個使用中です。

SCBリソースは、PSoC 4000Sは2個、PSoC 4100Sは3個あります(Resource MeterはPSoC 4000Sの例)。そこで残りのSCBを、PSoC 4000S/4100S専用タッチUIテンプレートモジュールと装置や他MCUとの通信用に使う予定です。

通信用SCBの3モード:I2C/SPI/UARTのどれを使うかは、タッチUIテンプレート発売までに決めるつもりです。但し、パソコンとの通信テスト環境が簡単に準備できるUART、またはI2Cが有力です。この詳細については、次回評価ボードの解説時に説明します。