|
| | | | | | | 没有空间放时钟芯片啊 也不能从网络获取时间 这种情况有没有其他的办法修正啊
|
|
|
| | | | | 32.768k是经验使用较稳定的RCT时钟频率,65535的一半。 |
|
|
|
| | | | | | | 还有一个问题 假如能联网 也有波特率误差的问题 就是GPS模块发给MCU的波特率 (因为最终LCD的显示是由MCU来显示) 如果波特率是115200 实际是11500 那么能算出一天的误差吗?也是有误差的
|
|
|
| | | | | 精度取决于32.768晶振精度,需要主要晶振和它负载电容的匹配 |
|
|
| | | | | 不通过网络还可以通过其他信号校时,比如北斗、电视、甚至开机
因为32.768K是二进制的一个整数,可以一直被2整除到2
|
|
|
| | | | | | | 还有一个问题 假如能联网 也有波特率误差的问题 就是GPS模块发给MCU的波特率 (因为最终LCD的显示是由MCU来显示) 如果波特率是115200 实际是115000 那么能算出一天的误差吗?也是有误差的 你会计算吗?我说的是这个问题啊
|
|
|
|
| | | | | | | | | | | 不管你怎么引入 你的模组从服务器获取到的时间是不是要串口发给MCU?串口通讯是不是要设置号波特率???
|
|
|
| | | | | | | | | | | | | 只是引入一个校准时刻,其余时刻有晶振精度保证,与波特率没有半毛钱关系
比如刚才开机校准方案:开机上电延时1s,然后靠晶振从0点0分0秒开始计时,你每天23点59分59秒开机,这一整天都是精确的。通讯都不需要,与波特率有啥关系?
|
|
|
| | | | | | | | | | | | | | | 软件用的不是这种方式,你的方式不知道你基准时间从那里获取 |
|
|
| | | | | | | | | | | | | | | | | 只是告诉你,校时一是与传输波特率没有关系,二是也可以不通过网络获得,但一定都是来源于北京时间或者格林威治。
|
|
|
| | | | | 假如能联网 也有波特率误差的问题 就是GPS模块发给MCU的波特率 (因为最终LCD的显示是由MCU来显示) 如果波特率是115200 实际是115000 那么能算出一天的误差吗?也是有误差的.这个是我合作的一个软件工程师遇到的实际问题。因为MCU不能跑那么高的频率,只能用4M的晶振,后面需要115200跟无线模组通讯,那么经过单片机原厂的FAE计算,需要的晶振是7.0几MHZ,也是有这种频率的,结果放上去是有偏差的,因为MCU是不支持这个晶振频率的,但是也没其他的办法,不可能改芯片,因为涉及到算法,换芯片周期太长了,所以误差就出现了。。。这种误差能算出来不?关于波特率偏差导致MCU和无线模组通讯误差,然后时间也有误差
|
|
|