当前位置：首页 > news >正文

STM32F103系列单片机寄存器操作和标准库操作

news 来源：原创 2025/4/26 20:58:28

关于stm32，标准库很早就学完了，但如果想要更加深入学习计算机硬件，那么学会寄存器操作是非常有必要的。今天从最简单的点灯开始，我们来对比一下二者的不同。

一、寄存器操作和标准库操作中点亮LED的区别

寄存器操作：

//初始化PB5和PE5为输出口.并使能这两个口的时钟		    
//LED IO初始化
void LED_Init(void)
{RCC->APB2ENR|=1<<3;    //使能PORTB时钟	   	 RCC->APB2ENR|=1<<6;    //使能PORTE时钟	GPIOB->CRL&=0XFF0FFFFF; //推挽输出//XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX//1111 1111 0000 1111 1111 1111 1111 1111
//结果XXXX XXXX 0000 XXXX XXXX XXXX XXXX XXXXGPIOB->CRL|=0X00300000;//最大速度50MHZ//0000//0011//0011GPIOB->ODR|=1<<5;      //PB.5 GPIOE->CRL&=0XFF0FFFFF;//推挽输出GPIOE->CRL|=0X00300000;//最大速度50MHZGPIOE->ODR|=1<<5;      //PE.5输出高 
}

标准库操作：

//初始化PB5和PE5为输出口.并使能这两个口的时钟		    
//LED IO初始化
void LED_Init(void)
{GPIO_InitTypeDef  GPIO_InitStructure;RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB|RCC_APB2Periph_GPIOE, ENABLE);	 //使能PB,PE端口时钟GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5;				 //LED0-->PB.5 端口配置GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; 		 //推挽输出GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;		 //IO口速度为50MHzGPIO_Init(GPIOB, &GPIO_InitStructure);					 //根据设定参数初始化GPIOB.5GPIO_SetBits(GPIOB,GPIO_Pin_5);						 //PB.5 输出高GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5;	    		 //LED1-->PE.5 端口配置, 推挽输出GPIO_Init(GPIOE, &GPIO_InitStructure);	  				 //推挽输出 ，IO口速度为50MHzGPIO_SetBits(GPIOE,GPIO_Pin_5); 						 //PE.5 输出高 
}

在上面两段代码中，我们可以看到，寄存器操作大多是使用0和1来控制寄存器；而标准库操作则是利用固件库封装的函数来实现。

相对来说，寄存器操作更偏向硬件底层，每次配置都需要结合具体的寄存器计算，需要多次查询相关手册。

而标准库则不同，我们只需要知道哪个引脚可以使能LED，就可以实现该功能。

二、寄存器和标准库的优缺点

寄存器操作

优点

性能高: 直接操作硬件寄存器通常比使用库函数更快，因为没有额外的函数调用开销。
灵活性强: 可以精确控制每个寄存器位，适合复杂的配置需求。
学习机会: 有助于深入理解硬件工作原理和寄存器结构。

缺点

复杂性高: 需要详细了解芯片手册中的寄存器定义和配置选项。
维护困难: 代码不易读取和维护，尤其是当项目规模较大时。
移植性差: 不同型号的STM32芯片寄存器可能有所不同，需要针对不同型号进行调整。

标准库操作

优点

易用性强: 提供了封装良好的函数接口，简化了编程过程。
可读性好: 代码更易于理解和维护。
移植性好: 使用标准库函数可以更容易地移植到其他STM32型号。
文档丰富: STM32标准外设库提供了详细的文档和示例代码。

缺点

性能稍低: 由于存在函数调用开销，性能略低于直接寄存器操作。
依赖库文件: 需要包含和链接相应的库文件，增加了项目的复杂性。

总的来说，如果使用简单开发的话，建议选择库函数或者HAL；如果需要定制或者对其性能，内存消耗要求较高的话，建议使用寄存器操作。

三、标准库的可移植性

我们可以看到，在上述标准库实现点灯的代码中，虽然较寄存器来说，标准库移植性相对较好。可是如果想把该代码移植到另一块开发板中，还是比较麻烦的。既然如此，我们可以这样进行优化。

在led.h头文件中，我们添加如下宏定义：

#define RCC_PB RCC_APB2Periph_GPIOB
#define RCC_PE RCC_APB2Periph_GPIOE

#define LED_Pin1 GPIO_Pin_5
#define LED_Pin2 GPIO_Pin_5

#define LED_GPIO1 GPIOB
#define LED_GPIO2 GPIOE

此时led.c代码为：

void LED_Init(void)
{GPIO_InitTypeDef  GPIO_InitStructure;RCC_APB2PeriphClockCmd(RCC_PB|RCC_PE, ENABLE);	 //使能PB,PE端口时钟GPIO_InitStructure.GPIO_Pin = LED_Pin1;				 //LED0-->PB.5 端口配置GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; 		 //推挽输出GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;		 //IO口速度为50MHzGPIO_Init(LED_GPIO1, &GPIO_InitStructure);					 //根据设定参数初始化GPIOB.5GPIO_SetBits(LED_GPIO1,LED_Pin1);						 //PB.5 输出高GPIO_InitStructure.GPIO_Pin = LED_Pin2;	    		 //LED1-->PE.5 端口配置, 推挽输出GPIO_Init(LED_GPIO2, &GPIO_InitStructure);	  				 //推挽输出 ，IO口速度为50MHzGPIO_SetBits(LED_GPIO2,LED_Pin2); 						 //PE.5 输出高 
}

        整体而言，我们好像改了很多，但又好像什么也没修改。还多加了一堆代码。

        从移植性的角度看，我们想要移植到另一块开发板时，只需要修改.h文件中的宏定义即可，大大节省了人力。

也有人会说，现在借助AI不是照样可以很快修改过来，也节省了人力，没必要这么麻烦，这属于典型的没苦硬吃。在这里，我有几点建议：

1.用AI确实很强大，写代码的速度远大于人工。但是，AI不知道这块开发板硬件电路如何设计的，如果想要让AI修改，开发者自身就必须对其有一定的了解；

2.如果全部依赖AI，那么AI也会反向从你这边接收信息，从而使项目变得透明；

        2.过多的借助AI，思维就会受到局限，开发者所能达到的上限就会降低，不利于更深入的发展；

3.最终建议：AI是帮助开发者开拓思路，发现问题并且解决问题的。如果把AI当作你的外置大脑，那么自身就会受到局限，不利于之后职业生涯的发展。

        网络是把双刃剑，AI亦然。过多的借助外力终究不是长久之计。