STM8S103K3的TIM1的Encode mode能用吗？

        留言称，之前用STM32的定时器做过正交编码应用，一切正常。换到STM8S103K3 后，折腾若干天了计数器就是不工作。外围硬件一样，代码配置流程一样，无非代码书写表达上有点差异。他使用的是TIM1，基于库函数写的，配置上并无啥明显问题。我查看8S103k3的CH1、CH2 所对应的管脚，也无需要特别配置的地方。

        考虑它对这个功能应用很熟悉了，加上他说折腾若干天了，不怎么怀疑他硬件上的原因。我甚至有点担心库函数是否有不完善的地方，建议他依照手册里的配置流程用操作寄存器的方法重新配置下，顺便也做些检查确认。

    后来过了一天时间，他反馈问题解决了，原因是管脚option方面的配置问题，即管脚复用重映射的问题。我明明记得8S103k3 TIM1的CH1、CH2 所对应的管脚不存在重映射问题的，便再次跟他确认芯片型号到底是不是8S103k3，结果他回答说是8S103f3。

        哦，原来是这样，那问题就好理解了。遗憾的是他一直都是说STM8S103F3，的确是涉及到管脚复用选项配置的问题。就这个问题似乎经常有人碰到，之前我在相关文字里提到过两三次。这里不妨以STM8S103F3的PC6 、PC7为例再聊聊。

    这两个脚默认可以复用为SPI通讯脚，但旁边又用中括号[]分别标注TIM1_CH1、TIM1_CH2。这里的意思是说，如果要把这两个脚作为TIM1_CH1、TIM1_CH2的话，还必须在option字里对进行AFR[Alternate Function Remap]的选择。相关的具体细节介绍在各芯片的数据手册里。  

     顺便看看STM8S103K3的TIM1_CH1、TIM1_CH2功能脚，分别是PC1、PC2的默认复用脚，不需要额外作AFR的配置。

       虽说折腾了若干天，其实原因很简单。当然了，应该说找到了原因就简单，没找到原因前无所谓简单复杂，出不来就是出不来。其实，开发环节中，任何一个地方都可以把人卡住。这时候我们更需要冷静，对问题现象做些梳理分析后有步骤地行动。

        如果这位工程师之前没有用STM32做过类似项目，或许还不会像他说的折腾若干天。正因为基于STM32做过，对整个项目流程很清晰，他对这个技术点也相当自信。当在STM8S平台上遇到麻烦时，不自觉地把很多心思花在怀疑芯片上了。甚至没花心思把芯片型号及数据手册做些基本的了解和确认。记得半个多月前，一个客户因为两行STM8S芯片的时钟代码配置有问题，使得产品不稳定绵延几个月。该工程师也是过于自信，一直怀疑MCU不够稳定所致，而疏于做些基本的检查和确认【其实他代码也没多少行】。当最终找到原因后，终于说了句能不怀疑MCU芯片时就先不要怀疑MCU的问题。

        当然MCU芯片有问题、有BUG也正常，但不要一遇到问题就过早的下结论是芯片的问题,这样容易导致开发进度停滞不前。正常来讲，各公司的MCU往往会有相关的勘误手册发布出来，建议开发前就弄来扫几眼，防患于未然。

        对于ST MCU，各个系列或子系列一般也有出勘误手册，即Errata Sheet的文件，网上可以自行下载。下载不到可以找代理商的FAE索取，或者在本微信公众号里留言也行，我尽力协助。