我在淘宝上买了个clrc663的板子，他们用spi手动写了个读写uid的程序，完成了放冲突环的流程，但是我看14443A的协议，不知道怎么获得ATS，14443A的协议里面也没有写获得方式，而流程中需要获得ATS才能进入读写流程。
本问题已解决，查看RTC寄存器，RTC的寄存器的值是在实时改变的，但是，首先是RTC_TR寄存器（设置时间），然后是RTC_DR寄存器（设置日期），所以，应该先设置RTC的时间更新HAL_RTC_GetTime，然后再设置RTC的日期更新HAL_RTC_GetDate，最后，就能够解决HAL库中RTC时间更新不正确的问题了。
这是一个好办法，以前我一直认为extern "C" {......}修饰的函数里面不能出现C++的东西，原来只是说明该函数采用c方式编译，函数里面可以出现c++特性。这样理解对吗？
阻抗匹配一般问题不大，我们甚至在CAN总线上总电阻在40甚至30欧姆的情况下都能读到正确的CAN报文。当然官方建议还是两端各跨接一个120欧姆电阻。 1.认真规划总线使用波特率和ID分配。良好的ID分配应该有深入的考虑，例如CANOpen或者J1939都是很好的范例。通过ID定义报文的优先级，在出现总线竞争的时候能够仲裁胜出。此外，还要便于报文的过滤，一个CAN网络，在1秒内可能产生超过1k条的CAN报文，如果没有良好的过滤机制，筛选报文也是一个头疼的事情。 2.单个控制器向外界发送周期性报文的时候，可以考虑在其中加入一个Live值，就是每个报文中某个字段比前一个+1，这样当其他设备读到这个值不符合预期时，可以判断报文丢失或通讯错误。 3.节点的CAN控制器应该考虑仲裁失利是否重发，重发带来的问题是可能会一直被堵塞。 4.配置BUS OFF。当控制器发现自己发送错误帧超过一定数目的时候可以考虑主动脱离CAN网络。
请问这个问题解决了吗，我最近做的项目也出现这个问题，有2块板子有一块正常的，有一块查了几天了，还是有问题，每次更换好的芯片，刚开始正常工作，几次以后就出现VBAT电流过大对地电阻基本在欧姆级别。
估计是RTC读时间太频繁， 建议弄个几个变量，把日期和时间保存起来， 秒变量就在定时器里累加。 然后，每30秒，或者1分钟，更新一次日期和时间。 估计这样，就能减少出问题的机率。 再者，检查一下RTC和OLED的程序， 有没有用到while之类的死等待的语句， 如果有的话，增加超时机制，防止程序死等待。 这样，就能避免死机了。
微信公众号
手机版
