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

A

嵌入式项目代码结构的分层——HAL（硬件抽象层）、FML（功能模块层）、APL（应用程序层）

一、遇到的问题

在“Zigbee之旅”系列博文中，每写一篇笔者都会编写一个小实验来展开讲解。通过这一段时间的实践，我积累了一些编码经验，但也体会到了之前的代码结构的缺陷：

（1）开发效率低：每次使用片内的某一资源（例如定时器等），笔者都要去查询CC2430中文手册，比较eggache~

（2）代码重复较多：每个实验源码中，诸如xtal_init，led_init等初始化函数每次都要编写

（3）不易修改：代码中的业务逻辑与SFR的操作混在一起，可读性较差，修改起来也费力

正是由于以上问题，笔者决定暂停了该系列博文的续写，抽出时间来思考一下解决办法。

笔者在学习嵌入式编程之前，曾有过https://www.sodocs.net/doc/0c2189395.html, 网站开发经验，对其分层理论也有所实践，下面简单提一下：

一般的有一定复杂度的网站可分为以下三层：

（1）数据接入层（DAL）：负责与数据库的交互，供业务逻辑层调用

（2）业务逻辑层（BLL）：调用数据接入层以获取数据，并为具体的业务需求提供支持

（3）用户界面层（UIL）：负责呈现最终的用户界面

相信博客园中很大一部分朋友都对此非常熟悉，在此不再赘述。总之，分层以后，大大提高了代码的复用性与扩展性。

那么在嵌入式开发中，能否也利用分层的思想，来提高开发效率，增强其可维护性与可扩展性呢？下面，是一些笔者思考后的浅见。

当然不能照搬https://www.sodocs.net/doc/0c2189395.html, 的具体分层思想，具体问题得具体分析嘛~

首先，嵌入式开发的核心就是芯片，它提供固定的片内资源共开发者使用。而且它具有一个很重要的特点就是，不随项目的需求变动而变动。所以应将其作为最底层，为上层提供基础支持。我们将其命名为硬件抽象层（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之旅”系列的某一篇博文时，笔者需要完成一个略带综合性的小实验“温度监测系统”，需求分析大概如下：

? 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 即可

五、结语

可能对于嵌入式编程高手来说，上述理论可能完全算不得什么，甚至还存在着很大的错误。不过在一个初学者从入门走向精通的途中，像这种发现问题→投入思考→提出方案的学习模式，我相信是值得而且很有必要的。就像很多人说的那样：过程比结论更重要。

接下来，笔者将会把大部分精力投入到“Zigbee之旅”的第一阶段的收尾工作中。希望在学习了C51编码规范，以及对代码分层的思考之后，我能够编写出一个虽然小但五脏俱全的项目代码。

敬请期待：Zigbee之旅（十）：探索型综合小实验——基于CC2430的温度监测系统（未完成）

分类: 嵌入式开发

B

整理： MilerShao

近日，某工程师用STM32F103C8开发产品，用到TIM3的PWM输出功能。他发现TIM3_CH2可以实现PWM【此通道对应的GPIO脚是PB5】;而TIM3_CH1却不能实现PWM【此通道对应的GPIO脚是PB4】。该工程师在基于ST官方之前提供的标准外设固件库做应用软件设计。

C

由于板子上没有焊外部晶振，所以选择HSI （16MHZ ）为时钟源通过PLL 倍频。 在第一帖中

https://www.sodocs.net/doc/0c2189395.html,/thread/277383/1写了一个简易的代码体验了一下工程的建立。其中没有配置时钟，程序在2MHZ 的时钟频率下运行。程序效果是LED 灯闪烁，程序中有一段延时是这么写的：

view plaincopy to clipboardprint?

1.void delay_test()

2.{

3. uint32_t ui_delay = 0xffff;

4. while(ui_delay--);

5.}

现在配置时钟为32MHZ，仍然使用这个延时函数，理论上是应该闪的更快。

打开STM32CUBEMX,选择新建工程，选择型号后配置外设资源：

板子上LED2接在PA5引脚上，所以配置PA5为输出模式

再配置时钟：

生成项目：

打开项目文件夹后，进入工程文件夹，打开MDK的工程：

在main.c中添加上面提到的延时函数，在添加如下代码作为测试：

view plaincopy to clipboardprint?

1.int main(void)

2.{

3.

4. /* USER CODE BEGIN 1 */

5.

6. /* USER CODE END 1 */

7.

8. /* MCU Configuration----------------------------------------------------------*/

9.

10. /* Reset of all peripherals, Initializes the Flash interface and the Systick. */

11. HAL_Init();

12.

13. /* Configure the system clock */

14. SystemClock_Config();

15.

16. /* System interrupt init*/

17. HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);

18.

19. /* Initialize all configured peripherals */

20. MX_GPIO_Init();

21.

22. /* USER CODE BEGIN 2 */

23.

24. /* USER CODE END 2 */

25.

26. /* USER CODE BEGIN 3 */

27. /* Infinite loop */

28. while (1)

29. {

30. HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET);

31. delay_test();

32. HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET);

33. delay_test();

34. }

35. /* USER CODE END 3 */

36.

37.}

编译之后，配置好DEBUG选项，下载程序，可以看到的效果是，LED灯闪烁的肉眼看不清，几乎是一直亮着。将延时函数中ui_delay = 0xffff;修改为ui_delay = 0xfffff;才可以看到LED闪烁起来。从效果上看，

时钟配置应该是有效果的

D

第一优先规则：

First Object = InPolygon，Second Object = All

第二优先规则：

First Object = All，Second Object = All

进入Design -> Rules -> Clearance 项目。选择第一个对象的匹配条件。现有的条件均没有Polygon 一项，于是进入

Query Builder。发现匹配条件中有Object Kind is 一项，而右侧列表中有Poly。依此设置点击OK 之后生成Full Query

内容为IsPolygon。那么满足IsPolygon 的对象与所有对象之间的间距肯定就是敷铜与所有对象之间的间距了，点击Apply

后报错“Some rules have incorrect definitions. Would you like to correct them?”说明此路不通：

设置Query

报错

心生好奇，上Google 搜索关键字“Altium (IsPolygon)”，返回第一个结果是Altium 官方的wiki 结果：https://www.sodocs.net/doc/0c2189395.html,/pages/viewpage.action?pageId=6848757

原来如彼，Polygon 本身作为对象是非法的，因为这里隐含的对象是导线之类的物体，不可能IsPolygon。必须用

InPolygon属性。而InPolygon 属性在Query Builder 里是找不到的。好奇尝试了一下用IsPolygon 做条件关键字，没有报

错，说明可行。

在Clearance 中右键添加新规则，并对新旧两个规则进行命名以便区分。而且我注意到两个规则有优先级之分：

我决定拿优先级为1的规则做通用规则，用于规范手动布线时属于不同网络的各种对象最小间距。而次优先的规则专门用

于限制敷铜与其它对象的最小间距。但我忽略了这是个逻辑问题，第一个规则里面的匹配条件必须彻底排除掉第二个规则所限

制的对象。如果没有排除，则优先级为1的规则会“覆盖”另一个规则。也就是说，如果第一个规则里的First Object 或者

Second Object 中任意一个可以包含InPolygon 这个属性，则第二个规则就形同虚设了。我想要的15mil间距不会出现，所有

的敷铜仍然按照8mil间距铺设。所以应该这样编辑第一个规则：

第二个规则：

打勾使这两组规则均生效，然后点OK。可以看到原先按照8mil间距铺设的敷铜已经被绿色高亮，明显已经无法通过规则检查。

重建敷铜，发现敷铜已经可以按照期望中的方式铺设。