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

于是讓我思索究竟這個腳本在嵌入式系統(tǒng)上。特別是工業(yè)系統(tǒng)上，能有多大的作為？究竟能走多遠(yuǎn)。

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

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

腳本語言特別像發(fā)展時間比較長的，如Python。其配合庫眾多龐大，已經(jīng)涉及到各個行業(yè)領(lǐng)域。

能夠輕松的用Python做一個Windows、Linux下的應(yīng)用程序。也能夠用來寫瀏覽器的Web界面，也能夠?qū)憇erver的CGI甚至server本身。這都難不倒Python。

相似的還有Ruby，Perl。PHP，在站點(diǎn)后臺專業(yè)領(lǐng)域，都有獨(dú)到的地方。

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

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

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

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

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

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

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

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

要是爛在了現(xiàn)場。更加是悔不當(dāng)初。

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

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

腳本是這樣的小系統(tǒng)的不二之選。

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

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

時間緊了。就多做些模塊間的測試?？刂埔幌聹y試的粒度。時間寬松了，用腳本能夠測得再細(xì)些。

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

可能有些朋友操心速度問題，Lua 有 LuaJIT，Python的PyPy，處理器的不斷進(jìn)步。我認(rèn)為這都不是問題，問題是你邁出了這步?jīng)]有？腳本和C，就像當(dāng)年的 C與ASM。

全然替代不是目的，合理的在嵌入式中優(yōu)化現(xiàn)有的實(shí)現(xiàn)框架。才是我們須要的。

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