作為支援遠端連接互聯網的物聯網設備，本地或遠端OTA升級也是腳本編程控制器的重要功能，因為不能保證繼電器完全沒有Bug，在利用bug，如果沒有OTA升級接口，很難讓客戶透過串口升級固件，控制器只能回廠升級，成本高，影響大。

另外，客戶可能有一些個人化功能無法透過中文程式設計實現，需要升級控制器韌體才能實現。

這兩種情況需要透過本地或遠端OTA功能來解決。

這幾天花了一點時間完成這個功能，現總結如下：
（1）ESP8266的FLASH可以儲存兩個韌體，名稱分別為user1.bin到user2.bin，兩個韌體的位址由位址0x0000處儲存的引導程式boot.bin決定，且儲存位址不同不同的閃光燈容量。
例如，ESP8266-01S Flash 容量為 1Mbyte，儲存位址分別為 0x01000 和 0x81000，ESP8266-07S FLASH 容量為 4Mbyte，儲存位址分別為 0x01000 和 0x101000。

(2)透過函數system_upgrade_userbin_check的回傳值取得目前程式執行的user1.bin或user2.bin，進行韌體升級，到另一個韌體儲存區寫入完整的韌體，例如如果目前執行的是儲存在user1 .bin的0x1000處，然後到地址0x81000(ESP8266-01S)或0x101000(EPS8266-07S)寫入韌體user2.bin，寫入完畢後，再透過SDKsystem_upgrade_flag_set(0x02)通知SDK設定完成系統參數，以便ESP8266啟動時引導到另一個韌體。

3）官方推薦的做法是透過http協定將韌體下載到雲端伺服器到記憶體中，我沒有使用這個方案，主要是出於兩個考慮，一是這個方案是否經過嚴格驗證，以及是否有充分考慮數據驗證以避免升級到磚塊，我對此表示懷疑。其次，這個程式要求控制器能夠連接到外部網絡，從伺服器下載固件，這並不容易做到。

我目前正在使用delphi開發一套韌體升級軟體，該軟體作為TCP客戶端直接連接到控制器，或連接到雲端伺服器的TCP網關然後傳輸到控制器，然後根據512 位元組用於將韌體推送到控制器的資料幀。

接下來可以將這套邏輯移植到伺服器上，客戶可以透過瀏覽器開啟網頁將韌體推送到控制器。

4）資料的完整性得到充分驗證，第一幀資料做crc32校驗，韌體寫入flash然後讀出與寫入的值進行比較，同時計算出該值crc32，與上位機發送的crc32值相比，讀寫資料相同，crc值也相同，則認為該幀資料寫入成功；
同時對每一幀資料的crc32值再進一步做crc32值，得到總的crc32值，與上位機發送的總crc32值進行比較，該值與呼叫函數system_upgrade_flag_set之前相同( 0x02) 以允許SDK 切換到啟動韌體。

(5)寫入兩個不同韌體區的韌體user1.bin、user2.bin不一樣，對於RTOS sdk開發，需要修改Makefile變數APP的值產生user1.bin、user2 .bin，分別是上位機根據控制器傳回目前運作的該儲存區域的韌體，選擇另一個儲存區域的韌體傳送給控制器。上位機根據控制器傳回的目前運作韌體的儲存區域選擇另一個儲存區域的韌體。

如果兩個儲存區域使用相同的韌體，ESP8266將無法正常啟動。