STM32
直播中

史晓明

7年用户 943经验值
私信 关注
[问答]

模拟运行的代码时间和实际运行的代码时间非常不同是什么原因导致的?


我的工程需要用到tiM1_CC_IRQHandler中断,需要知道我写在里面的代码的准确具体的执行时间。
因此,在中断入口和出口设置断点,在断点处记录TIM1- gt;CNT的值(TIM1的时钟为72MHz,且已经设置了断点时TIM1停止运行,来获得准确的TIM1的值。)
首先我模拟运行,发现入口断点处TIM1- gt;CNT = 0x242,而出口处TIM1- gt;CNT = 0x0288,时间差是70个系统时钟;
而当我用JLink连接硬件实际运行时,发现入口断点处TIM1- gt;CNT = 0x245,而出口处TIM1- gt;CNT = 0x02DD,时间差是152个系统时钟!
模拟运行的代码时间和实际运行的代码时间非常不同!
那我到底是应该信任哪一个时间呢?

下面是我的代码:
Below is my ISR code:

#include “STM32f10x.h”
#define DBGMCU_TIM1_STOP  ((u32)0x00000400)
u16 CCR_Acc_x;
u16 CCR_Acc_y;

int main(void)
{
RCC- gt;APB2ENR = 0x0845;         //使能TIM1和GPIOA/E和AFIO时钟
GPIOA- gt;CRH = 0x0B;         //PA8,9配置为复用推挽输出,50MHz
TIM1- gt;ARR = 0xffff;         //ARR为最大值,使用CCR1和CCR2的比较匹配事件来产生中断
TIM1- gt;DIER = 0x06;         //使能中断CC1IE和CC2IE
TIM1- gt;CCMR1 = 0x3030;         //CH1和CH2都是输出比较模式(翻转)
TIM1- gt;BDTR = 0x8000;         //使能MOE主输出
TIM1- gt;CCER |= TIM_CCER_CC1E;         //使能CC1E输出
TIM1- gt;CR1 |= TIM_CR1_CEN;         //使能定时器
CCR_Acc_x = 562;
CCR_Acc_y = 18000;
TIM1- gt;CCR1 = CCR_Acc_x;
TIM1- gt;CCR2 = CCR_Acc_y;
TIM1- gt;CCR3 = 0xffff;
TIM1- gt;CCR4 = 0xffff;
NVIC_SetPriorityGrouping(4); //3 bits preemption
NVIC_SetPriority(TIM1_CC_IRQn, 0); //highest
NVIC_EnableIRQ(TIM1_CC_IRQn);
DBGMCU- gt;CR |= DBGMCU_TIM1_STOP;
while(1)
{
}
}

u16 TIM1_SR_mask;
void TIM1_CC_IRQHandler(void)
{//entrance breakpoint here
TIM1_SR_mask = TIM1- gt;SR;
if (TIM1_SR_mask  amp; TIM_SR_CC1IF)        //CC1IF
{
TIM1- gt;SR = ~TIM_SR_CC1IF;
TIM1- gt;CCR1 = TIM1- gt;CCR1 + CCR_Acc_x;
}
if (TIM1_SR_mask  amp; TIM_SR_CC2IF)        //CC2IF
{
TIM1- gt;SR = ~TIM_SR_CC2IF;
}
TIM1_SR_mask = TIM1- gt;SR;
if (TIM1_SR_mask  amp; TIM_SR_CC1IF)        //CC1IF
{
NVIC_SetPendingIRQ(TIM1_CC_IRQn);
}
if (TIM1_SR_mask  amp; TIM_SR_CC2IF)        //CC2IF
{
NVIC_SetPendingIRQ(TIM1_CC_IRQn);
}
}//exit breakpoint here

my Chip: STM32F103 ZET6
my IDE: Keil MDK 4.73
JLink 4.76d

回帖(1)

康辅佑

2024-5-18 17:38:25
模拟运行的代码时间和实际运行的代码时间之间的差异可能是由多种原因导致的。以下是一些可能的原因:

1. **硬件差异**:模拟环境通常在计算机上运行,而实际运行是在目标硬件上进行的。硬件的性能、时钟速度和资源分配可能与模拟环境有所不同,从而导致执行时间的差异。

2. **中断处理**:在实际硬件中,中断处理可能受到其他硬件中断的影响,而在模拟环境中,这种影响可能被忽略或简化。这可能导致实际中断处理时间与模拟中断处理时间之间的差异。

3. **编译器优化**:在模拟环境中,编译器可能对代码进行优化,以提高模拟的效率。然而,在实际硬件上,编译器优化可能与模拟环境中的优化不同,导致执行时间的差异。

4. **缓存和内存访问**:在实际硬件中,缓存和内存访问可能会影响代码的执行时间。而在模拟环境中,这些因素可能被忽略或简化,从而导致执行时间的差异。

5. **系统负载**:在实际硬件中,系统负载可能会影响代码的执行时间。例如,其他正在运行的任务可能会占用CPU资源,从而影响中断处理的执行时间。在模拟环境中,这种影响可能被忽略。

6. **调试工具的影响**:使用JLink等调试工具可能会对实际硬件的执行时间产生影响。调试工具可能会引入额外的延迟或改变硬件的行为。

为了获得更准确的中断处理时间,您可以尝试以下方法:

1. **优化模拟环境**:确保模拟环境尽可能地模拟实际硬件的行为,包括中断处理、硬件性能和资源分配。

2. **减少编译器优化**:在实际硬件上编译代码时,尝试减少编译器优化,以便更准确地模拟实际执行时间。

3. **隔离中断处理**:在实际硬件上运行时,尝试隔离中断处理,以减少其他硬件中断和系统负载的影响。

4. **使用性能分析工具**:使用性能分析工具(如JLink的性能分析功能)来测量实际硬件上的中断处理时间,以便更准确地了解代码的执行时间。

5. **多次测量**:多次测量中断处理时间,以获得更可靠的数据。这可以帮助您识别可能的异常值,并更准确地估计中断处理时间。

通过采取这些措施,您应该能够更准确地估计实际硬件上的中断处理时间,并减少模拟运行与实际运行之间的差异。
举报

更多回帖

发帖
×
20
完善资料,
赚取积分