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