本帖最后由 makesoft 于 2019-12-1 20:58 编辑
没想到51的小程序调试起来这么麻烦,花了整整两天时间,让俺这老江湖汗颜。
其实就是偷懒造成的,一个函数在程序初始化时使用,这个时候系统任何中断并没有打开,另外这个函数在定时中断中也有使用,天真的认为不存在同时调用的可能,所以不可能存在再入的问题,就是没理会重复调用的告警信息。
后来程序不定时的出现问题,因为开始已经有了不可能同时调用再入这个函数的场合,所以就没有检查这个问题。
实在没有办法,刚才检查MAP信息,TNND才发现,其实不仅仅有再入的问题,这个函数使用的局域变量占用的地址,有一个是和其他函数是重复覆盖使用的,真相大白了,两天时间就是不想写一个reentrant,因为会增加一点点代码。
慢慢的,现在也开始偷懒了,中断中也不时出现函数了,看来是警觉性落后了呀!!
其实我从来都不同意函数不放中断的这种说法,整个CPU运行时间计算好了,各种中断优先级事先规划好了,中断里的函数运行时间是可预测的,这样的程序是没有任何问题的。
天天说中断里面不放函数的,我搞不清楚程序代码量有多少,1000行还是10000行还是十万行?这几种情况当然做法也是完全异同的,大程序有大程序的构架,小程序有小程序的做法,不能一概而论。
哎,不知道你有没有体会过,小众行业,项目驱动的研发,老板和客户的需求总是随心所欲,有时候更是变态的;
“这个项目就是要快,慢了就黄了,你不知道竞争有多么激烈,要快,马上要发货......
这个中断处理信号10us后要跟随xx信号动作, 持续时间需要多100us。如果xx信号检测到了动作,又要xxxx.........”
无数个这样的需求,能有具体的要求还是不错的,就怕那种,老板和客户都只是要这个结果,具体怎么实现也不清楚,对于某些指标就是要反应快,
不得不在中断中完成。而且还可能跟持续时间扯上关系,还有就是好几个中断信号,相互交叉。发货就是要快!!!!
这种情况下,写出来捉急的代码可能性是很高的!!
老板的逻辑是,先拿出货物出去交给客户再说,就算以后有bug,生意至少还由得做;拿不出东西,生意就黄了。
一周热门 更多>