STM32G0xのLPUART利用法

2019年4月29日2019年5月10日 WithHappy

STM32G0xデバイスは、従来からあるSTM32F0/F1デバイス通信機能USARTに、LPUART（Low Power UART）が新たに加わりました。本稿は、このSTM32G0xのLPUART利用法を解説します。

LPUARTとUSART

オンライントレーニング資料：STM32G0 – USARTのP26にLPUARTとUSARTの機能差分があります。

USART1/2からIrDA：赤外線とLIN：車載通信機能を除いたサブセット版がLPUARTで、USART3/4より8バイトFIFO付きで高機能です。データシート：DS12232 Rev 2から抜粋した各消費電流が下記です。

LPUARTとUSART消費電流（出典：STM32G071xデータシートRev2）

LPUARTは、USART1/2とUSART3/4の中間、USART2.5/3.5が名前として適当かもしれません。API名を考慮し、USART1/2よりもLow Powerという特徴のLPUARTにしたのでしょう。

LPUARTサンプルプロジェクトは1個

前稿STM32G0xのADC利用法STM32G0xのADC利用法で示したように、LPUARTの実践的使い方習得には、AN5110記載のLPUARTサンプルプロジェクト理解が近道です。

しかし、現状の「LPUART」サンプルプロジェクトは、Examples_LLにあるLPUART_WakeUpFromStopの1個のみ、しかも、STM32CubeMXで生成できません（STM32G0x v1.1.0、STM32CubeMX v5.1.0）。
※HAL APIを使うExampleにも、LPUARTサンプルプロジェクトは現状なしです。
※4月末リリースSTM32G0x v1.2.0、STM32CubeMX v5.2.0でも状況は同じです。

一方、STM32CubeMXで生成できるLL API利用「USART」サンプルプロジェクトは多数あります。サンプルプロジェクト流用や活用で自分のソフトウェアを開発する場合、このような需要と供給のミスマッチは良くあります。

このミスマッチ対処方法を以下に示します。

供給USARTサンプルプロジェクトから需要LPUARTプロジェクト作成

初めに示したように、LPUARTはUSART1のサブセット版です。PCとのVirtual COMポート利用なら機能差はありません。従って、以下の手順でUSARTサンプルプロジェクからLPUARTプロジェクトを作成します。

USARTサンプルプロジェクからLPUART プロジェクト作成手順。簡単な変換作業で新プロジェクト作成ができる。

STM32CubeMXのLow-Layer API利用法 (1)で示したAPIユーザマニュアル：UM2319を見ると、ユーザソースコードAPIのUSART部分をLPUARTに変更すれば、API変換ができることも解ります。

この手順の良いところは、2と3が、簡単にできることです。

STM32CubeMXで生成できるサンプルプロジェクさえあれば、2と3は簡単で、しかもミスなくできます。つまり、サンプルプロジェク活用・流用がより簡単・正確にできます。筆者が、AN5110記載サンプルプロジェクトの中で、STM32CubeMX生成アイコン付きにこだわる理由がこれです。

1. USART_Comminication_Tx_Initサンプルプロジェクト動作確認

STM32CubeMXでUSART_Comminication_Tx_InitをSW4STM32用に生成します。評価ボードCN10#21とJP6のRX、CN10#33とJP6のTXを配線します。起動後USER BOTTONを押すとHyper Terminal（Tera Term）にメッセージが出力されLD4が点灯します。

※STM32CubeMXのSW4STM32用の使い方は、前稿ADC利用法のADC_SingleConversion_TriggerSW_InitのSW4STM32へのインポートの章を参照ください。

USART_Comminication_Tx_Initサンプルプロジェクト動作確認ができました。

USART_Comminication_Tx_Initサンプルプロジェクト実行結果

2. STM32CubeMXでUSARTをLPUARTへ変更しコード生成

STM32CubeMXのPinout viewで、USART1をMode: Disable、LPUARTをMode: Asynchronous、115200bps/8Bits Word Lengthに設定します。LPUART1はProject Manager＞Advanced SettingsでデフォルトのHALからLLへ変更します。GENERATE CODEでコード生成します。

3. SW4STM32でユーザコードをUSART APIからLPUART APIへ変更

生成されたSW4STM32の/* USER CODE BEGIN … */～/* USER CODE END … */の間のユーザコードは、コード再生成してもそのまま上書きされます。

従って、ソースコードで旧USART APIが残っているのは、この上書きユーザコード部分だけです。これ以外は、STM32CubeMXがコード生成時にLPUART APIへ変更済みです。

USART_Comminication_Tx_Initの場合は、下図赤線部分などです。これを青線のLPUART APIへ変更します。SW4STM32のFind/Replace機能を使うと、変更がミスなく簡単にできます。

4. LPUART変更後のプロジェクト動作確認

USARTからLPUARTへ変更したので、評価ボードCN10#16とJP6のRX、CN10#18とJP6のTXを配線します。起動後USER BOTTONを押すとHyper Terminal（Tera Term）にメッセージが出力されLD4が点灯します。LPUART変更プロジェクトの動作確認が出来ました。
※出力メッセージは、“LPUART project creation …”に変更しました。

手順１～4で作成したLPUARTプロジェクトから、LPUARTは、USARTと同じ使い方ができ、40%低電力（Table 33の数値比較）なサブセット版であることが解りました。

STM32G0xデバイスの新通信機能としてLPUARTを積極的に活用したいと思います。

※本章は、LPUARTの細かな使い方は、ソースコードを読めば解るという前提で説明しています。ソースコードの具体的な読み方は、前稿：STM32G0xのADC利用法のmain.cソースコードの読み方の章などを参考にしてください。

STM32G0xの実践的LPUART利用法まとめ

実践的に周辺回路利用法を習得するには、サンプルプロジェクト理解が近道です。

現状のSTM32G0x v1.1.0、STM32CubeMX v5.1.0は、LPUART習得に使えるサンプルプロジェクはLPUART_WakeUpFromStop の1個のみで、STM32CubeMXを使って生成はできません。
※4月末リリースSTM32G0x v1.2.0、STM32CubeMX v5.2.0でも状況は同じです。

一方、現状でもSTM32CubeMXで生成できるUSARTサンプルプロジェクトは多数あるので、これらを利用し、求めるLPUARTプロジェクトを作成する簡単でミスの少ない手順を示しました。

作成したLPUARTプロジェクトから、LPUARTは、USART1/2と同じ使い方で40%低消費電力な新通信機能であることが解りました。

速報：STM32CubeIDE

2019年4月27日2019年4月29日 WithHappy

STマイクロエレクトロニクス（以下STM）公式ブログで、中国で開かれたSTM32 SummitにおいてSW4STM32とTrueSTUDIO、STM32CubeMXを統合した新しい統合開発環境：STM32CubeIDEを発表しました。

STM公式ブログ：STM32CubeIDE Makes a Massive Appearance in China。STM32CubeIDEは、既にSTMサイトよりダウンロード可能です。

STM32CubeIDEの主な特徴

EclipseベースIDE
マルチOS対応（Windows、Linux、macOS）
SW4STM32とTrueSTUDIOプロジェクトのインポート機能

STM32CubeIDE

早速STM32CubeIDEをインストールしてみました。所感は、STMが買収したAtollic® のTrueSTUDIOというよりむしろ、SW4STM32へSTM32CubeMXをプラグインしたような画面です。

STM32CubeIDE v1.0.0は、最新版STM32CubeMX v5.2.0とSTM32G0 FW v1.2.0/STM32F0 FW v1.10.0 /STM32F1 FW v1.7.0など開発に必要となるツールもパッケージとしてインストールできます。従来の個別インストールとツールアップデートが面倒だと感じる方には、朗報になるでしょう。

現在STM32G0x専用テンプレート開発は、SW4STM32で継続中です。しかし、販売時にはこのSW32CubeIDEでリリースする方が、SW4STM32からのマイグレーションガイドUM2579も付属済みですので良いかもしれません。

マイグレーション操作は簡単です。販売中のSTM32Fxテンプレートへもこのマイグレーションで対応できると思います。

STM32MCU開発環境の場合、IDE、STM32CubeMX、デバイス毎のFW、これら3つのバージョンがともに最新でないと、上手く動作しないことや不具合発生はありえます（例えば、STM32CubeMX v5.1.0では最新のSTM32G0 FW v1.2.0がインストールできないなど）。

STM32CubeIDEの出現で、バージョン管理が容易になれば良いと思います。以上、速報をお伝えしました。
動画がコチラで見られます。

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専用テンプレートは、近日中に発売予定です。

LibreOffice最新版6.2.3へ更新

2019年4月20日2021年2月8日 WithHappy

LibreOffice版数（2019/04/20現在）
パッケージ	想定ユーザ	2019/4/18版数
最新版（stable）	技術マニア、新しいもの好き、パワーユーザ向け	6.2.2 → 6.2.3
安定版（stable）	ビジネス組織、法人企業、慎重なユーザ向け	6.1.5（変更なし）

2019年4月19日、パワーユーザ向けに新機能を盛り込んだLibreOffice最新版が、6.2.3へマイナー更新されました。安定版は、6.1.5のままです。更新方法や無料テンプレートなどは、関連投稿を参照してください。

新元号「令和」への対応など90件以上の不具合修正が行われたそうです。筆者は、今回の更新でDrawサムネイル表示が、最後に編集したページになったことが気に入っています。

LibreOfficeのDraw — LibreOffice最新版6.2.3のDraw。最後に編集したサムネイル表示が気に入っています。

普通に使っていれば、最新版でも一度も不具合に遭遇したことはありません。しかも、上記サムネイル表示のように細かな改良が進み、使い易く、無料、マルチOS対応など、ビジネスツールとしての要件をLibreOfficeは満たしています。

Microsoft Officeとの一番の違いは更新時のユーザへの気配り

ユーザに対して、最新版と安定版のパッケージが2つあること、マイナー更新は、ユーザが主体的に更新を行うことが、Microsoft Officeの更新手法との違いです。

安定志向ユーザは、何回かの最新版リリース後のほぼ不具合が発生しにくい版数のインストールを行うので、より安全です。また、むやみやたらの更新に対して気に病む必要もありません。

筆者は、最新版ユーザですが、月1回程度の更新にも安定志向ユーザと同様前向きです。万一不具合が発生しても、ユーザデータはそのままで、簡単に前の版数にロールバックできるからです。

一方、Officeに限らずMicrosoft製品の更新には、緊張感と事前準備をユーザに求めます。“気軽にバージョンアップしても大丈夫？最新版「Office」運用で気を付けたい落とし穴”というIT media記事にその原因が説明されています。

C2R：Click to Runの思想

記事によると、Microsoftの新しいアプリケーションインストール形式、C2R：Click to Runは、実行時に最新の差分バイナリを取得し、常に最新バージョンのみをユーザへ提供する仕様です。しかも、万一の不具合に対して、簡単なロールバックができないようです。ユーザ対応としては、システムバックアップなどの準備が必要になりそうです。

ソフトウェアには、不具合は避けられません。十分なテストを行っても100%フリーは無理です。ユーザもこれは認識しています。問題は、不具合を被るユーザへの対応・気配りが、安心感を与えるのか、緊張感を与えるのかだと思います。

このユーザ対応は、一種の製品思想です。Microsoft Officeはビジネスツールの先駆者だけでなく、今や普通の生活に欠かせない普通の人々が使うソフトウェアです。LibreOfficeの安定版相当を提供する思想があっても良いと思うのは筆者だけでしょうか？

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での使い方を解説します。

GWお勧め本：トラ技5月号PSoC 4100S基板付きで販売中

2019年4月15日2019年4月27日 WithHappy

トランジスタ技術2019年5月号が、サイプレス・セミコンダクター（以下サイプレス）のPSoC 4100S搭載基板付きで1,180円（税込）で販売中です。平成最後のトラ技で、PSoC 4と統合開発環境PSoC Creatorの良さが判る雑誌が、安価に入手できます。

ゴールデンウイークの読物に、MCUソフトウェア開発者だけでなくハードウェア開発者へもお勧めです。

トランジスタ技術平成31年5月号PSoC関連目次（※説明のため着色しています。出典：トランジスタ技術）

弊社ブログ掲載MCU中、筆者が最も好きなMCUが、Cortex-M0のPSoC 4シリーズです。MCU技術、サイプレスサイト掲載情報量と質、どれも競合他社より優れていると思います。但し、中級者以上の方には受けが良くても、初心者や初めてサイプレスサイトを訪れる方が解り易いかは疑問です。

ネット並みの手軽さはありませんが、紙媒体のトラ技は、セキュリティ不安や無駄な広告が無く、図表が多く2色で色分けされた文章は、CQ出版社構成済みです。PSoC 4やサイプレスが初めての方でも、短時間で重要箇所を読み・理解するのも簡単です。

ここからは、トラ技を入手した方を前提に、（少々差し出がましいのですが）PSoC 4やPSoC Creatorに解説を加えます。本ブログ対象の、「個人でも低価格で入手性が良いMCUにPSoC 4が該当」するからです。

PSoC 4と4000Sシリーズ

PSoCファミリラインナップがP60コラムにあります。PSoC 4の位置づけが良く解ります。このPSoC 4（Cortex-M0コア）に旧富士通のFM0+買収で得たCortex-M0+コアを採用し、世代改良したのがPSoC 4000Sシリーズです。S付きがCortex-M0+、無しがCortex-M0です。

PSoC 4000Sシリーズのラインナップが下図です。

PSoC 4000シリーズ分類（出典：Cypress Semiconductorメールの一部抜粋）

メール画面切取り画像のためDigi-keyやMouserリンクは無効ですが、PSoC 4000Sシリーズは低価格で入手性も良いMCUであることが解ります。

Entry Level PSoC 4000Sのアナログ機能強化版であるPSoC 4100S：CY8C4146LQI-S433/Flash:64K/RAM:8K搭載基板がトラ技に付属しています。ブレッドボードなどで動作可能です（特設P115～に詳しい説明あり）。

PSoC 4100Sのトラ技採用理由は、第1部の（重い）処理内容や第2部のハイエンドPSoC 5LP（P104コラム参照）へのガイドがし易いからだと思います。

個人的には、先ずEntry LevelのPSoC 4000Sを使って、PSoCの良さをもっと手軽に読者に認知させた方が良いと感じました。4000Sと4100Sの差分は、内蔵アナログ・コンポーネントとその数だからです（MCU提供サイプレスの思惑もあるかもしれませんが…）。
※内蔵アナログ・コンポーネント解説は、特設P143～に詳しく説明されています。

PSoC Creator

PSoC Creatorは、EclipseベースIDEですが、他社IDEと異なります。使い勝手は、トラ技記事にあるように痒い所に手が届くように良くできたIDEです。モニタ1台ではなく、複数の高解像度モニタを使いたくなります。

簡単に言うと、MCUハードウェア開発者でも使える回路図機能とソフトウェア開発機能を全て盛り込んだ環境です。
※特設P129～のPSoC Creator操作マニュアルに詳しく説明されています。

筆者がPSoC 4000SとPSoC Creatorを勧める具体的理由が下記です。

MCUハードウェア開発者向け：自分で開発したハードウェアのテストプログラムを、できるだけ簡単に自作したいが、ソフトウェア開発技術を習得する時間が無い。

MCUソフトウェア開発者向け：制御ハードウェアの詳細を、データシートを読むよりも効率良く理解したい。ハードウェア担当者に直接聞くのも面倒だ。

これらの方々は、是非PSoC Creatorを試してください。ハード/ソフトの垣根がなく、自分が知りたいことをPSoC Creatorだけで調査でき、求める出力をCreateできるのがPSoC Creatorです。

PSoC Creatorを使うと、ハードウェア・ソフトウェア共に既存資産の活用と組み合わせでMCU開発するのが便利で効率的なのが良く解ります。ハードウェア的に言うとコンポーネント活用、ソフトウェア的に言うとAPI活用です。

PSoCの場合、外付けセンサー接続時にあると便利なアンプやコンパレータなどのアナログディスクリート回路や、AND/OR/NOTデジタルディスクリート回路などもMCU内蔵です。システム完成時の実装部品数が削減できます。

さらに、PSoC 4000Sには、タッチ・センサー制御に強いCapSenseも内蔵で、細かな調整もPSoC Creatorでできます。

一度使ってみれば、PSoC CreatorがPSoCの魅力を引き出すというトラ技解説が良く解ります。

PSoC 4000SとPSoC6テンプレート開発の可能性

弊社のPSoC 4/PSoC 4 BLE/PRoCテンプレートは、Cortex-M0対応で2015年発売当時は最新でした。

しかし、トラ技付属のPSoC 4100S搭載基板を活用できるテンプレートや、Entry Level第4世代PSoC 4000Sを使った新テンプレートも開発したくなりました。Cortex-M0+採用による低電力・高効率化が気になります。

例えば、PSoC 4000S CapSense Prototyping Kit（＄15）で新テンプレートを開発すると、タッチ・センサー機能も低価格で直にプロトタイプ開発ができそうです。更に高性能で低価格なPSoC 6ファミリ（Cortex-M4/M0+デュアルコア）にも興味があります。

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の習得に充てます。