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）。
图文：
（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官方之前提供的标准外设固件库做应用软件设计。
从客户的描述来看，基本可以肯定TIM3的时钟、GPIOB的时钟都已正确使能了。关于TIM3_CH1的PWM初始化代码应该不会有啥问题，除非偶尔的笔误没发现。后来一起查看了相关PWM初始化代码也的确没发现问题。
PB5脚对应的TIM3_CH2可以实现PWM,而PB4对应的TIM3_CH1却无法实现PWM。怀疑该脚是否还有其它的复用了。客户说，PB4他只用来做PWM输出，并无其它功能安排，硬件线路上也无其它连接。
打开芯片数据手册，查看PB4的管脚说明如下：
从这里可以看出，PB4脚的复位后的主功能是个特定功能脚，是JTAG口的一个复位脚。如果要用做TIM3_CH1的话得先做REMAP操作才可以。
经与客户工程师沟通，他的确也做了相关REMAP操作，而且REMAP是没问题的。因为PB5也是经过同一REMAP操作后才能成为TIM3_CH2通道的。
既然REMAP没问题，那应该是别的原因。询问该工程师是否使用JTAG调试口，答曰用SWD口，只涉及PBA13/PA14，根本没用到PB4。
查看STM32F1参考手册可以发现PB4及PA13\\PA14\\PA15\\PB3等5个脚在芯片复位后默认的就是专用的调试口，非通用GPIO。现在客户工程师虽然用SWD接口，只用到PA13\\PA14两根线，但PB4及PA15、PB3三根线的属性没变，还是专用调试口。如果要把不用的PB4等三根线作为GPIO，还得额外做些相关寄存器配置，即操作AFIO_MAPR寄存器中的SWJ_CFG【2:0】三个位。
让客户工程师在程序代码里添加有关AFIO_MAPR寄存器的配置代码后，测试基于PB4脚的TIM3_CH1的PWM输出功能，一切正常。看来，问题就出在跟调试口复用的GPIO脚释放问题上。即对于复位后呈现专用调试口的功能脚，欲部分或全部用在GPIO，得额外通过相关软件代码配置来修改其属性，将相关管脚释放为GPIO。
STM32 MCU芯片管脚复用之灵活而复杂是其一特色，增强了管脚使用与安排的灵活性。也正因为这个灵活，经常有人会因为管脚复用的安排遇到些小麻烦。像类似问题，在数据手册里各个管脚的复用功能都一一列出了，然后逐一核对有无多重使用问题也不难找到原因。
不过，如果使用ST公司的STM32CubeMx图形化配置工具来做管脚安排及时钟初始化等就可以避免很多类似上面谈到的繁琐或麻烦。利用STM32CubeMx配置工具，很多初始化的东西都可以依据你的管脚和时钟安排、外设功能的使能等而生成出相应的配置代码，不必手动二次添加配置,让你去专注你的用户应用代码设计与调试。
比方是以上面事例来谈，关于TIM3的功能脚的REMAP、JTAG脚的配置以及项目中用到的各外设的时钟使能、相关GPIO的配置等都可自动生成，不会出现配置代码方面丢这个少那个的问题，使用起来给开发者带来了不少方便，节省了不少时间。
C
由于板子上没有焊外部晶振，所以选择HSI（16MHZ）为时钟源通过PLL倍频。 在第一帖中http://forum.eepw.com.cn/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. /* USER CODE BEGIN 1 */
4. /* USER CODE END 1 */
5. /* MCU Configuration----------------------------------------------------------*/
6. /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
7. HAL_Init();
8. /* Configure the system clock */
9. SystemClock_Config();
10. /* System interrupt init*/
11. HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
12. /* Initialize all configured peripherals */
13. MX_GPIO_Init();
14. /* USER CODE BEGIN 2 */
15. /* USER CODE END 2 */
16. /* USER CODE BEGIN 3 */
17. /* Infinite loop */
18. while (1)
19. {
20. HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_SET);
21. delay_test();
22. HAL_GPIO_WritePin(GPIOA,GPIO_PIN_5,GPIO_PIN_RESET);
23. delay_test();
24. }
25. /* USER CODE END 3 */
26. }
编译之后，配置好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 结果：
http://wiki.altium.com/pages/viewpage.action?pageId=6848757
原来如彼，Polygon 本身作为对象是非法的，因为这里隐含的对象是导线之类的物体，不可能 IsPolygon。必须用
InPolygon属性。而 InPolygon 属性在 Query Builder 里是找不到的。好奇尝试了一下用 IsPolygon 做条件关键字，没有报
错，说明可行。
在 Clearance 中右键添加新规则，并对新旧两个规则进行命名以便区分。而且我注意到两个规则有优先级之分：
我决定拿优先级为1的规则做通用规则，用于规范手动布线时属于不同网络的各种对象最小间距。而次优先的规则专门用
于敷铜与其它对象的最小间距。但我忽略了这是个逻辑问题，第一个规则里面的匹配条件必须彻底排除掉第二个规则所限
制的对象。如果没有排除，则优先级为1的规则会“覆盖”另一个规则。也就是说，如果第一个规则里的 First Object 或者
Second Object 中任意一个可以包含 InPolygon 这个属性，则第二个规则就形同虚设了。我想要的15mil间距不会出现，所有
的敷铜仍然按照8mil间距铺设。所以应该这样编辑第一个规则：
第二个规则：
打勾使这两组规则均生效，然后点OK。可以看到原先按照8mil间距铺设的敷铜已经被绿色高亮，明显已经无法通过规则检查。
重建敷铜，发现敷铜已经可以按照期望中的方式铺设。
