STM32L0单片机 定时中断编程参考知识点.doc

A 嵌入式项目代码结构的分层——HAL（硬件抽象层）、FML（功能模块层）、APL（应用程序层） 　　在“Zigbee之旅”系列博文中，每写一篇笔者都会编写一个小实验来展开讲解。通过这一段时间的实践，我积累了一些编码经验，但也体会到了之前的代码结构的缺陷：　　（1）开发效率低：每次使用片内的某一资源（例如定时器等），笔者都要去查询CC2430中文手册，比较eggache~ 　　（2）代码重复较多：每个实验源码中，诸如?xtal_init?，led_init?等初始化函数每次都要编写 　　（3）不易修改：代码中的业务逻辑与SFR的操作混在一起，可读性较差，修改起来也费力 　　正是由于以上问题，笔者决定暂停了该系列博文的续写，抽出时间来思考一下解决办法。 　　笔者在学习嵌入式编程之前，曾有过 ASP.NET 网站开发经验，对其分层理论也有所实践，下面简单提一下：　　一般的有一定复杂度的网站可分为以下三层： 　　（1）数据接入层（DAL）：负责与数据库的交互，供业务逻辑层调用 　　（2）业务逻辑层（BLL）：调用数据接入层以获取数据，并为具体的业务需求提供支持 　　（3）用户界面层（UIL）：负责呈现最终的用户界面 　　相信博客园中很大一部分朋友都对此非常熟悉，在此不再赘述。总之，分层以后，大大提高了代码的复用性与扩展性。 　　那么在嵌入式开发中，能否也利用分层的思想，来提高开发效率，增强其可维护性与可扩展性呢？下面，是一些笔者思考后的浅见。 　　当然不能照搬ASP.NET 的具体分层思想，具体问题得具体分析嘛~　　首先，嵌入式开发的核心就是芯片，它提供固定的片内资源共开发者使用。而且它具有一个很重要的特点就是，不随项目的需求变动而变动。所以应将其作为最底层，为上层提供基础支持。我们将其命名为?硬件抽象层（Hardware Abstract Layer）。　　 　　芯片有了当然还不够，通常我们会在片外扩展一些功能模块来满足具体的项目需求，例如：传感器、键盘、LCD屏等。这一层的特点是，随项目的变动而以模块为单位动态增减。这一层的运作需要芯片内部资源的支持，所以应处于硬件抽象层之上，并为上层调用。我们将其命名为?功能模块层（Functional Module Layer）。 　　OK，现在原材料都准备齐了：芯片+扩展模块，接下来就要开始真正的加工了：我们需要灵活调用之前两层所提供的接口，实现具体的项目需求。我们将其命名为?应用程序层（Application Layer）。 　　图文： 　　实现对片内资源 (如定时器、ADC、中断、I/O等) 的通用配置，隐藏具体的SFR操作细节，为上层提供简单清晰的调用接口。 　　通过调用?HAL，实现项目中所涉及到的各片外功能模块，隐藏具体的模块操作细节，并为上层提供简单清晰的调用接口。 　　通过调用?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）　　 　　经此设计，其优点逐渐浮出水面：