iPadからマイコンに書き込みたいんだ！！！

[iPad / Webアプリ]
  ① ファーム(.bin)を選ぶ
  ② BLEでESP32へ小分け送信
              ↓
[ESP32]
  ③ 受け取った順にFlash(OTA領域)へ書く
  ④ 受信完了後に整合性チェック
  ⑤ 次回起動先を新ファームへ切替
  ⑥ 再起動 → 新ファームで起動

3) BLEなので「小分け送信」が必須

BLEはWi-Fiより帯域が小さく、1回に送れるサイズ（MTUの制約）も小さいです。

だから、数百KB〜数MBあるファームウェアをそのまま送るのではなく、

小さなチャンクに分割
順番に送信
ESP32側で順次Flashに追記

という形にします。

今回の実装では、iOS / Bluefy 寄りの安定性を見て 180バイト程度のチャンクを推奨にしています。

4) BLEのGATTって何をしてるの？（初心者向け）

BLEでは「サービス」「キャラクタリスティック」という箱を使って通信を整理します。

OTAでは典型的に以下の役割分担になります。

Control: 開始 / 終了 / 中止などの命令
Data: ファーム本体のバイナリ断片
Status: 進捗 / 成功 / エラー通知

今回の実装もほぼこの構成です。

5) ESP32側で何が起きてるの？（内部手順）

(A) OTA書き込み先を用意する

ESP32のFlashはパーティションに分かれています。 OTA対応では典型的に次のような構成を使います。

factory
ota_0
ota_1
nvs

更新時は、今動いている領域とは別のOTA領域に書きます。これにより、動作中のファームを直接壊さないので安全性が上がります。

(B) 受信しながらFlashへ書く

BLEで届いた断片を順に受けて、Update.write() のような処理でFlashへ書き込みます。

ここで設計上の論点になるのは、

中断時に再開可能にするか
再開なしで最初からやり直しにするか

です。

このプロジェクトでは、仕様をシンプルに保つため 途中再開は未対応 にしています。

(C) 完了後に整合性チェック

最後まで受け取ったら、少なくとも以下を確認します。

サイズ一致
ハッシュ / CRC一致（将来拡張含む）
書き込み完了判定

不一致なら新ファームは採用せず、旧ファームのまま動作します。

(D) ブート先切り替え → 再起動

検証OKなら、次回起動時に新ファーム領域を使うように切り替えます。再起動後、ブートローダがその情報を見て新ファームを起動します。

ここまでできて、初めて「OTAで更新できた」と言えます。

技術構成（ここからはポイント中心に淡々と）

この章では、実装の全詳細ではなく、GitHub/READMEに載せる内容と重複しすぎないように設計上の要点を絞って説明します。

全体構成

クライアント: iPad + Bluefy 上の WebApp（HTML/CSS/JavaScript）
デバイス: ESP32-S3 Super Mini（Arduino / PlatformIO）
主通信路: BLE（Provisioning / OTA / Debug すべて）
Wi-Fi: プロビジョニング確認用途のみ（OTAには不使用）

設計の主眼は、通信方式を絞って iOS 環境での実用性を上げることです。

なぜ「BLE一本化」寄りにしたか

iPad/Bluefy からの操作導線を単純化できる
OTA / ログ / 制御を同一接続上で扱える
Wi-Fi前提のローカルHTTP OTAに依存しない

結果として、現地でのセットアップ差分を減らせます。

BLE GATTの役割分割（要点）

3つの独立サービスに分割しています。

Provisioning Service: Wi-Fi資格情報の受け渡し
Debug Service: ログ通知 / コマンド受信
OTA Service: OTA制御 / バイナリ送信 / ステータス通知

ポイントは、OTAをDebugサービスに混ぜず、OTA専用サービスとして独立させたことです。運用時の責務分離とトラブル切り分けがしやすくなります。

OTAプロトコル設計（簡易）

OTAサービスは、以下の3キャラクタリスティック構成です。

OtaControl: START:<size>, END, ABORT
OtaData: バイナリチャンク送信
OtaStatus: READY, PROGRESS:x/y, SUCCESS, ERROR:*

要点:

シーケンス番号なしの順次書き込み（シンプル実装）
進捗通知を定期送信（100KBごと / 完了時）
失敗時は明示的なエラーコードを返す

再送制御や再開機構を入れていない分、仕様理解しやすさと実装容易性を優先しています。

OTAパーティション方針

OTA対応パーティションテーブル (partitions_ota_2m.csv) を使用
最大ファームウェアサイズは 2MB を前提
更新先は非実行中スロットを選択

この構成により、更新失敗時に旧ファームへ戻れる余地を確保しています。

WebApp構成（責務分離のポイント）

WebAppSide/ は機能ごとに分割しています。

ble-client.js: BLE接続・GATT操作の基盤
ota-client.js: OTA手順の制御
firmware-client.js: ファーム送信処理
ui.js: UI更新
constants.js: UUID / 定数定義

要点は、BLE I/O と OTA手順ロジックとUI更新を分離して、変更影響範囲を狭めている点です。

マイコン側構成（要点）

MiconSide/ は PlatformIO 前提で、以下が重要ファイルです。

platformio.ini: ボード / フレームワーク / パーティション設定
partitions_ota_2m.csv: OTA前提のFlash分割
src/main.cpp: BLEサービス / OTA / Debug / Provisioning の統合実装

プロジェクト初期段階では main.cpp 集約でも十分で、仕様が固まってから分割する方が追跡しやすい、という判断です。

制限事項（設計上の割り切り）

HTTP OTA未実装（OTAはBLEのみ）
途中再開未対応（中断時は再送）
同時OTA不可（1デバイスずつ）
チャンクサイズ最適化はiOS/Bluefy寄り（推奨180B）

このあたりは今後の拡張ポイントですが、現時点では「iPadから実際に書ける」を優先しています。

技術構成まとめ（短く）

今回の構成は、派手なことをしているというより、iPad/iOSの制約下で現実的に動く導線を丁寧に組んだ、というタイプの実装です。

通信方式をBLEに寄せる
GATTの責務を分ける
OTA手順を最小構成で安定化する
WebApp / マイコン側の責務を分離する

これで、少なくとも「iPadからマイコンへ書き込みたいんだ！！！」に対して、ちゃんと動く答えを作れました。

参考・補足（リポジトリ側に載せる内容）

詳細はGitHub側で以下を参照する想定です。

CreatePlan.md（実装詳細設計）
SpecifcationDoc.md（システム仕様）
MiconSide/README.md（マイコン側手順）
WebAppSide/README.md（WebApp側手順）

この記事では背景と設計意図を厚めに書き、実装の完全仕様はリポジトリへ寄せる、という役割分担にしています。

おわりに

iPadをメイン端末にしたい人って、たぶん「少数派」ではあるんですが、一定数いると思っています。

そしてその人たちが毎回ぶつかるのが、最後の「書き込み」です。

今回の構成はESP32系前提ではあるものの、

BLEで制御する
OTAロジックを先に載せる
Webアプリ化して端末依存を減らす

という考え方は、他の構成にも展開しやすいです。

同じことで詰まっている人の、突破口になればうれしいです。

BLE Compiler 〜iPadからマイコンに書き込みたい！〜

iPadからマイコンに書き込む！

推しアイデア

作った背景

推し技術

プロジェクト詳細

iPadからマイコンに書き込みたいんだ！！！

概要

デモ動画

使い方

ざっくり利用フロー

WebApp側でできること

使うときの注意点（実運用で大事）

序盤の背景的説明（なぜ iPad だけで書き込みたいのか）

1. まず単純に、iPad + PCの2台持ちが重い

2. iPadは「PCっぽいこと」がかなりできる

3. 逆にPCは、手描き・メモ・図解が弱い

4. でも最後に残るのが「書き込み」

5. 現地開発だと、さらに現実的につらい

メイン技術: OTA（ESP32系）を使う

そもそも書き込みとは？

OTAって何？

前提: ESP32とは？

なぜWi-Fi OTAじゃなくてBLE OTA？

BLE OTAを初心者向けに噛み砕く（ここは丁寧に）

1) 登場人物

2) データの流れ（超ざっくり）