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