开发TSC2046触摸芯片驱动问题分析(物理、模拟SPI分析阶段)

背景

换成物理SPI之后，程序又开始死掉，并且调试发现程序又死在了发送数据部分，然后首先检查SPI驱动代码，单独测量时，程序依旧死掉，发现仍然是由于无回应值导致。
最终检查是SPI在初始化时未使能，但是使能之后，程序依旧有问题，测量结果很奇怪，每次测量结果都很小，与模拟阶段的数值差距很大，仔细阅读TSC2046数据手册，如图10发现该芯片支持的最大时钟速率为125KHz。

而我们使用的是SPI3，如果使用物理SPI那么根据F4的参考手册，所使用的时钟源为APB1，再查看CubeMx配置的数值42MHz，可以看出SPI使用最大的分频系数256，此时的时钟频率也为168KHz，已经超过了范围。

问题分析

我们再分析一下其他的SPI，SPI6和SPI5，以及SPI1和SPI4使用的是APB2（会影响串口线上的速率），而SPI3和SPI2使用的是APB1，经过计算如果要满足SPI的时钟信号频率不高于TSC2046的上限频率，是很难配出合适的配置的。
所以，目前的方法只能使用模拟的SPI来驱动TSC2046进行测量和数据通信，优点是可以灵活调整时序时钟的频率，但是其时钟的产生需要占用MCU的资源。需要考虑到这一损耗，如果后面对响应速率以及软件的稳定性和实时性，就需要解决掉这一问题，最终可能还要使用物理SPI（最高效）。

测量模式（8位/12位）分析阶段

在第二节已经提到，TSC2046存在两种精度的数据模式，当我们对速度的需求高于精度时，就可以考虑使用8位模式，反之就要使用12位模式了。
但是，根据时序图可以看出，无论是使用8位模式还是12位模式，都需要在数据发送时提供16个时钟周期的时钟信号（只不过最终取出的数据不一样而已），这是这两个执行测量所使用的时间长短不一样。
一开始，并没有意识到这一点，以为我们在使用12位测量时，只需要提供12个时钟周期即可，但是实际测量，发现这样采集到数据之后，会导致下一次测量值出现异常，根据框图可以看出，应该是上次的测量值在下次的时钟输入时才被完整地传出（毕竟数据的传输需要有时钟信号的驱动）。
通过数据手册可以找到两种时钟模式，16 Clocks-per-Conversion和15 Clocks-per-Conversion（不适合我们的单片机，适合用于FPGA），根据手册，我们可以连续发送测量指令，但是需要满足时序条件。

触摸坐标原点分析阶段

解决了测量数值不正常的问题后，分析五个特殊触摸点的测量值后，发现触摸面板的坐标原点并不是正常的左下角，而是右上角。
如图14所示，是触摸板的接线端子图，最终跟硬件的确认之后，发现是该接线端子的接线顺序接反了，按顺序的从左到右的排线，实际连接是从右到左了，实际上该问题也不难理解。
只需要将下图的坐标系进行翻转，将坐标原点翻转到右上角，就可以发现此时的X坐标方向成了之前的Y的反方向，Y坐标的方向是之前的X坐标的反方向。

实际上，这种错误连接并不致命，只是会导致我们的坐标转换过程的工作量增大，即使连接正确，但是我们的emWin所使用的坐标系，如下图是emWin的屏幕坐标系。
所以为了减少坐标转换的工作量，也就建议硬件那边将接线端子反接Y坐标的两根线。这样就可以保证触摸坐标和emWin的LCD坐标系统一，从而简化坐标转换过程。

此次TSC2046出现的问题，其根本原因就是对该芯片的了解不够，以及对于此类驱动的开发缺少经验。
并且前期阅读该芯片的数据手册存在很大的障碍，并且在一开始就对触摸芯片的PENIRQ引脚存在一个误解，实际上该引脚只是在触摸时会被拉低，松开后才会恢复高电平，但是测量时该引脚会再次被拉低，并且测量期间不会响应点击。
此次问题的解决核心就是它的时序图，包括它的指令发送，测量过程忙等待（关于这一点，希望可以使用硬件引脚查询BUSY脚的方式），以及最后的数据读取（需要提供完整的时钟信号）。

问题总结

1.对于一个芯片的驱动开发，尤其是使用SPI或I2C接口的，要仔细研读它的数据手册，
2.在遇到问题时，要将问题的表现和特征记录下来，然后绘制问题要因图，然后对问题进行分析，排除无关因素，并对各个因素进行排序，逐个进行验证，验证过程和解决过程要详细记录，这个案例在编写的过程中就深有体会，由于这个问题在解决过程中并没有记录，所以导致在后期整理时，思绪很混乱。
3.在编写底层驱动时，不仅仅要考虑当前的驱动性能，还要考虑它的使用场景，然后再决定是使用查询方式还是使用中断方式等。