这一年来在实验室总是忙个不停,总的来说,是被老板牵着鼻子懵懵懂懂地走了一年,在他东打一枪,西打一枪的指挥下,貌似积累了一点基础,终于,到了第二年,他的灵犀一动,给了我我一个长期的新目标:接过师姐的枪,继续研究混合调度的ERTOS。于是,所有事情都要重新开始,我继续从原点出发,一步一步走下去......
开学后一个月都在忙着《著作权申请书》,《用户说明书》,还有难得一见的中秋7天假+国庆7天假,一下子,深秋的季节已经到来,虽说这是收成的季节,但现在我最需要的是积累,要一步一步从量变开始,慢慢积累知识,在co-operative schedule的基础上实现hybrid schedule,解决遇到的所有问题。
近来断断续续地看了几篇文章,现在对这些文章再过一遍:
《Design and evaluation of a "time-triggered microcontroller"》
——主要是M.J.Pont想用终于方便的重配置性,硬件可编程性,设计一个专门适用于TTCS的微控制器(Microcontroler),提到了可以将某些简单的任务编译进逻辑块里,让处理器将更多的资源用于复杂的任务中去。(参考意义不大)
《Meeting real-time constraints using "Sandwich Delays"》
——介绍了一种利用微处理器的timer实现任务运行时间的控制(适用于reliable,resource-constrained嵌入式系统),具体方法是:在某任务运行前设置WCET(Worst-Case Execution Time)作为timer溢出(overflow)时间,运行任务,等待timer的溢出信号。前后两个关于timer的函数将任务包(wrap up)起来了,这就是所谓的“三文治”。
code eg.
void Timer_ISR(void) // ISR invoked by timer overflow every 10 ms
{
// Execute Do_X() in a ‘Sandwich Delay’ - BEGIN
Set_Sandwich_Timer_Overflow(5); // Set timer to overflow after 5 ms
Do_X(); // Execute Do_X - WCET approx. 4 ms
Wait_For_Sandwich_Timer_Overflow(); // Wait for timer to overflow
// Execute Do_X() in a ‘Sandwich Delay’ - END
Do_Y(); // WCET approx. 4.0 ms
}
Sandwich Delay可有效地减少任务运行时间抖动问题(jitter),简单易实现且代码可预测性高,但有如下缺点:
1. 需要知道(做夹心的)任务的WCET;
2. 需要小心检查代码(wait函数可能不会自动结束);
3. 运用Sandwich Delay后依然会有1us左右的任务抖动时间;
4. 需要一个额外的timer。
(LPC2100中的32-bit timer,其前标(pre-scalar)最大值为232-1,若有12MHz的晶振(4分频),timer的前标会在1432秒后加1,要加到232-1大概要20万年时间)
《RTOSed balance performance with ease of use》——COTS(Commercial Of The Shelf) Journal
——根据市场调查情况,对RTOS使用需求作出分析。
(to be continued。。。。。。。。