使用CUBE_MX生成带有free_RTOS操作系统的工程,我们经常会使用到系统相对时间,尤其是使用其做数据采集的项目中经常需要给你数据打上时间的标签就需要实时获取系统的相对时间。
当然,我们可以单独开一个时钟来计时,但是我们在使用操作系统的时候就已经选用了一个定时器,这个定时器做的事情很简单就是为操作系统提供时间节拍,如果我们能够使用这个时钟就能减少很多的初始化定时器的工作,而且能够省下一个定时器。
我们都知道使用cube_MX生成带有free_RTOS操作系统的工程中的时钟节拍都是1ms(当然这个时间有的选择,但是最好保持为默认的1ms)。于是,我们是否可以使用这个时钟节拍来获取我们所需要的系统时间,答案当然是可以的。在使用cube_MX生成的工程的main.c文件中可以找到HAL_TIM_PeriodElapsedCallback()这样一个函数,如下
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance == TIM6) {
HAL_IncTick();
}
}
我这边使用的是TIM6为操作系统提供基础时钟,这个定时器6的回调函数中有一个HAL_IncTick(),这个函数就是系统滴答时钟递增函数,是的,毫秒级别的,我们进入这个函数看看
__weak void HAL_IncTick(void)
{
uwTick += uwTickFreq;
}
里面就一条语句,很好理解,全局变量uwTick就是操作系统的滴答时钟计数器,于是我们只要在使用中获取到这个变量的数值就能获取操作系统的相对时间,相对于系统开始运行的时间的毫秒数。往下看一看,果然由这个提供变量数据的函数,所以我们直接使用这个函数就能获取操作系统相对的系统时钟
__weak uint32_t HAL_GetTick(void)
{
return uwTick;
}
在这里使用的是一个uint32_t的数据类型来表示操作系统的系统时钟,但是真的能够满足我们的需求吗?我们可以计算一下这个操作系统时钟的适用范围。可以使用如下公式计算从这个变量从开始计数到他置零经历的时间
sec: 2^32/1000 = 4294967296/1000=4294967.296
min: sec/60 = 71582.78826666
hour: min/60 = 1193.04647111
day: hour/24 = 49.7102696969
这样这个变量可以跑超过49天才会被置零,足够我们使用,但是要注意49天这个期限。
我们可以重新封装一下这个函数
uint32_t Get_sys_time_ms(void)
{
return HAL_GetTick();
}
完美,但是有时候我们需要精度更高的系统时间怎么办?
这很好办,操作系统使用的心跳是按照ms来计的,但是他对于我们所选用的系统定时的操作是us级别的,周期为999us,正好在一次定时器的中断到来的时候上升1ms,所以我们可以将HAL_GetTick()的毫秒时钟乘以1000然后叫上定时器的计数就可以获得系统的相对时间,us级别的。
uint32_t Get_sys_time_us(void)
{
uint32_t sys_us = 1000*HAL_GetTick()+TIM6->CNT;
return sys_us;
}
如此我们就提供了系统微秒级别的系统相对时间。但是这个更需要考虑时间的范围(量程),它只能表示几个小时。
到这里大家又想到了,使用两个数据来表示就可以获得更大的量程了,是的,这个很简单自己去完成就行。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)