nand意思的問題，透過圖書和論文來找解法和答案更準確安心。 我們找到下列免費下載的地點或者是各式教學

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

為了解決nand意思的問題，作者邱毅凌 這樣論述：

老鳥流淚！新手必看！史上最平易近人的嵌入式專案開發書籍獻給正在這個業界努力求生存，以及將要踏入這個領域的勇士們！ 　　■以幽默逗趣的職場對話，點出嵌入式系統開發的精髓。 　　■脫離傳統介紹嵌入式系統原理和設計理論，直接切入實戰現場。 　　■透過完整的專案架構，循序引導正確的嵌入式系統開發觀念。 　　■用正統派的專案管理知識，貫穿電子產品開發生命週期，指引工程人員職涯發展再上層樓。 　　這是一本專為系統開發人員撰寫，以能快速理解何謂「嵌入式系統」的書，作者以自身擁有的豐富經驗與見聞，不藏私地分享在嵌入式領域真正有用的觀念。 　　本書最大的特色是以一個完整的嵌入式系統開發流程為架構，透過一位菜鳥工

程師與專案經理的詼諧對話，故事性的帶出系統觀念及開發要素，實際瞭解要成為一位稱職的嵌入式系統工程師，於實務工作上所必須具備的各項知識及技能。是一本能讓你少走冤枉路，學習如何輕鬆的駕馭並有效率完成開發專案的實用指南。 新版特色 　　■重新改寫專案架構，更貼近開發人員的實務核心。 　　■基於嵌入式系統開發專案的特性，深入說明專案管理的觀念與工具。 　　■完全揭露專案進度追蹤實務，透過工具可更有效率的執行專案，避免專案進入無限輪迴。 　　■透過新增多個實際案例的探討，加重力道闡述系統架構設計的方法與重要性。 　　■全面性收錄目前嵌入式系統開發領域中，從業人員不可不知的所有面相，包含以下幾個嵌入式系統

書籍的創舉： 　　．闡述硬體抽象層（HAL）對嵌入式系統團隊之重要性，並詳實說明其開發實務。　　．完整揭露實現NAND Flash系統的流程與不可忽略的重點技術。　　．剖析開發Turnkey Solution與一般嵌入式系統專案的異同與注意事項。　　．深入探討IC設計公司之嵌入式系統團隊（System Application；SA）的管理。 作者簡介 邱毅凌 　　成功大學工程科學研究所計算機組碩士，畢業論文為分散式物件導向作業系統的實作，從此與系統底層結下不解之緣。畢業後進入資策會，開發了生平第二個作業系統，並任專案經理，開始電子產品開發專案管理的工作。 　　之後赴大陸深圳的網京科技公司帶領研

發團隊，技術主軸為資訊家電（IA），2001年任職台北的Canon研發中心，期間除了負責系統開發與研發人員管理之外，並主導台灣、大陸、日本、美國、韓國等研發單位的共同開發專案。 　　2007年，加入國內某上市IC設計公司，擔任SA團隊的部門經理，順利導入專案管理與軟體工程的研發流程，並改善品質系統與開發效率。 　　專長：作業系統實務、嵌入式系統開發與專案管理 　　著作：《現代嵌入式系統開發專案實務》 第01章　系統．嵌入．硬體 第02章　嵌入式專案管理 第03章　嵌入式系統開發專案生命週期：專案啟動與規劃 第04章　嵌入式系統開發專案生命週期：設計、執行與結案 第05章　實作你的第一個嵌入式

系統 第06章　實作嵌入式系統平台 第07章　建構良好的嵌入式系統開發環境 第08章　上電之後：Boot Loader 第09章　驅動程式 第10章　設計硬體抽象層 第11章　菜鳥當自強：軟體工程師硬起來 第12章　做好記憶體管理 第13章　記憶體管理(II)：NAND Flash概論 第14章　模擬器 第15章　專案進度追蹤實務 第16章　SoC設計公司中嵌入式系統團隊的管理 第17章　系統整合 第18章　Testing、Debugging與Tuning 第19章　結案前的煎熬 附錄A 　未執行專案管理的專案 附錄B 　Callback Function 附錄C 　用C來實作物件導向的概念

附錄D 　電子產品設計的最終依據：用戶體驗 作者序 　　《現代嵌入式系統開發專案實務》自2007年6月上市至今已有三年多的時間了，期間收到相當多的反饋、鼓勵、建議與指教，最令人開心的，則是能夠對想進入嵌入式系統開發領域的朋友提供諮詢，他們透過這本書找到了筆者，讓筆者有機會分享自己在這個領域的經歷與體驗，讓迷惘的朋友可以得到指引。本書強調的是『正念』（正確的觀念），亦即嵌入式系統開發與專案管理的觀念，不會因產品不同而有太大的差異，但筆者仍認為本書必須與時俱進，除了內容更豐富完整之外，還加入了筆者這些年來產業觀察與實際執行電子產品開發專案的心得，還延請更專業的出版團隊進行編製，使得這本書的品質

更加精良。 邱毅凌 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當然是困難重重。