任何一个操作系统都会提供大量的API供程序员使用，μC/OS-Ⅱ也不例外。由于μC/OS-Ⅱ面向的是嵌入式开发，并不要求大而全，所以内核提供的API也就大多和多任务息息相关。本文通过分析μC/OS-Ⅱ中提供的API来引出μC/OS-Ⅱ中API的设计思路和实现机制。

Interface，中文是应用程序编程接口的意思。API是操作系统提供给用户的一组函数，供用户在编写应用程序时调用，可以完成应用程序对操作系统的各种调用，包括进程调度、存储管理、图形设备接口及文件管理等。μC/OS-Ⅱ作为一个嵌入式操作系统，相对于其他操作系统，有很多自己的特色，在设计思路和实现机制上都和一般操作系统有很大的不同。

　任何一个操作系统都会提供大量的API供程序员使用，μC/OS-Ⅱ也不例外。由于μC/OS-Ⅱ面向的是嵌入式开发，并不要求大而全，所以内核提供的API也就大多和多任务息息相关。μC/OS-Ⅱ的API主要分以下几类：（1）任务类、（2）消息类、（3）同步类、（4）时间类、（5）临界区与事件类等。下面分别从这几类API分析各自的设计思路和实现机制。

μC/OS-Ⅱ可以管理多达64个任务，并从中保留了四个最高优先级和四个最低优先级的任务供自己使用，所以用户可以使用的只有56个任务。任务类API包括如何在用户的应用程序中建立任务、删除任务、改变任务的优先级、挂起和恢复任务，以及获得有关任务的信息等。

    想让μC/OS-Ⅱ管理用户的任务，用户必须要先建立任务。用户可以通过传递任务地址和其它参数到以下两个函数之一来建立任务：OSTaskCreate()

    OSTaskCreate()与μC/OS是向下兼容的，OSTaskCreateExt()是OSTaskCreate()的扩展版本，提供了一些附加的功能。用两个函数中的任何一个都可以建立任务。任务可以在多任务调度开始前建立，也可以在其它任务的执行过程中被建立。在开始多任务调度(即调用OSStart())前，用户必须建立至少一个任务。任务不能由中断服务程序(ISR)来建立。

    OSTaskCreate()的函数定义如下。从中可以知道，OSTaskCreate()需要四个参数：task是任务代码的指针，pdata是当任务开始执行时传递给任务的参数的指针，ptos是分配给任务的堆栈的栈顶指针，prio是分配给任务的优先级。

用OSTaskCreateExt()函数来建立任务会更加灵活，但会增加一些额外的开销。

有时候删除任务是很有必要的。删除任务,是说任务将返回并处于休眠状态，并不是说任务的代码被删除了，只是任务的代码不再被μC/OS-Ⅱ调用。通过调用OSTaskDel()就可以完成删除任务的功能。OSTaskDel()一开始应确保用户所要删除的任务并非是空闲任务，因为删除空闲任务是不允许的。不过，用户可以删除statistic任务。接着，OSTaskDel()还应确保用户不是在ISR例程中去试图删除一个任务，因为这也是不被允许的。调用此函数的任务可以通过指定OS_PRIO_SELF参数来删除自己。接下来OSTaskDel()会保证被删除的任务是确实存在的。该函数的入口参数很简单，只需要知道要删除任务的优先级即可。

在用户建立任务的时候会分配给任务一个优先级。在程序运行期间，用户可以通过调用OSTaskChangePrio()来改变任务的优先级。换句话说，就是μC/OS-Ⅱ允许用户动态的改变任务的优先级。函数定义如下：

用户不能改变空闲任务的优先级，但用户可以改变调用本函数的任务或者其它任务的优先级。为了改变调用本函数的任务的优先级，用户可以指定该任务当前的优先级或OS_PRIO_SELF，OSTaskChangePrio()会决定该任务的优先级。用户还必须指定任务的新(即想要的)优先级。因为μC/OS-Ⅱ不允许多个任务具有相同的优先级，所以OSTaskChangePrio()需要检验新优先级是否是合法的（即不存在具有新优先级的任务）。如果新优先级是合法的，μC/OS-Ⅱ通过将某些东西储存到OSTCBPrioTbl[newprio]中保留这个优先级。如此就使得OSTaskChangePrio()可以重新允许中断，因为此时其它任务已经不可能建立拥有该优先级的任务，也不能通过指定相同的新优先级来调用OSTaskChangePrio()。接下来OSTaskChangePrio()可以预先计算新优先级任务的OS_TCB中的某些值。而这些值用来将任务放入就绪表或从该表中移除。

 有时候将任务挂起是很有用的。挂起任务可通过调用OSTaskSuspend()函数来完成。被挂起的任务只能通过调用OSTaskResume()函数来恢复。任务挂起是一个附加功能。也就是说，如果任务在被挂起的同时也在等待延时的期满，那么，挂起操作需要被取消，而任务继续等待延时期满，并转入就绪状态。任务可以挂起自己或者其它任务。

被挂起的任务只有通过调用OSTaskResume()才能恢复。因为OSTaskSuspend()不能挂起空闲任务，所以必须得确认用户的应用程序不是在恢复空闲任务。注意，这个测试也可以确保用户不是在恢复优先级为OS_PRIO_SELF的任务(OS_PRIO_SELF被定义为0xFF，它总是比OS_LOWEST_PRIO大)。

　　2.5 获得任务信息API

用户的应用程序可以通过调用OSTaskQuery()来获得自身或其它应用任务的信息。实际上，OSTaskQuery()获得的是对应任务的OS_TCB中内容的拷贝。用户能访问的OS_TCB的数据域的多少决定于用户的应用程序的配置(参看OS_CFG.H)。由于μC/OS-Ⅱ是可裁剪的，它只包括那些用户的应用程序所要求的属性和功能。

函数参数为一指针变量，指向对应任务的OS_TCB结构地址。本函数是有用的调试工具。

　　3． 消息和同步类API的设计思路和实现机制

　μC/OS-Ⅱ中有三种方法实现消息通信和同步：信号量、邮箱和消息队列。一个任务或者中断服务子程序可以通过事件控制块ECB（Event Control Blocks）来向另外的任务发信号。这里，所有的信号都被看成是事件（Event）。这也说明为什么上面把用于通讯的数据结构叫做事件控制块。一个任务还可以等待另一个任务或中断服务子程序给它发送信号。这里要注意的是，只有任务可以等待事件发生，中断服务子程序是不能这样做的。对于处于等待状态的任务，还可以给它指定一个最长等待时间，以此来防止因为等待的事件没有发生而无限期地等下去。多个任务可以同时等待同一个事件的发生。在这种情况下，当该事件发生后，所有等待该事件的任务中，优先级最高的任务得到了该事件并进入就绪状态，准备执行。上面讲到的事件，可以是信号量、邮箱或者消息队列等。当事件控制块是一个信号量时，任务可以等待它，也可以给它发送消息。

μC/OS-II中的信号量由两部分组成：一个是信号量的计数值，它是一个16位的无符号整数（0 到65,535之间）；另一个是由等待该信号量的任务组成的等待任务表。用户要在OS_CFG.H中将OS_SEM_EN开关量常数置成1，这样μC/OS-II才能支持信号量。

邮箱是μC/OS-II中另一种通讯机制，它可以使一个任务或者中断服务子程序向另一个任务发送一个指针型的变量。该指针指向一个包含了特定“消息”的数据结构。为了在μC/OS-II中使用邮箱，必须将OS_CFG.H中的OS_MBOX_EN常数置为1。

消息队列是μC/OS-II中另一种通讯机制，它可以使一个任务或者中断服务子程序向另一个任务发送以指针方式定义的变量。因具体的应用有所不同，每个指针指向的数据结构变量也有所不同。为了使用μC/OS-II的消息队列功能，需要在OS_CFG.H 文件中，将OS_Q_EN常数设置为1，并且通过常数OS_MAX_QS来决定μC/OS-II支持的最多消息队列数。

μC/OS-Ⅱ提供一系列API函数供用户调用，实现各个任务之间的通信和同步功能。下面以信号量为例说明各个API的实现。

F6.5说明了任务、中断服务子程序和信号量之间的关系。图中用钥匙或者旗帜的符号来表示信号量：如果信号量用于对共享资源的访问，那么信号量就用钥匙符号。符号旁边的数字N代表可用资源数。对于二值信号量，该值就是1；如果信号量用于表示某事件的发生，那么就用旗帜符号。这时的数字N代表事件已经发生的次数。从图

函数参数传递的是要创建的信号量的初始值，在函数内部对任务控制块进行初始化。OSSemCreate()返回给调用函数一个指向任务控制块的指针。以后对信号量的所有操作，如OSSemPend(), OSSemPost(), OSSemAccept()和OSSemQuery()都是通过该指针完成的。因此，这个指针实际上就是该信号量的句柄。如果系统中没有可用的任务控制块，OSSemCreate()将返回一个NULL指针。

值得注意的是，在μC/OS-II中，信号量一旦建立就不能删除了，因此也就不可能将一个已分配的任务控制块再放回到空闲ECB链表中。如果有任务正在等待某个信号量，或者某任务的运行依赖于某信号量的出现时，删除该任务是很危险的。

它首先检查指针pevent所指的任务控制块是否是由OSSemCreate()建立的。如果信号量当前是可用的（信号量的计数值大于0），将信号量的计数值减1，然后函数将“无错”错误代码返回给它的调用函数。显然，如果正在等待信号量，这时的输出正是我们所希望的，也是运行OSSemPend()函数最快的路径。

它首先检查参数指针pevent指向的任务控制块是否是OSSemCreate()函数建立的，接着检查是否有任务在等待该信号量。如果该任务控制块中的.OSEventGrp域不是0，说明有任务正在等待该信号量。这时，就要调用函数OSEventTaskRdy()，使一个任务进入就绪状态，把其中的最高优先级任务从等待任务列表中删除并使它进入就绪状态。然后，调用OSSched()任务调度函数检查该任务是否是系统中的最高优先级的就绪任务。如果是，这时就要进行任务切换[当OSSemPost()函数是在任务中调用的]，准备执行该就绪任务。如果不是，OSSched()直接返回，调用OSSemPost()的任务得以继续执行。如果这时没有任务在等待该信号量，该信号量的计数值就简单地加1。

上面是由任务调用OSSemPost()时的情况。当中断服务子程序调用该函数时，不会发生上面的任务切换。如果需要，任务切换要等到中断嵌套的最外层中断服务子程序调用OSIntExit()函数后才能进行。

当一个任务请求一个信号量时，如果该信号量暂时无效，也可以让该任务简单地返回，而不是进入睡眠等待状态。这种情况下的操作是由OSSemAccept()函数完成的。该函数在最开始也是检查参数指针pevent指向的事件控制块是否是由OSSemCreate()函数建立的，接着从该信号量的事件控制块中取出当前计数值，并检查该信号量是否有效（计数值是否为非0值）。如果有效，则将信号量的计数值减1，然后将信号量的原有计数值返回给调用函数。调用函数需要对该返回值进行检查。如果该值是0，说明该信号量无效。如果该值大于0，说明该信号量有效，同时该值也暗示着该信号量当前可用的资源数。应该注意的是，这些可用资源中，已经被该调用函数自身占用了一个（该计数值已经被减1）。中断服务子程序要请求信号量时，只能用OSSemAccept()而不能用OSSemPend()，因为中断服务子程序是不允许等待的。

在应用程序中，用户随时可以调用函数OSSemQuery()来查询一个信号量的当前状态。该函数有两个参数：一个是指向信号量对应事件控制块的指针pevent。该指针是在生产信号量时，由OSSemCreate()函数返回的；另一个是指向用于记录信号量信息的数据结构OS_SEM_DATA（见uCOS_II.H）的指针pdata。因此，调用该函数前，用户必须先定义该结构变量，用于存储信号量的有关信息。在这里，之所以使用一个新的数据结构的原因在于，调用函数应该只关心那些和特定信号量有关的信息，而不是象OS_EVENT数据结构包含的很全面的信息。该数据结构只包含信号量计数值.OSCnt和等待任务列表.OSEventTbl[]、.OSEventGrp，而OS_EVENT中还包含了另外的两个域.OSEventType和.OSEventPtr。

　　4． 时间类API的设计思路和实现机制

μC/OS-Ⅱ(其它内核也一样)要求用户提供定时中断来实现延时与超时控制等功能。这个定时中断叫做时钟节拍，它应该每秒发生10至100次。时钟节拍的实际频率是由用户的应用程序决定的。时钟节拍的频率越高，系统的负荷就越重。

下面主要讲述五个与时钟节拍有关的API函数。

这应该程序员们调用最多的一个函数了，这个函数完成功能很简单，就是先挂起当起当前任务，然后进行任务切换，在指定的时间到来之后，将当前任务恢复为就绪状态，但是并不一定运行，如果恢复后是优先级最高就绪任务的话，那么运行之。简单点说，就是可以任务延时一定时间后再次执行它，或者说，暂时放弃CPU的使用权。一个任务可以不显式的调用这些可以导致放弃CPU使用权的API，但那样多任务性能会大大降低，因为此时仅仅依靠时钟机制在进行任务切换。一个好的任务应该在完成一些操作主动放弃使用权。

　OSTimeDly()虽然是一个非常有用的函数，但用户的应用程序需要知道延时时间对应的时钟节拍的数目。增加了OSTimeDlyHMSM()函数后，用户就可以按小时(H)、分(M)、秒(S)和毫秒(m)来定义时间了，这样会显得更自然些。与OSTimeDly()一样，调用OSTimeDlyHMSM()函数也会使μC/OS-Ⅱ进行一次任务调度，并且执行下一个优先级最高的就绪态任务。任务调用OSTimeDlyHMSM()后，一旦规定的时间期满或者有其它的任务通过调用OSTimeDlyResume()取消了延时，它就会马上处于就绪态。同样，只有当该任务在所有就绪态任务中具有最高的优先级时，它才会立即运行。

μC/OS-Ⅱ允许用户结束延时正处于延时期的任务。延时的任务可以不等待延时期满，而是通过其它任务取消延时来使自己处于就绪态。这可以通过调用OSTimeDlyResume()和指定要恢复的任务的优先级来完成。实际上，OSTimeDlyResume()也可以唤醒正在等待事件的任务，虽然这一点并没有提到过。在这种情况下，等待事件发生的任务会考虑是否终止等待事件。

用户可以通过调用OSTimeGet()来获得该计数器的当前值。也可以通过调用OSTimeSet()来改变该计数器的值。注意，在访问OSTime的时候中断是关掉的。这是因为在大多数8位处理器上增加和拷贝一个32位的数都需要数条指令，这些指令一般都需要一次执行完毕，而不能被中断等因素打断。

　　5． 临界区类API的设计思路和实现机制

和其它内核一样，μC/OS-Ⅱ为了处理临界段代码需要关中断，处理完毕后再开中断。这使得μC/OS-Ⅱ能够避免同时有其它任务或中断服务进入临界段代码。

μC/OS-Ⅱ定义两个宏(macros)来关中断和开中断，以便避开不同C编译器厂商选择不同的方法来处理关中断和开中断。μC/OS-Ⅱ中的这两个宏调用分别是：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。因为这两个宏的定义取决于所用的微处理器，故在文件OS_CPU.H中可以找到相应宏定义。每种微处理器都有自己的OS_CPU.H文件。

很多人都以为它是个函数，其实不然，仔细分析一下OS_CPU.H文件，它和下面马上要谈到的OS_EXIT_CRITICAL都是宏。他们都是涉及特定CPU的实现。一般都被替换为一条或者几条嵌入式汇编代码。由于系统希望向上层程序员隐藏内部实现，故而一般都宣称执行此条指令后系统进入临界区。其实，它就是关个中断而已。这样，只要任务不主动放弃CPU使用权，别的任务就没有占用CPU的机会了，相对这个任务而言，它就是独占了。所以说进入临界区了。这个宏能少用还是少用，因为它会破坏系统的一些服务，尤其是时间服务。并使系统对外界响应性能降低。

这个是和上面介绍的宏配套使用另一个宏，它在系统手册里的说明是退出临界区。其实它就是重新开中断。需要注意的是，它必须和上面的宏成对出现，否则会带来意想不到的后果。最坏的情况下，系统会崩溃。我们推荐程序员们尽量少使用这两个宏调用，因为他们的确会破坏系统的多任务性能。

通过对μC/OS-II中这几类API的简单分析，我们可以看出μC/OS-II作为一个多任务、抢占式嵌入式操作系统，其API都是为多任务及其多任务之间的调度和通信的实现来设计的。μC/OS-II提供的API简洁而灵活，使用户在设计实际应用时能够很方便的利用系统提供的各种调用，充分发挥μC/OS-II实时、高效的优点。

王田苗，嵌入式系统设计与实例开发—基于ARM微处理器与μC/OS-Ⅱ实时操作系统[M].清华大学出版社，2002.9

• 提炼本质、专注内容、还原情境...

• js判断函数是否存在...

• js获取服务端时间，利用js读取文件头信息，虽然还是会有一点延时，但是已经很好了。...

• jquery绑定自定义事件，如绑定事件名：diyEvent，测试参数名如：event,a,b ，触发这个自定义参数使用trigger来触发，如下代码在click中触发了diyEvent 这个事件并传递了参数，貌似参数要以数组形式传入...

• textarea随文字的增多自动增高或者减小，这里是利用了textarea中的换行符\n 然后改变 row 的值实现的textarea随文字的增多自动增高或者自动减少。...

• jquery上传插件uploadify v3.2.1使用说明api，详细注释。上传插件uploadify新版3.2+的使用方法已经变化和老的上传插件有很大出入。...

• js监听input等表单输入框的变化事件oninput，手机页面开发中使用到文本框textarea输入字符监听文本框变化计算还可以输入多少字符，如果使用onkeyup的话...

• 谷歌二维码api来生成二维码，先看一个示例：如果只是固定一个二维码不变的话，建议去网站搜索一下二维码在线生成，生成二维码比较好。在线生成的二维码还可以选择渐变色，添加标志logo等功能。...

• js动态插入css或者js文件，打开页面时浏览器动态的加载js文件、动态的加载css 文件...

项目中需要做一个面向开发者的开放API平台，想问问各位大神，一般API Gateway或者OpenAPI的平台都包括哪些功能？是否有什么资料或者书可以参考、借鉴和学习的呢？
目前我仅仅知道OpenAPI平台需要做权限验证、用户注册；据了解好像应该还有API编排等，但是没有系统的了解过，希望各位大神能够指点1,2，谢谢。

• 参考一：淘宝开放平台/?spm=a…

个人想法: 大致从签名鉴权，流量控制，请求转发，日志记录等这几个方面下手

本文出自汗血宝马，转载时请注明出处及相应链接。