简介：这个KEIL5工程专为STM32F103ZET6芯片设计，实现CAN控制器纯软件回环通信验证——不依赖外部CAN收发器或第二块板子，直接在芯片内部完成发送与接收闭环。工程采用标准外设库结构，SYSTEM目录负责系统初始化和毫秒级延时，HARDWARE目录下封装了CAN初始化、发送、接收及状态查询函数，同时集成USART串口打印用于实时观察帧收发结果，LCD和KEY模块保留接口便于后续功能扩展。代码包含main.c主流程调度、can.c核心驱动逻辑、delay.c高精度延时、sys.c系统配置，以及标准启动文件startup_stm32f10x_hd.s和链接脚本。配套readme.txt说明编译步骤与调试要点，Objects和Listings目录自动生成编译中间文件，.uvprojx和.uvguix.admin支持KEIL5一键打开即用。所有源码已通过完整编译，输出可执行的.axf、.hex和.htm调试信息文件，还提供stm32_simulator.py脚本辅助仿真验证。适合嵌入式初学者快速掌握CAN寄存器配置、中断处理流程和回环模式调试方法，也适用于MCU外设功能自检与实时通信基础验证。
1. 项目概述：为什么CAN回环测试是嵌入式工程师的“必修课”
刚接触STM32 CAN外设的朋友，十有八九会在第一步卡住：接好硬件，烧进程序，串口却始终没打印出“接收成功”——到底是线没接对？收发器坏了？还是CAN波特率算错了？我带过不少应届生做毕业设计，他们花三天排查物理层问题，最后发现只是把CAN_RX和CAN_TX引脚焊反了。这种低级错误背后，其实是缺乏一个“隔离变量”的调试起点。而CAN控制器内部回环（Loopback Mode）就是这个起点：它把发送出去的数据帧，不经过物理总线、不经过收发器芯片、不依赖任何外部硬件，直接在CAN控制器内部打个弯，原封不动送回接收FIFO。你看到的“收到一帧”，不是从另一块板子发来的，而是自己刚发出去的“影子”。这就像给CAN外设装了个单向玻璃——你能清楚看见它内部每个寄存器怎么被写入、状态位如何翻转、中断何时触发，而完全不用操心外部线路是否可靠。
这个工程专为STM32F103ZET6打造，核心价值就四个字：免硬件验证。关键词里反复出现的“STM32 CAN回环”“KEIL5工程”“CAN驱动例程”，说的正是这件事——它不是一个炫技的完整通信系统，而是一把精准的手术刀，专门用来解剖CAN控制器的工作机理。你不需要买TJA1050收发器，不需要准备两块开发板，甚至不需要焊接一根杜邦线。只要一块带SWD接口的STM32F103ZET6最小系统板（比如正点原子或野火的战舰/指南者），用ST-Link连上KEIL5，点一下编译下载，就能立刻看到串口输出“TX OK → RX OK → ID:0x123, Data:01 02 03 04…”这样的实时日志。它把抽象的CAN协议栈，压缩成可触摸、可打断点、可逐行观察的C代码。SYSTEM目录下的delay.c提供微秒级延时，这是配置CAN波特率时计算BS1/BS2分频系数的基础；HARDWARE/can.c里每一行寄存器操作，都对应着参考手册第22章CAN控制器的状态机图；而USART串口打印，则是你与芯片之间的翻译官，把二进制的CAN帧ID、DLC、数据域，转化成人类能读懂的十六进制字符串。这不是一个拿来即用的产品级工程，而是一个“可拆解的教具”——所有模块边界清晰，所有函数职责单一，所有配置项都有注释说明计算依据。哪怕你是第一次听说“同步段”“传播段”这些术语，也能通过修改can.c里的CAN_BTR寄存器值，亲眼看到波特率变化如何影响接收成功率。它解决的不是“怎么让两台设备通信”，而是“怎么确认我的CAN外设真的活了”。
2. 整体架构与设计思路：为什么选择标准外设库而非HAL
拿到这个工程，第一眼看到的是熟悉的目录结构：SYSTEM、HARDWARE、CORE、USER。这种组织方式不是为了好看，而是源于十多年嵌入式开发中踩出的一条血路。很多新手一上来就奔着HAL库去，觉得“高级封装=省事”，结果调试时一头雾水——某个CAN接收中断没触发，翻遍HAL_CAN_Receive_IT()源码，发现它底层调用了__HAL_CAN_ENABLE_IT()，而这个宏又展开成一堆位操作，中间还夹着__HAL_CAN_GET_FLAG()的状态轮询。当问题出现在硬件初始化阶段时，你根本不知道该在HAL_CAN_Init()里打断点，还是在HAL_CAN_MspInit()里查GPIO配置。而标准外设库（SPL）不同，它像一本摊开的说明书：CAN_DeInit()就是把CAN寄存器全清零，CAN_Init()就是按顺序往CAN_BTR、CAN_MCR等寄存器里填数值，CAN_Transmit()就是往发送邮箱写数据再置位请求位。没有中间商赚差价，没有抽象层遮蔽细节。这个工程坚持用SPL，核心考量就三点：可追溯性、可教学性、可移植性。
先说可追溯性。当你在KEIL5里按F12跳转到CAN_Init()函数，看到的是实实在在的寄存器地址操作：
CAN->MCR &= ~CAN_MCR_SLEEP; // 退出睡眠模式
CAN->MCR |= CAN_MCR_INRQ; // 请求初始化
while((CAN->MSR & CAN_MSR_INAK) != CAN_MSR_INAK); // 等待初始化确认
CAN->BTR = (uint32_t)(CAN_BTR_SJW | CAN_BTR_TS2 | CAN_BTR_TS1 | CAN_BTR_BRP);
每一行都能在《STM32F103xx参考手册》第22.5节找到对应描述。而HAL库里类似的逻辑被封装在几十层函数调用之下，初学者容易迷失在API海洋里。再说可教学性。这个工程的can.c文件只有不到300行，但涵盖了CAN控制器初始化、发送、接收、状态查询四大核心功能。其中初始化部分，重点处理了三个关键寄存器：MCR（主控制寄存器）、BTR（位定时寄存器）、IER（中断使能寄存器）。MCR的CAN_MCR_LOOPBACK位必须置1才能开启回环模式，这是整个工程的基石；BTR的配置则直接决定波特率精度，我们采用经典的8MHz晶振+500kbps方案，计算过程如下：目标波特率500kbps，CAN时钟频率为APB1总线频率（通常为36MHz），时间量子数TQ = 1 / (波特率 × TQ) = 1 / (500000 × 20ns) = 100。根据公式TQ = (TS1 + 1) + (TS2 + 1) + 1，取TS1=5、TS2=2，则BS1=5、BS2=2，剩余分频系数BRP = (36MHz / 500kbps) / 100 - 1 = 7。最终BTR值为0x001C0007。这些计算细节全部写在can.c的注释里，而不是藏在HAL库的magic number里。最后是可移植性。SPL的寄存器定义与芯片手册严格对齐，当你需要把这套回环测试迁移到STM32F4系列时，只需替换启动文件和链接脚本，CAN初始化逻辑几乎不用改——因为F4的CAN控制器寄存器布局与F1高度兼容。而HAL库的移植往往意味着重写整个外设初始化流程。所以，这个工程没选HAL，不是因为它落后，而是因为它更“透明”。它强迫你直面硬件本质，而这恰恰是嵌入式工程师的核心竞争力。
3. 核心细节解析：回环模式下的寄存器配置与状态机流转
CAN控制器的内部回环模式，本质上是对硬件状态机的一次精准操控。它不像普通通信那样经历“发送→总线传输→接收”的物理路径，而是将发送邮箱（TxMailbox）与接收FIFO（RxMailbox）在逻辑上短接。要理解这个过程，必须拆解三个关键寄存器的操作序列：MCR、MSR和TSR。很多人以为只要设置CAN_MCR_LOOPBACK=1就万事大吉，结果发现接收中断死活不触发——问题往往出在状态机没有进入正确的运行阶段。
首先看MCR（主控制寄存器）。它的bit0（INRQ）是初始化请求位，bit1（SLEEP）是睡眠模式位，bit7（LOOPBACK）是回环使能位。正确配置顺序必须是：先清SLEEP位退出睡眠，再置INRQ位请求初始化，等待MSR寄存器的INAK位（初始化确认位）变为1，此时CAN控制器才真正进入初始化模式；接着配置BTR寄存器设定波特率；最后清除INRQ位并置LOOPBACK位，同时确保CAN_MCR_ABOM（自动离线管理）和CAN_MCR_AWUM（自动唤醒）为0，避免意外状态切换。这个顺序不能颠倒，否则MSR会一直卡在CAN_MSR_INAK=0，导致后续配置无效。我在调试初期就栽在这里：把LOOPBACK位和INRQ位同时置1，结果CAN控制器永远停在初始化模式，接收FIFO永远空。
然后是MSR（主状态寄存器）。它像一面镜子，实时反映CAN控制器的健康状况。回环测试中最关键的两个位是CAN_MSR_INAK（初始化确认）和CAN_MSR_SLAK（睡眠确认）。前者为1表示已进入初始化模式，后者为1表示处于睡眠模式。正常回环运行时，CAN_MSR_INAK必须为0（非初始化），CAN_MSR_SLAK必须为0（非睡眠），且CAN_MSR_RX（接收状态）应周期性闪烁。如果串口始终打印“RX FIFO Empty”，首先要检查MSR——很可能CAN_MSR_INAK还是1，说明初始化流程没走完。
最后是TSR（发送状态寄存器）。它揭示了发送动作的微观过程。当调用CAN_Transmit()后，TSR的bit23（TME0）会从1变为0，表示邮箱0已被占用；bit22（LOW0）变为1，表示邮箱0处于低优先级；bit19（TXOK0）在发送完成后变为1，表示发送成功。但在回环模式下，“发送完成”和“接收成功”几乎是同时发生的。我们通过轮询TSR的TXOK0位来确认发送结束，紧接着立即读取RF0R（接收FIFO0寄存器）的FMP0位（FIFO消息挂起数）。FMP0的值范围是0~3，当它从0变为1时，就证明回环数据已进入接收FIFO。这个“发送-确认-接收”的三步闭环，就是整个测试的灵魂。工程中在main.c里实现了严格的时序控制：
// 发送一帧标准帧
TxMessage.StdId = 0x123;
TxMessage.ExtId = 0x00;
TxMessage.RTR = CAN_RTR_DATA;
TxMessage.IDE = CAN_ID_STD;
TxMessage.DLC = 4;
TxMessage.Data[0] = 0x01; TxMessage.Data[1] = 0x02;
TxMessage.Data[2] = 0x03; TxMessage.Data[3] = 0x04;
TxMailbox = CAN_Transmit(&CAN_InitStructure, &TxMessage);
// 等待发送完成（超时保护）
timeout = 0;
while((CAN_TransmitStatus(&CAN_InitStructure, TxMailbox) == CAN_TxStatus_Failed) && timeout++ < 0xFFFF) {
delay_us(1);
}
if(timeout >= 0xFFFF) printf("TX Timeout!\r\n");
// 立即检查接收FIFO
if(CAN_MessagePending(&CAN_InitStructure, CAN_FIFO0) > 0) {
CAN_Receive(&CAN_InitStructure, CAN_FIFO0, &RxMessage);
printf("RX OK! ID:0x%03X, Data:%02X %02X %02X %02X\r\n",
RxMessage.StdId, RxMessage.Data[0], RxMessage.Data[1],
RxMessage.Data[2], RxMessage.Data[3]);
} else {
printf("RX FIFO Empty!\r\n");
}
这段代码看似简单，实则暗含玄机。CAN_TransmitStatus()返回CAN_TxStatus_Failed时，可能是因为邮箱被抢占，也可能是因为控制器未就绪；而CAN_MessagePending()的返回值大于0，才是接收成功的铁证。很多初学者习惯用CAN_GetITStatus()配合中断，但在纯轮询模式下，必须依赖这些状态寄存器的原始值。这就是为什么工程坚持用SPL——它让你亲手触摸每一个比特的变化，而不是依赖HAL库里封装好的“黑盒”函数。
4. 实操过程与核心环节实现：从KEIL5工程打开到串口日志验证
拿到这个工程压缩包，解压后你会看到典型的KEIL5项目结构。双击.uvprojx文件，KEIL5会自动加载所有源文件、头文件路径、宏定义和链接脚本。但别急着编译，先做三件关键的事：确认芯片型号、检查时钟配置、验证串口引脚映射。这是所有后续步骤的基石，跳过它们等于在流沙上盖楼。
第一步：确认Target配置。点击Project → Options for Target，在Device选项卡里，确保选择的是“STM32F103ZE”——注意是“ZE”后缀，不是“CB”或“C8”。ZET6芯片拥有512KB Flash和64KB RAM，其CAN控制器位于APB1总线上，时钟源来自APB1预分频器。如果误选成F103C8，KEIL会加载错误的启动文件，导致CAN时钟频率计算偏差，波特率必然不准。在Clock选项卡里，检查System Clock设置是否为72MHz（这是F103ZET6的典型主频），并确认APB1 Prescaler为2，这样APB1总线频率就是36MHz，与can.c里BTR寄存器的计算基准完全匹配。
第二步：检查头文件包含路径。在C/C++选项卡的Include Paths里，应该有四条关键路径：
.\SYSTEM\sys
.\SYSTEM\delay
.\SYSTEM\usart
.\HARDWARE\can
这些路径指向对应的.h文件。特别注意stm32f10x_conf.h这个配置文件，它决定了哪些外设驱动会被编译进工程。打开它，确认#define USE_STDPERIPH_DRIVER已启用，且#define STM32F10X_HD被取消注释（HD代表High Density，对应ZET6的大容量Flash）。如果这里配置错误，编译时会出现undefined reference to 'CAN_Init'之类的链接错误。
第三步：验证USART1引脚映射。这个工程默认使用USART1，TX引脚为PA9，RX引脚为PA10。打开usart.c，检查GPIO_PinRemapConfig(GPIO_Remap_USART1, ENABLE)是否被调用。对于F103ZET6，USART1的默认引脚确实是PA9/PA10，无需重映射。但如果开发板把PA9复用给了其他功能（比如USB的DP），就必须在sys.c的Sys_Init()函数里禁用相关外设时钟，避免资源冲突。
做完这三项检查，就可以点击Build按钮编译了。正常情况下，Output窗口会显示“0 Error(s), 0 Warning(s)”，生成templete.axf（调试文件）、templete.hex（烧录文件）和templete.htm（符号表）。此时用ST-Link Utility或KEIL自带的Flash Downloader，将hex文件烧录到芯片。烧录完成后，打开串口调试助手（如XCOM或SSCOM），设置波特率为115200，8N1，你应该立即看到类似这样的输出：
CAN Loopback Test Start...
TX OK!
RX OK! ID:0x123, Data:01 02 03 04
TX OK!
RX OK! ID:0x123, Data:05 06 07 08
...
如果串口一片空白，不要慌，按以下顺序排查：
1. 检查ST-Link连接：设备管理器里是否有“STMicroelectronics ST-LINK USB Device”？没有的话重插ST-Link或更新驱动。
2. 确认串口线连接：PA9（TX）必须接到USB转串口模块的RX引脚，PA10（RX）接到TX引脚，GND共地。接反会导致无法发送。
3. 测量PA9电平：用万用表测PA9对地电压，空闲时应为3.3V（高电平），发送数据时应有脉冲波动。如果一直是0V，说明USART1时钟没开启或GPIO配置错误。
4. 检查CAN引脚：虽然回环模式不依赖物理总线，但CAN_RX（PA11）和CAN_TX（PA12）仍需正确配置为复用推挽输出。打开can.c的CAN_GPIO_Config()函数，确认GPIO_Mode_AF_PP和GPIO_Speed_50MHz设置无误。
一旦串口开始稳定输出，恭喜你，已经跨过了最硬的门槛。接下来可以深入验证更多场景：比如修改can.c里的CAN_BTR值，把0x001C0007改成0x001C000F（BRP=15），观察波特率降到250kbps后，接收成功率是否下降；或者在main.c的循环里加入CAN_ITConfig(CAN_IT_TME, ENABLE)开启发送中断，把轮询改成中断驱动，体验不同的编程范式。这个工程的价值，正在于它提供了这样一个安全、可控、可逆的实验场——所有改动都在软件层面，不会烧毁任何硬件，也不会引发总线冲突。
5. 常见问题与排查技巧实录：那些官方文档不会告诉你的坑
在实际教学和项目支持中，我整理了一份高频问题清单，这些问题大多不会出现在ST官方参考手册里，却是新手在KEIL5环境下跑通CAN回环时最常踩的“隐形地雷”。它们有些源于开发环境的细微差异，有些来自芯片手册的模糊表述，更多的是多年调试经验沉淀下来的直觉判断。
5.1 问题：串口输出“TX OK!”但始终不打印“RX OK!”，接收FIFO一直为空
现象描述：发送函数返回成功，TSR寄存器显示TXOK0=1，但CAN_MessagePending()始终返回0，RF0R的FMP0位恒为0。
根本原因：CAN控制器未真正退出初始化模式。MSR寄存器的CAN_MSR_INAK位仍为1，导致接收FIFO被锁定。
排查步骤：
1. 在KEIL5调试模式下，打开Peripherals → CAN → CAN1，观察MSR寄存器值。如果INAK=1，说明初始化流程卡住了。
2. 检查can.c中的CAN_Init()函数，确认在配置完BTR后，是否执行了CAN->MCR &= ~CAN_MCR_INRQ;（清除INRQ位）。常见错误是漏掉这行，或者把它写在了配置BTR之前。
3. 添加临时调试代码：在CAN_Init()末尾插入while(CAN->MSR & CAN_MSR_INAK);，强制等待初始化完成。如果程序卡在这里，证明前面的配置有误。
5.2 问题：串口输出乱码，或只显示部分字符（如“CAN Loopba…”后截断）
现象描述：预期输出“CAN Loopback Test Start…”，实际只看到前几个字符，后续内容缺失或变成乱码。
根本原因：USART时钟配置错误，导致波特率严重偏离115200。F103ZET6的USART1时钟源是APB2总线，而APB2频率由RCC_CFGR寄存器的PPRE2位决定。如果误将PPRE2设为2分频，APB2频率会变成72MHz/2=36MHz，此时USARTDIV计算值错误，实际波特率可能只有57600。
解决方案：
1. 打开sys.c，检查RCC_Configuration()函数中RCC_PCLK2Config(RCC_HCLK_Div1)是否被调用（即APB2不分频）。
2. 在usart.c的USART_Init()调用前，用示波器测PA9引脚，发送一个固定字符（如’U’），测量起始位到下一个起始位的时间间隔。115200bps对应周期≈8.68μs，如果实测为17.36μs，基本确定是APB2被2分频了。
5.3 问题：工程在KEIL5 v5.38上编译报错“undefined symbol CAN_Init”，但在v5.23上正常
现象描述：同样的源码，在不同版本KEIL5中编译结果迥异。
根本原因：KEIL5从v5.30开始，默认启用了ARM Compiler 6（AC6），而标准外设库是为ARM Compiler 5（AC5）编写的。AC6的链接器对符号解析更严格，会拒绝链接未声明的函数。
解决方案：
1. Project → Options for Target → Target选项卡，将ARM Compiler版本改为“Use default compiler version 5”。
2. 或者，在C/C++选项卡的Define框中，添加__USE_STDPERIPH_DRIVER宏定义，确保stm32f10x_conf.h正确包含CAN驱动头文件。
5.4 问题：使用stm32_simulator.py脚本仿真时，CAN接收中断不触发
现象描述：Python脚本能模拟发送，但KEIL5的调试窗口看不到中断服务函数（CAN1_RX0_IRQHandler）被执行。
根本原因：仿真脚本与真实硬件的中断触发机制不同。真实芯片中，回环数据写入接收FIFO会自动置位RF0R的FULL位，并触发中断；而仿真脚本只是修改内存中的RF0R值，并未模拟NVIC中断控制器的行为。
绕过方法：
1. 在can.c中，将接收逻辑从中断模式改为轮询模式（即注释掉CAN_ITConfig(CAN_IT_FMP0, ENABLE)，改用while(CAN_MessagePending() > 0)循环检测）。
2. 这样仿真脚本只需保证RF0R的FMP0位被正确修改，就能被主循环捕获。
5.5 问题：修改波特率后，接收成功率大幅下降，偶尔出现“RX OK!”但数据错乱
现象描述：将BTR从0x001C0007（500kbps）改为0x001C0003（1Mbps）后，约30%的帧接收失败或数据校验错误。
根本原因：波特率过高时，采样点偏移超出容限。CAN协议要求采样点落在TQ的87.5%位置附近，而F103的CAN控制器在1Mbps下，TS1+TS2的组合难以精确满足。
优化方案：
1. 重新计算BTR：保持BRP=3，取TS1=3、TS2=1，则TQ=3+1+1=5，采样点位置=(TS1+1)/TQ=4/5=80%，接近理想值87.5%。BTR值为0x000C0003。
2. 在can.c中增加CAN->MCR |= CAN_MCR_NART;（禁止自动重传），避免因采样错误导致的无限重发，掩盖真实问题。
提示：所有这些问题的根源，都指向同一个原则——CAN通信的本质是时序艺术，而非逻辑编程。每一个寄存器位的设置，都是在跟纳秒级的时间赛跑。这个工程的价值，不在于它能跑通，而在于它逼你直面这些微妙的时序关系，直到你能在脑中画出完整的位定时波形图。
6. 工程扩展与进阶实践：从回环测试到真实总线通信
当CAN回环测试稳定运行后，下一步自然是从“自说自话”走向“真实对话”。这个工程预留了极佳的扩展接口，所有硬件抽象都已做好，你只需替换几个关键模块，就能无缝接入物理总线。但切记：扩展不是简单地拔掉回环开关，而是要系统性地补全通信链路的每一个环节。
6.1 物理层接入：从回环到真实CAN总线
回环模式关闭只需一行代码：CAN->MCR &= ~CAN_MCR_LOOPBACK;。但这只是万里长征第一步。真实通信必须解决三个物理层问题：终端电阻、共模电压、收发器选型。
- 终端电阻：CAN总线两端必须各接一个120Ω电阻。很多新手只在开发板上接一个，结果通信不稳定。记住口诀：“两头有阻，中间无阻”。
- 共模电压：CAN_H和CAN_L的电压差必须在±2V内，否则收发器无法识别。用万用表测开发板CAN接口的CAN_H-CAN_L电压，正常应在2.5V左右。如果低于1.5V，检查收发器供电是否正常（TJA1050需5V，SN65HVD230需3.3V）。
- 收发器选型：工程中HARDWARE目录下的can.c已预留了CAN_GPIO_Config()函数，它配置PA11/PA12为复用推挽。但不同收发器对引脚驱动能力要求不同：TJA1050需要强驱动，应设置GPIO_Speed_50MHz；而SN65HVD230对驱动要求较低，GPIO_Speed_2MHz即可。
6.2 协议栈升级：从裸机驱动到CANopen基础
回环测试验证的是物理层和数据链路层，而真实应用需要更高层的协议。这个工程的模块化设计，让它成为绝佳的CANopen入门跳板。
- 对象字典雏形：在HARDWARE/can.c中，CAN_Receive()函数已解析出StdId、DLC、Data[]。你可以在此基础上，定义一个简单的对象字典结构体：
typedef struct {
uint16_t index; // 如0x1001（错误寄存器）
uint8_t subindex; // 如0x00（子索引0）
uint8_t data[8]; // 数据内容
} CO_OBJ_DICT;
- NMT状态机：在
main.c的主循环中，加入NMT（网络管理）状态机，监听0x0000标准帧，根据第二个字节（命令字）切换节点状态（Pre-operational/Operational）。 - PDO映射：利用CAN控制器的过滤器（Filter），在
CAN_FilterInit()中配置接受列表，只接收特定ID的PDO帧，避免CPU被无关帧打断。
6.3 调试工具链整合：从串口打印到CAN分析仪
工程自带的串口打印是初级调试手段，进阶需要专业工具。
- CANalyzer/CANoe对接：将开发板的CAN接口接入PC的USB-CAN适配器，在CANalyzer中新建数据库（.dbc文件），导入工程中定义的帧ID（如0x123为心跳帧，0x201为温度数据帧）。这样，串口打印的“ID:0x123”就变成了图形化的信号曲线。
- 逻辑分析仪抓波形：用Saleae Logic或DSLogic，同时采集CAN_H、CAN_L和PA9（USART TX），对比物理层波形与协议层解析结果。你会发现，当波特率误差超过±1%时，逻辑分析仪显示的位宽开始抖动，而CAN控制器仍能正确接收——这正是CAN协议鲁棒性的直观体现。
注意：所有扩展的前提，是彻底吃透当前回环工程的每一行代码。我见过太多人，急着加CANopen协议栈，结果连最基本的波特率计算都搞错，最后在协议层浪费大量时间。真正的进阶，永远始于对基础的敬畏。这个工程的价值，正在于它用最朴素的方式告诉你：嵌入式没有捷径，只有把寄存器每一位都摸透，才能在复杂系统中游刃有余。
简介：这个KEIL5工程专为STM32F103ZET6芯片设计，实现CAN控制器纯软件回环通信验证——不依赖外部CAN收发器或第二块板子，直接在芯片内部完成发送与接收闭环。工程采用标准外设库结构，SYSTEM目录负责系统初始化和毫秒级延时，HARDWARE目录下封装了CAN初始化、发送、接收及状态查询函数，同时集成USART串口打印用于实时观察帧收发结果，LCD和KEY模块保留接口便于后续功能扩展。代码包含main.c主流程调度、can.c核心驱动逻辑、delay.c高精度延时、sys.c系统配置，以及标准启动文件startup_stm32f10x_hd.s和链接脚本。配套readme.txt说明编译步骤与调试要点，Objects和Listings目录自动生成编译中间文件，.uvprojx和.uvguix.admin支持KEIL5一键打开即用。所有源码已通过完整编译，输出可执行的.axf、.hex和.htm调试信息文件，还提供stm32_simulator.py脚本辅助仿真验证。适合嵌入式初学者快速掌握CAN寄存器配置、中断处理流程和回环模式调试方法，也适用于MCU外设功能自检与实时通信基础验证。
898
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
