Python 微软 google Firefox Windows Android 云计算 程序员 开源 apache wordpress php java Ubuntu centos shell linux mysql 编程 nginx

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

一般的有一定復雜度的網站可分為以下三層:數據接入層(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 即可

延伸阅读

    评论