目前,大多数的产品开发是在基于一些小容量的单片机上进行的。51系列单片机,是我国目前使用最多的单片机系列之一,有非常广大的应用环境与前景,多年来的资源积累,使51系列单片机仍是许多开发者的首选。针对这种情况,近几年涌现出许多基于51内核的扩展芯片,功能越来越齐全,速度越来越快,也从一个侧面说明了51系列单片机在国内的生命力。
多年来我们一直想找一个合适的实时 *** 作系统,作为自己的开发基础。根据开发需求,整合一些常用的嵌入式构件,以节约开发时间,尽最大可能地减少开发工作量;另外,要求这个实时 *** 作系统能非常容易地嵌入到小容量的芯片中。毕竟,大系统是少数的,而小应用是多数而广泛的。显而易见,μC/OS—II是不太适合于以上要求的,而Keil C所带的RTX TIny不带源代码,不具透明性,至于其FULL版本就更不用说了。
1 Keil C51与重入问题
说到实时 *** 作系统,就不能不考虑重入问题。对于PC机这样的大内存处理器而言,这似乎并不是一个很麻烦的问题,借用μC/OS—II RTOS的说法,即要求在重入的函数内,使用局部变量。但5l系列单片机堆栈空间很小,仅局限在256字节之内,无法为每个函数都分配一个局部堆空间。正是由于这个原因,Keil C51使用了所谓的可覆盖技术:
①局部变量存储在全局RAM空间(不考虑扩展外部存储器的情况);
②在编译链接时,即已经完成局部变量的定位;
③如果各函数之间没有直接或间接的调用关系,则其局部变量空间便可覆盖。
正是由于以上的原因,在Keil C51环境下,纯粹的函数如果不加处理(如增加一个模拟栈),是无法重人的。那么在Keil C5l环境下,如何使其函数具有可重人性呢?下面分析在实时 *** 作系统下面,任务的基本结构与模式:
vold TaskA(void*ptr){
UINT8 vaL_a;
//其他一些变量定义
do{
//实际的用户任务处理代码
}while(1);
}
void TaskB(void*ptr){
UINT8 vaLb;
//其他一些变量定义
do{
Funcl();
//其他实际的用户任务处理代码
)while(1);
void Funcl(){
UlNT8 v al_fa;
//其他变量的定义
//函数的处理代码
}
在上面的代码中,TaskA与TaskB并不存在直接或间接的调用关系,因而其局部变量val_a与val_b便是可以被互相覆盖的,即其可能都被定位于某一个相同的RAM空间。这样,当TaskA运行一段时间,改变了val_a后,TaskB取得CPU控制权并运行时,便可能会改变val_b。由于其指向相同的RAM空间,导致TaskA重新取得CPU控制权时,val—a的值已经改变,从而导致程序运行不正确,反过来亦然。另一方面,Funcl()与 TaskB有直接的调用关系,因而其局部变量val_fa与val_b不会被互相覆盖,但也不能保证其局部变量val_fa不会与TaskA或其他任务的局部变量形成可覆盖关系。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)