【总结】从认知硬件的中断机制到加深对系统设计中断信号(异常)与任务调度的理解。

前言

最近(2021年01月31日)理了一遍自己作为软工走进嵌入式底层后,对硬件的认知的提升过程,现在我把它记录下来,方便后人可以较为容易的去认知和理解该事物。

按时间顺序进行理解。

  • 在还不知道中断这个事物的时候,我只知道进程和线程的系统调度的存在,它出现在计算机系统里,主要关键知识点是时间片轮和银行家调度算法的实现,更多是描述软件上是如何进行多任务调度的规划,常见与 CPU 调度的优先级和上下文切换(寄存器列表置换)。

  • 在开始接触 MCU 硬件后,我认知到还有一个叫中断的存在,它出现在硬件启动的时候,导入一些预定好的异常中断函数,供软件链接,意味着当发生异常的时候,会根据其优先度决定是否打断当前任务的执行,这个时候的打断是由 CPU 在执行指令的时候自行决定的,此时已经认知到 MCU 启动过程中就已经完成了相应的硬件处理中断异常的机制,意味着它的效果类似于在程序中设置 C 语言的 sigh 信号一样,接收到 Ctrl + C 的程序信号时,决定是否要退出程序,与系统的 IO 通信队列有异曲同工之处。

  • 从 micropython 语言中的异常机制得知了 nlr 和 setjump 的上下文切换等寄存器操作,意味着程序可以任意借用 CPU 资源进行调度,关键在于能否进行地址跳转和寄存器置换。

  • 现在结合 Linux 的嵌入式芯片上的异常向量表后,可以将两端的实现联系起来,首先硬件会对每次执行的指令检查是否出现异常,然后异常产生触发中断,将寄存器列表现场保存下来,移交给软件定义对称的中断触发的接收函数进行处理,此时完成了硬件到软件的异常中断的设计。

这里就不细说中断的各种芯片的具体实现手段了,主要是记录一下异常与中断软件设计相关的描述,基础认知可以看这篇Linux中断机制

中断和异常管理

通过中断和异常管理这篇文章的细节描述,可以得知一个系统需要硬件提供哪些接口实现中断和异常的程序设计,注意我的思考方向是反过来的,因为从上层往下层推会得到不一样的角度。

例如软中断可以如何实现的问题,它可以怎样设计结构。

事实上,有了前面的认知基础,这一切都是相通的,软件实现的时候,根据硬件的工作机制去设计中断的触发机制,就可以实现软件上的信号处理,与硬件不同的是异常向量表是提供给 CPU 检查的,而软件上的是提供给程序执行时的进程表检查的。

此时你就会明白,软件是如何处理程序一些外部信号或按键的,而且信号实质上是软中断,中断有优先级,信号也有优先级,如果这时候再深入思考,硬件的硬中断实际上只是一种中断来源。

此时不再区分软硬件了,可以统一理解为开发系统的话,可以如何实现流程的中断这件事的。

如果你理解了上文,那就拓展来说系统可以如何实现多进程,多线程的呢,事实上是可以通过高优先级定时器中断信号来完成上下文切换的调度和管理,由该中断任务来决定要不要将当前执行的代码段挂起(上下文切换),然后更换备选的线程队列数据进行选择算法的调度。

但我个人还是建议程序从一开始就写成状态机全异步实现,否则基于这个机制,就要自己多多思考程序的优先级管理以及并行资源的加锁和同步了。

补充一下,进程是独立的程序内存区域,线程与进程共用同一片内存区域,推荐再看这篇Linux任务调度机制

原文地址:https://www.cnblogs.com/juwan/p/14353321.html