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

2019年4月19日2019年4月27日 WithHappy

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へ周辺回路毎に変更します。

第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のユーザ追記箇所が赤囲みです。

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関数の中身を記述します。

自動生成されたファイル名（橙色）とユーザ追記位置（緑色）とユーザ追記コード（赤色） — 自動生成されたファイル名（橙色）、ユーザ追記位置（緑色）、ユーザ追記コード（赤色）

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回）

・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両デバイス性能を１MCUでカバーするSTM32G0xは、専用アプリケーション、つまりLL API開発に値するデバイスだと思います。STM32G0xテンプレートは、LL APIを使い専用テンプレートとして開発します。

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

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

2019年4月12日2019年4月15日 WithHappy

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を混在利用時は、色々な注意点があります。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)

2019年4月6日2019年4月12日 WithHappy

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サンプルプロジェクトから、２つのGPIOプロジェクトに着目します。この２プロジェクトは、どちらも評価ボード実装済みLD4を250ms毎に点滅させます。

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年4月3日2019年4月3日 WithHappy

前投稿で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で生成可能

2019年3月31日2019年4月6日 WithHappy

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

従来サンプルプロジェクトと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の差異

2019年3月25日2019年3月31日 WithHappy

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が、電源ピン数やデフォルト使用周辺回路が異なることを示します。

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

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

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

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

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

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

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

スタンドアロン版はSTM32CubeMX更新が簡単で、１つの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へ生成コードを現状は出力できないようです😴。

という訳で、手順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を推薦しているためと思います。

その他の差異

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

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

まとめ

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

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

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

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

2019年3月18日2019年3月30日 WithHappy

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

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

汎用STM32Fxテンプレート開発時の主な投稿と内容
年月日	投稿タイトル	主な内容
2017年5月	STM32マイコンIDE構築	SW4STM32の構築
2017年6月	STM32CubeMXの使い方	HAL APIの選定理由と利用法
2017年6月	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の、気になる点１：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～に英文で詳しく説明されています。

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使用法、これらを読者の方々が理解できよう力を入れて投稿記事を作成します。

STM32G0x専用Edge MCUテンプレート開発

2019年3月10日2019年3月30日 WithHappy

本稿は、STマイクロエレクトロニクス（以下STM）のSTM32G0xデバイス（Cortex-M0+/60MHz）が、汎用MCUのSTM32Fx（F0/Cortex-M0/48MHz、F1/Cortex-M3/72MHz）と異なり、IoT向きの新世代Edge MCUであること、そのテンプレート開発も汎用STM32Fxテンプレートと異なること、これら理由を説明します。

まとめ

はじめに内容をまとめた表1と表2、図1を示し、次章からその詳細理由を説明します。

要するに、STM32G0xデバイスのIoT Edge MCU向きの広いハードウェア性能を活かすには、LL（Low Layer）APIを利用したSTM32G0x専用Edge MCUテンプレート開発が得策だということです。

表1 STM32G0xデバイスとSTM32F0/F1デバイスのハードウェア差
デバイス名	製造プロセス	コア	最大動作周波数	Edge MCU向き周辺回路
STM32G0x デバイス	70nm	Cortex-M0+	60MHz	2.5Msps 12ビットADC、USB Type-C、暗号化処理
STM32F0/F1 デバイス	120nm	Cortex-M0/M3	48/72MHz	特になし（汎用MCU）

表2 STM32G0x Edge MCUテンプレートとSTM32Fxテンプレートの違い
テンプレート名	使用API	流用性	動作確認評価ボード	IoTサービス	重点ポイント
STM32G0x Edge MCU テンプレート	LL（＋HAL）	低い	STM32G071RB	今後決める（TBD）	STM32G0x性能発揮
STM32Fx テンプレート	HAL	高い	STM32F072RB STM32F103RB	特になし（汎用）	デバイス間移植・流用性

テンプレート開発の方向性 — 図1　テンプレート開発方向性。同じメインストリームMCUでもSTM32G0xデバイスは専用性、STM32Fxデバイスは汎用性重視。

STM32G0xデバイス（Cortex-M0+/60MHz）の特徴

STMの場合、新世代Edge MCUと従来MCUの最も異なる点は、製造プロセスです。STM32G0xは70nm、STM32Fxは120nmの製造プロセスです。

製造プロセスによる性能差は、Intelプロセサでお馴染みだと思います。ごく簡単に言うと、製造プロセスを小さくすると、全く同じMCUでも、動作周波数が上がり、消費電力は下がる、販売コストも下がるなど、良いこと尽くめの効果が期待できます。

さらにSTM32G0xは、Cortex-M0の電力消費を改良しCortex-M3の良さを取り入れたCortex-M0+コアを採用しています。つまり、コアと製造プロセスの両方でCortex-M0のSTM32F0デバイスを上回り、動作周波数をCortex-M3のSTM32F1デバイス72MHzに近い60MHzとしたことで、STM32F1と同程度の高性能なのに超低電力動作します。まさに新世代のIoT MCUです。

また、2.5Mspsの12ビットADC、USB Type-C、暗号化処理などEdge MCUに相応しい周辺回路を実装しています（3タイプあるデバイスで実装周辺回路を変え、低価格供給中）。

STM32G0xデバイスとSTM32F0/F1デバイスのハードウェア差をまとめたのが表1です。STM32G0x出現で、STM32F1/F0デバイスで開発する意味は、低下したとも言えるでしょう。
※但し、他デバイスへの移植性・流用性を重視した開発ならSTM32F1/F0デバイスを使い汎用STM32Fxテンプレート使う意味は依然として大きいです。

現在はSTMから何のアナウンスもありませんが、STM32G0xと同じ70nm製造プロセスでCortex-M3/≦100MHzの上位デバイスSTM32G1xが発売されれば、なおさら低下します。

関連投稿に上記特徴の出典などがあります。
関連投稿：守備範囲が広いSTM32G0
関連投稿：STM新汎用MCU STM32G0

STM32G0x専用Edge MCUテンプレートと汎用STM32Fxテンプレートの違い

STM32Fxテンプレートは、ハードウェア差を隠蔽するHAL（Hardware Abstraction Layer）APIを使い、万一性能不足などでデバイスを変える事態が生じても、同じソフトウェアを使えます。従って、STM32F0とSTM32F1の両デバイスで動作するアプリケーションが、ほんの少しの修正で素早く作成できます。

これは、HALのおかげです。HALがデバイスや周辺回路差を吸収するため、アプリケーション側は移植性の高いシンプルな記述ができるのです。その副作用として、アプリケーション記述コードは少なくてもコンパイル後のコードサイズは、周辺回路を直接制御するLL（Low Layer）に比べ大きくなります。

関連投稿：STM32CubeMXの使い方、STM32CubeMXの2種ドライバライブラリの章参照

HALを使うと言うことは、たとえデバイスが変わっても開発したソフトウェアとその労力を無駄にせず、流用・応用できることが最大のメリットです。

汎用「STM32Fxテンプレート」は、この流用・応用に適したテンプレートです。動作確認評価ボードは、STM32F072RBとSTM32F103RBのみですが、全ての汎用STM32Fxデバイスへ応用できます。勿論、ここで示したSTM32G0xデバイスにもこのHALを使う手法は適用可能です。

一方、「STM32G0x専用Edge MCUテンプレート」は、LL APIを使います。つまり、STM32G0x専用のテンプレートです。※LL APIは、使用デバイスにより異なるので専用テンプレートになります。

STM32G1xデバイスが持つCortex-M0からCortex-M3までをカバーする広い適用力と超低電力動作を活かすには、ソフトウェア開発にHAL比60～80％の高速処理のLLを使った方が得策と判断しました。

つまり、STM32G0xデバイスをEdge MCUと認め、そのSTM32G0xの性能や能力を十分に発揮する専用テンプレートがSTM32G0x専用Edge MCUテンプレートです。
※但し、流用性が高い一部機能には、HAL活用も考慮中です。LLとHALは混在可能です。

STM32G0x専用Edge MCUテンプレートと汎用STM32Fxテンプレートの違いをまとめたのが表2、テンプレート開発の方向性を示したのが図1です。

STM32G0x Edge MCU評価ボード選定

STM32G0x専用Edge MCUテンプレートの動作確認評価ボードには、Nucleo-G071RB（￥1,203）を予定しています。

前投稿で示したEdge MCUテンプレート評価ボードの3要件を再掲します。

R1. 低価格、入手先豊富なEdge MCU評価ボード＜￥3,000
R2. 最新Edge MCU使用（2018年後半の新しいIoTトレンドに沿って開発されたEdge MCUであること）
R3. 何らかのIoTサービス例を簡単に示せる

これら3要件のうち、R3：何らかのIoTサービス例を示す要件がNucleo-G071RB 単独ではNGですが、Arduinoコネクタに何らかのIoTサービスシールドを追加することで満たす予定です。

評価ボードNucleo-G071RB。64ピンパッケージでも電源供給が2本のみのなのでアートワーク担当者が喜ぶ。

※STM32G0xデバイスの評価ボードで、IoTのUSB Type-Cサービスを示すSTM32G0 Discovery Kitや、暗号化処理サービスを示すSTM32G081B-EVALは、両方ともR3要件を満たしますが、価格要件R1＜￥3,000を満たさないので利用を断念しました。

守備範囲が広いSTM32G0

2018年12月24日2019年5月18日 WithHappy

2018年12月のSTM32マイコンマンスリー・アップデートのトップページに、先日投稿した新汎用MCU STM32G0の概要とブロック図が記載されました。また、12月18日のEDN JapanにもIoT機器を小型化効率化する32ビットマイコンとしてSTM32G070（48ピン/ROM128KB）が約69セントと安価であることが紹介されています。

STM32G0シリーズブロック図（出典：マンスリー・アップデート2018年12月トップページ）

本稿は、これら新MCU STM32G0記事を整理し、開発ベースとして最適なアクセス・ライン製品STM32G71と評価ボードの入手性、価格について示します。

3製品：バリュー・ライン、アクセス・ライン、アクセス・ライン＆エンクリプション

STM32G0の説明がある時、3製品のどれを説明しているかを区別、意識する必要があります。というのは、STM32G0のアプリケーション守備範囲が、とても広いからです。3製品の特長をまとめたのが下表です。

STM32G0の3製品特徴
製品ライン	型番例	特徴
バリュー・ライン	STM32G70	コスト最重視のエントリクラス製品
アクセス・ライン	STM32G71	ハードウェアセキュリティ搭載の標準製品
アクセス・ライン＆エンクリプション	STM32G81	アクセス・ラインに暗号化機能搭載製品

EDN Japan記事のSTM32G070（48ピン/ROM128KB）の69￠は、バリュー・ラインのことです。マンスリー・アップデートのブロック図は、3製品機能をAND表示したものです。

3製品差を理解するには、STMサイトのSTM32G0製品シリーズと、オンライントレーニング資料STM32G0 Series Presentation P2が役立ちます。

STM32G0の3製品差（出典：STM32G0 Series Presentation P2）

現在供給中の3製品差と、今後のラインナップを整理すると以下になります。

バリュー・ライン（灰色）
アナログフロントエンド向きのアプリケーションに特化した2.5Mspsの高速12ビットADC実装のバリュー・ライン（STM32G070）は、価格最重視のエントリ製品でEDN Japan記事のように1$以下の調達ができます。また、供給中と今後のラインナップの図から、8/20ピンなどの小ピン＆小ROM製品が予定されていることも解ります。

アクセス・ライン（水色）
バリュー・ラインと同様小ピン＆小ROM製品に加え、100ピン＆大ROM製品の予定もあります。アプリケーションに応じてDAC、USB-PO、CAN FDなどの周辺回路が実装可能です。さらに、1.65-3.6Vと他製品より低電圧側への広い動作も特徴です（Presentation P2参照）。

これらの仕様の幅広さから、STM32G0の最も標準的なベースMCUと言えます。アクセス・ラインでプロトタイプ開発しておけば、内蔵周辺回路が同じシリーズのバリュー・ラインやアクセス・ライン＆エンクリプションへそのまま応用・適用できるからです。

アクセス・ライン＆エンクリプション（紺色）
IoTアプリケーションでは必須になるハードウェア暗号化機能をアクセス・ラインに追加しています。

STM32G0の幅広いMCUコア性能

これも先の投稿で示したSTM32FxとSTM32G0の違い図から、STM32G0はSTM32F0より低い消費電力と、STM32F1並みの高性能をハイブリッドしたMCUであることが解ります。つまり、STM32G0（Cortex-M0+/64MHz）で、F0～F1のMCUコア性能範囲をカバーできるのです。

STM32G0のGは、アプリケーション守備範囲の広さを示すGlobal、またはGeneral（汎用性）を表しているのかもしれません。STM32FxのFは、Flexibilityでしょうか？

STM32G0のサンプルソフトウェア

アクセス・ラインSTM32G071RB（64ピン/ROM128KB）実装の評価ボードNUCLEO-G071RBは、STMの公式サンプルソフトウェア数が159個（AN5110参照）と現在最も多く、STM32G0のアプリケーション開発に適していると思います。

この評価ボードとサンプルソフトを活かして開発したソフトは、バリュー・ラインやアクセス・ライン＆エンクリプションへも同じシリーズですので、容易に応用・流用が可能です。

また、暗号化機能搭載のアクセス・ライン＆エンクリプションSTM32G081RB搭載の評価ボードSTM32G081B-EVAL board：$382を使えば、暗号化認証手順や鍵管理などのセキュリティ関連が効率的に習得できるハズ（？）です。
※セキュリティ関連は、ホストとスレーブの2役が必要など、筆者自身不明な点も多いため、今後別途調査したいと考えています。

STM32G0の入手性と価格

ネット通販が盛んになったおかげで、近頃は新発売後1ヶ月も経っていない最新デバイスであっても、個人で1個から入手できます。

2018年12月24日現在、Mouser（マウサー日本）のアクセス・ラインSTM32G071RB（64ピン/ROM128KB）と、評価ボードNUCLEO-G071RBの価格表です。もちろん代理店経由なら、この価格よりも安く入手できるでしょう。

STM32G0の価格（2018年12月調査）
Mouser入手の場合	数量	価格（JPY）
STM32G071RB	1	398
	10	360
	100	298
	1000	213
NUCLEO-G071RB	1	1,203

STM32G0は、たとえ個人でも、入手性良く低価格で入手できると言えるでしょう。

まとめ

新発売STM32G0は、従来メインストームSTM32F0～STM32F1で開発していた広いアプリケーション範囲をカバーできる汎用MCUです。またIoTエッジMCUに必要になる暗号化機能をハードウェアで実装済みの製品もあります。

3種ある製品のうち、アクセス・ラインのSTM32G071RB（64ピン/ROM128KB）実装の評価ボードNUCLEO-G071RB は、STM公式サンプルソフトウェア数が現時点で最も多く、STM32G0の汎用性、広範囲アプリケーション対応性を活かした開発のベースに最適と評価しました。

これら評価ボードとSTM32G071RBデバイスは、個人でも比較的安価に入手できることも分かりました。

STM新汎用MCU STM32G0

2018年12月7日2019年5月16日 WithHappy

2018年12月4日、STマイクロエレクトロニクス（以下STM）の公式ブログで新汎用MCU STM32G0、Cortex-M0+/64MHzを発表しました。以下の特徴があります。
※汎用＝メインストリームと本稿では考えます。

新汎用STM32G0、Cortex-M0+/64MHz、メインストリーム90nmの特徴

STM32メインストリームMCU：STM32FxとSTM32G0の違い（出典：STM32 Mainstream）

「メインストリーム初の90nmプロセスMCU」：従来メインストリームSTM32F0は180nmプロセス
「ハイブリッド」：STM32L4（90nmプロセス）の低消費電力とSTM32F0のメインストリームの両方をハイブリッド
「モアIO」：64ピンパッケージSTM32F071比較でIOピン9本増加、48ピンでもIOピン7本増加
「単一電源供給」：PCBパターン設計が容易
「セキュリティハード内蔵/非内蔵」：128/256ビットAES、セキュアブート、乱数発生器、Memory Protection Unit (MPU)
「USB-C」： IPによりUSB-Type-C可能
「NUCLEO-G071RB board」：低価格評価ボード提供中、「STM32G081B-EVAL board」：$382

STM32G0 Product Lines（出典：STM32G0 Serie Presentation） — STM32G0 Product Linesから3種製品の違いが解る（出典：STM32G0 Series Presentation）

STM32G0オンライントレーニング

データシートよりも解りやすいSTM32G0オンライントレーニング資料が多数あります（要ログイン）。

例えば、以下のような興味深い情報が得られます。各数ページの英文スライド形式ですので、STM32G0以外のMCUを使用中の方でも、チョットした空き時間に読めます。

STM32G0 Series Presentation：内蔵ハードウェアによりValue/Access/Access & Encryptionの3種製品特徴
ARM Cortex-M0+　(Core)：Cortex-M0とM0+の差、Memory Protection Unit 説明
Safety：安全基準とその実現方法
Random Number Generator (RNG)：アナログノイズに基づいた32ビット乱数発生
STM32G0 Boards：NUCLEO-G071RB board解説

STM32CubeMX V5.0.0

STM32G0のコード生成は、STM32CubeMX V5.0.0からサポートされました。

V4までと同じSW4STM32、TrueSTUDIO、両方のIDEで使えます。STM32CubeMX V5が提供するMCUファームパッケージで、本ブログ関連を抜粋したのが下表です。

STM32CubeMX V5.0.0提供MCUファームウェア版数
対象MCU firmware（評価ボード、STM32G0ボード暫定）	最新Version
STM32F1（STM32F103RB、Cortex-M3/64MHz）	V1.7.0
STM32F0（STM32F072RB、Cortex-M0/48MHz）	V1.9.0
STM32G0（V5で新設、STM32G071RB、Cortex-M0+/64MHz）	V1.0.0

STM32Fxテンプレートでも使用中のHAL（Hardware Abstraction Layer）ライブラリでコード生成すれば、STM32F1、STM32F0とSTM32G0間で、流用/応用が容易なソフトウェア開発ができると思います。

まとめ

新発売のSTM32G0は、90nmプロセス初のメインストリーム汎用MCUです。一般的に製造プロセスを微細化すれば、動作クロックが高速になり電力消費も低下します。さらに、STM32G0は、Cortex-M0より性能が向上したCortex-M0+コアの採用により、Cortex-M3のSTM32F1クラスに並ぶ高性能と超低消費電力動作をハイブリッドした新汎用MCUと言えます。

周辺回路では、IoTで懸念されるセキュリティ対策をハードウェアで実施、IOピン数増加、PCB化容易、USB-Type Cインタフェース提供など、各種IoTエッジMCU要求を満たす十分な魅力を持つMCUです。

競合するライバルMCUは、Cortex-M0+のNXP S32K116/S32K118（2018/7発売）などが考えられます。