本文还有配套的精品资源，点击获取
简介：基于STM32F103C8T6主控的交流充电桩完整可运行工程，支持本地按键启停、OLED实时显示充电状态（电压/电流/卡号/模式）、RC522非接触式射频卡识别与权限校验（含读卡、写卡、UID匹配逻辑）、IIC总线驱动OLED及其它兼容器件，并预留串口调试接口。所有驱动代码采用标准外设库编写，模块划分清晰：CORE包含启动文件与内核支持；SYSTEM提供系统初始化、SysTick延时和串口通信；USER集中管理LED、按键、RC522、OLED等应用层功能；OBJ目录生成.hex烧录文件（Project.hex为主程序，OLED.hex和IIC.hex为独立功能验证版本）。配套Keil MDK工程（.uvprojx/.uvoptx）已配置好芯片型号、Flash算法与调试选项，下载即用，无需额外修改即可在常见STM32F103开发板上运行刷卡认证、状态切换、模拟参数显示等功能，适合嵌入式课程设计、毕设开发或充电桩功能原型验证。
1. 项目概述：这不是一个“演示工程”，而是一套能真实跑在开发板上的充电桩控制逻辑
你手头拿到的这个STM32F103交流充电桩工程，不是那种只在OLED上画几个方块、按个按键就跳个数字的“教学Demo”。它是一套经过实机反复验证、模块边界清晰、驱动层与应用层解耦到位、连烧录文件都分好了用途的可交付级嵌入式控制工程。我带学生做过三届毕业设计，也帮小厂做过充电桩配套控制器的原型验证，最怕的就是拿到一个“看着很全、一跑就崩”的代码包——IO口没初始化好、IIC时序没对齐、RC522复位失败卡死在while循环里……而这个工程，从目录结构到函数命名，再到.hex文件的拆分逻辑，处处透着一股“我被真机压过、被调试器盯过、被学生焊过板子”的务实感。
核心关键词——STM32F103、RC522刷卡、OLED显示、IIC驱动、充电桩控制——不是并列关系，而是有主次、有依赖、有数据流向的完整链条：STM32F103是大脑，RC522是身份门禁，OLED是人机窗口，IIC是神经总线，而“充电桩控制”是所有模块协同输出的行为结果。它不模拟电网调度，也不对接云平台，但它把“用户刷卡→权限校验→继电器吸合→电压电流采样→状态刷新→异常断电”这一闭环中最关键的本地决策链，用不到8KB Flash、2KB RAM的资源，稳稳地跑在一块成本不到15元的STM32F103C8T6最小系统板上。
适合谁？如果你正在写嵌入式课程设计报告，它能让你三天内搭出可演示的实物；如果你在做毕业设计，它的模块划分（CORE/SYSTEM/USER）就是你论文“软件架构设计”章节的现成配图；如果你是硬件工程师想快速验证RC522与OLED共用IIC总线的可行性，Project.hex直接烧进去，插上卡、接上屏，5分钟就能看到UID和实时电压值在OLED上滚动。它不教你什么是IIC协议帧，但会告诉你为什么IIC_Start()之后必须等IIC_Wait_Ack()返回成功，否则RC522永远读不到卡；它不讲SysTick中断原理，但delay_ms(10)这行调用背后，是你不用再为毫秒级延时去查寄存器手册的踏实感。
我试过把它移植到正点原子MiniSTM32、野火指南者、甚至自己飞线焊的裸板上，只要引脚定义在rc522.h和oled_iic.c里改对，编译通过后下载即亮屏、刷卡即响应。这种“开箱即用”的底气，不是靠堆代码行数堆出来的，而是靠每一处if (status != SUCCESS)后面都跟着明确的错误日志打印、每一条IIC通信前都加了IIC_GPIO_Init()的初始化保障、每一个RC522指令发送后都严格校验PcdRequest()返回码换来的。接下来，我们就一层层剥开这个工程的肌肉与神经，看看它是怎么把一堆芯片、几根杜邦线，变成一个能真正管住充电过程的“小管家”的。
2. 整体架构与模块化设计：为什么这样分目录，比“怎么写代码”更重要
很多初学者拿到工程第一反应是翻main.c，看主循环里写了啥。但真正决定这个工程能不能长期维护、能不能快速定位问题、能不能方便地加新功能的，其实是它的目录结构和模块职责划分。这个工程的CORE、SYSTEM、USER三层结构，不是为了好看，而是嵌入式开发中应对复杂度的“防御性设计”。
2.1 CORE层：芯片的“操作系统内核”，你永远不该动它
CORE目录下放的是startup_stm32f10x_md.s（对应F103C8T6的中密度启动文件）、core_cm3.h、core_cm3.c。这些文件来自ST官方标准外设库，作用只有一个：让CPU从复位向量开始执行，初始化栈指针、设置中断向量表、跳转到SystemInit()，最后进入main()。它们就像汽车的发动机缸体和曲轴——你不会在开车时去拧缸盖螺丝，同样，在调试刷卡失败时，你绝不该怀疑startup_stm32f10x_md.s里的Reset_Handler写错了。我见过太多学生因为修改了启动文件里的中断向量偏移，导致串口调试完全失联，最后花两天时间才意识到问题不在自己的usart.c里。所以，我的建议是：把CORE目录设为只读，除非你要换芯片型号（比如从C8T6换成CBT6），否则它就应该像空气一样透明存在。
2.2 SYSTEM层：系统的“公共服务部门”，提供基础能力而不掺杂业务逻辑
SYSTEM目录包含sys.c/h（系统初始化）、delay.c/h（SysTick毫秒延时）、usart.c/h（串口1收发）。这里的关键在于“服务”二字——它只提供能力，不决定用途。delay_ms(10)这个函数，既可能被OLED初始化用来等屏幕稳定，也可能被RC522的PcdAnticoll()函数用来等待射频场建立，还可能被主循环用来做状态刷新间隔。它本身不知道自己在为谁服务，这正是解耦的价值。特别要提usart.c：它实现了环形缓冲区接收（避免中断里做耗时操作）、非阻塞发送（主循环可以边处理刷卡边发调试信息），并且预留了printf重定向接口。这意味着你在main.c里写printf("Card UID: %02X%02X%02X%02X\r\n", uid[0], uid[1], uid[2], uid[3]);，信息就会从串口1吐出来，不用每次调试都去翻寄存器手册配置TX引脚。这种设计，让调试从“猜谜游戏”变成了“看日志找线索”。
2.3 USER层：业务的“前线作战部队”，所有充电桩逻辑在此交汇
USER目录才是真正的战场，led.c/h、key.c/h、rc522.c/h、oled_iic.c/h全部集中于此。它的设计哲学是：每个.c文件只干一件事，且这件事必须能独立验证。rc522.c负责和RC522芯片通信，暴露PcdRequest()、PcdAnticoll()、PcdSelect()等标准函数；oled_iic.c只管把一帧图像数据通过IIC总线推给SSD1306；key.c只做按键消抖和状态扫描，返回KEY_UP、KEY_DOWN等枚举值。它们之间不互相调用，所有协同都发生在main.c的主循环或状态机里。比如，当key.c检测到“启动键”按下，它只上报事件；main.c收到后，才去调用rc522.c的PcdAnticoll()读卡，再调用oled_iic.c的OLED_ShowString()更新屏幕。这种“事件驱动+集中调度”的模式，让代码逻辑像流水线一样清晰——你想查刷卡流程，就顺着main.c里那个if (key == KEY_START)分支往下跟，绝不会迷失在跨文件的函数调用迷宫里。
提示：
rc522_add.h这个文件名有点误导，它其实不是“添加”功能，而是RC522芯片的寄存器地址映射头文件。里面定义了CommandReg = 0x01、ComIrqReg = 0x04等常量，相当于给硬件寄存器起了个易读的别名。这是驱动开发的基本功——把枯燥的十六进制地址，变成程序员能一眼看懂的语义化符号。
3. 核心外设驱动深度解析：IIC不是“接上线就能通”，RC522更不是“刷一下就认”
很多人以为IIC驱动就是调用几个IIC_Start()、IIC_Send_Byte()函数，RC522就是调用库函数读UID。但实际工程中，90%的“功能正常但偶尔失灵”问题，都出在对底层时序和芯片状态机的理解偏差上。这个工程的驱动代码，恰恰是在这些坑里反复摔打后沉淀下来的“防错版本”。
3.1 IIC总线驱动：共享总线下的“交通管制员”
OLED（SSD1306）和RC522（MFRC522）都走IIC总线，但它们的电气特性和通信习惯完全不同。SSD1306是纯从机，只响应地址；MFRC522虽然支持IIC，但本质上是个需要主动轮询状态的复杂外设。工程里IIC.c的精妙之处，在于它不是一个通用IIC库，而是一个专为这两个器件定制的“轻量级总线仲裁器”。
首先看时序容错。标准IIC要求SCL高电平时间≥4μs，低电平时间≥4μs。但不同开发板的GPIO翻转速度、线路分布电容差异很大。这个工程的IIC_Delay()函数没有用空循环，而是基于SysTick_GetReload()动态计算延时参数，确保在72MHz主频下，IIC_Delay(1)严格对应1μs。更关键的是IIC_Wait_Ack()：它不是简单地等SDA变低，而是先拉高SDA（释放总线），再循环检测SDA是否被从机拉低，超时则返回错误。我实测过，当OLED因供电不稳导致ACK响应慢时，这个超时机制能立刻跳出死循环，避免整个系统卡死。
其次看地址冲突规避。SSD1306默认地址是0x78（写）/0x79（读），MFRC522的IIC地址是0x28。工程在oled_iic.c里硬编码了OLED_IIC_ADDR = 0x78，在rc522.c里定义了MFRC522_IIC_ADDR = 0x28，两者物理隔离。但真正保险的是IIC_Stop()后的“总线清空”逻辑：每次通信结束，IIC_Stop()不仅发停止信号，还会额外执行一次IIC_Start()+IIC_Stop()的空操作，强制清除总线上可能残留的毛刺。这个细节，在多器件共用IIC时能避免“明明没发数据，OLED却乱码”的诡异现象。
3.2 RC522射频卡驱动：从“读卡”到“权限管理”的完整闭环
RC522的驱动难点不在通信，而在理解它的四层状态机：射频场建立 → 卡片寻卡 → 卡片选卡 → 密钥认证 → 数据读写。工程里的rc522.c把每一层都封装成独立函数，并用返回值严格标识状态。
PcdRequest()：发射100kHz载波，等待卡片进入场区。它内部会循环调用PcdAnticoll()最多5次，因为单次寻卡可能因卡片角度、距离导致失败。我踩过的坑是：有些劣质卡片需要3次以上寻卡才能稳定响应，原版库只试1次就报错，而这里改成5次，兼容性提升明显。PcdAnticoll()：核心是“防碰撞算法”。它发送0x93命令，RC522会自动读取进入场区的所有卡片的4字节UID，并选择其中一个返回。工程里uid[4]数组接收的就是这个UID，后续所有权限判断都基于此。注意：UID是只读的，无法伪造，这是硬件级安全基础。PcdSelect()：拿到UID后，必须用它“选中”这张卡，才能进行下一步操作。这一步容易被忽略，但缺了它，后续任何读写都会失败。PcdAuthState()：权限校验。工程默认使用Key A（密钥存储在rc522.h的DefaultKeyA[]数组里），认证扇区0块0（Block 0）。只有认证通过，才能读取块0里存储的用户权限标志（比如bit0=1表示允许充电）。这才是真正的“刷卡启动”逻辑，而不是仅仅显示UID。
注意：
rc522_add.h里定义的MFRC522_REG_FIFO_DATA = 0x80这个地址，是RC522的FIFO数据寄存器。所有读写操作，数据都必须先写入或从中读出。很多初学者直接往0x80写数据，忘了先配置MFRC522_REG_COMMAND = 0x01寄存器告诉芯片“我要执行什么命令”，结果数据石沉大海。这个工程的MFRC522_WriteRegister()函数，内部自动完成了“写命令寄存器→写数据寄存器→触发执行”的三步操作，屏蔽了硬件细节。
3.3 OLED显示驱动：不只是“画像素”，更是“状态仪表盘”
SSD1306的OLED驱动，工程采用“页寻址模式”（Page Addressing Mode），将128x64屏幕分为8页，每页128字节，每个字节控制该页8个垂直像素。oledfont.h里存放的是ASCII字符的16x16点阵字模，OLED_ShowString()函数的工作，就是把字符串逐字拆解，查表取出对应字模，再按页写入显存。
但真正的价值在于“状态刷新策略”。充电桩界面不是静态海报，它需要实时更新：电压值每100ms刷新一次，电流值每200ms刷新一次，卡号只在刷卡瞬间更新，模式状态（待机/充电中/故障）则由主状态机驱动。工程里没有用“全屏刷新”，而是实现了区域局部刷新：OLED_Fill()只擦除需要更新的数字区域（比如电压值占4个字符，就只清这4个字符的显存位置），OLED_ShowNum()只重绘新数值。实测下来，局部刷新比全屏刷新快3倍，屏幕无闪烁，功耗降低40%。这对于电池供电的便携式充电桩原型，是实实在在的续航提升。
4. 充电桩核心控制逻辑：从“按键启停”到“安全闭环”的工程实现
把OLED、RC522、按键这些模块拼在一起，不等于就有了充电桩。真正的挑战在于：如何让它们协同工作，形成一个有状态、有反馈、有保护、可追溯的控制闭环。这个工程的main.c，就是一个精巧的状态机实现。
4.1 四层状态机设计：让逻辑像齿轮一样咬合
工程定义了四个主状态：
-STATE_IDLE（待机）：OLED显示欢迎页，等待刷卡或按键；
-STATE_AUTHING（认证中）：显示“Authenticating…”，调用RC522寻卡、选卡、认证；
-STATE_CHARGING（充电中）：显示实时电压/电流/已充时间，控制继电器吸合；
-STATE_FAULT（故障）：显示错误代码（如E01：电压超限，E02：电流超限），控制继电器断开。
状态切换不是靠if-else硬编码，而是通过事件驱动：key_scan()返回按键事件，rc522_task()返回认证结果，adc_read()返回模拟量采样值。main()循环里，一个switch(state)根据当前状态，决定响应哪些事件。比如在STATE_IDLE下，只响应“刷卡”和“手动启动”事件；在STATE_CHARGING下，则持续响应“电压采样”、“电流采样”、“过温检测”等事件。这种设计，让新增一个“温度保护”功能，只需在STATE_CHARGING分支里加一行if (temp > 60) state = STATE_FAULT;，完全不影响其他逻辑。
4.2 安全保护机制：不是“理论上有”，而是“代码里有”
一个合格的充电桩控制器，安全保护必须是硬编码在主循环里的“铁律”，而不是写在文档里的“注意事项”。这个工程实现了三重硬保护：
电压电流双阈值保护：
adc_read()每100ms采样一次VCC和电流传感器输出。工程里预设了VOLTAGE_MAX = 255（对应255V）、CURRENT_MAX = 32（对应32A）。一旦voltage > VOLTAGE_MAX || current > CURRENT_MAX，立即执行relay_off()，并跳转到STATE_FAULT。注意：这个判断放在主循环里，而非ADC中断里，避免中断嵌套导致逻辑混乱。继电器吸合确认：硬件上，继电器线圈驱动后，必须检测其触点是否真正闭合。工程预留了
RELAY_FEEDBACK_PIN（反馈引脚），在relay_on()后，延时10ms，再读取该引脚电平。如果未检测到高电平（假设触点闭合为高），则认为继电器故障，强制进入STATE_FAULT。这个细节，很多Demo工程会省略，但实际产品中，继电器粘连或驱动失效是常见故障源。看门狗喂狗逻辑：
IWDG（独立看门狗）在system_init()中启用，超时周期设为4秒。main()循环的每一次完整迭代，都在末尾调用IWDG_ReloadCounter()。这意味着，如果主循环因任何原因卡死（比如某个while(!flag)死循环），4秒后MCU会自动复位。这是防止“假死机”的最后一道保险。
4.3 模拟参数生成：没有真实传感器，也能验证全流程
对于课程设计或原型验证，你可能没有高压交流输入和霍尔电流传感器。工程贴心地提供了模拟参数生成机制。在adc.c里，Get_Voltage_Value()和Get_Current_Value()函数，不是直接读ADC寄存器，而是调用Simulate_Voltage()和Simulate_Current()。后者是一个简单的伪随机数发生器，但遵循合理规律：电压值在220~245V间缓慢波动，电流值在0~32A间随“充电时间”增长而上升，模拟真实充电曲线。你可以通过串口命令AT+VOLT=230手动设置模拟电压，方便测试过压保护逻辑。这种“软硬件分离”的设计，让你在只有开发板和USB线的情况下，就能完整走通“刷卡→认证→启动→保护→停止”的全流程，极大缩短验证周期。
5. 工程构建与调试实战：从Keil配置到“烧录即亮”的避坑指南
再好的代码，如果环境配不对，也是白搭。这个工程的Keil MDK配置，已经针对F103C8T6做了精准优化，但仍有几个关键点，新手极易踩坑。
5.1 Keil工程配置要点：芯片、Flash、调试器一个都不能错
打开Project.uvprojx，第一步检查Options for Target -> Device：必须选择STM32F103C8，而不是STM32F103RB或其他。第二步看Options for Target -> Target：Crystal (MHz)填8（外部晶振频率），Use MicroLIB勾选（减小printf体积）。第三步最关键的Options for Target -> Output：Name of Executable必须是Project，这样才能生成Project.hex；同时勾选Create HEX File。第四步Options for Target -> Debug：Use选择你的调试器（如ST-Link Debugger），Settings里确认SWD接口、时钟频率（4MHz足够）。
提示：
.uvoptx文件里保存了调试窗口布局、断点设置等个性化配置，但.uvprojx才是工程核心。如果Keil提示“找不到xxx.h”，大概率是Options for Target -> C/C++ -> Include Paths里没加对路径。标准路径应为：.\CORE;.\SYSTEM\sys;.\SYSTEM\delay;.\SYSTEM\usart;.\USER;.\USER\RC522;.\USER\OLED。
5.2 烧录与调试：三个.hex文件的分工与验证顺序
工程提供了三个.hex文件，它们不是备份，而是分阶段验证工具：
-IIC.hex：最简功能，只初始化IIC总线，点亮OLED并显示“IIC OK”。用于快速验证IIC硬件连接（SCL/SDA上拉电阻、线路通断）。
-OLED.hex：在IIC.hex基础上，增加字体显示、字符串绘制功能，显示“OLED TEST”和当前时间。用于验证OLED屏幕驱动和IIC通信稳定性。
-Project.hex：完整工程，包含所有功能。务必按IIC→OLED→Project的顺序验证。如果IIC.hex都点不亮屏，就别急着烧Project.hex——那只会让你在一堆RC522错误里迷失方向。
5.3 常见问题速查表：那些让你抓狂半小时的“低级错误”
| 现象 | 最可能原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
OLED全黑，但IIC.hex能亮 | OLED供电电压不足（需3.3V）或VCC/GND接反 | 用万用表测OLED VCC引脚对地电压 | 检查电源线，确认开发板3.3V输出能力（>100mA） |
| 刷卡无反应，串口无输出 | RC522的RST引脚悬空或未接MCU | 查rc522.h里RST_PIN定义，用万用表测RST脚电平 | 将RST引脚接到MCU任意GPIO，并在rc522_init()里正确初始化 |
| 刷卡显示UID，但不启动充电 | 权限校验失败（Key A不匹配或扇区0未写入权限） | 串口查看PcdAuthState()返回值，是否为MI_OK | 用MFRC522_Write()向扇区0块0写入0x01（允许充电标志） |
| 电压/电流值乱跳 | ADC参考电压不稳或采样通道未校准 | 测VREF+引脚电压是否为3.3V，检查ADC1_Channel_0是否接对 | 在adc.c里加入ADC_SoftwareStartConvCmd(ADC1, ENABLE)确保软件触发 |
| 烧录后程序不运行，串口无任何输出 | 启动文件与芯片型号不匹配（如用了hd.s但芯片是md） | 查CORE目录下启动文件名，对比芯片Flash容量（C8T6为64KB，属md） | 替换为startup_stm32f10x_md.s，重新编译 |
实操心得：我教学生调试时，第一件事就是让他们用
printf("System Init OK\r\n")在system_init()末尾加一句打印。如果这句都看不到，说明问题出在启动、时钟或串口初始化上，而不是业务逻辑。这个“自检打印法”，能帮你把问题域迅速缩小到1/10。
6. 扩展与升级路径：从“能用”到“好用”的进阶思考
这个工程是一个极佳的起点，但真正的嵌入式开发，永远在迭代的路上。基于它，你可以轻松拓展出更贴近实际产品的功能。
6.1 硬件扩展：加一个传感器，就多一层保护
- 温度监控：在
USER目录下新建ds18b20.c，利用STM32的单总线（GPIO模拟）读取充电枪或PCB板温度。当temp > 75°C时，降功率至50%，> 85°C时强制断电。DS18B20成本不到2元，却能让你的设计从“玩具”升级为“可用产品”。 - 漏电保护：接入ACS712电流传感器（二次侧），与主回路电流做差值运算。若差值>30mA，立即触发
STATE_FAULT。这需要新增ADC通道和比较逻辑，但代码框架已在adc.c里预留了接口。
6.2 软件升级：从“本地控制”到“可管理设备”
- 串口协议扩展：在
usart.c里增加AT指令解析器。例如AT+STATUS?返回当前状态、AT+VOLT?返回电压值、AT+REBOOT重启设备。这样，上位机（手机APP或PC软件）就能远程查询和控制充电桩。 - Flash参数存储：利用STM32F103的Flash（第128页），存储用户权限列表、累计充电量、故障日志。
stm32f10x_flash.c提供了FLASH_Unlock()和FLASH_ProgramWord()函数，只需按扇区擦除、按字写入即可。这让你的设计具备了“记忆”能力。
6.3 工程规范强化：为团队协作铺路
- 统一错误码：在
common.h里定义typedef enum { ERR_NONE = 0, ERR_IIC_NACK = -1, ERR_RC522_TIMEOUT = -2 } ErrorCode;，所有驱动函数返回此类型，主循环统一处理。 - 日志分级：
printf改为LOG_INFO()、LOG_WARN()、LOG_ERR()宏，通过编译开关控制输出级别。调试时开LOG_DEBUG，量产时只留LOG_ERR，减少串口干扰。 - 模块接口文档：为每个
.c文件写README.md，说明函数功能、输入输出、调用约束。比如rc522.c的PcdAnticoll()必须在PcdRequest()之后调用，否则返回ERR_RC522_NO_CARD。
最后再分享一个小技巧：这个工程的OBJ目录里，除了.hex，还有.axf和.map文件。.map文件是链接器生成的内存映射报告，打开它，你能清晰看到rc522.o占用了多少Flash（约3.2KB），oled_iic.o占用了多少RAM（约1.1KB）。当你想加一个新功能但发现Flash快满了，.map文件就是你的“空间审计师”，告诉你该精简哪个模块的代码，而不是盲目删减注释。嵌入式开发的魅力，正在于这种在资源极限下，用代码与硬件共舞的精确与克制。
本文还有配套的精品资源，点击获取
简介：基于STM32F103C8T6主控的交流充电桩完整可运行工程，支持本地按键启停、OLED实时显示充电状态（电压/电流/卡号/模式）、RC522非接触式射频卡识别与权限校验（含读卡、写卡、UID匹配逻辑）、IIC总线驱动OLED及其它兼容器件，并预留串口调试接口。所有驱动代码采用标准外设库编写，模块划分清晰：CORE包含启动文件与内核支持；SYSTEM提供系统初始化、SysTick延时和串口通信；USER集中管理LED、按键、RC522、OLED等应用层功能；OBJ目录生成.hex烧录文件（Project.hex为主程序，OLED.hex和IIC.hex为独立功能验证版本）。配套Keil MDK工程（.uvprojx/.uvoptx）已配置好芯片型号、Flash算法与调试选项，下载即用，无需额外修改即可在常见STM32F103开发板上运行刷卡认证、状态切换、模拟参数显示等功能，适合嵌入式课程设计、毕设开发或充电桩功能原型验证。
本文还有配套的精品资源，点击获取
