只要程序执行到空闲任务了，就用一个变量不停自加这样就可以根据变量值来大概计算空闲任务的执行时间但是这里又存在一个问题：如果这个变量一直自加，肯定会溢出，该怎么解决加大变量的大小，比如原先使用一个字节、两个字节的，那么如果溢出，就用四个字节、八个字节但32位系统最大能支持的也就8个字节了，如果还是溢出了咋办？再套一个循环，一个循环的数加完了，再加另一数就行了但是还有一个问题，如果说自加的时间不做限制，那么再多的变量也不行，而且还会影响CPU计算的实时性，也就不能实时反映CPU利用率了；而如果时间太短，如果刚好有任务的执行时间在这个范围，那么很可能你计算CPU利用率就直接是100%了比如说你一个任务需要执行10毫秒，然后你计算CPU的周期也是10毫秒，那么可能刚好开始计算时跳到了那个任务执行，那么你的变量就没有自加了，也就会显示100%利用率了这里其实说的是前面的第一个问题，一段时间是多少？对于这个时间，因为鱼鹰看的书籍比较少，所以也没有理论支撑（如果有道友知道的，不如留言）但是肯定既要考虑变量溢出（这个可以通过加循环方式解决），又要考虑实时性，还要考虑其他任务的最大执行时间，否则本来系统没有问题的，但是因为你追求实时性，导致CPU利用率80%、90%的，那就很尴尬了以上讨论如果没有经验可能比较难理解，所以建议大家在看完后面内容，实操过后，再回头重新看一遍，这样才有更深的理解现在再看CPU计算公式：cpu_usage = (total_count – count）/ total_count × 100 %cpu_usage: CPU利用率；total_count：单位时间内全速运行下的变量值；count：单位时间内空闲任务自加的变量值total_count这个值表现了单片机全速运行下，所能达到的最大值所谓全速运行，即不响应中断，也不去执行其他任务，就单纯让它在一个地方持续运行一段时间，这个值可以体现CPU的算力有多大比如，51单片机，可能这个值自加10毫秒之后只有100，STM32F1单片机自加能到1000，而STM32F4单片机能到2000，这样就能体现他们之间的算力差别了这个值可以是动态的，也可以是静态的静态有静态的好处，动态有动态的好处所谓的静态是指，在系统没有运行任务时，关闭所有的中断，自加这个值这样，这个值比较准确，但是如果一开始这个值计算错了，那么后面的计算肯定也是有问题的，而且如果系统启动后长时间既不启动任务，也不响应中断，肯定对系统有一定的影响但是好处是，系统消耗更少，因为他只计算一次而动态计算，则是在空闲任务中，当这个值为零时，计算一次，之后只会在空闲任务自加的变量值超过这个数时，才会更新这个值，这样一来，最终还是能准确反映CPU利用率的好处是，不需要在开机时关闭所有中断，当然坏处是，前期可能不是很准，因为可能由于中断原因导致计算的值较小（中断处理时消耗了算力）废话太多了一些，直接开始干吧新建一个文件，拷贝如下代码：以上的代码网上找的，首先分析这两个宏，第二个宏就是前面所说的防止变量溢出用的，而第一个值就是CPU计算周期，这个值比较关键，后面再说首先在系统启动前设置钩子函数：然后，就没有然后了对的，设置完之后就可以了，但为了让我们能观察到，可以打印出来我们可以观察效果如何，开始设置计算周期和任务延时函数一样，10毫秒测试结果：可以看到，因为是动态计算的，所以开始为0，因为系统首先运行其他任务，只有其它任务不运行时，才会开始运行空闲任务，所以CPU利用率为0但是即使后面有值了，你也会发现CPU利用率变化很大，0.82%~1.5%而且你会发现除了开始的0.0%，后面又再次出现了，这又是怎么回事？通过设置断点分析，发现，这是因为计算值超出了开始的值，重新设置了：这就是动态计算的一些问题了，它在一开始的一段时间里，因为无法完全表现算力，只能通过后面不停的修正该值才能达到稳定现在修改计算周期 20 毫秒：发现它的表现更差劲，4.3%~11.61%，而且会周期性出现低利用率的情况再改，100毫秒：可以看到这个比较稳定了，13.71%~14.35%那么这个测试代码实际情况的CPU利用率是多少呢？我们可以通过前面的笔记《》大概计算线程执行时间：1.59毫秒，10毫秒执行周期，如果只有这个任务执行，大概1.59/10=15.9%（准确计算应该是 1.59/(10 + 1.59) =13.7%）和前面的100毫秒类似我们先不管前面的结果，先理解一下里面的计算方法首先，如果total_count开始为0，那么开始第一次计算这次计算会关闭调度器计算过后，就不再进入之后就是动态计算过程：和第一次计算一样，都是在一定时间内自加计数器，不同的是，这次不会关闭调度器，也就是说，如果有高优先级任务就绪，那么是可以执行其他任务的并且计时时间使用的是系统函数rt_tick_get()，单位为系统调度时间测试环境中，系统调度时间为 1 毫秒有意思的是，在进行最终的计算时，采用了分步计算，首先计算整数，再计算小数为什么要这样做？效率
这样的计算方法，可以将浮点运算转化成整型运算，这在没有浮点运算单元的单片机中，能大大减少计算时间另外，为了防止溢出，还使用了一个循环结构理解了以上内容，现在开始进行鱼鹰式深度思考：1、 上面的分步计算是否存在问题？2、 关调度器只关闭了任务调度，但还是会响应中断，这能够体现单片机最大算力吗？3、 使用rt_tick_get() 函数进行计时，精度是多少，会影响最终的计时吗？4、 有必要使用循环体吗？如果单位时间内不溢出，是否不用循环体会更好？5、 前面的CPU使用率为什么会跳动，按理说任务的执行时间应该是确定的，也只有一个任务在运行，不应该跳动才对？6、 10毫秒的计算和100毫秒的计算差别在哪？7、 终极问题，如何精确计算CPU使用率？上面的问题，如果只是粗略计算，其实都可以不用考虑，本着对技术的热爱，还是聊一聊好了1) 分步计算，不知道你想到了什么BUG？这个问题其实在以往的笔记都提过，这次再说一次当你在获取CPU使用率时，如果刚好在更新这两个值，那么可能整数部分是上一次计算的值，而小数部分却是这次计算的值，那么肯定有问题这就涉及到数据完整性获取的问题怎么解决关调度器、关中断都可以但是因为是粗略计算，那么小数部分即使是错误的，也没事2) 因为只关调度器，所以对于中断还是会响应，比如说你设定计算周期为100毫秒，那么1毫秒一次的systick中断肯定会执行，那么在100毫秒中，有100次进入中断执行，而这些算力在上述算法中是无法体现的3) rt_tick_get() 函数精度问题，因为这个是系统的软件计时器，所以在测试环境中为1毫秒递增一次，也就是说它的精度在1毫秒因此，在100毫秒的计算周期里面，有1% 的误差存在，在10毫秒的计算周期里面，误差10%
4) 有没有必要用循环体？在1秒计算一次的情况下，即使不用循环体，也不会导致溢出问题而且使用了循环体，还会导致精度降低，毕竟样本少了比如使用循环体最大值为100，不使用时为10000，哪个精度高？5) CPU使用率跳动问题因为是测试，所以只有一个任务在运行，而且任务很简单这个任务的执行时间应该是固定的才对，但即使是使用了后面的高精度计算方式，CPU使用率还是会跳动，这是为什么？第一，rt_kprintf函数执行时间是不固定的，不固定在哪，比如要显示的变量开始是1，后面是1000，因此它输出的字符串不一样，并且打印时间也不一样，因为是查询方式打印，所以差别很大
这就是我为什么推荐DMA打印的原因，未使用前是10%，使用后可能就是1%，甚至更低第二点，也是非常容易忽视的一点，插入的中断执行时间系统每隔1毫秒需要进入systick执行一次（或者其他中断执行时间），如果说任务的执行时间超过1毫秒，那么中间必然会先执行中断，再执行任务，这样一来，因为中断的插入，导致时间不再那么准确了而当你把打印的时间控制在 1 毫秒以内，那么CPU使用率会变的非常稳定第三：延时rt_thread_delay()函数本身的误差，受到系统精度的影响，这个延时时间其实也不是固定的，会有一定的浮动6) 10毫秒和100毫秒计算的差别？如果说你的任务执行时间小于1毫秒，那么在10毫秒和100毫秒的计算差别不是很大，但是如果说计算周期变成了5毫秒，即使任务执行时间小于1毫秒的情况下，计算值也是会在最大和最小之间来回跳动的而执行时间一旦超过1毫秒，那么10毫秒和100毫秒的计算就有较大的差别并且测试的时候，因为系统延时时间是10毫秒，而计算的时候也是10毫秒的周期，所以出现了比较诡异的事情，因为按理说延时10毫秒，任务执行时间2.56毫秒，任务运行周期为12 毫秒（还记得前面所说的延时误差吗），CPU 使用率按理应该是 21.3 左右，实际上却是 6.5% 左右，相差太大了，这就非常奇怪了而且如果更改执行时间为1.5毫秒时（通过修改代码修改执行时间），发现计算值又正常了；而即使不修改执行时间，修改计算时间为100毫秒，又正常了，这是怎么回事？通过深入分析发现，刚好在主任务延时10毫秒的时候，切换到了空闲任务进行空闲时间计算，执行了9.4毫秒的时候，又切回到了主任务，所以计算时，得到了6.5%的计算值粗略表示如下所示：通过这个分析，你应该知道，计算CPU的时候，尽量不要使用和任务延时时间一样的计算周期，否则会出现莫名其妙的事情；还有一点就是，任务的执行周期 = 任务执行时间 + 系统延时，而前面所介绍的计算方法只是粗略的表示，严格来说是有问题的7) 终极问题，如何提高计算精度？通过以上分析，我们其实已经知道了计算时的一些问题点首先，计算周期问题，这个可以根据系统来确定，但是千万要注意前面的提到的问题如果说500毫秒计算周期可以满足要求的话，就没必要使用50毫秒，不然你会发现计算值跳动很大其次，时间精度问题，这个问题老生常谈了，鱼鹰建议是DWT，如果没有，找一个定时器代替也是可以的最后是单位时间算力问题，为了保证精确，可以关闭中断进行第一次计算，或者用短一点的时间，比如1毫秒得到一个算力，如果计算周期为100毫秒，那这个算力乘以100就行了当然如果系统时钟不经常变的话，也可以通过静态方式先得到单位时间的算力，之后就以它为标准就可以了这样就不会有长时间关中断的情况出现了但是计算算力的时候，千万千万要注意一点的是，C语言转化为汇编代码时，可能一样的代码，在不同的地方执行时间是不一样的（比如前面代码的第一次计算和后面的计算，看似一样，但实际上有较大差别，原因就在于执行效率不一样），这个涉及到寄存器比内存效率更高的问题，所以计算算力时，可以把它封装成一个函数，这样，只要优化等级不变，那么函数的执行时间就可以认为是确定的有帮助的话，记得关注哦
（图片来源网络，侵删）
0 评论