改进型时间触发嵌入式系统编程模式
系统中每个任务都定义了优先级、任务循环周期和任务延迟时间，系统定时器中断程序SCH Updatc()按设定的节拍对任务队列进行刷新，在超级大循环中只执行任务调度器SCH_Dispatch_Tasks()，根据任务队列的状念安排任务的执行。
这种编程结构避免了超级大循环结构循环时间随代码量的增加而线性增加的问题，但是由于任务是不可剥夺的，一旦任务启动执行，任务调度器只有在当前任务完成后才有机会执行，这就要求每个任务占用CPU的时间不能太长，否则将影响整个系统的响应速度。所以，FFT运算在这种编程模式下还是必须进行有效的拆分，否则就必须提高CPU的档次或使用可剥夺型的抢先式RTOS，这势必造成系统成本的增加。那么有没有更好的解决办法呢?
下面的编程结构埘“时间触发编程模式”进行了改进，使之在不提高硬件成本的情况下，使编程人员更直观地定义任务，减少任务特性对系统程序结构的冲击，使程序结构简单、明了并提高系统的实时响应速度。
2 对“时间触发编程模式”的改进
根据多年嵌入式系统编程的经验，通常嵌入系统的任务可以划分成3种类型：
①及时型任务。这类任务是事件触发型的，一旦事件发生，系统必须在限定的时间内进行响应，对这类任务，最自然的方法就是使用中断来完成，即定义成“前后台方式”中的后台任务。
②周期型任务。这类任务是时间触发式周期型的，系统必须保证在指定的周期内执行任务，“时间触发编程模式”可以很好地满足这类任务的需求。
③背景型任务。这类任务是非实时型的，实时性不是非常重要，系统在运行过程中可随时中断这类任务以便执行前两类任务，系统只要能充分利用资源尽最大可能快速完成这类任务即可，这类任务最适合定义成“前后台方式”中的前台任务。
根据以上任务分类，对“时间触发编程模式”的改进可概括成以下需求：
◆任务分3类，1类任务优先级最高，3类任务优先级最低；
◆高优先级的任务可中断低优先级任务的执行，同级的任务之间不可相互剥夺；
◆实际没计中为提高系统的可预测性，应尽量减少1类任务的数量及1类任务的执行时间；
◆为降低系统资源的占用，系统不给任务划分单独的堆栈空间。
以上改进的本质是设计3个优先级的简单的任务调度机制，高优先级的任务可中断低优先级的任务，同优先级的任务之间不能相互剥夺，该调度机制不为每个单独的任务保存任务上下文和单独的堆栈，这样可以减少该编程模式对系统资源的需求。
可剥夺式RTOS中的一个高优先级任务中断一个低优先级的任务时，会保存好低优先级任务的上下文并把该低优先级任务的局部变量保存在本任务单独的堆栈中，如果系统不给任务分配单独的堆栈，如何保证高优先级任务退出后，低优先级任务执行环境的恢复呢?
对这个问题，可以借鉴中断的处理机制用以下办法予以解决：
①在系统中设计一个定时中断函数，该函数的功能就是执行周期性任务的调度，该定时中断在所有中断中优先级最低。
②在系统中设计另一个定时中断函数，该函数的功能是刷新周期型任务的任务管理队列，为任务调度提供支持，本定时中断函数的优先级在系统中次低。
③周期型任务就是一个函数，该函数入口的第一个操作是开中断，允许任务执行期间被中断以便响应及时型任务。
④背景型任务就是在主函数超级循环中执行的代码，该代码可随时被及时型和周期型任务中断，当系统没有及时型任务和周期型任务时才循环执行背景型任务的代码。 linux操作系统文章专题:linux操作系统详解（linux不再难懂）
评论