本節書摘來異步社群《嵌入式系統開發之道——菜鳥成長日志與項目經理的私房菜》一書中的第1章，第1.4節，作者：邱毅淩，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視
嵌入式系統開發之道——菜鳥成長日志與項目經理的私房菜
pm：“這個組就是我們的固件組。你可以看到每個人桌上除了個人計算機外，有着各式各樣的闆子、儀器、檔案和一堆不知名的線。前陣子大老闆要我要求所有工程師保持桌子的整齊，我馬上向他報告此事窒礙難行，不同領域的員工自有其工作模式，身為管理者必須為其創造最能發揮工作力的環境，不應該妄加限制。”
菜鳥：“好像負責固件的人數不是很多，面試時您曾提過除了正在開發的産品外，我們已經開始設計下一代的硬體平台。我以為開發階段應該會有許多問題等待解決，而新的硬體平台設計應該需要更多的人力，但我們就這四五個人，夠嗎？”
pm：“确實不夠，但這是我目前僅能擠出的人力，況且也不是每個人都适合做固件開發的。這樣說吧，若非不得已，不會有任何一個軍隊指揮官，會把一條一公裡的戰線交給隻剩15人的連隊防守，基本上，隻有15人的連隊根本就是不合理的存在，然而，這是不得不的現實。”
菜鳥：“老闆知道這樣的事嗎？”
pm：“當然，其實老闆正是始作俑者之一！哪一位老闆不希望用最少的資源創造最大的價值？公司存在的主要目的是什麼？不就是營利嗎？這就是我這個專業項目經理存在的原因之一。嵌入式系統開發本來就是限制重重的，人力缺乏隻是其中之一而已，而我的責任就是妥善統籌資源、人力與時間配置設定。”
在1-3節中說明了嵌入式系統的多樣性，接下來，我們從以下5個方面來說明嵌入式系統的另一個特性—限制。
産品規格設計
人力配置設定
進度管理
硬體設計
系統設計
嵌入式系統和一般軟體項目有個顯著的不同點，嵌入式系統完全應用于電子産品，而電子産品的開發必然牽涉硬體、結構、外觀設計及其制造成本，也就是說，軟體并不是某件電子産品是否熱銷的唯一原因1。
任何電子産品的開發計劃都始于需求或創意，而創意的實作卻往往被制造成本所限制， 也就是說，制定電子産品規格時必須有所節制，不能天馬行空的無限想象。舉例來說，要用國産車的造價，設計出奔馳同等級的車款，無異是緣木求魚。成本會影響規格，而規格則會影響所有與開發有關的工作。生産電子産品必須在成本與規格上取得微妙的平衡，如果規格及制造成本都不願讓步，那就隻能考驗開發團隊的能力了2。
偏偏現實世界是大部分的客戶或制定産品規格的人員都高估工程師的能力了。确切地說，應該是高估了目前計算機與管理科學的水準。在pc上某些很簡單的事情，要在8位cpu，或少得可憐的記憶體（可以想象整個系統的記憶體容量居然是以kb或byte為機關來計算的嗎？）的平台上實作時，需要的算法有時都可用來寫論文了。
結論是：因為制造成本的考慮，電子産品在制定規格時便限制重重，而産品規格更是直接影響了運作其中的嵌入式系統的開發。
嵌入式系統開發并不一定都是複雜的項目，例如“電子寵物機”就是一個技術簡單、成本低廉的産品，但其所牽涉的人力或技術種類卻肯定比一般軟體項目要多。以下簡單列出嵌入式系統開發流程不可或缺，但一般軟體項目可能不需要的人力資源。
硬體設計工程師
pcb layout工程師
pcb制作協助廠商
結構工程師
模具制造協助廠商
提供硬體零件的廠商（如cpu、裝置ic、記憶體、lcd子產品、電阻電容等）
固件工程師
硬體測試協助廠商
硬體品管及驗貨人員
工廠
即便隻負責軟體開發，也無可避免地要和其他機關協調與合作，如果軟體工程師能稍具其他領域的知識與技能，對嵌入式系統的開發絕對大有裨益。但現實情況是要找到具備與其他領域人員溝通的熱誠、管理協助廠商的能力，并兼具程式設計之外技能的軟體工程師确實不多，隻能讓工程師從工作中學習，等工程師好不容易漸入佳境，卻又要擔心被其他公司挖角，這是每一位管理嵌入式系統項目的項目經理心中無法抹滅的痛！
嵌入式系統開發在人力資源上的限制不僅僅是項目人數的問題，主要是牽涉機關太多，而各機關各有自己的文化及語言，管理的複雜度自然大增，若想把所有相關機關都納于同一公司或團隊之内，或要求每位員工都必須多才多藝且可同時執行不同領域的工作，卻也顯得不切實際且成本過高。
嵌入式系統不一定比一般軟體項目複雜（其實有些電子産品的軟體簡單的出奇），也不一定需要更多或更高素質的人力，但“人”的管理，絕對是嵌入式系統項目能否順利結項最重要的因素之一。
嵌入式系統的進度計劃（schedule）管理與人力管理面對同樣的問題與限制，即參與開發的機關通常很多。項目主管一方面要花時間精力協調各機關，以便精準控制進度；另一方面，某項任務的延誤，往往會影響其他機關的開發，尤其當這個機關隸屬于别家公司，甚至這家公司不在國内時，不理性的争執、責任的推诿以及語言與文化的隔閡，必然讓進度延誤的狀況雪上加霜。
圖1-15所示是個典型的嵌入式系統的進度計劃表，你可以發現很多任務是有前後關系的，而這些任務之間又往往屬于不同領域、牽涉到不同公司。實際上，因為不确定性因素太多，進度計劃表幾乎都是邊做邊修正的。
項目中的任務之間必然會有一些相依性。舉例來說，硬體的延誤會影響軟體的開發，而驅動程式的開發延誤也可能影響硬體設計的驗證，産品規格遲遲無法确定，則會打亂其他開發機關的步調，零件供貨商供貨出問題，則會直接影響生産，若到開發中後期，某零件無法供應，則直接受沖擊的将是硬體設計以及固件工程師，整體項目進度勢必推遲。
以圖1-15所示為例，最常發生的悲劇是所有時間表都是由預計量産時間點往前推導得來。舉例來說，營銷部門希望12月底産品可以上架販賣，是以往前推12月5日必須開始量産，再往前推一個月必須做小量試産，也就是說，在11月5日前硬體所有問題都要解決并完成備料。再繼續推演。假設公司規定試産後軟硬體設計就不該再更動，那麼，既然11月5日要小量試産，軟體應該要在半個月前就緒，而根據經驗，軟體要經過3輪qc測試才能将所有問題解決完，是以推導出軟體整合必須在10月初就完成，于是管理人員拍拍腦袋就把進度計劃畫出來了。
注意到了嗎？上述推演是以銷售時間推導量産時間，用量産時間推導硬體開發時間，再用硬體開發時間推導軟體開發時間，其中完全沒考慮到人力與規格複雜度，主事者的說法必然是：“如果軟體沒辦法照我的計劃完成，這個産品就無法如期上架銷售，則項目視同失敗，是以請大家盡量配合加班……”其中邏輯看似合理，其實相當荒謬，一個擺明無法執行的進度規劃行同廢紙一張。
而且嵌入式系統是軟硬體整合，調試較為困難，測試負載量也較大。在産品應用日漸複雜的情況下，偏偏電子産品的生命周期越來越短，為求盡快将産品推到市場，開發時間往往被迫壓縮。然而産品品質和上市時機（time to market）孰重孰輕沒有一定的答案，要視情況而定，是以嵌入式系統開發的進度管理需要考慮的事情非常多，要訂出合理且可滿足品質與上市時間的開發進度，幾乎是件不可能的任務。
身為項目經理，制定進度計劃時隻能秉持經驗、知識與職業道德勉力為之。原則上，項目進入執行階段就不該大幅度修改進度計劃，但實際上，頻繁的更改進度計劃卻是業界的常事。其實項目進度并不是測不準，主要是嵌入式系統項目牽涉的變量太多，偏偏預定上市時間又太趕，往往沒做好完整的風險評估就貿然進入執行階段，任何一件小事若發生推遲的狀況，就可能對整個項目進度造成出乎意料的影響。
嵌入式系統的硬體設計也是限制重重，成本考慮是造成這些限制的主因，其他會影響硬體設計的原因還包括：
産品規格與客戶要求：産品規格當然會直接影響硬體設計，而負責制定産品規格的客戶常常有些特殊的要求。例如，指定使用該集團子公司生産的零件，或要求硬體設計必須符合其舊有産品的結構。尤其是某些傳統的國際大廠自有一堆内部标準，從鍵盤的反應時間、系統的耗電流、音頻輸出的品質、必須通過環境測試的種類，一直到零件采購公司的限制等。舉例來說，通常這些大公司内部都有一份可采購零件的廠商清單，如果硬體設計者忽略了這個限制，到後期才發現可就麻煩了。若一開始不弄清楚客戶的要求，等到産品試産之後才發現問題一堆，除了影響進度，勢必影響工程師的士氣以及公司之間的合作氣氛。
cpu特性：cpu是電子産品的心髒，當cpu標明後，硬體設計才可随之展開，嵌入式系統使用的cpu往往不為人所熟知。舉例來說，epson可不是隻作列印機而已，他們的半導體部門根據特定的應用領域設計了一系列的嵌入式cpu。該cpu内部內建了許多外圍晶片，如sdram、lcd controller等，廣泛地應用在諸如電子辭典或電子書等産品上。除此之外，許多硬體産商為特定應用自行設計的asic或soc更是不勝枚舉。
cpu的特性與功能直接影響其他部分的硬體設計，舉例來說，若cpu的gpi/o（general purpose i/o；cpu中可用于一般用途的輸出或輸入腳位）不夠，則勢必要外加擴充i/o電路或晶片，假若cpu有提供諸如i2c或i2s等通信接口，硬體設計者就可以選用支援此接口的外圍晶片，因為這些接口可以把多個晶片串在同一個bus上，不但控制簡單，還可節省i/o腳位。此外，嵌入式系統領域裡的cpu通常內建了許多其他外圍ic，如此可減輕硬體設計的複雜度與工作量。
cpu的選擇對産品開發有着決定性影響，選擇cpu時必須在性能、單價以及可用資源上取得平衡。基本上，工程師不必奢望會有性能遠超過産品應用需求的cpu可用，這是嵌入式系統工程師的宿命！
耗電流：開發pc或web應用程式時幾乎不需考慮系統耗電的問題，但在許多産品應用上，盡量延長使用時間卻是重要的規格或功能之一，手機是最容易明了的例子。要延長産品的使用時間，軟硬體都要配合，硬體設計上除了使用更長效的充電電池之外，還必須花時間選用較省電的零件。為了在待機時可以盡可能的把沒在動作的零件電源關閉，硬體設計時必須考慮到軟體的需求，如選用cpu某根i/o腳來當作某個零件的電源開關。
産品size大小及外觀：結構設計也可能影響硬體設計。同樣功能的硬體零件要“擺”在開發初期用的大闆子（target board）與最終産品的小闆子（real size board），在硬體設計的困難度并不是在同一個等級上的！其中牽涉到layout走線以及為了抗幹擾所增加的硬體設計。
圖1-16所示有兩張比較圖，其機器具有完全相同的電路設計，但因為最終産品外觀結構不同，其中一台機器必須分為兩塊闆子，就硬體設計而言，其複雜度自然較高。
銷售國家或地區：每個國家或區域對電子産品上市前要通過的檢查标準都不同，簡單地說，同樣類型的産品，銷售某些非洲國家和銷售美國、歐洲、日本等已開發國家就可能采用不同的硬體設計（這樣說并沒有任何輕視非洲國家的意思）。往往硬體設計為了提升一點性能必須付出極大的代價，例如，ca認證标準要求産品的抗靜電能力必須達到某個等級，但有些廉價的晶片抗靜電能力就很差，要解決這個問題，要不就得加抗靜電電路、修改結構或加銅箔保護，否則就隻能更換主要晶片，除了成本增加外，也可能影響其他部分的硬體設計。
工廠制造與備料能力：這是一個常被項目經理或工程師忽略的因素，硬體工程師設計出來的東西，最終當然希望順利大量生産，但選中的工廠卻不見得有生産這些産品的能力。工廠并不是隻有組裝而已，同樣以手機的例子來說，要驗證生産線上手機半成品的通信功能需要昂貴的儀器，并非每間工廠都負擔得起。此外，有時選擇零件還必須考慮工廠的庫存與備料的能力，是以硬體設計初期，最好就能和工廠人員确認設計是否可行。例如，這個産品要用到某個型号的flash memory（閃存），在設計定案之前，應該先了解工廠是否有燒錄該flash的能力（如支援該flash的燒錄器）。
嵌入式系統開發在軟體上的限制顯而易見，許多工作項目在一般軟體開發項目上都是沒有的，而本書大半的篇幅便是試圖說明面對這個現實的因應之道，在此我們先列舉如下。
不熟悉的cpu與硬體平台
不熟悉的開發環境
不易調試
cpu計算能力限制
記憶體容量限制
在不穩定的硬體平台上進行驅動程式開發
電源管理程式
工廠驗證專用軟體開發
嵌入式作業系統開發
仿真器開發
軟硬體整合測試
穩定度與性能調整
code size調整
細節會在之後的章節陸續提到，本節僅用一個例子來說明嵌入式系統軟體開發的“艱苦卓絕”。
在個人計算機cpu已邁入64位的時代，工作頻率超過3 ghz，還可以多核心，記憶體容量從gb等級起跳，請想想，你可以用8 bit、2 mhz的cpu來做什麼？
答案是任天堂電視遊戲機（紅白機），雖然這已是老古董了，且效果當然比不上ps23、ps3、wii、xbox 360等，但當你知道它的cpu是8 bit、1.77 mhz時，是否也對開發這個系統以及許多愛不釋手遊戲的軟體工程師懷有欽佩之意？這是個20多年前的産品，當時許多軟體技術都不如今日發達，他們是怎麼做到的？即便其下一代主機“超級任天堂”的cpu也僅僅是16 bit、3.68 mhz！
千萬不要以為8 bit cpu的時代已經過去了，據統計，微控制器廠商（mcu）在産品布局是以8位微控制器為主力，其次為16位，主要鎖定消費性應用市場。目前仍以8位微控制器的市場最大，就最典型的8位8051架構微控制器而言，全球一年的出貨量就高達33億個。這個數量已經明顯大過個人計算機cpu的需求！
2001年嵌入式系統國際會議年會jim turley的報告中提到：根據統計報告，pc的數量隻占cpu總銷售量的0.1%，而且直到可預見的未來，這個懸殊的比例都不會有太大的改變。這就是嵌入式系統開發的業界生态—絕大部分的電子産品制造商，正使用着不為人所熟知的cpu，開發圍繞你我生活的各種電子産品。
這也是嵌入式系統軟體工程師的宿命之一，他們的價值不在于用過許多cpu，寫過很多驅動程式，或開發過很多産品，而在于處處限制的情況下把産品開發出來，這意味着清晰的計算機系統概念、高效能的算法、良好的程式寫作習慣以及有效率的資源管理。