首先，嵌入式開發的核心就是芯片，它提供固定的片內資源共開發者使用。而且它具有一個很重要的特點就是，不隨項目的需求變動而變動。所以應將其作為最底層，為上層提供基礎支持。我們將其命名為 硬件抽象層（Hardware Abstract Layer）。
芯片有了當然還不夠，通常我們會在片外擴展一些功能模塊來滿足具體的項目需求，例如：傳感器、鍵盤、LCD屏等。這一層的特點是，隨項目的變動而以模塊為單位動態增減。這一層的運作需要芯片內部資源的支持，所以應處於硬件抽象層之上，並為上層調用。我們將其命名為 功能模塊層（Functional Module Layer）。
OK，現在原材料都准備齊了：芯片+擴展模塊，接下來就要開始真正的加工了：我們需要靈活調用之前兩層所提供的接口，實現具體的項目需求。我們將其命名為 應用程序層（Application Layer）。
圖文：
（1）硬件抽象層（HAL）
實現對片內資源 (如定時器、ADC、中斷、I/O等) 的通用配置，隱藏具體的SFR操作細節（我相信哪些年直接操作寄存器的編程方式大家早就受夠了），為上層提供簡單清晰的調用接口。
（2）功能模塊層（FML）
通過調用 HAL，實現項目中所涉及到的各片外功能模塊，隱藏具體的模塊操作細節，並為上層提供簡單清晰的調用接口。
（3）應用程序層（APL）
通過調用 HAL 與 FML，實現最終的應用功能。
四、小試牛刀
OK，我們舉一個具體的例子，來說明分層思想的運用。
在寫作“Zigbee之旅”系列的某一篇博文時，筆者需要完成一個略帶綜合性的小實驗“溫度監測系統”，需求分析大概如下：
• 節點將數據傳送至PC端
• 節點可以接收來自PC的控制指令，以調整采樣速率和電源模式
• 具備停機自動復位能力
• 可進入睡眠狀態，並可由按鍵喚醒
從上面的需求中我們可以看出，本實驗的核心芯片為CC2430，需要的片外擴展模塊為LED燈與按鍵，預期要達到具體項目需求即以上五點。
接下來，我們利用上面提到的分層理論小試牛刀，對“溫度監測系統”這一實驗的代碼結構進行規划：
（1）應用程序層（APL）
[main.c] 引用 hal.h、ioCC2430.h 與 module.h，實現溫度采集、與PC互通信、停機復位等具體的應用需求
（2）功能模塊層（FML）
[module.h] 定義了一系列片外功能模塊（LED、按鍵），以及一系列的相關函數的聲明
[module.c] 引用 hal.h，實現各片外模塊（LED、按鍵）的功能
（3）硬件抽象層（HAL）
[ioCC2430.h]（系統自帶）：定義了CC2430的所有SFR 、中斷向量
[hal.h] 包括常用類型定義、常用賦值宏、以及CC2430片上資源的配置（I/O、串口通訊、ADC、定時器、電源管理等）
（注：由於本實驗所涉及的片外模塊——LED與按鍵——的使用極其簡單，所以筆者將其合並入了單個源文件。若遇到較復雜的模塊，可以單獨新建 .h 與 .c 文件來實現，如LCD.h、LCD.c）
經此設計，其優點逐漸浮出水面：
• 快速擴展：若需要加強系統功能，只需在 FML 層添加相應功能模塊（即 .c 文件），並在 main.c 中調用即可
• 較高的代碼重用性：HAL 層所提供的SFR操作可供通用，而且該層幾乎不用修改就可直接用於新的CC2430項目中
• 較好的可維護性：項目代碼結構清晰，HAL 與 FML 幾乎不需要修改，只需修改 APL 即可