由網站開發延伸的嵌入式項目開發分層思想

一般的有一定複雜度的網站可分為以下三層：資料接入層（DAL）：負責與資料庫的互動，供業務邏輯層調用;業務邏輯層（BLL）：調用資料接入層以擷取資料，并為具體的業務需求提供支援;使用者界面層（UIL）：負責呈現最終的使用者界面。

在

嵌入式開發

中，也體會到了之前的代碼結構的缺陷：開發效率低：每次使用片内的某一資源（例如定時器等），筆者都要去查詢技術手冊，比較eggache；代碼重複較多：每個實驗源碼中，諸如 xtal_init ，led_init 等初始化函數每次都要編寫；不易修改：代碼中的業務邏輯與SFR的操作混在一起，可讀性較差，修改起來也費力。

現在我們也對嵌入式項目也來個分層:

首先，嵌入式開發的核心就是晶片，它提供固定的片内資源共開發者使用。而且它具有一個很重要的特點就是，不随項目的需求變動而變動。是以應将其作為最底層，為上層提供基礎支援。我們将其命名為 硬體抽象層（Hardware Abstract Layer）。

晶片有了當然還不夠，通常我們會在片外擴充一些功能子產品來滿足具體的項目需求，例如：傳感器、鍵盤、LCD屏等。這一層的特點是，随項目的變動而以子產品為機關動态增減。這一層的運作需要晶片内部資源的支援，是以應處于硬體抽象層之上，并為上層調用。我們将其命名為 功能子產品層（Functional Module Layer）。

現在原材料都準備齊了：晶片+擴充子產品，接下來就要開始真正的加工了：我們需要靈活調用之前兩層所提供的接口，實作具體的項目需求。我們将其命名為 應用程式層（Application Layer）。

嵌入式項目設計.jpg

1.硬體抽象層（HAL）

實作對片内資源 (如定時器、ADC、中斷、I/O等) 的通用配置，隐藏具體的SFR操作細節，為上層提供簡單清晰的調用接口。

2.功能子產品層（FML）

通過調用 HAL，實作項目中所涉及到的各片外功能子產品，隐藏具體的子產品操作細節，并為上層提供簡單清晰的調用接口。

3.應用程式層（APL）

通過調用 HAL 與 FML，實作最終的應用功能。

現在我們拿溫度監測系統來做一個需求分析：

CC2430節點實作對溫度的定時采集，并可通過LED燈訓示其采樣頻率

• 節點将資料傳送至PC端

• 節點可以接收來自PC的控制指令，以調整采樣速率和電源模式

• 具備停機自動複位能力

• 可進入睡眠狀态，并可由按鍵喚醒

從上面的需求中我們可以看出，本實驗的核心晶片為CC2430，需要的片外擴充子產品為LED燈與按鍵，預期要達到具體項目需求即以上5點。

接下來，我們利用上面提到的分層理論小試牛刀，對“溫度監測系統”這一實驗的代碼結構進行規劃：

應用程式層（APL）

[main.c] 引用 hal.h、ioCC2430.h 與 module.h，實作溫度采集、與PC互通信、停機複位等具體的應用需求

功能子產品層（FML）

[module.h] 定義了一系列片外功能子產品（LED、按鍵），以及一系列的相關函數的聲明

[module.c] 引用 hal.h，實作各片外子產品（LED、按鍵）的功能

硬體抽象層（HAL）

[ioCC2430.h]（系統自帶）：定義了CC2430的所有SFR 、中斷向量

[hal.h] 包括常用類型定義、常用指派宏、以及CC2430片上資源的配置（I/O、序列槽通訊、ADC、定時器、電源管理等）

（注：由于本實驗所涉及的片外子產品——LED與按鍵——的使用極其簡單，是以筆者将其合并入了單個源檔案。若遇到較複雜的子產品，可以單獨建立 .h 與 .c 檔案來實作，如LCD.h、LCD.c）

經此設計，其優點逐漸浮出水面：

• 高效的開發速率：編完 HAL 層中的 hal.h 之後，我們就可以很友善地調用，而不必反複地去查詢SFR的具體設定細則

• 快速擴充：若需要加強系統功能，隻需在 FML 層添加相應功能子產品（即 .c 檔案），并在 main.c 中調用即可

• 較高的代碼重用性：HAL 層所提供的SFR操作可供通用，而且該層幾乎不用修改就可直接用于新的CC2430項目中

• 較好的可維護性：項目代碼結構清晰，HAL 與 FML 幾乎不需要修改，隻需修改 APL 即可