MicroPython 在設計上最初就是為了嵌入式微處理器執行，例如在 nRF51822 (256kB flash + 16kB RAM) 的晶片上也可以執行起來，也有人腎得慌在 STM32F103 上跑起來了，從程式碼上來看 Python 函式棧的官方預設是 16K RAM，也就意味著它可以在許多微晶片上提供一個最小的 Python 程式碼互動環境，但這並不包含它們的拓展功能，畢竟編譯更多的功能程式碼意味著需要更多的 Flash 或 外部儲存。
高度與寬度
根據定位的場景我們可以看到 MicroPython 在硬體的深度可以去到超低功耗晶片開發領域，而採用 Python 語言的開發方式決定了它的軟體寬度可以站在全世界熱門的 Python 領域中進行借鑑和參考，這帶來了許多改變，如改變以往的硬體測試流程和開發流程，改變一貫認為的硬體程式開發困難的刻板印象，這個現象之後會詳細闡述。
Arduino(C++)
基於 C++ 程式碼設計
擁有和 C 相容的優勢，可以無縫接入 ESP-IDF 。
大量遺留的程式碼庫可以直接整合使用。
近年來的提供的外設硬體庫質量大幅度下降，導致硬體開發後的穩定性欠缺。
Javascript
常見於 Ruff lite 、 JerryScript 等。
新生事物，同 MicroPython 相似的結構
支援 JS 非同步驅動事件模型，要求晶片必須擁有系統（RTOS）。
在硬體上使用瀏覽器形式的開發方式
硬體驅動相關支援庫較弱，基於此深耕硬體介面的開發者不多。
相關的開發資料和程式碼還不夠穩定。
lua
相比 MicroPython 和 JerryScript 它的可移植性要來得更為簡單一些。
如倉庫：https://github.com/whitecatboard/Lua-RTOS-ESP32
但由於 lua 是小眾語言，地位和 bat 、 bash 差不多。
所以不是在開發應用領域裡不是很流行，但作為自動化指令碼工具還是很棒的。
開發資料相關周邊的基本沒有，會 lua 的大多都是孤芳自賞，比如我（大概）。
ESPEasy
大概算是一種開發環境，類似於路由器系統（openwrt）
除了好玩，就沒有什麼用了。
像這樣的韌體還有很多很多，在這裡就不一一舉例了。
esp-idf
硬體開發晶片原廠一般都會提供的 SDK ，esp32 提供的多為 esp-idf 、esp-adf 、 esp-mdf 諸如此類，對應的 stm32 的 hal 或 CC25XX stack 等等原生 C 程式碼 SDK 。
上述開發環境均基於此繼續開發得來的產物。
經過了上述的各類開發環境的初步認識，我們就來說說 MicroPython 對比後的優劣吧。
MicroPython 的優劣
我們不難看到，MicroPython 和 Python 一樣，發揮了膠水語言的優勢，最大化的相容和保持了各自的優勢，減少自己的劣勢。
在動態語言大戰中，MicroPython 保留了面向過程、物件、切面、函式的程式設計語法，豐富的開發方式帶來了程式碼的開發廣度，反觀 lua 從語法上砍掉了大量開發常用的語法糖，大幅度的裁剪程式碼量，在開發者開箱即用的角度來看， MicroPython 迎合了大多數開發者的拿來主義（我？）。
與 JavaScript 相比的 Python 在效能上沒有太多的優勢，唯一的優勢就是 Js 的程式設計思維並不適合長期浸染在面向過程領域裡的 C 語言硬體程式設計，例如串列埠收發這樣簡單的一件事情，在 Js 的非同步事件繫結模型下，需要設定一些回撥函式等待處理，而在 MicroPython 中，透過多執行緒可以實現 Js 的效果，但沒有多執行緒也可以透過 While 死迴圈輪詢或非阻塞狀態機來實現同樣的功能，而後者的死迴圈就是嵌入式 C 中的常見程式設計習慣了，但在 JS 的硬體程式設計中，某個函式若是發生了死迴圈，那真的是一種災難，所有的後臺執行緒都無法運行了，但死迴圈這樣的開發方式真的太爛了，建議硬體開發的時候多寫非同步驅動程式碼，或者是狀態機程式碼，以提高 IO 效能。
因此 MicroPython 在眾多動態語言中與 C 語言的相容性為最佳，在程式設計上也是如此，向下相容語言的同時又吸取了上層優秀程式碼的精髓，尤其是異常機制和動態型別。
此時相比 C 或 C++ 語言，MicroPython 犧牲了一些執行效能，平均每段 Python 程式碼回到 C 的執行函式操作額外增加了 5 us 左右，這是我在寫軟串列埠的時候發現的，但也帶來了直譯器介面（其他動態語言也是如此），透過動態調整執行介面的引數，加速了硬體程式的驗證與開發。
在面對硬體程式的主控方面的開發，經常面對大量的硬體 API 通訊除錯，就像除錯網路服務裡的 HTTP API ，對硬體裡的 UART 、I2C 、 SPI 、RS485、CAN 等等從機裝置的控制，使用 MicroPython 進行開發驗證，要比純粹使用 C 、Arduino 來的更為迅速，畢竟它們編譯一次 2 分鐘，執行 10 秒，而 MicroPython 燒錄 2 分鐘，之後每隔 5 秒執行反覆執行，這也得益於 MicroPython 的硬體外設驅動的開發相當可靠和穩定（其實是 ESP-IDF 穩定可靠的原因 XD ）。
所以別人花一天除錯的硬體介面，我幾個小時就可以除錯得七七八八了，尤其是多機協議的反覆測試介面，例如： Modbus readaddr 或是 I2C.scan 這類介面。當然，上述的這種開發哪怕是封裝成 AT 指令的介面方式也可以做到，但在 Python 直譯器的基礎上可以編寫更多複雜的後續邏輯操作，而非 AT韌體的指定介面形式除錯。
綜上所述， MicroPython 的硬體開發地位處於硬體開發的初期驗證和原始開發階段，在後期大多都會轉回 C ，而軟體領域裡，則有大量的邏輯示例程式碼供硬體開發呼叫和測試,對於硬體開發人員，將會獲得更多控制硬體的方法，對於軟體人員也會更容易的配合硬體人員開發硬體和除錯硬體。
結語
MicroPython 在設計上最初就是為了嵌入式微處理器執行，例如在 nRF51822 (256kB flash + 16kB RAM) 的晶片上也可以執行起來，也有人腎得慌在 STM32F103 上跑起來了，從程式碼上來看 Python 函式棧的官方預設是 16K RAM，也就意味著它可以在許多微晶片上提供一個最小的 Python 程式碼互動環境，但這並不包含它們的拓展功能，畢竟編譯更多的功能程式碼意味著需要更多的 Flash 或 外部儲存。
高度與寬度
根據定位的場景我們可以看到 MicroPython 在硬體的深度可以去到超低功耗晶片開發領域，而採用 Python 語言的開發方式決定了它的軟體寬度可以站在全世界熱門的 Python 領域中進行借鑑和參考，這帶來了許多改變，如改變以往的硬體測試流程和開發流程，改變一貫認為的硬體程式開發困難的刻板印象，這個現象之後會詳細闡述。
Arduino(C++)
基於 C++ 程式碼設計
擁有和 C 相容的優勢，可以無縫接入 ESP-IDF 。
大量遺留的程式碼庫可以直接整合使用。
近年來的提供的外設硬體庫質量大幅度下降，導致硬體開發後的穩定性欠缺。
Javascript
常見於 Ruff lite 、 JerryScript 等。
新生事物，同 MicroPython 相似的結構
支援 JS 非同步驅動事件模型，要求晶片必須擁有系統（RTOS）。
在硬體上使用瀏覽器形式的開發方式
硬體驅動相關支援庫較弱，基於此深耕硬體介面的開發者不多。
相關的開發資料和程式碼還不夠穩定。
lua
相比 MicroPython 和 JerryScript 它的可移植性要來得更為簡單一些。
如倉庫：https://github.com/whitecatboard/Lua-RTOS-ESP32
但由於 lua 是小眾語言，地位和 bat 、 bash 差不多。
所以不是在開發應用領域裡不是很流行，但作為自動化指令碼工具還是很棒的。
開發資料相關周邊的基本沒有，會 lua 的大多都是孤芳自賞，比如我（大概）。
ESPEasy
大概算是一種開發環境，類似於路由器系統（openwrt）
除了好玩，就沒有什麼用了。
像這樣的韌體還有很多很多，在這裡就不一一舉例了。
esp-idf
硬體開發晶片原廠一般都會提供的 SDK ，esp32 提供的多為 esp-idf 、esp-adf 、 esp-mdf 諸如此類，對應的 stm32 的 hal 或 CC25XX stack 等等原生 C 程式碼 SDK 。
上述開發環境均基於此繼續開發得來的產物。
經過了上述的各類開發環境的初步認識，我們就來說說 MicroPython 對比後的優劣吧。
MicroPython 的優劣
我們不難看到，MicroPython 和 Python 一樣，發揮了膠水語言的優勢，最大化的相容和保持了各自的優勢，減少自己的劣勢。
在動態語言大戰中，MicroPython 保留了面向過程、物件、切面、函式的程式設計語法，豐富的開發方式帶來了程式碼的開發廣度，反觀 lua 從語法上砍掉了大量開發常用的語法糖，大幅度的裁剪程式碼量，在開發者開箱即用的角度來看， MicroPython 迎合了大多數開發者的拿來主義（我？）。
與 JavaScript 相比的 Python 在效能上沒有太多的優勢，唯一的優勢就是 Js 的程式設計思維並不適合長期浸染在面向過程領域裡的 C 語言硬體程式設計，例如串列埠收發這樣簡單的一件事情，在 Js 的非同步事件繫結模型下，需要設定一些回撥函式等待處理，而在 MicroPython 中，透過多執行緒可以實現 Js 的效果，但沒有多執行緒也可以透過 While 死迴圈輪詢或非阻塞狀態機來實現同樣的功能，而後者的死迴圈就是嵌入式 C 中的常見程式設計習慣了，但在 JS 的硬體程式設計中，某個函式若是發生了死迴圈，那真的是一種災難，所有的後臺執行緒都無法運行了，但死迴圈這樣的開發方式真的太爛了，建議硬體開發的時候多寫非同步驅動程式碼，或者是狀態機程式碼，以提高 IO 效能。
因此 MicroPython 在眾多動態語言中與 C 語言的相容性為最佳，在程式設計上也是如此，向下相容語言的同時又吸取了上層優秀程式碼的精髓，尤其是異常機制和動態型別。
此時相比 C 或 C++ 語言，MicroPython 犧牲了一些執行效能，平均每段 Python 程式碼回到 C 的執行函式操作額外增加了 5 us 左右，這是我在寫軟串列埠的時候發現的，但也帶來了直譯器介面（其他動態語言也是如此），透過動態調整執行介面的引數，加速了硬體程式的驗證與開發。
在面對硬體程式的主控方面的開發，經常面對大量的硬體 API 通訊除錯，就像除錯網路服務裡的 HTTP API ，對硬體裡的 UART 、I2C 、 SPI 、RS485、CAN 等等從機裝置的控制，使用 MicroPython 進行開發驗證，要比純粹使用 C 、Arduino 來的更為迅速，畢竟它們編譯一次 2 分鐘，執行 10 秒，而 MicroPython 燒錄 2 分鐘，之後每隔 5 秒執行反覆執行，這也得益於 MicroPython 的硬體外設驅動的開發相當可靠和穩定（其實是 ESP-IDF 穩定可靠的原因 XD ）。
所以別人花一天除錯的硬體介面，我幾個小時就可以除錯得七七八八了，尤其是多機協議的反覆測試介面，例如： Modbus readaddr 或是 I2C.scan 這類介面。當然，上述的這種開發哪怕是封裝成 AT 指令的介面方式也可以做到，但在 Python 直譯器的基礎上可以編寫更多複雜的後續邏輯操作，而非 AT韌體的指定介面形式除錯。
綜上所述， MicroPython 的硬體開發地位處於硬體開發的初期驗證和原始開發階段，在後期大多都會轉回 C ，而軟體領域裡，則有大量的邏輯示例程式碼供硬體開發呼叫和測試,對於硬體開發人員，將會獲得更多控制硬體的方法，對於軟體人員也會更容易的配合硬體人員開發硬體和除錯硬體。
結語