2019.1.5 晴

早上起来(指10点)看了下微信发现通知停暖气了……

终于调通了这块狗屎板子,昨天下午7点开始写,到凌晨2点也没完成。10点多起床又开始改,直到刚刚才完成。遇到的问题(我能想起来的)列在下边了。

我首先写的串口发送数据的子程序,写完之后直接烧进去试了一下,此时发送一切正常,收到的是设计好的字符串。然后我开始写采集数据的主程序,写完之后跑一遍试试,这时候按下确定键就卡死。

经过单步调试排查,确认问题出在定时器中断的按键读取上,在前一步写入显示的时候为了防止被中断,就关闭了按键扫描的定时器中断。下一条就是判断按键是否松开的死循环,读取到松开按键才会跳出循环……但是因为按键扫描被关了,所以永远读不到按键是否松开,也就出不去死循环了……

排除之后,继续测试,这时发现串口发送出现问题,无论调用发送子程序,发送什么内容,收到的均是00。删除与串口无关的函数调用与定时器初始化之后串口发送依然不正常,最后将程序删除到只剩串口发送部分,这时候发送不是00了,但,是乱码。更换板子烧写程序效果相同,排除了硬件问题的可能,将usb转串口的tx?rx对接自收发,排除了串口转换芯片的问题。找来之前写的串口发送程序,将串口部分子函数复制过来覆盖已有的子函数,测试无效果。整篇复制覆盖过来,发送恢复正常。一个个函数一个个定义添加上去,添加一个就编译烧写测试一次。直到程序恢复到最开始的结构,未能复现问题。至此,串口发送不正常的问题已解决但是仍然不知道原因。

接收端可以正常显示字符了,第一次发0001是正常的,第二次发0001就变成4097,第三次还是4097,紧挨着发0000就变成4096,再发0000就正常了。认为是存储数据的数组在一次使用完之后没有清空导致的,虽然我觉得下次写入的时候应该会覆盖上一次的数据,不需要清空,还是添加了一段数组清空的函数。编译测试发送0001正常,再发0001正常,发0000正常,发0010显示0016

继续排查,单步调试后发现问题出在拆分运算上。原来的拆分运算代码如下

num1=b/1000;
num2=b%1000/100;
num3=b%100/10;
num4=b%10;

更改后如下

num1=b/0x1000;
num2=b%0x1000/0x100;
num3=b%0x100/0x10;
num4=b%0x10;

编译测试,输出正常了。至此,全部debug工作完成。

最终感想:写程序太修身养性了