企业官网建设流程全解析

1. 项目创建前的思路整理

1.1 为什么“创建项目”这一步常常劝退新手

我见过不少初次接触STM32的开发者，其实学习热情挺高，也买了开发板和数据手册，结果卡在了第一步——不知道怎么把一个空工程搭起来。有的人下载了官方的例程包，打开里面的工程发现各种文件混杂在一起，想看看到底谁在调用谁，结果越看越晕。有的人直接在编译环境里新建一个文件开始写代码，写完编译才发现连最基本的启动文件都没有，报错几百条，根本无从下手。

说白了，STM32的项目创建本身就是一个独立的技能点。它不像写一个普通的C程序那样，新建一个.c文件就能跑。芯片上电后要经过启动文件引导、时钟初始化、外设寄存器配置、中断服务函数链接等一系列动作，这些都需要在工程里提前安排妥当。如果对工程的结构没有一个整体概念，后面写再多驱动代码都是空中楼阁。

这篇文章就打算从实际开发的角度出发，把创建STM32工程的完整流程拆开揉碎，讲清楚每一步在干什么、为什么这么干，以及哪些地方容易踩坑。不管你是刚拿到开发板的新手，还是之前只玩过标准库但想转用CubeMX生成工程的老手，这份流程都值得完整过一遍。

1.2 先搞清楚三类工具之间的关系

在动手创建工程之前，我建议你先花十分钟把工具链的关系弄清楚。STM32开发环境涉及几个层面的东西：

• 芯片厂商配套的图形配置工具：比如STM32CubeMX，它用来可视化地选择芯片型号、配置时钟树、配置引脚功能，最后自动生成一个基础工程。
• 编译集成环境：比如Keil MDK、STM32CubeIDE，或者基于GCC的工具链。CubeMX生成的是源文件和工程骨架，它本身不能编译代码。
• 固件库：这层是芯片厂商提供的驱动代码，分HAL库和LL库两种风格。HAL库偏抽象封装、代码冗余一点但好写；LL库偏底层操作、代码精简但要求你自己更懂寄存器。

很多人一开始就是被这三者的关系搞晕了。有人以为装了Keil就可以直接敲代码，有人以为CubeMX能替代Keil，还有人不知道固件库到底要不要手动添加。实际上一个标准流程是：先用CubeMX根据你的芯片型号生成一个带好GPIO、时钟、外设配置的工程，再用Keil（或者CubeIDE）打开这个工程，编写业务逻辑，最后编译下载。

1.3 本次创建工程的目标设定

为了让这整个过程有一个可以验证的终点，我们设定一个最经典也最容易排查的目标：创建一个基于HAL库的STM32工程，初始化系统时钟，配置一个GPIO输出引脚，让开发板上的LED灯周期性地闪烁。

这个目标虽然简单，但它覆盖了项目创建的所有关键环节：芯片选择、时钟初始化、引脚配置、工程生成、代码编写、编译下载、硬件验证。只要这条路走通了，后面做串口、I2C、ADC之类的功能无非就是在这个工程骨架上继续加扣件，思路完全一样。

2. 环境准备与工具选型

2.1 选择编译环境：为什么优先推荐MDK

编译环境的选择，其实直接影响你后面查阅资料和排坑的效率。我个人的建议是：做主流程开发使用Keil MDK，理由非常简单——十几年积累下来的中文教程数量是其他工具没法比的。你任何一步卡住了，搜出来的答案大概率都是MDK操作界面上的截图。虽然MDK的代码编辑体验跟VS Code这类现代编辑器没法比，但它在ARM开发领域的生态地位短时间内不会被替代。

如果你是纯粹的新手，我甚至不建议一上来就折腾开源工具链。GCC + Makefile + VS Code这套组合本身需要你理解编译器的调用过程、链接脚本的机制，这些属于进阶知识。把这一堆工具链完全理解后再开始写业务代码，学习曲线太陡了。先让LED亮起来，建立信心，后面再考虑是否迁移环境，这个顺序更合理。

MDK的安装过程网上已经有海量教程，这里只说三个容易出问题的点：

• 安装路径不要带中文和空格，后续工程路径也建议全英文，否则编译时偶尔会冒出一些难以定位的奇怪错误。
• 版本选择上，5.x和6.x编译器在编译HAL库时差别不大，但如果你需要在老项目上改动代码，版本兼容性要提前确认。
• 安装完成后第一件事是检查是否自动识别了你的芯片型号对应的器件库，没有的话需要单独下载安装。

2.2 固件库版本：直接用HAL库

在我接触过的项目里，老工程师用标准库的还挺多，尤其是51转过来的那批人，习惯直接用寄存器操作，觉得HAL库太绕。但从当前各方权衡来看，HAL库已经是大势所趋。芯片厂商把重点都放到HAL库和LL库的更新上，标准库早已停止维护。你可以理解为标准库是手写情书，HAL库是发微信消息——前者更有仪式感和掌控感，但后者是当下大家沟通的主流方式。

HAL库的哲学是把寄存器操作封装成一系列API函数。初始化一个外设，你只需要填充一个配置结构体，调用对应的初始化函数，底层发生了什么不用你操心。代价是代码量变大，执行效率有微小损失，但对于绝大多数应用场景，这点损失完全可以忽略。

我个人的建议很直接：新项目一律用HAL库，除非你的项目对时序要求极其苛刻，否则不要跟趋势对着干。

2.3 CubeMX在工程创建中的角色

CubeMX是全流程的起点，它的功能可以概括为一句话：把你在图形界面上的所有配置操作生成对应的C代码。

它的优势不在于省去你写结构体的时间，而在于两点：一是芯片引脚冲突检测，你在配置GPIO功能时，如果两个功能复用同一个引脚，它会直接报错；二是时钟树计算，你不需要自己翻数据手册算分频系数，只要选定外部晶振频率和目标主频，它会自动算出各总线时钟。

创建工程前的配置工作基本都集中在这三个页面：Pinout & Configuration（引脚功能配置）、Clock Configuration（时钟配置）、Project Manager（工程管理配置）。

3. 从CubeMX到第一个可运行的工程

3.1 选择芯片型号的细节

打开CubeMX的第一步是选择芯片型号。这里有个新手经常遇到的问题——芯片后缀的封装编号太多了，不知道选哪个。

以某款开发板上常用的芯片为例，它的完整型号编号结构一般包括几个部分：内核型号、RAM和Flash容量等级、封装形式、温度等级。选型时最容易犯的错误是只看了“STM32F4”这个大系列名就动手，结果生成的工程跟自己手上的芯片配置对不上，烧录时有各种无法解释的诡异现象。

一个实用的做法是：把开发板背面丝印上的完整型号抄下来，直接在搜索框里输入。比如针脚数量相近的两个型号，引脚完全兼容但内存大小不同，选错了虽然工程能编译，但下载到芯片后可能因为容量超限导致运行异常。

当然，CubeMX也允许你在没有具体芯片型号时按系列搜索，比如查所有STM32F407系列，然后下拉列表中会列出所有型号供你挑选。选的时候对照开发板的丝印最靠谱。

3.2 引脚与时钟配置实操

选完芯片后，进入主界面。左侧是芯片的引脚预览图，右侧是功能列表。我们这次的目标是点亮LED，所以先想清楚一件事：LED接在哪个引脚上。

不同开发板上的LED接法各不相同，有的接PA5，有的接PC13，还有的通过排阵转接。在没法确认的情况下，用万用表顺着LED的电路走一遍，找到它连到MCU的哪个引脚，或者查阅你手上开发板附带的原理图，这是最稳妥的办法。这里我们假设LED接在某个GPIO引脚上，比如PC13，配置方式一样。

在引脚预览图中直接点击PC13这个引脚，从弹出的功能菜单里选择GPIO_Output，这就完成了引脚功能的设定。接下来在右侧功能列表里展开System Core以下选项，找到对应刚才配置的GPIO口，把输出电平初始值设为高或低，这里取决于你的LED是“低电平点亮”还是“高电平点亮”，对照原理图选就行。

时钟配置的页面看起来很复杂，但CubeMX已经帮你做了大部分计算。如果你用的是板载8MHz高速晶振，就把HSE那里选为Crystal/Ceramic Resonator，输入8，然后在上面的PLL配置里把目标主频填到你想用的频率，点击回车，软件会自动算好分频倍频系数。如果你没接晶振，直接保持HSI默认也可以，LED闪烁这个程度的需求对时钟精度完全没有压力。

3.3 工程管理配置

生成代码之前还有最后一块配置，很多人忽略这里的细节，导致工程生成后烧录时找不着目标芯片。

在Project Manager页面里的第二项Linker Settings中，你会看到Flash大小和RAM大小的默认值。这里的默认值是从你选择的芯片型号里自动带出来的，正常情况下不用改。但如果你用的是某个特定产量分级的芯片，注意核对一下容量跟实际是否一致。

更重要的是第三项MCU Settings中关于调试接口的配置。CubeMX默认会开启串行下载接口（如SWD），这个配置在正常调试时保持开启就好。但如果你自己画板子，为了把调试引脚复用成普通GPIO而关闭了调试接口，就得确认你还有别的途径下载程序。这个坑和配置没关系，属于硬件设计层面的上下文问题，但在CubeMX里你会第一次意识到这个选项的存在。

工程管理里还需要指定一个工程名字和保存路径，路径最好不要有中文，工程名建议用英文描述项目内容，比如led_demo。下面那个Toolchain/IDE下拉框是关键，你要用它告诉CubeMX你要为哪个环境生成工程。选MDK-ARM的话，它会对应输出一个led_demo.uvprojx工程文件；选STM32CubeIDE的话，它输出的是一个.project工程目录。根据不同环境下拉选择对应的选项，版本号选个主流版本就行，兼容性通常不会有问题。

3.4 代码生成选项的参数含义

在Project Manager页面的代码生成器相关选项卡里，有几个选项值得仔细说一下：

• Copy only necessary library files这个选项的意思是只把用到的HAL库模块拷贝到工程里。既然是点亮LED，我们只需要GPIO模块和基础的时钟模块。勾上它，生成的工程就会精简很多，文件夹里的文件数量少一大截，理解起来更省力。
• Generate peripheral initialization as a pair of .c/.h files per peripheral能让每个外设的初始化和配置单独生成一对.c/.h文件。我建议勾上，尤其当你后需开始写多个外设驱动时，模块化程度会高很多，找一个配置函数的位置比在巨大的main.c里翻要舒坦得多。
• Generate Under Root和Use previous settings这些选项理解成本低，按默认来就好，它们不影响工程核心结构。

3.5 生成并打开工程

以上配置完成，点击右上角的Generate Code按钮，CubeMX会弹出生成进度条，等待它跑完即可。生成的目录结构大致如下：

led_demo/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ ├── gpio.h │ │ └── stm32f4xx_it.h │ ├── Src/ │ │ ├── main.c │ │ ├── gpio.c │ │ ├── stm32f4xx_hal_msp.c │ │ └── stm32f4xx_it.c │ └── Startup/ │ └── startup_stm32f407xx.s ├── Drivers/ │ ├── CMSIS/ │ └── STM32F4xx_HAL_Driver/ │ ├── Inc/ │ └── Src/ ├── led_demo.uvprojx └── led_demo.ioc

用Keil打开工程文件，你会注意到CubeMX已经替你生成了SystemClock_Config()函数，并且已经在main()函数的开头被调用了。还生成了GPIO引脚的初始化函数，同样已经被调用。这就是官方推荐的开发模式：CubeMX负责工程配置代码生成，你只需要在USER CODE BEGIN的标记注释中间添加自己的业务逻辑。这个标记注释区域，在CubeMX后续重新生成代码的时候会被保留下来，不会因为重新生成而弄丢你自己的代码。

4. 工程内部结构深度解析

4.1 启动文件在干什么

很多初学者第一次打开工程，看到那个以.s结尾的汇编文件，往往陷入长时间的沉默。我强烈建议你不要绕开它，哪怕不细读代码，也要理解它的作用。这关系到你对整个工程运转逻辑的整体认知。

启动文件本质上是被执行的第一段代码。芯片上电后，硬件电路先把PC寄存器指向Flash的起始地址，从这个地址拿到一个偏移表的值，这个值其实是初始的栈顶地址。启动文件的任务包括：建立中断向量表、初始化堆栈空间和清零BSS段、调用SystemInit()为时钟初始化前置条件、最后跳转到main()函数。

你可以类比成：启动文件就是一场话剧开幕前的暗场换景。观众进场看到的只是舞台灯光亮起的那一刻，但幕布后面的布景搬运、灯光调试，都是在开场前无声完成的。

在断点调试的时候，如果你单步复位然后——对——你总会被卡在启动文件里。从启动文件开始单步走，能帮你看清楚代码是怎么一步步跳到主函数的。

4.2 HAL库驱动的调用关系

生成代码里的HAL库驱动目录大得吓人，几百上千个文件，但实际编译时只有很小一部分参与进来。这要归功于HAL库那套很严谨的头文件包含关系。

打开stm32f4xx.h，你会看到一个核心宏定义：STM32F407xx这类芯片型号宏。这个宏决定了整个固件库编译时包含哪些外设的定义和寄存器地址映射。再往上追踪，编译器的全局宏定义里已经提前把这个芯片型号宏加入进来了，所以在编译的一开始，芯片类型的条件编译分支就已确定，不会出现A系列芯片的代码参与B系列芯片编译的情况。

使用HAL库的用户代码里会包含stm32f4xx_hal.h这个总入口头文件。这个总头文件会根据有没有定义某个名为HAL_GPIO_MODULE_ENABLED的宏来决定要不要包含stm32f4xx_hal_gpio.h。这个宏是哪来的？回溯到stm32f4xx_hal_conf.h，这个文件对每个外设都有一行注释掉或者打开的宏定义。CubeMX生成工程时只会把用到的外设对应行保留打开状态，其它一律注释掉。你完全不需要人工切换开关，但这种编译裁剪机制的巧妙之处值得记住。

4.3 main.c中用户代码区间的用途

用CubeMX生成代码后，main.c里会有大量注释标记，例如：

/* USER CODE BEGIN 1 */ /* USER CODE END 1 */

这些标记在官方文档中被称为“用户代码段”，它们不是普通的注释——CubeMX在后序每次重新生成代码时，都会扫描这些标记段，把它识别为“你已经占有的领地”。你在标记之间写的代码会被完整保留，标记之外的代码则会被重新生成覆盖。

所以强烈建议：写业务代码时，如果业务逻辑属于外设配置或者初始化之后的处理流程，统统放在这些标记区间内。这养成的是一种工作习惯，让你在后续继续用CubeMX调整外设配置时不会因为重新生成代码而丢东西。

我个人的习惯是，在USER CODE BEGIN 0这一区间内做区块注释分隔线，后面放函数声明；在USER CODE BEGIN 4区间内放中断回调函数和用户自定义函数。不要在main函数外的空白处随意添加全局变量和函数，等CubeMX一刷新代码，这些内容会被扫得干干净净，到时候哭都来不及。

4.4 编译输出与烧录文件

写完代码进行编译之后，Keil的Output窗口会显示编译状态，关键信息是编译完成的情况与“烧录镜像文件生成完毕”类似的信息。生成的HEX文件或者BIN文件会在工程目录下的Objects或Build文件夹里。烧录时就选择这个编译产物。

这种文件格式就是把含有地址信息的汇编指令打包成一套文本数据，下载器按照地址信息把内容写入Flash。这也解释了为什么烧录时要求的芯片型号必须匹配——不同型号芯片的Flash起始地址和容量不一样，烧录时校验不过就会报错。

5. LED闪烁的代码实现与调试记录

5.1 最小可执行的用户代码

生成工程的默认状态下，while(1)循环里是空的，你需要在USER CODE BEGIN WHILE和USER CODE END WHILE之间添加自己的业务代码。在这里我们实现一个最原始的软件延时闪烁：

/* USER CODE BEGIN WHILE */ while (1) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); HAL_Delay(500); HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); HAL_Delay(500); /* USER CODE END WHILE */ /* USER CODE BEGIN 3 */ }

关于LED_GPIO_Port和LED_Pin这两个宏，在CubeMX生成的头文件里已经定义好了。以PC13为例，它们对应的是GPIOC和GPIO_PIN_13。这里我故意用CubeMX生成的宏名称而不是寄存器名，是为了让你养成“使用BSP层抽象”的思维习惯。后续你更换了引脚接线，只需要在CubeMX里改动配置，重新生成代码，这两个宏会自动跟着变化，你的主函数逻辑完全不用改。

HAL_Delay(500)使用的是Systick中断还是其他时间基准，取决于你在CubeMX里对时间基准源的选择。默认情况下HAL库使用Systick作为时间基准，这个延时函数在系统时钟正确配置的前提下，精度足够应对LED闪烁这类需求。

5.2 编译阶段的三个常见错误

编译成功是最理想的状态，但如果你的配置有误，最常见的错误基本集中在以下三类：

第一类是在启动文件或Linker配置环节出问题。典型症状是提示找不到某类芯片型号的启动文件，或者Flash容量与启动文件的向量表长度不匹配。这类问题在你手动移植工程时特别多，用CubeMX自动生成时反而不容易出现。

第二类是头文件路径缺失。打开工程设置里的C/C++选项卡，你会看到编译器搜索头文件的路径列表。CubeMX生成的这个列表是经过精心梳理的，但如果你自己手动添加了第三方库的目录忘记加进路径，就会出现找不到某个头文件的报错。不要犹豫，直接去Options for Target -> C/C++ -> Include Paths里检查。

第三类是宏定义冲突。这通常发生在你手动修改了标准库头文件里某类型定义，而HAL库的代码没有跟着更新时。解决办法很简单，删除你的手动修改，让固件库保持一致。

5.3 烧录时的目标芯片配置

编译成功只是通往目标的一半，烧录又是一道关卡。Keil里烧录相关的设置在Options for Target -> Debug选项卡里。

你需要选择具体的调试下载器型号。常见的下载器会提供两种模式选择，一种是调试模式，一种是下载模式。每次烧录代码后，如果复位运行配置正确，LED应当立即开始闪烁。

这里有一个值得反复强调的经验：如果你发现烧录完成后程序没有跑起来，先把接线、复位引脚和启动模式确认一遍，然后再看是否把Reset and Run选上了。这个选项的含义是烧录完成后自动复位芯片开始运行程序，很多开发板的默认配置没勾这个选项，导致烧录后要手动按一下复位键程序才跑。虽然不勾也不影响实际使用，但每次都要按一下复位键，实在太影响调试节奏了。

5.4 从闪烁开始，把整个链路摸熟

第一个LED亮起来之后，你其实已经完成了一次完整的从工程创建到硬件验证的闭环。这个闭环的价值怎么强调都不为过——它证明了你这块开发板、这条USB线、这个下载器、这台电脑上的所有软件配置和这个工程文件之间是一条通畅的链路。

建议在LED亮起之后不要急着关掉工程。花几分钟把工程结构熟悉一遍，看看各个目录里都放了什么，在Keil的Project窗口里展开每个分组，点开几个关键源文件看看内容。我认识很多人用了STM32很久，但从来没打开过stm32f4xx_hal_msp.c这个文件，也不知道里面对引脚复用、时钟使能做了什么操作。等到项目出现问题的时候再来补课，代价就大了。

6. 常见问题与排查技巧实录

6.1 编译通过但开发板无反应

这是新手最常遇到的情况，遇到不要慌张。排查顺序我的个人习惯是：

首先用万用表量一下开发板的电源指示灯是否正常亮起，电源没到位一切免谈。然后量一下芯片VDD引脚的电压是否在正常范围。再检查下载器与开发板的连接，如果你用的下载器，它有状态指示灯，但不同品牌表示逻辑可能不同。接下来看Keil在烧录后是否提示成功，如果提示烧录成功，说明硬件链路基本没问题，问题大概率出在引脚配置跟LED实际接入位置不一致上。

说到引脚不一致这个问题，我有一次亲身经历非常有代表性。某次画好的板子回来后，LED原理图上接的是PA4，但底层的封装库画错了，PCB实际走线连接到的是PA5。烧完程序后LED死活不亮，排查了整整一个下午才发现问题出在PCB上而不是代码里。所以遇到LED不亮，强烈建议先看原理图再核对PCB走线，最后才是怀疑代码——把这个顺序反过来的代价，我已经替你付过了。

6.2 芯片锁死无法下载

这个问题的场景是：你烧录了一个程序，其中把某几个引脚初始化成了普通GPIO输出，并且恰好这几个引脚包含了串行调试时钟和数据线，然后你发现下次连接下载器时怎么都连不上芯片了。

解决这个问题的核心思路是让芯片在启动时不执行你的用户程序，从而恢复调试接口的功能。操作办法是：按住开发板上的复位键，点击Keil的下载按钮，在进度条出现瞬间松开复位键。这个时序很玄学，多试几次就能找到感觉。有些下载器在物理上支持给目标芯片单独断电，配合复位时序操作更稳妥。

这种问题靠CubeMX就能很大程度上规避：在GPIO配置界面，如果你要把调试口复用成普通IO，软件会弹出一个警告提示你正在删除调试接口。新手看到警告不要慌，也不要直接忽略。如果只是调试阶段，建议保留调试接口；如果你确实需要释放引脚且量产板不再需要调试，再考虑关掉。

6.3 烧录时报Flash校验错误

很多看起来像Flash硬件问题的校验错误，实际原因是芯片型号选错了。你手头芯片的实际Flash容量是512KB，但在Keil的烧录算法里配置成了256KB。烧录算法有人在尝试写入超出Flash末尾的地址时，芯片会拒绝写入并返回校验错误。

还有一种情况是你手动改了Flash的烧录起始地址，比如为了做Bootloader，把用户程序起始地址设到了偏移量。但如果你的中断向量表没有同步重映射，芯片上电后从哪里运行自然就乱了套。

对照检查顺序：确认芯片型号、确认烧录算法、确认调试接口开启、确认复位模式。这几项都没问题，Flash校验错误基本就没理由出现。

6.4 电流消耗异常大

新增工程后，有时候会莫名其妙感觉到芯片发热厉害。这通常和没有正确配置GPIO的上下拉状态有关。比如你配置了一个引脚为输出模式，但没设置默认电平，上电后它可能输出一个不确定的电平，恰好外部电路对这个引脚输入了冲突电平，就会形成大电流环路。

另外，如果你用CubeMX生成工程时使能了所有外设的时钟，但代码里并没有使用它们，功耗自然比预期高。功耗是从项目创建第一天就要留意的指标，跟后面是否做低功耗优化无关——千万别让功耗问题恶化到变成硬件故障才回头查。

7. 从项目创建到工程管理的几个习惯

7.1 目录结构的命名与归档

工程创建这件事，在单文件学习阶段看不出多大差异，但一旦进入正式项目，文件组织混乱会导致灾难。我建议从第一个工程起就养成目录归档的习惯。

CubeMX生成的结构已经比较合理，但你可以在这个基础上进一步组织：Core下分Src、Inc、Startup；Drivers下分CMSIS和HAL_Driver；自己写的驱动模块单独放一个BSP或App目录，和厂商固件库明确区分。这样一来，代码审计、他人接手、版本管理都会舒服很多。

7.2 版本管理从第一个可运行版本开始

有些开发者觉得“版本管理是大项目的事，我先做出来再说”。这个观点在日常学习和刚起步的小项目里害人最深。即使是一个人写一个很小的演示项目，Git仓库从第一个LED亮起的版本建立都不算早。

创建工程后第一件事就是把CubeMX生成的原始代码初始化成Git仓库，然后提交一次。后续每次你改了什么功能、解决了什么问题，都有记录可查。这个习惯让我在项目出问题回溯时省了大量的脑力——我不用靠记忆去猜“上一版这里是不是没改”，直接查看提交记录一清二楚。

7.3 工程文件与CubeMX配置文件的同步

最后提醒一件事：.ioc文件是CubeMX的配置存档，这个文件虽小，但它包含了整个工程的引脚配置、时钟配置、外设配置的全部信息。把这个文件跟源码一起放进版本管理，是工程管理的基础操作。

很多人维护代码时只提交源码，等过了一段时间需要修改引脚配置时，发现手头根本没有当初的CubeMX配置，只好对照代码一个个反推。这种痛苦，体验过一次就再也不会忘记了。

8. 写在最后的一些个人体会

回头看我第一次创建STM32工程的过程，那真是踩坑踩得毫无章法。当时并不知道有CubeMX这种东西，全靠手动从官方例程里东拼西凑地复制源文件，一路配一路报错，用了整整一个周末才让板子上的LED闪起来。现在有了CubeMX这个利器，创建工程的成本已经降得很低，但理解工程内部逻辑的习惯仍然不能丢。

我的体会是，创建工程这件事本身不算难，难的是通过这个流程理解整个芯片的工作框架。时钟树是怎么组织的，外设时钟是怎样使能的，引脚复用和GPIO配置之间是什么关系，中断服务函数怎么被登记的，这些知识没有一次真正的项目创建经历打底，光看书是完全体会不到的。

建议拿到开发板之后，不要急着把例程直接烧进去看效果。用CubeMX从头到尾走一遍这个流程，自己生成一个空工程，自己接好LED，自己写下第一行闪烁代码。这个过程花不了多少时间，但它帮你建立起来的概念模型，会在未来很长一段时间里陪你走完各种复杂项目。