STM32CubeMXのLow-Layer API利用法 (3)

STM32G0x専用テンプレートで使うSTM32CubeMXのLL API利用法第3回(最終回)は、STM32CubeMXのLL API利用設定、NVIC利用時のユーザ追記箇所を示し、最後にLow-Layer API利用法第1回から本稿まで全体をまとめます。
LL API利用法第1回第2回は、リンク先参照。

LL API利用設定

STM32CubeMXでHAL API利用時と異なるのは、Project Manager>Advanced Settingsの赤囲みの部分のみです。デフォルトは全てHALです。これを、HALからLLへ周辺回路毎に変更します。

LL API利用時のSTM32CubeMX設定
LL API利用時のSTM32CubeMX設定。デフォルトHALなので変更が必要。

第2回で説明したように、LLとHALの混在利用は避けた方が無難です。各周辺回路で両者の選択ができますが、HALかLLの二者択一をお勧めします。また、周辺回路追加・変更時は、デフォルトHALです。LL APIアプリケーション開発時は、注意してください。

STM32CubeMX便利機能に各種設定値のPDF出力:File > Generate Reportがありますが、v5.1.0ではLL/HAL設定値は未出力です。

LL API利用の割込み:NVIC利用時のソースコードユーザ追記箇所

LL APIの割込み:NVIC利用時のユーザ追記箇所は、HAL API利用時に比べ多いです。
※HAL API割込み処理のユーザ追記箇所は、関連投稿:STM32CubeMX生成ファイルのユーザ処理追記箇所を参照してください。

第1回で示したAN5110で説明します。Examples_LLサンプルプロジェクト、EXIT_ToggleLedOnIT_Init.iocのNVIC設定が下図です。このプロジェクトは、評価ボードのUserButtonを押すと割込みが発生しLED4がトグル点滅します。NVICのユーザ追記箇所が赤囲みです。

EXIT_ToggleLedOnIT_Init.icoのNVICユーザ設定
EXIT_ToggleLedOnIT_Init.icoのNVICユーザ設定

GENERATE CODEをクリックすると、stm32g0xx_it.cのL149~L166にEXIT4_15_IRQHandler(void)が自動生成されます。
stm32g0xx_it.cのL160のUserButton_Callback()は、ユーザが追記したCallback関数です。
main.hのL71で、このUserButton_Callback(void)は、ユーザが宣言します。
main.cのL209~L212で、UserButton_Callback(void)は、ユーザがCallback関数の中身を記述します。

LL APIのNVIC利用時のソースコードユーザ追記箇所
LL APIのNVIC利用時のソースコードユーザ追記箇所(赤:ユーザ追記、緑ユーザ追記場所、橙:ユーザ追記ファイル)

STM32CubeMXは、IRQハンドラ関数の割込み発生原因:トリガ検出部分を生成するのみです。

ユーザは、Callback関数とその中身を、「/* USER CODE BEGEN… */ ~ /* USER CODE END… */」で囲まれた3ファイル指定場所に追記します。囲まれた範囲は、STM32CubeMXで再度GENERATE CODEをクリックしても上書きされ残ります。

本章は、NVIC利用時のユーザ追記箇所を示しました。これらは、ADCなどの一般的な周辺回路利用時のユーザ追記箇所とは大きく異なります。
※一般的な周辺回路のユーザ追記箇所は、ADCを例に次回説明します。

STM32CubeMXが生成したソースコードの「どこに、何を、ユーザが追記すべきか」は、生成ソースコード理解が必要です。これには、公式サンプルプロジェクトソースコードの理解が役立ちます。
※これも、次回ADC例を使って、ソースコード理解方法を説明します。

STM32CubeMXのLow-Layer API利用法:全体まとめ

3回に分けて説明した「STM32G0x専用テンプレートで使うSTM32CubeMXのLL API利用法」全体をまとめます。

表1 STM32G0x専用テンプレートで使うSTM32CubeMXのLL API利用法(2019年4月19日)
初期化処理生成

(第1回)

・STM32CubeMXを使う方法と、高性能小サイズなユーザ自作方法の2つ

・STM32CubeMX生成の初期化処理関数名は、接頭語にMX_が付く

・STM32CubeMXを使うと、無限ループ内処理に集中できる

LLとHALの違い

(第2回)

・LL:HALよりもハードウェアに近く、高速軽量なエキスパート向け

・HAL:ハードウェア抽象化で、STM32MCU間で最大限の移植性を保証

・LLは、HALハンドルレジスタを直接上書きする可能性あり

・LLとHAL混在:同一はもとより異なる周辺回路でも混在は避けた方が無難

STM32CubeMX設定

(第3回:本稿)

・Project ManagerのAdvanced Settingsで全周辺回路をLLに一括変更

・周辺回路追加・変更時、Advanced SettingsデフォルトHALに注意

・NVIC生成ハンドラのCallback関数と中身は、ユーザ作成が必要

これら3分野を把握しておけば、STM32CubeMXのLL APIを安全に利用できると思います。

上記まとめで少し気になるのは、安全側評価で「異なる周辺回路でもLLとHAL混在は避けた方が無難」とした点です。本当に異なる周辺回路で混在利用はできないでしょうか?

周辺回路が異なれば、LLがアクセスするハードウェアも当然異なり、競合は無いハズです。例えば、I2CはHAL API、GPIOはLL API利用でも競合問題はなさそうです。

多分、API利用者が、アプリケーションレベルでレジスタ競合などが無いことを確認できれば、「自己責任で異なる周辺回路なら混在可能」だと思います。但しこれを行うには、LLやHALの深い部分まで解読、競合調査が必要です。

AN5110のExamples_MIXサンプルプロジェクトで示された、HALの一部をLLへ置換え、処理高速化を狙う例に止めた方が良さそうです。

以上、STM32CubeMXのLow-Layer API利用法をまとめました。

LL APIとHAL APIはトレードオフ

LL APIを使うと、MCUハードウェア性能を活かし、少ない容量で高性能アプリケーション開発ができます。半面、他のSTM32MCUへの移植性はHAL APIに比べ低下します。

LL APIとHAL APIは、トレードオフの関係です。LLかHAL、どちらのAPIでソフトウェア開発するかは、このトレードオフ評価で決めます。

STM32F0/F1両デバイス性能を1MCUでカバーするSTM32G0xは、専用アプリケーション、つまりLL API開発に値するデバイスだと思います。STM32G0xテンプレートは、LL APIを使い専用テンプレートとして開発します。

次回は、全てのSTM32G0xデバイスで実装済みでIoT MCU必須機能、2.5Msps12ビットADCのLow-Layer APIでの使い方を解説します。

STM32CubeMXのLow-Layer API利用法 (2)

STM32G0x専用テンプレートで使うSTM32CubeMXのLL API利用法第2回は、LL APIとHAL APIの違いを説明します。
専用テンプレートはLL、汎用テンプレートはHALを使う理由がお判りになると思います。

LL(Low-Layer)とHAL(Hardware Abstraction Layer)相対比較

第1回で示したLL API関連資料一覧のUM2319の最初のページに、LLとHALの定義が示されています。

・LL:HALよりもハードウェアに近く、高速で軽量なエキスパート向けレイヤー
・HAL:ハードウェア抽象化で、STM32MCU間で最大限の移植性を保証するレイヤー

MCUハードウェアに依存するLLは、高速・軽量ですが移植性が低いので、LL APIを利用するソフトウェア(=アプリケーション)はそのMCU専用になります。一方、HALはMCU移植性が高いため、HAL API利用アプリケーションはSTM32MCU間で汎用的に使えます。

HALの方が現代的で少ないユーザ記述でアプリケーション開発ができ、さらに汎用なので開発労力が無駄にならない利点があります。しかし、HALが隠蔽している制御の分Flash(ROM)やRAM容量が必要で、LLに比べ低速です。モーター制御など高速処理が必要な部分にはLLの方が向いているかもしれません。

以前の投稿STM32CubeMXの使い方で示した、HAL APIとLL API相対比較表を再掲します。

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

専用テンプレートと汎用テンプレート

LL APIの利点は、ハードウェア性能を活かし少ない容量で高性能アプリケーション開発ができる点です。これは、小Flashで高性能なSTM32G0xデバイスに最適と言えるでしょう。

現状はSTM32G0xが「単独デバイス」でSTM32F0/F1両方のMCU性能をカバーしているので「専用テンプレートが最適」だと言えます。しかし、「STM32G0xシリーズに更に高性能なSTM32G1xデバイス」が発売されれば、移植性が高いHALでSTM32G0xソフトウェア開発を行う方が良くなる可能性はあります。

但しこの場合には、HAL API利用の販売中汎用STM32FxテンプレートをSTM32G0xデバイスへ適用すれば済みます。汎用性を示すこの適用例は、近く投稿する予定です。

特定ハードウェア性能を活かす専用アプリケーションが、少ないROM/RAM容量でも開発できるLL APIメリットを示すデバイス例としてSTM32G0xを選び、専用テンプレートを開発中です。

LL APIとHAL APIのアプリケーションサイズ実例比較

LL API利用時、容量がHAL APIに比べどの程度小さくなるかを実例で示します。

これも前の投稿STM32CubeMXの使い方で示したように、一般的にはLLの方がHAL比60~80%小さくなると言われます。

実例に評価ボードNucle-G071RBに処理は何もせず、64MHz動作のみをLL APIとHAL APIだけを変えてビルドした結果が下記です(SW4STM32 v2.8.1、STM32CubeMX v5.1.0、STM32G0 v1.1.0)。

  text data bss 使用容量 容量比(%)
LL API 3120 12 1564 4696 59
HAL API 9680 20 1708 11408 100

LL API利用の方が 59%小さく実現できることが判ります。

LL APIとHAL API混合利用時の注意点

AN5110には、LLとHAL両方を混在させた公式サンプルプロジェクトのExamples_MIXがNucleo-G071RBでも9例と少ないながら掲載されています。

LLとHAL混在利用の公式サンプルプロジェクト(出典:AN5110)
LLとHAL混在利用の公式サンプルプロジェクト(出典:AN5110)

LLとHALを混在利用時は、色々な注意点があります。UM2319の5章に詳細がありますが、一部抜粋します。

・同じ周辺回路をHALとLLで混在制御するのは避ける
・LLはHALがハンドルしているレジスタを上書きすることがあるので注意

また、UM2303の2章にLLとHALの示すアーキテクチャが示されています。

STM32CubeG0 Firmware Architecture(出典:UM2303)
STM32CubeG0 Firmware Architecture(※説明のため着色しています。出典:UM2303)

つまり、上層HALが下層LLを利用する場合がある訳です。LLは、HALがどのように周辺回路を制御しているかを知ることなく直接ハードウェアレジスタにアクセスします。混在時はレジスタ競合などの詳細な注意がAPI利用者側で必要です。

Nucleo-G071RB 利用時LLとHAL混在利用は、Examples_MIXの9例を除いては避けた方が良さそうです。
BSP(Board Support Package)も、同じ理由でSTM32G0x専用テンプレートには使いません。

※以上は、同一周辺回路でLLとHALを混在利用する場合の注意点です。
※では、周辺回路が異なれば混在は問題ないのでしょうか? 例えば、I2CはHAL、GPIOはLLの場合などです。この場合でも、HALがLLを利用することを考慮すると、アプリケーションレベルでの安全側評価では混在は避け、LLまたはHALに統一して利用する方が無難だと思います。

STM32CubeMXのLow-Layer API利用法 (2):LL APIとHAL APIの違いまとめ

STM32G0x専用テンプレートは、HAL APIとの混在利用は避け、LL APIのみで開発します。

従って、STM32G0xデバイス専用のアプリケーションとなります。
汎用テンプレートSTM32Fxテンプレートは、HAL APIを使っていますので、STM32MCUで汎用的に使えるアプリケーションです。
※このSTM32Fxテンプレート汎用性を示すため、STM32G0xデバイスへこの汎用テンプレートを適用した例を示す予定です。

LLとHAL混在アプリケーション開発は、レジスタアクセス競合などの詳細注意が、API利用アプリケーション側で必要です。
公式サンプルプロジェクトExamples_MIXで示されたやむを得ない場合を除いては、避けた方が無難です。

STM32CubeMXのLow-Layer API利用法 (1)

STM32G0x専用テンプレートで使うSTM32CubeMXのLL(Low-Layer) API利用法を3回に分けて投稿します。

第1回:LL API初期化処理(本稿)
第2回:LL APIとHAL APIの違い
第3回:STM32CubeMXのLL API利用時注意点と第1回~第3回全体まとめ

第1回は、LL API初期化処理です。組込みソフトウェアは、初期化処理と無限ループ内処理の2つから構成され、LL APIでも汎用テンプレートで使ったHAL(Hardware Abstraction Layer)APIでもこの2構成は同じです。

LLとHALに関するSTマイクロエレクトロニクス(以下STM)資料は数多くあります。ただSTMは、STM32ソフトウェア開発は、基本的に「HAL API利用を推薦」していると思います。MCUハードウェア差を隠蔽でき、開発ソフトウェア移植性にも優れているからです。また、STM32CubeMXで生成する関数もHAL APIがデフォルトです。

STM32G0xシリーズLL API関連ソフトウェア資料一覧

筆者がそう考えるからかもしれませんが、STM32G0xシリーズのLL API関連資料は、投稿時点では未だ少ない状況で、リストアップすると表1の4個程度です。近くより小ピン小容量のSTM32G0xがリリースされますので、もっと多くなると期待しています。
※5番目のSTM32Cube ファームウエア テクニカル・プレゼンテーションにはLL API関連はありませんが、BSPやUSB制御をSTM32G0x専用テンプレートでも使う可能性を考慮して追加しました。

高性能ハードウェアを活かしコードサイズもHALより小さいSTM32G0x専用LL API関連資料4+1個の範囲でその利用法をまとめます。

表1 STM32G0xシリーズLL API関連ソフトウェア資料一覧(2019年3 月末)
資料名 概要
AN5110 STM32CubeMXで生成可能なSTM32G0公式サンプルプロジェクトの一覧表。HAL APIのみ、LL APIのみ、HALとLL混在などに区分けされたアプリケーションノート。
UM2303 STM32CubeMXを使いSTM32G0ソフトウェア開発着手時のユーザマニュアル
UM2319 STM32G0のHAL APIとLL APIユーザマニュアル
STM32Cube G0 Firmware Package STM32G0公式サンプルプロジェクト概要を示すオンライントレーニング資料
STM32Cube ファームウエア テクニカル・プレゼンテーション STM32シリーズSTM32CubeMXのHAL/BSP/ミドルウェア/USBライブラリの日本語解説書

STM32CubeMX LL API利用法の習得アプローチ

表1の概要を読むと、実践的にはAN5110のLL APIのみのサンプルプロジェクトとUM2303、万全を期すにはUM2319のLL API解説章の理解が必要です。

そこでLL API利用法は、実践的アプローチから着手し、不明な点やレファレンスが必要な時にUM2319を参照することにします。

STM32G0のLL API利用例:AN5110のExamples_LL

STM32G0x専用テンプレート動作確認評価ボードは、Nucleo-G071RBです。Nucleo-G071RBは、AN5110のExamples_LLで示されたLL API利用サンプルプロジェクト数が75個と掲載ボード中最も多いので前章アプローチに最適です。

これら多くのLL APIサンプルプロジェクトから、2つのGPIOプロジェクトに着目します。この2プロジェクトは、どちらも評価ボード実装済みLD4を250ms毎に点滅させます。

GPIOサンプルプロジェクト差
2つのGPIOサンプルプロジェクト差(※説明のため着色しています)

MXアイコンが付いているGPIO_InfiniteLedToggling_Initは、STM32CubeMXで生成可能、GPIO_InfiniteLedTogglingは生成不可です。その差は、Descriptionによると初期化処理(Initialization FunctionとUnitary Service Function)です。両者ソースコードの初期化処理を下図に示します。

GPIO_InfiniteLedToggling_InitとGPIO_InfiniteLedTogglingの初期化処理の差
GPIO_InfiniteLedToggling_Init(左)とGPIO_InfiniteLedToggling(右)の初期化処理の差

MX_GPIO_Init()が、STM32CubeMX生成可能プロジェクト、Configure_GPIO()が、生成不可プロジェクトの初期化処理です。

つまり、
・MX_GPIO_Init()=Initialization Function (generated by STM32CubeMX)
・Configure_GPIO()=Unitary Service Function (generated by User or by Peripheral Library)
です。※()内は、筆者が追記。

MX_GPIO_Init()は、STM32CubeMXが生成した初期化処理で、MX_が接頭語として付いていることからLLとHAL混在時でも使える関数です。一方、Configure_GPIO()は、MX_GPIO_Init()と同じ機能ながら少ないソースコードで記述できています。

その結果、Configure_GPIO()の方が、MX_GPIO_Init()よりも高性能で小サイズとなります(初期化処理以外は、どちらも同じ)。

MX_GPIO_Init()は、付属オリジナルSTM32CubeMXプロジェクトに変更を加えた時にでも中身はSTM32CubeMXが自動生成する関数で置換えられるだけで、MX_GPIO_Init()はそのまま残ります。一方、Configure_GPIO()は中身のユーザ修正が必要です。

結局、STM32CubeMXで生成可能なGPIO_InfiniteLedToggling_Iniプロジェクトは、ユーザが何らかの変更を加えても初期化処理をSTM32CubeMX任せにでき、無限ループ内にある変更処理に集中できる訳です。

STM32G0xのLL API利用法 (1):初期化処理まとめ

・初期化処理生成はSTM32CubeMXを使う方法と、高性能小サイズなユーザ自作方法の2つがある
・STM32CubeMX生成の初期化処理関数名は、HAL API混在時でも使用可能なMX_が接頭語
・STM32CubeMXを使うとプロジェクト変更時、無限ループ内処理のみに集中できる

STM32CubeMXは、LL APIまたはHAL APIの利用切替えが周辺回路毎に設定可能です。そこで、たとえLL APIのみ利用するプロジェクトでも、初期化処理関数の接頭語には、後々の周辺回路のHAL利用・変更・追加などに備えてML_を付けるのだと推測します。

LL API利用時、初期化処理をSTM32CubeMX任せにすると、ユーザ自作よりも多少サイズが犠牲になります。但しその差は、着目したプロジェクトGPIO_InfiniteLedToggling_Init:2808B、GPIO_InfiniteLedToggling:2604Bと微々(7.3%減)たるものです(SW4STM32 v2.8.1、STM32CubeMX v5.1.0、STM32G0 v1.1.0)。

公式サンプルプロジェクト応用が簡単にできることを考慮すると、その差を十分補える効果があります。

STM32G0x専用テンプレートのLL  API初期化処理方針

以上のことから、LL APIを利用するSTM32G0x専用テンプレートの初期化処理は、STM32CubeMX任せにします。

勿論、STM32G0x専用テンプレート用STM32CubeMXプロジェクトも添付いたしますので専用テンプレート応用・流用は簡単となります(汎用STM32Fxテンプレートは、既にテンプレート用STM32CubeMXプロジェクト添付済みです)。

訂正のお知らせ:STM32CubeMX 5.1.0でSTM32G0 1.1.0公式サンプルプロジェクト生成可能

前投稿で2019年3月末時点ではSTM32G0 V1.1.0の公式サンプルプロジェクト内の付属STM32CubeMX全プロジェクトファイルが未完成と書きましたが、一部改善されました。
つまり、公式サンプルプロジェクトExamples_LLがSTM32CubeMXで生成可能になりました。

お詫びして😔、訂正いたします。

STM32CubeMXは、起動毎に更新チェックやインストール済みのMCUパッケージを自動更新します。STM32G0 1.1.0のままプロジェクトファイルからの生成が可能に変わりましたので、STM32CubeMX本体が更新されたと思うのですが、版数はVersion 5.1.0のままで変わりません(何回か起動を繰返すと正常化するのかもしれません😅、同じ症状の方はお試しを…)。

なんにせよ、STM32G0x専用テンプレートで使うSTM32CubeMXのLL(Low-Layer) API開発には朗報に変わりありません。めでたしめでたしです。

朗報:STM32G0公式サンプルプロジェクトがSTM32CubeMXで生成可能

STマイクロエレクトロニクス(以下STM)の新MCU:STM32G0xシリーズだからこそできた快挙です。AN5110 – Rev 3 – February 2019で、STM32G0公式サンプルプロジェクトが、付属STM32CubeMXプロジェクトファイル(拡張子.ioc)で生成できるようになりました(Table 1のMXアイコン部分)。

AN5110のTable 1
AN5110掲載のTable 1(一部抜粋)

従来サンプルプロジェクトとSTM32G0サンプルプロジェクト比較

例えば、従来のSTM32F0公式サンプルプロジェクトは、エキスパート自作のもの(多分、むかしの標準ペリフェラルライブラリ利用)でした。STM32ソフトウェア開発は、今はSTM32CubeMXコード生成出力へユーザコードを追加する方式です。

従って、従来サンプルソースコードを利用するには、エキスパート作成の必要部分を解読後カットし、STM32CubeMXで生成した自分のソースコードへペーストして流用してきました。

AN5110は、この公式サンプルプロジェクトが、付属STM32CubeMXで直接生成できることを示しています。サンプルプロジェクト流用・活用が、これまで以上に簡単・便利になります。従来のソースコードカット&ペーストから、付属STM32CubeMX変更と生成コードへユーザコードを追加すれば済むからです。

STM32ソフトウェア開発の最重要ツール:STM32CubeMX活用に即した方法がAN5110と言えます。

2019年3月末時点では付属STM32CubeMXプロジェクトファイル未完成

重要なのは、ここからです。

3月末時点では、公式サンプルプロジェクト内のSTM32CubeMXプロジェクトファイルが未完成です。例えば、Table 1一番上のNucleo-G071RBのADC_AnalogWatchdogプロジェクト付属STM32CubeMXプロジェクトファイルを開いた様子が下図です。

ADC_AnalogWatchdogの.ico
図1 ADC_AnalogWatchdogサンプルプロジェクト付属STM32CubeMXプロジェクトファイルの.iocを開いた様子

このままコード生成してもADC_AnalogWatchdogサンプルプロジェクトはできません😴。

ADC_AnalogWatchdogプロジェクトだけではなく、全ての公式サンプルプロジェクトで同様です。

つまり、現時点では、残念ながら公式サンプルプロジェクト内の付属STM32CubeMXプロジェクトファイルは未完成です。公式サンプルプロジェクトの素:STM32G0 1.1.0改版を待たねば、AN5110は実現しません。
前投稿で書いたようにSTM32G0 1.1.0(2019/02/26)は、STMに買収されたAtollic TrueSTUDIOへも未対応でした(図1にTrueSTUDIOフォルダが無いことからも判る)。

新しいMCU発売にはありがちですが、開発に一番重要なツール完成には、開発元ベンダーであっても年単位の時間が必要です(AN5110 Revision historyより)。

STM32CubeMXを使って公式サンプルプロジェクトを生成するAN5110の方向性は、正しいと思います。
新MCU:STM32G0シリーズSTM32G0だけでなく、他の既存MCU:STM32F0/F1シリーズSTM32F0/F1などもこの方向の対応を期待します。

まとめ

以上のように、STM32G0x専用テンプレート開発環境は整いつつありますが、少し待ってから、具体的には、STM32CubeMXへインストールするSTM32G0xシリーズMCUパッケージ、STM32G0 V1.1.0改版を待ってから先へ進めた方が良さそうです。

この改版までの待ち時間は、STM32G0x専用テンプレート開発で使うLL(Low-Layer)APIの習得に充てます。

TrueSTUDIOとSTM32CubeMXインストール方法、STM32G0xとSTM32F0xの差異

STM32G0x専用テンプレートのIDE:TrueSTUDIOを使った開発環境構築手順も、汎用STM32Fxテンプレートのそれと同じです。

本稿はSTM32G0x専用テンプレート開発用IDE TrueSTUDIOとスタンドアロン版STM32CubeMXのインストール方法を示し、インストールしたSTM32CubeMXを使って同じ汎用MCUでもSTM32G0xとSTM32F0xのどこが違うかを具体的にまとめます。

STM32G0x専用テンプレートIDE:TrueSTUDIOを使った開発環境構築手順

2017年5月投稿のSW4STM32のIDE構築手順が左側、これがTrueSTUDIOに変わると右側になります。

表1 TrueSTUDIOとSTM32CubeMXインストール手順とSW4STM32構築時の比較
手順 SW4STM32で構築(2017年5月) TrueSTUDIOで構築(本稿)
1 SW4STM32インストールとUpdate TrueSTUDIOインストールとUpdate
2 STM32CubeMXプラグインとUpdate STM32CubeMXスタンドアロン版とUpdate
3 評価ボードMCUコアのライブラリダウンロード STM32G0パッケージのダウンロード
4 ライブラリのファイル構成確認 同左(しかし、当面見合わせ)
5 評価ボードデモソフト説明と構築環境の動作検証 同左(しかし、当面見合わせ)

差分はIDEと、STM32CubeMXスタンドアロン版をインストールする点、評価ボードがNucleo-F072RBからNucleo-G071RBに変わったので、STM32CubeMXへダウンロードするMCUパッケージにSTM32G0を加える点です。

前半で手順1~5の簡単な説明、後半は、インストールしたSTM32CubeMXを使って同じ汎用MCUグループのSTM32G0xとSTM32F0xが、電源ピン数やデフォルト使用周辺回路が異なることを示します。

手順1 TrueSTUDIOインストールとUpdate

Atollic TrueSTUDIO for STM32 9.3.0(2019/2/22リリース)は、atollicサイトからダウンロードボタンのクリックで入手できます。以後、Windows版で説明します。

ダウンロード後、インストーラを実行すると言語選択ダイアログが現れます。日本語を選択するとインストール後のTrueSTUDIOメニューも自動的に日本語化されます。
インストール後、ヘルプ(H)>更新の検査、をクリックしTrueSTUDIO を最新状態にします。

※TrueSTUDIOインストール検討中の方は、手順4を読んだ後に再検討してください。

手順2 STM32CubeMXスタンドアロン版とUpdate

コード生成ツールSTM32CubeMX V5.1.0は、SW4STM32と今回インストールするTrueSTUDIOの両方で使います。そこで、各IDEのプラグインではなく、スタンドアロン版としてインストールします。インストール方法は、UM1718 Rev28の3.2を参照してください。
インストール後、Help>Check for Updates、をクリックしSTM32CubeMXを最新状態にします。

※UM1718は、チュートリアルも豊富でSTM32CubeMXの重要マニュアルです。全356ページと分量は多いのですが、読む章を選択するなどして目を通すことをお勧めします。

スタンドアロン版はSTM32CubeMX更新が簡単で、1つのSTM32CubeMXで両方のIDEに生成ファイルを出力する時に便利です。

手順3 評価ボードMCUコアのライブラリダウンロード

評価ボードNucleo-G071RBのMCUコアは、Cortex-M0+です。STM32Fxと同じMainstream(≒汎用)MCUですが、新世代の汎用MCUです。
関連投稿:STM32G0x専用Edge MCUテンプレート開発

STM32CubeMXのHelp>Manage embedded software packagesでSTM32G0を選択し、最新版Package1.1.0をインストールします。

STM32G0インストール
STM32G0 MCU Packegae 1.1.0のインストール

手順4 ライブラリのファイル構成確認

STM32CubeMXは優れものソフトウェアで、IDEプラグインからスタンドアロン版へ途中変更してもデフォルトRepositoryディレクトリ(C:\Users\ユーザ名\STM32Cube\Repository)を変えなければ、プラグイン版Packagesの各MCUパッケージがスタンドアロン版へそのまま引き継がれます。

ただし今回のSTM32G0は、ライブラリファイル構成がSTM32F0/F1をインストールした時と一部異なります。

Repository/STM32Cube_FW_G0_V1.1.0\Projects\NUCLEO-G071RB\Templatesフォルダ内にTrueSTUDIOフォルダが無いのです(EWARM/MDK-ARM/SW4STM32は以前と同様有るが、UM1718にもTrueSTUDIO説明無し)。

残念ながら、手順3でインストールしたSTM32G0は、TrueSTUDIOへ生成コードを現状は出力できないようです😴。

SW4STM32の必然性
TrueSTUDIOではなくSW4STM32の必然性を示す結果となった

という訳で、手順4と5以降は、STM32G0がTrueSTUDIOへ対応した後に検証を行います。Communityによると次版のSTM32G0で対応予定だそうです。

STM32G0x専用テンプレート開発IDEに、SW4STM32からSTM買収後のAtollic TrueSTUDIOへの変更必要性を示すつもりが、今現在は、SW4STM32の使用を続ける必然性を示す結果となりました😴。

STM32CubeMXを使ったSTM32G0xとSTM32F0xの差異まとめ

TrueSTUDIOへ生成コードを出力しなければSTM32CubeMXに問題はないので、(個人的にはマルチOS対応SW4STM32が好きですし……気を取り直して…)、STM32CubeMXを使いSTM32G0xとSTM32F0xの違いをまとめます。

STM32G0xもSTM32F0xも共にMainstream、つまり、汎用MCUに属します。しかし、STM32CubeMXを使うと、評価ボード実装の同じ64ピンパッケージでも、電源ピン数やデフォルト利用の周辺回路が異なることが良く判ります。

Nucleo-G071RBとNucleo-F072RB差異
Nucleo-G071RB(左)とNucleo-F072RB(右)の利用ピン差異

Tips:STM32G0 1.1.0では、評価ボードNucleo-G071RB使用中のLD4(PA5)とB1(PC13)がPinout & Configurationに表示されません。その理由は不明ですが、手動で追加設定する必要があり上左図は設定済みのものを示しています。ちなみに、上右図Nucleo-F072RBは、LD2とB1がデフォルトで表示されます。

電源ピン(VDD/VSS)数

STM32G0xは、黄色で示された電源ピン(VDD/VSS)が1組、一方STM32F0xは4組あります。STM32G0xのCortex-M0+コアと70nmプロセスの結果、電力供給1組でも十分動作します。

不要になった電源ピンは、GPIOに変更し同じ64ピンパッケージでもSTM32F0xよりも多くの外部制御が可能です。

パッケージのピン配置

STM32G0xシリーズのパッケージピン配置が下図です。将来リリース予定の4パッケージピン配置は一貫しています。これにより、基板アートワークや周辺部品の配置も一貫した設計計画が立てられます。

電源ピンはどのパッケージでも1組で、左辺中央です。

STM32G0xシリーズパッケージピン配置(出典:STM32G0 and CubeMX Webinar)
STM32G0xシリーズのパッケージピン配置(出典:STM32G0 and CubeMX Webinar)

デフォルト利用周辺回路

STM32G0xのConnectivity(通信処理)は、デフォルトでLPUART1(Low Power UART、Stopモードからの再起動可)ですが、STM32F0xはUSARTです。STM32G0xもUSARTを実装していますが、低電力動作に適したLPUARTを推薦しているためと思います。

LPUARTとUSARTの差異(出典:STM32G0オンライントレーニング)
LPUARTとUSARTの差異(出典:STM32G0オンライントレーニング)

その他の差異

これら以外にも、STM32G0xは、USB Type-C™ Power Delivery controllerや2.5MspsのADC、メモリープロテクションなどIoT Edge MCU向きの周辺回路を実装済みです。

また、Nucleo-G071RB評価ボードのUSBはMicro-Bコネクタ、Nucleo-F072RBはMini-Bコネクタです。

USB Micro-BとMini-Bコネクタ(出典:ウィキペディア)
USB Micro-BとMini-Bコネクタ(出典:ウィキペディア)

まとめ

STM32G0x専用テンプレート開発に使うTrueSTUDIOとSTM32CubeMXインストール方法を示し、そのSTM32CubeMXを使ってSTM32G0xとSTM32F0xの差異を示しました。

STM32CubeMXは2重起動可能です。STM32G0xとSTM32F0xそれぞれのSTM32CubeMXプロジェクトファイルを同時に開いて比べると、各デバイスのデータシートで比べるより差異が早く良く判ります。

STM32G0x専用テンプレート開発IDEには、当面、筆者が好きなSW4STM32が適していることも判りました。

STM32G0x専用テンプレート開発全体像俯瞰

STM32G0x専用テンプレートの開発着手にあたり、汎用STM32Fxテンプレート開発から2017年9月のテンプレート発売までをざっと振り返り、今回の専用開発との差分になりそうな箇所を示しSTM32G0x専用テンプレート開発全体像を俯瞰、力を入れる投稿予定を示します。

汎用STM32Fxテンプレート開発History

汎用STM32Fxテンプレート開発時の主な投稿と内容
年月日 投稿タイトル 主な内容
2017年5 STM32マイコンIDE構築 SW4STM32の構築
2017年6 STM32CubeMXの使い方 HAL APIの選定理由と利用法
STM32CubeMX生成ファイルのユーザ追記箇所 HAL利用時のユーザ追記箇所
2017年8 評価ボードの利用ピン指針 Baseboardとの接続指針
2017年9 STM32Fxテンプレート発売 汎用STM32Fxテンプレート発売

2017年5月当時は、4種ある無償IDEの中からマルチOS(Windows/MacOS/Linux)対応、仏/AC6社のSW4STM32を使いました。2017年末、無償IDE TrueSTUDIO提供のスウェーデン/Atollic社がSTマイクロエレクトロニクス(以下STM)に買収され、公式にはTrueSTUDIOがSTM32マイコンの純正無償IDEに昇格(!?)したようです😅。

関連投稿:STM32のStep-by-Step Guideの、気になる点1:TrueSTUDIO参照

STM32G0x専用テンプレート開発IDE:TrueSTUDIO

そこで、STM32G0x専用テンプレート開発には、TrueSTUDIO無償版(Windows/Linux対応、MacOSなし)を使います。現在SW4STM32を使っている方にも判り易いようにTrueSTUDIOとの差分を説明する予定です。

但し、筆者はSW4STM32利用中の開発者が、あえてTrueSTUDIOに変更する必要は、今のところ少ないと考えています。ソフトウェア開発の主役は、STM純正コード生成ツールSTM32CubeMXだからです。最新STM32CubeMXを使えば、IDE差は少ないと今は思っています。

勿論、TrueSTUDIOの買収昇格時点でBetterなのは当然だと思います。専用テンプレート開発を通じBetterよりもSW4STM32からTrueSTUDIOへ変更するMust条件が判れば、本ブログでお知らせします。

Tips:STMの日本語資料強化の一環なのか、TrueSTUDIOはEclipseベースIDEなのにインストーラは日本語対応、メニューも日本語になっています(下図参照)。但し、C\ユーザ名\Atollic\TrueSTUDIO for STM32 9.3.0\Manuals\Generalにある重要マニュアル5種は全て英文です。例えば、SW4STM32プロジェクトのTrueSTUDIOインポート方法や注意点は、User GuideのP75~に英文で詳しく説明されています。

日本語対応のTrueSTUDIOメニュー
日本語対応のTrueSTUDIOメニュー

STM32CubeMX:LL API(Application Programing Interface)利用

STM32G0x専用テンプレートは、汎用STM32Fxテンプレート開発で使ったHAL(Hardware Abstraction Layer)APIに変わりLL(Low Layer)APIを使います。LL利用により、STM32CubeMX生成ファイルの初期化コードやユーザ追記箇所がHALとは異なります。LL APIの利用は、専用テンプレートの肝ですので、ブログで詳しく説明します。

IoTサービス例:2.5Msps12ビットADC必須+α

汎用STM32Fxテンプレートは、Baseboardと評価ボードを接続し、基本動作完成形のBaseboardテンプレートを開発しました。STM32G0x専用テンプレートは、Arduinoコネクタに何らかのIoTサービスを示すシールドを接続する予定です。しかし、最悪の場合、汎用と同じBaseboard接続にする可能性もあります。

ただし、特に2.5Mspsの12ビットADCは、3タイプある全STM32G0xデバイスに実装済みで、IoTサービス必須機能ですので、このADCを活かしたIoTサービスは実装必須にします。その他のIoTサービスに関しては、今後決めます。

2.5Msps12ビットADC (RM0444より)
2.5Msps12ビットADC (出典:RM0444)

STM32G0x専用テンプレート発売:2019/3Q~

汎用STM32Fxテンプレートは、5か月の期間で開発しました。STM32G0x専用テンプレートは、HALよりもLL API利用難易度が高いことを考慮すると、最低でも同じ開発期間が必要だと思います。

STM32G0x専用テンプレート開発全体像俯瞰の結果

以上、STM32G0x専用テンプレート開発の全体像を俯瞰しました。
SW4STM32からTrueSTUDIO IDEへの変更必要性、STM32CubeMX のLL API利用法、全STM32G0xデバイス実装済みでIoTサービス必須機能2.5Msps12ビットADC使用法、これらを読者の方々が理解できよう力を入れて投稿記事を作成します。

MCUパラメタ設定を改善したSTM32CubeMX version 5

2018年12月STマイクロエレクトロニクス(以下STM)のMCUコード生成ツール:STM32CubeMXがversion 5にメジャー更新しました。本稿は、このSTM32CubeMX version 5について主に旧version 4をご利用中の方を対象に説明します。初めてSTM32CubeMXを利用される方は、インストール方法などは旧version 4で示したコチラの関連投稿と同じですのでご覧ください。

STM32CubeMX version 5への更新方法

STM32CubeMXは、スタンドアロンアプリケーションとして動作させる場合と、Eclipse IDEのプラグインとして動作させる場合があります。更新が簡単なのは、先に説明するスタンドアロン版です。Eclipse IDEは、SW4STM32を例にプラグイン更新方法を示します。

スタンドアロン版STM32CubeMXの更新方法

デフォルト設定を変えてなければ、STM32CubeMX起動時に自動的に更新を検出しInstall Nowクリックで最新版がダウンロードされます。ダウンロード後、一旦STM32CubeMXを終了し、再起動でversion 5への更新が始まります。

STM32CubeMX version 5への更新(スタンドアロン版)
STM32CubeMX version 5への更新(スタンドアロン版)

スタンドアロンの場合は、更新開始時Access Errorが表示されることもあります。この時は、「管理者として実行」で更新プロセスが始まり、STM32CubeMX version 5の初期画面になります。

STM32CubeMX version 5初期画面
STM32CubeMX version 5初期画面

Eclipse IDE(SW4STM32)プラグイン版STM32CubeMXの更新方法

Eclipse IDEのプラグインでSTM32CubeMX機能を追加した場合は、旧プラグインを削除した後にversion 5プラグインをインストールします。SW4STM32のプラグイン削除は、Help>About EclipseからInstallation Detailsボタンをクリックし、Installed Softwareタブから旧STM32CubeMXを選択、Uninstallまたは、Updateクリックで行います。

旧版STM32CubeMXプラグイン削除
旧版STM32CubeMXプラグイン削除

Uninstallの方が確実です。削除後、新しいSTM32CubeMX version 5プラグインを再インストールすれば、スタンドアロンと同じ初期画面が示されます。SW4STM32のUpdate checkでは、STM32CubeMXの更新を検出できませんので、手動でプラグイン削除、更新された新プラグインのインストールが必要です。

STM32CubeMX version 5改善点

version 5のユーザマニュアルUM1718 Rev 27から、以下の点がversion 4から改善されました。
関連投稿:MCU更新情報取得方法と差分検出ツール、の “2PDF資料を比較するDiffPDF” の章参照

・MCUパラメタ設定にマルチパネルGUI採用(UM1718、5章)
・CMSIS-Packサポート(UM1718、7章)
・X-Cube-BLE1ソフトウェアパック(UM1718、14章)
・ST-TouchGFX追加(UM1718、17章)

一言で言うと、5章:カラフルになったパラメタ設定、7章:CMSIS-Pack追加が可能、14章と17章:2チュートリアル追加です。CMSIS-Packとチュートリアルは、必要に応じて理解すれば良いでしょう。

そこで、基本操作の5章STM32CubeMX version 5のパラメタ設定を、弊社STM32F0シンプルテンプレートで用いたSTM32CubeMX version 4プロジェクトファイルを使って説明します。
※STM32F0シンプルテンプレート(¥1,000販売中)をご購入頂いてない方のために、上記プロジェクトファイルのみをコチラから無料でダウンロードできます(zipファイルですので解凍してご利用ください)。

マルチパネルGUIによるMCUパラメタ設定改善の実例

Open Existing Projectsで上記STM32F0シンプルテンプレートプロジェクトファイル:F0SimpleTemplate.iocを選択すると、旧versionで作成されていること、FWも更新されていて、最新環境へ更新(Migrate)するか、FWはそのままSTM32CubeMXのみ更新(Continue)かの選択肢が表示されます。
※MigrateとContinueの差は後述します。

旧版プロジェクトファイルを開いた時のメッセージ
旧版プロジェクトファイルを開いた時のメッセージ

今回は、Migrateを選択すると、見慣れたPinout & Configuration画面が現れます。

STM32F0シンプルテンプレートのプロジェクトを開いた画面
STM32F0シンプルテンプレートのプロジェクトをversion 5で開いた画面

Connectivity >を開くと、STM32F0シンプルテンプレートで使用中USART2の各種パラメタ設定値がマルチパネルで表示されます。

STM32F0シンプルテンプレートプロジェクトのUSART2マルチパネル画面
STM32F0シンプルテンプレートプロジェクトのUSART2マルチパネル画面

このマルチパネル表示がversion 5で最も改善された機能です。従来版では、複数タブで分離表示されていた設定が、1画面のユーザインタフェース:UIに集約されました。より解りやすく、より簡単にMCUパラメタ設定ができます。

その他の機能は、カラフルな見た目になってはいますが、旧versionと殆ど同じと考えて良いと思います(開発元には失礼ですが…😅)。不明な点は、HelpでUM1718が直に表示されるので調べられます。

また、販売中の弊社STM32Fxテンプレート付属説明資料のSTM32CubeMXは、version 4で説明しておりますが、この程度の改版ならば、説明資料をversion 5用に作り直さなくても、ご購入者様に内容をご理解頂けると思います。

旧版プロジェクトファイルを開いた時のMigrateとContinueの差

STM32CubeMXは、UIをつかさどる共通部分と、STM32MCUファミリ毎の個別ファームウエア:FW部分の2つから構成されています。本稿は、UI共通部分の更新を説明しました。FWもバグとりや、ファミリへの新MCU追加などで更新されます。周辺回路の初期化CコードやHAL:Hardware Abstraction Layer library 、LL: Low-Layer library利用のAPI生成は、FW部分が担います。

Migrateは、このUIとFWを同時に最新版へ更新します。一方、Continueは、UI部分のみ更新しFWは既存のままです(安全側更新とも言えます)。FW更新で既製ソフトウェアへ悪影響がでる場合には、Continueを選択することもあるでしょう。しかし、基本的にはUI、FWともに最新版へ更新するMigrateが本来の更新方法です。

万一FW更新でトラブルが発生した時は、デフォルトでSTM32Cube>Repositoryフォルダに新旧FWがzipファイルで保存されていますので、FWのみ元に戻すことも容易です。

*  *  *

Postscript:24日午前3時~午前4時5分に実施されたSTM32G0 and STM32CubeMX 5.0ウェブナーどうでしたか? 解りやすいスライドが豊富で、STM32G0の良さがより理解できました。全機能無償のKeil uVision5対象デバイスにSTM32L0、STM32F0とSTM32G0も加わりました。STM32CubeMX 5.0と評価ボードNUCLEO-G071RBを使ったLチカコード生成も解りやすかったですね😃。
※タイムリーなことに、1月25日STM公式ブログ上で上記一連の処理がYouTubeに投稿されました。

さて、ウェブナー参加で目から鱗が落ちたのは、STM32G0の広い応用範囲と低電力動作を活かすには、デバイス間移植に優れるHAL APIよりも、デバイス最適化のLL API利用が適してかもしれない点です。
HAL利用のSTM32Fxテンプレートとは異なるアプローチ、例えば、STM32Gxテンプレートの新開発が必要になりそうです👍。

関連投稿:HALとLLの違いは、STM32CubeMXの使い方、“STM32CubeMXの2種ドライバライブラリ”の章参照
関連投稿:STM32Fxテンプレートのアプローチは、STM32評価ボードNUCLEO-F072RB選定理由参照

MCU更新情報取得方法と差分検出ツール

MCUプロジェクト開発中は、雑音に邪魔されず当面の課題解決に集中したいものです。しかし、MCU最新情報や開発ツール更新などは、いつ発生するかが不明で、開発中であってもこれらの情報把握は大切です。新情報が、課題解決の決め手になる可能性もあるからです。各ベンダーもこの最新情報提供のために便利機能を提供中です。

今回は、 STマイクロエレクトロニクス(以下STM)に追加された更新情報メール通知機能と、更新情報量が多い時に効率的に差分を検出するツール:DiffPDFを紹介します。

STM最新MCUと更新情報のメール通知機能

STMは、STM32マイコンマンスリー・アップデートを配布中です。月一回、MCU最新情報や資料の更新情報へ簡単にアクセスできます。ただし、マンスリー・アップデートは、全てのSTM32MCU更新情報を集約した言わばポータルサイトです。自分が開発中のMCU情報を含む場合もありますし、そうでない場合もあります。開発スケジュールが押し迫ると、当該重要情報や更新を見落とす事があるかもしれません。

そこで、自分の開発関連情報のみをピックアップし、コンテンツ更新時は毎週木曜日にメール通知する機能がSTMサイトに追加されました。設定方法を、STM32MCUコード生成ツール:STM32CubeMXのユーザマニュアル:UM1718を例に紹介します。

UM1718をお気に入りに登録
UM1718をお気に入りに登録する方法

STMサイトにアクセスし、UM1718で検索すると、右上に「お気に入りに登録>」ボタンが現れます。これをクリックし、「更新情報メールを受け取りますか?」に「はい」を選択するだけです。UM1718以外でも同様です。

更新情報がほしいページの「お気に入りに登録>」クリックで、マイページのお気に入り一覧に追加され、更新発生の木曜に一括してメール通知されます。削除も簡単です。

マイページのお気に入り一覧
マイページのお気に入り一覧、削除も簡単

マンスリー・アップデートよりも早く、しかも、自分の開発必須情報に絞った更新通知メールなので、更新イベントの見落とがなく便利です。

効率的に更新情報量をさばく

更新通知を受け取った後は、どこが変わったかを素早く把握したいものです。新しいSTM32CubeMX version 5のユーザマニュアル:UM1718 Rev 27全327ページを例に、更新箇所特定ツールDiffPDFを紹介します。

STM32CubeMXは、MCU処理スケルトンと周辺回路初期化処理Cソースを生成するツールです。周辺回路の設定はGUIで行い、STM32MCU開発の最初の一歩を踏み出す時に使います。2018年末、このSTM32CubeMXがversion5に更新されました。

STM32CubeMX v5は、v4にマルチパネルGUIを加えパラメタ設定をより容易に、さらに、MCU性能評価やシミュレーション機能なども追加されました。このSTM32CubeMXのユーザマニュアルがUM1718です。

既にSTM32CubeMXを使いこなしている方にとって、Rev 27の327ページは分量が多すぎます(初めてSTM32MCUを使う方は、UM1718を読むことをお勧めします。日本語版もありますが最新版和訳ではないことに注意してください)。このように改版資料の情報量が多い時は、DiffPDFが便利です。

2PDF資料を⽐較するDiffpdf Portable

Diffpdf Portableは、2つのPDF資料を比較し差分を明示するWindows 8.1用のツールで、Windows 10でも動作します。UM1718 Rev27とRev 25をCharactersで比較した例が下記です。

DiffPDF新旧UM1718比較結果
DiffPDFで新旧UM1718を比較した結果

マルチパネルGUI によりSTM32CubeMXのuser interfaceが大きく変わったことが一目で解ります。
※効率的に更新箇所、差分を見つけることに焦点を置きましたので、新しいSTM32CubeMX version 5の説明は、後日改めて行う予定です。

DiffPDFを使えば、どこが変わったかを素早く見つけられるので、ハイライト箇所のみを読めば短時間で内容把握ができます。その結果、更新内容が、現状課題の解決に役立つか否かの判断も早くできます。

まとめ

忙しいプロジェクト開発中であっても、MCU最新情報や開発ツール更新イベントは発生します。

STMサイトに追加されたお気に入り登録を使えば、自分の開発に必要情報の更新時のみ木曜メールで通知されるので、プロジェクト関連情報の変更イベントを見落としなく把握できます。

さらにDiffPDFを使えば、更新情報量が多くても、どこが変わったかが簡単に見つけられるので、更新内容がプロジェクトの課題解決に役立つか否かの判断が早くできます。

MCUのAI機能搭載

スマホの顔/指紋認証や、写真の高度処理などにAI機能(機械学習)が搭載され始めています。本稿は、AI機能搭載プロセッサ最新記事からルネサスマイコン:MCU関連を抜き出し、さらに、STマイクロエレクトロニクスのコード生成ツールSTM32CubeMXに追加されたAI機能拡張パックSTM32Cube.AIを紹介します。

ルネサスMCU AI機能の現状

2019年1月10日のEE Times Japanに、“2019年も大注目! 出そろい始めた「エッジAIプロセッサ」の現在地とこれから”が掲載されました。

MCUだけでなく、スマホ、車載などAI機能を処理するプロセッサ全般の現状分析と今後について、分かりやすく解説されています。AI機能の搭載は、一過性ブームではなくADAS(先進運転支援システム)やセキュリティなど更に多くの処理へ適用されると予想しています。

この記事で、昨年本ブログ投稿のRZファミリ搭載「DRP(Dynamically Reconfigurable Processor)」の現状(図1)と、7nm製造プロセス換算での性能比較(図5)が示されています。

関連投稿:NXPとルネサスのMCU開発動向、ルネサスのMCU開発動向の章

図1:AIプロセッシングを実行する演算器の関係(出典:テカナリエレポート)
図1:AIプロセッシングを実行する演算器の関係(出典:テカナリエレポート)
図5:7nmプロセスで製造した場合の性能(出典:カタリナレポート)
図5:7nmプロセスで製造した場合の性能。小さい程高性能。(出典:カタリナレポート)

日本オリジナルのルネサスAI IPが、公表通り推論処理能力1000倍の開発ロードマップで進めば、低コスト/低電力なMCU AI機能が実現できそうです。RZだけでなく、RL78やRX MCUへの搭載も期待します。

STM32CubeMXにAI機能拡張パックを提供

STMのコード生成ツールSTM32CubeMX version 5.0.1以降から、AI機能実装の拡張パックSTM32Cube.AIが2019年1月3日に発表されました。

Cortex-M4クラスの低電力MCUが前提ですが、ニューラルネットワークを使ったHuman Activity Recognition:人間活動認識(HAR)や、Acoustic Scene Classification:音響シーン分類(ASC)のアプリケーションに適しているそうです。

Human Activity Recognition (HAR)(出典:Neural Networks on the STM32)
Human Activity Recognition (HAR)(出典:Neural Networks on the STM32)
Audio Scean Classification (ASC)(出典:Neural Networks on the STM32)
Audio Scean Classification (ASC)(出典:Neural Networks on the STM32)

MCU AI機能の搭載

現状は、ルネサスはRZ、STMはCortex-M4と高性能MCUがAI機能の対象デバイスです。

例えば、スマホで指紋認証時、本人なのに認証されないとイラッ😡ときます。安全側評価で仕方がないとは思いますが、リアルタイムで結構な処理を行っているのでしょう。例外処理で、カメラ起動などは認証なしで動作させるなどの工夫が見られます。

AI機能は、このように相手が人間なだけにリアルタイムで高負荷な処理になります。MCUへのAI機能搭載は、このかなり高いハードルをこなせる処理能力が必要です。記事にもあるように、プロセス微細化による低コスト/低電力化や、開発環境を含めたベンダー側の対応が普及の鍵になるでしょう。

個人的には、AI機能の「アプリケーションレベルでのライブラリ化」を望みます。ベンダー側でMCU処理能力に応じてライブラリ内部を工夫し、開発者である我々は、MCU選択でAI機能レベル(誤認識率、深層解析能力など)も選択できれば嬉しいですね😁。