MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M4コアARMマイコン,IoTマイコン,FreeRTOS,STM32CubeMX,HAL,NUCLEO-G071RB,NUCLEO-G474RE,API生成ツール,CMSIS RTOS

STマイクロエレクトロニクス)STM32MCUを使ってRTOS開発時のSTM32CubeMX、HAL、CMSIS RTOSの3注意点について示します。前編が、STM32CubeMXとHALについてです。CMSIS RTOSは、別途後編で示します。

STM32CubeMXとHAL の注意点を解説した後、サンプルプロジェクトで実例を示すという順番で説明します。

ソースコード生成ツール:STM32CubeMX

STマイクロのソースコード生成ツール:STM32CubeMX(以下CubeMX)は、MCU内蔵周辺回路の初期設定やAPIを、GUIベースで自動生成する非常に便利なツールです。

※MCUベンダのAPI生成ツールを比較した関連投稿は、コチラをご覧ください。

CubeMX生成APIは、ハードウェアを抽象化し、STM32MCU間で最大限の高いソフトウェア移植性を狙ったHAL (Hardware Abstraction Layer)と、よりハードウェアに近くHALよりも高速・軽量なエキスパート向けLL(Low-layer)の2種類から選択可能です。

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

一般的に、HAL APIが好まれます。というのは、このLL APIを利用し開発した2019年6月発売のSTM32G0xテンプレートV1の売上げはゼロでした。対策に、LL APIからHAL APIに変更し再開発した2020年6月発売のSTM32G0xテンプレートV2は、人気があるからです。

これらCubeMXの各種GUI設定や選択APIは、CubeMXファイル(.ico)に構成ファイルとして纏められます。

STM32MCU新規プロジェクト開発時に、この既成CubeMXファイル(.ico)を利用すると、ゼロから着手するのに比べ、効率的かつ間違いなく周辺回路や初期設定ができるため、利用価値の高いファイルです。

特に、ベアメタル比、さらに多くのCubeMX設定が必要となるRTOS開発では、既成CubeMXファイルを再利用するメリットがより高まります。同時に、生成コードの意味も理解しておく必要があります。

HALタイムベース

HALには、他ベンダにない便利なAPI:HAL_Delayがあります。

例えば、10msの待ち処理を行う場合、他ベンダなら、MCUコア速度に応じて適当にループ回数を調整したループ処理で10ms相当の遅延を自作します。しかし、HAL APIならば、HAL_Delay(10)の記述だけで、MCUコア速度に依存しない正確な10ms遅延が実現できます。

これは、HAL自身が、MCU内蔵タイマ:SysTickの利用を前提に設計されているからです。遅延処理を例に説明しましたが、STM32のHAL APIsは、SysTickと強く結びついています。

もちろん、HAL APIをベアメタル開発で利用する場合は、この結びつきに何ら問題はありません。

RTOSタイムベース

FreeRTOSも、タスク(スレッド)状態遷移タイムベースに、SysTickを使います。

これは、FreeRTOSだけでなく他のRTOSでも同じです。SysTickは、その名称が示すようにMCUシステムレベルのタイムベース専用タイマです。

従って、STM32MCUでRTOS開発を行い、かつHAL APIを利用する場合には、RTOS側でSysTickを使うのが、名称に基づいた本来の使い方です。

HALタイムベース変更

そこで、STM32RTOS開発でHAL利用の場合は、HALのタイムベースを、デフォルト使用のSysTickから別のタイマへ変更する必要が生じます。この変更に伴う手動設定も当然必要となります。

*  *  *

ここまでが、STM32RTOS開発におけるSTM32CubeMXとHALに関する注意点です。
これらの注意点が解っていると、次章で示すRTOSサンプルプロジェクトのCubeMXファイルの意味と生成コードが理解できます。

STM32RTOS開発実例

STM32RTOS開発実例に、評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)でRTOS開発する場合を示します。

NUCLEO-G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/32KB)でRTOS開発する時でも同様です。しかも、RTOSサンプルプロジェクトは、STM32G071RBの方が(発売が古いためか?)多いので、NUCLEO-G071RBをお持ちの方は、是非ご自身で試してみてください。

FreeRTOS Example Selector

STM32CubeIDEのFile>STM32 Projectで、新規プロジェクト作成パネルを表示します(最新情報更新のため、表示に少し時間がかかる場合があります)。Example Selectorタブを選択、Middleware>FreeRTOSにチェックを入れ、NUCLEO-G474REのFreeRTOS_Queuesを選択したのが下図です。

NUCLEO-G474REのFreeRTOS_Queues
NUCLEO-G474REのFreeRTOS_Queues

右上欄、Noteの内容が、前半までに示した注意点のことです。参照先UM1722 Rev3は、CMSIS RTOSとFreeRTOSの関係があるのみです。このCMSIS RTOSについては、別途後編で説明します。

Nextをクリックし、FreeRTOS_Queuesサンプルプロジェクトを新規作成します。

さて、FreeRTOS Examples Listが318アイテム(STM32CubeIDE v1.6.1時)もあるので、Exportをクリックし、出力されたExcelファイルをBoardでフィルタリング、NUCLEO-G071RBとNUCLEO-G474REを抽出したのが下図です。

FreeRTOS Example List
FreeRTOS Example List

緑に色付けしたNUCLEO-G071RBの方が、FreeRTOSサンプルプロジェクト数が多いことが判ります。開発予定のSTM版FreeRTOSアプリケーションテンプレートは、Cortex-M4コアが対象ですので、本稿ではNUCLEO-G474REのFreeRTOS_Queuesを実例として使いました。

FreeRTOS_QueuesのSTM32CubeMXファイル

FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル:FreeRTOS_Queues.icoが下図です。グレー文字は変更不可、黒文字は変更可能を示します。

FreeRTOS_Queues.ico
FreeRTOS_Queues.ico

TIM6がグレーなのは、HALタイムベース変更先がTIM6だからです。Kernel settings CPU CLOCK HZのSystemCoreClockがグレーなのは、RTOSタイムベースがSysTickだからです。つまり、本来の名称に基づいたSysTickがRTOS側で使われ、HALの新タイムベースにTIM6が割当済みであることが解ります。

FreeRTOS APIは、変更不可のグレーCMSIS V1です。ここは、後編で説明します。

デフォルトDisabledのUSE IDEL HOOKを、Enabledに変更し、ソースコード自動生成のGenerate Code(Alt+K)を実行してください。

HALタイムベースTIM6変更結果

FreeRTOS_QueseのTIM6とHook関数
FreeRTOS_QueseのTIM6とHook関数

app_freertos.cのL62に、Hook関数:vApplicationIdleHoolのひな型が自動生成済みです。ここへWFIを追記すれば、FreeRTOSアイドル時に低電力動作ができます。コチラのNXP版関連投稿Step5: FreeRTOS低電力動作追記と同じです。

main.cのL289は、TIM6満了時動作です。HAL_IncTick()が自動生成済みです。ベアメタル開発のSysTickからTIM6へHALタイムベースが変更されたことが解ります。

そのTIM6は、stm32g4xx_hal_timebase_tim.cで、1MHz=1ms満了に初期設定済みです。

つまり、STM32RTOS開発でHAL利用時に必要となる変更が、「全てCubeMXで自動生成済み」なのが解ります。

※上図は、USE_TICK_HOOKもEnabledへ変更した例です。Disabledへ戻すなどして、CubeMX自動生成ファイルが変化することを確かめてください。

この実例のように、CubeMX付属RTOSサンプルプロジェクトのCubeMXファイル(*.ico)を再利用すれば、周辺回路や初期設定ミスを防ぎ、RTOS新規アプリケーション開発が容易になることが解ります。

まとめ

STM32MCUでRTOS開発を行う時の3注意点、STM32CubeMX、HAL、CMSIS RTOSのうち、前編としてSTM32CubeMX、HALの2注意点とサンプルプロジェクトを使ってその実例を示しました。

RTOS開発では、既成STM32CubeMXファイル再利用価値が高まること、HALタイムベース変更の必要性がご理解頂けたと思います。3つ目のCMSIS RTOS関連は後編で示します。

あとがき

ベアメタル開発経験者であっても、STM32RTOS開発時、CubeMXのNoteを読むだけで、ベアメタル開発では何の問題も無かったHAL タイムベース変更理由が解り、その結果生じるCubeMXファイルや自動生成ソースコードの中身が理解できる方は、少ないと思います。本稿は、この変更理由と生成コードに説明を加えました。

STM32CubeMXは、STM32MCU開発に必須で強力なAPI生成ツールです。が、時々、説明不足を感じます。問題は、どのレベル読者を相手にするかです。エキスパートなら説明不要ですが、初心者ならゼロから説明しても解らないかもしれません。文章による組込み技術説明が、難しいのが根本原因でしょう😂。

そんな組込み開発ですが、文章だけでなく、「実際に評価ボードと手足を使って慣れてくると、案外すんなり簡単に理解、習得できる方が多いのも組込み開発」です。

販売中のNXP版FreeRTOSアプリケーションテンプレートにも、本稿同様、詳しいFreeRTOS解説を付けています(一部ダウンロード可能)。FreeRTOS開発を手軽に試せ、習得を支援するツールです。

MCU:マイコン,STM32マイコンテンプレート,Cortex-M0+,IoTマイコン,STM32CubeMX,HAL,API,汎用,STM32Fx,STM32G071,STM32G0x,専用テンプレート,移植

LL APIを利用するSTM32G0x「専用テンプレート」開発は、3月からの投稿で一応目安が付きました。
※投稿下欄タグ:専用テンプレートをクリックすると本稿を含め関連投稿が読めます。

これらの投稿で販売中の汎用STM32Fxテンプレートは、HAL APIを使っているので別STM32MCU、例えばG0シリーズMCUのSTM32G071RBなどへの使用・移植も簡単であることを何度か書いてきました。

そこで、この「汎用テンプレート」のSTM32G071RBへの使用法を説明します。

STM32Fxテンプレートは、図1に示すようにF0シリーズMCUのSTM32F072RBと、F1シリーズMCUのSTM32F103RB両方で動作確認済みです。本稿は、このSTM32FxテンプレートをSTM32G0へポーティングします。

汎用STM32Fxテンプレートのソフトウェアアークテクチャ
汎用STM32Fxテンプレートのソフトウェアアークテクチャ

汎用STM32FxテンプレートのSTM32G0x使用法まとめ

  • HAL APIはSTM32MCUで共通なので、HAL API利用アプリケーション(この場合はテンプレート、STM32Fx Template)は、STM32デバイスが変わってもそのまま使える
  • HAL APIより下層のソフトウェアは、STM32CubeMXを使って自動生成
  • STM開発環境にMCU移植機能が無い現状では、移植デバイス先のSTM32CubeMX設定さえ間違わなければ、HAL APIより上層アプリケーションの使用・移植は、簡単

汎用STM32Fxテンプレートを購入検討中の方、または既にSTM32Fxテンプレートをお持ちの方は、HAL API利用STM32Fxテンプレートの別デバイス移植性が優れていることが本稿でご理解頂けると思います。

汎用STM32F0シンプルテンプレートのSTM32G071RB移植手順

手順1.SW4STM32で、F0SimpleTemplateプロジェクト名をG0SimpleTemplateへリネームコピー

手順2.STM32CubeMXで、評価ボードNucleo-G071RBプロジェクトを新規作成し、F0SimpleTemplate.icoと同じ変更を加え、手順1でリネームしたG0SimpleTemplate.icoへ上書き保存後、コード生成

手順3.SW4STM32で、G0SimpleTemplateのmain.cとUserDefine.hなど数か所を変更&コンパイル

手順4.STM32G071RB評価ボードNucleo-G071RBで、移植シンプルテンプレート動作確認

文章で書くと手順1~4のように量が多くなります。しかし、HAL APIはSTM32MCUで共通、デバイスが変わってもHAL API利用アプリケーションをそのまま使うために、下層の構築にSTM32CubeMXを使うだけです。HAL APIアプリケーション移植は簡単です。

手順詳細を説明します。

手順1:SW4STM32で、F0SimpleTemplateプロジェクトをG0SimpleTemplateへリネームコピー

F0SimpleTemplateをコピー、同じワークスペースへペーストする時にG0SimpleTemplateへリネームします。

F0SimpleTemplateをG0SimpleTempleteへリネームコピー
F0SimpleTemplateをG0SimpleTempleteへリネームコピー

G0SimpleTemplateフォルダ内のF0SimpleTemplate.iocをG0SimpleTemplate.iocへF2:リネームします。
※手順1の目的は、F0SimpleTemplateソースコードのユーザ追記部分を、丸ごとG0SimpleTemplateで流用するためです。

手順2:STM32CubeMXで、Nucleo-G071RB新規作成とコード生成

現状のSTM32CubeMXには、MCUデバイス間の移植機能がありません。そこで、F0SimpleTemplate.iocファイルを見ながら、新規作成Nucleo-G071RBの周辺回路を手動で同じ設定にします。

先ずG0SimpleTemplete.iocファイルを新規作成し、手順1でリネームしたG0SimpleTemplete.iocへ上書き保存します。その後、STM32CubeMXの2重起動を活かしF0SimpleTemplate.iocを見ながらG0SimpleTemplete.ioc周辺回路を同じ設定にします。最後に、全ての周辺回路をHAL APIでコード生成します。

STM32CubeMXのNucleo-G071RB設定
STM32CubeMXのNucleo-G071RB設定

※Connectivityは、F0SimpleTemplateに合わせてUSART2、Clock Configurationは、HCLK Max.の64MHz、Timerは、F0SimpleTemplateのTIM3機能に近いTIM7を使いました。

手順3:SW4STM32で、main.cとuserdefine.hの数か所を修正&コンパイル

どのようなアプリケーションソフトでも、デバイス依存の箇所があります。F0SimpleTemplateも同様です。これらは手動で変更・修正するとビルドが成功します。変更・修正箇所が下記です。

  • HALライブラリとBSP(Board Support Package)変更
    stm32f0xx_hal.h→stm32g0xx_hal_conf.h、stm32f0xx_nucleo.h→stm32g0xx_nucleo.h(UserDefine.h)
  • BSPはRepository\STM32Cube_FW_G0_V1.2.0\Drivers\BSP\STM32G0xx_Nucleoのstm32g0xx_nucleo.c/hをSrc/Incへコピー
  • TIM3の代わりにTIM7を使ったので、htim3→htim7(main.c)
  • G0SimpleTemplateに無関係ファイル削除(stm32f0xx_nucleo.c/h, system_stm32f0xx.c)

手順4:評価ボードNucleo-G071RBで動作確認

F0SimpleTemplateをG0SimpleTempletaへ流用したVitrual COMポート画面
F0SimpleTemplateをG0SimpleTempletaへ流用したVitrual COMポート画面

※表示メッセージは、STM32G0xデバイス対応に変更しています。

あとがき

繰返しますが、文章で書くと移植手順は長く複雑に感じます(特に手順3)。しかし、ソフトウェアアーキテクチャ図1が理解済みならHAL API利用アプリケーションの別デバイスへの移植は簡単です。手順3内容は、デバイスが変われば当然必要となる事柄です。

HAL API利用アプリケーションの最大メリットは、MCU移植が容易なことです。つまり、HAL APIアプリケーションは、「STM32MCUデバイス非依存」とも言えます。

現状では、このメリットを活かす開発環境が不備なだけです。不備分は手動で補い、STM32F0/F1アプリケーションをSTM32G0アプリケーションへ移植する方法を示しました。

近い将来、STM開発環境にMCUデバイス移植機能が提供されると筆者は思います。

お知らせ:LL APIを利用するLL APIのSTM32G0x「専用」テンプレートの販売時には、本稿のHAL API利用「汎用」G0SimpleTemplateも添付し、専用と汎用の両方を1パッケージで販売する予定です。

※LL APIとHAL APIの差を把握したい方は、STM32CubeMXのLow-Layer API利用法(2)を参照ください。

MCU:マイコン,STM32マイコンSTM32CubeMX,HAL,API,STM32F0x,STM32MCU,STM32G0x,専用テンプレート,Low-Layer,利用法,NVIC,トレードオフ,STM32F1

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利用時の設定箇所
LL API利用時の設定箇所。デフォルトは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のユーザ追記箇所が赤囲みです。

EXIT_ToggleLedOnIT_Init.iocのユーザNVIC設定箇所
EXIT_ToggleLedOnIT_Init.iocのユーザ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両デバイス性能を1MCUでカバーするSTM32G0xは、専用アプリケーション、つまりLL API開発に値するデバイスだと思います。STM32G0xテンプレートは、LL APIを使い専用テンプレートとして開発します。

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

MCU:マイコン,STM32マイコンテンプレート,Cortex-M0+,IoTマイコン,STM32F072RB,SW4STM32,STM32CubeMX,HAL,API,STM32G0x,LL,専用テンプレート,Low-Layer

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で示されたやむを得ない場合を除いては、避けた方が無難です。

MCU:マイコン,STM32マイコン,Cortex-M0+コアARMマイコン,Cortex-M0+,IoTマイコン,MCU,HAL,API,STM,IoT,STM32Fx,STM32G0x,Edge,LL

本稿は、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
評価ボードNucleo-G071RB。64ピンパッケージでも電源供給が2本のみのなのでアートワーク担当者が喜ぶ。

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

MCU:マイコン,STM32マイコン,Cortex-M0+コアARMマイコン,Cortex-M0+,IoTマイコン,STM32CubeMX,HAL,STM32G0,コード生成,STM32Fx,IoTエッジMCU,専用テンプレート

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

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

STM32メインストリームMCU
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ラインナップ (出典:STM公式ブログ)
供給中の3種製品とSTM32G0ラインナップ (出典:STM公式ブログ)
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発売)などが考えられます。

関連投稿:NXP新汎用MCU S32K1

MCU:マイコン,STM32マイコンテンプレート,ARMマイコン,Cortex-M0,IoTマイコン,STM32F072RB,SW4STM32,STM32F103RB,STM32CubeMX,Cortex-M3,HAL,BSP

STM32CubeMXは、STM32Fxマイコンのコード生成ツールとして良く出来ています。但し、現状1つ残念なことがあります。HAL:Hardware Abstraction Layerに加え、BSP:Board Support Packagesをドライバとして出力しないことです。そこで、現状のHALドライバのみ出力に対策を加えます。

STM32CubeMX
STM32CubeMX

STM32Fxファームウエア構成

STM32Fx Software Structure
STM32Fx Software Structure

STM32Fxファームウエア構成が上図緑線の個所です。STM32Fxマイコンサンプルソフトは、使用するファームウエアライブラリに応じて、Low Layer examples、Mixed HAL & Low Layer examples、HAL examplesの3種類あります。

各ファームウエアの差や、サンプルソフトの場所は、以前記事で解説しました。ここでは、STM32F0からSTM32F1へのポータビリティが最も高いHALライブラリ(=ドライバ)を使うサンプルソフト:HAL examplesに的を絞って解説します。

HAL Examples

このサンプルソフトの優れた点は、評価ボード実装済みの青SW(USER Blue)と緑LED(LD2)のみで全てのサンプルソフト動作を確認できることです。SW入力と、LED点滅間隔を変えることで、正常/NG/入力待ちなど様々なサンプルソフトの動作状態を表現します。

この青SWと緑LEDを制御するには、GPIO定義とHALライブラリを組合せた一種のサブルーティンがあると便利です。このサブルーティンが、BPS:Board Support Packagesです。例えば、下記などです。

BSP_LED_On()、BSP_LED_Off()、BPS_LED_Toggle()、BPS_PB_GetState()

BSP_が先頭に付いているので、一目で評価ボード実装済みの青SWや緑LEDを制御していることが判りますし、HALライブラリを使って表現するよりも、可読性もより高まります。BPSの中身は、HAL自身ですので、Drivers層のBSP、HALともに同じ黄緑色で表示しています。

HAL exampleは、これらBSPとHAL両方を使って記述されています。

STM32CubeMX

STM32CubeMXは、最初に使用する評価ボードを選択後、コード生成が行えます。

STM32CubeMX Board Selector
STM32CubeMX Board Selector

但し、生成コードに含まれるのは、HALドライバのみです。BSPは、HALサブルーティンですので、自作もできますが、評価ボードを選択するのですから、せめてHALのみか、それともHALとBSPの両方をドライバとして出力するかの選択ができるように改善してほしい、というのが私の希望(最初に言った現状の残念なこと)です。

もしHALとBPSドライバ両方がSTM32CubeMXで出力されると、多くのHAL Examplesを殆どそのまま流用できるメリットが生じます。HAL Examplesは、残念ながらエキスパートの人手で開発したソースですが、これを自動コード生成の出力へ、より簡単に流用できる訳です。

STM32CubeMX出力ファイルへのBSP追加方法

BSPドライバを自動出力しない現状のSTM32CubeMXで、上記希望をかなえる方法は、簡単です。

STM32CubeMX出力ファイルへのBSP追加
STM32CubeMX出力ファイルへのBSP追加

手動でBSPのstm32f0xx_nucleo.cとstm32f0xx_nucleo.hをSTM32CubeMX生成プロジェクトのSrcとIncフォルダへコピーし、main.cのL43へ、#include “stm32f0xx_nucleo.h”を追記すればOKです。
※stm32f0xx_nucleo.c/hは、\STM32Cube\Repository\STM32Cube_FW_F0_V1.8.0\Driversにあります。

たとえSTM32CubeMXで再コード生成しても、stm32f0xx_nucleo.c/hはそのままですし、追記した部分もそのまま転記されます。この方法で、HAL Examplesの流用性が向上します。

HAL Examplesを読むと、周辺回路の細かい設定内容が解ります。この設定をそのままSTM32CubeMXに用いれば、周辺回路の動作理解が進み、さらに自動コード生成ソースへ、Examplesソースをそのまま流用できるので、評価ボードでの動作確認も容易です。

まとめ

現状のSTM32CubeMXは、BSPドライバを出力しません。対策に、手動でBSPドライバを追加する方法を示しました。これによりエキスパートが開発したサンプルソフトを、より簡単に自動生成ソフトへ組込むことができます。

開発中の弊社STM32Fxテンプレートも、サンプルソフトを流用/活用が使いこなしのポイントです。そこで、このBPSを組込む方法をSTM32Fxテンプレートへも適用し、サンプルソフト流用性向上を図っています。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コアARMマイコン,Cortex-M0,Cortex-M0+,STM32F072RB,SW4STM32,STM32F103RB,STM32CubeMX,Cortex-M3,HAL

STM32ソフト開発に、HAL:Hardware Abstraction Layerライブラリを使えば、文字通りARMコアを抽象化したソフトが作れます。コード生成ツールSTM32CubeMXが、HALをデフォルトで使うのもこの理由からです(HALとLLライブラリについては、6月5日記事も参考にしてください)。

そこで、STM32CubeMXのHAL出力とF0:Cortex-M0評価ボードSTM32F072RB(48MHz)で動作するSTM32Fxシンプルテンプレートを、F1:Cortex-M3評価ボードSTM32F103RB(64MHz)へ載せ替えた時のソースコード変更箇所を示し、HALを使ってARMコアを抽象化した結果、ソースコードのどこが共通化でき、どこが異なるのかを具体的に示し、HALの利用効果を評価します。

※STM32Fxシンプルテンプレート仕様は、前回記事参照。
※STM32F072RBとSTM32F103RBは、ARMコアのみが異なる評価ボードで、実装済みの緑LEDとユーザ青SWも同一GPIOピンを使用しているので、STM32F0:Cortex-M0からSTM32F1:Cortex-M3へのソフト載せ替え評価に最適。

STM32FxシンプルテンプレートのSTM32F0からSTM32F1へのソースコード変更箇所

(1)HALライブラリのインクルード

結果から言うと、ARMコア抽象化機能を持つHALライブラリを使えばユーザが追記したソースコードは、大部分を共通にできます。
しかしHALライブラリ自身は、ARMコアにより異なります。このため、HALライブラリをインクルードするソースコードの箇所は、下記のようにstm32f0xx_hal.hからstm32f1xx_hal.hへ変更が必要です。

HALライブラリインクルード:STM32F0(左)とSTM32F1(右)
HALライブラリインクルード:STM32F0(左)とSTM32F1(右)

(2)割込み:NVICプログラマーズモデル

Cortex-M0/M0+は、割込み最大数32、優先度レベル4、一方Cortex-M3は、割込み最大数240、優先度レベル8~256とコアで異なるモデルですので、割込み関連ヘッダファイルの変更が必要です。

NVICプログラマーズモデル:STM32F0(右)とSTM32F1(左)
NVICプログラマーズモデル:STM32F0(右)とSTM32F1(左)

※STM32Fxシンプルテンプレートは、SysTick割込み以外はポーリングを使っています。GPIO割込みは、未使用です。この箇所は、デモソフトのGPIO割込み利用部分が参考になるため、テンプレートにそのまま流用した結果、変更が必要になった箇所です。

テンプレートへGPIO割込み処理を追加し、更にARMコアを変更する場合には、このNVICプログラマーズモデルの違いで変更が必要になります。

*  *  *

HALライブラリを使った結果、上記2か所以外のユーザソース、ヘッダファイルは、STM32F0とF1のMCUで共通化できました。共通ソースコードの一部を示します。動作クロックが48MHzと64MHzと異なりますが、同じHAL API:HAL_UART_Transmit()によりUART2送受信(19200bps 8-Non-1)ができています。

HAL_UART_Transmit()によるUART2送信
HAL_UART_Transmit()によるUART2送信

Cortex-M3のSTM32F103RB(64MHz)動作STM32Fxシンプルテンプレートファイル構成が下記です。

Simplate Template for STM32F1 Project Explorer
Simplate Template for STM32F1 Project Explorer

弊社が追加したソースファイルやヘッダファイルは、Pascal形式でファイル名を付けますので、図示のように赤で色分けしなくても一目でSTM32CubeMX生成ファイルとの区別ができます。

STM32CubeMX生成ファイルのHALライブラリインクルード部分は、STM32CubeMXが当該HALライブラリ(stm32f1xx_hal.h)を、また割込みは、当該NVICプログラマーズデモルに応じたソースを「上書きで」生成しますので、コア載せ替えによる修正箇所は、弊社追加ソースファイルとヘッダファイルに限定できます。

この限定ファイル(1)と(2)の個所のみを変更すれば、STM32F0ソースコードをF1へそのまま使えます。HALライブラリ利用によるソース/ヘッダの共通化効果は、非常に高いと言えるでしょう。

弊社ソースファイル、ヘッダファイルの変更箇所は、#ifdefプリプロセッサを使って、コアによる差分箇所を1つへまとめることも可能です。リリース版では、これを採用したいと考えています。HALライブラリ利用により、ARMコアに依存しないSTM32Fxテンプレート構想(x=0 or 1)が実現します。