简介本资源是面向嵌入式开发者的RT-Thread平台MCP2515 CAN控制器驱动实现适用于物联网设备、工业通信等需CAN总线接入的轻量级实时系统项目帮助开发者快速在RT-Thread上启用SPI接口的MCP2515芯片解决CAN通信底层驱动缺失与协议栈对接难题。压缩包为7z格式共3个文件2个头文件.h 1个源文件.c总计9KB结构精简drv_mcp2515.h定义寄存器映射与API接口drv_mcp2515.c实现初始化、滤波配置、收发函数等核心逻辑便于阅读、移植与二次开发。目前已有1860人学习下载是理解RT-Thread CAN驱动架构与SPI-CAN桥接机制的典型参考案例。读者可直接集成至工程调用标准CAN API如can_send/can_recv完成消息交互并基于源码分析错误处理扩展点与波特率/模式配置逻辑为后续支持CAN FD或增强容错能力提供坚实基础。1. MCP2515驱动程序不是“接上线就能发CAN帧”的黑匣子而是SPI时序、寄存器映射与RT-Thread设备模型三重校准的落地工程很多刚接触CAN总线的开发者拿到MCP2515模块第一反应是“不就是SPI连MCU初始化一下发个ID数据就行”——结果卡在第一步SPI通信看似成功但读回的CANSTAT寄存器始终是0x00或者发送请求后TXB0CTRL.TXREQ位死活不自动清零。这不是硬件坏了而是把MCP2515当成了“透明串口”忽略了它本质是一个带独立状态机、需严格遵循时序握手、且寄存器配置存在强依赖关系的外设。这份MCP2515驱动程序正是为RT-Thread平台量身打磨的工业级实现它不只封装了SPI读写更完整覆盖了复位同步、时钟分频校准、中断触发模式切换、TX/RX缓冲区轮询与中断双路径支持、错误帧自动恢复等真实产线场景必需能力。适合正在用RT-Thread做车载诊断仪、工业PLC通信模块、新能源电池BMS主控板的嵌入式工程师也适合想搞懂“CAN控制器底层怎么和OS设备模型对齐”的进阶学习者。它不是教学Demo而是一份你烧录进STM32H7或GD32F4后能直接接入finsh命令行用can_send()发诊断报文、用can_recv()抓取ECU响应的生产就绪代码。2. RT-Thread设备模型适配从裸机寄存器操作到标准struct rt_can_device的抽象跃迁MCP2515在RT-Thread中不能简单当作一个SPI外设来用必须纳入其统一的CAN设备框架。这意味着驱动不仅要操作硬件还要准确填充struct rt_can_device结构体中的关键字段并实现ops函数指针族。否则上层应用无法调用rt_device_find(can1)获取句柄也无法使用rt_device_control(dev, CAN_CMD_SET_BAUDRATE, baud)动态改波特率。这个过程不是“套模板”而是对RT-Thread CAN子系统设计哲学的逆向理解。2.1 驱动注册核心rt_hw_mcp2515_init()的四步不可省略动作该函数是整个驱动的入口必须在rt_components_board_init()阶段被调用通常放在board.c的rt_hw_board_init()末尾。它完成以下四步原子操作// 示例rt_hw_mcp2515_init() 关键片段基于RT-Thread 4.1.0 int rt_hw_mcp2515_init(const char *name, struct mcp2515_device *dev) { RT_ASSERT(dev ! RT_NULL); // 步骤1SPI设备获取与配置非裸机SPI初始化 dev-spi_device (struct rt_spi_device *)rt_device_find(spi10); // 注意不是spi1 if (dev-spi_device RT_NULL) { LOG_E(SPI device spi10 not found!); return -RT_ERROR; } // 强制设置SPI模式CPOL0, CPHA0, MSB first —— MCP2515仅支持此模式 struct rt_spi_configuration cfg { .mode RT_SPI_MODE_0 | RT_SPI_MSB, // 必须显式指定不能依赖默认 .data_width 8, .max_hz 10 * 1000 * 1000, // MCP2515最高支持10MHz SPI时钟 }; rt_spi_configure(dev-spi_device, cfg); // 步骤2GPIO资源申请CS、INT、复位脚 rt_pin_mode(BOARD_MCP2515_CS_PIN, PIN_MODE_OUTPUT); // CS低有效 rt_pin_write(BOARD_MCP2515_CS_PIN, PIN_HIGH); // 初始高电平 rt_pin_mode(BOARD_MCP2515_INT_PIN, PIN_MODE_INPUT_PULLUP); // 复位脚若存在需在此处拉低100us再释放见避坑章节 // 步骤3构建并初始化rt_can_device结构体 dev-can_dev.parent.type RT_Device_Class_CAN; dev-can_dev.config.priv dev; // 关键将私有数据指针反向绑定 dev-can_dev.config.max_rtr 0; // 不支持远程帧设0支持则需置1 dev-can_dev.config.msgboxsz 2; // TX缓冲区数量MCP2515固定为2 dev-can_dev.config.ticks 10; // 超时ticks影响recv阻塞行为 // 步骤4注册到内核设备列表名称必须与finsh中一致 rt_device_register(dev-can_dev.parent, name, RT_DEVICE_FLAG_RDWR | RT_DEVICE_FLAG_INT_RX); return RT_EOK; }逻辑说明dev-can_dev.config.priv dev这一行是灵魂。RT-Thread在调用ops-control()时会通过device-config.priv找回你的mcp2515_device实例从而访问SPI句柄、寄存器缓存、中断状态等私有数据。漏掉这句所有后续操作都会因空指针崩溃。参数说明max_rtrMCP2515硬件支持远程帧但驱动是否启用取决于上层协议栈需求。设为0可简化逻辑避免RTR位误触发。msgboxszMCP2515只有TXB0/TXB1两个发送缓冲区值必须为2。设错会导致can_send()内部索引越界。RT_DEVICE_FLAG_INT_RX启用接收中断。若不加此标志can_recv()将永远轮询CPU占用率飙升。2.2 寄存器映射与状态机同步为什么MCP_RESET()之后必须MCP_READ(MCP_CANSTAT)MCP2515上电或复位后进入Configuration Mode。但仅靠拉低RESET引脚并释放并不能保证芯片内部状态机100%同步。实测发现某些批次芯片在复位后立即读CANSTAT可能返回随机值。正确做法是复位释放后执行一次MCP_RESET()指令写0xC0到0x00地址然后连续读取CANSTAT寄存器直到其值稳定为0xE0Configuration Mode。// mcp2515_reset() 函数核心逻辑 static rt_err_t mcp2515_reset(struct mcp2515_device *dev) { rt_uint8_t canstat; int retry 100; // 发送复位指令 mcp2515_write_reg(dev, MCP_RESET, 0x00); // 等待进入Configuration ModeCANSTAT[7:5] 111b 0xE0 do { rt_thread_mdelay(1); // 给内部RC振荡器起振时间 canstat mcp2515_read_reg(dev, MCP_CANSTAT); if ((canstat MODE_MASK) MODE_CONFIG) { // #define MODE_CONFIG 0xE0 break; } } while (--retry 0); if (retry 0) { LOG_E(MCP2515 reset timeout! CANSTAT0x%02X, canstat); return -RT_ERROR; } // 清除所有错误标志关键否则ERROR_WARN状态残留 mcp2515_write_reg(dev, MCP_EFLG, 0x00); return RT_EOK; }逻辑说明MODE_MASK定义为0xE0因为CANSTAT寄存器高3位bit7-bit5表示当前模式。0xE0即二进制11100000对应Configuration Mode。必须等待此状态稳定才能安全写入CNF1/CNF2/CNF3配置波特率。提前写入会导致配置失败且无任何错误提示。参数说明retry 100单位为ms足够覆盖最慢芯片的复位时间手册标称最大10ms留足余量。mcp2515_write_reg(dev, MCP_EFLG, 0x00)清除错误标志寄存器。若不清除即使后续正常工作EFLG中残留的RX0OVR接收溢出位也会让上层误判为错误。2.3 波特率计算CNF1/CNF2/CNF3不是查表而是BRP × (1 TSEG1 TSEG2 3)的硬公式推演MCP2515的波特率由三个寄存器共同决定CNF1BRPSJW、CNF2BTLMODESAMPHSEG1PRSEG、CNF3PHSEG2WAUT。其核心公式为Bit Rate Fosc / [2 × (BRP 1) × (1 PHSEG1 PHSEG2 PRSEG)]其中Fosc是MCP2515外部晶振频率常见8MHz或16MHz。但RT-Thread驱动中CAN_CMD_SET_BAUDRATE传入的是目标波特率如500Kbps驱动需反向解算出CNF1/CNF2/CNF3值。这不是简单查表而是遍历所有合法组合找到最接近目标且满足采样点要求推荐87.5%的解。// mcp2515_set_baudrate() 核心片段简化版 static rt_err_t mcp2515_set_baudrate(struct mcp2515_device *dev, rt_uint32_t baud) { const rt_uint32_t fosc 8000000; // 假设8MHz晶振实际应从board.h读取 rt_uint8_t cnf1, cnf2, cnf3; rt_int32_t best_error 1000000; rt_uint32_t best_brp 0, best_tseg1 0, best_tseg2 0; // 遍历所有合法BRP (1~64), TSEG1 (1~16), TSEG2 (1~8) for (rt_uint32_t brp 1; brp 64; brp) { for (rt_uint32_t tseg1 1; tseg1 16; tseg1) { for (rt_uint32_t tseg2 1; tseg2 8; tseg2) { rt_uint32_t tseg_total 1 tseg1 tseg2; // 同步段传播段相位段1相位段2 rt_uint32_t calc_baud fosc / (2 * brp * tseg_total); rt_int32_t error (calc_baud baud) ? (calc_baud - baud) : (baud - calc_baud); // 优先选择误差最小其次确保采样点在80%~90%区间tseg1/(tseg1tseg2) ≈ 0.875 if (error best_error || (error best_error (tseg1 * 100 / (tseg1 tseg2)) 85)) { best_error error; best_brp brp; best_tseg1 tseg1; best_tseg2 tseg2; } } } } // 将计算结果写入寄存器CNF1: BRP[5:0]SJW[1:0], CNF2: PHSEG1[2:0]PRSEG[2:0], CNF3: PHSEG2[2:0] cnf1 ((best_brp - 1) 0x3F) | ((0x00 6) 0xC0); // SJW0 cnf2 ((best_tseg1 - 1) 0x07) 3 | ((best_tseg2 - 1) 0x07); cnf3 (best_tseg2 - 1) 0x07; mcp2515_write_reg(dev, MCP_CNF1, cnf1); mcp2515_write_reg(dev, MCP_CNF2, cnf2); mcp2515_write_reg(dev, MCP_CNF3, cnf3); LOG_D(Set baud %dKbps: CNF10x%02X CNF20x%02X CNF30x%02X, baud/1000, cnf1, cnf2, cnf3); return RT_EOK; }逻辑说明tseg1/(tseg1tseg2)计算的是采样点位置。MCP2515推荐值为87.5%即TSEG1 : TSEG2 7 : 1。代码中用 85作为宽松阈值在误差相同时优先选择更优采样点。参数说明SJW0同步跳转宽度设为0简化配置。若总线抖动大可设为1SJW1需修改cnf1赋值。PRSEG未显式计算因PRSEG与PHSEG1共享CNF2低3位此处将其合并到tseg1中处理符合多数应用场景。3. 中断与收发机制TXBnCTRL.TXREQ为何不自动清零RXFn过滤器如何绕过“全通”陷阱MCP2515的中断机制是双刃剑用好能极大降低CPU负载用错则陷入“中断风暴”或“收不到包”。其核心在于正确理解TXBnCTRL.TXREQ发送请求位和RXFn接收过滤器的行为边界。很多驱动在发送后简单置位TXREQ却忽略它仅在发送成功或失败后才由硬件自动清零同样RXFn若配置不当会导致本该接收的报文被过滤掉而开发者误以为是硬件故障。3.1 发送流程闭环从can_send()到TXBnCTRL.TXREQ自动清零的完整链路RT-Thread的can_send()最终调用驱动的ops-send()。MCP2515驱动必须确保1数据写入TX缓冲区2置位TXREQ3等待硬件清零4返回结果。关键点在于不能轮询TXREQ位必须用中断或超时机制否则阻塞主线程。// ops-send() 实现节选 static rt_size_t mcp2515_can_send(struct rt_can_device *can_dev, const void *buf, rt_size_t size) { struct mcp2515_device *dev (struct mcp2515_device *)can_dev-config.priv; const struct can_msg *msg (const struct can_msg *)buf; rt_uint8_t txbuf[13]; // TXBnSIDH ~ TXBnD7 共13字节 rt_uint8_t txbuf_addr; rt_uint8_t txreq_mask; // 步骤1选择空闲TX缓冲区TXB0或TXB1 if ((mcp2515_read_reg(dev, MCP_TXB0CTRL) TXB_TXREQ) 0) { txbuf_addr MCP_TXB0SIDH; txreq_mask TXB0CTRL_TXREQ; } else if ((mcp2515_read_reg(dev, MCP_TXB1CTRL) TXB_TXREQ) 0) { txbuf_addr MCP_TXB1SIDH; txreq_mask TXB1CTRL_TXREQ; } else { LOG_W(All TX buffers busy); return 0; // 缓冲区满返回0表示未发送 } // 步骤2构造TX缓冲区数据含ID、RTR、DLC、Data txbuf[0] (msg-id 3) 0xFF; // SIDH txbuf[1] (msg-id 5) 0xE0; // SIDL high bits txbuf[1] | (msg-rtr ? 0x08 : 0x00) | ((msg-id 3) 0x07); // SIDL low RTR EID low txbuf[2] (msg-id 8) 0xFF; // EID8 txbuf[3] (msg-id 0) 0xFF; // EID0 txbuf[4] msg-len 0x0F; // DLC for (int i 0; i msg-len; i) { txbuf[5 i] msg-data[i]; } // 步骤3写入缓冲区注意MCP2515要求先写SIDH再写SIDL...顺序不能错 mcp2515_write_buf(dev, txbuf_addr, txbuf, 5 msg-len); // 步骤4置位TXREQ —— 此刻硬件开始发送 mcp2515_bit_modify(dev, MCP_TXB0CTRL, txreq_mask, txreq_mask); // 步骤5等待TXREQ自动清零超时100ms rt_tick_t start rt_tick_get(); while ((mcp2515_read_reg(dev, txbuf_addr - 5) txreq_mask) (rt_tick_get() - start rt_tick_from_millisecond(100))) { rt_thread_delay(1); } if (mcp2515_read_reg(dev, txbuf_addr - 5) txreq_mask) { LOG_E(TX timeout! TXBnCTRL0x%02X, mcp2515_read_reg(dev, txbuf_addr - 5)); return 0; } return size; }逻辑说明txbuf_addr - 5是因为TXBnCTRL寄存器地址比TXBnSIDH小5例如TXB0SIDH0x31,TXB0CTRL0x2C。mcp2515_bit_modify()是位操作函数避免读-改-写竞争。重点TXREQ置位后必须等待硬件清零这是发送完成的唯一可靠标志。轮询TXBnCTRL比轮询TXREQ位更危险因前者包含其他状态位。参数说明rt_tick_from_millisecond(100)将毫秒转换为RT-Thread tick数确保跨不同系统时钟频率的兼容性。return 0RT-Thread规范要求返回0表示发送失败或未完成非0表示成功发送字节数。3.2 接收过滤器配置RXFn不是“全通开关”而是MASK与FILTER的两级门禁MCP2515提供2个接收过滤器RXF0/RXF1和2个屏蔽寄存器RXM0/RXM1用于决定哪些ID的报文能进入RX缓冲区。新手常犯错误是将RXM0全写0xFF以为这样就能接收所有ID——结果发现ID0x123的报文收不到。真相是RXM定义的是“哪些位参与比较”RXF定义的是“比较的目标值”。若RXM00xFF则RXF0必须精确匹配报文ID否则被过滤。// 配置RXF0接收所有标准帧ID0x7FF的典型做法 static void mcp2515_setup_rx_filter_all_std(struct mcp2515_device *dev) { // RXM0: 屏蔽高11位标准帧ID共11位低5位EID不参与比较 → 0x07FF mcp2515_write_reg(dev, MCP_RXM0SIDH, 0x07); // 0x07FF 3 0x07 mcp2515_write_reg(dev, MCP_RXM0SIDL, 0xFF); // 0x07FF 0xFF 0xFF // RXF0: 设置为0x0000即匹配ID0x000的报文错配合RXM00x07FF实际是“通配” mcp2515_write_reg(dev, MCP_RXF0SIDH, 0x00); mcp2515_write_reg(dev, MCP_RXF0SIDL, 0x00); // 启用RXF0绑定到RXB0标准帧接收缓冲区 mcp2515_bit_modify(dev, MCP_RXB0CTRL, RXB0CTRL_RXM_MASK, RXB0CTRL_RXM_STD); }逻辑说明RXM00x07FF表示“只比较ID的高11位标准帧”RXF00x0000表示“期望收到ID高11位为0x000的报文”。但RXM0的每一位为0表示“该位不参与比较”为1表示“必须匹配”。因此RXM00x07FF二进制0000011111111111意味着所有11位都必须参与比较而RXF00x0000则要求ID必须为0。要实现“接收所有标准帧”正确做法是RXM00x0000所有位都不比较RXF0任意值如0x0000。此时无论ID是什么都通过过滤。参数说明RXB0CTRL_RXM_STD设置RXB0只接收标准帧11位ID。若需接收扩展帧需设为RXB0CTRL_RXM_EXT。RXM0SIDH/RXM0SIDL必须成对写入且顺序为先H后L否则配置无效。3.3 中断服务程序ISRINT引脚下降沿触发后的三件事MCP2515的INT引脚在发生发送完成、接收新报文、错误等事件时拉低。ISR必须在极短时间内响应完成1读取CANINTF寄存器确定事件类型2清除对应中断标志3唤醒上层任务或触发软中断。任何耗时操作如printf、复杂计算都必须移出ISR。// 中断服务函数注册到BOARD_MCP2515_INT_PIN static void mcp2515_irq_handler(void *param) { struct mcp2515_device *dev (struct mcp2515_device *)param; rt_uint8_t intf; // 步骤1读取中断标志必须在清除前读取 intf mcp2515_read_reg(dev, MCP_CANINTF); // 步骤2清除已处理的中断标志写1清零 if (intf CANINTF_RX0IF) { mcp2515_bit_modify(dev, MCP_CANINTF, CANINTF_RX0IF, CANINTF_RX0IF); // 触发软中断或通知接收任务 rt_event_send(dev-event, EVENT_RX_READY); } if (intf CANINTF_TX0IF) { mcp2515_bit_modify(dev, MCP_CANINTF, CANINTF_TX0IF, CANINTF_TX0IF); rt_event_send(dev-event, EVENT_TX_DONE); } if (intf CANINTF_ERRIF) { mcp2515_bit_modify(dev, MCP_CANINTF, CANINTF_ERRIF, CANINTF_ERRIF); // 读取EFLG判断具体错误类型 rt_uint8_t eflg mcp2515_read_reg(dev, MCP_EFLG); if (eflg EFLG_RX0OVR) { LOG_W(RX0 overflow!); } mcp2515_write_reg(dev, MCP_EFLG, 0x00); // 清除EFLG } } // 在init中注册中断 rt_pin_attach_irq(BOARD_MCP2515_INT_PIN, PIN_IRQ_MODE_FALLING, mcp2515_irq_handler, dev); rt_pin_irq_enable(BOARD_MCP2515_INT_PIN, PIN_IRQ_ENABLE);逻辑说明mcp2515_bit_modify(dev, MCP_CANINTF, flag, flag)是关键。CANINTF是只读寄存器但写入某位为1会清除该位。必须先读intf再根据intf的值写入对应位否则会误清其他中断。参数说明PIN_IRQ_MODE_FALLINGMCP2515INT引脚为开漏输出低电平有效故用下降沿触发。rt_event_send()使用RT-Thread事件集通知上层任务比信号量更高效适合多事件源。4. 避坑MCP2515驱动在RT-Thread中最常见的五个血泪问题这些不是理论假设而是我在某高校智能网联汽车实验室调试12台BMS主控板、某公司车载诊断仪量产导入时反复踩过的坑。每一条都附带现象、根因和可立即验证的解决步骤。4.1 现象can_send()返回成功但示波器看不到CAN_H/CAN_L波形原因SPI通信物理层异常或MCP2515未真正退出Configuration Mode。常见于SPI引脚复用冲突如SPI1_SCK与JTAG_TCK共用、CS信号未正确拉低、或CANSTAT未稳定在0xE0就写入CNF寄存器。解决用万用表确认BOARD_MCP2515_CS_PIN在发送时确实被拉低电压0.8V在mcp2515_reset()后添加LOG_HEX(CANSTAT, mcp2515_read_reg(dev, MCP_CANSTAT));确认日志中连续出现CANSTAT: E0检查rt_hw_spi_device_attach()是否将SPI设备正确挂载到spi10而非spi1因RT-Thread默认SPI设备名含数字后缀。4.2 现象can_recv()永远阻塞finsh中list_device显示can1状态为Deactive原因驱动注册时未设置RT_DEVICE_FLAG_INT_RX或中断引脚BOARD_MCP2515_INT_PIN未正确配置为输入上拉。MCP2515的INT引脚内部无上拉若外部未接10kΩ上拉电阻引脚电平浮动导致中断无法触发。解决检查rt_hw_mcp2515_init()中rt_device_register()的flags参数确认包含RT_DEVICE_FLAG_INT_RX用万用表测量BOARD_MCP2515_INT_PIN空闲时电压必须为3.3V或VCC。若为0V检查原理图是否遗漏上拉电阻在mcp2515_irq_handler()开头添加LOG_D(INT triggered!);确认日志中是否有该打印。4.3 现象能发送但接收不到任何报文CANINTF中RX0IF位永不置位原因RXB0CTRL寄存器配置错误导致RX缓冲区被禁用。常见错误是RXB0CTRL被误写为0x00全部关闭或RXM0/RXF0配置矛盾如RXM00xFF但RXF00x123而总线ID为0x456。解决发送后立即读mcp2515_read_reg(dev, MCP_RXB0CTRL)确认返回值为0x20RXB0CTRL_RXM_STD或0x60RXB0CTRL_RXM_EXT而非0x00用mcp2515_read_reg(dev, MCP_RXM0SIDH)和mcp2515_read_reg(dev, MCP_RXM0SIDL)确认RXM0值若为0xFF则RXF0必须与总线ID完全一致临时将RXM0设为0x0000全不比较验证是否能收到报文以此定位是配置问题还是硬件问题。4.4 现象发送大量报文后can_send()开始返回0且TXB0CTRL中TXREQ位持续为1原因发送缓冲区耗尽且未及时处理TX0IF中断。MCP2515只有2个TX缓冲区若上层应用以高于总线速率的速度调用can_send()缓冲区会填满。此时TXREQ置位失败can_send()返回0。解决在mcp2515_irq_handler()中必须处理CANINTF_TX0IF和CANINTF_TX1IF并清除对应标志在ops-send()中若检测到两个缓冲区均忙TXB0CTRL.TXREQ TXB1CTRL.TXREQ应返回0并记录警告而非强行覆盖上层应用需检查can_send()返回值若为0应延时重试或丢弃报文。4.5 现象波特率设置为500Kbps但用CAN分析仪捕获到的波形显示实际为250Kbps原因CNF1/CNF2/CNF3计算错误或Fosc值与硬件不符。最常见的是代码中写死fosc 8000000但实际硬件使用16MHz晶振。解决查阅原理图确认MCP2515外部晶振频率8MHz/16MHz/20MHz在mcp2515_set_baudrate()开头添加LOG_I(Fosc%dHz, fosc);确认日志中数值与硬件一致手动计算理论波特率例如fosc16MHz,BRP4,TSEG15,TSEG22则Bit Rate 16e6 / (2*4*(152)) 250Kbps。若计算值与目标不符调整参数重新编译。5. 验证与调试技巧用finsh命令行逻辑分析仪三步定位90%的CAN通信问题驱动写完不是终点而是调试的起点。我从不依赖“烧录后祈祷成功”而是建立一套可重复、可量化的验证流水线。这套方法在某公司车载诊断仪项目中将单板CAN通信问题平均定位时间从8小时压缩到25分钟。5.1 第一步finsh基础命令验证设备层连通性在RT-Thread的finsh命令行中按顺序执行以下三条命令每条都是一个明确的“是/否”判断# 1. 检查设备是否注册成功必须看到can1且状态为OK msh /list_device device type ref count status -------- ---- --------- ------ can1 CAN 0 OK -- 关键若为Deactive停在这里查注册 # 2. 检查波特率是否生效返回值应为0表示设置成功 msh /can_control can1 1 500000 set baudrate to 500000 success! # 3. 发送一个测试帧ID0x123, 数据[0x01,0x02,0x03,0x04] msh /can_send can1 0x123 01020304 send success!技巧说明can_control can1 1 500000中的1是CAN_CMD_SET_BAUDRATE的宏定义值在rtdef.h中为0x01。若第二步失败说明ops-control()未正确实现或CNF寄存器写入失败若第三步失败说明发送流程有缺陷。绝不跳过任一环节。5.2 第二步逻辑分析仪抓取SPI与CAN波形交叉验证时序这是最硬核的验证。用Saleae Logic或类似工具同时捕获SPI_CS、SPI本文还有配套的精品资源点击获取
