关于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 XXXX
GPIOB->CRL|=0X00300000;//最大速度50MHZ
//0000
//0011
//0011
GPIOB->ODR|=1<<5; //PB.5
GPIOE->CRL&=0XFF0FFFFF;//推挽输出
GPIOE->CRL|=0X00300000;//最大速度50MHZ
GPIOE->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口速度为50MHz
GPIO_Init(GPIOB, &GPIO_InitStructure); //根据设定参数初始化GPIOB.5
GPIO_SetBits(GPIOB,GPIO_Pin_5); //PB.5 输出高
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_5; //LED1-->PE.5 端口配置, 推挽输出
GPIO_Init(GPIOE, &GPIO_InitStructure); //推挽输出 ，IO口速度为50MHz
GPIO_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口速度为50MHz
GPIO_Init(LED_GPIO1, &GPIO_InitStructure); //根据设定参数初始化GPIOB.5
GPIO_SetBits(LED_GPIO1,LED_Pin1); //PB.5 输出高
GPIO_InitStructure.GPIO_Pin = LED_Pin2; //LED1-->PE.5 端口配置, 推挽输出
GPIO_Init(LED_GPIO2, &GPIO_InitStructure); //推挽输出 ，IO口速度为50MHz
GPIO_SetBits(LED_GPIO2,LED_Pin2); //PE.5 输出高
}整体而言，我们好像改了很多，但又好像什么也没修改。还多加了一堆代码。
从移植性的角度看，我们想要移植到另一块开发板时，只需要修改.h文件中的宏定义即可，大大节省了人力。
也有人会说，现在借助AI不是照样可以很快修改过来，也节省了人力，没必要这么麻烦，这属于典型的没苦硬吃。在这里，我有几点建议：
1.用AI确实很强大，写代码的速度远大于人工。但是，AI不知道这块开发板硬件电路如何设计的，如果想要让AI修改，开发者自身就必须对其有一定的了解；
2.如果全部依赖AI，那么AI也会反向从你这边接收信息，从而使项目变得透明；
2.过多的借助AI，思维就会受到局限，开发者所能达到的上限就会降低，不利于更深入的发展；
3.最终建议：AI是帮助开发者开拓思路，发现问题并且解决问题的。如果把AI当作你的外置大脑，那么自身就会受到局限，不利于之后职业生涯的发展。
网络是把双刃剑，AI亦然。过多的借助外力终究不是长久之计。