汎用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が有力です。この詳細については、次回評価ボードの解説時に説明します。

PSoC 4100S CapSenseの使い方(その3後半)

Cypress PSoC 4 MCU内蔵タッチセンサ:第4世代CapSenseの使い方、3回目後半は、CapSenseのプログラミングです。ソフトウェア開発者にとって一番面白い箇所です。

参照情報:AN85951 PSoC® 4 CapSense® Design Guide.pdf(日本語版)

CapSenseプログラミング理解はサンプルソースコードが最適

AN85951のCapSenseの設計フロー:P9をご覧ください。本稿テーマのCapSenseプログラミングは、8. Firmware Designに相当します(9. はPSoC Creatorの一般的な使い方でCapSenseとは無関係)。

これまでのPSoC 4100S CapSenseの使い方に関する一連の投稿は、1~7の内容を抜粋し、かつ、ソフトウェア開発者向けに説明してきました(従って、本ブログで不明な点は、1~7を参照頂ければ、より理解できます)。

8. Firmware Designドキュメントは、P10に示されています。PSoC Creatorサンプルプロジェクトをクリックすると、P45の4.1.4 サンプルプロジェクトと4.2 ハードウェアキットへジャンプします(コンポーネントデータシートは、第4世代より古いCapSenseのこと)。

さて、このジャンプが意味するのは、「CapSenseプログラミングは、サンプルプロジェクトを読みなさい」ということです。

実際に動作するサンプルプロジェクトのソースコードを見れば、文章で細々プログラミングを説明するよりも一目瞭然ということです。

筆者も、これに完全に同意します。やはりソースコードが、一番良いプログラミング教科書です。…と書くと、これで本稿が終わりますので、少々解説を加えます。

CapSenseプログラミング解析

4.2 ハードウェアキットの開発キット3列目が(名称が違いますが)本開発の評価ボード:CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kit です。

このサンプルプロジェクト:CE210709_CapSense_Linear_Slider_and_Buttonsのmain.cの一部を抜粋します。

評価ボードサンプルソースコードの一部抜粋
評価ボードサンプルソースコードの一部抜粋

初期設定:CapSense_Start()後、無限ループ内でCapSenseの3状態(SENSER_SCAN → WAIT_FOR_COMPLETE→ PROCESS_DATA)遷移を繰返します。default : breakがあるので、さらに別状態の可能性もあります。が、ここでは無視します。
※ENABLE_TUNERは、次回EZ_I2Cで示すCapSenseリアルタイムモニタ機能です。今回は無視してください。

注目すべきは、WAIT_FOR_COMPLETE状態のCySysPmSleep()です。

つまり、CapSenseスキャン開始と終了の間は、CPU:Cortex-M0+はスリープしているのです。この間にCPUで別処理をすることも可能です。スキャンとスリープCPUの割込み起動は、CapSenseコンポーネントが行います。

まとめると、ソースコードから以下が解ります。

・コンポーネント初期設定は、コンポーネント名_Start
・コンポーネントAPIは、コンポーネント名_処理内容
※CapSense以外の全てのコンポーネントでも上記2つは同じ
・CapSenseスキャン開始~終了間のハードウェア処理時間が長いため、CPUをスリープにするのが低電力化に良い。スリープ起動にCapSense割込みを使用。
・PSoC 4000S無限ループは、for(;;)の書き方

基本動作CapSense API

サンプルプロジェクトソースコードで使ったCapSense APIは、全部で6個です。

・CapSense_Start()
・CapSense_IsBusy()
・CapSense_ScanAllWidgets()
・CapSense_ProcessAllWidgets()

LED_Control()で、スライド・バー位置やパッドタッチに応じてLED制御を行うため2個使っています。

・CapSense_GetCentroidPos()
・CapSense_IsWidgetActive()

CapSenseコンポーネントデータシートには、CapSense APIが上記以外にも数多くあります。これらを使うとよりきめ細かな制御も可能です。興味ある方は、参照してください。

CapSenseファームウェアの注意書き

AN89548の6.1 ファームウェアP108~P110に以下の注意書きがあります。
※PSoC MCUでは、他社が言うソフトウェアのことをファームウェアと言います。

“CapSenseハードウェアは高感度アナログシステムなので、CPU並列動作によるデバイス電流の急激な変化は、CapSense検出能力に影響を与える可能性がある。CapSenseを、近接センサやオーバーレイ素材が厚い場合など高感度が必要な場合は、以下のブロッキングスキャンを使うこと。”

ブロッキングスキャンのソースコード
ブロッキングスキャンのソースコード(出典:AN89548)

ブロッキングスキャンとは、サンプルプロジェクトで示した状態遷移を止め、CapSense処理中は別処理を禁止するスキャンです。CapSenseのみにデバイス能力を使いますので、高感度ですがスキャン中の低電力化もしません。

“CapSenseといえども低消費電力設計が望ましいが、PSoC 4000デバイス(←Sなしに注意)は、CapSenseスキャン中のスリープは勧められない。” (以上の、” … “ が、6.1の注意書き)。

第4世代CapSense利用PSoC 4000S/4100Sテンプレート開発方針

本開発は、第4世代CapSense内蔵のPSoC 4000S(←S付き)とPSoC 4100Sデバイスが対象です。

従って、サンプルプロジェクトで示した「CapSenseスキャン中スリープ有り」の方法で開発し、高感度が必要な時は、ブロッキングスキャンを検討するアプローチで良いでしょう。

トラ技付録基板のPSoC 4100Sは、PSoC 4000Sに比べ内蔵アナログコンポーネントが豊富です(PSoC4100SとPSoC 4000Sの主な特徴差は、その1比較表参照)。

AN89548の注意書きから、CapSenseコンポーネントスキャン中の電流変動は禁物なので、欲張って他のアナログコンポーネントとデバイスを共用するのは、時分割処理すれば別ですが、CapSenseの性能を引出すのは大変そうな気がします。

この意味で、内蔵アナログ機能の少ないPSoC 4000SをCapSense専用デバイスとして使うのは、開発のスジは良いと思います。

一般的にCapSenseやADCなどのアナログ機能は、ノイズに敏感で動作中の電流変動にも性能を左右されます。また、トラ技2019年5月号P128、ACアダプタのノイズに注意の章記述から、トラ技付録基板利用時は、供給電源の品質も高いものを使うことが重要です。

以上のことから、CapSenseと別のアナログ機能を利用する時は、並列動作は避け、時分割処理の方がリスクも少ないと思います。

弊社テンプレートは、時分割処理動作です。従って、アナログ単独動作時とほぼ同じ性能を多重時でも出せます。

CapSenseの使い方(その3後半:CapSenseプログラミング)まとめ

PSoC 4000S/4100S内蔵第4世代CapSenseコンポーネントのプログラミング要点を示しました。

  1. CapSense基本動作プログラミング理解に、評価ボードサンプルプロジェクトソースコードは最適。
  2. CapSense基本動作なら、スキャン開始と終了の間、CPUスリープで低電力動作可能。
  3. 高感度CapSenseが必要なら、スキャン中別処理禁止のブロッキングスキャンを検討。
  4. CapSenseプログラミングは、他コンポーネントとの並列動作より時分割処理の方がリスクは少ない。
  5. CapSense基本動作で使うCapSense APIは、6個。さらに多くのCapSense APIあり。

PSoC 4100S CapSenseの使い方(その3前半)

Cypress PSoC 4 MCU内蔵タッチセンサ:第4世代CapSenseの使い方、3回目は、CapSenseの使い方を前後半に分けて示します。前半は、CapSenseのPSoC Creator設定方法、次回の後半は、CapSenseのプログラミングです。

図1 PSoC 4100S/4000S CapSenseの使い方
図1 PSoC 4100S/4000S CapSenseの使い方(第3回前半・後半の内容)

参照情報:PSoC 4 Capacitive Sensing (CapSense) コンポーネントデータシート Version 6.0

PSoC Creatorインストール → トラ技第3章参照

雑誌やブログの場合、各種ツールのインストール手順に多くの紙面が割かれます。本稿も同様でした。しかし、最新IDE:PSoC Creator 4.2インストール手順は、トラ技2019年5月号第3章P129~P142に詳しく記載済みです。

本ブログは、トラ技付録基板も活用予定なので、本稿読者は既にこのトラ技をご購入頂いている前提で、PSoC Creatorインストールや基本的な使い方は、トラ技を参照頂いて省略します(すいません😔)。

関連投稿:GWお勧め本:トラ技5月号PSoC 4100S基板付きで販売中

CapSenseコンポーネントのTopDesign.cysch配置

PSoC Creatorインストール後のPSoC MCU開発手順は、本ブログ記載PSoC Creator 3.3の時と同じです。

つまり、TopDesign.cysch:トップデサイン・スケマティックと呼ぶ回路図へ、PSoC 4000S/4100Sコンポーネントカタログからプロジェクトで使うCapSenseコンポーネントをクリック&ドロップで配置 → そのCapSenseコンポーネントのプロパティを設定しビルド → ビルドで生成された各APIをmain.cで利用 → ソフトウェア完成、という流れです。

図1 CapSenseとEZ-I2Cの2コンポーネントを配置した部分がTopDesign.cyschに相当します。本稿では、CapSenseコンポーネントのプロパティ設定を解説します。そして、次回後半が、ビルド後のAPIを使ったCapSenseプログラミング。
EZ-I2Cコンポーネントは、その4で説明します。

CapSenseコンポーネントのプロパティ設定

PSoC CreatorのTopDesign.cyschへCapSenseコンポーネントを配置し、右クリックしたのが図2です。

Open Datasheet…クリックで、最初に示した参照情報のPSoC 4 Capacitive Sensing (CapSense) コンポーネントデータシートがモニタ上に現れます。使用デバイスコンポーネントの詳細なデータシートが、クリックだけで簡単に参照できるのがPSoC Creatorの特徴です。

図2 Capsenseコンポーネントの配置とデータシート取得
図2 CapsenseコンポーネントのTopDesign.cysch配置とデータシート取得

CapSenseコンポーネントの詳細なプロパティ設定も、このデータシートに記載されています。ゆえに、このデータシートを参照してください…と書くと、これで本稿が終わりますので、少し解説を加えます。

図2のConfigure…をクリックします。コンポーネントのプロパティ設定は、どのコンポーネントでも全てConfigure…で現れるダイアログで設定します。

以下、本開発で用いる評価ボード、CY8CKIT-145-40XX PSoC 4000S CapSense Prototyping Kitを使って設定例を示します(図3)。
上側がCapSenseコンポーネント配置直後のプロパティ設定前、下側がプロパティ設定後です。基本動作に必要なコンポーネントプロパティ設定は、Basicタブのみで十分です。

図3 CapSenceコンポーネントのプロパティ設定
図3 CapSenceコンポーネントのプロパティ設定

配置直後の+アイコンクリックで、タッチUIに使うパッド形状:ButtonやLinear Slider選択 → Sensing mode:CSXやCSD選択という流れです。白抜きセル欄は選択肢あり、グレーセル欄は選択肢なし(変更不可)を示します。

CSXは相互容量式(Mutual-capacitance)のタッチ検出方法、CSDは自己容量式(Self-capacitance)のタッチ検出方法のことです。デフォルトはCSD(Self-cap)です。スライド・バー(SLD)は、自己容量式のみサポートですのでCSD、ボタン(BTN0/1/2)は、CSDかCSXの選択が可能で、評価ボードは相互容量式ですのでCSX(Mutual-cap)です(自己容量式、相互容量式は、その2投稿参照)。

CapSenseコンポーネントのプロパティ設定は以上です。繰り返しますが、基本動作はBasicタブの設定だけで十分です。

Advanceやその他のタブで更に詳細なCapSenseコンポーネントプロパティが設定できます。が、これらの設定は、データシートを参照してください。また、これら設定に、その4で説明するEZ-I2Cが役立ちます。

CapSenseコンポーネント使用GPIOピン設定

CapSenseコンポーネントが使うGPIOピン設定は、Workspace ExplorerのPinsクリックで別表示されるピンエディタ画面で行います。

CapSenseコンポーネントのGPIOピン設定
CapSenseコンポーネントのGPIOピン設定。TopDesign.cyschとは別画面で行うことに注意。

CapSenseコンポーネントのBTN0_Rx0使用ピンを、GPIOのP1[4]に設定する時が上図です。同様に、全てのCapSenseコンポーネントの使用GPIOピンを設定します。緑色□マーカーは、GPIO設定に問題が無いことを示しています。黄色が注意、赤色や灰色は設定NGです。

CapSenseの使い方(その3前半:CapSenseのPSoC Creator設定方法)まとめ

PSoC 4100S/4000S内蔵第4世代CapSenseコンポーネントのPSoC Creator設定方法を示しました。

  1. コンポーネントカタログからCapSenseを選び、TopDesign.cyschへ配置。
  2. 配置後、CapSenseコンポーネントのデータシートを参照し、CapSenseプロパティ設定。基本動作は、Basicタブ設定のみで十分。
  3. CapSenseコンポーネントが使用するGPIOピンの設定は、ピンエディタ画面で行う。

補足:PSoC Creator、コンポーネント、デバイスの関係

PSoC Creatorは、デバイス選択 → コンポーネントカタログから使用コンポーネントをTopDesign.cysch回路図へ配置 → コンポーネントプロパティ設定 → コンポーネント使用GPIOピン設定、という手順でソフトウェア設計を進めます。

それゆえ最初のデバイス選択を誤ると、コンポーネントリソース不足や、使用できるGPIOピンが無いなどの問題が発生します。PSoC Creatorは、この問題回避のため、設計途中であっても使用デバイスの変更が容易です(Project>Device Selection…で表示されるデバイスリストから代替デバイスを選ぶ)。これは、他社IDEに無いCypress PSoC Creatorの特徴です。

デバイスは、色々なコンポーネントを組合せた入れ物にしか過ぎず、コンポーネントこそがPSoCプログラミングの要です。コンポーネントが使う物理的GPIOピン割付を、論理的なTopDesign.cyschとは別画面のピンエディタで行うのもこのためです。

つまり、コンポーネントのプロパティ設定やコンポーネントAPIを使ったプログラミングは、デバイスが変わっても多くの場合そのまま引継げるのです。コンポーネントプログラミングが開発経験として蓄積できます。

PSoC Creatorとコンポーネント、デバイスの関係を示す図
PSoC Creatorとコンポーネント、デバイスの関係を示す図(出典:PSoC Creatorインストール時の図より)

但し、数多いデバイスリストから、最新の第4世代CapSenseコンポーネントを持つデバイスを再選択するのは、結構大変です(新旧コンポーネント混在や、CapSenseのように後方互換が無い例があるため。第4世代CapSense後方互換性は、その1参照)。

2019年6月現在、第4世代CapSenseコンポーネントを使用する時は、PSoC 4000S、PSoC 4100Sシリーズのデバイスから選ぶのが良いでしょう。