① Openwrt如何輸入命令行
你先下載一個Putty,然後利用這個軟體SSH到路由器，就可以在命令行裡面輸入這些命令了。
② micropython的優缺點
以下是這門語言的優缺點：
優點：是官方手下的，所以很好用。
缺點：1.模式，畫質老舊，類似於ENIAC計算機顯示屏幕。
2.輸入代碼後會直接運行。
3.沒有保存等其他功能，功能單一。
Python是一門通俗易懂的編程語言，但是最好不要使用micropython，因為它比較老舊，所以我推薦你使用官方渠道：python.org去下載。
MicroPython在設計上最初就是為了嵌入式微處理器運行，例如在nRF51822(256kBflash+16kBRAM)的晶元上也可以運行起來，也有人腎得慌在STM32F103上跑起來了，從代碼上來看Python函數棧的官方默認是16KRAM，也就意味著它可以在許多微晶元上提供一個最小的Python代碼交互環境，但這並不包含它們的拓展功能，畢竟編譯更多的功能代碼意味著需要更多的Flash或外部存儲。
高度與寬度
根據定位的場景我們可以看到MicroPython在硬體的深度可以去到超低功耗晶元開發領域，而採用Python語言的開發方式決定了它的軟體寬度可以站在全世界熱門的Python領域中進行借鑒和參考，這帶來了許多改變，如改變以往的硬體測試流程和開發流程，改變一貫認為的硬體程序開發困難的刻板印象，這個現象之後會詳細闡述。
Arino(C++)
基於C++代碼設計
擁有和C兼容的優勢，可以無縫接入ESP-IDF。
大量遺留的代碼庫可以直接整合使用。
近年來的提供的外設硬體庫質量大幅度下降，導致硬體開發後的穩定性欠缺。
Javascript
常見於Rufflite、JerryScript等。
新生事物，同MicroPython相似的結構
支持JS非同步驅動事件模型，要求晶元必須擁有系統（RTOS）。
在硬體上使用瀏覽器形式的開發方式
硬體驅動相關支持庫較弱，基於此深耕硬體介面的開發者不多。
相關的開發資料和代碼還不夠穩定。
lua
相比MicroPython和JerryScript它的可移植性要來得更為簡單一些。
如倉庫：/whitecatboard/Lua-RTOS-ESP32
但由於lua是小眾語言，地位和bat、bash差不多。
所以不是在開發應用領域里不是很流行，但作為自動化腳本工具還是很棒的。
開發資料相關周邊的基本沒有，會lua的大多都是孤芳自賞，比如我（大概）。
ESPEasy
大概算是一種開發環境，類似於路由器系統（openwrt）
除了好玩，就沒有什麼用了。
像這樣的固件還有很多很多，在這里就不一一舉例了。
esp-idf
硬體開發晶元原廠一般都會提供的SDK，esp32提供的多為esp-idf、esp-adf、esp-mdf諸如此類，對應的stm32的hal或CC25XXstack等等原生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的執行函數操作額外增加了5us左右，這是我在寫軟串口的時候發現的，但也帶來了解釋器介面（其他動態語言也是如此），通過動態調整執行介面的參數，加速了硬體程序的驗證與開發。
在面對硬體程序的主控方面的開發，經常面對大量的硬體API通信調試，就像調試網路服務里的HTTPAPI，對硬體里的UART、I2C、SPI、RS485、CAN等等從機設備的控制，使用MicroPython進行開發驗證，要比純粹使用C、Arino來的更為迅速，畢竟它們編譯一次2分鍾，運行10秒，而MicroPython燒錄2分鍾，之後每隔5秒運行反復運行，這也得益於MicroPython的硬體外設驅動的開發相當可靠和穩定（其實是ESP-IDF穩定可靠的原因XD）。
所以別人花一天調試的硬體介面，我幾個小時就可以調試得七七八八了，尤其是多機協議的反復測試介面，例如：Modbusreadaddr或是I2C.scan這類介面。當然，上述的這種開發哪怕是封裝成AT指令的介面方式也可以做到，但在Python解釋器的基礎上可以編寫更多復雜的後續邏輯操作，而非AT固件的指定介面形式調試。
綜上所述，MicroPython的硬體開發地位處於硬體開發的初期驗證和原始開發階段，在後期大多都會轉回C，而軟體領域里，則有大量的邏輯示例代碼供硬體開發調用和測試,對於硬體開發人員，將會獲得更多控制硬體的方法，對於軟體人員也會更容易的配合硬體人員開發硬體和調試硬體。
結語
③ openwrt能跑python或ruby么
Python 是可以跑的，通過openwrt的軟體工具可以安裝的。
但是因為openwrt對存儲的預設空間要求很低，安裝 python 會減少openwrt的「磁碟」空間。