uCOS系统的思考

http://blog.csdn.net/yuan1125/article/details/7585619

 一：  世界潮流，浩浩汤汤，顺之者昌，逆之者亡---孙中山

      从80X86到ARM9，再从ARM9到ARM7，平台是越做越简单，但是简单并不是意味着退步，反而是种潮流趋势。。。

      在CISC道路上渐行渐远的INTEL，在移动市场无所作为，而且服务器市场也面临着ARM的潜在威胁。

      废话不多说，还是直入主题：

ARM7的特性：

        1：

        采用RISC架构的MCU最显而易见的优点就是：

        统一寻址模式，访问外设就像访问内存一样简单。而X86上则需要用特殊的IO操作指令来访问外设。

       

       2：

       差强人意的保护机制：

       ARM7只提供了2中权限：

                   Handler Mode 

                   Thread Mode：特权级/非特权级

       一般来说，OS的代码使用特权级，APP代码使用非特权级，虽然可以保护OS代码不受非法访问。

       但是没有MMU单元，APP的代码访问空间则得不到限制，线程之间可能互相破坏。所以你再也遇不到segment fault了。。转而是顷刻之间系统崩溃。。。。

 

      事情正在起变化----毛泽东

       我通读过Linux Kernel的大部分源代码，特别是关于进程调度、内存管理这部分。以为掌握了现代操作系统的设计的精髓。。。面对麻雀般的uCOS2，难免有些轻视。。。

      事情并非如此简单，原因是UCOS2的进程调度策略与现代的OS有很大的区别。

 

     时间片轮转算法：

       uCOS2的调度策略并没有采用这个算法，我想大概与uCOS2是一个实时系统有关。

       如果高优先级的进程不主动释放CPU，那么低优先级的进程永远也得不到运行。

       Linux实现了时间片轮转，只是高优先级的进程时间片长，优先运行。好处显而易见，高优先级的如果跑飞不会导致整个系统宕掉。

 

    char类型引发的血案：

      一个BUG。。。最后查了好久才发现是char类型的问题。

      因为keil编译器char类型默认被解释为unsigned char [0-255]

      而GCC/VC编译器char类型默认被解释为signed char [-128, 127]

 

      由于出现了这种代码

     char a;

      while(a-- >=0)

     { ....}

    所以程序就再也不会退出了。。。之所以查了好久，是我理所当然的认为char会被默认解释为signed char...

   之后我翻阅了C99 Doc。。。。在没有加前缀的情况下，char的具体类型由编译器决定。。。

               

     从LINUX&GCC转入UCOS2&KEIL，一切都变了。。看来我得重新审视一下这个小系统了。 

         

      uCOS2：

      uCOS2唯一值得学习的一个地方就是关于进程调度的O(1)算法：

      最简单也是最愚蠢的方法是维护一个链表List。

      这种方法的问题是：当一个Thread就绪时，如果根据其优先级插入List，则算法的时间复杂度为O(n)。

      Linux采用了Bitmap，uCOS2也不例外。当然uCOS2的处理更简单，因为uCOS2必须在系统编译时配置好支持的Thread最大数量，用来分配Bitmap。

      例如：

      支持64, 则分配8字节的Bitmap，如果支持256，则分配16字节的Bitmap。

      Bitmap的每一个Bit代表thread的状态，如果Bit为1则表示就绪，0则表示挂起。

      以64为例：

    

       在Bitmap中如何快速找到为1的BIT，再转换成THREAD的优先级？

       如果采用扫描的方式，按位与操作不是好方法，这里涉及循环和计数。所以操作时间和THREAD数量又成O(N)了。

       所以uCOS2采用了分组的方法：8个字节64BIT，分为8*8,如图。

       用OSRdyGrp变量的BIT来指示哪个分组里有就绪的THREAD，然后在提取出来该分组，再从该分组中找到优先级最高的THREAD。

       线程优先级Priority和分组的关系如图。也就是X,Y如何组成Priority。

　　还有一个问题：如何找到优先级最高的线程？Priority值越小，Thread优先级越高。

　　比如OSRdyGrp = 0x10001000，OSRdyTbl[3]=0x10001000.

       很明显OSRdyGrp的BIT4和OSRdyTbl[3]的BIT4代表的Thread 27才是我们想要的。

   

　　为了解决这个问题，uCOS2又采用的了一个快速转换表OSMapTbl。

       该转换表原理如下： 0x10001000 --->转换表---->3

                                        0x00001000 --->转换表--->3

        1字节8BIT，有256种BIT组合，但是组合方式返回的值是可以提前算好，存在OSMapTbl中。

      比如OSRdyGrp=0x11111111和OSRdyGrp=0x00000001都应该返回0. [0代表第一个分组]

       所以OSMapTbl如下：

      

INT8U const OSUnMapTbl[256] = {
0, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0， /* 0x00 to 0x0F */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x10 to 0x1F */
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x20 to 0x2F */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x30 to 0x3F */
6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x40 to 0x4F */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x50 to 0x5F */
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x60 to 0x6F */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x70 to 0x7F */
7, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x80 to 0x8F */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0x90 to 0x9F */
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0xA0 to 0xAF */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0xB0 to 0xBF */
6, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0xC0 to 0xCF */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0xD0 to 0xDF */
5, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0, /* 0xE0 to 0xEF */
4, 0, 1, 0, 2, 0, 1, 0, 3, 0, 1, 0, 2, 0, 1, 0 /* 0xF0 to 0xFF */
};  可以看出OSMapTbl[0]和OSMapTbl[255]都是0。

       

       Jean J. Labrosse，uCOS的作者，一个不懂哲学的人？

       uCOS诞生于1992年，我想想，那个时候Linus在芬兰已经设计出了Linux的第一版本Beta0.12。David Cluter在西雅图为MicrioSoft第一个现代的版本操作系统内核NT忙的焦头烂额。

        上个世纪90年代，OS设计已经进入了工业界，在学术界早已盖棺论定.

        Labrosse在设计uCOS竟然没有采用最基本C/S模型。这也是设计OS的最基本哲学之一。

        也就是Kernel为Server，App Thread为client。

       App Thread 通过Kernel 提供的系统调用发出请求，具体操作由Kernel完成。

 

       以X86平台为例，在Linux/Windows上，比如打开文件的Open函数，在libc库中的实现一定类似于：

            MOV  AX, XX

            MOV  BX, XX

            MOV  CX, XX

            MOV  DX, XX

            INT 0X80

这里并不涉及文件操作的任何代码，而是APP向OS发出一个请求：我要打开FILE,请帮我打开。

       1. BX、CX、DX用来保存Open的参数(FILE的路径，打开模式).

       2. AX用来保存系统调用号，因为有很多系统调用，比如OPEN /WRITE/READ/CLOSE，他们各自对应一个调用号，比如OPEN对应1，WRITE对应2等等。。。 

       3. INT指令用来产生软中断。

       软中断处理函数(exception handler)，通过AX换算得到打开FILE操作的真正地址去执行。

 

这样的好处是：

       任何线程不能直接控制硬件资源，只能提交请求，这样最大保证了系统的稳定性。

      

       当然这个和CPU有莫大的关系，如果CPU没有提供类似于INT的软中断触发指令，和相应的保护模式，则不能实现现代OS。

       作者可能受制于MOTO的芯片，才设计一个不符合惯例的OS.

       OS Kernel / interrupt routine / app 采用一样的特权级。app任何微小的错误将导致整个系统崩溃。。。。

       怪不得有朋友说，这类似于古老的DOS。。。

       

 贡献两个技巧：

  1 如何检验栈的使用量：

      其实非常简单的操作，每次线程创建时，把栈空间全部清零。然后定期检测栈中非零的空间，就知道栈的使用量了。【只有线程运行到一定程度时，线程栈使用量才准确】

   

 2 如何判断栈是否溢出：

      在uCOS中创建任务时，在任务控制块中保存堆栈的栈底地址，并在栈底地址所对应的内存块中写入MAGIC NUMBER,  定期检查该字节是否被更改，用此来判断堆栈是否溢出。