為什麼 ESP32 專案需要Arduino IDE 2.x 開發程式碼、Arduino IDE 1.8.x 上傳 SPIFFS？
- abintsai
- 2025年12月27日
- 讀畢需時 3 分鐘
這不是 workaround，而是目前 Arduino / ESP32 生態系中「最穩定、最可預期、最可維護」的工具鏈分工方式。
我們刻意把工作拆成兩個層級：
IDE 2.x：負責「程式碼開發」
IDE 1.8.x：負責「Flash 檔案系統（SPIFFS）寫入」
原因不是技術能力不足，而是 Arduino 官方對 IDE 架構的設計選擇已經改變。
1. 問題背景：SPIFFS 到底是什麼角色？
在 ESP32 專案中，我們通常會把：
HTML
JavaScript
CSS
圖示、資源檔
放進 Flash-based File System（SPIFFS / LittleFS），目的有三個：
前後端分離
UI 不必跟韌體一起重新編譯
Web UI 可獨立修改與版本控管
這在工程上是「正確做法」，而不是 Arduino 玩具等級用法。
2. Arduino IDE 1.x 與 2.x 的「架構本質差異」
Arduino IDE 1.8.x（Java-based）
單體 Java 應用
支援： <Arduino>/tools/*/*.jar
ESP32FS / ESP8266FS 正是靠這個機制實作
因此可以在 IDE 裡直接出現： Tools → ESP32 Sketch Data Upload
IDE 1.x 本身就同時承擔「開發環境 + Flash 工具」
Arduino IDE 2.x（Electron + arduino-cli）
完全重寫
核心理念改為：
IDE：寫程式、編輯、除錯
CLI：負責 build / upload / filesystem
不再掃描 tools/*.jar
官方立場是：
IDE 不應該承載任意 Flash 工具檔案系統操作應交由 CLI 或外部工具
👉 ESP32FS 這種外掛在 IDE 2.x 是「刻意不支援」
這不是「功能還沒補齊」，而是架構決策。
3. 為什麼「IDE 2.x 目前沒有 SPIFFS 上傳功能」不是 Bug
從工程角度來看：
IDE 2.x 已經不再是單一工具
它是 GUI + CLI 工具鏈的一部分
SPIFFS 上傳被視為：
Flash 操作
資源部署
非 IDE 核心職責
因此官方實際期望的流程是： IDE（寫程式）
CLI（build / upload / filesystem）
而不是：
IDE（包辦所有事情）
4. 為什麼我們沒有強行「在 IDE 2.x 解決 SPIFFS」
從工程實務來看，有幾個選項：
❌ 把 HTML / JS 寫進 C++ 字串
不可維護
每次 UI 修改都要重新編譯
無法版本化前端資源
不符合前後端分離原則
❌ 自行魔改 IDE 2.x
非官方路線
維護成本極高
不可預期
❌ 等官方補功能
官方已明確不走這條路
👉 全部都不是工程上可接受的解法
5. 為什麼「IDE 2.x + IDE 1.8.x」是合理的工程分工
我們實際做的是：
IDE 2.x（主力開發環境）
C++ / Arduino 程式碼
WebSocket / 控制邏輯
除錯、重構、版本管理
新架構、未來相容性
IDE 1.8.x（工具用途）
只負責一件事：SPIFFS 寫入
使用成熟、穩定的 ESP32FS 工具
不承擔開發角色
這本質上等同於： 「IDE 2.x 是編輯器，IDE 1.8.x 是 Flash 工具」
在嵌入式工程裡，這是非常正常的分工。
6. 這個流程是不是「暫時方案」？
短期
是目前 最穩定、最不踩雷 的做法
ESP32 社群大量採用
中期
可改用 arduino-cli + script（.bat / .sh）
完全不需要 IDE 1.8.x
適合自動化、CI/CD
長期
PlatformIO / ESP-IDF
但那是另一個開發層級
👉 現在這個選擇是「成熟工程專案的合理折衷」
7. 給使用者的簡化說法
Arduino IDE 2.x 與 1.x 在架構上已經完全不同。目前 SPIFFS（Flash 檔案系統）寫入工具僅在 1.x 提供穩定支援。 因此本專案採用： Arduino IDE 2.x：進行程式碼開發 Arduino IDE 1.8.x：進行 SPIFFS 資源上傳 這是基於官方工具鏈設計與穩定性考量，而非功能缺失或設定錯誤。
這不是因為 Arduino IDE 2.x 不夠好，而是它刻意不再做「Flash 工具」這件事。
我們只是依照工具鏈設計，把工作放在最合適的層級。
留言