|
我的嵌入式軟件開發(fā)之路 注：本文作者Michael Barr是Barr Group的技術(shù)長，專精于安全且可靠的即時運算嵌入式軟件架構(gòu)。Michael Barr曾任教于馬里蘭大學(xué)(University of Maryland)與約翰霍普金斯大學(xué)(Johns Hopkins University)；他還曾發(fā)表過三本書，以及超過65篇有關(guān)嵌入式系統(tǒng)設(shè)計專文。 隨著專為嵌入式系統(tǒng)編程人員所設(shè)計的《Embedded System Design》平面雜志劃下句點，我們更能看出未來的嵌入式軟件設(shè)計趨勢將更強調(diào)自動生成的代碼，而不再那么重視手寫編程了。 《Embedded System Design》最早在1988年以《Embedded Systems Programming》(ESP)的名稱出刊時，我才剛高中畢業(yè)。就像當(dāng)時大多數(shù)人一樣，我從來沒聽說過“嵌入式系統(tǒng)”一詞，也沒想太多深藏于另一種產(chǎn)品中的電腦形式。六年后，我取得了電子工程師的學(xué)位，也像1990年代中期的許多電子工程師一樣找到了一份嵌入式軟件設(shè)計工作(而非硬件設(shè)計)。不久，我在一位同事的辦公桌上看到了這本雜志，馬上就訂閱而且成了忠實讀者。 早期發(fā)展 1990年代初的情形就和現(xiàn)在一樣，學(xué)校中從來沒教過如何編寫出可靠的嵌入式軟件等專業(yè)知識。我在大學(xué)中唯一上過一門有關(guān)編程的課就是FORTRAN；后來才知道曾有過兩次實作課程學(xué)習(xí)匯編語言和C語言編程就是我在編寫嵌入式軟件方面僅有的正規(guī)教育。我大多經(jīng)由工作以及這份雜志的內(nèi)容學(xué)習(xí)，從這些篇章間第一次學(xué)會了如何編寫元件驅(qū)動程序、移植并使用操作系統(tǒng)、滿足即時的期限要求、建置有限狀態(tài)機(jī)等技巧，以及除C和匯編語言以外其它編程語言的優(yōu)缺點、遠(yuǎn)端除錯與JTAG等等。 在那個時代，擔(dān)任固件開發(fā)人員的我每天日常工作就是和英特爾hex文件、元件編程器、UV擦除器、僅kb容量的存儲器、8/16位處理器、電路模擬器與ROM監(jiān)視器等東西打交道。數(shù)據(jù)手冊有如就像書本一樣地多又厚，全部集中在一起的話就可以占滿整個書架。我在我的辦公桌上的HP-UX工作站編寫固件程序，后來必須到樓下實驗室去燒芯片，插入原型板中，再用ICE進(jìn)行測試與除錯。我還記得有一個特別棘手的專案，所用的編譯器和元件編程器距離唯一可用的目標(biāo)硬件8英哩遠(yuǎn)；而一個單色的紅光LED和一款滿是灰塵的示波器就堆在我的除錯工具箱附近。 我也和你一樣在1990年代中期就有互聯(lián)網(wǎng)可用，但除了特定的幾個FTP站點(還有人記得sunsite.unc.edu的FTP嗎？或Gopher？)以外，當(dāng)時的網(wǎng)絡(luò)并沒有太多對我的工作有用的信息，大多是一些閃爍的標(biāo)題文字以及The Hampster Dance(它直到現(xiàn)在都還存在呢！)；而亞馬遜(Amazon)也還只是當(dāng)時世界上最大的河流。那時也還沒有或。為了學(xué)習(xí)軟件和硬件的最佳實作途徑，我晚上還在進(jìn)修MSEE和CS課程，同時也常參與嵌入式系統(tǒng)大會(ESC)。 當(dāng)時，我記得也沒有任何有關(guān)嵌入式編程的書籍。我發(fā)現(xiàn)有關(guān)C語言的每一本書都是從寫"Hello, World"開始介紹起，但都十分抽象，最后也都未能提到如何解決周邊控制、中斷服務(wù)程序、連接匯編語言程序與操作系統(tǒng)(無論是否為RTOS)等問題。因此，多年后當(dāng)Jack Ganssle問我時，我不知哪來的勇氣認(rèn)為自己能夠針對嵌入式C編程領(lǐng)域所欠缺的部份撰寫一本書，后來也真的和O'Reilly簽約，開始著手寫書─ ─但我并沒在這本書一開始，而是到了最后才介紹用RS-232 移植編寫"Hello, World"。 到了1998年，在多次參與嵌入式系統(tǒng)大會后，有機(jī)會認(rèn)識了《Embedded System Design》的主編Lindsey Vereen。除了寫書以外，我還曾經(jīng)為《Embedded System Design》寫過幾篇文章，因而Lindsey已經(jīng)對于我解釋技術(shù)差異的能力留下深刻印象。不過，當(dāng)Lindsey告訴我他正在尋找一位技術(shù)編輯人選時，那時還不知道他屬意的人就是我。 未來的發(fā)展趨勢 從我第一次接觸到這本雜志，就與它結(jié)下了不解之緣；接著先是技術(shù)編輯到后來成為主編及其后的特約編輯，這一直是我在個人職業(yè)生活中最精彩的一部份。在這本《Embedded System Design》創(chuàng)辦后的前十年，我自己就是這本雜志及其中許多專欄作家和特約編輯的忠實讀者，到了第二個十年，我認(rèn)為自己的努力更有助于使其成為一個提供讀者交換關(guān)鍵設(shè)計理念、實作以及產(chǎn)業(yè)學(xué)習(xí)時更有價值的討論場域。而今，盡管我能了解為什么這本雜志光靠現(xiàn)有的平面廣告再也撐不下去了，但對于它結(jié)束發(fā)行還是感到傷心與不舍。 回想過去的這段時光，嵌入式軟件設(shè)計領(lǐng)域真的發(fā)生了許多改變。時至今日，匯編語言已經(jīng)很少被用到了，C和C++就更不用說了。EPROM及其元件編程器與UV擦除器已被閃存與開機(jī)載入程序所取代。總線寬度與存儲器容量也顯著地增加了。昂貴的電路模擬器與ROM監(jiān)示器已經(jīng)轉(zhuǎn)型為較便宜的JTAG除錯。ROM-DOS已被微軟的任何嵌入式Windows操作系統(tǒng)所取代。而開放來源的Linux由于發(fā)展得相當(dāng)不錯，不但限制RTOS產(chǎn)業(yè)的成長，同時也成為我們期望能更專精以便為簡歷加分的技術(shù)。 那么，未來將會發(fā)生什么呢？嵌入式編程人員在2020年、2030年或2040時的日常生活與體驗又會是什樣子的呢？在此，我提出將影響未來這些時間點的三大發(fā)展趨勢，特別是其中每一個趨勢已經(jīng)開始發(fā)生了。 趨勢一：32位CPU實現(xiàn)大量應(yīng)用 我的第一個預(yù)測是低成本、低功耗且高整合的微控制器將為32位帶來最高度的大量應(yīng)用領(lǐng)域──最佳例子就是當(dāng)今的ARM Cortex-M系列。8位和16位CPU將隨元件過時逐漸減少應(yīng)用量。雖然你可能已在為32位處理器編程，而發(fā)現(xiàn)目前仍是8位與16位處理器推動整體CPU芯片銷售量的現(xiàn)況，但其實我指的是像基于8051及其它30-40年前那種指令集架構(gòu)的微處理器。這些舊式架構(gòu)在今日仍十分普遍，只是因為特定嵌入式處理所需的低利潤、大量應(yīng)用必須竭盡所能地節(jié)省BOM成本的每一分錢。 8位和16位架構(gòu)的限制對于必須使用它們的嵌入式系統(tǒng)開發(fā)人員帶來許多方面的挑戰(zhàn)。首先，由于有限的位址總線寬度導(dǎo)致存儲器容量受限、還有存儲器庫、分割技術(shù)以及其他設(shè)法超越那些限制的變通辦法。其次，這些CPU在決策方面的效果優(yōu)于其數(shù)學(xué)運算──這是因為缺乏有效處理較大整數(shù)的能力，而且也沒有浮點運算性能。最后，這些舊式的處理器也缺乏能夠執(zhí)行像Linux等大型互聯(lián)網(wǎng)操作系統(tǒng)的能力，同時也缺乏由MMU所提供的安全與可靠性保護(hù)。 當(dāng)然，總會存在許多相當(dāng)具成本限制的運算應(yīng)用，所以我的預(yù)期并不是指8位和16位架構(gòu)被完全淘汰，而是基于先進(jìn)指令集架構(gòu)與晶體管幾何的32位微處理器整體價格(包括BOM成本與功耗)逐漸下滑，最后將會贏在價格上。這將可為設(shè)計人員帶來更充裕的電腦運算性能，并有助于簡化工作。 趨勢二：復(fù)雜度推動C以外的語言發(fā)展 我的第二個預(yù)測是C編程語言在嵌入式系統(tǒng)領(lǐng)域占優(yōu)勢主導(dǎo)地位的美好時光已經(jīng)屈指可數(shù)了。 請不要誤會我的意思，C語言是一種我更能掌握且很喜歡的編程語言。但是，正如你可能知道的，C根本就無法勝任打造需要超過1百萬條代碼的系統(tǒng)。然而，1百萬多行代碼的系統(tǒng)卻是長久以來推動編程領(lǐng)域的嵌入式軟件所需的復(fù)雜程度。有些事情就是得具有一定的復(fù)雜度。 此外，還有嵌入式系統(tǒng)開發(fā)人員平均年齡迅速在增加中，而C語言通常不再于大學(xué)課程中教授等等迫在眉睫的問題。因此，即使每個產(chǎn)業(yè)對于嵌入式智慧的要求越來越高，熟悉或有經(jīng)驗的C語言編程人員人數(shù)卻在不斷減少中。有些事也得要有人員才能完成??！ 但是，什么樣的替代語言可用于建立即時軟件、直接地操縱硬件，以及快速地移植到眾多指令集架構(gòu)呢？它當(dāng)然不會是C++或Ada或Java──這些都已經(jīng)被試過，而且發(fā)現(xiàn)其不足之處了。然而，在經(jīng)歷過許多CPU產(chǎn)品系列以及試過這么多其它語言后，開發(fā)一種新的編程語言可能也不見得是我們想要的答案。 因此，根據(jù)系統(tǒng)規(guī)格來看，我預(yù)期能為我們可靠地自動生成數(shù)百萬行C程序碼的工具，最終將成為新的替代方案。以目前符合這種趨勢的現(xiàn)有工具來看，我們可以密切注意Miro Same用于事件導(dǎo)向編程的開放來源Quantum Platform架構(gòu)及其免費的Quantum Model繪圖建模工具選項。你可能并不喜歡當(dāng)今自動生成代碼的作法，但我保證一旦你在為狀態(tài)機(jī)架構(gòu)進(jìn)行編程時，你將看到這整個結(jié)構(gòu)的好處，以及它可為編程帶來的效率。 對于這一類的工具而言，我認(rèn)為C語言是一種相當(dāng)普遍的輸出語言，這是因為C語言能直接操縱硬件緩存，而且為大量市場開發(fā)的每一種處理器都有兼容的編譯器可用。其實我真的期望持續(xù)要求具有技能與興趣的人員能為其協(xié)助調(diào)整代碼生成或編寫元件驅(qū)動器的性能，使其得以更密切地整合于硬件中。 趨勢3：連接性提升安全的重要性 越來越多的嵌入式系統(tǒng)之間密切地彼此互連，并連接到互聯(lián)網(wǎng)。你可能聽說過“物聯(lián)網(wǎng)”(Internet of Things；IoT)以及“普適計算”(ubiquitous computing)，也可能已經(jīng)把TCP/IP加進(jìn)你的設(shè)計中。但連接性還有太多我們從未了解到的層面，或許其中最明顯的就是安全性。 互連的設(shè)備離不開安全性，因此，我們必須從一開始就為連接設(shè)備加進(jìn)安全性的設(shè)計。觀察這整個產(chǎn)業(yè)，大多數(shù)的嵌入式設(shè)計人員很大程度上并不熟悉安全性。當(dāng)然你已經(jīng)讀過加密算法，也知道幾個相關(guān)的技術(shù)名詞。但大部份的嵌入式社群就和安全性設(shè)計人員一樣地似懂非懂，而其組織也無法為其帶來太多協(xié)助。安全性的強度僅僅和這一系統(tǒng)鏈中最薄弱的環(huán)節(jié)一樣。 這種狀況必須改變。正如閃存取代UV可擦除的EPROM一樣，在未來的幾十年，通過網(wǎng)絡(luò)下載升級程序與軟件升級也將成為主要的機(jī)制。我們首先必須架構(gòu)出安全的系統(tǒng)，然后才可能安全地進(jìn)行下載，從而使我們的產(chǎn)品有能力免于駭客的威脅與攻擊。 無論未來的情況如何發(fā)展，我確定嵌入式軟件開發(fā)仍將會是一個具吸引力與挑戰(zhàn)性的專業(yè)領(lǐng)域。 8位MCU將死？ 上文中Michael Barr預(yù)測32位處理器將最終擊敗或是完全取代8位產(chǎn)品。獨立嵌入式開發(fā)講師和顧問Jack G. Ganssle對此撰文作了如下評論。 我還記得，1990年時，一位分析師曾斬釘截鐵地對我說，8位已死，不久的將來將會是32位的天下。 Barr的文章引出了兩極化的意見，一位名為Chuck Manning的讀者認(rèn)為，32位的價格降低，將推動更多小型低端產(chǎn)品的發(fā)展。過去，我也好幾次提出過同樣的觀點。當(dāng)你可以用一分錢就買到一顆8位元件時，就可能再開啟一個今天我們都無法想像的廣大應(yīng)用市場。 Chuck 還指出，byte-wide處理器所吃的功率較少，而且能比32位處理器容忍更寬的電源電壓。這是實話，低功耗無疑是電子產(chǎn)業(yè)當(dāng)前的圣杯，不過，在可預(yù)見的未來，我還沒看到任何能發(fā)展出無功耗CPU的跡象。 另一位讀者Miro Samek則說，“8位已經(jīng)沒有什么意義了。”他的理論基礎(chǔ)在于，CPU本身只是典型微處理器中的一小部份，其他很大部份是存儲器和周邊。關(guān)于這點，來自支持與反對的意見很多。但基本上我不贊同這種說法。 確實，今天一個采用40nm制程的Cortex-M0+所需的尺寸不到0.01 2。在晶體管開銷或晶粒尺寸等限制條件下，CPU本身最終將會成為更加微小的部份。 不過，就今天討論的主題而言，我們也看到了三個充滿矛盾和混亂的趨勢： 首先，許多非常低端的元件，都是由已經(jīng)完全折舊的“古董級”晶圓廠和制程所制造的。若未來這類元件要采用更先進(jìn)的制程，就必須支付更高昂的制造費用。 第二，還有另一種成本不會消失。讓我們面對現(xiàn)實：未來的32位微控制器會是ARM的天下，而ARM的主要營收來源是向每顆元件收取授權(quán)或權(quán)利金。這些數(shù)字諱莫如深，但我已聽到一些傳言，其Cortex元件要支付的費用達(dá)數(shù)十美分。 即使所有其他費用都零，但些元件仍然很難在價格極端敏感的應(yīng)用中競爭。我一直認(rèn)為，ARM的最大的競爭對手至今仍未出現(xiàn)：即一個免收授權(quán)費的開放源代碼CPU供應(yīng)商，而且還能支持所有的ARM產(chǎn)品。 這會發(fā)生嗎？或許吧。若真的出現(xiàn)，它會成功嗎？從對專有工具的支持朝自由、開放的一端轉(zhuǎn)移，一直是半導(dǎo)體產(chǎn)業(yè)中的一個主要趨勢，所以，一旦出現(xiàn)開放源代碼CPU，必然能符合制造商的發(fā)展模式。但確實，我們很難看到這樣一個自由的轉(zhuǎn)移模式，如何創(chuàng)造出巨大的、大多與ARM兼容的生態(tài)系統(tǒng)。 第三，硅芯片成本將繼續(xù)下降，直到他們不再是低端微處理器要考慮的問題。屆時最花錢的部份會在封裝，但沒有理由高端和低端微控制的封裝和接腳不兼容。想想六引腳的Cortex元件吧。 另外，我也不認(rèn)同Miro的說法：“我認(rèn)為，讓8位持續(xù)強大的主要原因與技術(shù)沒什么關(guān)系，而是來自于嵌入式開發(fā)社群的習(xí)慣。” 毫無疑問，這的確的事實，但成本仍然是推動工程決策的關(guān)鍵因素。不過，除了成本以外，還必須考慮工具。我最近用了ARM幾款還不錯的IDE，但它的成本高達(dá)數(shù)千美元。相較之下，Microchip的PIC工具就幾乎是免費的了。當(dāng)然，你也可以拿GCC來開發(fā)ARM，并建立你自己的環(huán)境，但你所需要的時間和更多的專業(yè)知識可能必須超過一家開發(fā)商所擁有的。 |