腳本曾經限于行業應用，一直給我低效、低能的印象，但凡事總有個例外，我工作中用到了腳本語言。

于是讓我思索究竟這個腳本在嵌入式系統上。特別是工業系統上，能有多大的作為？究竟能走多遠。

腳本語言不是什么新奇的東西，自打有了編譯型的語言自然就有了解釋型的語言。限于計算機硬件，解釋型的語言初期沒有編譯型的語言強手。后來計算機硬件越來越強了，解釋型語言，這樣的易于學習，編程簡單的語言漸漸流行，代表的就是Basic。

再后來，橫空出世了Java。這樣的介于解釋型和編譯型語言之間的語言。代表了一個時期的技術走向。90年代前后誕生了很多有影響力的語言，如站點類的PHP。Ruby等。全能高效的Python。小巧靈動，在游戲界大顯身手的Lua。Linux下的 Bash 腳本……太多了。

腳本語言特別像發展時間比較長的，如Python。其配合庫眾多龐大，已經涉及到各個行業領域。

能夠輕松的用Python做一個Windows、Linux下的應用程序。也能夠用來寫瀏覽器的Web界面，也能夠寫server的CGI甚至server本身。這都難不倒Python。

相似的還有Ruby，Perl。PHP，在站點后臺專業領域，都有獨到的地方。

然而在嵌入式里。這些腳本語言好像都失去了蹤影。特別是一些可靠性高，實時性好的領域，對腳本語言往往敬而遠之。廣大的嵌入式從業者。特別是單片機編程程序猿們，對這個東西還是比較抗拒的。

原因非常easy，原生的Python集成到單片機上得接近900KB的代碼空間，除此之外，還須要付出大量的內存開銷。嵌入式系統，往往內存管理是簡陋的。甚至是沒有。這對腳本語言這樣的內存大戶來說。實在難以接受。

有非常多嵌入式的有志之士，干了非常多有意思的嘗試，比方說將Lua弄到單片機上。用Lua開發單片機程序。

不失為一個有意思的創新。如Python的python-on-a-chip。micropython，這些項目都是非常有價值的探索。腳本和C語言比。究竟能為我們帶來什么？腳本的出現并非偶然。程序實際上就是一套施加在一些數據上的一些算法。計算完畢后，輸出數據而已。沒有輸出數據的程序是無意義的。 腳本。如Python中的表、元表、字典等數據結構，非常easy的幾十行代碼能構建出用C語言成百上千行才干寫出來的復雜數據結構。簡單的迭代方式遍歷復雜數據結構的辦法，也是C語言無法簡單的模仿。

就連用C++的迭代器，相比也是羅嗦麻煩。靜止的引用回收機制。使得腳本基本不考慮內存的泄漏問題。這些特點，決定了腳本適合復雜的數據處理。

天生的不須要編譯的特點，也使得在執行時刻也能夠方便的改變代碼。

嵌入式有幾類應用，是非常適合腳本處理的：

1.復雜的數據結構實現。用C/C++寫，真心的不好，還是用腳本去實現吧。比方說,uC/OS和FreeRTOS這樣的跑一個諸如sqlite的數據庫，數據庫的查詢，插入等等。選擇腳本是明智的。往往Linux太大，團隊實施起來，須要較多的精力，并且，網上東找西找的Linux下的代碼，穩定性可靠性難以保證。短時間搞出產品來實在是太難了。

要是爛在了現場。更加是悔不當初。

這時，小巧的腳本，如Lua就是個非常理想的選擇。

2.靈活性的選擇，系統規模沒有上到Linux這樣的水平。但在系統里又想保留靈活性。希望能像載入可執行文件一樣，迅速的讓系統獲得新的特性。

腳本是這樣的小系統的不二之選。

3.測試，一般做嵌入式的公司，時間都非常的緊張，沒時間做非常仔細的白盒測試。

在進度和質量的雙重壓力下，白盒測試往往成了走過場，大家都心照不宣。那就根本不走。導致后來的集成測試中問題扎堆。事實上利用腳本語言能夠非常輕松的構建測試用例，測試代碼，進行模塊間的測試。和主要的單元測試。

時間緊了。就多做些模塊間的測試。控制一下測試的粒度。時間寬松了，用腳本能夠測得再細些。

特別對于嵌入式中須要的復雜數據，可能須要其它系統。諸如PC平臺的軟件配合。都能夠在腳本里輕松的模擬出來。

可能有些朋友操心速度問題，Lua 有 LuaJIT，Python的PyPy，處理器的不斷進步。我認為這都不是問題，問題是你邁出了這步沒有？腳本和C，就像當年的 C與ASM。

全然替代不是目的，合理的在嵌入式中優化現有的實現框架。才是我們須要的。

我堅信，腳本在嵌入式中一定會大放異彩。