STM新汎用MCU STM32G0

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 Serie 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

SLA (Software license Agreement)

STマイクロエレクトロニクス(以下STM)のSTM32マイコン マンスリー・アップデート2018年8月 P4のコラムに、ソースコード生成ツールSTM32CubeMXのSLA(Software license Agreement)変更が記載されています。

SLAとは

SLAは、ソフトウェア利用(または使用)許諾契約(きょだくけいやく)のことです。ウィキペディアに詳しい説明があります。

コラム記載の新しいライセンスが、SLA0048 – Rev 4 – March 2018です。この新ライセンス中にSTM32CubeMXで検索してもヒットしませんし、法律文言の英文解釈能力も持ち合わせていませんので、コラムをそのまま抜粋します。

「マイコンに書き込まれた状態であれば著作権表示などは不要だが、それ以外の状態であればソースコード、バイナリいずれも著作権表示などは必要」になりました。

STM32CubeMXでHALを使ってソースコードを生成すると、ソースコードの最上部に下記コメントや、その他の部分にも自動的にコメントが挿入されます。

STM32CubeMX生成ソースコード
STM32CubeMX生成ソースコード(STM32Fxマイコンテンプレートの例)

要するに、新SLAは、これらSTマイクロエレクトロニクス提供ツールSTM32CubeMXが自動挿入したコメントを、我々開発者は、勝手に削除してはいけない、と言っているのだと思います。

IDE付属ソースコード生成ツール

マイコンのソースコード生成ツールは、STM32CubeMX以外にも、各社のIDE(統合開発環境)に付属しており、

  • ルネサスエレクトロニクス:コード生成
  • NXPセミコンダクターズ:SDK、Processor Expert
  • サイプレス・セミコンダクター:Generate Application

などがあります(固定ページのAPI生成RADツール参照)。これらツールが自動生成するソースコードには、開発者が解りやすいように多くのコメントが付いています。

殆どのIDE付属エディタは、最上部の著作権関連コメントを畳んで表示することが可能ですし、これらコメントは、コンパイル後、つまりマイコンに書き込まれる状態では削除されますので、普段は注意を払わない開発者が殆どだと思います。

これらコメントも、STM32CubeMXと同様、各社のSLA違反になる可能性がありますので、生成ソースコードでのコメント削除はせず、オリジナル出力のまま使うことをお勧めします。

マイコンテンプレート

弊社販売中のマイコンテンプレートも、上記コード生成ツールのソースコード出力は、そのまま使っております。

マイコンテンプレートの版権は、ご購入者様個人に帰属します。但し、テンプレートそのものの転売、配布はご遠慮ください。お願いいたします。🙏

マイコンテンプレート活用プロトタイピング開発(4)

マイコンテンプレートへ機能を追加するには、既に枠組みが出来上がっているテンプレートへ、追加機能名のファイルを新規作成し、追加機能をこのファイル内で記述、テンプレートのLauncher()で起動すれば完成です。長文であった第3回を、一口で言えばこうなります(トホホ… Orz)。

Basic Form of Embedded Software (Initial Setting and Repetitive)
無限ループ前に1回実行する初期設定処理と、無限ループ内の繰返し処理の2つから構成される「組込みソフトの基本形」

これは、Arduino IDEの新規作成ファイル画面です。このsetup()とloop()の構造は、Arduinoに限らず全ての「組込みソフトの基本形」です。つまり、無限ループ前に1回実行する「初期設定処理」と、無限ループ内の「繰返し処理」の2つから構成されます。

弊社マイコンテンプレートもこの基本形に則っています。但し、機能追加がし易いように、無限ループがLauncher()に変形し、複数のユーザ関数を起動できるように工夫しているだけです。

従って、最も安直(!?)な機能追加の方法は、追加機能のサンプルソフトを見つけることです。あとはテンプレートのLauncher()でこのサンプルソフトを起動すれば、テンプレートへ機能追加ができるのです。

今回の目標は、テンプレートへのSDカード機能の追加です。そこで、このSDカード機能追加に最適と思うサンプルソフト:Developing Applications on STM32Cube with FatFs:UM1721を解説します。

UM1721: Developing Applications on STM32Cube with FatFs

2014年6月版 UM1721では、STM32Cubeと記述されていますが、これはSTM32CubeMX(以下CubeMX)のことです。また、STM32F4xxとSTM32CubeF4で記述されていますが、全てのSTM32デバイスとCubeMXに置換えて読めば使えます。

FatFsは、ユーザアプリケーションと下層HAL(Hardware Abstraction Layer)の間で機能するミドルウェアで、主目的は、開発するアプリケーションが読書きするデータと、物理ストレージファイルの割付(領域管理)です。パソコンなどでは、本来WindowsなどのOSが行う機能を代行するのがFatFsと考えれば良いでしょう。また、FatFs自体はMCUハードウェアには依存しないので、本稿STマイクロエレクトロニクス以外のマイコンでも使えます。

FatFs Middleware module architecture (Source:UM1721)
FatFs Middleware module architecture (Source:UM1721)

もっと知りたい方は、UM1721の2章までに詳しく記述されています。本投稿は、FatFsを使うサンプルソフトが目的ですので読み進めると、3.3のサンプルソースが見つかります。

FatFsサンプルソフト

FatFs Sample Software (Source:UM1721)
FatFs Sample Software (Source:UM1721)

懇切丁寧なサンプルソフトとは言えませんが、必要最低限で記述しているのでしょう。一見、組込みソフトの基本形と違うと思われるかもしれませんが、初期設定処理はCubeMXが自動生成し、別の場所にソースコードを出力するため(おそらく)省略しています。また、ファイルアクセスは低速なので、繰返し回数を1で処理すると考えれば、このサンプルソフトも基本形に則っています。

サンプルソフトから、FatFsを使うAPI(Application Programming Interface)が5種、FatFsとLow Level Disk I/O Driversをリンクする2種のAPIを使えば、SDカードへの読書きができることが解ります。
※書込み:f_write()を、f_read()に置換えれば読込みができます。

FatFsサンプルソフトで使用するAPI
用途 API
FatFsとアプリケーション間

f_mount()

f_open()

f_close()

f_read()

f_write()

FatFsとLow Level Disk I/O Driversリンク間

FATFS_LinkDriver()

FATFS_UnLinkDriver()

FatFsサンプルソフトAPI動作テスト

このサンプルソフトを、第3回で使用したレファレンスプロジェクトへ挿入し、各APIの動作を確認します。

FatFs Sample API Test Source
レファレンスプロジェクトへ挿入したFatFsサンプルソフト。

結果は、FatFsとアプリケーション間5種全てのAPIで正常動作が確認できました。つまり、レファレンスプロジェクトでは、このサンプルソフトを使いSDカードへの読書きができます。その結果、SDカードへwtext[] = “text to write logical disk”のデータを、ファイル名STM32.txtとして保存できました。

FatFs Write Test to SD Card
FatFsサンプルソフトを使い、SDカードへ書込んだファイルSTM32.txtと書込みデータ。

レファレンスプロジェクトは、Low Level Disk I/O Driversリンク側のAPI相当を、エキスパートが自作しているのでコメントアウトしています。

STM32CubeMXでFatFs機能追加

第3回と同様、シンプルテンプレートをRenameし、機能追加用のSPI1FatFs_Sdプロジェクトを作成し、CubeMXでSPI1とFatFs機能を追加します。また、SdCard.cファイルを作成し、この中に前章で動作確認したサンプルソフトを挿入します(プロジェクトやファイル作成の詳細は、第3回を参照)。

FATFS and SPI1 Functions Add by STM32CubeMX
STM32CubeMXでFATFSとSPI1を追加。SPI1のピン割付は、実装シールド基板に合わせている。

Launcher()からサンプルソフトを起動し、1回のみ処理するように変更を加え、レファレンスプロジェクトと同様各APIのリターン値を確認しましたが、f_open()以降で正常動作しません。

初期設定処理を自動生成するCubeMXのFatFs設定に間違いが無ければ、SPI1FatFs_SdプロジェクトでもユーザデータをSDカードへ読書きできるハズです。UM1721には、FatFsの設定記述がないので、CubeMXのFatFsデフォルト設定にしましたが、お手上げです。

そこで、STM Communityを検索すると、例えばコチラのように現在のCubeMXのFatFsにはバグがあるようです。対策もCommunityにありますが、STMもバグ状況を把握していますのでCubeMXの改版を待つ方が良さそうです。

*  *  *

サンプルソフト自体は、レファレンスプロジェクトで動作確認済みです。CubeMXのFatFs初期設定生成に問題があることは間違いありません。つまり、組込みソフト基本形の初期設定以外の半分(50%)の処理をUM1721から獲得できたと言えます。

Tips: 動作サンプルソフトは、FatFsがMCUハードウェアに依存しないので、他社マイコンでも使えます。獲得した50%処理は、適用範囲が広いものです。

対策としては、STMによるCubeMX改版を待つこと、レファレンスプロジェクトからFatFs関連の初期設定を抜き出すこと、の2つあります。後者については、検討中です。

STM32マイコンへ深層学習実装、「走る」「歩く」動作判断

日刊工業新聞3月7日電子版掲載の日本で2桁成長を狙っているSTマイクロエレクトロニクス、このSTMが、STM32シリーズマイコンへディープニューラルネットワーク:DNN(深層学習)を実装し、マイコンの「走る」「歩く」状態を正確に判断するデモを展示しました。

STM32F7(Cortex-M7)搭載時計でユーザ動作を正確に判断(記事より)
STM32F7(Cortex-M7)搭載時計でユーザ動作を正確に判断(記事より)

マイコンDNN実装の3課題と解決ツール

記事によるとSTM32マイコンへDNNを実装する時の3つの課題、

  • マイコン実装のためのコードサイズ実現
  • ソフトウェア最適化
  • マイコンとクラウドの相互運用性

解決のため、STM32CubeMx.AI(現在αバージョンで2018年後半リリース予定)ツールを使うそうです。

このSTM32CubeMx.AIは、STM32CubeMXの機能拡張版だと思います。
現在のSTM32CubeMXも、全てのSTM32シリーズで共通に使えるAPIを自動生成します(STM32CubeMXのTipsはコチラの投稿も参照)。機種共通API生成とソフトウェア最適化は、既にSTM32CubeMXでも実現済みです。

従って、弊社STM32Fxテンプレートも、STM32CubeMXを使えばSTM32シリーズ全般にテンプレートが適用できるハズです(STM32F0とSTM32F1のみ実機検証済み。APIが共通なので機種差は、インクルードするヘッダーファイルなど数点のみ。他機種は未検証です念のため…)。

※STM32マイコンの開発環境は、弊社ブログのカテゴリで、“STM32マイコン”をクリックすると投稿がカテゴライズされ読みやすくなります。投稿ページの初めの方に開発環境構築方法などの投稿が集まっています。

STM32マイコン重点分野

電子版によるとSTM32マイコンは、自動車、産業用、スマートホームなどのIoT分野を重点にして市場拡大を狙うそうです。STM32マイコンに、上記クラウドAI技術が適用され、その開発環境の使い勝手も良いとなると、かなり期待ができます。

STM32Fxテンプレート発売

2016年MCUシェア第5位のSTマイクロエレクトロニクス(STMicroelectronics、本社スイス)のSTM32F0:Cortex-M0とSTM32F1:Cortex-M3向けのテンプレートを開発しましたので、販売開始します。従来テンプレートと同額の1000円(税込)です。

STM32Fxテンプレートの特徴

STM32Fxテンプレート構成
STM32Fxテンプレート構成
  • Cortex-M0とCortex-M3両コア動作のテンプレート
  • 移植性、可読性が高いHALドライバを使ったので、他コアへの流用、応用性も高い
  • カウントダウンループを使ったCortex-M系コードテクニックで開発

従来テンプレートは、ARM Cortex-M0/M0+とルネサスS1/S2/S3コアが対象でした。

つまり、8/16ビットMCUの置換えを狙ったCortex-M0/M0+と、RL78汎用MCUへテンプレートを供給していました。しかし、IoTの通信処理や要求セキュリティを考慮すると、より高性能なMCUも視野に入れた方が良いと感じていました。また、Cortex-M3デバイスの低価格化も期待できます。

初めてCortex-M3のSTM32F103RB:NUCLEO-F103RBへもベアメタルのテンプレートを開発したのは、以上のような背景、理由です。

ST提供のHAL:Hardware Abstraction Layerドライバは、移植性、可読性が高く、Cortex-M0/M3両対応のテンプレートも簡単に開発できました。Cortex-M3よりもさらに高性能なMCUが、ベアメタル開発を行うかは疑問ですが、HALを使ったので適用できると思います。

動作確認評価ボードは、STM32F072RB:Cortex-M0/48MHzとSTM32F103RB:Cortex-M3/64MHzですので、これはあくまで私見、見込みですが…、HALドライバならば問題なく適用できるハズです。

HALドライバ作成にSTM32CubeMXを使うと、異なるコア動作速度(M0:48MHz、M3:64MHz)でも、同じ周辺回路ならば、同じHAL APIが使えます。

今日現在、このSTM32CubeMX周辺回路のGUI設定に関する詳しい資料が見当たりません。そこで、テンプレート添付資料では、テンプレートのSTM32CubeMX設定方法や、SW4STM32開発ヒントやTipsなど開発に役立つ情報を満載しています。初めての方でもSTM32MCUの開発障壁を低く出来ます。

また、本テンプレートをプロトタイピング開発に使って、MCU性能の過不足を評価するのも便利です。ボードレベルでピンコンパチなSTM32 NUCLEO評価ボードですので、評価ボード単位の載せ替え/交換も可能です。

さらに、デクリメントループを使ってループ終了を行っているなど、Cortex-M系のコード作成にも注意を払いました。

*  *  *

マイコンテンプレートサイトへ、STM32Fxテンプレートを掲載します(9月2日追記:サイト更新完了しました)。
添付資料のP1~P3、もくじの内容を掲載しております。P1~P3は、資料ダウンロードが可能です。STM32Fxテンプレートをご購入の上、是非、ご活用ください。

STM32CubeMXの使い方Tips

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テンプレートへも適用し、サンプルソフト流用性向上を図っています。

評価ボードNUCLEO-F072RB/F103RBのピン選択指針

STマイクロエレクトロニクスの評価ボード、NUCLEO-F072RBやNUCLEO-F103RBを使って、ボード外部と接続する際の、ピン選択に関する指針を示します。

NUCLEO-F072RBの外部接続ピン
NUCLEO-F072RBの外部接続ピン

評価ボードのピン配置とSTM32CubeMXのピン選択

評価ボードには、外部接続用のピンとしてArduinoピン(ピンク色)と、NUCLEOボード独自のMorphoピン(青色)があり、Morphoピンの一部は、Arduinoピンと共用(赤囲み)です。2つの黄色マークは後述します(評価ボードのユーザマニュアルは、コチラを参照)。

Arduinoピンは、メスコネクタ、一方Morphoピンは、オスコネクタを使っており、ブレッドボードや弊社マイコンテンプレートで使うBaseboardとの接続には、Arduinoピンを使いオスーオス結線が便利です(Baseboardやオスーオス結線のメリットはコチラの記事を参照)。

評価ボードNUCLEO-F072RB (=STM32F072RB)やNUCLEO-F103RB (=STM32F103RB)を使う時のコード生成ツールが、STM32CubeMXです(STM32CubeMXはこちらの記事などを参照)。

STM32CubeMXは、MCUパッケージイメージから使用ピンを選択、設定します。色付きピンは、既に評価ボードで使用済みのピン、灰色ピンが未使用ピンです。

例えば、灰色ピンのPB7は、I2C 1_SDA~GPIO_EXIT7までの広い範囲で自由に機能を設定可能です。

STM32CubeMXのピン選択
STM32CubeMXのピン選択

STM32F072RBとSTM32F103RBは、どちらもLQFP64パッケージでピンコンパチです。緑色のB1 [Blue Push Button] :PC13と、LD2 [Green LED] :PA5の2ピンを評価ボードで使用しますので、前述の評価ボード接続ピンに、既に使用済みという意味で黄色マークを付けました。

長くなりましたが、ここまでが、前置きです。これらの前置きを知ったうえで、STM32CubeMXで自由に設定できる灰色ピンの内どれを使うと、効果的な評価ボード開発ができるのかを明らかにするのが本記事の目的です。

STM32CubeMXのピン選択指針

STM32F072RBやSTM32F103RBのソフト開発の場合、最初にSTM32CubeMXで使用ピンを決め、コード生成をします。もちろん使用ピンは、コード生成後も変更できますが、変更のたびに再コード生成が必要です。再コード生成の手間は、できれば避けたいです。

こんな時、ピン選択の指針があると便利です。

前置き情報から、Arduinoピンを使うと、ブレッドボードやBaseboardとの接続が、オスーオス結線で簡単、市販Arduinoシールドも使えることが判ります。そこで、Morpho ピンで、Arduinoピンと共用しているピンを昇順に抜粋すると、下記になります。

GPIOA:            PA0/PA1/PA2/PA3/PA4/PA5/PA6/PA7/PA8/PA9/PA10
GPIOB:            PB0/PB3/PB4/PB5/PB6/PB8/PB9/PB10
GPIOC:            PC0/PC1/PC7/PC9

GPIOAが多数ですが、Arduinoピン名をみるとA0などのアナログ入力ピンとの共用が多いので、デジタル入出力と思われるD0~D15での共用が多いGPIOBから先に割り当てる方針を立てました。

BaseboardとのLCD接続

この方針でBaseboardのLCDと接続し、LCD出力した例を示します。本方針が、LCD接続では有効であることが判ります。

NUCLEO-F072RBとBaseboard接続しLCD出力
NUCLEO-F072RBとBaseboard接続しLCD出力

まとめ

開発中のSTM32Fxマイコンテンプレートは、テンプレート応用例としてシンプル/Baseboardテンプレートの2つを添付します。シンプルテンプレートは、評価ボード単体で動作しますので、使用する外部接続ピンに悩む必要はありません。

Baseboardテンプレートは、評価ボードとBaseboardを接続して動作させますので、効果的な接続方法として、評価ボード外部接続ピンの選択指針を検討しました。

デジタル接続なら、Arduinoピンとのデジタル共用が多いGPIOBから選択し、アナログ接続なら、GPIOAから選択する指針を示し、この指針に基づいてBaseboardのLCDと接続し出力を確認しました。

追記

評価ボードのArduinoとMorphoの共用コネクタ部分の回路図を抜粋したのが下図です。

NUCLEO64 Boardのコネクタ回路図
NUCLEO64 Boardのコネクタ回路図(ユーザマニュアルより)

評価ボード裏面のジャンパー(回路図のSBxxなど)を、工夫(オープン/ショート)すると、ArduinoピンとMorphoピンの共用ピンをさらに変更できることが判ります。よく考えられた評価ボードです。

STM32F0ソフトをF1変更時の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)が実現します。

STM32デモソフトから見える問題点

STM32Fxシンプルテンプレート

前回記事で予告しました、弊社マイコンテンプレートを使い、STM32評価ボードのデモソフトへUART-USB通信機能を追加しました(下記仕様参照)。

デモソフトのSW押下げの代わりに、評価ボードとパソコン間のUART-USB通信コマンドでLED点滅速度を変えます。これをマイコンテンプレートのSTM32F0マイコンへのシンプルな応用例という意味で、STM32Fxシンプルテンプレートとします(年内に既存マイコンテンプレートと同様、Baseboardテンプレートと合わせSTM32Fxマイコンテンプレートとして1000円で販売予定)。

STM32Fxシンプルテンプレート仕様
・動作確認評価ボード:STM32F072RB(Cortex-M0)
・LED出力:評価ボード実装 緑LED LD2点滅速度をUART-USBコマンドで変更
・SW入力:評価ボード実装 青ユーザSW(ソフトチャタリング対策済み)PushをUART-USBで表示
・UART-USB通信:TeraTermなどのターミナルソフトへメッセージ入出力(19200bps 8-Non-1)
・低電力動作:Sleep処理
・使用ライブラリ:HAL

STM32Fx Simple-Template Overview
STM32Fx Simple-Template Overview

STM32評価ボードデモソフトから見えるサンプルソフトの問題点

STM32評価ボードのデモソフトは、マイコンサンプルソフトの問題点を示しています。この問題点は、マイコンサンプルソフト全般に言えます。

サンプルソフトの問題点とは、1つの機能を、初期設定と無限ループを使って説明する点です。この方法は、初心者が単独機能を理解する際には、動作が解り易く、優れています。

しかし、実際のアプリケーションでは、複数の機能が並列的に動作するのが普通です。実アプリケーションの[複数並列(的)動作]と、サンプルソフトの[無限ループ単独動作]とのギャップが大きいことが、マイコン初心者にとっての大きな障壁です。

結論から言うと、サンプルソフトの解り易さに貢献している無限ループの時間消費(浪費)が問題です。

デモソフトの具体例

具体的にSTM32評価ボードのデモソフトで説明します。無限ループ内のLED点滅処理が下図です。

Sample Software Infinite Loop Trouble
Sample Software Infinite Loop Trouble

LED点滅速度は、SW割込みのCallback関数で変えます。このサンプルソフトは、LED出力とSW入力が並列動作しています(サンプルソフトとしては、SW割込みを使う点で珍しい例)。

LED点滅処理を繰り返すのが、無限ループの目的です。1ループのLED処理は、500/100/50ms毎に1回トグルを実行し、その他の時間は、HAL_Delayで時間消費(浪費)です。殆どのサンプルソフトは、この構成です。

つまり、

典型的サンプルソフト ➡[単独処理+時間浪費]の繰り返し

これにより1つの機能を説明する構成です。この方法は、説明の受け側にとっては、解り易いものです。単独処理の中身は、ポーリングが多いのも特徴です。ポーリング結果で、別処理へジャンプするなどします。

別処理の無限ループへの追加

STM32評価ボードのデモソフトは、割込みでSW入力の別処理を追加しています。しかし、無限ループへ、割込み以外で別処理を追加するのは困難です。なぜなら、[単独処理+時間浪費]へ別処理を追加するには、時間浪費の時間を変えるしか手がないからです。

時間浪費の時間を変えたとします。すると、[単独処理+追加処理+変更した時間浪費]となり、既に存在したLED点滅処理の点滅間隔が変わる可能性が生じます。

つまり、処理追加により既存処理へも影響が及ぶのです。厳密には、割込みでも既存処理へ影響が及びますが、その影響は極わずかです。

処理追加で既存処理に影響が及ぶので、追加前の既存処理単独でのデバッグが無駄になります。デバッグの積み重ねができないのです。

それならば、いつも割込みで処理を追加すれば良いかというと、そうでもありません。

割込み処理は、ポーリングに比べデバッグが難しくなります。また、割込み処理のサンプルソフトは、ポーリングに比べ少数です。

サンプルソフトは、単独動作の説明に重点を置いたポーリング動作のものが多数で、実アプリケーション開発へ、そのままでは使いにくい構成、構造になっていることがお判りになったと思います。

弊社マイコンテンプレートの対策

デモソフトのLED点滅処理に着目したのが、弊社マイコンテンプレートです。500ms、100ms、50ms毎に1回処理し、その他の時間は、別処理、低電力処理(Sleep処理)を時分割で処理します。

つまり、

弊社マイコンテンプレート ➡ ①[単独処理]終わり
____________ ➡ ②[別処理]終わり
____________ ➡ ③[低電力処理]終わり
____________  ①~③の繰り返し

簡単に言うと、時分割の無限ループランチャーです(起動される①側からみると、単独で無限ループ内にあるのと同じ、②、③も同様)。複数処理を起動する仕組みをテンプレート自体が持っているとも言えます。

RTOS: Real Time Operating systemを使うと複数処理起動が簡単です。しかし、RTOS理解のオーバーヘッドが必要です。弊社マイコンテンプレートは、簡易的に処理を並列に起動します。

起動される側の処理は繰り返し起動されますので、ポーリング動作のサンプルソフトの多くがそのまま流用できます。数多くあるポーリングサンプルソフトを活用、流用してアプリケーションの早期開発ができるのが、弊社マイコンテンプレートの特徴です。

また、STM32Fxシンプルテンプレート仕様から解るように、実アプリケーションに最低限必要な、低電力処理、LED出力、SW入力、UART-USB通信の各処理は既にシンプルテンプレートに実装済みです。

このシンプルテンプレートへ実用アプリで必要となる処理を追加しさえすれば、直ぐに最終段階アプリとなる構成になっています。プロトタイピング開発に適し、実アプリケーションとサンプルソフトとのギャップを小さくします。

もちろん処理を追加や削除しても、既存処理への影響が小さいので、デバッグの積み重ねもできます。

STM32CubeMX生成ファイルのユーザ処理追記箇所

STM32CubeMXが生成するプロジェクトと自動生成ファイルのユーザ処理追記箇所を解説します。STM32マイコンのソフト開発は、この出力ファイルへ、ユーザ処理コードを追記して完成しますので、どのファイルのどこに追記すれば良いかを知ることが重要です。

前回記事でSTM32CubeMXの使用ライブラリにHAL: Hardware Abstraction Layerを選びました。UM1718の5章に、HAL単独、LL単独とHAL/LL混合の各ライブラリ使用時のSTM32CubeMX生成ファイル詳細説明があります。本ブログ記事は、このHAL単独版に相当します。

STM32CubeMXの設定条件

STM32CubeMXは、設定により出力プロジェクトの生成ファイルが様々に異なりますので、STM32マイコンテンプレート開発で使う下記条件でコード生成します。

前提条件

評価ボード:STM32F072RB(ARM Cortex-M0)
3ウイザード:Pinout、Clock Configurationは評価ボードデフォルト設定、ConfigurationはEXTI line 4 to 15 interruptsに☑設定
使用ライブラリ:HAL

STM32CubeMX Code Generation
STM32CubeMX Code Generation

出力プロジェクトとユーザ処理追記が必要なファイル

STM32CubeMXの出力プロジェクトのうち、ユーザ処理を追記する必要があるファイルは、Inc(ヘッダーファイル)とSrc(ソースファイル)にあります。これらInc/Srcフォルダ内のファイル概要とユーザコード追記箇所の有無一覧が下記です。

USER CODE Add in for STM32CubeMX Project
フォルダ>ファイル 概要 ユーザ処理追記箇所 STM32CubeMX再生成時
Src main.c main処理(動作クロックとHAL初期設定生成コード含む) あり
ユーザ処理以外上書き
stm32f0xx_it.c 割込み処理(EXIT1 4_15) あり(自動割付済み)
stm32f0xx_hal_msp.c HAL MSP処理とエラー処理 あり(可能性は低い)
system_stm32f0xx.c システムクロック設定 なし
Inc main.h IOピンのラベル定義 あり(Pinoutウイザード設定分のみ) 完全上書き
stm32f0xx_it.h 割込み定義 なし
stm32f0xx_hal_conf.h HAL構成定義 なし

Incフォルダのmain.hユーザ追記部分は、Pinoutウイザードでピン名を追加した分のみです。つまり、ウイザード出力があるだけで実質ユーザ追記は不要です。STM32CubeMXで再度コード生成した場合は、ヘッダーファイルは全て上書きされます。

従って、再生成してもユーザ追記コードが残るのは「あり」で示した、main.c、stm32f0xx_it.c、stm43f0xx_hal_msp.cのSrcフォルダ内の3ファイルです。

このうちstm43f0xx_hal_msp.cは、HALライブラリのMSP: MCU Support Package処理(≒ハード抽象化)やエラー処理ファイルですので、通常はユーザが追記する可能性は低いと思います。

結局、ユーザ処理の追記が必要なファイルは、Srcフォルダのmain.cとstm32f0xx_it.c(割込み処理)の2ファイルです。

ユーザ追記コード(割込み処理)

先ず、割込み処理を説明します。

HALライブラリを使うと、割込みの前処理(割込み要因フラグ確認、フラグリセット、ユーザ処理関数callback)は、全てSTM32CubeMXが自動生成する割込みハンドラが行います。但し、この割込みハンドラ名には、HAL_という接頭語が付いていて、コアの割込みハンドラ名と異なるため、コア割込みハンドラと生成割込みハンドラの対応付けが必要です。

このハンドラ名称の対応付けを行うのが、stm32f0xx_it.cです。評価ボードのデモソフト(STM32マイコン統合開発環境参照の5)動作検証参照)の例で示すと、stm32f0xx_it.cの下記部分です。但し、この割付は、ConfigurationウイザードでEXTI line 4 to 15 interruptsに☑設定した結果、自動割付済みです。つまり、ここもウイザード出力結果が反映されていて、実質ユーザ追記が不要です。

stm32f0xx_it.cのユーザ追記箇所
stm32f0xx_it.c

ハンドラがコールするユーザ処理関数は、Callback以外がハンドラ名と同じHAL_GPIO_EXIT_Callback()という関数名というSTM独自の決まりがあります。このCallback関数は、main.c内にあり下記部分です。

main.c
main.cのユーザ追記箇所

まとめると、割込み処理は

EXTI4_15_IRQHandler()は、    コアの割込みハンドラ(startup_stm32f072xb.sに記述)
HAL_GPIO_EXTI_IRQHandler()は、  STM32CubeMX自動生成の割込みハンドラでHAL_GPIO_EXTI_Callback()をコールバック
HAL_GPIO_EXTI_Callback()は、   ユーザが追記する割込み処理でmain.cに処理内容を追記

という3段構成なので、最終的にユーザが追記する割込み処理の箇所は、Callback()の中身つまりmain.cのみです。

ユーザ追記コード(割込み処理以外)

当然main.cは、割込み処理以外にも、様々なユーザ処理を追記します。STM32CubeMXが自動生成する「ナマ(生)のmain.c」を以下に示します。

main.c souce
main.c souce(折り畳み済み)

ユーザ追記箇所を解り易くするために、ソースを折りたたんでいます。先に示した割込み処理HAL_GPIO_EXTI_Callback()の追記箇所は、ソース構造から、USER CODE BEGIN 4の個所であることが判ります。

/* USER CODE BEGIN xyz */から/* USER CODE END xyz */のコメント間にユーザ処理を追記すれば、STM32CubeMXで再生成しても追記部分は、そのまま残ります。

USER CODE xyzのコメントを読んで、追記が必要なユーザ処理を追加していきます。但し、GPIOやシステム動作クロックの初期設定は、STM32CubeMXが自動生成済みですので、更なる追記は、本当にユーザ処理の部分のみということが判ります。デモの場合なら、LED2の点滅速度変更処理LED2_Blink()のみです。

以上をまとめると、STM32CubeMXが自動生成するプロジェクトとファイルへは、

  • 3ウイザードさえ間違わずに設定すれば、main.cのみの最小限ユーザ追記でアプリ完成
  • たとえウイザード設定に間違えても修正し再生成すれば、USER CODE xyzへ追記したユーザコードは保持され安心

STM32CubeMX自動生成の活かし方

プログラムサイズが大きい場合には、全てのユーザ追加ソースを1つのmain.cファイルに記述するのは現実的ではありません。しかし、単機能のサンプルソフト程度であれば、STM32CubeMXが自動生成するmain.cへユーザ処理を追記してもさほど可読性は悪くなりません。

STM32CubeMXは、STM32マイコンソフトを効率的に開発するツールです。なるべく小さく単機能ソフトをSTM32CubeMXで開発し、単体でバグが取れた後に、各機能を結合して目的のソフトへ仕上げるのが、STM32CubeMX自動生成出力を活かす方法です。

この活かす方法を使って次回は、評価ボードUART入出力をUSB経由でパソコンと繋げるUART-USB(VirtualUART)機能と、評価ボードデモの2つを結合し、パソコンコマンドでボードのLED点滅速度を変えるソフト開発の話をする予定です。これは実は、STM32マイコンのシンプルテンプレートに相当します。ご期待ください。

※固定ページ(本ブログの上部タブリンク)を、CurieからSTM32Fxマイコン開発へ全面変更いたしました。