Overflow
static volatile uint32_t timerx_micros_counter = 0;
static volatile uint32_t timerx_millis_counter = 0;
void TIMX_IRQHandler(void)
{
if(TIM_GetITStatus(TIMx, TIM_IT_Update)==SET)
{
timerx_micros_counter += 20000; // 20000us each overflow=20ms
timerx_millis_counter += 20; // 20ms each overlflow
...省略
}
TIM_ClearITPendingBit(TIMx, TIM_IT_Update);
}
uint32_t XXX_Scheduler::micros()
{
uint32_t time_micros, tcnt, current;
do
{
time_micros = timerx_micros_counter;
tcnt = TIM_GetCounter(TIMx);
}
while(time_micros != timerx_micros_counter);
current = time_micros + tcnt;
return current;
}
简要分析
首先,timerx_micros_counter是一个32位寄存器最大也就是4294967296。
其中每一个数表示1us，稍微计算一下就知道了，这里的timerx_micros_counter顶多会在71.58分钟的时候，溢出。
而micros()这个函数其自身意义是显示当前系统从启动开始到现在的时间。
在Pixhawk中的任务调度系统中起关键作用，所以如果这个函数出了问题，那么带来的就不是一点点问题了，可能整个系统都会挂掉。
而根据我对Pixhawk的感觉来说，写代码人和飞行的人大概都觉得71分钟溢出，太久了，飞行器电池根本撑不了那么久。
然而实际情况却不是这样的，很多时候调试时不断电，只是不起飞而已，那么这个系统时间依然在走。
如果你飞行时间都刚好在71分钟内，那肯定不会出问题，但是如果你刚好越过了它，那就是机毁人亡。
当然上面的分析是针对使用了32位的数据类型来做计数的，而且Timer每滴答一次是1us的基础上才会这样，其他情况要具体问题具体分析。
解决方案
扩大数据类型
既然32位数据类型会溢出，那么使用64位不就可以了吗？
数据扩大了一倍，根本不可能出现问题了。
uint64_t
long long
想也知道,修改了micros()的返回值类型，造成的结果就是，所有使用了micros()的地方，全部都需要修改数据类型。
整个系统和时间有关的函数基本都要改，修改量真的是非常大。
就算是封装了那么多的接口，面对这样的问题依然没办法。
除了这里有一个数据类型的问题，还要考虑STM32以及Keil对于64位数据类型的编译和运算问题，很有可能返回的时候出现问题。
http://www.openedv.com/thread-82038-1-1.html
比如这里，虽然他是用了keil的自带模拟查看的结果，可能不够准确，需要去拿板子实际测试一下才行。
经过测试：
static volatile uint64_t timer5_micros_counter = 0x600000000;
void TIM5_IRQHandler(void)
{
//TIM5的中断
if(TIM_GetITStatus(TIM5, TIM_IT_Update)==SET)
{
timer5_micros_counter += 20000; // 20000us each overflow
timer5_millis_counter += 20; // 20ms each overlflow
}
TIM_ClearITPendingBit(TIM5, TIM_IT_Update);
}
uint64_t micros()
{
uint64_t time_micros, tcnt, current;
do
{
time_micros = timer5_micros_counter;
tcnt = TIM_GetCounter(TIM5);
}
while(time_micros != timer5_micros_counter);
current = time_micros + tcnt;
return current;
}
int main(void)
{
uint64_t timenow=0;
uint32_t *first,*second;
delay_init(168);
uart_init(115200);
//TIM5 20ms一次中断 每次+1=1us
_init_timer(5, 20000-1, 84-1);
while(1)
{
timenow=micros();
first=(uint32_t*)&timenow;
second=first+1;
printf("\r\n 当前系统时间: %d %d %lld \r\n",*first,*second,timenow);
delay_ms(500);
}
}
测试结果：
[13:46:44.325]收←◆
当前系统时间: 3042703 6 25772846479
[13:46:44.829]收←◆
当前系统时间: 3546520 6 25773350296
[13:46:45.333]收←◆
当前系统时间: 4050337 6 25773854113
[13:46:45.837]收←◆
当前系统时间: 4554154 6 25774357930
[13:46:46.340]收←◆
当前系统时间: 5057971 6 25774861747
[13:46:46.843]收←◆
当前系统时间: 5561788 6 25775365564
[13:46:47.350]收←◆
当前系统时间: 6065606 6 25775869382
说明使用64位是没有问题的，至少STM32F4这里是没问题的。
调整TIMER滴答时间
既然Timer是一次1us，那么我只要让他这个表示的时间久一点，那么带来的结果自然是溢出时间也变久了。
比如把Timer调整为0.5MHz，或者更低的情况，这样就可以在不动数据类型，不修改任何接口的情况下，完成溢出的问题。
但是这样也有一个无法避免的缺点，那就是统计时间的精度下降了，而且除了这一点，如果IMU连着也用了这个函数进行姿态积分
那么计算的精度变差了，漂移时间也多了一些，整个稳定度会有所降低，但是具体降低多少，这个要实际测试，结合Timer降低的频率来看。
最重要的是，其实还是在使用micros()的时候，这里表示的意义，不再是系统启动后过了多少us
而是系统启动后过了多少2us，这个意义就和之前不同了。
而且中断也对应变成了40ms一次的中断了。
除了这里需要改一下，还有使用这个接口的地方也需要改，需要把得到的时间差*2，从而获得正确的时间差。
复合数据类型
既然不能保证64位数据类型运算时，不出一点错，还要考虑兼容的问题，那么就用一个Struct类型，包含更多的基础变量，从而保障这一结构体没有问题。
当然如果要这样做，和改成64位数据类型一样，也需要修改所有相关联的地方。
增加溢出标志
既然已知是会溢出的，那么加一个标志计数器，用来统计溢出次数。
将上面的程序稍微修改一下就行，只是接口部分还是需要修改加上检测溢出情况的。
Exception
三月份就发现了溢出,但是这个异常直到12月份才抓到,所以才重写了这个部分
void Copter::loop()
{
// wait for an INS sample
while( ins_sample_time + 2500 > micros() ) {
if( (ins_sample_time+2500) - micros() > 1500 )
delay(1);
else if( (ins_sample_time+2500) - micros() > 200 )
delay_microseconds(200);
else if( (ins_sample_time+2500) - micros() > 20 )
delay_microseconds(20);
else
delay_microseconds(1);
}
uint32_t timer = micros();
ins_sample_time = timer;
整个系统发生错误就是在这里,这个作为整个飞控的主循环是要保证2500us执行一次的,如果执行时间短于2500us则要在这里做延迟,而如果超过了2500us则直接进行下一步.
乍一看好像代码没有错,但是如果计数器溢出并且刚好时间是超过2500us的情况,就会发生71分钟甚至更久的延时等待情况
比如:
ins_sample_time = 0xFFFFDAF1
这时 ins_sample_time+2500 = 0xFFFFE4B5
但是由于一次loop执行时间超过了2500us,当程序执行到这里的时候micros()已经发生了溢出,那么这时micros()的返回值必然会很小,0x00000001F
ins_sample_time + 2500 > micros() 就会出现必然成立的情况,就会出现一直等待的问题,至于恢复时间则完全要看发生溢出时的值是多少了,最少也要等待71分钟才能恢复正常.
而事实上这里的代码完全可以换一种方式,就能直接避免出现这样的情况了
减法做差
while( micros() - ins_sample_time < 2500 ) {
if( (micros() - ins_sample_time ) < 1500 )
delay(1);
else if( micros() - ins_sample_time ) < 2300 )
delay_microseconds(200);
else if( micros() - ins_sample_time ) < 2480 )
delay_microseconds(20);
else
delay_microseconds(1);
}
事实上由于这里存储时间都使用的是32位无符号整数,所以在计算差值的时候,就不应该使用加法然后做差,永远保证使用较大的数去减较小的数来做判断,就不会出现上述的异常了
总结
从某种程度上来说，这个函数规划的的时候就没有做好导致了现在这个结果。
在关于系统时间，计数器上一定要注意是否会溢出的问题。
不能以当前系统电力可持续时间来估计，而是以其十倍甚至百倍的时间来估计时间是否会溢出问题。
差值判断使用减法,可以避免出现一些溢出性的错误
Quote
https://www.arduino.cc/en/Reference/Micros
http://www.openedv.com/thread-82038-1-1.html