📚 课程目录第2章 CAN FD控制器硬件架构

CAN FD控制器硬件架构：核心模块介绍、FIFO在收发路径中的位置

做CAN FD开发，第一件事就是搞懂硬件架构。

很多人上来就啃数据手册，结果被一堆寄存器绕晕。

我自己的习惯是——先看图，再想为什么这么设计。

这套架构你弄明白了，后面定位FIFO溢出才能有的放矢。

一个典型的CAN FD控制器，内部长什么样？

我拆解给你看：

模块名称	一句话功能
协议控制器	按CAN FD协议解析/组装报文，处理帧起始、CRC、ACK等
位时序逻辑	管理采样点、同步段、相位缓冲段，决定波特率
发送引擎	从发送FIFO取数据，逐位送到总线
接收引擎	从总线收位流，解析后存入接收FIFO
FIFO缓冲区	CPU和总线之间的水位调节池，分发送和接收两组
消息过滤器	只让ID匹配的报文进入接收FIFO，减轻CPU负担
错误处理单元	统计错误计数，触发总线关闭或主动恢复

这里面，FIFO是CPU和总线之间的关键缓冲带。说白了，它就是个临时仓库——CPU往仓库里放要发的货，总线派送员从仓库取货；反过来，总线收来的货先堆到仓库，CPU闲了再来取。

仓库大小（深度）决定了你能扛多少突发流量。太小，溢出了；太大，延迟变大。

咱们把数据流走一遍：

发送路径：CPU通过AHB/APB总线写入发送FIFO → 发送引擎从FIFO头部取出报文 → 协议控制器打包成CAN FD帧 → 位时序逻辑逐位发送到CAN总线。
接收路径：CAN总线上信号经过位时序逻辑采样 → 协议控制器解帧 → 接收引擎把报文放入接收FIFO → CPU轮询或中断读取。

你看，FIFO夹在CPU和硬件引擎中间。它解决了一个根本矛盾：CPU的处理速度和总线的位流速度不匹配。

举个例子：CAN FD的仲裁段波特率可能是500kbps，数据段能飙到2M甚至8M。CPU如果每次发一条报文都要等总线空闲，效率太低了。FIFO让CPU可以一口气塞好几条报文，然后干别的去。

收也是一样——总线可能在短时间内连续涌入多条报文，CPU不可能每一条都立即响应。接收FIFO先兜着，CPU有空再慢慢取。

关键认知：FIFO不是用来“存数据”的，是用来解耦生产者和消费者速度的。你理解了这个，就能明白为什么溢出检测、阈值中断、优先级管理是硬件设计里绕不开的硬功夫。

下面这张图，我手绘了核心模块的连接关系和数据流向。你看一眼，再回来看文字，会更清楚。

有一次做车载网关项目，CAN FD总线负载率到了65%。

跑测试的时候，偶尔丢帧。一开始以为是干扰，加屏蔽、改终端都没用。

最后查寄存器，发现接收FIFO的溢出中断触发了一百多次。

问题在哪？接收FIFO深度只有16个消息，而CPU中断响应延时太长——一次中断进来，还没来得及读完，后面又涌进来好几条。

更要命的是，溢出标志清零后，后面丢的帧连痕迹都没有。你从应用层看，就是偶尔“莫名其妙”少一条报文。

后来我加了硬件阈值中断：FIFO存到8条就触发，CPU提前抢读。溢出次数从一百多直接降到0。

我的惯用配置：接收FIFO深度选64（如果芯片支持），阈值设在50%。既能保证CPU有足够时间响应，又不会让FIFO塞满后产生长时间中断延迟。

你在选型或做寄存器配置时，下面这几个参数得重点关注：

注意：有些芯片的发送FIFO和接收FIFO共享一个RAM空间。你配置发送深度时，接收会自动减少。对这种情况，一定要算好最大可能的消息排队长度，别让两边打架。

嗯，硬件架构这部分，我暂且讲这么多。

你脑子里现在应该有张图了：CPU、FIFO、发送/接收引擎、协议控制器，还有那条实实在在的CAN总线。FIFO就是那个连接两端的水库，淹了还是干了，全看你怎么管理水位。

下一层，咱们会聚焦在FIFO溢出这个具体问题上，看看它到底是怎么发生的、怎么定位的。