嵌入式开发：周期调度和代码执行时间理解_嵌入式处理器处理一个函数的时间与那些因素有关(1)

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

程序员按照需求，负责写代码，这些代码最终被CPU执行，进而控制执行器，以此达到预期功能。如果想要达到预期功能，对应的功能代码就要被CPU执行，多长时间执行一次呢？答：这取决于具体的功能。比如：收音机开启检测功能，此功能对应一段代码（eg：Check_AF_Switch()）。驾驶员想要打开车载收音机，触发动作10s以后，收音机打开可以吗？答：可以，但是，驾驶员的体验会非常不好。所以，对于打开车载收音机的检测就应设计一个合理的检测周期，以便于及时捕获驾驶员的意图。假设：10ms周期检测驾驶员是否有打开车载收音机的请求，那这10ms如何理解呢？答：10ms就是收音机开启与否的检测频率，在这10ms的时间内，CPU要完整执行一次Check_AF_Switch()代码。所以，代码开发中，往往会将Check_AF_Switch()这段代码放到10ms Task中，即：让Check_AF_Switch()这段代码每10ms执行一次。

那么，Check_AF_Switch()这段代码执行时间等于10ms吗？答：显然不是。10ms，是CPU去执行Check_AF_Switch()这段代码的频率，并不是Check_AF_Switch()这段代码执行一次所要花费的时间，实际上，Check_AF_Switch()这段代码执行一次花费的时间要远远低于10ms（eg：100ns）。Check_AF_Switch()调度频率与执行时间示意如下所示：

（一）CPU时钟周期与指令执行时间理解

我们知道，高级语言代码（eg：C语言）汇编后，变成一个一个汇编指令（注意：不同架构的单片机，汇编指令不同），一个汇编指令具体需要多少个CPU时钟周期，在芯片的用户手册中会有说明。比如：Aurix单片机的指令，需要的指令时钟周期，示例如下：

eg：ADD指令，需要一个CPU Clock即可完成。如果CPU的主频为300MHz，意味着ADD指令仅需要1 / 300000000 ≈ 3.33ns即可完成。我们对CPU执行一个指令花费的时间有了一定认知，也就能认识到：CPU执行一段代码，实际花费的时间并不多。假设：Check_AF_Switch()有100行代码，汇编后有200个指令，每个指令需要1个CPU Clock，则Check_AF_Switch()代码执行一次，需要耗费200*3.33≈666ns，都不到1us，所以，相对于一个10ms的Task，Check_AF_Switch()这段代码执行的时间是极小的。

既然CPU执行速度很快，一个Task的代码量有限，那么，CPU执行完一次Task中的代码，下一次执行时间还没到，CPU在干啥呢？答：“偷懒”。假设：CPU仅有一个10ms周期性Task，Task中代码执行需要2ms，这意味着CPU有8ms时间可以去"偷懒"。既然偷懒，就别让人看到，去空闲Task呆着去，这也就是工程上常说的Idle Task（空闲任务，优先级最低）或者Background Loop（背景loop），示意如下：

（三）如何理解CPU使用率和CPU负载

在汽车嵌入式开发中，我们往往会关注一个参数：CPU负载。CPU负载和CPU使用率有什么不同呢？假设：系统只有一个CPU，也就是单核处理器，这个CPU仅需要处理一个10ms周期的Task，执行这个Task中的代码需要花费2ms，则CPU有效使用率就是20%，这和我们常说的CPU负载有什么关系呢？答：个人理解，工程中常说的CPU负载应该是这里的CPU使用率。真正的CPU负载又怎么理解呢？假设：一个CPU分配了3个Task：

• 20ms Task1，优先级最低，对应代码完整执行一次需要6ms；
• 5ms Task2，优先级中等，对应代码完整执行一次需要1ms（下图中的10应该是5）；
• 5ms Task3，优先级最高，对应代码完整执行一次需要3ms。

三者使用CPU的关系如下所示：

如上图，Task1并不能在20ms时间内，完整执行一次对应的代码，虽然此期间，CPU一直在干活（CPU使用率100%）。由于Task1的优先级最低，在执行Task1程序期间，不断地被Task2和Task3抢占，因此，CPU要完整的执行一次Task1中的代码，至少需要26ms。而这26ms地时间内，Task2、Task3中代码，均按照预期，完整地执行了6次。提示：工程开发中，除了Task之间的抢占，中断也会抢占Task。

当出现上述工况时，CPU的负载率＞1。如何理解CPU负载率＞1呢？举一个例子：一个5座小汽车，最多可以承载5人，如果超过5人乘车，小汽车则无法承载，即：小汽车的负载＞1。类比CPU，如果让CPU处理上述的Task2、Task3，CPU游刃有余，还可以"偷懒"，此时，CPU的负载率＜1。当CPU同时处理Task1、Task2、Task3时，即使CPU一直不停的工作（CPU使用率100%），也无法在Task1规定的期限内（20ms），有效的将Task1中的任务，完整的执行一次，此时，CPU的负载＞1。

所以，CPU负载＜1，是CPU可以有序处理Task的前提，CPU负载和CPU使用率是两个概念。也就是说，CPU使用率≤100%，也可以有效的处理任务，但是，CPU负载＞1，则不能按照预期处理Task。

2、Task超时引发的工程问题

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**