1.uC/OS-II中使用互斥信号对象应该注意
互斥信号对象(Mutual Exclusion Semaphore)简称Mutex，是uC/OS-II的内核对象之一，用于管理那些需要独占访问的资源，并使其适应多任务环境。
创建每一个Mutex，都需要指定一个空闲的优先级号，这个优先级号的优先级必须比所有可能使用此Mutex的任务的优先级都高！
uC/OS-II的Mutex实现原理大致如下：
当一个低优先级的任务A申请并得到了Mutex，于是它获得资源访问权。如果此后有一个高优先级的任务B开始运行(此时任务A已经被剥夺)，而且也要求得到Mutex，系统就会把任务A的优先级提高到Mutex所指定的优先级。由于此优先级高于任何可能使用此Mutex的任务的优先级，所以任务A会马上获得CPU控制权。一直到任务A释放Mutex，任务A才回到它原有的优先级，这时任务B就可以拥有该Mutex了。
应该注意的是：当任务A得到Mutex后，就不要再等待其它内核对象(诸如：信号量、邮箱、队列、事件标志等等)了，而应该尽量快速的完成工作，释放Mutex。否则，这样的Mutex就失去了作用，而且效果比直接使用信号量(Sem)更糟糕！
虽然普通的信号量(Sem)也可以用于互斥访问某独占资源，但是它可能引起“优先级反转”的问题。假设上面的例子使用的是Sem，当任务A得到Sem后，那么任务C(假设任务C的优先级比A高，但比B低)就绪的话将获得CPU控制权，于是任务A和任务B都被剥夺CPU控制权。任务C的优先级比B低，却优先得到了CPU！而如果任务A是优先级最低的任务，那么它就要等到所有比它优先级高的任务都挂起之后才会拥有CPU，那么任务B(优先级最高的任务)跟着它一起倒霉！这就是优先级反转问题，这是违背“基于优先级的抢占式多任务实时操作系统”原则的！
综上所述，uC/OS-II中多个任务访问独占资源时，最好使用Mutex，但是Mutex是比较消耗CPU时间和内存的。如果某高优先级的任务要使用独占资源，但是不在乎久等的情况下，就可以使用Sem，因为Sem是最高效最省内存的内核对象。
2. uC/OS-II应用程序调用OSSchedLock()和OSSchedUnlock()函数应注意
uC/OS-II的OSSchedLock()和OSSchedUnlock()函数允许应用程序锁定当前任务不被其它任务抢占。使用时应当注意的是：当你调用了OSSchedLock()之后，而在调用OSSchedUnlock()之前，千万不要再调用诸如OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之类的事件等待函数！而且应当确保OSSchedLock()和OSSchedUnlock()函数成对出现，特别是在有些分支条件语句中，要考虑各种分支情况，不要有遗漏！
需要一并提醒用户的是：当您调用开关中断函数OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()时也要确保成对出现，否则系统将可能崩溃！不过，在OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()函数之间调用OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之类的事件等待函数是允许的。
3.uC/OS-II驱动程序编写规范，特别推荐
首先应该阐明的是，我们这里讨论的是“驱动程序”，而不是“中断服务程序”，这两个词语往往被用户混淆。
(1)中断服务程序指那种硬件中断一旦发生，就会立即被硬件中断控制器调用的一小段程序，它的操作追求简单明了，越快速越精简就越好。
(2)驱动程序是指封装了某种硬件操作细节的函数集，它提供给应用程序的是统一、标准、清晰、易用的API。
对于中断服务程序的编写，往往与驱动程序的设计相关联。比如驱动程序提供异步操作的功能，那么就需要中断服务程序为它准备缓冲区和一个结构体，并且中断服务程序会依照这个结构体的成员参数自动完成所要求的操作。又如，串口(UART)中断服务程序的设计有两种：基于数据包传输和基于单字节传输，前者适用于以数据包为单位的通信程序，而后者适用于如超级终端这样的应用程序。
如果在一个系统中，要求使用同一个硬件设备完成几种不同的操作方式，就需要设计一个通用的驱动程序，而该驱动程序可以根据需要安装各种针对性很强的中断服务程序。
在设计驱动程序时，特别需要注意的是，某些外设的操作往往以一个连续而严格的时序作为原子操作，比如用I/O端口来访问DS1302、24C01、LM75A等等。在这类设备的操作过程中，不允许有其它任务来控制对应的I/O端口，否则会引起数据错误甚至器件损坏。所以，这种设备的驱动程序都应该仔细设计“原子操作”，把必须连贯操作的时序控制代码用互斥对象封装成一个“原子操作”，以适应多任务环境。其实，大部分设备都是这样，需要确定“原子操作”，如LCD、RTL8019AS、Flash等等也是如此。
关于驱动程序的设计，还有很多很多的文章可作，需要具体问题具体分析。在这里我就不列出个条条目目了，希望有兴趣的朋友多多讨论。