48、可以人工地计算出任务需要的堆栈空间大小，逐级嵌套所有可能被调用的函数， 添加被调用函数中所有的参数， 添加上下文切换时的CPU 寄存器空间， 添加切换到中断时所需的 CPU 寄存器空间，添加处理 ISRs 所需的堆栈空间。 把上述的全部相加， 得到的值定义为最小的需求空间。 因为我们不可能计算出精确的堆栈空间。 通常是再乘以 1.5 以确保任务的安全运行。
49、另一种防止堆栈溢出的方法是分配的空间远大于可能需要的。 首先， 当任务创建时其堆栈被清零。 程序运行一段时间后，通过一个低优先级任务， 计算该任务整个堆栈中值为 0 的内存大小。 这是一种非常有效的方法。 注意的是， 程序需用运行很长的时间以让堆栈达到其需要的最大值。
50、从用户的观点来看，任务可以是有 5 种状态，休眠状态，就绪状态，运行状态，挂起状态，中断状态 。
51、调用 OSTaskSuspend() 会任务无条件地停止运行。 有些时候调用 OSTaskSuspend() 不是为了等待某个事件的发生，而是等待另一个任务调用 OSTaskResume()函数恢复这个任务。
52、任务控制块是被 uC/OS-III 用于维护任务的一个结构体。 每个任务都必须有自的己 TCB 。TCB 中的一些变量可以根据具体应用进行裁剪。用户程序不应该访问这些变量（尤其不能更改它们）。
53、有些处理器有硬件寄存器可以自动地检测并确保堆栈不发生溢出， 如果处理器没有这些硬件施，ucos-iii的堆栈检测可以用软件模拟。 然而， 软件模拟不如硬件可靠。
54、在 uC/OS-III 初始化的时候，它会创建至少 2 个内部的任务 (OS_IdleTask() 和 OS_TickTask()) ， 3 个可选择的任务（ OS_StatTask() ，OS_TmrTaks() ， OS_IntQTask() ）。这些可选择的任务在编译时由OS_CFG.H 中的配置决定。
55、当 CPU 中没有其它就绪任务运行时，空闲会被运行。空闲任务是一个无限循环的不会等待任何事件的任务。空闲任务的每次循环，都会调用 OSIdleTaskHook()函数，这个函数提供给用户扩展应用，如让处理器进入低功耗模式等。
56、） 使用硬件定时器并被设置为以 10 到 1000Hz 之间的频率产生时基中断，时基中断并不是一定要用 CPU 产生， 事实上， 它可以从其他的具有较精确的周期性时间源中获得，比如电源线（ 50-60Hz ）等。
57、当时基任务执行时，它会遍历挂起队列中所有等待期满的任务或等待事件超时的任务。 它会就绪时基列表中的那些期满、超时的任务。使用轮转法遍历队列（此队列为二维数组的形式）大大减少了遍历队列所占用CPU的时间。
58、统计任务能够统计总的 CPU 使用率, 每个任务的 CPU使用率，每个任务的堆栈使用量。59软件定时器通常需要的频率可由用户设置， 通过软件将时基分频。 换句话说如果时基速率为 1000Hz, 但是想要的定时器速率为 10Hz, 软件定时器任务会每 100 个时基被标记一次。时基任务的优先级要高于定时器任务，定时器任务的优先级需要于统计任务。
60、当一个任务创建了一个具有相同优先级的任务，这个新任务会被添加到该优先级队列的尾部（因为具有相同优先级情况下， 没有理由让新任务先运行）。然而，当一个任务创建了一个具有不同优先级的任务时，这个新的任务就会放到对应优先级列表中的首部。注意：正在运行的任务也被放在就绪列表中。
61会发生调度的调度点：任务被标记或发送消息给另一个任务、任务调用 OSTimeDly() 或 OSTimeDlyHMSM()、任务所等待的事件发生或超时、任务被取消挂起 、新任务被创建 、任务被删除 、内核对象被删除 、任务改变自身的优先级或其它任务的优先级 、任务通过调用OSTaskSuspend() 停止自身、任务调用OSTaskResume()
恢复其它停止了的任务、退出中断服务程序 、通过调用 OSSchedUnlock() 调度器被解锁、调用OSSchedRoundRobinYield() 任务放弃了分配给它的时间片、用户调用OSSched()。
62、任务提交一个事件后调用调度器。 当然， 任务可以一次性提交多个事件， 但在最后一个事件提交后才调用调度器。
63、uC/OS-III 有 2 种调度方式： OSSched() 被用于任务级。 OSIntExit()被用于中断级。由于中断产生时已经将任务 A 的状态保存在任务 A 的堆栈中，所以 ISR 返回时无需再保存任务 A 的状态，而是直接载入任务 B 的 CPU 寄存器到硬件CPU 寄存器中即可。
64、当 uC/OS-III 转向执行另一个任务的时候，它保存了当前任务的 CPU 寄存器到堆栈。并从新任务堆栈中 相关内容载入CPU 寄存器。这个过程叫做上下文切换。上下文切换需要一些开支。 CPU 的寄存器越多， 开支越大。 上下文切换的时间基本取决于有多少个 CPU 寄存器需要被存储和载人。保存状态寄存器和程序指针寄存器到当前的任务堆栈。保存的顺序与中断发生时 CPU 保存寄存器的顺序相同。
65、CPU 处理中断有两种模式： 1 所有的中断指向同一个 ISR2 每个中断指向各自的 ISR 。） ISR 的工作完成后， 用户必须调用 OSIntExit() 告诉 uC/OS-III中断服务程序已经完成。
66、uC/OS-III 有两种方法处理来自于中断的时间； 直接提交和延迟提交。其区别在于如何处置中断中所产生的事件。延迟提交的方式为事件不是直接发送给任务， 而是先发送到中断队列。 然后中断处理任务（其优先级为0）被就绪，这样，事件的提交便可在任务级完成，从而减少了ISR处理的时间。
67、uC/OS-III 必须有系统时基是普遍的误解。 事实上， 很多低功耗应用中没有系统时基，因为需额外的能量用于维护时基源。换句话说 ，将能量用于维护时基源是不合理的。因为 uC/OS-III 是一个可抢占式内核， 一个事件可以唤醒进入低功耗模式处理器（按键或其它事件）没有时基意味着用户不能再对任务进行延时或超时设置。 用户在研发低功耗产品时可以考虑这个特性。
68、任务在挂起队列中是根据优先级分类的。 高优先级任务被放置在队列的头部，低优先级任务被放置在队列的尾部。
69、任务不是直接链接到挂起队列中， 而是通过叫OS_PEND_DATA 的结构体作为媒介。 这个媒介在任务被挂起时分配到任务堆栈的。挂起队列中的对应指针指向该结构体。
70、延时函数OSTimeDly()，任务调用这个函数后就会被挂起直到期满。以时基为单位，但需注意，当任务在时基中断将要到来时被挂起，那么实际的延时时基会少1个时基。这个函数可以有设置为三种模式：相对延时模式，周期性延时模式，绝对延时模式（用于对时间要求很高的应用）。
71、uC/OS-III 定 时 器 的 分 辨 率 决 定 于 时 基 频率。定时器可以被设置为 3 种模式：一次性定时模式， 无初始定时周期模式，有初始定时周期模式 。如果定时器被停止，那其定时值也将被停止， 直到定时器被恢复时，定时器值继续被递减。不能在定时器的执行代码中等待事件发生。否则定时器任务会被挂起，导致定时器任务崩溃。
72、uC/OS-III 可能要维护上百个定时器。 使用定时器列表会大大降低更新定时器列表所占用的 CPU 时间。 定时器列表类似于时基列表，以二维数组的形式存储记录。
73、uC/OS-III提供关中断方式、锁调度器方式、、信号量方式、mutex方式保护共享资源。只有任务才允许使用信号量，ISR是不允许的。用信号量保护共享资源不会导致中断延迟。当任务在执行信号量所保护的共享资源时，ISR或高优先级任务可以抢占该任务。
74、信号量经常被过度使用。很多情况下，访问一个简短的共享资源时不推荐使用信号量，请求和释放信号量会消耗CPU时间。通过关/开中断能更有效地执行这些操作。信号量会导致一种严重的问题：优先级反转。
75、优先级反转是实时系统中的一个常见问题，仅存在于基于优先级的抢占式内核中。uC/OS-III支持一种特殊类型的二值信号量叫做mutex，用于解决优先级反转问题。
76、死锁，就是两个任务互相等待对方所占用的资源的情况。除一般的防死锁方式外，uC/OS-II还可以在申请信号量或mutex时允许设置其期限，这样能防止死锁，但是同样的死锁可能稍后再次出现。
77、uC/OS-III中用于同步的两种机制：信号量和事件标志组。两个任务间可以用一个信号量实现单向同步，用两个信号量实现双向同步。当任务要与多个事件同步时可以使用事件标志。若其中的任意一个事件发生时任务被就绪，叫做逻辑或(OR)。若所有的事件都发生时任务被就绪，叫做逻辑与（AND）。
78、有些情况下任务或ISR与另一个任务间进行通信，这种信息交换叫做作业间的通信。可以有两种方法实现这种通信：全局变量、发送消息。需注意的是：任务与ISR通信只能通过全局变量。如果全局变量被ISR改变，任务将不会知道全局变量被改变，除非该任务检测该变量或者ISR标记任务告知该变量被改变。
79、消息可以被发送到媒介—消息队列中，也可以直接发送给任务，因为uC/OS-III中每个任务都有其内建的消息队列。如果多个任务等待这个消息时建议将该消息发送到外部的消息队列。当只有一个任务等待该消息时建议直接将消息发送给任务。
80、消息中包含一个指向数据的指针、该数据的大小、时间戳变量。该指针可以指向数据区域甚至是一个函数。当然，消息的发送方和消息的接收方都应该知道消息所包含的意义。
81、消息队列是先入先出模式（FIFO）。然而，uC/OS-III也可以将其设置为后入先出模式（LIFO）。若任务或ISR发送紧急消息给另一个任务时，后入先出模式是非常有用的，在这种情况下，该紧急消息绕过消息队列中的其他消息。
82、任务A发送多个消息给任务B，如果更高优先级的任务抢占了任务B，那么任务A所存放在消息队列中的数据就可能被溢出。解决这个问题的一种方法是在处理中添加流量控制：所有任务在发送消息给任务B之前必须获得信号量。任务B消息队列的空余量为多少，信号量计数值就为多少。
83、任务可以等待多个内核对象。然而，uC/OS-III只允许任务同时等待多个信号量或消息队列。换句话说，不能同时等待多个事件标志组或mutex。但这将花费uC/OS-III较多时间去处理。
84、可以通过使用编译器提供的函数malloc()和free()动态地分配和释放内存快。然而，在嵌入式实时系统中使用malloc()和free()可能是非常危险的。因为它可能会导致很多内存碎片。
85、ucos-iii可以创建多个大小不同的内存分区，一个内存分区可被设置为多个大小相同的任务块，用于存储临时性的数据。根据需求设置，但内存块被分配后必须返回给它
所在的内存分区，这种管理方式仅会导致内存块块内的碎片。从而减少了内存碎片。
