【问题标题】:What is a normal interrupt latency and context saving time on Microchip C18?Microchip C18 上的正常中断延迟和上下文保存时间是多少?
【发布时间】:2011-06-20 20:51:58
【问题描述】:

我正在使用 Microchip C18 编译器,在发生中断时,我在 ISR 代码开始运行之前经历了相当长的延迟。

作为一个实验,这是我的主要功能:

while(1)
{
    LATAbits.LATA4 = 1;
    LATAbits.LATA4 = 0;
}

作为中断处理程序,我使用的是从一些示例中复制的代码(我不知道为什么会这样):

#pragma interrupt high_isr
void high_isr(void)
{
    LATAbits.LATA4 = 1;
    LATAbits.LATA4 = 1;
    LATAbits.LATA4 = 0;
    LATAbits.LATA4 = 1;
    LATAbits.LATA4 = 1;
    LATAbits.LATA4 = 0;
}

#pragma code high_vector=0x08
void interrupt_at_high_vector(void)
{
_asm GOTO high_isr _endasm
}

我通过 SPI 接收字节,在接收到一个字节后不久,主循环停止。然后在 ISR 代码开始运行之前有 16.5 µs 的延迟。也就是 165 个指令周期!

enlarge image

我知道有一些与中断相关的上下文保存,而且低优先级中断更糟糕。我已禁用 IPEN 并且仅使用高优先级向量。 165条指令是上下文保存的正常持续时间吗?

【问题讨论】:

    标签: microcontroller interrupt pic pic18


    【解决方案1】:

    在某些情况下,中断开销可能与您的一样大!
    看看this

    【讨论】:

    • +1 我知道这一点,但我认为实际上调用的函数需要很长时间。很好的常见问题解答。
    【解决方案2】:

    从 PIC 上的中断中获得良好性能的关键是最大限度地减少所需的上下文保存/恢复代码的范围。在许多情况下,这意味着用机器代码编写中断处理程序的时间关键部分。在至少有一些可用于中断使用的未分组寄存器的部分上(我真的不喜欢 Microchip 决定吞噬大部分或全部公共存储区用于 FSR2 寻址,而不是分配例如 15 个字节用于 FSR2 寻址,每个 7 个字节用于FSR0 和 FSR1 寻址,以及为每个 FSR 提供​​一个“魔术操作”寄存器 [我很乐意讨论这些事情的想法])有时可以在没有 任何上下文保存/恢复的情况下通过常见情况。例如,在我的一个 14 位 PIC 项目中,我需要每 1000 个时钟周期产生一次中断。因此,在禁用 RTCC 预标量的情况下,我的中断类似于:

    中断入口: bcf INTCON,TMR0IF decfsz int_counter,f 回复 movwf saveW movf 状态,w clrf 状态;银行 0 movwf 保存状态 movlw 4 movwf int_counter movlw 1024+3-1000 ' TMR0 未调整时间,加上 3 'slip',减去所需时间 addwf TMR0,f bsf INTCON,GIE ;在这一点之后,中断可以安全地嵌套! ...其他中断的东西 movf saveStat,w movwf 状态 交换保存W 改版;也可以使用 RETURN,因为启用了中断

    请注意,在 3/4 的情况下,中断将在执行了多达 3 条指令后返回,从下面执行的任何代码总共需要大约 6 个周期。

    【讨论】:

    • 问题是关于 C18 编译器的。尽管可能会有所帮助,但除非您将其放在上下文中,否则我无法对您的答案做出正面或反面。我什至不知道把这个内联汇编代码放在哪里。
    猜你喜欢
    • 2015-12-28
    • 2021-06-25
    • 2019-03-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-01-25
    • 1970-01-01
    • 2012-05-16
    相关资源
    最近更新 更多