目前，大多數的產品開發是在基于一些小容量的單片機上進行的。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空間（不考慮擴展外部存儲器的情況）;

　?、谠诰幾g鏈接時，即已經完成局部變量的定位;

　?、廴绻骱瘮抵g沒有直接或間接的調用關系，則其局部變量空間便可覆蓋。

　　正是由于以上的原因，在Keil C51環境下，純粹的函數如果不加處理（如增加一個模擬棧），是無法重人的。那么在Keil C5l環境下，如何使其函數具有可重人性呢？下面分析在實時操作系統下面，任務的基本結構與模式：

　　vold TaskA（void*ptr）{

　　UINT8 vaL_a;

　?。渌恍┳兞慷x

　　do{

　　／／實際的用戶任務處理代碼

　　}while（1）;

　　}

　　void TaskB（void*ptr）{

　　UINT8 vaLb;

　?。渌恍┳兞慷x

　　do{

　　Funcl（）;

　?。渌麑嶋H的用戶任務處理代碼

　?。﹚hile（1）;

　　void Funcl（）{

　　UlNT8 v al_fa;

　　／／其他變量的定義

　?。瘮档奶幚泶a

　　}

　　在上面的代碼中，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或其他任務的局部變量形成可覆蓋關系。