在前面章节中我们自己建工程的时候需要定义一个SystemInit空函数，但是在这个用STM32标准库的工程却没有这样做，SystemInit函数去哪了呢？

这个函数在STM32标准库的“system_stm32f10x.c”文件中定义了，而我们的工程已经包含该文件。标准库中的SystemInit函数把STM32芯片的系统时钟设置成了72MHz， 即此时AHB时钟频率为72MHz，APB2为72MHz，APB1为36MHz。当STM32芯片上电后，执行启动文件中的指令后，会调用该函数，设置系统时钟为以上状态。

细心对比过前几章我们自己定义的GPIO_Init函数与STM32标准库中同名函数的读者，会发现标准库中的函数内容多了一些乱七八糟的东西， 就是断言，具体见 代码清单:GPIO输出-5 。

基本上每个库函数的开头都会有这样类似的内容，这里的“assert_param”实际是一个宏，在库函数中它用于检查输入参数是否符合要求， 若不符合要求则执行某个函数输出警告，“assert_param”的定义见 代码清单:GPIO输出-6 。

这段代码的意思是，假如我们不定义“USE_FULL_ASSERT”宏，那么“assert_param”就是一个空的宏(#else与#endif之间的语句生效)，没有任何操作。 从而所有库函数中的assert_param实际上都无意义，我们就当看不见好了。

假如我们定义了“USE_FULL_ASSERT”宏，那么“assert_param”就是一个有操作的语句(#if与#else之间的语句生效)， 该宏对参数expr使用C语言中的问号表达式进行判断，若expr值为真，则无操作(void 0)，若表达式的值为假， 则调用“assert_failed”函数，且该函数的输入参数为“__FILE__”及“__LINE__”， 这两个参数分别代表 “assert_param”宏被调用时所在的“文件名”及“行号”。

但库文件只对“assert_failed”写了函数声明，没有写函数定义，实际用时需要用户来定义， 我们一般会用printf函数来输出这些信息，见 代码清单:GPIO输出-7 。

注意在我们的这个LED工程中，还不支持printf函数(在USART外设章节会讲解)，想测试assert_failed输出的读者， 可以在这个函数中做点亮红色LED灯的操作，作为警告输出测试。

那么为什么函数输入参数不对的时候，assert_param宏中的expr参数值会是假呢？这要回到GPIO_Init函数，看它对assert_param宏的调用， 它被调用时分别以“IS_GPIO_ALL_PERIPH(GPIOx)”、“IS_GPIO_PIN(GPIO_InitStruct->GPIO_Pin)”等作为输入参数，也就是说被调用时， expr实际上是一条针对输入参数的判断表达式。例如“IS_GPIO_PIN”的宏定义：

若它的输入参数 PIN 值为0，则表达式的值为假，PIN非0时表达式的值为真。 我们知道用于选择GPIO引脚号的宏“GPIO_Pin_x”的值至少有一个数据位为1， 这样的输入参数才有意义，若GPIO_InitStruct->GPIO_Pin的值为0，输入参数就无效了。配合“IS_GPIO_PIN”这句表达式， “assert_param”就实现了检查输入参数的功能。对assert_param宏的其它调用方式类似，大家可以自己看库源码来研究一下。

在STM32标准库以及我们自己编写的“bsp_led.c”文件中，可以看到一些比较特别的注释，类似 代码清单:GPIO输出-8 。

这是一种名为“Doxygen”的注释规范，如果在工程文件中按照这种规范去注释，可以使用Doxygen软件自动根据注释生成帮助文档。 我们所说非常重要的库帮助文档《stm32f10x_stdperiph_lib_um.chm》，就是由该软件根据库文件的注释生成的。 关于Doxygen注释规范本教程不作讲解，感兴趣的读者可自行搜索网络上的资料学习。

在STM32标准库的所有头文件以及我们自己编写的“bsp_led.h”头文件中，可看到类似 代码清单:GPIO输出-9 的宏定义。 它的功能是防止头文件被重复包含，避免引起编译错误。

在头文件的开头，使用“#ifndef”关键字，判断标号“__LED_H”是否被定义，若没有被定义，则从“#ifndef”至“#endif”关键字之间的内容都有效， 也就是说，这个头文件若被其它文件“#include”，它就会被包含到其该文件中了，且头文件中紧接着使用“#define”关键字定义上面判断的标号“__LED_H”。 当这个头文件被同一个文件第二次“#include”包含的时候， 由于有了第一次包含中的“#define __LED_H”定义，这时再判断“#ifndef__LED_H”， 判断的结果就是假了，从“#ifndef”至“#endif”之间的内容都无效，从而防止了同一个头文件被包含多次，编译时就不会出现“redefine（重复定义）”的错误了。

一般来说，我们不会直接在C的源文件写两个“#include”来包含同一个头文件，但可能因为头文件内部的包含导致重复，这种代码主要是避免这样的问题。 如“bsp_led.h”文件中使用了“#include “stm32f10x.h””语句，按习惯， 可能我们写主程序的时候会在main文件写“#include “bsp_led.h” 及#include “stm32f10x.h””， 这个时候“stm32f10x.h”文件就被包含两次了，如果没有这种机制，就会出错。

至于为什么要用两个下划线来定义“__LED_H”标号，其实这只是防止它与其它普通宏定义重复了， 如我们用“GPIO_PIN_0”来代替这个判断标号，就会因为stm32f10x.h已经定义了GPIO_PIN_0，结果导致“bsp_led.h”文件无效了，“bsp_led.h”文件一次都没被包含。