嵌入式系統設計不僅要了解硬件還應該瞭解它與軟件之間的相互影響和作用。硬件設計需要一定的設計範例，這點對於軟件設計卻不那麼適用。如何從單純的硬件設計過渡到硬軟結合的設計，在你着手開發軟件時需注意以下八個軟件設計技巧。
1.設計控制流程圖
工程師進行到開發軟件這一步時會情不自禁地開始書寫代碼。這種思維定勢就像在原理圖還未完成之前就開始嘗試畫PCB。當着手開發軟件時，剋制寫代碼的衝動，取而代之的應該是軟件流程結構圖表的設計，這點非常重要。流程圖能清晰地呈現給開發人員軟件的各個需要的組成部件，正如電路圖列出硬件設計所需的各種元器件一樣。做到這點能很大程度上使程序整體更易於組織，而且也會減少佔開發週期較長的調試工作量進而節省時間減少調試的繁瑣。
2.使用狀態機控制程序流程
狀態機是20世紀優秀的軟件發明之一。應用程序一般被分解爲多個不同的狀態，每一個狀態控制一個特定的程序分支。狀態機包括內部狀態和依據不同激勵所控制的狀態轉換。使用狀態機機制設計軟件能夠使模塊化的可維護的軟件開發更加容易而且易於理解。狀態機原理與算法的示例隨處可見。
3.避免使用全局變量
在過去的函數式編程中，程序員使用函數編寫程序，他們的唯一目標是使程序儘可能快的運行而不考慮程序的結構和重用性。這類程序風格在使用全局變量時不注意變量的作用範圍引起其他函數修改的危險性。這樣變量會被多次佔用和重寫。如今面向對象的程序設計中，成員變量被定義在最小的作用範圍之內並封裝起來避免被重新復值和濫用。所以建議儘量少地使用全局變量，實在需要的話，使用C語言中的關鍵字“extern”來修飾。
4.充分利用模塊化的設計理念
如果你問一位工程師項目的哪一部分最有可能會拖延交付並超出預估時間，那答案一定是軟件週期了。軟件通常是複雜而且不易開發和維護的，特別是當項目應用程序集中在一個單一的文件裏，或者幾個結構鬆散的文件中時。爲了便於代碼重用和軟件可維護並減小軟件的複雜度，強烈建議發揮高級程序設計語言模塊化的特性，在程序的結構中把公用的函數分離出來作爲一個獨立的模塊。通過這種方式可以讓程序員開始創建包含有常用函數和常用的聲明定義，它可以很容易的被其他的代碼重用，這在以後的測試階段不僅可以節省時間代價還能提高代碼的質量。
5.中斷服務事件保持簡練
中斷服務事件是中斷處理器正在執行的程序，轉而去處理觸發該中斷的外設的請求的一種機制。處理器響應中斷請求需要大量的系統開銷，具體表現在保存被中斷程序的狀態（入棧下條指令的段地址、偏移地址和程序狀態寄存器，有時還會入棧若干寄存器的值），執行中斷服務程序然後恢復中斷點繼續執行（依次出棧各寄存器），雖然現在的處理器速度非常快但是這種系統開銷仍然需要考慮。一般來說，爲了避免與主程序衝突程序員總想使中斷執行時間減小到最小。這就意味着中斷服務事件應該短小簡單。不能在中斷程序中調用函數。另外，如果中斷需要處理的事件特別複雜或者需要花費較長的時間，這個時候中斷服務程序應該滿足最小的需求，例如將數據載入到緩衝寄存器、設置標誌位，而讓主程序去處理讀入的數據。這樣處理器的工作大部分週期都在處理程序而不是中斷。
6.使用處理器示例代碼測試設備
對於硬件設計，在畫板之前標準的測試電路有助於工程師理解電路的特性。同樣可以適用於軟件設計，半導體廠商通常有測試微處理器各個部分的功能的示例程序提供工程師體驗各部分是如何工作的。據此可以提前組織軟件的結構並且預知在設計中的問題。提前確定在設計潛在的障礙遠比在產品完成前幾個小時發現問題更加科學合理。而值得注意的是廠商提供的代碼通常不是模塊化而且不做必要的修改是很難直接用於實際的軟件中的。
7.控制函數的複雜度
在工程設計中有句俗語叫“KISS”，意思是“Keep It Simple Silly”。在處理一些複雜的任務時最簡單有效的方法是把它分解成若干個簡單的子任務，當任務或者功能很複雜時，人們很難留意所有的細節也很難不出錯。當工程師寫了一個在當時能夠理解的複雜函數，可一段時間後需要維護程序了還能不能清晰的呈現出當初的設計思想這是值得考慮的。有大量的技術來衡量函數的複雜度像“循環複雜度”。經驗告訴我們，函數的循環複雜度應該低於10比較好。
8.詳細的文檔
在激烈的軟件開發競爭中關注的焦點很容易就侷限在代碼的書寫和調試而忽略文檔的編寫。有時迫於壓力要求寫文檔，開發人員通常把文檔安排在項目開發的最後的一個環節集中編寫。然而給代碼寫文檔應該乘在頭腦裏面還比較清晰的時候比較關鍵，這樣在後續的開發或者自己閱讀註釋的時候能很快的回憶起當時的設計思想