半導体メーカM&Aと技術シナジー

本ブログでも関心があったFreescaleをNXPが買収し、そのNXPをQualcommが買収するという半導体メーカのM&Aは、終息に向かうようです。Runesasもアナログ、ミックスドシグナル半導体を得意とするIntersil(インターシル)の買収を完了しました。
※QualcommのNXP買収は、未だに決着がついていない買収案件だそうです。

一方で、AtmelとMicrochipに見る、半導体企業M&Aの難しさという記事を読むと、M&A完了後も企業の技術的シナジーが生まれるには時間がかかりそうです。

以前記載しましたが、NXP)LPC8xxのLPCOpenライブラリv3.01の状況を観ると、この記事内容は頷けるものがあります。MCU部門だけを比較すると、実はNXPよりもFreescaleの方が規模は大きく、また、Cortex-M0/M0+ MCUで比較すると、2社で重複する製品があるので、既成製品(LPC8xx、LPC111xやKinetisシリーズ)の将来は、明確には判らないのが現状だと思います。

統合開発環境:IDEは、旧FreescaleのKinetis Design Studio+Processor Expertと旧NXPのLPCXpresso+LPCOpenライブラリが、新NXPではMCUXpresso+SDK+Config Toolsとなり、一見、新しい開発環境に統合されたように見えます。

しかし、買収完了後の新発売MCU開発以外は、個人的には旧開発環境の方がどちらの既成製品開発にも適している気がします。

9月28日現在、LPC8xx用のLPCOpenライブラリv3.01は、残念ながら更新されていません

BLEとThreadソフト開発者必見動画

IoT通信規格のBLE 4.2とThread(802.15.4)両方をサポートするNXP)Kinetis KW41Z搭載の評価ボードを使ったBEL4.2とThreadメッシュ接続の開発Video(タイトルが以下Lesson 1~10)を紹介します。

Kinetis KW41Z Video Lesson Contents
Kinetis KW41Z Video Lesson Contents

BLEやThreadソフト開発者必見のLessons

内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。特に興味深い内容とその出所が以下です。

  1. Bluetooth ClassicとBluetooth Low Energyの本質的な違い(Lesson 3、3分ごろ)
  2. Bluetooth ClassicとBLE間を接続するBluetooth Smart Ready(Lesson 3、6分ごろ)
  3. BLE接続の具体例(Lesson 3、19分ごろ)
  4. BLE/Thread接続に必要な知識(Lesson 3, 6)
  5. Threadが生まれた背景(Lesson 6、2分ごろ)
  6. Cortex-M0+/48MHz、512MB ROM、128KB RAM、FreeRTOSで実現するBLE/Thread IoT端末(Lesson  5, 9, 10)

BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。

Kinetis KW41Z

KINETIS KW MCU FAMILY BLOCK DIAGRAM
KINETIS KW MCU FAMILY BLOCK DIAGRAM

Kinetis KW41Zの評価ボードは、以下の2種(Digi-Key価格)です。

低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。但し、Lesson 10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。

ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。

API for IoT

MCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。

BLE Protocol Stack
BLE Protocol Stack

また、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。
※簡単なIoT端末は後述

BLEやThreadは、IoT通信の有力な候補です。しかし、IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。

その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理(ADCスレッド)と、ADC変換データをIoT通信APIへ出力する処理(IoT出力スレッド)の2処理を追加開発すれば良いからです。

ADCスレッドは、IoT通信規格には無関係です。一方、IoT出力スレッドは、Uart出力と同様のIoT APIが使える(用意される)と思います。NXP)LPC8xxマイコンのUart APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。IoT API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。

*  *  *

IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。また、FreeRTOSを使えば、48MHz動作のCortex-M0+、512MB ROM、128KB RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。是非、ご自分でご覧になってください。

簡単なIoT端末のイメージ

データ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。
サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。
端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

RL78ファミリのロードマップ

最新RL78 MCUファミリのカタログから、ルネサスRL78 MCUの開発ロードマップを抜粋しました。今後のRL78 MCUの方向性として、アナログ、センサ対応力強化が見えてきます。

RL78ロードマップと周辺回路の強化ポイント

RL78ロードマップ
RL78ロードマップ(カタログP2より)

ページ2ロードマップの赤字コメントは、ルネサスがその製品特徴を一言で表したキーワードです。緑色新製品MCUの赤字記載で目立つのは、アナログ強化とセンサです(ここでは、前提条件として無償版開発環境CS+で開発できるMCUでフィルタリングするので、ROM64KB以上の製品は除外します)。

さらに、このアナログ強化とセンサの詳細内容をカタログ記載の各MCUから読むと、S1/S2/S3コアへ、周辺回路PGA:Programmable Gain Amplifierとコンパレータ、ADC/DACを強化した製品であることが判ります。汎用製品でも、よりIoT向けのMCUへ変化しつつあることが、同ページのRL78応用分野からも解ります。

ARM Cortex-M系に勝るRL78の高品質サンプルソフト

ARM Cortex-M系が全盛な低価格MCUの市場で、唯一独自16ビットS1/S2/S3コアでライバルと争っているRL78。この市場で生き残るには、価格や開発環境の良さに加えて、実際の開発がラク、手軽になることです。

前回、RL78開発者の方々へ少し悲観的な記事を書きましたが、RL78 MCUは、使えるサンプルソフトが豊富で解説が親切、理解しやすいことも特徴です。サンプルソフトの良さ悪さは、アプリケーションの早期開発(=プロトタイピング)には重要な要素です。プロトタイピングには、ルネサスの高品質サンプルソフトと、弊社RL78/G1xテンプレートを活用してください。

開発環境CS+のサンプルソフトは、付属のスマートブラウザーを使うと、検索が簡単です。

CS+スマートブラウザーによるサンプルソフト検索
CS+スマートブラウザーによるサンプルソフト検索

残念ながら、サンプルソフトの質は、評価しにくい項目なので、MCU選定時の項目からは除外されがちです。本ブログでは、RL78サンプルソフトの質が優れた特徴をもっとアピールしていきたいと考えています。

*  *  *

PS:LPC81x/82x共通化を目指したLPC8xxテンプレートV3の開発は、7Eを予定していましたが、LPCOpenライブラリv3.01付属サンプルソフトに複数の不具合があるため、一時停止としました。これら不具合解消後、再開します。

LPC8xxのGPIO制御とデバッグTips

NXP ARM Cortex-M0+マイコンLPCXpresso8xxのLPCOpenライブラリが、v3.01へ更新され、v2.x版から持ち越された多くのバグが修正されたようでした(結論から言うと、LPC81xにはバグが残っています。LPCXpresso8xxのLPCOpenライブラリv3.01は、前回の記事を参照してください)。

今回は、マイコン制御で最も基本となるGPIO制御を、MCUXpressoのサンプルソフトperiph_gpioと最新LPCOpenライブラリv3.01を使って解説し、さらにデバッグTipsを示します。

サンプルソフトperiph_gpioのGPIO API

LPCOpen v3.01のGPIO API数は、GPIO機能初期化、GPIOピン単位制御、GPIOポート単位制御の3種類で35個あります。全部使う必要はありませんので、最も基本的なGPIO APIを抜粋し使っているのがperiph_gpioで下記7個です。

periph_gpioのGPIO API一覧(その1)
GPIO API 概要
1 Chip_GPIO_Init(LPC_GPIO_PORT); GPIO機能初期化(=クロック供給)
2 Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, ledBits[i]); ピン(入)出力方向設定
3 Chip_GPIO_GetPinState(LPC_GPIO_PORT, 0, ledBits[LEDNumber]); ピン入力値取得
4 Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, ledBits[i], true); ピン出力値設定
5 Chip_GPIO_SetPinToggle(LPC_GPIO_PORT, 0, ledBits[LEDNumber]); ピン出力値反転

LPCXpresso8xxは、Portは0しかありませんので、「LPC_GPIO_PORT, 0,」は決まり文句、最後のパラメタは、GPIO0_xyzのGPIO論理ポート番号を示します。物理ピン番号ではない点に注意してください。

periph_gpioのGPIO API一覧(その2)
GPIO API 概要
6 Chip_GPIO_SetPortMask(LPC_GPIO_PORT, 0, ~PORT_MASK); ポートマスクレジスタ設定
7 Chip_GPIO_SetMaskedPortValue(LPC_GPIO_PORT, 0, count); ポート出力値設定(マスクレジスタ経由)

ポート単位のGPIO APIは、複数の出力ピン出力を同時に設定するもので、バス出力時に便利です。これら7個のGPIO APIのみを習得していれば、基本的なGPIO制御ができます。

評価ボード実行結果

LPC81xは、LPCXpresso812、LPC82xは、LPCXpresso824-MAXの評価ボードで実行した結果が下図です。

periph_gpio実行のデバッグ画面
periph_gpio実行のデバッグ画面(赤色がLPC824、青色がLPC812)

LPC81xとLPC82xでは、同じソースでも、ポート出力値が異なります。期待値は、LPCXpresso824-MAXでしか得られません。つまり、LPC81xにはGPIO APIのポート制御にバグがあることが判ります。

デバッグTips

ここで、デバッグのTipsを解説します。

MCUXpressoのローカル変数は、Quick Start ViewのVariablesタブで、周辺回路状況は、Workspace ViewのPeripherals+タブで表示可能です。適当な場所にブレークポイントを設定しF8クリックで、ブレークポイントまで実行します。評価ボード実行結果は、この操作で得られたものです。

現行版MCUXpressoは、デバッグでよく使うファンクションキーのツールチップが一部表示されません。
F8(実行)と、F5(ステップ実行)、F6(ステップオーバー:関数に入って処理「後」停止)、F7(ステップリターン:関数に入った状態で処理「後」停止)を覚えておくとデバッグ効率が良くなります。

LPCOpenライブラリv3.01のLPC81xポート制御、バグ回避方策

LPC812とLPC824はGPIOレジスタ構成が異なります。後で開発されたLPC824の方が、より制御し易いレジスタを備えています(ハードウエアマニュアルより抜粋)。

LPC824とLPC812のGPIOレジスタ比較
LPC824とLPC812のGPIOレジスタ比較

バグがあったLPC81xのポート出力値設定の代替として、他のGPIO API利用または、直接ハードレジスタ操作などを試しましたが、LPCOpen v3.01では、代替方法が見つかりません。思うにLPC81xライブラリの結構深い場所にバグがある可能性があります。

そこで、LPC81x動作には、旧LPCOpenライブラリv2.15を、LPC82x動作には、最新LPCOpenライブラリv3.01を使ってLPC82xテンプレート開発をすることに方針変更しました。当初目標のLPC8xxテンプレート、つまりLPC82xとLPC81xの両方を同じテンプレートソースで実現することは、残念ながら諦めました。

MCUXpressoでの旧LPCOpenライブラリv2.15の使い方

MCUXpressoは、このようなバグの場合に備えて旧LPCOpenライブラリ群も備えています(C:\nxp\MCUXpressoIDE_10.0.2_411\ide\Examplesフォルダ参照)。最新版MCUXpresso IDE v10.0.2_411でもLPCOpenライブラリv3.01が同封されていないのも、本稿で示したバグが理由かもしれません。

旧LPCXpressoプロジェクトをMCUXpressoで開こうとすると、下記ワーニングが出力されます。

Older Workspace Version Warning
Older Workspace Version Warning

旧LPCXpressoとMCUXpresso両方を使い続ける方は、LPCXpressoプロジェクトをコピーして別名のプロジェクトを作成した後に、MCUXpressoで開くと良いでしょう。

LPC81xテンプレートV2.1は、テンプレートプロジェクト内にLPCOpenライブラリv2.15を装着していますので、そのままMCUXpressoで開いても問題なく動作します。

*  *  *

LPCOpenライブラリv3.01を使った新しいLPC82xテンプレートV3の開発は、7E目標で進行中ですが、上記のようなLPCOpenライブラリv3.01バグがあり、予定より難航しています。ちなみにUart関連は、LPCOpenライブラリv3.01でかなり改善されました。

また、MCUXpressoは、Ctrl+スペースキーによる入力補完機能も実装されており、使い勝手は向上しています。旧LPCXpressoを使う必要性は低いと思います。

LPC8xxテンプレートV3完成は、今しばらくお待ちください。

NXP LPC8xx LPCOpenライブラリ更新

NXPのLPX8xxのLPCOpenライブラリが、1年7か月ぶりに更新されv3.01になりました。リリースノートを見ると、多くのバグが修正され、積み残しバグ(Carried Forward)も(現時点では)無くなりました。

なお、7月11日発表のMCUXpresso IDE v10.0.2 [Build 411]に、この最新LPCOpenライブラリv3.01は、未だ同胞されていません。 是非LPCOpenサイトから手動でダウンロードしてください。

v2.15積み残しGPIO APIバグ解消

本ブログ2015年9月記事のGPIO APIバグも解消されました。
このGPIO APIバグは、2年以上前のv2.15から積み残されたものです。GPIO APIは、マイコンAPIのなかで最も重要かつ頻繁に使うものだけに、手動で修正し利用されていた方も多いと思いますが、やっと解決されました。

LPC111xのLPCOpenライブラリは未更新

LPC1100シリーズのLPCOpenライブラリ更新状況がコチラです。残念ながら、弊社LPC111xテンプレートで使用中のLPCOpenライブラリLPC11C24は、v2.00a(2013/09/13)のままです。但し、LPC111xテンプレート動作には特に問題ありません。

LPC82xテンプレート開発再開

LPC8xx LPCOpenライブラリが更新され、GPIO APIバグも無くなりましたので、前述の2015年9月記事で一時停止中であったLPC82xテンプレートの開発を再開します。

開発環境は、旧LPCXpressoを変更し、最新のMCUXpressoとします。リリースは、7月末を予定しております。
勿論、既存LPC81xテンプレートも最新LPCOpenライブラリv3.01を使って再開発し、まとめてLPC81x、LPC82x両方に対応したLPC8xxテンプレートとします。

また、Cortex-M系マイコンのコードテクニックとして有名な、ループ構文には、カウントダウンの方が高速でコードサイズも小さいことをテンプレートへ取り入れた改良も加える予定です。
※上記コードテクニックは、ARMコンパイラバージョン6.6ソフトウエア開発ガイド 7章を参照してください。

*  *  *

LPCOpenライブラリの更新は、NXPの 各種Cortex-Mマイコンへの力の入れ具合を反映したものと思います。

最新マイコンのLPC54xxxのLPCOpen版数は、v3.03.000やv3.00c.001で、LPC8xxよりも更新日も早いのは当然ですが、LPC8xxが、例えばLPC13xxなどの既存他シリーズよりも早くLPCOpen v3.xxへ更新されたのは、反映結果でしょう。これは、2016年12月記事の2017NXPロードマップとも符合します。

既存マイコンの置換え市場を狙った、小ピンでスイッチマトリクスを持つ32ビットLPC8xxマイコンの優位性を示す指標の1つだと言えます。

ARM Cortex-M3低価格化への期待

ARM Cortex-M3の設計開始時ライセンス費用がCortex-M0同様、無償化されることが発表されました。

これにより、新たに商品化されるCortex-M3コアを使ったMCU価格が下がる可能性があります。Cortex-M0(ARMv6-M)を100%とする性能比較をみると、Cortex-M3(ARMv7-M)の性能向上比が大きいことが判ります。

Performance of Cortex-M
Performance of Cortex-M

RTOSやIoT通信などのMCU環境の変化を考慮すると、コストパフォーマンスに優れたCortex-M3を次期MCU選択肢に、より入れやすくなります。

NXP LPC84x発表、2017/3Qより供給予定

6月27日、NXP LPC8xxロードマップ2017掲載のLPC84xが発表されました。

LPC84xは、従来のLPC8xx(小ピン+スイッチマトリクス)に、新たな特徴が追加されました。

・高速アクセス初期設定メモリ(FAIM)により、電源オン時クロック低周波数モード起動が可能でスタートアップ消費電流を最小化
・GPIOポートの設定構成による即時起動が可能で、MOSFETなどの付属デバイスによる潜在的な終端問題を解消

データシート6章のブロック図を示します。

LPC84x Block Diagram
LPC84x Block Diagram(データシートより)

スタートアップ消費電流の最小化を実現するのが、FIAM:Fast Initialization Memoryでこれを使うことで1.5MHzブートが可能です。起動を繰り返してもバッテリー消費が抑えられ、より長い期間の動作が期待できます。

また、容量式タッチセンシングやライブラリーによる自動キャリブレーションなどのアプリケーション向きの機能も追加されています。

LPC8xx MCU Lineup
LPC8xx MCU Lineup(ファクトシートより)

2017/3Q(7~9月)に評価ボードLPCXpresso845-MAXとともに供給開始の予定だそうです。

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)が実現します。

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マイコン開発へ全面変更いたしました。

STM32CubeMXの使い方

STM32マイコンのソフト開発を早く効率的にするのが、STM32CubeMXです。コード生成ツールのSTM32CubeMXの概要、使い方を示します。

STM32CubeMXの使い方ビデオ

STMが提供するSTM32CubeMX解説ビデオは、このページの右に2つあります。STM32CubeMX – Overview (6:44)とGetting Start with STM32CubeMX (9:12)です。Overviewを見ると概要が、Getting Startを見ると、5つの使いこなしポイントが判る(かも?)という内容です。STM32CubeMXのマニュアルUM1718もページ下にあります。

この2ビデオとUM1718、その他の関連資料から、私なりにSTM32CubeMXの要点、使い方を纏めましたので以下に示します。

STM32CubeMXのウイザード

STM32CubeMXは、4IDE(SW4STM32ほか3種IDE、前回記事参照)へプロジェクトファイルと初期設定(クロック設定と周辺回路)Cソースコードを自動生成します。この生成の基になるのがPinout、Clock Tree、Peripheral & Middlewareの3ウイザードです。

Power Consumptionウイザードは、生成時の消費電力を評価する計算ツールです(使用例はコチラを参照)。

STM32CubeMX Four Wizard
STM32CubeMX Four Wizard

STM32CubeMXの3ウイザード設定後、コード生成(Ctrl + Shift + G)実行で指定先へプロジェクトファイルが出力され、これをSW4STM32でImportすれば、初期設定コード付きのプロジェクトが得られます。

従って、残りのユーザ処理をプロジェクトへ追加していけば、アプリ完成という段取りです。

STM32CubeMXの2種ドライバライブラリ

注意点は、デフォルトでSTM32CubeMXが生成するのは、HALドライバライブラリを使ったプロジェクトだということです。勿論LLドライバライブラリでの生成も可能ですが、この場合は、初期設定ソースコードが自動生成されません。LLライブラリ利用の場合は、ユーザが初期設定コードも書く必要があります。

つまり、STM32CubeMXでLLドライバを使うと、SW4STM32で、初期設定とユーザ処理の両方をプロジェクトに追記しなければならず、しかも、各LLドライバ分解能はHALに比べて低いので、より多くのLL APIを使った追記が必要です。

HALとLLは、UM1749(全1466ページ)に詳しい説明があります。
HAL: Hardware Abstraction Layerとは、文字通りハードウエアを抽象化し、より簡単に周辺回路制御ができるAPIをユーザ側へ提供します。
一方、LL: Low Layerは、速度優先でエキスパート向けのAPIですので、高速ですが移植性や可読性はHALよりも低くなります。

HALとLLのAPIを相対比較した表が下記です。

STM32CubeMX HAL and LL APIs Comparison
STM32CubeMX HAL and LL APIs Comparison

追記コードはHALの方が少なくても、実際はHALの方が抽象化オーバーヘッドの分だけコンパイル後のコードサイズは大きくなります。プログラムにもよりますが、その差は60~80%だそうです。LLを使うとこのサイズが小さい分だけ高速処理が可能ということです。

STM32CubeMXでLLを使って生成するプロジェクトファイルは、本当の意味でフレームワークのみです。

Peripheralウイザード設定の目的は、SW4STM32のAPI入力支援機能を活用するためです。例えばコード記述中、LL_DAC_まで入力後、Ctrl + spaceを押すと、可能性があるLL APIがリストで選べます(HAL APIも下記のように同様)。Visual StudioのIntellisence機能のマイコン版に相当します。

Intellisence (Ctrl + Space) and USER CODE BEGIN to END
Intellisence (Ctrl + Space) and USER CODE BEGIN to END

このIntellisenceが表示するAPIは、当該周辺回路の全てのAPIを示すと思います。全てのAPIから使えるAPIを選ぶには、Peripherals & Middlewareウイザードの設定意味が解っている必要があるでしょう。

再度STM32CubeMXでコード生成し、プロジェクトファイルを作り直しImportしても、ユーザ追記部分を残すためには、USER CODE BEGINからUSER CODE ENDまでのコメント間に記述します。これは、Runesas CS+のコード生成と同じです。

STM32マイコンテンプレートはHALドライバライブラリを使用

使用するドライバライブラリは、60~80%の高速性か、ポータビリティかの選択です。STM32マイコンは、ROM/RAMが大容量なこと、コア速度も速いこと、STM32CubeMXもデフォルトでHAL使用することから、STM32マイコンテンプレート開発にも、HALライブラリを使います。

これにより、当初の目的であった機種特定を避けCortex-M0/M0+コアのSTM32F0/L0や、Cortex-M3のSTM32F1などのSTM32マイコン全てに使えるベアメタルマイコンテンプレートを開発します。

*  *  *

ここまでが、STM32CubeMXコード生成の使い方です。使用ライブラリにHALを選べば、初期設定Cソースコード付きのSW4STM32プロジェクトが作れます。

ビデオや各種資料もここで終わるものが多いのですが、ソースにユーザ処理の追加が残っています。このユーザ処理の参考にすべきなのが、STM32CubeMXのRepositoryフォルダで提供される周辺回路毎のサンプルソフトです。

STM32CubeMXサンプルソフトの使い方

前回記事Figure4に示したExampleで提供されるのが、HALライブラリ使用のサンプルソフトです。Example_LLはLLライブラリ利用サンプル、Example_MIXは、HALとLLの混合サンプルを示します。

いずれのサンプルも、4IDEで使える構成になっているのは、前回記事の通りです。

サンプルソフトがSTM32CubeMXを使って作られたものなら、そのまま利用できるのでBestですが、残念ながら専門家、人が開発したプロジェクトです。しかし有力なサンプルであることに違いはありません。

従って、使う周辺回路が決まったら先ずこのExampleで使用例を大体でも知ったうえで、コード生成するのが本来のSTM32CubeMXの使い方手順だと思います。この前処理抜きでPinout、Clock Tree、Peripheral & Middlewareの3ウイザードを正しく設定できれば別ですが、分厚いマニュアルを読むよりは効率的だと思います。

まとめ

私は、STM32CubeMXは、コード生成とRepository内のサンプルソフトの両方を、車の両輪のように同時に使うことでSTM32マイコンのソフト開発が早く効率的になると思います。

効率的なSTM32CubeMXの使い方は以下です。

1) Repositoryフォルダから使用する周辺回路とライブラリに応じたサンプルソフトを探し、おおよその利用法、特にユーザ処理を知る(サンプルソフトファースト)
2)コード生成Pinout、Clock Tree、Peripheral & Middleware各ウイザードを出来るならサンプルソフトと同じ設定にし、コード生成を実行(デフォルトはHALライブラリを使うことに注意)
3)生成されたプロジェクトをIDEにImportし、ユーザ処理を1)のサンプルソフトを参考にUSER CODE BEGIN~ENDの間に追記し、デバッグ
4)再度コード生成しても3)で追記したユーザ処理は残る(但し、ヘッダーファイルは完全に上書きされるので注意)

STM32マイコンテンプレートは、STM32CubeMXのHALドライバを使い、MCUコア依存性が少ないベアメタルテンプレート開発にする方針を立てました。STM32マイコンテンプレートの目的を知りたい方は、弊社マイコンテンプレートサイトをご覧ください。