MicroPython 的優勢

定位的場景

MicroPython 在設計上最初就是為了嵌入式微處理器運行，例如在 nRF51822 (256kB flash + 16kB RAM) 的芯片上也可以運行起來，也有人腎得慌在 STM32F103 上跑起來了，從代碼上來看 Python 函數棧的官方默認是 16K RAM，也就意味着它可以在許多微芯片上提供一個最小的 Python 代碼交互環境，但這並不包含它們的拓展功能，畢竟編譯更多的功能代碼意味着需要更多的 Flash 或 外部存儲。

高度與寬度

根據定位的場景我們可以看到 MicroPython 在硬件的深度可以去到超低功耗芯片開發領域，而采用 Python 語言的開發方式決定了它的軟件寬度可以站在全世界熱門的 Python 領域中進行借鑒和參考，這帶來了許多改變，如改變以往的硬件測試流程和開發流程，改變一貫認為的硬件程序開發困難的刻板印象，這個現象之后會詳細闡述。

同類開發環境一覽

我（🐱）以正在開發的 BPI:BIT(ESP32) 為例，對應的同類解釋器或 SDK 源碼相關開發環境有：

• 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 ，而軟件領域里，則有大量的邏輯示例代碼供硬件開發調用和測試,對於硬件開發人員，將會獲得更多控制硬件的方法，對於軟件人員也會更容易的配合硬件人員開發硬件和調試硬件。

結語

如果你有其他更多的見解，歡迎一同探討和分享。

• 撰寫時間：2019年9月2日
• 作者名稱：junhuanchen
• 聯系方式：
• WeChat & Github： 作者名稱
• QQ & E-mail： 作者名稱@qq.com