目次
この記事でできること
- STM32CubeIDEをインストールできる
- STM32CubeMXでプロジェクト生成できる
- ビルド〜書き込み〜実行までできる
- STM32開発の基本ワークフローを理解できる
はじめに
仕事はハードウェア開発でソフトウェア開発はからっきしなgoldear@JiN_C125です。
趣味のソフトウェア開発の主軸はMicroPython@RP2040、Python@RaspberryPiで、IoT機器やGPSロガー程度であれば何も問題はありませんでした。
過去にこんなものを作ってました。
ただ、少し込み入ったものを作ろうとするとスペック不足は否めません。そこでC言語@STM32H7で電子工作を始めようと考えました。STMicro製のSTMシリーズに関してはよく耳にするが、肝心な入門記事・情報が少なすぎて避けていたところがあります。今回は私の備忘録も兼ねて基本的な動かし方をシリーズ記事で書き、最終的にはFFT付きのポータブル計測器を作るところまで発展させる予定です。
今回のゴール
本記事のゴールは以下となります。開発の準備段階となります。
- STM32CubeIDEインストール
- プロジェクト生成
- Lチカできる状態まで
使用環境
- STMicro Nucleo STM32H723ZG (秋月電子)
- STM32CubeIDE v2.0.0
- STM32CubeMX v6.16.1
- Windows / Linux (本シリーズはWindowsで実施)
- USB Micro-B ケーブル
USB Micro-B ケーブルは開発ボードに付属していないので注意。
STM32開発では、主に以下の2つのツールを使用します。
- STM32CubeMX：ピン設定やクロック設定などの「構成ツール」
- STM32CubeIDE：コード編集・ビルド・書き込みを行う「開発環境」
全体の流れ
本記事では、STM32開発の最初の一歩として、以下の流れで環境を構築していきます。
- STM32CubeIDE / CubeMX のインストール
- CubeMXで新規プロジェクト作成
- 自動生成されたコードの構造を理解
- ビルドして実機へ書き込み
まずは「動かせる状態を作ること」をゴールに進めていきます。
細かい内部構造や設計方針については、後半で解説します。
Step1. STM32CubeIDE/CubeMXのインストール
まずは公式ページから2つのツールをダウンロードします。ダウンロードにはSTMicroのアカウントが必要となりますが、ゲストアカウントでもダウンロードできるようです。
STM32CubeIDE
STM32CubeMX
STM32CubeIDEのインストール
特に難しいことはありません。ポチポチとNextしてください。
初回インストール時にドライバインストール確認ダイアログが表示されます。（詳細は後述）。
インストールが完了すると、生成ファイル除外ダイアログが表示されます（詳細は後述）。
STM32CubeMXのインストール
特に難しいことはありません。ポチポチとNextしてください。
Step2. 新規プロジェクト作成 (CubeMX)
STM32CubeIDEとSTM32CubeMXのインストールが完了したら、次はCubeMXでプロジェクトを作成します。以前はCubeIDE内からCubeMX相当の設定ができましたが、本記事ではCubeMXで生成→IDEでビルドの流れで進めます。
Start My project from MCU 「ACCESS TO MCU SELECTOR」をクリックして開発ボードのMCUを選択していきます。
初回選択時はファイルのダウンロードが発生します。
左上のPart Numberに「STM32H723ZGT6」と入力して、右下のMCU ListからMCUを選択。右上のStart Projectをクリックします。
MCUが表示されて、ピンを設定していきます。今回はLチカ用にUser LEDに接続されているピンを設定していきます。
とは言うもの、どのピンがアサインされているのかわからないので、以下のページからSTM32H723ZG開発ボードのドキュメントを参照します。UM2407が該当するユーザマニュアルになります。
7.6.1. LEDs に以下のように記載されているので、これらに従って設定します。
User LD1: A green user LED → PB0
User LD2: A yellow user LED → PE1
User LD3: A red user LED → PB14
MCUから該当するピンをクリックして、「GPIO_Output」 を選択します。3つのピンを同様に設定したらLチカの準備完了です。
今後、どのピンが使用可能なのか調べる必要があります。回路図を見たほうが早いので、以下のドキュメントも参考にしてください。
Schematic
System Core → GPIO からさきほど設定したピンにUser Labelを付けます。他のピンも同様にUser Labelを付けておきます。
クロックの設定を行います。難しそうですが、自動で選択してくれるので全く難しくありません。
550MHz max と記載されている箇所がメインCPUの周波数になります。これを550MHzにセットしてください。周辺回路の周波数も自動で設定されていきます。
プロジェクトを設定します。Project Name と Project Location は任意の名前・場所を設定してください。プロジェクトは基本的に相対パスなので後からの場所の移動は可能です。
特に重要なのがToolchain/IDE で「 STM32CubeIDE」を選択してください。
「Toolchain / IDE」では、どの開発環境向けのプロジェクトを生成するか を指定します。
今回は STM32CubeIDE を使用するため、「STM32CubeIDE」を選択します。
この設定により、以下の設定ファイルが生成されます。
- Eclipse形式のプロジェクトファイル
- ワンクリックビルド／デバッグが可能
もし VSCode + Makefile など別の開発スタイルを使う場合は、
ここで「Makefile」などを選択すると、対応したビルド環境用のファイルが生成されます。
つまり、この項目は「将来どのIDE・ビルド方法を使うか」を決める重要な設定 です。
最後に右上の「GENERATE CODE」をクリックしてプロジェクトファイルを生成します。
初回ビルド時はファームウェアがないからダウンロードするとのメッセージが出ます。そのままYesで大丈夫です。
Step3. 自動生成コード群の構成と中身を理解する
STM32のプロジェクトは大量のファイルが生成されますが、覚えることはシンプルです。
普段触るのは main.c のUSER CODE部分だけです。
それ以外は基本的に自動生成コードなので、原則触りません。
STM32CubeMXでコード生成すると、上記のような構成になります。
最初はファイルが多くて戸惑いますが、実際に触る場所はごく一部だけです。
重要なポイントはこの3つだけ
- Core/
- main.c
- 割り込み処理
- ユーザーコードを記述
- Drivers/
- HAL本体
- CMSIS
- ベンダ提供ライブラリ
- .ioc
- CubeMX設定ファイル
- プロジェクトファイル群生成のための元ファイル
- 実質こいつが本体
Driversフォルダには、STM32を動かすための基本ライブラリが入っています。
CMSIS
→ ARM Cortex-M 共通の低レイヤ定義（CPUレジスタ・割り込み番号などの土台）
HAL（Hardware Abstraction Layer）
→ GPIOやSPIなどを簡単な関数で操作できるAPI集（普段直接使うのは主にこれ）
これらは「STM32を動かすための基礎部分」なので、基本的に編集せず使うだけでOKです。
なお、FatFsやUSBなどの追加機能は Drivers ではなく
Middlewares フォルダ に配置されます。
これらは 基本的に編集せず「使うだけ」 でOKです。
int main(void)
{
HAL_Init();
SystemClock_Config();
MX_GPIO_Init();
while (1)
{
/* USER CODE BEGIN */
/* USER CODE END */
}
}
・ USER CODE内 → 自分のコードを書く
・ それ以外 → 再生成で上書きされる可能性あり
USER CODEブロック
- USER CODE BEGIN/END の中は再生成しても残る
- 上記以外の“外側”に記述するプロジェクト再生成時に消えることがある
- 「自分の処理は基本ここ」
補足1) HAL_Init()：OSの起動みたいなもの
HALライブラリの初期化処理です。SysTickタイマや割り込み設定など、HALを使用するための準備を行います。
通常は意識する必要はありません。
HALライブラリの初期化
SysTick（1msタイマ）など、HALが動くための土台
割り込み優先度グループ等の設定が入ることが多い
補足2) SystemClock_Config()：CPUの“速度設定”
この関数は、CPUや周辺回路の動作クロックを設定する初期化コードです。
ただし 手動で編集するための関数ではありません。
設定内容はすべて CubeMX のクロック設定画面から自動生成されます。
つまり以下のような関係です。
・設定変更 → CubeMXで行う
・SystemClock_Config() → 自動生成される結果
直接編集しても、再Generate時に上書きされてしまうため注意してください。
補足3) MX_GPIO_Init()：CubeMX設定が“コードになった”場所
CubeMXで設定した内容がここに反映される
「GUI設定 → Cコード化」の接点
while (1)
{
/* USER CODE BEGIN */
HAL_GPIO_TogglePin(LED_RED_GPIO_Port, LED_RED_Pin);
HAL_Delay(500);
/* USER CODE END */
}
例えば、LEDを点滅させる処理を書く場合も、上記のように USER CODEブロックの中だけ に記述します。
GPIOの詳しい設定方法やLチカの実装については、次回の記事で解説します。
Step4. ビルドと書き込み
プロジェクトが生成できたら、実際にビルドしてボードへ書き込みます。
ツールバーのハンマーアイコン（Build）をクリックします。
エラーが表示されず、Build Finished と表示されれば成功です。
Nucleo開発ボードをUSBで接続した状態で、「Run」(再生マーク)または「Debug」(虫マーク)をクリックします。
ST-LINK経由で自動的に書き込みが行われ、プログラムが実行されます。
これでSTM32への書き込みが完了しました。
次回はいよいよGPIOを使ってLチカ（LED点滅）を実装していきます。
ハマりポイント・注意点
環境構築中に実際に「戸惑ったポイント」をまとめておきます。
Q. ST-LINKドライバの警告が表示された
→ 初回接続時に表示されます。公式ドライバなのでインストールしてOKです。
これは Nucleo 開発ボードに搭載されている ST-LINK のUSBドライバ です。
ST-LINKは以下の役割を持っています。
- 書き込み（Flash書き込み）
- デバッグ（GDB接続）
- 仮想COMポート（printf出力）
このドライバインストールは必須ですので、「インストール」を選択してください。
Q. Microsoft Defenderの除外ダイアログが出る
→ ビルド時のスキャンを省略して高速化するための確認です。許可推奨です。
これは Windows Defender がビルドフォルダをウイルススキャン対象から除外するかと確認してきています。
STM32CubeIDEでは、ビルド時に大量の中間ファイル（.o や .elf など）を生成します。これらを毎回スキャンするとビルド時間が長くなるため、IDE側が「除外すると高速になります」と提案してきています。基本的には開発環境のビルド生成物なので問題になりにくいですが、気になる場合は除外せずに進めてもOKです（その分ビルドが遅くなることがあります）。
Q. 初回に「ファームウェアダウンロード」が始まってめちゃくちゃ時間がかかる
→ 初回起動時に、大量のダウンロードが始まることがあります。
これは STM32H7用のファームウェアパッケージ（開発用SDK一式） の取得処理です。
サイズは約1.7GBもあり、環境によっては数分〜十数分かかります。
中身は以下の通り「開発に必要な部品一式」です。
- HALライブラリ
- CMSIS
- 各種ドライバ
- USB / Ethernet / FatFs
- サンプルコード集
ST-LINKのファームウェア更新とは別物なので、時間がかかっても正常動作なのでそのまま待てばOKです。
正直これが一番時間かかりました（笑）
Q. ST-LINKのファームウェア更新が始まった
→ 初回のみ発生します。数分かかることがありますが正常です。
初回書き込み時にST-LINKのファームウェアアップデートが発生する可能性があります。YesでファームウェアをアップデートしてOKです。
Q. プロジェクトがビルドできない（謎エラー）
→ パスに日本語・全角・スペースが含まれていると失敗することがあります。
英数字のみのフォルダ名を推奨します。
Q. コードを書いたのに消えた
→ USER CODE以外に書くと、CubeMX再生成時に「ひっそり消えます」
必ず USER CODE ブロック内に記述しましょう。
ディレクトリ設計方針
ここまでで、STM32CubeMXによって自動生成されたプロジェクトをそのまま使用できるようになりました。ただし実際の開発では、生成コードと自分のコードを分離して管理することが非常に重要 になります。生成コードを書き換えてしまうと、以下の問題が発生します。
- 再Generate時に消える
- どこが自作コードかわからなくなる
- 保守が困難になる
そのため本シリーズでは、以下のように責務ごとにディレクトリを分けて開発していきます。
drv/ : OLED・SDなどデバイスドライバ
mw/ : 外部ライブラリ（FatFsなど）
app/ : アプリケーションロジック
- 上記フォルダ ＝ 自分のコード（触る）
- Core/Drivers ＝ CubeMX管理（基本的に触らない）
これらを徹底することで、以下のようなメリットがあります。
- 再生成しても安全
- 見通しが良い
- 機能追加しやすい
CubeMXが生成する Core/Drivers は「生成物」なので、自分のコードをプロジェクト直下に分離して管理する方針にしました。
これにより、再生成の影響を最小化し、保守性と拡張性を確保できます。
詳細は次回以降の記事で少しずつ実装していきます。
まとめ
今回はSTM32H723ZGを使った開発を始めるため、STM32CubeIDEとSTM32CubeMXのインストール・開発環境の構築を実施しました。今となったから言えるのですが、最初は「とっつきにくいツールだな」と思っていたのですが、触っていくうちに「そこまで複雑じゃないじゃん」ってなりました。次回はGPIOでUserLEDを使ったLチカを実装していきます。
【STM32H723ZG入門②】GPIO編 に続きます。
コメント