シリーズ：基礎シリーズ（組み込み開発）
この記事のねらい：実験シリーズ「評価ボードでLEDを点滅」に入る前に、最低限の開発フロー（作る→書く→動かす→止めて見る） だけを理解する。
※点滅はループで待つだけのシンプルな想定。
はじめに（最初に伝えたいこと）
評価ボードでLEDを点滅させるとき、つまずきやすいのは「LEDの回路」よりも、
- どうやってプロジェクトを作るのか
- どうやってビルドするのか（マイコンが動く形に作り直す）
- どうやって動かすのか（書き込み含む）
- どうやってデバッグするのか（不具合の原因を調べる）
という 開発の流れそのもの です。
この記事では「最低限これだけ分かれば、LED点滅実験に入れる」という範囲に絞って説明します。
※インストール手順や画面操作の詳細は、別記事（セットアップ／操作）に分けます。
要点（これだけ覚えればOK）
- 組み込み開発は 「編集 → ビルド → 書き込み → 実行」 の繰り返し
- 動かないときは、まず ビルドが通っているか／書き込みできているか を確認する
- LED点滅を行うなら、最初は FSPの生成コード＋APIを使えばOK（レジスタ直叩きは後回し）
- 待ち時間は、最初は ループで待つ（delay） で十分
1. 組み込み開発って何をしている？
組み込み開発の基本作業は、次の4つです。
- ソースコードを書く（C言語）
- ビルドする（コンパイル＋リンクして「実行させるファイル」を作る）
- マイコンに書き込む（マイコンにプログラムを入れる）
- 動かして確認する（うまくいかない場合は原因を調べる）
※ビルドについては、この後説明します。
LED点滅は、この一連の流れを「小さく」「確実に」体験するのに最適な題材です。
2. この実験で出てくる道具（役割だけ）
※ここでは「役割」だけ押さえます。インストール手順や接続手順は別記事／実験記事で扱います。
- 統合開発環境（IDE）：e² studio
コード編集、ビルド、動作確認をまとめて行う場所 - FSP（Flexible Software Package）
RAシリーズ用の設定・生成コード・ドライバAPIを提供する仕組み - 評価ボード／デバッガ（実機側）
書き込みや実行確認に使う（※実機での書き込み・接続は実験シリーズで扱います）
※評価ボードの見方は「マイコン（RA8M2）」カテゴリで扱います
※デバッガは、動いているプログラムを 止めて、いまの実行状況を確認するためのツールです。
統合開発環境（e² studio）に含まれています。
3. 最初に知っておくと迷わない「プロジェクトの中身」
LED点滅の時点では、細部は分からなくてOKです。雰囲気だけ押さえます。
- main.c：処理を書く場所（LEDを点滅させるプログラムの場所）
- 生成コード（FSPが作る部分）：最初は「土台」として使う
（ボード設定、クロック、ピン設定、ドライバなど）
※生成コードとは、統合開発環境で自動で作成してくれるコードのことです。
※最初の段階で「生成されたファイル全部を理解する」のは不要です。
LED点滅の目的は 開発フローに慣れることです。
4. 作業の流れ（LED点滅に入る直前まで）
ここは実験記事と重なるので、この記事では「何をするか」を整理します。
4-1. 新規プロジェクトを作る（やることの意味）
「プロジェクト」は、ソースコード（Cファイル）や設定（FSP設定など）をまとめて管理する ひとまとまり です。
まずプロジェクトを作る＝「このマイコン用に開発を始める土台を作る」イメージです。
- 対象のマイコン／ボードに合ったプロジェクトの枠を作る
- FSPの設定ができる状態にする
目的：ビルドできる「枠」を作る
4-2. ビルドする（最低限のゴール）
ビルド（build）は、簡単に言うと 「書いたC言語のコードを、マイコンで動く形に作り直す作業」 です。
- IDE（統合開発環境：e² studio）のビルドを実行する
- エラーが0で終了することを確認する
目的：まず 「マイコンに書き込める」状態を作る （実行ファイルを作る）
※LEDが光る前に、ここで止まることが一番多いです。
4-3. 書き込む（ここでは“意味”だけ）
- ビルドで作った成果物をマイコンに転送して、フラッシュメモリに入れる
目的：マイコン側で実行できる状態にする
※具体手順（接続・書き込み操作）は実験シリーズで扱います。
4-4. 実行する（最低限のゴール）
- 実行して動作確認する
- うまくいかない場合は、次章の「デバッグの最小」を使う
5. デバッグの最小（LED点滅に必要な分だけ）
デバッグとは、
- 狭い意味のデバッグ：不具合の原因を調べて直す（いわゆる“バグ取り”）
- 広い意味のデバッグ：プログラムを止めたり中身を見たりしながら、動作を確認する作業全般
です。
LED点滅で必要なデバッグは、これだけで十分です。
5-1. ブレークポイント（プログラムを止める位置）
ブレークポイントは、プログラムを止めたい行に置く「目印」です。
main()の先頭や、ループの中にブレークポイントを置く- 実行して、そこで止まることを確認する
これができると分かること：
- 書き込みできている（少なくとも実行対象が動いている）
- CPUが動いている
- どこまで実行できているか追える
5-2. ステップ実行（1行ずつ進める）
- Step Over / Step Into を使ってプログラムを1行ずつ動かす
- LED制御の処理が実行されているか確認する
5-3. 変数の値を見る（必要なら）
LED点滅では必須ではありませんが、
- カウンタ変数が増えているか
- 条件分岐が期待通りか
など、確認に使えます。
6. 今回はタイマーを使わない：待ち時間は「ループで待つ」でOK
LED点滅には「待ち」が必要です。タイマーを使うと説明が増えるので、最初はループで十分です。
6-1. ループ待ちの考え方
CPUが何回も同じ処理を繰り返す → それが待ち時間になります。
6-2. 注意点（初心者がハマるところ）
- ループ待ちは消えることがある
ループで待ち時間を作るとき、何も起きない処理（ただ回しているだけ）は、ビルド時に
「この処理は結果に影響しない＝なくしても同じ」 と判断して、処理をまとめたり消したりすることがあります。
その結果、思ったより点滅が速くなったり、待ち時間がほとんど無くなったりします。 対策：volatile変数を使って「この処理は意味がある」ことを明示する。
またはFSPのdelay APIを使う。 - 正確な時間にはならない
目で見て点滅すればOK。時間精度は後回し。
7. よくあるつまずき（最低限）
7-1. ビルドエラーで止まる
ビルドが通らない原因は、コードの間違いよりも 「開発環境の設定が合っていない」 ことがよくあります。
たとえば「必要な部品（ライブラリ）を見つけられない」「コンパイラの設定が違う」などです。
7-2. 書き込みできない（実機側）
- USBケーブル（充電専用）問題
- デバッガ選択ミス
- ボードの電源／設定
※具体手順は実験シリーズ側の「書き込み」パートに寄せます。
7-3. 実行しても止まらない／動かない
main()にブレークポイントで止まるか確認- とまらない → マイコンにプラグラムを書き込みできていない・実行が始まっていない可能性
- とまる → LED制御部分（GPIO設定や点灯条件）を疑う
8. 実験シリーズを行う準備チェック（これだけ）
- e² studioが起動できる
- プロジェクトが開ける／作れる
- ビルドがエラー0で通る
- 実験シリーズの記事の「書き込み」手順に進める状態になっている
まとめ
- 組み込み開発は 編集→ビルド→書き込み→実行 の繰り返し
- LED点滅の前に、まず ビルドが通る状態を作る
- うまくいかないときは 「ビルド」「書き込み」「mainで止まるか」 を順に確認する
- 点滅の待ち時間は最初は ループで待つで十分（正確さは後回し）
次に読む（おすすめの順）
- 次回：LED点滅に必要なC言語だけ（main / while / 関数 / delay）
- 実験シリーズ：RA8M2評価ボードでLEDを点滅（手順・コード・結果・つまずき）