4、硬件篇-触控IC与驱动：触控IC的扫描频率、报点率、滤波算法对延迟的影响。

各位同学，今天我们聊聊触控IC。这东西看着不起眼，但它是整个触控体验的“第一道关卡”。你手指点下去，信号能不能快速、准确地传到主芯片，全靠它。

我经常跟团队说一句话：“触控IC是延迟的起点，也是延迟的终点。” 为什么？因为所有后续的优化，都是在跟触控IC“抢时间”。如果IC本身底子差，后面再怎么优化，天花板就在那。

好，我们直接切入正题。影响触控延迟的三个核心参数：扫描频率、报点率、滤波算法。

4.1 扫描频率：触控IC的“心跳”

扫描频率，说白了就是触控IC每秒对触摸屏“摸”多少次。单位是Hz。比如120Hz的扫描频率，意味着IC每秒扫描120次，每8.3ms完成一次完整的扫描。

这个参数直接决定了触控IC能感知到的最小时间颗粒度。你想想看，如果扫描频率只有60Hz，那IC每16.6ms才能“看”一次屏幕。你手指点下去，最坏情况下要等16.6ms才能被检测到。这还没算后续的传输和处理时间。

为什么？因为车载环境复杂。手指可能戴着手套，屏幕可能有水雾，甚至还有强电磁干扰。高扫描频率意味着IC有更多的机会“抓到”有效信号，从而降低漏报和误报的概率。

我在一个项目中遇到过，某款触控IC标称支持120Hz，但实际跑起来只有90Hz左右。后来发现是驱动配置里有个“省电模式”没关。嗯，这里要注意，很多IC默认会开启一些节能策略，会动态降低扫描频率。做驱动适配时，一定要确认实际跑起来的频率，而不是只看规格书。

4.2 报点率：数据管道的“吞吐量”

报点率，也叫报告率，是触控IC向主芯片上报触摸点数据的频率。单位也是Hz。

很多人会把扫描频率和报点率搞混。我打个比方：扫描频率是IC“采集”数据的频率，报点率是IC“发送”数据的频率。采集快，但发送慢，数据就会在IC内部堆积，产生额外的延迟。

但现实往往没那么美好。很多低成本的触控IC，报点率只有60Hz甚至更低。这意味着即使扫描频率是120Hz，IC也只能每16.6ms上报一次数据。中间有8.3ms的数据被“丢弃”了，或者被合并了。这直接导致触控轨迹的“断点”和“跳跃感”。

我曾经调试过一个项目，用户反馈“划屏时指针会跳”。我抓了log一看，触控IC的报点率只有45Hz。而屏幕刷新率是60Hz。这就导致每帧画面里，触控数据可能只有0.75个点。指针能不跳吗？后来换了一颗报点率120Hz的IC，问题立刻解决。

所以，报点率必须大于等于屏幕刷新率，这是基本要求。如果要做高帧率交互（比如60fps的动画），我建议报点率至少是屏幕刷新率的1.5倍。

4.3 滤波算法：延迟的“隐形杀手”

滤波算法，是触控IC内部用来处理原始信号的一套数学方法。它的目的是去除噪声，让触控坐标更平滑、更稳定。

但滤波是一把双刃剑。滤波越强，坐标越平滑，但延迟也越大。为什么？因为很多滤波算法（比如滑动平均、卡尔曼滤波）都需要“看”历史数据。你滤波窗口越大，需要积累的历史数据越多，输出的坐标就越滞后。

那么，怎么平衡滤波和延迟？我个人的经验是：

• 静态场景（比如看地图、点按钮）：可以适当加强滤波，让坐标更稳定，减少误触。
• 动态场景（比如滑动列表、拖动图标）：必须降低滤波强度，优先保证响应速度。

有些高端触控IC支持“动态滤波”，可以根据手指移动速度自动调整滤波强度。这个功能很实用，我建议在项目中优先选用。

4.4 三个参数的协同关系

扫描频率、报点率、滤波算法，这三个参数不是孤立的。它们共同决定了触控延迟的“下限”。

我画个简单的公式：

触控IC延迟 ≈ 扫描周期 + 报点周期 + 滤波延迟

举个例子：

你看，光是触控IC这一关，就已经贡献了20多毫秒的延迟。这还没算I2C/SPI传输、主芯片处理、UI渲染的时间。所以，想要降低端到端延迟，触控IC是必须优化的第一站。

4.5 实战建议

最后，我给大家几条实战建议：

1. 选型时，不要只看规格书上的“最大”值。要问清楚：在典型工作模式下，扫描频率和报点率是多少？滤波算法是否可调？
2. 驱动开发时，务必关闭不必要的节能模式。很多IC默认会降频，导致实际性能远低于标称值。
3. 滤波算法要“按需配置”。不要一股脑开到最强。我建议在开发阶段，把滤波强度做成可调参数，方便后期调优。
4. 用示波器或逻辑分析仪实测。不要相信软件log。直接抓IC的中断信号和SPI/I2C波形，看实际报点间隔。这是最准确的方法。

好，这一章就到这里。下一章我们聊聊触控IC和主芯片之间的通信协议——I2C和SPI，看看它们对延迟的影响有多大。