减去两个 uint32_t 变量会得到一种溢出的结果?
Subtracting two uint32_t variables gives a kind of overflowed result?
我正在编写一个 stm8s
微控制器,我正在使用 STVD
IDE 和 COSMIC
编译器。
两个uint32_t
变量相减的结果保存在另一个uint32_t
变量中。有时这个过程会产生一个奇怪的值。这个奇怪的值始终是预期值,最高有效位设置为 1s
.
这是我的代码片段:
static uint32_t lastReceivedLed = 0;
uint32_t timeSinceLast = 0;
timeSinceLast = IL_TimTimeNow() - lastReceivedLed;
if(timeSinceLast > 2500U)
{
Inhibitor = ACTIVE; // HERE IS MY BREAKPOINT
}
IL_TimTimeNow()
的定义如下:
volatile uint32_t IL_TimNow = 0;
uint32_t IL_TimTimeNow(void)
{
return IL_TimNow; // Incremented in timer ISR
}
以下是调试会话中的一些实际值:
timeSinceLast
应该是 865280 - 865055 = 225 = 0xE1
但是编译器计算出来的结果是4294967265 = 0xFFFFFFE1
请注意,最低有效字节是正确的,而其余字节在编译器的结果中设置为 1s
!
另请注意,这种情况只会偶尔发生一次。否则,它会按预期完美运行。
这是溢出了吗?什么会导致这种情况?
调试器中显示的值为:
- IL_TimNow = 865280
- lastReceivedLed = 865055
- timeSinceLast = 4294967265
请注意,4294967265 也是将 -31 转换为 uint32_t
时得到的结果。这表明 IL_TimTimeNow()
在减法之前返回的 IL_TimNow
的值实际上是 lastReceivedLed - 31
,即 865055 - 31,即 865024.
调试器 (865280) 中显示的 IL_TimNow
的值与减法前的 IL_TimNow
的值 (865024) 之间的差值为 256。此外,least-significant 两个值的8位都为零。这表明在 least-significant 字节回绕到 0 并且下一个字节递增时正在读取该值。 IL_TimTimeNow()
中的评论说 // Incremented in timer ISR
。由于 8 位微控制器一次只能读取一个字节,因此似乎定时器 ISR 在函数读取 IL_TimNow
的四个字节时发生。
有两种方法可以解决这个问题。第一种方法是在读取 IL_TimNow
的值时禁用 IL_TimTimeNow()
中的定时器中断。所以 IL_TimTimeNow()
函数可以改成这样:
uint32_t IL_TimTimeNow(void)
{
uint32_t curTime;
disable_timer_interrupt();
curTime = IL_TimNow;
enable_timer_interrupt();
return curTime;
}
但是,您需要检查暂时禁用定时器中断只会导致中断被延迟,而不是完全跳过(否则您将失去定时器滴答声)。
另一种解决问题的方法是在IL_TimTimeNow()
中继续阅读IL_TimNow
,直到得到两个相同的值。所以 IL_TimTimeNow()
函数可以改成这样:
uint32_t IL_TimTimeNow(void)
{
uint32_t prevTime, curTime;
curTime = IL_TimNow;
do
{
prevTime = curTime;
curTime = IL_TimNow;
} while (curTime != prevTime);
return curTime;
}
do ... while
循环通常会有一个迭代,读取 IL_TimNow
两次。偶尔会循环两次,读取IL_TimNow
三次。实际上,我不希望循环迭代超过两次,但该函数也可以处理。
一个不太安全但可能稍微快一点的版本是当 least-significant 字节为 0 时只读取 IL_TimNow
两次:
uint32_t IL_TimTimeNow(void)
{
uint32_t curTime;
curTime = IL_TimNow;
if ((curTime & 0xFF) == 0)
{
// Least significant byte possibly just wrapped to 0
// so remaining bytes may be stale. Read it again to be sure.
curTime = IL_TimNow;
}
return curTime;
}
如果性能不是问题,请使用更安全的版本之一。
我正在编写一个 stm8s
微控制器,我正在使用 STVD
IDE 和 COSMIC
编译器。
两个uint32_t
变量相减的结果保存在另一个uint32_t
变量中。有时这个过程会产生一个奇怪的值。这个奇怪的值始终是预期值,最高有效位设置为 1s
.
这是我的代码片段:
static uint32_t lastReceivedLed = 0;
uint32_t timeSinceLast = 0;
timeSinceLast = IL_TimTimeNow() - lastReceivedLed;
if(timeSinceLast > 2500U)
{
Inhibitor = ACTIVE; // HERE IS MY BREAKPOINT
}
IL_TimTimeNow()
的定义如下:
volatile uint32_t IL_TimNow = 0;
uint32_t IL_TimTimeNow(void)
{
return IL_TimNow; // Incremented in timer ISR
}
以下是调试会话中的一些实际值:
timeSinceLast
应该是 865280 - 865055 = 225 = 0xE1
但是编译器计算出来的结果是4294967265 = 0xFFFFFFE1
请注意,最低有效字节是正确的,而其余字节在编译器的结果中设置为 1s
!
另请注意,这种情况只会偶尔发生一次。否则,它会按预期完美运行。
这是溢出了吗?什么会导致这种情况?
调试器中显示的值为:
- IL_TimNow = 865280
- lastReceivedLed = 865055
- timeSinceLast = 4294967265
请注意,4294967265 也是将 -31 转换为 uint32_t
时得到的结果。这表明 IL_TimTimeNow()
在减法之前返回的 IL_TimNow
的值实际上是 lastReceivedLed - 31
,即 865055 - 31,即 865024.
调试器 (865280) 中显示的 IL_TimNow
的值与减法前的 IL_TimNow
的值 (865024) 之间的差值为 256。此外,least-significant 两个值的8位都为零。这表明在 least-significant 字节回绕到 0 并且下一个字节递增时正在读取该值。 IL_TimTimeNow()
中的评论说 // Incremented in timer ISR
。由于 8 位微控制器一次只能读取一个字节,因此似乎定时器 ISR 在函数读取 IL_TimNow
的四个字节时发生。
有两种方法可以解决这个问题。第一种方法是在读取 IL_TimNow
的值时禁用 IL_TimTimeNow()
中的定时器中断。所以 IL_TimTimeNow()
函数可以改成这样:
uint32_t IL_TimTimeNow(void)
{
uint32_t curTime;
disable_timer_interrupt();
curTime = IL_TimNow;
enable_timer_interrupt();
return curTime;
}
但是,您需要检查暂时禁用定时器中断只会导致中断被延迟,而不是完全跳过(否则您将失去定时器滴答声)。
另一种解决问题的方法是在IL_TimTimeNow()
中继续阅读IL_TimNow
,直到得到两个相同的值。所以 IL_TimTimeNow()
函数可以改成这样:
uint32_t IL_TimTimeNow(void)
{
uint32_t prevTime, curTime;
curTime = IL_TimNow;
do
{
prevTime = curTime;
curTime = IL_TimNow;
} while (curTime != prevTime);
return curTime;
}
do ... while
循环通常会有一个迭代,读取 IL_TimNow
两次。偶尔会循环两次,读取IL_TimNow
三次。实际上,我不希望循环迭代超过两次,但该函数也可以处理。
一个不太安全但可能稍微快一点的版本是当 least-significant 字节为 0 时只读取 IL_TimNow
两次:
uint32_t IL_TimTimeNow(void)
{
uint32_t curTime;
curTime = IL_TimNow;
if ((curTime & 0xFF) == 0)
{
// Least significant byte possibly just wrapped to 0
// so remaining bytes may be stale. Read it again to be sure.
curTime = IL_TimNow;
}
return curTime;
}
如果性能不是问题,请使用更安全的版本之一。