tzz1983 发表于 2023-10-31 08:17:58

本帖最后由 tzz1983 于 2023-10-31 08:31 编辑

对于STC,是否 “当中断发生后,至少会执行一条指令,才能再响应新的中断” ?

个人认为不会,从STC的手册全文来看,没有一个地方明确指出类似的说法。

以下是个人对〈STC多级流水线内核的中断响应〉 多级连续中断响应的个人理解:

以前有些书箱把中断响应过程描述为调用指令“LCALL”行为, 但是很明显,中断响应比“LCALL”做的事情更多一点。
现在我假设中断响应的过程可以等效于一条名为“LCALL+”的指令 ,那么看以下推断:

1.    //产生了中断请求A
2.    _nop_();    // 不是特殊指令
3.    //产生了中断请求B,B的优先级高于A
4.    _nop_();    //不是特殊指令
5.    LCALL+A;// 中断请求A之后已经执行了两条指令 ->现在可以响应中断请求A, 转至A向量口
6.    LCALL+B;// 中断请求B之后已经执行了两条指令 ->现在可以响应中断请求B, 转至B向量口

如果以上假设成立, 可以看到中断A响应后,并没有执行任何代码,随即响应了中断B。 当然了,这只是个人假设前提下的理解,最终还是得要STC硬件开发来定音。



神农鼎 发表于 2023-10-31 09:07:21

STC32G12K128数据手册中的说明,
从传统STC89C52RC/Intel8051开始的比较








上面是讲传统8051,STC89C52RC/Intel8051
下面是讲STC32G12K128系列,这个新的32位8051








神农鼎 发表于 2023-10-31 09:17:19

STC8H8K64U数据手册中的说明,
从传统STC89C52RC开始的比较



下面是指传统8051,STC89C52RC/Intel8051


各种与中断相关的寄存器


下面指现代的STC8 系列的8位8051, STC8H8K64U为代表的








fanxsp 发表于 2023-10-31 09:26:52

本帖最后由 fanxsp 于 2023-10-31 10:01 编辑

tzz1983 发表于 2023-10-31 08:17
对于STC,是否 “当中断发生后,至少会执行一条指令,才能再响应新的中断” ?

个人认为不会,从STC的手册 ...
我也查了很多资料,我理解传统的51的中断响应过程是这样的:每个机器周期都会把中断信号锁存到中断请求标志中以及检测上一个机器周期锁存的中断请求标志,检测到中断请求标志后,如果符合条件(1.是指令的最后一个机器周期(也就是说 当前指令已完成)2. 当前指令为RETI或者是访问IE、IP、中断请求寄存器的指令,则该指令以及紧接其后的一条指令已执行完成)就开始中断响应,经过2个机器周期(硬件产生类似LCALL的指令)跳转到中断向量表。如果硬件产生的类似LCALL指令的时序和LCALL指令是一样的,就应该会响应高优先级指令,但时序也可能不同,这个最终只有设计芯片的人清楚。而且现在的51单片机和传统的51不一样,中断都有很多扩充,也可能不同厂家还不一样。

fanxsp 发表于 2023-10-31 09:33:50

本帖最后由 fanxsp 于 2023-10-31 09:43 编辑

神农鼎 发表于 2023-10-31 09:17
STC8H8K64U数据手册中的说明,
从传统STC89C52RC开始的比较


你这个分析没有错,现在我们关心的是,从开始响应中断,到跳转到中断向量表,单片机内部是怎么运行的,需要几个机器周期,在这几个机器周期中会不会响应更高优先级的中断。你分析的都是执行指令的情况,响应中断后,硬件自动跳转到中断向量表,这个算不算一条指令呢

神农鼎 发表于 2023-10-31 10:04:09

STC8H8K64U硬件决定自动跳转到中断向量入口地址
===就是LCALL的时间

tzz1983 发表于 2023-10-31 10:25:04

本帖最后由 tzz1983 于 2023-10-31 10:29 编辑

神农鼎 发表于 2023-10-31 09:07
STC32G12K128数据手册中的说明,
从传统STC89C52RC/Intel8051开始的比较


神农鼎先生,您好,你说的和我说的不冲突,但是并不是一回事. 手册上主要是说特殊指令对中断响应的延时效果,而我说是的一个中断响应以后可不可以立即响应另一个中断。如果说可以把中断响应看成LCALL+效果,LCALL+并不是特殊指令,那么我的推断是正确的

CosyOS 发表于 2023-10-31 10:41:18

本帖最后由 CosyOS 于 2023-10-31 11:18 编辑

中断响应过程分析


一:中断响应
"LCALL"   中断向量入口地址
................@SP <- 当前PC + 3;
................PC <- 中断向量入口地址


二:中断向量入口
"LJMP"    中断服务程序入口地址
................PC <- 中断服务程序入口地址


三:中断服务程序
INC   OSIntNesting; 中断服务程序入口第一条指令
PUSH ...
...
POP ...
RETI



"LCALL"、"LJMP",是说从原理上去理解,是相当于这两条指令,但真实的硬件执行逻辑可能有差异,不得而知。

按照我的理解,中断嵌套保护能否实现的关键在于,只要 "LCALL" 指令执行了,INC   OSIntNesting 指令就必须被执行,
才能达到嵌套保护的目的。从"LCALL" 到 INC 这一过程不能被更高优先级的中断打断,否则中断嵌套保护就会失效。
如果我的理解正确的话,这一过程能否被打断呢???


"LJMP" 似乎是真实的 LJMP 指令,单从这条指令来说,上述过程就可被打断。
然而也不绝对,还要看硬件设计上是否有相应的中断响应过程不被打断的机制。




fanxsp 发表于 2023-10-31 11:24:42

神农鼎 发表于 2023-10-31 10:04
STC8H8K64U硬件决定自动跳转到中断向量入口地址
===就是LCALL的时间

时间就 LCALL 的时间,这个没有问题。问题是,在这期间,会不会响应高优先级中断。

CosyOS 发表于 2023-10-31 11:32:40

不确定就是不可靠,所以... ...
页: 1 2 [3] 4 5 6 7 8 9 10 11 12
查看完整版本: uC/OS-II @Ai8051U 移植版,AI8051U,32G8K64,32G12K128