STM32G0xのADC利用法

2019年4月26日2019年4月27日 WithHappy

STM32G0xのラインナップは、Value/Access/Access&Encryptionの3製品です。製品により内蔵周辺回路が異なりますが全製品共通回路が、2.5MSPS 12bit ADCです。本稿は、このSTM32G0xのADC利用法を解説します。

STM32G0xのADC資料一覧

時短に役立つ資料を表1にリストアップしました。

表1　STM32G0xのADC資料一覧（2019年4月現在）
資料名	概要
STM32G0 – ADC	STM32G0のADCトレーニング資料。全20ページの内容は判り易く良書。
AN5110	STM32CubeMXを使い生成可能なSTM32G0x公式サンプルプロジェクト一覧表。 HAL API 4個、LL API 8個、HALとLL混在1個のADC公式STM32CubeMXプロジェクト掲載アプリケーションノート。
AN2834	全STM32MCUのADCを精度よく使う方法アプリケーションノート。全49ページ。

3資料と数は少ないですが、ADC内容は盛り沢山です。

STM32G0xのADC公式サンプルプロジェクトAN5110とオンライントレーニング資料を中心に、AN2834も参照するアプローチで解説します。

STM32G0とSTM32F0のADC差

STM32G0は最新IoT Edge MCU、STM32F0は普通の汎用MCUで、どちらもMainstream（≒汎用）MCUですが内蔵12bit ADCは異なります。トレーニング資料P18に特徴の比較があります。

先ず、Conversion：ADC変換時間が0.4usと高速になった点。STM32G0xはMax. 64MHz動作（F0は48MHz）ですが2倍以上高速です。次に、Analog watchdog対応数が増え、バッテリー動作に備え低圧側に動作電圧が広がっています。ハードウェアオーバーサンプリングと高度なシーケンサーが新しい機能です。

勿論、普通のSTM32F0と同じADC制御もできますが、これら新機能を使いこなし、コアMCU負担を減らすように制御すると上手い使い方と言えるでしょう。

トレーニング資料は英文ですが、ポイントを抑えた非常に良くできた資料です。筆者の下手な解説より資料を読んで頂くと、STM32G0xのADCの使い方が判ると思います。

実践的ADCの使い方習得

トレーニング資料が一番効果的ですが、本稿では、開発中のSTM32G0x専用テンプレート動作確認評価ボードNucleo-G071RBで動作するAN5110のExamples_LL掲載サンプルプロジェクト（MXアイコン付きの下記8個）を使って、実践的にLL APIによるADCの使い方を習得します。

なぜLL APIを使うのかは、STM32G0x専用テンプレート開発全体像俯瞰、また、全般的なLL API利用法はSTM32CubeMXのLow-Layer API利用法 (1)～(3)を参照してください。

Descriptionを読むと、大別して4種類のサンプルプロジェクトがあることが解ります。AN5110は、Examples_LLフォルダを名前順に表示したもので、MXアイコン付き8個を制御別に解り易く並び変えたものが表2です。

表2　MXアイコン付き8プロジェクトを制御別に並び換える
制御	基本プロジェクト名（_Init省略）	応用プロジェクト名（_Init省略）
1	ADC SingleConversion TriggerSW	ADC SingleConversion TriggerSW DMA ADC SingleConversion TriggerSW IT ADC SingleConversion TriggerTimer DMA
2	ADC ContinuousConversion TriggerSW	ADC ContinuousConversion TriggerSW LowPower
3	ADC Oversampling	なし
4	ADC AnalogWatchdog	なし

4種類を整理すると、最も基本のADCプロジェクトが1です。

1のSingleConversion_TriggerSoftwareは、ソフトウェアトリガでADCを開始し、ポーリングでデータ取得、データ転送にDMA転送、割込みなどの応用例があります。タイマをトリガにDMA転送の発展例もあります。ADC処理回数は1回です。

2のContinuousConversionは、1のADC処理回数の連続形で、LowPowerでの応用例があります。
※1と2のConversion Mode説明が、トレーニング資料P11にあります。

3のOversamplingは、新機能のサンプルプロジェクトです。
※Hardware Oversampling説明が、トレーニング資料P12にあります。

4のAnalogWatchdogも、新機能の3個AnalogWatchdogを使ったサンプルプロジェクトです。
※AnalogWatchdog説明が、トレーニング資料P13にあります。

いかがですか？　ADCサンプルプロジェクトだけでもおなか一杯で、しかも、これでもADCの豊富な機能の一部抜粋です。さらに、省電力動作や、実際に接続するアナログセンサ出力への対応、加えてAN2834記載の変換精度向上なども考慮すると、ADCだけでも上手く使うのはかなりのスキルや経験が必要なのが分ります。

こういう時は、最も基本のADC_SingleConversion_TriggerSWを先ず理解し、プライオリティに応じて順次ステップアップするのが常套手段です。プライオリティ無しの手当たり次第の理解は、消化不良を起こします😂。
※なおSTM32G0x専用テンプレートは、このADC_SingleConversion_TriggerSWを実装予定です。

ADC_SingleConversion_TriggerSW_InitのSW4STM32インポート

※統合開発環境SW4STM32とコード生成ツールSTM32CubeMXは、Windowsパソコンへインストール済みとします。インストール方法は、関連投稿を参照してください。

先ず、ADC_SingleConversion_TriggerSW_Initを使って、STM32G0xのADC使い方を説明します。

サンプルプロジェクト：ADC_SingleConversion_TriggerSW_InitをIDE：SW4STM32へインポートする方法は色々あります。簡単な方法が下記です。

1.STM32CubeMXをインストールしたPCの、
STM32Cube\Repository\STM32Cube_FW_G0_V1.1.0\Projects\NUCLEO-G071RB\Examples_LL\ADC\ADC_SingleConversion_TriggerSW_Initフォルダを開き、ADC_SingleConversion_TriggerSW_Init.iocをクリックすると、STM32CubeMXが起動します。

2.起動したSTM32CubeMXのProject Manager＞Projectで、Toolchain/IDEをSW4STM32へ変えます。Advanced SettingsタブでADCや周辺回路のLL利用を確認しておきます。

3.GENERATE CODEをクリックし、表示されるダイアログでOpen Projectをクリックすると、SW4STM32が起動します。ワークスペースを入力後、下記Successfully imported the project…が表示されればインポート完了です。

4.SW4STM32でreadme.txtを開くとインポートしたプロジェクト内容が解ります。評価ボード：Nucleo-G071RBのPA.04、またはArduinoコネクタCN8 A2接続の、0から3.3Vまでのアナログ入力電圧を、ソフトウェアトリガでADCスタートし、ADC完了ポーリングでデータ変換完了を確認するのがこのプロジェクトです。
評価ボード単独でもアナログ入力電圧は不定ですが、動作可能です。

サンプルプロジェクトmain.cソースコードの読み方

初めてmain.cを見た方は、ソースコード行数が多いのでビックリするかもしれません。しかし、以下のSTM32CubeMX（以下MX）生成ソースコードの構造を押さえて読めば簡単です。

自動生成ソースコードは、ユーザコード/コメントを追記する部分と、MX生成部分の2つからなる
ユーザコード/コメント部分は、再度MXで新たにコード生成しても、上書きされそのまま残る
コーザコード/コメント部分は、/* USER CODE BEGIN… */ ～ /* USER CODE END… */で囲まれている

従って、サンプルプロジェクトのユーザコード/コメント部分は、「ユーザの代わりにSTMが作成したコードと明示的に説明を加えた箇所」です。注意して読みましょう。それ以外のMX生成部分は、コメントを眺める程度で十分です。

サンプルプロジェクトmain.c解説

ソースコードが読めると、サンプルプロジェクト内の重要関数も解ります。

ADC_SingleConversion_TriggerSW_Initの場合は、L121のConversionStartPoll_ADC_GrpRegular(void)とL120のActivate_ADC(void)が重要関数です。

これら以外のLED点滅関数（L122～124）とMX生成関数（L116～118）は、他のプロジェクトでも使える、いわばLL API開発時の汎用関数です。

ADC_SingleConversion_TriggerSW_Initのmain.c解説。重要関数と汎用関数に分けて読む。

L121へカーソルを移動し、F3を押すとConversionStartPoll_ADC_GrpRegular(void)の定義場所へ簡単に移動できます。

ConversionStartPoll_ADC_GrpRegular(void)は、本来ユーザが作成する関数を、STMが代わりに作成した信頼性が高い関数です。ユーザが利用しない手はありません。ライセンス上も問題なく使えます。

しかも、STMが明示的に付けたコメントがありますので、自分の開発ソースコードへ利用・活用できるようにコメントを読んで内容を理解しておきましょう。内容理解には、readme.txtやトレーニング資料も役立ちます。

同様に、もう1つの重要関数：Activate_ADC(void)も利用・活用できるように理解しましょう。

以上のように重要関数を理解すると、サンプルプロジェクト：ADC_SingleConversion_TriggerSW_Initが示した処理内容とその中から利用できる関数を、自分が開発するプロジェクトの代替関数（≒一種の部品）として使えるようになります。

公式サンプルプロジェクトは、この「高信頼部品の宝庫」です。部品を利用すれば、開発速度が上がります。
また、公式サンプルプロジェクトは、「周辺回路利用時の作法」も明示STMコメントが示しています。

ユーザは、どこに、何を、追記すべきか

前章は、ADC_SingleConversion_TriggerSW_Initを使って、サンプルプロジェクトソースコード：main.cの理解方法を示しました。

一般的な周辺回路のユーザ追記箇所は、前章のように主としてmain.cの無限ループです。周辺回路の初期設定（前章で言えばMX_ADC1_Init(void)やMX_GPIO_Init(void)）は、STM32CubeMXが担うからです。

サンプルプロジェクトには、周辺回路に割込みやDMAを利用した例もあります。

この場合は、STM32CubeMXのLow-Layer API利用法 (3)で示した割込みNVIC利用時のユーザ追記箇所と、本稿で示した周辺回路ユーザ追記箇所の2つに分けてソースコードを理解します。

STM32CubeMXが自動生成したソースコードの、「どこに、何を、ユーザが追記すべきか」は、本章で示した方法でサンプルプロジェクトを理解すれば、自然に解るようになります。
逆に、「どこに、何を、追記すべきか」かが解らないなら、まだサンプルプロジェクト理解が足りないと言えます。

公式サンプルプロジェクトのソースコードを作成するのは、STM32CubeMXと「ユーザ代替のSTMプロフェッショナル」です。両者の役割、作成部分やソースコード構造を理解するのがユーザ開発の第一歩です。

ここでは、表2の中で最も基本のADC_SingleConversion_TriggerSWサンプルプロジェクトを使って、STM32G0xのADC利用法を解説しました。

ADCサンプルプロジェクトは他にも多数あります。自分の開発プライオリティに応じて、他プロジェクトも同様に理解し、ステップアップすれば良いでしょう。

STM32G0x専用テンプレートの目的

MCUソフトウェア開発は、0から着手するのではなく、コード生成ツール：STM32CubeMX活用や前章で示した公式サンプルプロジェクトの部品利用・活用で、効率的に早く開発する、いわゆるプロトタイプ開発が主流です。また、プロトタイプ開発をしないと、競合他社とのビジネスには不利です。

プロトタイプ開発は、開発スピードが要求されます。何がしかの動作確認済みテンプレート（ひな形）と評価ボード、詳しい説明資料があれば、開発着手時のつまずきや手間が省け、より検討すべき項目に時間が割けます。
このテンプレートが、弊社汎用マイコンテンプレートです。

本稿のSTM32G0x専用テンプレートは、新しいEdge MCU「STM32G0xシリーズ専用」テンプレートで、STM32MCUで汎用性がある上記テンプレートとは異なりますが、目的や役割は汎用と同じです。

関連投稿：STM32G0x専用Edge MCUテンプレート開発

STM32G0x専用テンプレートには、本稿で示したADC重要関数や、USB経由のADC変換データパソコン出力、パソコンからの評価ボードLED点滅制御など、STM32G0x開発着手時に最低限必要な機能や部品をあらかじめテンプレートに実装済みです。

STM32G0x専用テンプレートをサンプルプロジェクトとの差分で説明すると、複数サンプルプロジェクトが実装済みで、プロトタイプ開発着手のレベルにより近いプロジェクト、これがテンプレートとも言えます。また、各種サンプルプロジェクト追加や削除が簡単なのも特徴です。

テンプレートのソースコードには、日本語コメントを豊富に付加し、初心・中級開発者が理解できるよう詳細な解説資料付きで提供します。

STM32G0x専用テンプレートを利用すると、STM32G0xプロトタイプ開発を即座に始められます。

STM32G0x専用テンプレートは、近日中に発売予定です。

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プロジェクト添付済みです）。

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を満たさないので利用を断念しました。