総務省:2020年4月以降IoT機器アップデート機能義務化予定

総務省は、電気通信事業法を改正し、2020年4月以降「IoT機器アップデート機能義務化を予定」しているそうです(日経ビジネス2019年9月6日有料会員限定記事、“モノのインターネットに死角あり 狙われるIoT機器”より)。

本稿は、普通のMCU開発者が知るべき最低限のIoT MCUセキュリティ対策をまとめてみたいと思います。

IoT MCUセキュリティ

記事には、“歴史の浅いIoT機器は、開発者とユーザ双方にセキュリティ意識が欠如している“、”開発者は、便利で魅力的な機能搭載を優先し、セキュリティ配慮は2の次”とあります。確かにそうゆう見方はあります。

しかし、サイバー攻撃やセキュリティ関連ニュースが溢れる昨今、開発者/ユーザともに無関心ではないハズです。むしろ、現状のMCU能力では、セキィリティ強化が無理な側面を十分知った上で妥協している(目を瞑っている)のが事実だと思います。

セキィリティ関連記事は、その性質上、英語の省略用語を多用し、漏れがない細かい説明が多いので、全体を把握したい普通のMCU開発者には、解りにくいと筆者は考えています。

そこで、全体把握ができるMCUセキュリティのまとめ作成にトライしたのが次章です。

サイバー攻撃対策

MCUセキュリティ機能は、サイバー攻撃を防ぐための対策です。サイバー攻撃には、以下3種類があります。

  1. ウイルス感染
  2. 通信傍受
  3. 通信データ改ざん

2)通信傍受対策には、暗号化が効果的です。暗号化処理には、データをやり取りする相手との間に鍵が必要で、共通鍵と公開鍵の2方式があります。共通鍵は、処理負荷が公開鍵に比べ小さく、公開鍵は、鍵を公開する分、処理負荷が大きくなる特徴があります。

3)通信データ改ざん検出には、ハッシュ関数(=要約関数)を使います。ハッシュ関数に送信データを与えて得た値をハッシュ(=要約値)と言います。送信データにハッシュを追加し、受信側でハッシュ再計算、送受ハッシュ一致時がデータ改ざん無しと判定します。

2)と3)は、データ通信が発生するIoT MCUセキィリティ機能です。暗号化、ハッシュ関数は、新サイバー攻撃に対し、次々に新しい防御方式が提案される鉾と盾の関係です。MCU外付けセキュリティデバイス(例えばNXPのEdgeLock SE050など)によるハードウエア策もあります。

PCやスマホのようなウイルス対策ソフト導入が困難なMCUでは、1)のウイルス感染対策に、MCUソフトウェアのアップデートで対応します。総務省は、IoT機器にアップデート機能とID、パスワード変更を促す機能を義務付ける予定です。
※開発者自身で溢れるウイルス状況を常時監視し、ソフトウェア対応するかは不明です。

従来のMCUソフトウェアアップデートは、UART経由やIDE接続で行ってきました。しかし、ネットワーク経由(OTA)やアクセス保護のしっかりしたソフトウェア書換えなどを、1)のアップデートは想定しています。

以上、ごく簡単ですが、MCUセキュリティ対策をまとめました。

総務省の「IoT機器アップデート機能義務化」が、具体的にどのようになるかは不明です。ただ、無線機器の技適規制などを考えると、技術ハードルは、かなりの高さになることが予想できます。

サイバー攻撃対策のIoT MCUセキュリティ
サイバー攻撃対策のIoT MCUセキュリティ

ディアルコアや超高性能汎用MCUの背景

簡単にまとめたMCUセキィリティ対策を、IoT機器へ実装するのは、簡単ではありません。

実現アプローチとしては2つあります。

1つ目は、ディアルコアMCU(例えばNXPのLPC54114、関連投稿:ARM Cortex-M4とM0+アプリケーションコード互換)や、超高性能な汎用MCU(例えばSTMのSTM32G4、関連投稿:STM32G0x専用テンプレート発売1章)が各ベンダから発売中です。

これら新世代MCU発売の背景は、従来MCU処理に加え、法制化の可能性もあるセキュリティ処理実装には、MCU処理能力向上が必須なためです。

ワールドワイドにIoT機器は繋がります。日本国内に限った話ではなく、地球規模のIoT MCUセキュリティ実装に対し、ディアルコアや超高性能汎用MCUなどの新世代MCUでIoT機器を実現するアプローチです。

2つ目が、セキュリティ機能が実装し易いMPU(例えばRaspberry Pi 4など)と、各種センサー処理が得意なMCU(旧世代MCUでも可能)のハイブリッド構成でIoT機器を実現するアプローチです。



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は、新しい評価ボードから対応中なので、残念ながら少し待つ必要があるかもしれませんが…😅。

ARM Cortex-M4ベンダと評価ボード(選択失敗談)

本稿は、模索中のCortex-M4評価ボード選択の失敗談です。

初心者・中級者のMCU習得・開発を支援するのが本ブロブの目標です。手段として、個人でも入手性の良い低価格MCU評価ボードを使い、効率良く具体的にポイントを把握できる記事作成を心掛けています。

先日のIoT市場を狙うデュアルコアMCUで、本ブログでこれまで取り上げてきたMCUコア以外にARM Cortex-M4開発経験がIoT要件になる可能性を示しました。そこで、新たにCortex-M4カテゴリをブログに加えたいと考えているのですが、今日現在、適当な評価ボードや開発環境が見つかっておりません。

ARM Cortex-M4カテゴリ

Cortex-M4カテゴリは、急増するIoT開発に対する個人レベルでの先行準備的な位置付けです。

ARM Cortex-M0/M0+/M3コアやルネサスS1/S2/S3コア習得が初級レベルの方は、開発障壁が少し高いかもしれません。なぜなら、Cortex-M4コアの知識ベースはCortex-M0/M0+/M3だからです。この高さ軽減のため、過去のブログ関連投稿をリンク付けします。

中級レベルの方は、Cortex-M4の高いMCU能力を、Cortexコア間のアプリケーション移植やRTOS活用への発展、IoTで高度化するセキュリティ機能の実装などに意識してCortex-M4カテゴリ記事をご覧頂ければ役立つと思います。

32ビットMCUベンダシェアと本ブログカテゴリ

2018年の32ビットMCUベンダシェアが、6月7日投稿InfineonのCypress買収で示されています(下図右側)。

買収成立時の自動車と32ビットMCUシェア(出典:EE Times記事)
買収成立時の自動車と32ビットMCUシェア(出典:EE Times記事)

上位5ベンダ(Runesas、NXP、STM、Cypress、TI)と、本ブログカテゴリとの関係が下表です。

例えば、NXPのLPCマイコンでCortex-M0+記事であれば、MCUカテゴリはLPCマイコン、32ビットコアカテゴリはCortex-M0+などとカテゴリが重複する場合もあります。ただ、本ブログのカテゴリ記事数(n)がベンダシェアや、Cortexコアの人気傾向を示しており、32ビットMCUベンダシェアともほぼ一致します。

2018年MCU上位5ベンダと本ブログカテゴリの関係
MCUベンダ(シェア順) MCUカテゴリ 32ビットコアカテゴリ
Runesas RL78マイコン なし
NXP LPCマイコン/Kinetisマイコン Cortex-M0/M0+/M3/M23マイコン
STM STM32マイコン Cortex-M0/M0+/M3マイコン
Cypress PSoC/PRoCマイコン Cortex-M0/M0+マイコン
Texas Instruments なし なし

※Cypress+Infineonは買収成立と仮定

ルネサスMCUは16ビットコア(S1/S2/S3)のみ掲載中です。理由は、同社32ビットコアMCU開発環境が、コンパイラ1ライセンス当たり10万円程度と高価で、個人レベルでのライセンス購入が困難なため、本ブログ対象外としたからです。

MCUベンダシェアとカテゴリとを俯瞰すると、Texas Instrument(以下TI)とCortex-M4カテゴリがないことが解ります。※32ビットMCUコアでNon ARM系のRunesasを除くと、事実上Cortexコアのみで、その中で記載が無いメジャーMCUコアがCortex-M4です。

そこで、TIのARM Cortex-M4Fマイコン、MSP432の評価ボードを調査しました。

ARM Cortex-M4F搭載MSP432評価ボード

MSP-EXP432P401R LaunchPad Kitとブロック図
MSP-EXP432P401R LaunchPad Kitとブロック図

低消費電力MSP432P401R(ARM Cortex-M4F、48MHz、浮動小数点ユニット、DSPアクセラレーション、256KB/Flash、64KB/RAM)搭載の評価ボード:SimpleLink™ LaunchPad™です(TIは評価ボードをローンチパッドと呼びます)。Digi-KeyMouser秋月電子(秋月電子は在庫限りRev 1.0 (Black)、2100円)で低価格購入可能です。

他社ARM MCU評価ボードで一般的に用いられるArduinoコネクタ増設ではなく、BoosterPack(ブースタパック)と呼ぶTI独自拡張コネクタでBLEやWi-Fi機能を追加します。また、SimpleLink AcademyトレーニングというWebベースの教材などもあります。

MSP432評価ボード単体では、情報量の多さ、価格ともに魅力的です。Cortex-M4クラスの評価ボードでも、Cortex-M0/M0+/M3プラスアルファの低価格で入手できるのには驚きました。プロトタイプ開発は全てCortex-M4で行い、製品時Cortex-M0/M0+/M3を選択する方法もありだと思います。Cortex-M4とM4Fの違いは、本稿PS:パート2動画で解ります。

MSP432P401Rの開発環境は、TI純正無償Code Composer Studio(CCS)です。但し、無償版CCSはMSP432利用時32KBコードサイズ制限付きです。当面32KBでも十分ですが、制限解除には有償版(サブスクリプション)が必要です。

低価格評価ボードがあるのに開発環境に個人での使用に障害がある事象は、Runesas 32ビットMCUと同じです。

以上から本ブログのCortex-M4カテゴリに、TI:MSP-EXP432P401R Launch Pad を使うのは、有償開発環境の点から断念しました(NXP/STM/Cypressは、無償版でもコードサイズ制限無しです)。

まとめ

2018年32ビットMCUベンダシェアから本ブログ記事を俯瞰した結果、Cortex-M4カテゴリとベンダのTexas Instrumentが欠けていることが解り、ARM Cortex-M4F搭載のTI)MSP432P401R評価ボードMSP-EXP432P401R Launch Pad導入を検討しましたが、無償CCSコードサイズ制限のため採用を見合わせました。

勤めている企業の取引の関係でベンダや開発に使うMCUは、既に決まっていることが多いです。しかし、開発者個人レベルでは、ポケットマネーの範囲内で、ベンダもMCU選択も自由です。

ARM Cortex-M4 MCU開発経験はIoT普及期には必須になる可能性があります。普及期への先行準備、また、仕事以外のMCUを手掛けることによる視野拡大、リスク回避手段に適当なCortex-M4評価ボードを選択し、Cortex-M4カテゴリ投稿を計画しています。初回は、Cortex-M4評価ボード選択の失敗談となりました。

PS:TIサイトに下記MSP432日本語版トレーニング動画(要ログイン)があります。ARM Cortex-M4Fを使ったMSP432の全体像が効率的に把握できます。

タイトル 所要時間
パート 1 : MSP432 概要 09:24
パート 2 : ARM Cortex-M4F コア 08:12
パート 3 : 電源システム 05:25
パート 4 : クロック・システム、メモリ 07:53
パート 5 : デジタル・ペリフェラルとアナログ・ペリフェラル 10:07
パート 6 : セキュリティ 05:15
パート 7 : ソフトウェア 07:29
パート 8 : MSP430 から MSP432 05:06

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開発が短期で効率的に習得できます。

STM32CubeIDE v1.0.1更新

STマイクロエレクトロニクス(以下STM)のSTM32マイコンマンスリー・アップデート2019年7月号P9に、STM32CubeIDEのv1.0.1更新が記載されています。

STM32CubeIDE v1.0.1更新内容

内蔵のコード生成ツールSTM32CubeMXがv5.2.0からv5.2.1に変更されたこと、バグ修正が主な更新内容です(RN0114(2019/07/11))。

STM32CubeIDE v1.0.1更新内容
STM32CubeIDE v1.0.1更新内容

最新のSTM32CubeMX v5.2.1により、STM32G0x LL APIを活かしたソフトウェア開発がSTM32CubeIDE v1.0.1でも可能となりました。つまり、弊社推薦のSTM32MCU開発環境:SW4STM32+STM32CubeMX v5.2.1+STM32G0 FW 1.2.0と同じ土俵に今回の更新でなった訳です。

関連投稿:続報STM32CubeIDE

ベースEclipse IDE状況

STM32CubeIDE v1.0.1のベースEclipse IDE は、ECLIPSE™ 2019-03 です。Eclipse最新版は、ECLIPSE™ 2019-06(2019/06/19)ですので、ベースに合わせてSTM32CubeIDEも更新されるでしょう。

Eclipse IDEは、昨年の2018年6月までは、Photon、Oxygen、Neonなどのリリース名が付いていましたが、6月以降は、ECLIPSE™リリース年-月に変更されました。3か月毎に更新され、次回は2019-09予定です。
※メジャー/マイナー更新かは、判りにくくなりました。

STM32CubeIDE v1.0.1使用所感

今回の更新で期待していた日本語対応に関しては、旧STM32CubeIDE v1.0.0からの改善は見られません。

例えば、SW4STM32プロジェクトをSTM32CubeIDEへインポートすると、日本語ソースコードコメントが文字化けします。Preferences>Text Editors>Colors and Fontsを変えても同様です。

付属エディタを使っての直接日本語入力は問題ありませんが、SW4STM32からのマイグレーションツールでの文字化け発生は、回避手段があるとは思いますが面倒です。Atollic社)TureSTUDIO最終版で見せた日本語メニュー実装などは、先の話になりそうです。

また、旧v1.0.0では正しく表示されていたInformation Centerページも、‘表示できません’となります。

RN0114の2.3 Known problems and limitations項目も多いので、あえて今すぐにSW4STM32に変えてSTM32CubeIDE v1.0.1を使う必要性は感じません。土俵(付属開発ツール版数)が同じになっただけです。

現行SW4STM32 → 新STM32CubeIDE切替えタイミング

コードサイズ制限無しのSTM32MCU無償IDEは、旧Atollic社)TrueSTUDIOは既にDiscontinue、AC6社)SW4STM32も新デバイスへの更新をしない可能性が高いと思います。新しいIDE:STM32CubeIDEへ切替えるタイミングが、そろそろ近づいてきました。

筆者としては、SW4STM32の更新状況を注視しつつ現行IDE使用を維持し、次回のSTM32CubeIDE更新タイミングで新IDEへ切替えるつもりです。

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