UCOSIII中的时基系统

吾日三省吾身：为人谋而不忠乎？与朋友交而不信乎？传不习乎？

序言

UCOSIII中有一个模块可以向我们提供系统运行时的各种统计信息，这极大地方便我们实现系统的白盒管理，但是我觉得只会把那几个统计参数打出来看根本不叫白盒管理，我们应当清楚地知道每一个参数值是怎么被统计出来的。今天我就CPU运行速率这个统计参数进行了白盒探究，我试图搞清楚它的整个计算流程，但是事与愿违，一直到现在，还是有一些现象与我想得不一样（CPU在启动瞬间，CPU使用率会非常高，之后才逐渐降低到平稳水平），这些现象看似合理（也的确合理），但我还是没搞清楚为什么会这样。
我想，什么会影响CPU的使用情况，无非就是任务，但我自己建立的任务只有一个，剩下的都是系统任务，所以，我打算搞清楚每一个系统任务，UCOSIII一共有五个系统任务，它们分别在下面五个函数中初始化：OS_IntQTaskInit、OS_IdleTaskInit、OS_TickTaskInit、OS_StatTaskInit、OS_TmrInit。空闲任务没什么好说的，统计任务和定时器任务以及中断队列管理任务都是可选的，可选就代表着不是核心的，我们只看核心。所以现在只剩下一个Tick任务，我们下面就去仔细看看。

曾经的理解

之前听说Tick定时器是单片机专门为操作系统提供的定时器，它能够产生固定周期的中断为操作系统提供时基，什么是时基，顾名思义，时间的基准，操作系统中的绝大部分时间系统都是以这个中断周期作为最小时间单位的。

在CM3中这个定时器是怎样的

这个定时器是由下面四个寄存器控制的

#defi ne NVIC_STCSR ((volatile unsigned long *)(0xE000E010))
#defi ne NVIC_RELOAD ((volatile unsigned long *)(0xE000E014))
#defi ne NVIC_CURRVAL ((volatile unsigned long *)(0xE000E018))
#defi ne NVIC_CALVAL ((volatile unsigned long *)(0xE000E01C))

这个定时器是属于CM3内核的一个组件，我们一般用这个定时器作为时基，因为这样做的话，当我们再相同内核的不同芯片之间做移植的时候就不用再去配置时基了。它是由四个寄存器控制的：控制及状态寄存器、重装载寄存器、当前计数值寄存器、校准寄存器。具体的配置方法和普通的定时器一样。
当它计数值满的时候就会产生一个中断，这个中断就会找到中断向量表中的

DCD     SysTick_Handler            ; SysTick Handler

这也是一个CMS绑定的中断向量，它在0x0000_003C。

中断服务函数是怎样的

如下便是其中断服务函数，也就是当定时时间到了的时候就会执行这个函数

//systick中断服务函数,使用ucos时用到
void SysTick_Handler(void)
{	
	if(delay_osrunning==1)						//OS开始跑了,才执行正常的调度处理
	{
		OSIntEnter();							//进入中断
		OSTimeTick();       					//调用ucos的时钟服务程序               
		OSIntExit();       	 					//触发任务切换软中断
	}
}

我们看到这个函数中并没有处理任何的时钟节拍事务，而是调用了另一个函数OSTimeTick，难道会再这里面处理时钟节拍事务？我们来看看。

void  OSTimeTick (void)
{
    OS_ERR  err;

    OS_IntQPost((OS_OBJ_TYPE) OS_OBJ_TYPE_TICK,             /* Post to ISR queue                                      */
                (void      *)&OSRdyList[OSPrioCur],
                (void      *) 0,
                (OS_MSG_SIZE) 0u,
                (OS_FLAGS   ) 0u,
                (OS_OPT     ) 0u,
                (CPU_TS     ) ts,
                (OS_ERR    *)&err);

#else

   (void)OSTaskSemPost((OS_TCB *)&OSTickTaskTCB,            /* Signal tick task                                       */
                       (OS_OPT  ) OS_OPT_POST_NONE,
                       (OS_ERR *)&err);
#endif
}

为了将注意了集中在主要矛盾上，我把一些可有可无的内容删除了（起码目前可有可无），现在只剩下两个函数了，一个是OS_IntQPost，一个是OSTaskSemPost，这两个函数是干什么的呢？我们知道UCOSIII有一个系统任务叫是节拍任务，如下所示：

void  OS_TickTask (void  *p_arg)
{
    OS_ERR  err;
    CPU_TS  ts;


    p_arg = p_arg;                                          /* Prevent compiler warning                               */

    while (DEF_ON) {
        (void)OSTaskSemPend((OS_TICK  )0,
                            (OS_OPT   )OS_OPT_PEND_BLOCKING,
                            (CPU_TS  *)&ts,
                            (OS_ERR  *)&err);               /* Wait for signal from tick interrupt                    */
        if (err == OS_ERR_NONE) {
            if (OSRunning == OS_STATE_OS_RUNNING) {
                OS_TickListUpdate();                        /* Update all tasks waiting for time                      */
            }
        }
    }
}

我们一眼就可以看到，这个系统任务正在等待信号量的到来。
我们回到刚刚的两个函数的理解上面，它们的作用其实就是向系统任务发送信号量，那么为什么要用两个函数呢，其实我们可以看到，这里采用了条件编译，也就是一次只能使用一个函数，第一种叫做延迟Post，第二种叫做直接Post，这两种发送信号量的方式有什么区别呢？这是我们下面要讨论的重点。

延迟Post与直接Post

直接Post

1. 外设产生中断请求；
2. 中断服务程序开始运行，该中断服务程序中可能会包含有发送信号量、消息、事件标志组等事件。那么等待这个事件的任务的优先级要么比当前被中断的任务高，要么比其低；
3. 如果中断对应的事件使得某个比被中断的任务优先级低的任务进入就绪态，则中断退出后仍恢复运行被中断的任务；
4. 如果中断对应的事件使得某个比被中断的任务优先级更高的任务进入就绪态，则UCOSIII将进行任务切换，中断服务程序推出后就执行更高优先级的任务；
5. 如果使用直接发布模式的话，则UCOSIII就必须关中断以保护临界段代码，防止中断处理程序访问这些临界段代码。

直接发布模式下，从中断发布消息和信号是直接在中断服务程序中发布的。

针对直接发布模式，如果进行临界段保护：UCOSIII会对临界段代码采用关闭中断的保护措施，这样就会延长中断的响应时间。虽然UCOSIII已经采用了所有可能的措施来降低中断关闭时间，但仍然有一些复杂的功能会使得中断关闭相对较长的时间。

延迟Post

1. 外设产生中断请求；
2. 中断服务程序开始运行，该中断服务程序中可能会包含有发送信号量、消息、事件标志组等事件。那么等待这个事件的任务的优先级要么比当前被中断的任务高，要么比其低；
3. 中断服务程序通过调用系统的发布服务函数向任务发布消息或信号，在延迟发布模式下，这个过程不是直接进行发布操作，而是将这个发布函数调用和相应的参数写入到专用队列中，该队列称为中断队列。然后使中断队列处理任务进入就绪态，这个任务是UCOSIII的内部任务，并且具有最高优先级0；
4. 中断服务程序处理结束时，UCOSIII切换执行中断队列处理任务，该任务从中断队列中提取出发布函数调用信息，此时仍需要关闭中断以防止中断服务程序同时对中断队列进行访问。中断队列处理任务提取出发布函数调用的信息后重新开中断，锁定任务调度器，然后进行发布函数调用，相当于发布函数调用一直是在任务级代码中进行的，这样本来应该在中断中处理的代码（发布函数调用）就被放到了任务级完成；
5. 中断队列处理任务将中断队列处理完，将自身挂起，并重新启动任务调度来运行处于最高优先级的就绪任务。如果原先被中断的任务仍然是最高优先级的就绪任务，则UCOSIII恢复运行这个任务；
   由于中断队列处理任务的发布操作使得更重要的任务进入就绪态，内核将切换到更高优先级的任务运行。

延迟发布模式下，从中断发布消息和信号是延迟发布的，就是将要发布的内容下入到一个专用的队列中，最后由中断服务管理任务进行发布。

针对延迟发布模式，如果进行临界段保护：在使用延迟发布模式额外增加的操作都是为了避免使用关中断来保护临界段代码。延迟发布模式下，是通过任务调度来实现的（任务调度到中断服务管理任务），那么就需要锁定任务调度来保护临界段代码。这些额外增加的操作仅包括将发布调用及其参数复制到中断队列中、从中断队列提取发布调用和相关参数以及一次额外的任务切换。

如果应用中存在非常快速的中断请求源，则当UCOSIII在直接发布模式下的中断关闭时间不能满足要求的时候，可以使用延迟发布模式来降低中断关闭时间

以上是书中的翻译内容，下面是我的精华总结：
延迟Post就是为了解决直接Post所导致的关中断时间过长问题，那么为什么延迟Post可以减少关中断时间，因为延迟Post是在任务级完成的，这意味着它有现场保护功能，所以可以被中断，也就没必要关中断。

注：听说延迟发布要被去掉了，要出来更好的解决方法吗？

---

明天我将对延迟发布进行源码级的介绍

Keep studying，see you next time?