手把手教你为51单片机写一个操作系统.pdfVIP

手把手教你为51单片机写一个操作系统 目前，大多数的产品开发是在基于一些小容量的单片机上进行的。51系列单片机，是 我国目前使用最多的单片机系列之一，有非常广大的应用环境与前景，多年来的资源积累， 51系列单片机仍是许多开发者的首选。针对这种情况，近几年涌现出许多基于51 内核的 扩展芯片，功能越来越齐全，速度越来越快，也从一个侧面说明了51系列单片机在国内的 生命力。 多年来我们一直想找一个合适的实时操作系统，作为自己的开发基础。根据开发需求， 整合一些常用的嵌入式构件，以节约开发时间，尽最大可能地减少开发工作量;另外，要求 这个实时操作系统能非常容易地嵌入到小容量的芯片中。毕竟，大系统是少数的，而小应用 是多数而广泛的。显而易见，μC／OS—II是不太适合于以上要求的，而KeilC所带的RTX Tiny不带源代码，不具透明性，至于其FULL版本就更不用说了。 1KeilC51与重入问题 说到实时操作系统，就不能不考虑重入问题。对于PC机这样的大内存处理器而言，这 似乎并不是一个很麻烦的问题，借用μC／OS—IIRTOS 的说法，即要求在重入的函数内， 使用局部变量。但5l系列单片机堆栈空间很小，仅局限在256字节之内，无法为每个函数 都分配一个局部堆空间。正是由于这个原因，KeilC51使用了所谓的可覆盖技术： ①局部变量存储在全局RAM空间（不考虑扩展外部存储器的情况）; ②在编译链接时，即已经完成局部变量的定位; ③如果各函数之间没有直接或间接的调用关系，则其局部变量空间便可覆盖。 正是由于以上的原因，在KeilC51环境下，纯粹的函数如果不加处理（如增加一个模 拟栈），是无法重人的。那么在KeilC5l环境下，如何使其函数具有可重人性呢？下面分析 在实时操作系统下面，任务的基本结构与模式： voldTaskA （void*ptr）{ UINT8vaL_a; ／／其他一些变量定义 do{ ／／实际的用户任务处理代码 }while （1）; } voidTaskB （void*ptr）{ UINT8vaLb; ／／其他一些变量定义 do{ Funcl （）; ／／其他实际的用户任务处理代码 ）while （1）; voidFuncl （）{ UlNT8val_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或其他任务的局部变量形成可覆盖关系。 将val_a、val_b 以及val_fa等局部变量定义为静态变量（加上static指示符）可以解决 这一问题。但问题是，定义大量的static类型变量，将导致RAM空间的大量占用，有可能 直接导致RAM空间不够用。尤其是在一些小容量的单片机内，一般只有128或256字节， 大量的静态变量定义，在如此小的RAM资源状况下显然就不太合适了。由此而有了另一种 的解决方法，如下代码所示： voidTaskC （void）{ UINT8x，v; whlk （1）{ OS_ENTER_CRITICAL （）; x=GetX （）; （1） y=GetY （）; （2） ／／任务的其他代码 OS_EXIT_CRITICAL （）; （3） 0SSlee （100）; （4） } } 以上代码TaskC 中使用了临界保护的方法来保护代码不被中断占先，确实有效地解决了 RAM空间太小，不宜大量定义静态变量的问题。然而如果每个任务都采用此种结构，任务 一开始，就关闭中断，将使实时性得不到保证。事实证明，这种延时是相当可观的。用一个 实例来说明，