嵌入式系統開發之道：菜鳥成長日誌與專案經理的私房菜

老鳥流淚！新手必看！史上最平易近人的嵌入式專案開發書籍
獻給正在這個業界努力求生存，以及將要踏入這個領域的勇士們！

　　■以幽默逗趣的職場對話，點出嵌入式系統開發的精髓。

　　■脫離傳統介紹嵌入式系統原理和設計理論，直接切入實戰現場。

　　■透過完整的專案架構，循序引導正確的嵌入式系統開發觀念。

　　■用正統派的專案管理知識，貫穿電子產品開發生命週期，指引工程人員職涯發展再上層樓。

　　這是一本專為系統開發人員撰寫，以能快速理解何謂「嵌入式系統」的書，作者以自身擁有的豐富經驗與見聞，不藏私地分享在嵌入式領域真正有用的觀念。

　　本書最大的特色是以一個完整的嵌入式系統開發流程為架構，透過一位菜鳥工程師與專案經理的詼諧對話，故事性的帶出系統觀念及開發要素，實際瞭解要成為一位稱職的嵌入式系統工程師，於實務工作上所必須具備的各項知識及技能。是一本能讓你少走冤枉路，學習如何輕鬆的駕馭並有效率完成開發專案的實用指南。

新版特色

　　■重新改寫專案架構，更貼近開發人員的實務核心。

　　■基於嵌入式系統開發專案的特性，深入說明專案管理的觀念與工具。

　　■完全揭露專案進度追蹤實務，透過工具可更有效率的執行專案，避免專案進入無限輪迴。

　　■透過新增多個實際案例的探討，加重力道闡述系統架構設計的方法與重要性。

　　■全面性收錄目前嵌入式系統開發領域中，從業人員不可不知的所有面相，包含以下幾個嵌入式系統書籍的創舉：

　　．闡述硬體抽象層（HAL）對嵌入式系統團隊之重要性，並詳實說明其開發實務。
　　．完整揭露實現NAND Flash系統的流程與不可忽略的重點技術。
　　．剖析開發Turnkey Solution與一般嵌入式系統專案的異同與注意事項。
　　．深入探討IC設計公司之嵌入式系統團隊（System Application；SA）的管理。

作者簡介

邱毅凌

　　成功大學工程科學研究所計算機組碩士，畢業論文為分散式物件導向作業系統的實作，從此與系統底層結下不解之緣。畢業後進入資策會，開發了生平第二個作業系統，並任專案經理，開始電子產品開發專案管理的工作。

　　之後赴大陸深圳的網京科技公司帶領研發團隊，技術主軸為資訊家電（IA），2001年任職台北的Canon研發中心，期間除了負責系統開發與研發人員管理之外，並主導台灣、大陸、日本、美國、韓國等研發單位的共同開發專案。

　　2007年，加入國內某上市IC設計公司，擔任SA團隊的部門經理，順利導入專案管理與軟體工程的研發流程，並改善品質系統與開發效率。

　　專長：作業系統實務、嵌入式系統開發與專案管理

　　著作：《現代嵌入式系統開發專案實務》

6-07 SDK
菜鳥：「有個問題一直困擾著我。所謂的SDK（Software Development Kit）應該是以開發系統為主的大公司，如Microsoft、Apple、Google，提供給產品開發商，讓他們可專注於諸如Windows、iPhone、Android應用程式開發的套件。而本公司主要是接電子產品開發案，面對的客戶通常就是出錢與出嘴巴，比較積極的客戶會介入我們的品質檢測流程，我的意思是說，客戶並不直接參與開發工作，我們也不需要提供開發套件給客戶。

既然如此，為什麼我們在做系統架構設計與工作分組時，還要特別組成SDK team，負責所有與嵌入式系統平台相關的工作？」

PM：「記不記得我對所有專案成員都有一個要求：永遠要把上一層的團隊當作客戶。從系統架構圖來看，system team是driver team的客戶、middleware team是system team的客戶，而AP team則是所有軟體研發團隊的客戶，若再往後延伸，工廠是硬體、軟體團隊的客戶等等。唯有用這樣的觀念做事，團隊間才能權責分明，而系統中各部份的規格才有辦法真正符合外部客戶的需求。

但據我觀察，一般研發團隊的文化恰恰相反，他們認為越底層才是越有技術的，既然底層團隊以技術掛帥，一不小心就會變成閉門造車，完全不認真考慮上層的真正需求。而上層團隊往往也只能逆來順受，用不合適的系統介面，勉強地按照客戶的規格開發應用程式，工作效率與產品品質難免因此而大打折扣。無論底層或上層團隊，對公司來說一樣重要，我要表達的是『越接近真正客戶的團隊，他們的意見越應該被重視』。

我一直設法跟公司高層與專案成員灌輸這樣的觀念。消費性電子產品的開發一定是top-down的，一切都必須由終端市場或使用者需求啟動，亦即所有的研發目標都必須對準end user，所以硬體上最重要的是機構外觀與製造成本，軟體上則是應用程式，然而很多公司都本末倒置了！」

菜鳥：「每次我問A，你都不正面回答，往往答案都直接跳到X、Y、Z去。恕弟子駑鈍，我的問題是：為什麼嵌入式系統開發團隊必須維護自己的SDK？你卻回答要把上層當作客戶、開發產品應該是top-down。是不是有點太離題了？」

6-7-1 為何嵌入式系統開發團隊必須維護自己的SDK？
PM：「我不至於那麼跳tone吧！你仔細想想，既然微軟必須提供SDK給開發Windows應用程式的客戶，為什麼我們的系統團隊不必為應用程式團隊準備SDK？在討論下去之前，你先說說我們的SDK裡面包含什麼套件，有什麼用途？」

菜鳥：「SDK的目的其實就是建立我們（即本章）一直討論的嵌入式系統平台，提供應用程式開發人員『舒適』的開發環境與足夠的系統功能。根據我們的定義，SDK（或說嵌入式系統平台）應該包含：

■ 開發環境：tool-chain + IDE + debug tool。
■ 系統功能：為所有系統與硬體功能定義明確的API，並將其implementation包裝為函式庫（Library）。若有必要，可提供少數系統模組的原始碼，供上層工程人員作客製化之用。
■ API文件與SDK使用手冊。
■模擬器環境（Simulator或Emulator）：圖6-25就是iPhone OS SDK提供的模擬器環境，當沒有硬體環境時，也可以進行應用程式的開發。
■ 硬體環境：EV-board（評估板）、EV-board使用手冊、線路圖。
■ 其他工具：系統更新工具、系統效能統計工具（Profile Tool、BenchmarkTools）、Resource（text & image）轉換工具等。

圖6-25：iPhone OS SDK提供的iPad模擬器（Emualtor）
SDK包含了必要的開發工具與範例程式，讓工程師能夠馬上進行應用程式的開發，不必理會程式編譯、image build、下載、除錯等細節。此外，系統與硬體功能應已經過嚴謹的抽象化，工程師只要關注自己要開發的部份，系統功能都可以當成是黑盒子。」

PM：「依據SDK的定義，你再思考一下，包裝SDK會需要多少額外的effort？以及SDK可以為我們這樣的嵌入式系統開發團隊帶來什麼優勢？」

菜鳥：「按照以上的列表來看，全都是本來就必須要做的事，只是找個專職單位負責將其包裝SDK Package，讓其他工程師可專注於應用程式的開發，以滿足客戶的真正需求。有些單位會認為包裝SDK Package需要更多的時間人力資源，我想是因為訂定不出API的原因吧！若在設計階段，系統架構中並未嚴格規範driver/system/middleware/AP之間只能透過API溝通，則工程師在實作時，上下層間難免交互參考，造成系統與應用程式模組間的耦合度過高，此時才想要包裝出所謂的SDK當然是困難重重。