memory-budgeting

メモリ予算の管理

メモリを名目上のボード仕様ではなく、測定可能な予算として扱います。実装は組み込み C/C++ です。ビルドログや実行時ログの解析が有用であれば、スクリプトを確定的なツールとして使用できます。

受付時に確認する情報

正確なボード／モジュール、フラッシュ／RAM／EEPROM／PSRAM、ブートローダーとパーティションのレイアウト、フレームワーク、コンパイラフラグ、ライブラリ、静的バッファー、タスクスタック、ファイルシステム／OTA の要件、プロトコルのピークサイズ、利用可能な測定出力を記録します。

手順

1. 静的データ、コード／フラッシュ、ヒープ、タスクスタック、割り込み状態、ファイルシステム、ブートローダー、OTA／更新用スロットを分けます。
2. カテゴリーごとに数値で予算を定め、最低限必要な余裕も設定します。ファミリー全体の数値をそのままプロジェクトの仕様として記載せず、ボードの資料を参照します。
3. コンパイラのサイズ出力を取得し、変更内容を機能または依存関係に関連付けます。
4. フレームワークで取得できる場合は、代表的な負荷をかけて、実行時の空きヒープ、最大ブロックサイズ、スタックのハイウォーターマーク、リセット／割り当ての失敗を測定します。
5. AVR では、適切な場合は F() を使ってリテラルをフラッシュに保持し、上限のあるバッファーと固定サイズのストレージを優先し、上限のない動的な String の使用を避けます。ESP32／RP2040 でもバッファーに上限を設け、ヒープ、スタック、フラッシュ、ファイルシステムを区別します。
6. メモリに影響する変更のたびにストレステストを再実行し、トレードオフを記録します。

正当化を防ぐための指針

近道	対応
「データシートによると 520 KB あるので、メモリは問題ありません。」	使用可能なヒープ、スタック、予約領域、無線／RTOS の使用量を分けて考えます。
「コンパイルできました。」	サイズ出力を確認し、実行時のメモリ割り当て経路をテストします。
「バッファーを大きくしましょう。」	プロトコルに上限を設け、必要な最大サイズを立証します。
「どこでも String を使いましょう。」	断片化と存続期間を確認し、必要に応じて上限のある代替手段を使います。
「OTA に必要なのはアプリケーションイメージだけです。」	両方の更新スロット、ブートローダー、メタデータ、ロールバック用イメージを予算に含めます。

検証

• ビルドサイズの出力と実行時メモリの根拠に、正確なターゲット／バージョンを明記します。
• 各予算に余裕を設け、失敗時の対応を定めます。
• 該当する場合、ストレステストでメッセージ、センサー、ロギング、無線、タスクのピーク負荷を網羅します。
• 最適化によって上限、安全チェック、復旧動作を取り除かないようにします。

共通の出力要件

共通の Arduino スキル契約を使用します。前提条件、必要なツールとバージョン、実装手順、検証段階ごとのテスト／根拠、既知の制限事項、復旧／セキュリティに関する注意事項を明記します。