企业官网建设流程全解析

板子到手那天，我第一件事不是插线，而是把它放在桌上盯着看了十分钟。STM32F103这块板子，在嵌入式圈子里几乎是“启蒙导师”一样的存在——菜鸟靠它入门，老鸟拿它做原型验证，甚至不少量产项目里它还在服役。时隔多年再买一块回来，说实话不是因为缺它不可，更多是想把当初踩过的坑、绕过的弯路重新梳理一遍。这篇文章就是写给和你一样刚把开发板买回来、准备认真学STM32的朋友：从环境搭建、点灯、串口，到定时器、中断、常见外设，再到CAN、USB这类进阶方向，一条线讲清楚。不管你是完全零基础，还是已经摸过51单片机想往上走一步，这篇文章都能让你少走几个月的冤枉路。

1. 拿到板子先冷静，这三个问题想清楚再动手

很多人买了开发板，第一反应是“赶紧跑个例程看看灯亮不亮”。这个心情我完全理解，但真正有效率的学习路径，是先把几个底层问题想明白。

1.1 STM32F103到底是个什么东西

STM32F103是基于ARM Cortex-M3内核的32位微控制器，主频最高72MHz，放在今天看参数平平无奇，但它的地位非常特殊：出货量巨大、资料铺天盖地、生态极其成熟。初学者常见的型号是STM32F103C8T6，也就是大家口中的“蓝 pill”或者“核心板”，48引脚，64KB Flash，20KB SRAM。

你可能想不通，为什么现在几百兆主频的芯片遍地都是，还要学这个“上古”芯片。原因其实很实际：STM32的架构和开发方式具有极强的通用性。你今天学会了F103的GPIO配置、中断系统、定时器原理，明天换到H7系列、G4系列，甚至换到别的厂商的ARM芯片，核心逻辑是一样的——时钟树、外设寄存器、中断向量，这些都是ARM Cortex-M生态的通用知识。学F103，本质上是学方法论。

另外一个现实原因是，F103的开发资料真的多到看不完。你能遇到的每一个问题，几乎都有人在网上踩过并留下了解决方案。这种“容错率”对新手来说太重要了，你不需要因为一个小问题卡好几天。

1.2 硬件验收：别急着上电，先做三件小事

我见过太多人兴冲冲插上USB线，结果板子毫无反应，然后心态爆炸。其实很多问题在上电前就能避免。板子到手后，我先做三件事：

第一，核对板卡版本和芯片丝印。核心板上最常见的芯片是STM32F103C8T6，丝印在芯片正面上，字很小，用手机微距拍一下放大看。曾经有人买的是“兼容芯片”或者翻新片，丝印模糊、字迹不工整，这种板子遇到诡异问题的概率会大不少。

第二，检查板上的晶振。F103核心板一般板载8MHz晶振和32.768kHz的RTC晶振。用万用表二极管档测一下两个晶振引脚是否通路——注意是测两端的阻值，不是短路，正常会有几百欧到千欧余的读数。晶振虚焊是核心板的常见“暗病”。

第三，看电源指示灯和3.3V电压。插上USB之前，先确认板子的供电跳线帽或者LDO电路没有异常。插上之后，第一时间用万用表测3.3V引脚对地电压，稳定在3.3V左右才算正常。芯片的VDDA、VDD引脚上如果电压不对，后面所有调试都是空中楼阁。

1.3 芯片第一脚怎么确认，别把引脚定义搞反

热词里有一个“stm32芯片第一脚怎么确认”，这个问题看起来简单，坑起人来毫不含糊。方法其实不复杂：找到芯片一角的小圆点或缺口标记，那个位置就是第1脚，然后逆时针编号，依次是2、3、4……直到最后一个脚，再从对侧回到第1脚旁边就是最高编号引脚。

但实际操作中有两个容易翻车的地方。一是有的核心板上的芯片引脚已经通过PCB引出来了，你真正要对准的是板子丝印上的引脚标注，而不是直接数芯片。二是有个反直觉的细节：很多开发板的丝印标注“1脚”的位置并不是物理芯片的第1脚，而是排针座上的第1个孔位。我干过一回，按芯片丝印接了一个外设，结果引脚对不上，排查了半天才发现是排针编号和芯片编号错位了。所以，拿到板子第一件事，把原理图下载下来，对照着看排针的标号和芯片引脚的映射关系。原理图就是你的地图，不看地图就上路，出了事还得怪自己。

2. 开发环境这一关，选对路子能省一个礼拜

环境搭建是劝退新手的第一大杀手。很多人的学习之路不是死在代码上，而是死在工具链的配置上。这里我直接给结论：如果你刚入门，用Keil MDK；如果有点经验了，可以用VSCode + PlatformIO或者STM32CubeIDE。

2.1 Keil MDK还是VSCode，我的真实建议

Keil MDK是STM32圈子里的“老大哥”，大学实验室、公司量产项目里随处可见。它的优点很突出：工程管理清晰、调试器集成度高、网上教程最多。新手照着教程一步步来，不容易出错。缺点也很明显：界面停留在上个时代，编辑器体验一般，而且激活问题让人头疼。

VSCode配Eclipse插件或者PlatformIO，体验更现代，代码补全、Git集成都很舒服。但问题是，配置过程对新手不太友好——你要自己处理编译器路径、调试器配置、链接脚本这些概念，而这些概念本身你可能还没搞清楚。

我的建议是分阶段：第一个月老老实实用Keil MDK，把编译下载调试的流程跑通，建立起“改代码——编译——下载——看现象”的正反馈循环。等你熟悉了工程结构、理解了编译过程，再迁移到VSCode或者STM32CubeIDE也不迟。工具是为你服务的，不是给你添堵的。别一开始就追求“最酷的工具链”，先把活儿干出来。

2.2 标准库、HAL库还是LL库，方向问题必须一次弄清楚

这个问题几乎每个新手都会问，也是争论最多的话题之一。我一句说透：标准库适合学习原理，HAL库适合做项目，LL库适合在HAL基础上做性能敏感的部分。

标准库就是官方提供的一套寄存器封装函数，比如GPIO_Init()、USART_SendData()，你调用函数时能清楚地看到底层寄存器是怎么被操作的，数据手册上的寄存器描述和代码能对得上。这对理解芯片内部工作原理非常有帮助。但同时它的结构比较老旧，官方已经停止维护新芯片的支持，F103这些老芯片还能用，新芯片就没戏了。

HAL库是ST现在主推的抽象层，特点是可移植性强，代码风格统一，配合STM32CubeMX图形化配置工具，生成初始化代码的速度极快。缺点也很明显——抽象层厚，性能损耗多一些，而且调试时发现问题要追好多层函数才能找到源头。

我给新手的路线是：先用标准库把GPIO、串口、中断、定时器这些基础外设的原理学一遍，哪怕只是把例程上的寄存器操作看懂。然后再用STM32CubeMX + HAL库去实现一个完整的小项目，比如一个带OLED显示、按键控制的小系统。两条腿走路，原理和效率都有了。

2.3 工程怎么建，以及烧录工具的选择

建工程是环境搭建里最容易出错的一步。以Keil MDK为例，普通核心板建工程时，你需要选对芯片型号（STM32F103C8）；配置Flash下载算法（C8是64KB，选STM32F10x Med-density）；设置Debug选项里的调试器类型（ST-Link就选ST-Link，J-Link就选J-Link，别设错了导致连不上）。

烧录工具方面，ST-Link V2是性价比最高的选择，某宝几十块钱一个，稳定可靠。J-Link功能更强大，支持的命令更多，但价格高、假货多，新手没必要一上来就用它。PowerWriter、DAPLink之类的也都能用，但主流教程里出现频率最高、出问题最少的就是ST-Link V2。

有个小坑要提醒一下：有的核心板把SWD调试口和别的功能引脚复用了，比如PB3、PB4、PA15这些引脚默认是JTAG功能。如果烧录时提示“No target connected”，可以试试按住板子上的复位键再点下载，等开始下载瞬间松开，这个“手动复位法”救过我好几次。

3. 第一个程序不只是点灯，GPIO的完整认知才是重点

学习STM32的起点基本都是LED点灯，这个例程看似简单，但背后涉及的知识点一点都不少：时钟使能、GPIO模式配置、输出寄存器操作。把这一个例程彻底吃透，你就迈过了STM32最基础也最重要的门槛。

3.1 时钟配置：为什么先要“开时钟”再配GPIO

很多新手第一次看标准库代码都会产生一个疑问：为什么配置GPIO之前，要先调用RCC_APB2PeriphClockCmd()？原因在于STM32的外设时钟默认是关闭的——这是为了降低功耗。你如果不打开GPIO所在总线的时钟，寄存器的写入根本不会生效，灯自然不亮。

用生活化类比理解：寄存器就像灯开关，但整个控制面板的电源闸是关着的。你要按开关，第一步是合上电源闸，第二步才是拨动开关。对应到代码里，就是先使能GPIO时钟，再配置引脚模式。

以F103核心板的PC13引脚接LED为例（很多板子是PB12或者PA0，务必查原理图），标准库的点灯代码骨架大概是这样：

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE); GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.GPIO_Pin = GPIO_Pin_13; GPIO_InitStruct.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStruct); GPIO_SetBits(GPIOC, GPIO_Pin_13); // 输出高电平

这里还有个细节：GPIO_Speed设置的是翻转速率，不是引脚输出的电压或电流能力。50MHz意味着引脚电平翻转最快能到50MHz，对于点灯这种应用，设成2MHz就完全够用。设置得太高会引入不必要的噪声和功耗。

3.2 按键输入和上拉下拉：你踩过的坑我全踩过

点完灯就该试试按键了，这涉及GPIO的输入模式。很多新手在这里第一次接触到“上拉、下拉”的概念，然后开始困惑：按键不按的时候，引脚电平到底是高还是低？

先说结论：按键电路常规做法有两种——按键一端接GND，另一端接引脚，引脚内部上拉。按键按下时引脚读到低电平，松开时读到高电平。另一种是按键一端接3.3V，另一端接引脚，引脚内部下拉，按下时读到高电平。推荐第一种，因为单片机引脚对地短路比较安全，对3.3V短路反而要小心电流。

配置内部上拉的代码很简单，把GPIO_Mode设成GPIO_Mode_IPU即可。但这里有个物理问题：机械按键按下和弹起的瞬间，触点会产生抖动，电平在短时间内跳变多次。如果不做消抖，一个按键按下去可能会被识别成十几次触发。消抖的方式有两种：硬件消抖加RC滤波，软件消抖延时10~20ms再判断。对于学习板，软件消抖足够，核心逻辑就是检测到电平变化后延时20ms，再确认一次电平。

if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) == RESET) { delay_ms(20); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) == RESET) { // 按键确实按下了 } }

3.3 引脚复用冲突：为什么PB3、PB4会“不听话”

点灯和按键玩熟之后，你可能会尝试把JTAG口（PA13、PA14、PA15、PB3、PB4）当普通GPIO用，然后发现怎么配置都不对。这是因为这几个引脚默认被JTAG功能占用了，要使用它们必须先把复用功能释放掉。

标准库下只需一行：

GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE);

这句话会把SWJ调试功能完全关闭，释放PA15、PB3、PB4。注意，释放之后ST-Link的SWD调试功能也不可用了——SWD用的是PA13和PA14，所以如果你想一边用这几个引脚一边还能调试，那就需要用GPIO_PinRemapConfig的另一个选项，比如禁用JTAG但保留SWD（GPIO_Remap_SWJ_JTAGDisable）。这个细节我当时不知道，结果把ST-Link刷得连不上了，只能按复位键靠运气重连，非常狼狈。

4. 串口、中断和定时器，才是STM32的核心用法

点灯按键属于“感官刺激”，真正体现单片机灵魂的，是串口通信、中断响应和定时器的组合运用。这也是从“会玩”走向“会用”的分水岭。

4.1 串口通信和printf重定向，调试效率直接翻倍

串口是STM32和外界沟通最基础的通道。调试时用串口打印变量的变化，比用LED灯闪烁判断程序状态要高效一万倍。F103最常用的串口是USART1，对应引脚是PA9（TX）和PA10（RX）。

配置串口的要点有三个：引脚复用、波特率、数据格式。基础配置用标准库写出来大概是：

RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1 | RCC_APB2Periph_GPIOA, ENABLE); GPIO_InitTypeDef GPIO_InitStruct; GPIO_InitStruct.GPIO_Pin = GPIO_Pin_9; GPIO_InitStruct.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStruct.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStruct); GPIO_InitStruct.GPIO_Pin = GPIO_Pin_10; GPIO_InitStruct.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStruct); USART_InitTypeDef USART_InitStruct; USART_InitStruct.USART_BaudRate = 115200; USART_InitStruct.USART_WordLength = USART_WordLength_8b; USART_InitStruct.USART_StopBits = USART_StopBits_1; USART_InitStruct.USART_Parity = USART_Parity_No; USART_InitStruct.USART_Mode = USART_Mode_RX | USART_Mode_TX; USART_Init(USART1, &USART_InitStruct); USART_Cmd(USART1, ENABLE);

但光能发送还不够，调试时最好能直接用printf(“%d”, value)这样的格式输出。这要做一步“printf重定向”，本质是重写底层字符输出函数，让printf的每一个字符都通过串口发出去：

int fputc(int ch, FILE *f) { USART_SendData(USART1, (uint8_t)ch); while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET); return ch; }

这个过程有几个坑。第一，必须勾选Keil里“Use MicroLIB”选项，否则printf会占用大量资源，而且底层实现可能不认你的fputc。第二，USART发送要等待TXE标志置位，否则连续发送时数据会丢。第三，波特率不要设太高，我遇到过波特率设到2Mbps后，USB转串口芯片跟不上导致数据全乱的情况，后来改成115200稳定得很。

4.2 定时器：除了延时，它更擅长计数和捕获

很多新手用定时器，只会用延时函数delay_ms()。其实定时器是STM32里功能最丰富的外设之一，除了定时中断之外，还能做输入捕获、输出比较、PWM生成、编码器接口等。热词里提到的“stm32定时器捕获测频率”就是一个典型场景。

先搞清楚基本原理：定时器本质是一个计数器，它按照你设定的时钟频率不断累加，当计数值到达你设置的自动重装值时，产生一个更新事件。如果你设置计数频率为1MHz（1us一个计数），自动重装值是999，那么定时器每1ms溢出一次。

用定时器做延时，标准库的骨架是：

void TIM2_Init(void) { RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); TIM_TimeBaseInitTypeDef TIM_InitStruct; TIM_InitStruct.TIM_Prescaler = 7200 - 1; // 72MHz / 7200 = 10kHz TIM_InitStruct.TIM_Period = 10000 - 1; // 10kHz / 10000 = 1Hz TIM_InitStruct.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_InitStruct); TIM_Cmd(TIM2, ENABLE); }

这里的分频值和重装值都减了1，是因为定时器从0开始计数，到设定值需要（设定值+1）个时钟周期。很多人算出来的定时常数不对，就是漏了这个加一减一。

4.3 延时要可靠：Delay函数卡死的常见原因

热词里有“stm32延时函数delay卡死”，这个问题我当年也遇到过，而且它非常隐蔽。常见的卡死原因有三个：

第一个是SysTick没有及时重装。SysTick是内核自带的24位倒数定时器，适合做系统级延时。用它的正确流程是：设置重装值、清零当前计数值、启动倒数、等待COUNTFLAG标志。如果你在中断服务函数里没有清除标志，或者中断优先级配置有误，SysTick中断一直被占用，延时就会卡住。

第二个是优化等级引起的“错误优化”。编译器在O2甚至O3优化等级下，可能把空的while循环判断直接优化掉，导致延时函数根本等不到标志位翻转。解决办法是给标志变量加上volatile修饰。

第三个是中断嵌套逻辑错误。如果延时函数放在了某个中断服务函数里，而这个中断的优先级比SysTick还高，SysTick中断无法打断当前中断，延时就会死等。记住一个原则：延时函数里不要放无关紧要的中断服务逻辑，能放到主循环的就别放中断里。

我在实际项目中还遇到过一种情况：用了HAL库的HAL_Delay()，但SysTick的中断优先级被我手动改成了比某些外设中断低，结果外设频繁触发中断时，HAL_Delay()的时间严重不准。排查了半天，最后才发现是优先级配置的问题，重设SysTick为最低抢占优先级后恢复正常。

4.4 定时器输入捕获：实测的测频率方法和误差来源

输入捕获功能的本质，是利用引脚上的边沿信号来“锁存”定时器的当前计数值。简单说就是：当引脚出现上升沿时，硬件自动把此刻的计数值保存到捕获寄存器里。通过连续两次捕获到的计数值之差，就能算出信号的周期，进而算出频率。

以捕获一个PWM信号为例。假设定时器时钟为72MHz，预分频设为72减1，也就是计数频率为1MHz。第一次捕获到上升沿时CNT值是1000，第二次捕获到上升沿时CNT值是2000，差值就是1000，意味着信号周期为1000us，也就是1ms，频率为1kHz。

这里有几个误差来源要注意。第一，定时器的计数频率越高，分辨率越好，但计数溢出也越快，适合测高频；相反，计数频率低，适合测低频但精度差。第二，如果两次捕获之间定时器已经溢出过，就要用更新事件补记溢出次数，否则计算出来的周期会偏小。第三，信号本身有抖动时，测量结果会跳变，工程上常用连续测量多次取平均值的方式。

我实测一个旋转编码器输出信号时，用输入捕获测频率到0.1Hz精度是没问题的，但如果被测频率接近定时器溢出频率的整数倍，就会产生“混叠”现象，测出的频率会突然跳到另一个值。这类现象不是单片机坏了，而是测量方法本身有边界，只能通过调整分频系数来避开。

4.5 ADC采样：从单次转换到连续扫描

如果说串口是单片机的嘴巴，那么ADC就是它的眼睛。F103的ADC是12位的，精度在绝大多数传感器场景下够用。热词里“stm32 adc中断”被反复搜，是因为ADC有两种典型用法：一种是查询式，程序不断去读转换完成标志；另一种是中断式，转换完成后进入中断读取结果。

中断式的好处是主程序不用一直轮询等待，适合对实时性有要求的场景。标准库配置一个ADC中断通道的逻辑大约是：配置ADC触发方式（软件触发或定时器触发）、使能转换完成中断、在中断服务函数里读取ADC值并且清除标志。

有一个细节很容易被忽略：ADC转换完成之后，读取DR寄存器这个动作本身就会清除EOC标志。如果你在中断里先清了一次标志再读数据，读完之后又进了一次中断但数据已经丢了，就会产生“重复进入中断”的假象。正确顺序是先读数据，再清标志。这个顺序问题我写过专门的笔记，因为它在ADC+DMA配合时特别容易出现。

5. 常见外设实战：OLED、超声波、LCD屏的连线与调试

学完基础外设，就可以往传感器和屏幕方向发展了。这几个方向在实践中非常常见，也是热词里搜索量最大的内容。

5.1 I2C总线：OLED和BH1750光照传感器的标准玩法

I2C是一种只需要两根线（SCL时钟线、SDA数据线）就能挂多个设备的通信总线。OLED屏（SSD1306驱动）和BH1750光照传感器都是I2C设备，把两者挂在同一总线上非常典型。

连线时需要注意两个问题。第一个是地址冲突。I2C设备的地址是固定的或者可以通过引脚配置的，比如OLED的地址通常是0x3C或0x3D，BH1750的地址是0x23或0x5C。如果两个设备地址相同，在同一总线上就会发生通信冲突，必须错开。第二个是上拉电阻。I2C总线需要接上拉电阻，F103的I2C引脚内部已经有上拉，但如果线缆较长或者挂载设备多，建议外部再加4.7k的上拉。

关于F103的I2C外设，圈内有个共识：硬件I2C存在设计缺陷，容易卡死。所以很多老工程师宁可用GPIO模拟I2C。模拟I2C的代码逻辑不算复杂，就是靠GPIO的高低电平变化严格按照时序来模拟SCL和SDA的跳变。虽然效率不如硬件I2C，但胜在稳定可控。我是强烈建议新手先跑通模拟I2C，理解时序后，再尝试硬件I2C也不迟。

5.2 ILI9341读ID是A1A1，这屏幕怎么修

热词里“stm32使用ili9341读id是a1a1”这个搜索词，一看就是屏幕驱动的经典故障。ILI9341是2.4寸/2.8寸TFT LCD最常见的驱动芯片。正常读ID时，初始化代码会通过SPI接口发送读ID指令0x04，正确返回的ID通常是0x9341。如果你读到的是0xA1A1，说明数据完全没有正常返回。

A1A1这个值几乎是SPI通信失败的标志。我遇到过的情况里，最大的嫌疑是SPI的MISO线没接对。ILI9341模块一般有SDO/MISO引脚，如果你在初始化代码里只配置了SPI的MOSI、SCK和CS，没有把MISO引脚初始化成输入模式，读回来的数据就是全空或者全0xFF，经过某种处理后就变成A1A1。

排查思路按优先级排列：第一步查接线，MISO是否连到板子的SPI MISO引脚；第二步查SPI模式，ILI9341要求CPOL=0、CPHA=0或者CPOL=1、CPHA=1，与模块的SPI mode别搞错；第三步查IO电压，有些模块是5V供电的，但STM32的引脚是3.3V电平，两者不共地或电平不匹配会导致读回来的数据乱码；第四步查初始化序列，如果芯片不是标准ILI9341而是兼容品，初始化代码里的某些命令不认，也会导致读ID异常。我后来在调试一块“国产兼容屏”时，就是校准了SPI mode之后ID才正常的。

5.3 HC-SR04超声波测距的时序实现

超声波测距模块HC-SR04是极其经典的学习项目，也是很多毕业设计的标配。它的工作原理很简单：向Trig引脚发送一个至少10us的高电平脉冲，模块内部发出8个40kHz的超声波脉冲，然后Echo引脚输出高电平，高电平的持续时间就是超声波从发射到返回的时间。

距离计算公式是：距离 = 时间 × 声速 ÷ 2。常温下声速约为340m/s，也就是0.034cm/us。所以如果Echo高电平持续时间为t微秒，距离（厘米）就是t × 0.034 / 2 = t × 0.017。

用单片机实现的时候，最原生的方式是用定时器输入捕获功能，测量Echo引脚上升沿到下降沿的时间。但F103的定时器资源有限，而且这种单次测量方式在信号没回来时会一直死等，影响主程序的运行。工程上更常用的是用GPIO外部中断配合SysTick时间戳来做：设置Echo引脚上升沿中断，进入中断后记录当前时间；再设置下降沿中断，进入中断后计算时间差。

这里有个经验值：HC-SR04的有效测距范围一般在2cm到400cm之间，测量周期要大于60ms，否则发射的超声波会与上次回波混淆。而且模块的测量角度很窄，对着光滑墙面测的时候，反射信号可能被弹到别的方向导致测不到。我调试时拿它在桌面测，对着显示器背面就总是跳变，后来才知道是显示器表面反射太散了。

6. 通信进阶路线图：从CAN到USB，再到电机控制

基础打牢之后，很多人的下一步是往通信总线和运动控制方向走。这一步跨过去，你才真正从一个“玩开发板的”变成一个“做项目的”。

6.1 CAN通信突然连不上，先查这五个地方

CAN总线在工业控制和汽车电子里无处不在。它最显著的特点是差分信号、多主通信、带错误检测。热词里有“stm32 can通信突然连不上”，关键词是“突然”——说明系统之前是能正常通信的，后来才出的问题。

突然连不上，我最先怀疑的是终端电阻。CAN总线规范要求在总线的两端各接一个120欧姆终端电阻。这是匹配阻抗用的，用来吸收信号反射。有的开发板已经板载了120欧电阻和跳线，如果你同时用了板载电阻，又在外部额外并联了电阻，或者两个节点都开了板载电阻但中间距离很短，反射照样严重，通信就会异常。排查办法是用万用表量CANH和CANL之间的电阻，正常应该在60欧左右（两个120欧并联），如果量到120欧，说明只接了一个终端电阻。

第二查波特率是否一致。CAN的波特率由同步段、传播段、相位段1、相位段2的配置决定，不同芯片的同一个波特率值下的总线时序可能不完全一样。F103的CAN可以配置成1Mbps，但如果另一端控制器实际跑的波特率有细微偏差，通信就可能时好时坏。

第三查CANH和CANL是否接反。CAN收发器出来的信号是有极性的，CANH接CANH、CANL接CANL，接反了会导致总线错误帧一大堆。

第四查共地。差分信号理论上不要求共地，但实际系统中如果不共地，共模电压会超出收发器的容忍范围，表现就是时通时断。

第五才是查代码。如果以上四项都没问题，再看初始化顺序、过滤器配置是否把帧给过滤掉了。F103的CAN过滤器配置很容易配置错误，数据明明在总线上，但就是收不到。

6.2 用串口控制伺服电机，485总线要注意电平

工业现场的伺服电机，很多用MODBUS-RTU协议通过485总线控制。热词里“stm32控制伺服电机485”就是这个应用方向。STM32本身的USART没有485电平功能，需要一个RS485收发器芯片（比如MAX485或者SP3485）把TTL电平转成差分信号。

485通信和CAN有些相似，也是两根线（A和B），也需要终端电阻，但它的通信方式更简单粗暴：半双工、主从轮询。主机发出请求帧，从机应答。程序中只需要注意一个切换方向的问题：发送之前要把收发器的发送使能引脚（DE/RE）拉高，发完之后立刻拉低回到接收状态。

这个切换动作看似简单，实际坑很多。最常见的是切换太快，最后一个字节还没完全发送出去就切换了方向，导致数据尾帧被截断。解决办法是发送完之后等USART的发送完成标志（TC）置位，再切换方向。另一个常见问题是多个设备挂在总线上时，地址冲突、同一地址的设备互相抢总线，会导致整个网络通信乱七八糟。这些在调试时都值得提前排查。

6.3 USB设备方向：虚拟串口和HID设备

STM32F103原生带USB全速设备控制器，可以自主开发USB设备。热词里“stm32 如何做usb设备”是个大方向，但入门最常见的选择是USB虚拟串口（CDC类）和HID设备。

CDC虚拟串口的意思是：STM32插上USB线后，电脑端会识别出一个新的串口，你不需要额外接USB转TTL模块，直接在调试助手里选择这个“虚拟串口”通信就行。这个方案非常实用，相当于把USB通信包装成了串口协议，原有串口代码几乎不用改动。

HID类设备则是把STM32做成键盘、鼠标、游戏手柄之类的东西。HID的好处是免驱、即插即用，电脑端无需安装任何驱动。我做过一个用F103模拟USB键盘的demo，可以实现按下按键后自动输入一段文本。这个方向特别适合做外设类的小项目。

USB方向有个共同的坎：USB的D+和D-是高速差分信号，线一定要短、要直。如果用杜邦线飞线，信号质量差，USB枚举大概率失败——表现就是电脑根本没反应或者“无法识别的USB设备”。我当时为了调试方便，用了十几厘米的杜邦线，折腾了一整天都枚举不上，后来把线剪到5厘米以内就好了。

6.4 毕业设计热门方向：从智能台灯到两轮差速小车

每年毕业设计季节，STM32都是大热门。智能台灯、两轮差速小车、智能鱼缸这几个方向几乎年年出现。它们的共同点是：传感器采集数据、主控做逻辑、执行器做动作、屏幕做交互，整体难度适中，展示效果直观。

以两轮差速小车为例：核心是直流电机的PWM调速和编码器测速，加上PID闭环控制。F103的定时器可以同时输出多路PWM，也能用编码器接口模式直接读取正交编码信号。热词里“stm32 foc 代码”那个就更进阶了，那是无刷电机控制，涉及到Clark变换、Park变换和SVPWM，是控制领域里的深水区，建议先把PID和PWM调速吃透再碰。

智能台灯这个方向我特别喜欢推荐给新手做项目，原因是它天然就是一个完整系统：光敏传感器检测环境亮度（ADC）、人体感应模块判断是否有人（GPIO外部中断）、PWM调节LED亮度、OLED显示状态、按键切换模式。把所有基础外设串在一个真实场景里，学习效率和成就感都非常高。

7. 常见问题排查实录，帮你省掉一个月的踩坑时间

这部分内容是我实际调试中积累的“血泪史”。列出来的问题，每一个我都真实遇到过，并花了或多或少的代价才搞清楚原因。把它们放在一起，相当于给你的排查路径画了一张避雷图。

7.1 IDE和芯片包相关的坑

很多新手一碰到这些情况就开始焦虑，其实大部分都是配置层面的小问题，耐心捋一遍就能解决。芯片包安装尤其容易被忽略：换了台电脑、换了个Keil版本，设备列表是空的，工程自然建不起来。这时候不是代码的问题，是环境的问题。

7.2 调试时值和日志异常的排查思路

7.3 用Keil查看IO输出波形，不花钱的调试技巧

热词里有“keilc stm32查看io输出波形”，这其实是Keil的一个隐藏功能。在调试模式下打开“View”菜单，找到“Analysis Windows”，选择Logic Analyzer，然后添加你要观察的GPIO引脚，就能看到引脚电平随时间变化的波形。这个功能在很多场景下能替代昂贵的逻辑分析仪，至少可以做定性判断。

想用这个功能有个前提：调试接口必须是SWD或JTAG在线调试模式，仿真器要能实时读取引脚状态。操作上把光标放到要观察的引脚变量上，右键选择“Add to Logic Analyzer”。不过这里的波形是仿真器通过调试接口轮询获取的，频率太高或有严格时序要求的信号，这个方式看不了，那还是得老老实实上逻辑分析仪。便宜的逻辑分析仪几十块钱，是调试串口、I2C、SPI协议的神器，后面做项目基本人手一个。

7.4 关于巴法云和VSCode开发环境的一些补充经验

如果想把STM32和物联网云平台对接，巴法云是一个很轻量的选择。它的接入方式很简单：走MQTT协议，模组用ESP8266或者ESP32通过串口AT指令与STM32通信。STM32端只需要做好每帧AT指令的收发和解析即可。这个过程要特别注意AT指令的响应超时处理，不能一直死等板子回复，否则一旦网络卡顿，整个控制逻辑就卡死了。用状态机来解析“OK”“ERROR”这些关键字，是工业上的常规做法。

VSCode搭配PlatformIO搭建STM32开发环境，体验确实现代，文件树、智能提示、Git集成都很顺滑。但PlatformIO默认用的编译链、链接脚本和Keil的不完全一致，最典型的就是Flash和RAM的占用计算方法不同，有时会出现Keil能编译通过、PlatformIO报space不够的情况。如果你是想学习嵌入式原理，建议还是把Keil当主环境；如果你是为了代码体验和持续集成，PlatformIO也值得一试。两条路线我都走过，没有绝对的好坏，关键是你得知道自己此刻想要什么。

真正把STM32玩明白的人，都有一个共同的感受：它不是一个需要背知识的科目，而是一个需要不断“上手”的手艺。你每踩一个坑，就离它的底层机制更近一层。我当年花了整整两天才搞清楚为什么SPI读ID读到A1A1，但正因为那两天，我后来排查所有SPI设备的问题都快了很多。今天的你拿到这块STM32F103开发板，起点已经比我当年好太多——资料更全、工具更顺手、网上踩坑记录俯拾即是。接下来要做的，不过就是打开Keil，点掉那个LED灯的例程，然后赶在灯亮起来那一刻，兴奋地对自己说一句：成了。后面的路，就交给一块块外设、一行行代码、一个个深夜的小问题去铺吧。