人中狼 发表于 2017-7-17 13:57
好像是这样，如果不退出中断，应该不会再响应同一个中断，所以在中断里尽量避免用延时类函数。
这类情况的处理应该是在定时中断里开启或关闭蜂鸣器，蜂鸣器的开启时间最好是定时器溢出时间的倍数，通过状态标志来判断应该是开启，还是关闭蜂鸣器。 ...

实际上根据我的实验效果看
只要delay函数不超过interrupt函数的时间就没有问题
当delay函数在执行++操作时 中断函数并没有被delay打断
而是按照他原来自己的时钟执行 所以我初步判断只要delay函数的时间小于
中断这个程序就不会有错，但是应该把delay时间调短一点 要不然就失去了中断节省CPU的意义了
中断函数并不是执行到delay就把自己的模式中断 简而言之他们是两个完全独立的
只有当中断溢出的时候才会中断CPU当前操作。 不知道我想的对不对

是的，因为beep里延时的存在对你中断函数是绝对有影响的。不能仅仅根据实际效果好像没啥大问题就放任不管，养成习惯了以后迟早要吃亏。
【玩】蜂鸣器连叫
http://bbs.elecfans.com/jishu_514253_1_1.html
(出处: 中国电子技术论坛)
这是我以前发的一个蜂鸣器的帖子，也是利用定时器实现蜂鸣器的叫的，你可以参考一下。

moon548834 发表于 2017-7-17 20:17
但我认为
假设中断函数你的溢出是500ms 只要你的延时函数小于500ms就对这个中断应该没有任何影响
只是会增加cpu的负担。

你理解的基本正确，假设的例子不可能，什么定时器中断能长达500ms，12M时钟最长只能65ms，中断程序耗时过长也不符合使用中断的原则。在实际应用中常会使用中断嵌套，很有可能发生冲突。

moon548834 发表于 2017-7-17 20:17
但我认为
假设中断函数你的溢出是500ms 只要你的延时函数小于500ms就对这个中断应该没有任何影响
只是会增加cpu的负担。

如果你有2个中断在进行任务操作，中断本身的目的就是为了快速响应。如果高优先级的中断先中断了，结果进去以后来个delay延时，恰巧低优先级的任务需要执行，那这效率就大打折扣了。

moon548834 发表于 2017-7-17 20:17
但我认为
假设中断函数你的溢出是500ms 只要你的延时函数小于500ms就对这个中断应该没有任何影响
只是会增加cpu的负担。

还有啊，中断里加延时也会导致你的超级大循环的效率降低，比方说你在主函数里用延时做个闪灯，由于中断延时的问题，主函数的闪灯时间也将变得不可确定。  当然如果你觉得这些都是假设，那就按照自己的理解来。