一、遇到的问题
通过这一段时间业务代码编写实践，体会到了之前的代码结构的缺陷：
（1）开发效率低：每次使用片内的某一资源（例如定时器等），笔者都要去查询CC2430中文手册，比较eggache~
xtal_init ，led_init
（3）不易修改：代码中的业务逻辑与SFR的操作混在一起，可读性较差，修改起来也费力
二、嵌入式项目也来分个层
硬件抽象层（Hardware Abstract Layer）。
功能模块层（Functional Module Layer）。
应用程序层（Application Layer）。
图文：
（1）硬件抽象层（HAL）
实现对片内资源 (如定时器、ADC、中断、I/O等) 的通用配置，隐藏具体的SFR操作细节，为上层提供简单清晰的调用接口。
（2）功能模块层（FML）
HAL，实现项目中所涉及到的各片外功能模块，隐藏具体的模块操作细节，并为上层提供简单清晰的调用接口。
（3）应用程序层（APL）
HAL 与 FML，实现最终的应用功能。
三、小试牛刀
OK，我们举一个具体的例子，来说明分层思想的运用。
在写作“Zigbee之旅”系列的某一篇博文时，笔者需要完成一个略带综合性的小实验“温度监测系统”，需求分析大概如下：
• CC2430节点实现对温度的定时采集，并可通过LED灯指示其采样频率
• 节点将数据传送至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）
优点逐渐浮出水面：
• 高效的开发速率：编完 HAL 层中的
hal.h 之后，我们就可以很方便地调用，而不必反复地去查询SFR的具体设置细则
• 快速扩展：若需要加强系统功能，只需在 FML 层添加相应功能模块（即 .c 文件），并在 main.c 中调用即可
• 较高的代码重用性：HAL 层所提供的SFR操作可供通用，而且该层几乎不用修改就可直接用于新的CC2430项目中
• 较好的可维护性：项目代码结构清晰，HAL 与 FML 几乎不需要修改，只需修改 APL 即可
四、结语
发现问题 → 投入思考 → 提出方案
