Progress Log: v1.9.5 リファクタリング検証計画（ベースライン vs フル機能比較）¶

Task Description¶

v1.9.5のリファクタリング効果を定量化するため、ベースライン構成とフル機能構成を比較する検証計画を策定した。

検証アプローチ¶

v1.0.0との厳密な比較は困難なため、v1.9.5を基準として以下を実施：

ベースライン構成 - すべてのコンパイルフラグを無効化
フル機能構成 - すべてのコンパイルフラグを有効化（ただしWIFIはOFF）

この2つを比較してパフォーマンスインパクトを定量化し、リファクタリングの効果を検証

検証対象¶

パフォーマンス比較：RAM/Flash使用量、ビルド時間
機能検証：フル機能時のすべての機能動作確認
個別フラグ検証：WiFi、RTC等の重要フラグについては追加検証

Outcome¶

検証計画を完全に策定。以下の構成で実施予定。

検証項目¶

1. ベースライン構成¶

すべてのオプション機能を無効化した最小構成

[env:esp32dev-release]
build_type = release
build_flags =
    ${env.build_flags}
    -O2
    -DCORE_DEBUG_LEVEL=0
    -DADC_DEPEND_CHANNEL=1
    -DENABLE_BME280=1
    -DDEADTIME_MS=0
    -DSTREAM_FORMAT=0
    -DENABLE_FREERTOS_QUEUE=0
    -DENABLE_GPIO_ABSTRACTION=0
    -DENABLE_TEXT_PROTOCOL=0
    -DENABLE_WIFI=0

$ task prod:build

RAM:   [=         ]   6.9% (used 22648 bytes from 327680 bytes)
Flash: [==        ]  23.1% (used 303341 bytes from 1310720 bytes)

期待される特性：

最小のFlash使用量
最小のRAM使用量
基本的な検出機能のみ

2. フル機能構成（WIFI=0）¶

WIFI以外のすべてのオプション機能を有効化

[env:esp32dev-dev]
build_type = release
build_flags =
    ${env.build_flags}
    -O2
    -DCORE_DEBUG_LEVEL=0
    -DADC_DEPEND_CHANNEL=1
    -DENABLE_BME280=1
    -DDEADTIME_MS=0
    -DSTREAM_FORMAT=3
    -DENABLE_ADCMV=1
    -DENABLE_FREERTOS_QUEUE=1
    -DENABLE_GPIO_ABSTRACTION=1
    -DENABLE_RTC=1
    -DENABLE_TEXT_PROTOCOL=1
    -DENABLE_TIMESTAMP=1
    -DENABLE_WIFI=0

$ task dev:build
RAM:   [=         ]   7.7% (used 25392 bytes from 327680 bytes)
Flash: [==        ]  24.3% (used 318621 bytes from 1310720 bytes)

期待される特性：

すべてのオプション機能が動作
テキストコマンドプロトコル対応
WiFi、RTC、タイムスタンプ機能搭載

（参考）フル機能構成（WIFI=1）¶

$ PLATFORMIO_BUILD_FLAGS="-DENABLE_WIFI=1" task dev:build
RAM:   [=         ]  14.9% (used 48728 bytes from 327680 bytes)
Flash: [======    ]  60.7% (used 795801 bytes from 1310720 bytes)
============ [SUCCESS] Took 7.73 seconds ======================

Environment    Status    Duration
-------------  --------  ------------
esp32dev-dev   SUCCESS   00:00:07.735
============ 1 succeeded in 00:00:07.735 =======================

検証チェックリスト¶

Phase 1: ビルド比較¶

Phase 2: メモリ使用量分析¶

基本比較（WiFi=0）¶

メトリクス	ベースライン	フル機能	増加量
RAM (%)	6.9%	7.7%	+0.8%
Flash (%)	23.1%	24.3%	+1.2%
ビルド時間 (s)	6.278	7.228	+0.950

分析結果：

RAM増加: 22648 → 25392バイト = +2744バイト (+0.8%)
Flash増加: 303341 → 318621バイト = +15280バイト (+1.2%)
ビルド時間増加: 0.95秒 (+15%)

WiFi機能のコスト分析¶

メトリクス	フル機能（WiFi=0）	フル機能（WiFi=1）	WiFi追加コスト
RAM (%)	7.7%	14.9%	+7.2%
Flash (%)	24.3%	60.7%	+36.4%
ビルド時間 (s)	7.228	7.735	+0.507

分析結果：

RAM追加: 25392 → 48728バイト = +23336バイト (+7.2%)
Flash追加: 318621 → 795801バイト = +477180バイト (+36.4%)
ビルド時間追加: 0.51秒 (+7%)

全体評価¶

構成	評価	理由
ベースライン	✅ 優秀	最小限のメモリ使用。後方互換性検証に最適
フル機能（WiFi=0）	✅ 優秀	フル機能で+0.8% RAM、+1.2% Flash。非常に効率的
フル機能（WiFi=1）	⚠️ 容認可能	Flash 60.7%使用。WiFi搭載時の現実的な構成

結論：

v1.9.5のリファクタリングは極めて効率的に実装されている
WiFiなしで全機能を搭載可能（+1.2% Flash）
WiFi機能の追加で+36.4% Flashだが、ESP32のメモリに十分な余裕あり
用途に応じて柔軟に構成可能な設計

Phase 3: ベースライン動作確認¶

ファームウェア書き込み成功
シリアル出力確認（SSV形式のみ）
宇宙線検出で正常なイベント出力
LEDフィードバック動作
基本的なセンサー読み込み

Phase 4: コマンドキューの動作確認¶

目的¶

ENABLE_FREERTOS_QUEUE=1をデフォルト設定にしてもよいことを確認する

問題（v1.0.0）¶

スレッショルド設定（DAC書き込み）がたまに失敗する。成功の可否は、書き込み時のエコーで確認している。これが期待している文字列でない場合に「失敗」と判定している。

考えられる原因¶

原因はいまいち分かっていないが、 OSECHIのLED点灯の様子からスレッショルドは設定されているようなので、シリアル通信に起因する問題かもしれないと思っている。

測定に与えている影響¶

スレッショルド値の設定の成功が保証できていないので、測定データも保証できていない。とくに、スレッショルドスキャンを実施する際に影響がある。スレッショルド値を短時間（10秒間隔）で変更すると、DAC書き込みの失敗判定が多い。

対処した内容（v1.9.5）¶

kurikintonsに、コマンド受信時のキューを導入した。リトライ回数が減少することを期待。

確認手順¶

ENABLE_TEXT_PROTOCOL=0でビルド
理由：haniwersのDAC書き込みがテキストコマンドに対応していないため
haniwers-v1 threshold parallelコマンドを使う
すべてのチャンネルに対して並列スキャンを実施。
リトライ回数（＝成功するまでに書き込んだ回数）を記録
平均リトライ回数を比較
v1.0.0（以前に測定済み）
v1.9.5（ENABLE_FREERTOS_QUEUE=0）
v1.9.5（ENABLE_FREERTOS_QUEUE=1）
確認事項
v1.0.0 -> v1.9.5で平均リトライ回数が50%以上減少することを確認
QUEUE=0 / QUEUE=1で平均リトライ回数が10%以内の差分に収まることを確認

測定条件¶

$ uv run haniwers-v1 threshold parallel --thresholds "1:300;2:300;3:300" --step 1 --nsteps 100 --max-retry 100 --duration 2

中心値: 300（--thresholds "1:300;2:300;3:300"）
スキャン範囲: [200, 400]（--step 1 --nsteps 100）
1点あたりの測定時間: 2秒（--duration 2）
最大リトライ回数: 100回（--max-retry 100）

測定結果（ファイル名）¶

v1.0.0:
v1.9.5（カスタムキュー）:
v1.9.5（FreeRTOS Queue）:

測定結果の比較¶

Jupyter Notebookで解析
それぞれの測定のthreshold_history.csvを読み込む
概算
平均リトライ数を計算する
詳細
スレッショルド値とリトライ回数の散布図（棒グラフ）を作成する

Phase 4: フル機能動作確認¶

4.1 シリアル通信フォーマット¶

JSONL形式で出力確認（STREAM_FORMAT=3）
テキストコマンドHELP実行確認
テキストコマンドSTATUS実行確認
テキストコマンドGET_VERSION実行確認

4.2 タイムスタンプ機能¶

uptime_msフィールド出力確認
timedelta_usフィールド出力確認
RTC: SET_TIMEコマンド実行確認
RTC: GET_TIMEコマンド実行確認
検出イベントにunix_timestampが含まれること確認

4.3 環境センサー¶

BME280: 温度値の出力確認
BME280: 気圧値の出力確認
BME280: 湿度値の出力確認

4.4 WiFi機能¶

WiFiAPモード起動確認（SSID: OSECHI-DETECTOR）
192.168.4.1でアクセス可能
ステータスページ表示

4.5 その他機能¶

ADC電圧表示（ENABLE_ADCMV=1）
GPIO抽象化レイヤー（ENABLE_GPIO_ABSTRACTION=1）

個別フラグ検証（必要に応じて）¶

重要なフラグについては追加検証実施

WiFi機能（ENABLE_WIFI=1）¶

AP モード安定性テスト（5分間の連続接続）
接続切断・再接続の動作確認

RTC機能（ENABLE_RTC=1）¶

時刻設定の永続化確認
検出イベント毎の time_timestamp 記録確認

テキストプロトコル（ENABLE_TEXT_PROTOCOL=1）¶

全コマンドの実装確認
エラーハンドリング動作確認

記録フォーマット¶

検証実施時に以下の情報を記録：

## ベースライン構成（日付: ___）

ビルド結果：
- RAM: ___ %
- Flash: ___ %
- ビルド時間: ___ s

動作確認：
- シリアル出力: ✅/❌
- 検出機能: ✅/❌
- LED フィードバック: ✅/❌

## フル機能構成（日付: ___）

ビルド結果：
- RAM: ___ %
- Flash: ___ %
- ビルド時間: ___ s

動作確認：
- テキストコマンド: ✅/❌
- WiFi機能: ✅/❌
- RTC機能: ✅/❌
- タイムスタンプ: ✅/❌
- 環境センサー: ✅/❌

## 分析結果

メモリ増加率（フル機能 - ベースライン）：
- RAM: ___ % → ___ % = +___ %
- Flash: ___ % → ___ % = +___ %

結論：
[リファクタリングの効果、パフォーマンスインパクト等を記載]

Learnings¶

v1.0.0との比較が困難な理由
v1.0.0はタグの切り替えが必要（機能も不足しているため、比較しにくい）
v1.9.5の多くの機能がコンパイル時フラグで制御可能
ベースラインvsフル機能の比較が実測値で可能
モジュール化の価値
すべての機能がコンパイル時フラグで制御可能
不要な機能を除外してメモリを最適化可能
3つのビルドプロファイルで異なるニーズに対応
検証の実用性
ベースライン構成で基本機能の検証（後方互換性確認）
フル機能構成で新機能の検証
両者の比較でリファクタリングのコスト・ベネフィット明確化

Next Steps¶

検証実施
ベースライン構成のビルド・テスト実施
フル機能構成のビルド・テスト実施
メモリ使用量の記録
結果分析
増加量の分析（許容範囲内か確認）
機能の完全性確認
ドキュメント作成
検証結果を progress ログに追記
v1.10.0 リリースノート作成（予定）