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マイコン,Cortex-M0+コアテンプレート,ARMマイコン,Cortex-M0+,IoTマイコン,STM32CubeMX,汎用,ADC,IoT,TrueSTUDIO,STM32Fx,STM32G071,STM32G0x

STM32G0x専用テンプレートの開発着手にあたり、汎用STM32Fxテンプレート開発から2017年9月のテンプレート発売までをざっと振り返り、今回の専用開発との差分になりそうな箇所を示しSTM32G0x専用テンプレート開発全体像を俯瞰、力を入れる投稿予定を示します。

汎用STM32Fxテンプレート開発History

汎用STM32Fxテンプレート開発時の主な投稿と内容
年月日 投稿タイトル 主な内容
2017年5 STM32マイコンIDE構築 SW4STM32の構築
2017年6 STM32CubeMXの使い方 HAL APIの選定理由と利用法
STM32CubeMX生成ファイルのユーザ追記箇所 HAL利用時のユーザ追記箇所
2017年8 評価ボードの利用ピン指針 Baseboardとの接続指針
2017年9 STM32Fxテンプレート発売 汎用STM32Fxテンプレート発売

2017年5月当時は、4種ある無償IDEの中からマルチOS(Windows/MacOS/Linux)対応、仏/AC6社のSW4STM32を使いました。2017年末、無償IDE TrueSTUDIO提供のスウェーデン/Atollic社がSTマイクロエレクトロニクス(以下STM)に買収され、公式にはTrueSTUDIOがSTM32マイコンの純正無償IDEに昇格(!?)したようです😅。

関連投稿:STM32のStep-by-Step Guideの、気になる点1:TrueSTUDIO参照

STM32G0x専用テンプレート開発IDE:TrueSTUDIO

そこで、STM32G0x専用テンプレート開発には、TrueSTUDIO無償版(Windows/Linux対応、MacOSなし)を使います。現在SW4STM32を使っている方にも判り易いようにTrueSTUDIOとの差分を説明する予定です。

但し、筆者はSW4STM32利用中の開発者が、あえてTrueSTUDIOに変更する必要は、今のところ少ないと考えています。ソフトウェア開発の主役は、STM純正コード生成ツールSTM32CubeMXだからです。最新STM32CubeMXを使えば、IDE差は少ないと今は思っています。

勿論、TrueSTUDIOの買収昇格時点でBetterなのは当然だと思います。専用テンプレート開発を通じBetterよりもSW4STM32からTrueSTUDIOへ変更するMust条件が判れば、本ブログでお知らせします。

Tips:STMの日本語資料強化の一環なのか、TrueSTUDIOはEclipseベースIDEなのにインストーラは日本語対応、メニューも日本語になっています(下図参照)。但し、C\ユーザ名\Atollic\TrueSTUDIO for STM32 9.3.0\Manuals\Generalにある重要マニュアル5種は全て英文です。例えば、SW4STM32プロジェクトのTrueSTUDIOインポート方法や注意点は、User GuideのP75~に英文で詳しく説明されています。

日本語対応のTrueSTUDIOメニュー
日本語対応のTrueSTUDIOメニュー

STM32CubeMX:LL API(Application Programing Interface)利用

STM32G0x専用テンプレートは、汎用STM32Fxテンプレート開発で使ったHAL(Hardware Abstraction Layer)APIに変わりLL(Low Layer)APIを使います。LL利用により、STM32CubeMX生成ファイルの初期化コードやユーザ追記箇所がHALとは異なります。LL APIの利用は、専用テンプレートの肝ですので、ブログで詳しく説明します。

IoTサービス例:2.5Msps12ビットADC必須+α

汎用STM32Fxテンプレートは、Baseboardと評価ボードを接続し、基本動作完成形のBaseboardテンプレートを開発しました。STM32G0x専用テンプレートは、Arduinoコネクタに何らかのIoTサービスを示すシールドを接続する予定です。しかし、最悪の場合、汎用と同じBaseboard接続にする可能性もあります。

ただし、特に2.5Mspsの12ビットADCは、3タイプある全STM32G0xデバイスに実装済みで、IoTサービス必須機能ですので、このADCを活かしたIoTサービスは実装必須にします。その他のIoTサービスに関しては、今後決めます。

2.5Msps12ビットADC (RM0444より)
2.5Msps12ビットADC (出典:RM0444)

STM32G0x専用テンプレート発売:2019/3Q~

汎用STM32Fxテンプレートは、5か月の期間で開発しました。STM32G0x専用テンプレートは、HALよりもLL API利用難易度が高いことを考慮すると、最低でも同じ開発期間が必要だと思います。

STM32G0x専用テンプレート開発全体像俯瞰の結果

以上、STM32G0x専用テンプレート開発の全体像を俯瞰しました。
SW4STM32からTrueSTUDIO IDEへの変更必要性、STM32CubeMX のLL API利用法、全STM32G0xデバイス実装済みでIoTサービス必須機能2.5Msps12ビットADC使用法、これらを読者の方々が理解できよう力を入れて投稿記事を作成します。

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M0+コア,Cortex-M33コアARMマイコン,Cortex-M0+,Kinetis Design Studio,IoTマイコン,LPCXpresso,汎用,車載,産業機器,S32K,AEC-Q100,Cryptographic Services Engine,CSEc

NXPセミコンダクターズ(以下NXP)から車載・産業機器向けの、新しい汎用Cortex-M0+/M4 MCU S32K1ファミリが発売中です。
同社の汎用MCUと比べ、何が新しいかを調べました。

S32K1の特徴(汎用MCUとの差分)

セキュリティ強化ARMコアは、Cortex-M23/M33があります。ところが、NXPのS32K1ファミリは、従来のCortex-M0+/M4コアを使います。Cortex-M0/M0+/M3汎用MCUと比べると、差分として以下の特徴があります。

AEC-Q100グレード1規格準拠

AEC-Q100:Automotive Electronics Council、車載用電子部品信頼性の規格化団体の規格AEC-Q100は、世界標準規格で欧米の車載向け集積回路の規格。製品使用温度範囲によりグレード0~3まであり、グレード0が-40℃から+150℃で最も広範囲、グレート1は-40℃から+125℃。

セキュリティ強化ハードウェア内蔵MCU

SHE準拠Cryptographic Services Engine (CSEc) - AES128、セキュアブート、ユニークID

専用IDEのソフトウェア開発

S32 Design Studio(Processor Expert)、無償、コードサイズ制限なし

車載・産業 両方向けの汎用MCUで最低15年供給

S32K11x(Cortex-M0+):S32K116/S32K118(2018/7発売)、評価ボード$49
S32K14x(Cortex-M4):S32K142/S32K144/S32K146/S32K148(2017/12発売)、評価ボード$49/$149

S32K MCUs for Automotive and Industrial Applicationsから抜粋したS32K1ファミリの特徴が下図です。図はAEC-Q100グレード0と表記がありますが、Cortex-M0+のS32K11xは、データシートによるとグレード1です。

S32K1特徴
S32K1の特徴 (出典:S32K MCUs for Automotive and Industrial Applications)

S32K118EVB-Q064はDigiKeyで購入可能

新汎用MCUのセキュリティ強化策と専用IDE:S32 Design Studio(Processor Expert)

IoTでは汎用MCUであってもセキュリティ強化が必須です。現在、対策として3アプローチあります。

  1. 汎用コアMCUに、セキィリティ強化回路を内蔵(本稿)
  2. 汎用コアMCUに、外付けセキュリティデバイスを追加 → 関連投稿:セキュリティ強化デバイス:A71CH
  3. セキュリティ強化コアを採用 → 関連投稿:セキュリティ強化ARMコアCortex-M23/M33

1のメリットは、2と比べ部品点数が少ないこと、3と比べ従来の汎用コア開発との親和性が高く、セキュリティ関連開発が容易になる可能性があることです。

専用IDE:S32 Design StudioのAPI生成ツールは、旧FreescaleのProcessor Expertです。NXPが、なぜ既存LPCXpresso IDEでなく、専用S32 Design studioとProcessor Expertを用いたかは不思議です。が、Processor Expertという優れたAPI生成ツールのことを知っている開発者にとっては朗報になるかもしれません。

S32K1の魅力:車載・産業機器・IoT全共用

現在のS32K1ファミリ想定アプリケーションは下記です。車載・産業向けに別々のS32K1が有るわけではなく共用です。

S32Kアプリケーション
S32Kアプリケーション(出典:車載・産業機器向け Arm® Cortex®ベース S32Kマイクロコントローラ (REV 3.1))

2017~2018年に供給が始まり、最低15年の供給保障、全てに評価ボードもあります。Cortex-M0+とCortex-M4間の接続は、次世代車載ネットワークCAN FDです。

S32K14x(Cortex-M4)がNode MCU化しIoT無線通信機能を実装すれば、S32K11x(Cortex-M0+)をEdge MCUとして利用可能で、S32K1が「車載・産業機器・IoT全てを狙える新しい汎用MCU」に大化けする可能性はあると思います。

関連投稿:Node MCUとEdge MCU、気になる点2の章参照

そのほか、FlexIO、FlexTimerなどの新しい周辺回路も実装されていますので、S32K1を引き続き調査する予定です。

MCU:マイコン,Cortex-M0+コア,Cortex-M0コアテンプレート,ARMマイコン,Cortex-M0+,IoTマイコン,汎用,アプリケーション特化,プロトタイピング開発

大別するとマイコン:MCUには、汎用マイコンとアプリケーション特化マイコンの2種類があります。

弊社は、下記理由から汎用マイコン:General Purpose MCUを主として扱います。

  1. 対象ユーザとマイコンが多い
  2. 低価格で入手性の良い評価ボードが多い → オリジナルハードウェア開発にも役立つ
  3. 無償開発環境:IDEでもマイコンソフトウェア開発ができる
  4. 応用範囲が広い汎用マイコン開発の方が、顧客、開発者双方にとって有益である

汎用マイコンとは何か?に対しては、マイコンベンダ各社サイトのGeneral PurposeのMCUを指します。一方、アプリケーション特化マイコンとは、モータ制御、ワイヤレス制御、5V耐性などが代表的です。

かつては5Vマイコンが普通でしたが、現在は3.3V動作以下です。その結果、5V耐性がアプリケーション特化マイコンにカテゴライズされました。このように、時代や多数派に合わせて汎用の定義は変わります。高度なセキュリティや無線通信が必須のIoTマイコンも、いずれこの汎用マイコンにカテゴライズされると思います。

本投稿は、4番目の理由の追風となる記事を見つけたので紹介します。

汎用マイコンの動向記事

  1. “G”と”L”で考える発展途上の産業エレクトロニクス市場、2018年3月13日、EE Times Japan
  2. 産業FAは「汎用」「多数」の時代に、国産マイコンが変化を支える、2018年2月5日、TechFactory

最初の記事の”G"は、Global、"L"は、Localを意味します。マイコンベンダも、マイコンを使うユーザも、どのマイコンを使うかは暗中模索で混迷しているが、いずれはLocalからGlobalへ移行すると筆者は考察しています。

2の記事は、産業用FAが専用、少量装置から、AI:人工知能を利用した汎用、多数装置の時代に入ったと分析し、ルネサスRZ/AシリーズにAI機能を組込んでこの時代変化に対応すると宣言しています(関連投稿のSTMはコチラ、ルネサスはコチラを参照)。

どちらの記事も、アプリケーション特化マイコンより汎用マイコンの方が、より多く利用されると予想しています。マイコンベンダにとっても、汎用品で大量生産ができ供給コストも下げられます。

お勧めはプロトタイピング開発

FPGAにソフトウェアIPを組込み、より柔軟制御を目指したことや、高分解能ADCマイコンで精密測定などの開発も行いましたが、技術的に得るものは多くても開発時間が予定より長くなり、結局収支は赤字だった経験があります。

パソコンCPUと同様、汎用マイコン処理能力やセンサ能力も半導体製造技術とともに年々向上します。特に処理能力が必要なIoTマイコンは、コア動作速度を上げる、ディアルコアを採用するなど、ここ数年で急激に向上しています(PSoC6は、Cortex-M0+ 100MH動作、Cortex-M4 150MHz動作)。

弊社も今後の組込開発は、汎用マイコンを使い、より早く低コストで装置化する方が、顧客、開発側双方にとって有益だと考えます。開発期間が長いと、その間により高性能マイコンが発売されたりするからです。つまり、プロトタイピング開発をお勧めします。

プロトタイピング開発した装置が仮に能力不足であった場合は、その不足部分のみに改良を加える方がリスクも低く、確実に目的を達成できます。プロトタイピングの意味は、この能力不足部分を明確にし、低コスト低リスクで成功への道筋を探すことも含まれています。

汎用マイコンテンプレート

開発の立ち上げを早くすることがプロトタイプ開発の第1歩です。弊社マイコンテンプレートは、

  • 汎用マイコンの評価ボード上で動作確認済み
  • 複数サンプルソフトウェアをそのまま使った時分割の並列処理可能
  • 開発のつまずきを防ぐ豊富なTips満載のテンプレート説明資料添付

などの特徴があります。汎用マイコンテンプレートを活用し、効率的なプロトタイピング開発ができます。