第1章 开发工具安装和配置

详见《DIDE使用说明书》，该说明书可以在官网有下载链接，在安装DIDE后，首次打开DIDE时，如果你的电脑安装有PDF文档阅读器，则会自动打开。

第2章 Hello led

2.1 获取源码

DJYOS是开源系统，安装DIDE后，首次运行时，DIDE会自动从git服务器上下载最新源码，当服务器上源码更新，也会自动更新。

我们都是跟随“HelloWorld”进入编程的世界，当第一次见到屏幕上显示“Hello World”时，感觉那就是全世界最美的字符。

但在深度嵌入式环境中，想看到“HelloWorld”可不是件简单的事，初始化输出输出终端环境，可不是件简单的事，至少，你需要有LCD，或者驱动串口吧。

在嵌入式板件中，一般都会有LED灯，控制gpio点个灯，比输出“Hello World”要简单得多，这里就用跑马灯来演示djyos下第一个应用程序。

先讲讲下面main.c文件中程序开头include的几个头文件。

os.h，几乎所有的DJYOS应用程序，都需要包含这个头文件，因为这个文件里面包含了所有OS内核数据结构和函数声明。

Cpu_peri.h，这个文件在“djysrc\bsp\cpudrv\cpuname\include”目录下。DJYOS的BSP中，所有CPU片内外设，都在bsp\cpudrv目录下。该文件包含了CPU外设的数据结构定义、变量声明等。凡是需要使用CPU片内外设的程序，都应该包含这个头文件。

stm32f10x.h和LED.h就不说了,大家都懂。

djy_main函数，是应用程序的入口函数，所有djyos发布版本都会带有这个函数。

按照《DIDE使用说明书》中介绍的方法，编译和烧录后，你的第一个djyos应用程序就完成了，赶紧上电试试吧。

第3章 裁减与配置

djyos提供强大的功能，但每个APP，往往只用到其中一小部分功能，为了减少占用RAM和FLASH，我们需要裁减掉一些组件，或者通过配置，弱化一些组件的功能。

DIDE提供了图形化的方法帮助我们裁减和配置djyos，参见《DIDE使用说明书》。

第4章 shell终端

DJYOS的shell是一种命令行式的shell。它可以接受用户命令，然后调用系统相应的程序，实现用户与操作系统之间的交互。

由于djyos是高度可裁减的，只有勾选的组件，其配套的shell命令才会加入，不同的系统配置，help命令列出的命令列表，会有所不同。

4.1 智能多IO端口

智能多IO端口是djyos的贴心功能。

djyos支持智能多IO端口，例如你可以同时使用串口和Telnet，如果从串口收到shell命令，则命令执行结果从串口输出；如果从Telnet收到shell命令，则命令执行结果从Telnet输出。

智能多IO端口有什么用？

工业设备用户的应用需求五花八门，有时候会提出多shell终端的需求。举一个案例，某工业现场运行的设备，用网络连接到远程服务器，需要在服务器上用Telnet登录执行shell命令；同时，本地设计有调试串口，厂商现场调试时，就需要用调试串口作为shell终端，且不允许碰用户的网络连接。

工业设备的安装现场环境，也会有类似的需求，例如某款电力设备，有些安装条件，现场维护人员只能接触到前面板，有些则只能接触到后面板。设备的前面板有网口，调试串口则安装在后面板。限于结构设计，调试串口无法在前面板引出。如果没有智能多终端，则软件必须按照现场安装条件不同，分成“前面板shell”版本和“后面板shell”版本，增加了版本管理成本。

shell控制台作为用户与操作系统之间的一种交互方式，通过标准IO的stdin输入控制命令，向stdout输出结果，向stderr输出出错信息，因此，使用shell之前，必须安装和配置好输入输出终端设备，详见第12.5.1节。

4.2 配置shell功能

通过DIDE中配置，可以裁减掉shell，也可以配置shell功能的强弱，以调节flash和ram占用，控制成本。

shell的功能，不外乎输出信息，执行命令，调用函数，查看变量，修改变量。配置shell功能的强弱，就是配置shell支持的命令集，调用的函数集，读/写的变量集的大小。

在DIDE的配置界面中，可以配置shell_level参数，SHELL_LEVEL_BASE、SHELL_LEVEL_EXPAND、SHELL_LEVEL_ALL三个级别。

图 4‑1DIDE中配置shell功能

DIDE如何使用，参见《DIDE使用说明书》

每个级别功能呈子集关系。

图 4‑2shell功能包含关系

4.2.1 BASE Level

shell level = BASE，则只支持一组基本的shell命令以及一组全局变量。

BASE组命令的执行函数原型必须是：

bool_t func_name(char *param);

宏ADD_TO_ROUTINE_SHELL用于把“func_name”函数添加到BASE功能组中，用法如下：

ADD_TO_ROUTINE_SHELL(cmdname, func_name,”命令的帮助信息”);

shell中执行BASE组命令的方法：

>cmdname parameter list [回车]

func_name函数将被调用，命令的参数由执行函数自己解释。

宏ADD_TO_ROUTINE_DATA用于被修饰的全局变量添加到BASE功能组，用法如下：

u32 var_name ADD_TO_ROUTINE_DATA;

BASE组全局变量查看和修改方法：

>var_name [回车]

即可查看变量。

>var_name = new value [回车]

即可修改变量。

4.2.2 EXPAND Level

若shell level =EXPAND，则在BASE组的基础上，增加一组基本的shell命令以及一组全局变量。

命令和变量加入到EXPAND组的方法与BASE组基本一样，就是宏的名称不一样，分别是：

ADD_TO_EXPAND_SHELL  和

ADD_TO_EXPAND_DATA

新增全局变量的使用方法与BASE组是一致的。

新增shell命令使用方法与BASE组不一样，BASE组执行函数的原型是固定的，EXPAND组执行函数原型是任意的（参数不能超过10个）。

EXPAND组命令的执行方法：

> cmdname 参数1类型 参数1  参数2类型 参数2 参数3类型 参数3……[回车]

执行函数的每一个参数，都需要在命令行中输入其类型，例如：

void ExpandSh(u32 a, float b);

ADD_TO_EXPAND_SHELL(myname, ExpandSh,"扩展shell命令范例");

在shell中调用时，格式是：

>myname u32 100 f 10.0 [回车]

数据类型表定义如下：

可见，EXPAND组命令的参数类型，是有限制的，无法使用指针传入的参数，也无法用指针输出参数，因此，参数中包含指针的函数，除非可以用NULL，否则无法在shell命令行调用。

4.2.3 ALL Level

若shell level =ALL，则全部函数都可以调用，全部全局变量均可以查看和修改。

BASE组和EXPAND组的函数，命令名和函数名可以不一样，ALL的函数，shell中输入函数名来调用，以及没有帮助信息。

除此之外，ALL组的函数调用和查看变量和修改变量的方法，与EXPAND组无异，不再赘述。

同样的原因，参数中包含指针的函数，除非可以用NULL，否则无法调用。

4.3 添加shell命令

djyos提供了四个宏，用于把用户定义的函数添加到shell表中去，以及把自己定义的变量添加到shell中。语法很简单，直接上代码，解释都是多余的了。

4.4 使用shell注意事项

4.4.1 输入命令限制

shell的输入命令和命令所带的参数，总长度不能超过255字节，并且拓展shell的命令参数不能超过10个。

shell虽然支持总长度超过255字符的路径名，但由于命令行长度限制，在命令行下，无法操作超过255字节的路径名。

4.4.2 文件和目录不能含有空格

shell支持在文件名和目录名中包含空格，但由于shell以空格作为断字符，故在shell中输入的文件名或者目录名不能包含空格符。

4.4.3 当前工作路径

si和dlsp版本是单进程的，当前工作目录是一个全局概念，在shell中使用cd命令改变当前目录时，需要特别注意，在shell中改变当前路径，应用程序是不知道的，如果应用程序继续使用原来的“当前路径”操作文件系统，将出现不可预料的错误。

4.4.4 函数调用

shell允许你调用任意函数，包括操作系统API、你自己写的任何函数。这个功能有一定的危险性，建议不要在在线运行的设备中使用，只在调试时打开这个功能。它的危险性来自于以下两个方面：

1.      被调用的函数是在shell事件的上下文中执行，shell并不知道被调用的函数所需的栈空间，也就存在栈溢出的可能，栈溢出的危险性，我不说，大家都清楚。你请客，我买单，我不知道你点什么菜，怎知道要带多少钱？

2.      你既然能用shell调用任何函数，也就可以干任何事，干好事坏事，全凭你的良心。

3.      如果被调用函数是不能重入的，而正好别的函数也在调用，结果同样不可预料。

第5章 事件、事件调度和线程调度

5.1 事件

计算机处理的是现实世界中的具体任务，有因才有果，现实生活中的任务不会无缘无故地产生，人们做某一件事肯定是因为发生了某种事件使其需要去做这件事情，这就是事件。计算机中的事件与现实生活中的事件是一致的，CPU不会无缘无故地执行某一段代码，就算是一段包含在一个if语句里的代码被执行，肯定是因为发生了使该条件成立的事件。人走到沙发前是一个事件，智能沙发上的计算机发现这个事件后然后处理这个事件，处理结果是执行调整坐垫到合适位置的操作；人转身面对电视机是一个事件，智能电视机里的计算机发现这个事件然后处理这个事件，处理结果是执行打开电视机的操作；人躺在床上并闭上眼睛，智能家居的计算机发现这个事件然后处理这个事件，处理的结果是执行关灯的操作。以上所述的事件，就是DJYOS操作系统中“事件”的原型。所有这些原型中，都有一个“发现”（或称“检测”）事件和执行一定操作以处理事件的过程，现实系统中，这两个过程可能非常复杂，甚至处于两个不同的学科，其软件实现模块可能会由两个不同专业方向的程序员编写。DJYOS软件模型是：由一个软件模块专门用于监测人的行为，另外一些模块执行开关灯、开关电视机、调整沙发坐垫的操作。检测模块发现人靠近沙发的事件后，不是去调整沙发坐垫，而是把“事件”报告给操作系统了事。操作系统收到该事件后，先把该事件记录在调度队列中，再依据调度算法，当决定要处理该事件时，就分配或创建用于处理该类型事件的线程，并启动该线程，再由这个线程去执行调整沙发坐垫的操作。这样，就使“检测”和“执行”相互独立开来。进程、线程之类的东西只是操作系统内部的秘密，线程作为一个资源，是创建新资源还是使用现有资源来处理事件，完全由操作系统自动完成，应用程序的程序员不知道也不需要关心这些。

DJYOS下程序运行的过程，就是新事件不断发生，然后被处理的过程。在此过程中，操作系统组织、创建、分配线程、进程以及其他资源去满足处理事件所需。每弹出一条事件，DJYOS操作系统就为它分配一个事件控制块，事件处理完毕后收回事件控制块。未处理完毕的事件就会堆积在队列中，操作系统对队列的容量有一定的限制，当队列中事件数量达到上限时，操作系统将拒绝接受新事件。core_config.c文件中的gc_u32CfgEventLimit常量用于确定队列容量，用户可以修改，但不能在程序运行过程中动态改变，最多允许16384个事件。

5.2 事件类型

程序运行期间会发生各种各样的事件，不同种类的事件由各自的线程处理，需要用事件类型去加以区分。DJYOS操作系统为每一类事件分配一个唯一的事件类型ID号，并为每个事件类型分配一个事件类型控制块（struct EventType）。事件类型控制块是静态分配的，其数量须按照内存量和应用程序实际需求合理设定，由工程目录下的core_config.c文件中的gc_u32CfgEvttLimit常量确定，用户可以修改，但不能在程序运行过程中动态改变，最多允许16384个事件类型。

事件类型必须调用DJY_EvttRegist函数登记才能使用，登记时要为该事件类型指定一个事件处理函数，该函数将成为线程的入口函数，还要设定该类型的默认优先级，并且告诉操作系统该函数运行需要多少栈空间。在某些情况下，操作系统会为部分类型事件至少保留一个线程（参见5.4节），当有该类型的事件发生(调用DJY_EventPop)时，操作系统可能会自动创建线程处理该事件，也可能会指挥现有线程（或创建线程）去处理该事件。

5.2.1 独立型和关联型事件

如果某类型事件重叠发生（即事件未处理完成，又发生相同类型事件），产生的多条事件可以用多个线程并行处理的，称为独立型事件。典型的独立型事件是web服务，当web服务器收到多个客户端的服务请求后，这些请求一般是独立的，服务器会创建多个线程独立处理多个请求。独立型事件用EN_INDEPENDENCE表示，该类型的每条事件都需要单独处理，每次弹出独立型事件，都会在事件队列中添加一条事件，事件反复发生而又来不及处理时，事件队列中将积压多条同一类型的事件。独立型事件也有特例，如果在调用DJY_EventPop函数时使用的参数是事件ID，也不会添加新事件，参见第5.7.6节。

反之，如果重叠事件互相关联，必须在一个线程中顺序处理，称之为关联事件。该类型事件一般表示的是物理世界的一种状态，若此类型的事件重复发生，它也只代表系统处于某种状态，不是每次发生的事件都需要单独处理。关联型事件用EN_CORRELATIVE标记，这种事件无论重复发生多少次，事件队列中都只会保留一条事件。这是一种很重要的事件，因为现实世界中有太多的关联型事件，试举数例如下：

1. 快件投递中，当客户有快件需要投递，就会给快递公司电话，同一个地址，无论重复多少次电话，只需派收件员上门一次把积累的快件全部取走就可以了。

2. 在LCD面板显示软件中，在内存中设计了一个显存镜像，应用程序修改显示内容时，修改的是镜像显存，然后发出“显示刷新”类型事件，处理该事件的过程就是把镜像显存中的图像搬到物理显示器上。这是一个典型的关联型事件，无论应用程序修改了多少次镜像显存，都表示“显存被修改”这一物理状态，处理一次“显示刷新”事件将把历史上积累的事件完全清理。

3. 串口通信软件中，缓冲区接收到数据，会发出“缓冲区有数据需处理”类型的事件，无论该类型事件重复发出多少次，都表示这样一个状态，事件处理时只要把缓冲区的所有数据取走，就可以了。

独立型事件的例子也很多，例如：

1. 在百货商店，每进来一个顾客算发生了一个“顾客来了”类型的事件，由于每个顾客都是独特的，所以必须单独服务。

2. 同样是LCD面板显示软件中，当用户需要绘制时，就会发出“屏幕绘制”事件，因为每次绘制的内容都可能不同，所以每条事件都必须单独处理。

3. 通信软件中，应用程序需要发送数据，就把数据准备好，弹出“发送数据”类型的事件，并把数据缓冲区作为事件参数，由于每次事件的数据缓冲区都是独立的，不能把多条事件统一处理，而是每条事件都要单独处理。

5.3 线程

DJYOS以事件为调度单元，理论上，操作系统可以用任何方法处理事件，只要能够调用事件处理入口函数就可以了，当前版本的DJYOS操作系统使用的方案是，创建一个线程执行事件处理入口函数来实现事件处理。注意，线程是操作系统自行创建的、用于执行用户提供的事件处理入口函数的手段，对程序设计者是不可见的，这就隐含了一个事实：操作系统还可以选择其他方案代替线程方案，遗憾的是，笔者至今也没有想到可以替代线程的可行方案。要处理事件，操作系统就要为该事件创建线程，用户在登记事件类型时必须告诉操作系统执行该入口函数需要多少栈空间。在DJYOS系统中，线程是处理事件的执行者，也作为事件的资源而存在——完成该事件需要许多资源，线程是诸多资源之一。

5.4 事件、事件类型与线程的关系

套用面向对象的方法，事件类型相当于C++的类，登记事件类型相当于声明一个类数据类型；事件相当于对象，弹出事件相当于定义对象，同时做一些构造函数的工作；事件处理完成相当于撤销一个对象，同时做一些类似析构函数的工作。

DJYOS中应用程序的运行过程，就是不断地弹出新事件和处理事件的过程。每个事件都必须属于已经登记的事件类型，相同类型的事件使用相同的线程进行处理。

DJYOS操作系统中，线程作为事件的资源而存在，而该事件就是线程的拥有者，因此，任何线程，都不能无缘无故地出生、存在和死亡，它必定与某一类型的某一条事件联系在一起。线程随事件的需要而生，随事件完成而消亡。线程无需登记，也无需有用户建立和启动，它的创建、启动和删除都是由操作系统自动完成的。这与传统操作系统不一样，传统操作系统可以由用户任意创建线程，创建一个毫无意义的线程是允许的。DJYOS系统的调度依据是一个就绪事件队列和若干个同步事件队列，而不是线程队列（有的操作系统也称其为任务队列），DJYOS中根本就没有线程队列。DJYOS的调度针对事件而不是线程，创建一个线程是因为它的拥有者需要处理，线程被切入是因为该线程的拥有者需要被切入，线程被切离是因为它的拥有者被挂起。把线程作为事件的资源的积极意义在于，当某类型的事件连续发生，操作系统将调集更多的资源，为其创建多个线程来处理该事件，如果在多处理机（多核）系统中，把这些线程分配给不同的处理器，处理器本身也就成为一种资源，将极大地方便多处理器系统的管理。而传统的编程方法中，程序员创建若干线程待机，每个线程对应一种或数种事件，待相应的事件发生后，唤醒线程予以处理，这种方式在管理多处理器方面要复杂得多。因此，DJYOS在多处理器系统中，有先天的优越性。

线程的属性必须与事件类型对应，相同类型的事件使用相同的线程处理，不同类型的事件使用不同的线程处理。用户登记一个事件类型时，必须传入操作系统创建用于处理该类型事件的线程所需要的两个关键参数：事件处理入口函数和该函数需要的栈空间。当某类型的事件发生后，操作系统就会在适当的时候创建线程（或分配存在的线程）执行该类型对应的事件处理函数。事件处理完成之后，操作系统会自动回收该线程所占用的资源，必要时还会删除线程。

每一条事件对应一个线程，如果有多条同一类型的事件需要处理，操作系统会创建多个相同的线程同时处理多个相同的事件。这可以更合理地使用计算机资源。虽然在单处理器的情况下，建立多个线程并不会比单个线程长期霸占处理器更充分利用处理器，但可以产生多个相同类型事件并行处理的效果，例如同时绘制多个窗口，特别是，在多处理机（或多核）系统中，可以把频繁发生的同一类型事件分配到不同的处理器上。而传统操作系统下，线程是由程序员创建的，如果程序员只为某项工作创建了一个线程，则该工作再繁忙也只有一个线程为它工作，该线程处理的多项任务只能串行执行。但是这样反复创建线程可能导致资源枯竭，比如处理某事件时需要使用串口，而串口又被其他线程占用，在串口被占用期间发生该事件，操作系统就会再次为其创建线程，该线程开始执行后会因串口资源繁忙而进入阻塞状态，如果事件反复发生，操作系统就会反复为其创建线程，直到消耗完所有内存，造成内存枯竭。为了防止发生资源枯竭事故，在事件类型控制块中提供了vpus_limit成员，表示该类型事件可以同时建立线程的个数。

5.5 线程调度和事件调度

DJYOS系统中，调度是以事件为依据，线程是事件的资源，线程本身是没有优先级的，但上述理论依然适用，只要把其中的“线程”两字改为“事件”就可以了。

在实时系统中，事件的优先级是能否实现实时指标的关键，现实中，大多数事件会继承事件类型的默认优先级，因此确定每一类事件的默认优先级是系统设计的重中之重。

基于事件进行调度，这是DJYOS与传统操作系统最大的区别。图 5‑1是从传统操作系统抽象出来的，无论是简单的OS还是复杂OS，其调度都是基于线程的。图 5‑1中，无论是初始化创建线程，还是线程执行过程中创建线程，都是在创建线程的时候分配线程所需要的资源，栈是其中的必备件。图 5‑2中，弹出事件时，除非新事件的优先级足够高，需要立即处理，否则弹出时不会分配或创建线程，直到该事件应该被处理的时候才创建或分配线程。

图 5‑1传统操作系统调度示意图

图 5‑2事件调度示意图

看起来，除了不能从中断处理函数中创建线程外，两图有很大的相似性，其实不然，传统OS下编程时，不应该频繁地在线程执行过程中创建新线程的，为什么呢？为了创建线程而导致阻塞，而被阻塞的却是当前线程。如果新线程的优先级低于当前线程，那当前线程就冤了，因为一个低优先级的线程，而导致高优先级线程阻塞，这在RTOS中是不允许的，从系统方案设计角度，也是不合理的；即使不被阻塞，高优先级线程执行过程中，花大量时间用于创建低优先级的线程，也是不合理的。所以，传统OS下编程时，所有线程总是在初始化阶段创建，极少在运行过程中创建。而DJYOS则没有这个问题，如果新弹出的事件优先级不够高，根本就不会为他创建线程。这使得DJYOS能够更加优化配置计算机的资源，假设有一个产品，有uart串口，在传统线程模式下， uart通信线程是在初始化时创建的，即使uart通信线没有连接，uart线程也必定占用内存资源。如果uart通信非常频繁地发生，也只能由初始化时创建的那个线程一点一点来处理，即使你有多个cpu核，其他cpu核也只能干着急。那不能创建多个线程吗？可以，线程池技术就是这样干的，究竟创建多少线程才合适，是一个非常令人头疼的问题。在传统OS下，线程池技术可是一门专门的学科哦。而DJYOS的事件调度呢？如果uart通信线上没有数据，则根本不会弹出该事件，也就不会占用任何资源。如果uart口频繁通信，就会频繁弹出事件，若计算机有多个cpu核，则自然而然地会把事件分散到不同的cpu核上，程序员根本不知道线程为何物，就能进行优化的多核编程。

大家都知道vc、cbuilder下编程吧，在桌面上放上一个按钮，然后为按钮点击事件编写处理函数，当用户点击该事件时，处理函数就被执行。这就是事件触发式编程，这是怎么实现的呢？原来，有一个线程一直在后台候着，等待windows发出的消息，一旦收到点击消息，线程便被唤醒执行。我们可以看到，无论该按钮是否被点击，甚至一辈子都不点击，该线程依然要占用系统资源。而DJYOS的方法则不同，只要该事件不发生，则不会占用任何系统资源。VC为什么要实现事件触发式编程呢？是因为现实需要，与传统操作系统需要像VC这样的工具支持才能实现事件触发式编程相比，DJYOS只需要文本编辑器就可以实现。VC这样的工具只能用于较大的系统中，而DJYOS却可以用在单片机中！

传统的基于线程（进程）的调度模式下，操作系统只知道哪个线程（进程）正在占有CPU，却不能知道该线程（进程）在干什么，调度器也只能针对线程（进程）分配CPU，不能针对计算机所处理的具体事务分配CPU。因此，传统操作系统下，程序员必须熟练掌握有关线程（进程）的知识，必须自己为程序需要处理的事务创建线程（进程），清楚在哪些状况下有哪些线程（进程）正在运行。而事件调度则不同，用户可能根本不知道线程（进程）的存在，以及谁正在运行，谁正在等待，实际上，程序员根本不需要关心这些。DJYOS系统中，程序员只知道哪个事件正在被处理，哪些事件已经处理完成，哪些事件正在队列中等待处理。定义一个一个的事件类型并登记到系统中，为每类事件编写处理函数，便是编程的全部工作。当相同类型的多条事件，具有不同的优先级时，在传统操作系统下，要么为每一种可能的优先级建立一个线程（进程）来实现，要么在执行中动态改变线程（进程）的优先级，不管哪种方式，程序员都需要花费大量的时间和精力，以确保事件按正确的优先级得到处理。而DJYOS不同，它先天就是以事件优先级作为调度的基础，只要在产生事件时，直接在事件中做优先级标志就可以了。例如一个串口通信程序，中断函数负责底层接收，当接收到完整数据包后，就发给上层应用程序处理，上层应用程序处理接收到的所有数据包，而数据包中有一个命令字域，不同的命令要求的优先级不同。在传统操作系统下，要么创建一个comm_app线程，在中断函数中把数据传送给该线程的同时根据命令字改变comm_app线程的优先级，这种在中断函数中改变线程优先级的做法，在许多操作系统中是不允许的；另一种方法是，为命令字对应的每一种可能的优先级，均创建一个相同的线程，这些线程除优先级不同外，其它部分完全相同，当中断函数接收到完整数据包时，就根据数据包中的命令字，发消息给相应优先级的线程。这种方法虽然可行，但是会消耗很多CPU资源，且难于在编码阶段穷举所有可能的优先级，一旦命令字发生变化，很可能就需要修改软件源码。而DJYOS系统不一样，程序员只需要定义一个事件类型，并为之编写事件处理函数proc_uart()，当中断函数接收到完整数据包，弹出事件时直接以命令字对应的优先级作为参数就可以，DJYOS的调度系统自动会根据事件优先级域进行调度。

另外，嵌入式系统多是应激系统，应激系统的主要任务是对外界的事件做出正确且及时的反应，从这点看，程序员根本就不用知道进程和线程这些东西，为处理外界事件而建立线程（进程）实际上是不得已而为之，传统操作系统下，你必须做这些工作，你的系统才能正确地为你做些事情。基于事件的调度非常适合这种应激系统，被调度的目标就是反映外部刺激的事件，而不是处理这些外部刺激的线程，符合人们的习惯性思维。即使是非应激系统，或者是非实时系统，基于事件的调度仍然有其优势，“有事就做，没事就坐”是人们最为习惯的思维方式，以事件为调度单位的调度策略显然符合这种思维方式，而与人们习惯性思维相同的调度方式，又是避免人为错误，减少软件bug的有效方法。

现代计算机已经进入“ubiquitous/Pervasive Computing”时代，即普适计算。在普适计算时代，触手可及的计算产品里面也包含着触手可及的计算机程序，这些程序由大量的嵌入式程序员编写，是的，十年前的硬件工程师可以不懂软件，软件工程师可以不懂硬件，而今天的嵌入式技术，除了在一些很特殊的方向如射频设计，已经没有纯粹意义上的软件工程师和硬件工程师了。让这些队伍迅速壮大的、软硬兼顾的“普适计算工程师”们去掌握晦涩难懂的进程和线程技术并灵活应用，恐怕要花费不少的人才培养成本，而使用传统的操作系统去开发嵌入式产品，不理解这些复杂的概念根本就寸步难行，而人才的匮乏又将限制嵌入式产业的发展。DJYOS操作系统不要求程序员操纵线程和进程，程序员只需把需要计算机处理的任务划分为一个个事件类型，并为各种不同类型的事件编写独立的事件处理函数，然后把它登记到系统中就可以了。当事件发生时，发现（检测到）该事件的程序员只要告诉操作系统“某类型事件发生了”，操作系统自动地创建或唤醒合适的线程去处理该事件，而无须程序员亲自创建或者唤醒相应的线程。当然，“普适计算工程师”即使是在DJYOS系统下编程，深入理解线程和进程技术，对开发工作也是很有帮助的。

5.6 典型情景编程对比

DJYOS与传统操作系统在调度方式上的差异，必然导致在其在编程模型上的差异。传统方式下，程序员编写函数以处理需要计算机完成的任务，然后建立线程来运行这些函数，创建线程、启动线程、线程同步、线程暂停、线程休眠、线程终止、线程删除等操作，均由程序员亲自完成。在DJYOS下，认为计算机执行某一段程序，必定是发生了使计算机执行这段程序的事件，计算机的所有操作，均由事件引发。程序员所需要做的工作是，以适当的粒度定义事件类型，为各类型事件编写处理函数，并且在需要的时候弹出事件，在必要的时候调用操作系统提供的事件同步功能。由此而导致了两种截然不同的编程模式，下面，我们通过不同场景的对照，来直观了解一下这两种编程方式。

5.6.1 场景1

一个网络通信端口收发模块，监视网络端口状态以及收发数据流。

这种模块一般是系统启动后即开始运行，只要通信口不关闭，就需要持续接收数据，直至关机，在整个运行期需要不间断地监视网络端口，并做出相应的响应。

5.6.1.1 传统操作系统实现方案

5.6.1.2 DJYOS实现方案

5.6.1.3 分析

分析上面两个程序模型，可以看到，这种场景下，两种编程方式看似没有区别。但实际上是有区别的，因为事件是直观的，与人类思维模式比较接近；线程是抽象的，与计算机的执行过程接近。越接近人类自然思维，就越容易学习和掌握，编程就越不容易出错。这种区别，从这个简单的例子中不容易体现出来，但如果软件规模比较大、逻辑复杂的系统，这种差别就显示出来了。

现代计算机已经进入“ubiquitous/Pervasive Computing”时代，即普适计算。触手可及的计算产品里面也包含着触手可及的计算机程序，这些程序由大量的嵌入式程序员编写。设计这些产品需要大量的软件工程师，这使得嵌入式程序员的队伍迅速增大，新增的程序员，可能来自各行各业，他们原来在各自的行业中，可能都是非常了不起的专家，比如化工专家、医疗专家等。这些不同领域的专家，却未必是计算机领域的专家，让他们去掌握晦涩难懂的线程技术并灵活应用，恐怕要花费不少的人才培养成本，而使用传统的操作系统开发嵌入式产品，不理解这些复杂的概念根本就寸步难行。DJYOS操作系统不要求程序员操纵线程和进程，程序员只需把需要计算机处理的任务划分为一个个事件类型，并为各种不同类型的事件编写独立的事件处理函数，并且把它登记到系统中就可以了。当事件发生时，发现（检测到）该事件的模块只要告诉操作系统“某类型事件发生了”，不需要管什么线程。从这个角度，DJYOS降低了程序员培训要求，客观地为企业节约了人力资源费用。

5.6.2 场景2

如场景1的通信口监视模块，通信口接收来自外部的请求，把接收到的请求交由服务器处理。为了确保通信口不丢数据包，通信口监视模块的优先级应该比服务模块高。

5.6.2.1 传统操作系统实现方案1

从上述代码中我们可以看到，thread_server线程无论如何，都占据内存的，即使通信线没有插上，一辈子都收不到请求，也是这样。那么，我们有改进方法吗？能不能收到请求后再创建线程，像传统方案2的代码这样。

5.6.2.2 传统操作系统实现方案2

一般来说，这种方法是不合理的，因thread_comm线程是高优先级线程，thread_server是低优先级线程。创建线程需要很长时间，并且分配栈可能需要使用动态分配内存，执行时间和结果都不确定。在高优先级的thread_comm线程中为低优先级的thread_server线程做执行这些操作，相当于在高优先级的线程中，花很多时间为低优先级线程做事，这是不合理的。

再者，在thread_comm中总是判断thread_server是否创建，也降低了运行效率。

5.6.2.3 DJYOS实现方案

表面上，DJYOS下的代码和传统操作系统下方案1的代码类似，但在水面以下，是完全不同的。因为如果event_comm没有收到服务请求，就不会弹出evtt_server事件类型，其所对应的线程就不会被创建，也就不会占用计算机资源。

有读者可能会问了：这样不会出现“传统方案2”中的问题吗？很好，这个担心在DJYOS下是多余的，因为弹出事件仅仅是把事件控制块推进事件调度队列中，需要的时间是非常少的。而创建线程的操作，只有等到该事件必须被处理时，才执行。因event_comm的优先级高于event_server，故不会在event_comm中执行创建线程的操作。

那又有读者可能要问，我要收到服务请求后，需要可靠响应怎么办？的确，创建线程需要分配内存，而分配内存有失败的可能。djyos登记事件类型时，允许静态分配内存的，系统会自动创建线程，等弹出事件之后，就无须创建线程，而是分配线程了。但线程投入运行，仍然是在收到端口发来的数据之后。

5.6.2.4 分析

传统操作系统下，无论任务是否产生，都要占用资源。

DJYOS下，不实际产生任务，就不占用资源。

孰优孰劣，就不用我说了吧。

举个简单例子，某通信产品，依通信口数量不同，有两种型号，A8型有8个通信口，A24型有24个通信口，每个通信口收到的数据，都由独立的线程处理。每个口需要为之创建一个线程，需要分配缓冲区，因此两个型号需要的内存数量和CPU速度是不一样的。

传统操作系统实现该产品的话，因为线程在上电时统一创建，要使软件版本保持一致，就必须为A8和A24型配置相同的内存，付出更高的硬件成本；为了节省成本，A8和A24型会按实际需要配置资源，此时，两个型号的软件版本是不一样的，至少差一个配置常量是不一样的。即使只有一个配置常量不一样，企业也要管理两个不同的版本。

在DJYOS下，未安装的通信口，自动就不占用资源，完全没有上述问题。

5.6.3 场景3

在场景2的基础上，如果频繁收到通信口发来的服务请求，但各个请求之间没有内在的关联，各个请求是可以独立处理的，有许多网络服务器接收的请求，以及云计算中的服务请求，就有这个特点。

5.6.3.1 传统操作系统实现方案

如果使用“传统操作系统方案2”的方法，CPU就只能串行地处理一个个接收到的请求，无论CPU的主频多么高，无论计算机有几个CPU核，都只能如此。

改善的办法是，创建多个线程，把不同的请求分配到不同的线程，但这样做的问题是，你不知道需要创建多少线程，创建的线程要是少了，服务请求密集到达的时候，就不够用；创建多了，就要占用很多资源，即使没有接收到请求，或者请求很少，这些资源也必须占用着。况且，这些活，操作系统内核是不会帮你做的，一切都要应用程序自己张罗。尤其是，在多核环境下，尤其麻烦。于是，就发展出了复杂的线程池技术，用一个用户级的软件组件去管理线程，有兴趣的可以google“线程池”，这里就不再赘述了。

5.6.3.2 DJYOS实现方案

在DJYOS下，天生就能支持优化这种应用。DJYOS的事件类型控制块中，有三个成员是为此类应用服务的：

vpus_res：繁忙时系统为本类型事件保留的线程数量，在登记事件类型时指定，详见djy_evtt_regist函数说明。

vpus_limit：该类型事件同时拥有的线程数量上限，在登记事件类型时指定，详见djy_evtt_regist函数说明。

vpus：本类型事件已经拥有的线程数量。

在这种情况下，只要把5.6.2.3代码中的event_server函数改成如下:

并且在登记evtt_server事件类型时，指定该类型为EN_INDEPENDENCE（独立型）就可以了。

当事件类型登记后，vpus=0或1（如果事件类型的优先级高于128），若事件频繁弹出，即频繁收到服务请求，操作系统将为此类事件创建多个线程，直到线程数量达到上限vpus_limit，达到上限后，如果再有新事件弹出，新事件就将阻塞在调度队列中。线程执行完所需服务后，操作系统会查看事件队列中有没有evtt_server类型的事件，如果有，就直接把线程转交给它。如果没有，再查看evtt_server类型事件拥有的线程数量是否超过vpus_res，若超过就销毁该线程，否则保留该线程。

这样，如果频繁收到服务请求，操作系统就为evtt_server类型事件保持较多线程，否则就维持在比较低的水平。

5.6.3.3 分析

本场景所涉及的，是大量相同或相似任务的线程级并行处理的问题。

传统操作系统面对这种应用时，需要在调度器之上，在应用程序这一级，用复杂的线程池技术才能实现线程级并行，整个程序的复杂度大大增加。而DJYOS却在调度器这一级别直接实现了需要用线程池技术才能解决的问题，仅用了非常少的代码量，系统复杂度几乎没有增加。我们都知道，系统越简单，可靠性越高。

5.6.4 场景4

如何实现事件触发式编程，我们知道，VB、VC等可视化编程工具下是事件触发式编程的，这说明，事件触发式编程是我们所需要的。在传统操作系统和DJYOS下，实现事件触发式编程有什么异同呢？

5.6.4.1 传统操作系统实现方案

让我们来看看CBuilder下的一个编程场景：

先优雅地拖一个按钮放到桌面上。

为鼠标点击该按钮的事件编写处理函数。

编码工作就这样完成了，很简单很强大吧。

接着编译、执行，用鼠标点击该按钮，就会执行处理函数。

这种优雅高效的编程方式是怎样实现的。原来，由开发工具创建的一个或多个线程一直在后台候着，等待操作系统弹出鼠标点击事件。操作系统则负责检测并弹出事件，潜伏的线程一旦收到鼠标点击事件，便被唤醒执行。我们可以看到，无论该按钮是否被点击，甚至一辈子都不点击，该线程依然要占用系统资源。

在事件触发是编程环境下，程序员只与程序需要处理的具体事件打交到，其编程过程完全与线程、进程等无关。我们也知道，在传统操作系统上，只有在PC上或者能运行linux、wince等的高端嵌入式平台上才能使用上述便利。为什么呢？究其原因，是因为操作系统是按照线程调度的，必须经过开发工具的包装后，才能转换成事件触发。而这种包装，需要耗费大量的计算机资源，所以只适合在高端平台上使用。再者，这种包装会大大增加软件的复杂性，其复杂性可能带来不可靠以及不可预测因素，也不适合在实时控制系统中应用。因此传统操作系统下，事件触发式只适合于做复杂的界面编程。

5.6.4.2 DJYOS实现方案

无须多说了，DJYOS只提供事件触发式编程模式，无论在高端平台还是在单片机上，都只能用事件触发式编程，区别仅在于，单片机上可能不能提供可视化编程方式。

5.6.4.3 分析

传统操作系统要的面向事件编程，只能在高端平台上实现，是不折不扣的奢侈品，而DJYOS却可以在单片机上，使用简单的开发工具就可以实现，摇身一变成为日用品；

传统OS，即使使用VC、VB之类的工具支持，事件触发式编程主要用于界面编程，不能覆盖所有需求，而DJYOS只需要单片机开发工具，就覆盖全部需求；

传统OS在VB、VC之类工具包装后，用事件触发式编程产生的目标程序尺寸庞大、效率低下，而DJYOS却跟线程编程有同样的效率。

5.7 事件调度相关API

5.7.1 timeout参数说明

凡是会引起阻塞的系统调用，都有一个参数：timeout，表示超时时间（uS），以避免无休止的等待。会引起阻塞的API，当阻塞条件解除时，将会被唤醒，如果阻塞条件一直存在，timeout参数将决定阻塞时间。

若 timeout == CN_TIMEOUT_FOREVER，则表示永久等待；

若 timeout == 0；则不等待，函数返回CN_SYNC_TIMEOUT。

若 timeout == 其他，则事件进入阻塞队列，timeout时间后会被唤醒，函数返回CN_SYNC_TIMEOUT。非tickless模式下，timeout会自动向上取整为CN_CFG_TICK_US（系统心跳）的整数倍。

5.7.2 微秒、纳秒级延时

参见第17章。

5.7.3 DJY_EvttRegist：注册事件类型

u16 DJY_EvttRegist(enum enEventRelation relation,

                        ufast_t default_prio,

                        u16 vpu_res,

                        u16 vpus_limit,

                        ptu32_t (*thread_routine)(void),

                        void *Stack,

                        u32 stack_size,

                        char *evtt_name);

头文件：

os.h

参数：

relation：事件类型属性选项。EN_INDEPENDENCE表示独立型事件类型，EN_CORRELATIVE表示关联型事件类型。关于独立型和关联型事件的差异，参见第5.2.1节。

default_prio：事件类型的默认优先级。如果在调用DJY_EventPop函数弹出该类型的事件时，如果prio参数为0，则新弹出的事件优先级是default_prio。

vpus_res：本参数用于独立型事件，系统为该事件类型保留的空闲线程数，当一个独立型事件有多个实例时，系统将为其创建多个线程，而事件处理完成后，如果该类型事件拥有的线程数量超过vpus_res，则销毁所用线程，否则保留。

vpus_limit：本参数用于独立型事件，该事件类型拥有的线程数量上限。

thread_routine：线程入口函数(事件处理函数)。

Stack：静态的栈指针，如果用户已经分配了栈，由此传入指针；如果Stack==NULL的话，系统将用malloc分配栈。

StackSize：如果Stack==NULL，在代表执行thread_routine需要的栈尺寸，如果Stack!=NULL；则代表Stack指针指向的内存块的size。

evtt_name：事件类型名。允许是NULL，但如果指定，就不能与其他事件类型名重名，不允许超过31个字符（超出部分将被忽略）。

返回值：

注册成功返回该事件类型ID，数值范围是16384~32767；失败则返回CN_EVTT_ID_INVALID。

说明：

注册一个新的事件类型到系统中,事件类型经过登记后,就可以pop了,否则,系统会拒绝pop该类型事件。下面就事件类型中涉及的一些知识作简要解释。

每次登记一个事件类型系统会分配一个事件类型控制块。事件类型控制块的总量是静态分配的，其数量需按照系统内存量和应用程序实际需求合理设定。

图 5‑3 DIDE中配置内核

事件类型ID一经注册分配，就不会改变，直到调用DJY_EvttUnregist注销之。注销后，该ID可以被重新利用。

优先级

DJYOS允许的优先级是0~255 ，但登记事件类型时只允许使用 5~249 ，0~4 、250~255 是操作系统保留，不允许用户使用。常用的优先级如下表表。

优先级小于128的事件，属于紧急事件，在登记事件类型时，系统将为其创建一个线程，并且运行过程中也至少为它保留一个线程。

线程池功能

参数vpus_res和vpus_limit跟线程池功能相关。基于下面的考虑，系统设定了这两个参数。一方面如果某个独立型的事件频繁弹出，系统需要创建相应多的线程来处理它，但是，线程数量太多的话，会耗光系统资源，因此系统为独立型事件类型设置了创建线程数量的上限vpus_limit。另一方面当事件处理完成后，线程留着也没用了，系统应该销毁它。且慢，由于创建线程会有一定的开销，故系统会保留一些线程，以备再次弹出该类型的事件时，立即把保留的线程分配给该事件。保留的线程数量由vpus_res确定。

注意，只有独立型事件类型才有线程池的机制，关联型事件系统最多只为其创建一个线程。

事件类型的先登记后使用原则

DJYOS的事件类型采用先登记后使用的原则，事件类型登记后，应用程序可以弹出该类型的事件，操作系统通过调度器来决定何时调用事件处理函数。如果是首次弹出该类型事件，必须使用事件类型ID作为参数；如果事件队列中已经有该类型事件，弹出事件时也可以使用事件ID为参数，详见DJY_EventPop函数说明。在事件调度未开始前的初始化过程中，可以登记事件类型和弹出事件，但必须在调用操作系统初始化函数__Djy_InitSys之后，不过这个限制对用户基本没有影响，因为系统在完成CPU核心硬件初始化后，就会立即调用__Djy_InitSys函数。在__Djy_InitSys函数中，登记了系统的第一个默认优先级为 250 的事件类型：系统服务事件类型。

事件参数

每次弹出事件，都可以携带两个ptu32_t类型的参数，该参数保存在事件控制块的param1和param2成员。DJY_GetEventPara函数用于读取正在处理的事件的参数，连续多次调用DJY_EventPop函数的话，后调用的参数将覆盖前面的，而不管早先的参数是否被读取。

evtt_name的用法

如果evtt_name != NULL，则新注册的事件类型是有名字的，调用函数DJY_GetEvttId可以得到事件类型ID，这在模块间交互非常有用。使用名字来交互，可以降解模块间的耦合。假设事件类型A的名称设为NULL，事件B在执行过程中，需要调用DJY_EventPop弹出A类型的事件。由于A没有名称，DJY_EventPop要获得事件类型A的ID，事件B和A的代码就必须在一起编译，如果A和B分属不同模块，将导致模块间耦合。有了名称之后，模块间可以通过DJY_GetEvttId函数获得事件类型A的ID，如此两个模块就可以互相独立开发和编译，项目经理或系统工程师只要管理好命名空间就可以了。

如何确定StackSize

StackSize是调用thread_routine所需要的内存尺寸，如果空间不够，将会发生非常严重且神秘莫测的问题。确定StackSize的方法如下：

1.列出thread_routine直接和间接调用的所有函数，计算每个参数和局部变量（不含静态变量）所需的内存。

2.列出线程入口函数thread_routine调用各级子函数的所有可能路径。

3.把各调用路径所调用的函数所需的内存加起来，就是该路径所需要的内存。若有递归调用，该函数所需内存应该乘以最大可能的递归次数。

4.挑出内存需求最大的一个路径，再乘以一个安全系数，得到stack_size。该安全系数一般取1.2即可，要求特别高的系统，可取1.5。

注意如果发生递归调用，则递归函数所需要的内存还应该乘以最大的迭代次数。同时，请咨询你的BSP工程师，中断处理函数是否使用被中断线程的栈，如是，则每个线程的栈都要加上中断嵌套最深时的中断栈需求。

返回CN_EVTT_ID_INVALID的处理

如果函数返回CN_EVTT_ID_INVALID，说明事件类型控制块已经耗尽，增大工程目录下的core_config.c文件中的常量gc_u32CfgEvttLimit的值可以解决。Shell命令evtt可以查看事件类型控制块的使用情况。

5.7.4 DJY_EvttUnregist：注销事件类型

bool_t  DJY_EvttUnregist(u16 evtt_id)

头文件：

os.h

参数：

evtt_id：待注销的事件类型ID。

返回值：

注销成功返回true；失败则返回false。

说明：

注销一个事件类型。如果事件类型仍然在使用之中（尚有弹出的事件未被处理），事件类型则暂时无法完成注销，系统完成对该类型的所有弹出事件之后，自动注销该事件类型。在等待注销期间，系统不允许弹出该类型的新事件。

事件类型成功注销时，事件类型ID和事件类型控制块将被收回，属于该类型的事件处理线程也将被完全销毁。

5.7.5 DJY_RegisterHook注册调度hook函数

bool_t DJY_RegisterHook(u16 EvttID,SchHookFunc HookFunc)

头文件：

os.h

参数：

EvttID：被注册的事件类型ID。

HookFunc：hook函数指针。

返回值：

true = 成功注册, false = 失败。

说明：

多事件调度过程中，会发生事件上下文切换，djyos提供一个机会，让用户注册钩子函数，在事件切入和切离时，该钩子函数都会被调用。无论是切入还是切离，都在当前事件的上下文中调用，使用当前事件的栈空间。注意，切入和切离时调用的是同一个函数，只是参数的值不同。

SchHookFunc类型定义为：

typedef void (*SchHookFunc)(ucpu_t SchType);

参数SchType == EN_SWITCH_IN表示切入。

参数SchType == EN_SWITCH_OUT表示切离。

5.7.6 DJY_EventPop：弹出事件

u16 DJY_EventPop(  u16  hybrid_id,

                  u32 *pop_result,

                  u32 timeout,

                  ptu32_t PopPrarm1,

                  ptu32_t PopPrarm2,

                  ufast_t prio);

头文件：

os.h

参数：

hybrid _id：事件类型ID或者事件ID。

pop_result：用于返回新事件弹出或处理状态，可以是NULL。

1、  若函数返回了合法的事件ID，且timeout !=0，* pop_result可能的返回值：

CN_SYNC_SUCCESS，表示新事件被处理完成后返回；

CN_SYNC_TIMEOUT，表示新事件未被处理完，超时返回；

CN_STS_EVENT_EXP_EXIT，新事件处理过程中被异常终止；

2、  若函数返回CN_EVENT_ID_INVALID，* pop_result可能的返回值：

EN_KNL_EVTTID_LIMIT，参数hybrid_id是事件类型号，且超过配置的事件类型数量上限。

EN_KNL_EVENTID_LIMIT ，参数hybrid_id是事件号，且超过配置的事件数量上限。

EN_KNL_CANT_SCHED，timeout参数 !=0，但调度处于关闭状态。

EN_KNL_EVTT_UNREGISTER，欲弹出的事件类型未注册，或正在等待注销。

EN_KNL_INVALID_PRIO，非法优先级。

EN_KNL_ECB_EXHAUSTED，没有空闲事件控制块。

timeout：参见第5.7.1节。

PopPrarm1、PopPrarm2，传递给新事件的参数，可以用DJY_GetEventPara函数取出。若新事件是关联型事件，且未及取出该参数，又重复弹出同类型事件，那么最后一次弹出时的参数PopPrarm1、PopPrarm2将覆盖前一次弹出的。

prio：事件优先级。若参数prio == 0，则新事件优先级为注册事件类型时的默认优先级（详见函数DJY_EvttRegist）。若参数prio != 0，则该值为新弹出事件的优先级。

返回值：

事件成功弹出返回事件ID；否则返回CN_INVALID_EVENT_ID。

说明：

向操作系统报告发生某事件类型的事件，操作系统接报后，把事件放进调度队列。在DJYOS系统下，应用程序完成一个完整的事件处理周期是从弹出事件开始的。

事件类型在登记后首次弹出时，hybrid_id必须使用事件类型ID，随后，可以使用事件类型ID，也可以使用事件ID，前提是该事件ID还存在（事件处理完成后，ID会被收回）。对于关联型事件，使用事件ID和事件类型ID是相同的。但对于独立型事件，hybrid_id使用事件ID和事件类型ID的效果完全不同。如果使用事件类型ID，则会分配新的事件控制块，新事件插入就绪队列中，并创建（分配）新的线程去处理这条事件。

如果timeout != 0，当前正在处理的事件将阻塞，直到调用Djy_EventSessionComplete函数，或者事件处理函数自然返回或异常退出，或者超时才解除阻塞。

警告：函数的prio参数只适用于弹出新事件。对于“旧（已存在）事件”，即参数hybrid_id为事件ID或者已弹出过的关联型事件类型ID时，该参数是无效的。

5.7.7 DJY_WaitEvttPop：等待事件弹出

u32 DJY_WaitEvttPop(u16 evtt_id,u32 *base_times, u32 timeout)

头文件：

os.h

参数：

evtt_id：目标事件类型ID。

base_times：输入时设定弹出次数值，目标事件的第“*base_times+1”弹出时，同步条件达到时，如果给NULL，则从调用时的弹出次数+1做同步条件。若base_times !=NULL, *base_times返回目标事件的实际弹出次数。

timeout：参见第5.7.1节。

返回值：

CN_SYNC_SUCCESS：表示等待事件类型的事件弹出次数满足，当前成功唤醒。

CN_SYNC_TIMEOUT：表示阻塞超时。

CN_SYNC_ERROR：表示当前事件阻塞失败（原因如事件类型未注册、事件类型需要被注销以及系统静止调度）。

EN_KNL_EVTTID_LIMIT：事件类型ID出错。

说明：

某事件处理过程中，调用本函数将等待另一个类型的事件被弹出设定的次数。如果被等待的事件未弹出设定次数，则阻塞等待；若已经被弹出设定次数，则不阻塞。注意，被等待的事件类型，也允许是调用者自身。

当前正在处理的事件进入被等待弹出的事件类型的弹出同步队列，等待evtt_id类型的事件弹出次数达到设定值后，系统调度器会唤醒当前事件。

若“*base_times-当前已弹出次数”>0x80000000，也认为同步条件已经达到，如此设计，是为防止出错情况下没玩没了地等。

设定的弹出次数只计有效弹出，有效弹出的判定比较复杂。

1.如果目标事件类型是关联型事件，每次弹出都有效。

2.如果是独立型事件且调用DJY_WaitEvttPop时hybrid_id是事件类型ID，则每次弹出对于弹出同步队列中的非本类型事件都是有效弹出。

3.如果是独立型事件且调用DJY_WaitEvttPop时hybrid_id是事件ID，则对弹出同步队列中事件ID== hybrid_id的事件算有效弹出。

当base_times非NULL时，该参数返回值表示的是目标事件类型的事件已弹出的次数。注意，一般情况下，返回时base_times的值会加1，但会有例外。例外情况：

如果调用DJY_WaitEvttPop时，传入参数*base_times = 100，正常情况下，pop_times=101时，函数将返回，*base_times应该=101。但如果此时目标事件类型的pop_times已经大于101的话，函数将立即返回，*base_times的值将被设为当前的pop_times。

这个函数常见的用法是等待自身再次弹出：

DJY_WaitEvttPop(DJY_GetMyEvttId( ),NULL,CN_TIMEOUT_FOREVER);

源码5‑1弹出同步典型用法

net_service收到连接请求后，弹出事件，使用的是事件类型ID；

net_socket收到数据包后，弹出事件，用的是事件ID；

协议处理模块(net_protocal)用于处理网络报文，每次处理完报文后，就等待自身再次被弹出。

协议处理模块(net_protocal)被设计为独立型事件，net_service弹出事件，由于使用的是事件类型ID，每次调用系统都会创建新的事件，每条事件都会有自己的事件ID，并为每条事件创建新的线程来运行net_protocol函数。

net_socket弹出事件时，用的是事件id，此时不会产生新的事件，而是仅仅把protocol_event_id相对应的那一条事件激活。

所有线程处理完当前数据包后，都会在DJY_WaitEvttPop阻塞，等待新的数据包。

进一步地，如果想每收到10个数据包，批量处理一次，怎么办呢？

只要把net_protocol函数改为这样就可以了：

DJY_WaitEvttPop在收到10个数据包后才会返回，由于timeout参数被设为1000000，则如果1秒内收到的数据包不足10个，也将返回。

5.7.8 DJY_GetEvttId：查询事件类型ID

u16  DJY_GetEvttId(char *evtt_name)

头文件：

os.h

参数：

evtt_name：事件类型名称。

返回值：

查找成功返回事件类型ID；否则则返回CN_EVTT_ID_INVALID。

说明：

通过事件类型名查找对应的事件类型ID，注意，事件类型不会重名，但允许没有名字。

5.7.9 DJY_SaveLastError：保存线程的最后错误

void  DJY_SaveLastError(u32 ErrorCode)

头文件：

os.h

参数：

ErrorCode：错误代码。

返回值：

无。

说明：

应用程序或者操作系统运行遇到错误，通过这个函数将错误信息告诉系统。事件控制块有一个变量，记录该事件处理过程中的最后一个错误代码，重复产生的错误码将互相覆盖。

C库中的errno，也是基于DJY_SaveLastError和 DJY_GetLastError实现的，因此，下面两行代码是等效的：

DJY_SaveLastError (ErrorCode);

errno = ErrorCode;

5.7.10 DJY_GetLastError：获取事件最后一次错误码

u32  DJY_GetLastError(void)；

头文件：

os.h

参数：

无。

返回值：

错误代码。

说明：

提取当前事件所记录的最近发生的错误代码。

参考DJY_SaveLastError函数，下面两行代码等价：

n = DJY_GetLastError (ErrorCode);

n = errno;

5.7.11 DJY_SetRRS_Slice：设置轮转周期

void  DJY_SetRRS_Slice(u32 slices)

头文件：

os.h

参数：

slices：轮转调度时间片长度，单位为微秒。如果系统运行于非tickless模式，则该值系统自动向上取整为CN_CFG_TICK_US（系统心跳）的整数倍。

返回值：

无。

说明：TIME_BASE_MIN_GAP

设置系统轮转调度时间片。如果系统运行于tickless模式，时间片的系统缺省值为10mS，如果系统运行于非tickless模式，则是1个CN_CFG_TICK_US，即与系统心跳同频率。如果就绪的最高优先级事件有多个，则轮流执行，每条事件处理时间达到slices后，将发生轮转调度，强制切换到下一条。事件处理线程调用DJY_EventDelay(0)相当于主动引发一次轮转调度。如果slices设为0，表示不允许时间片轮转。

5.7.12 DJY_GetRRS_Slice：获取轮转周期

u32  DJY_GetRRS_Slice(void)

头文件：

os.h

参数：

无。

返回值：

当前系统轮转调度时间片长度，单位为uS。

说明：

查询系统当前轮转调度时间片的长度。

5.7.13 DJY_GetRunMode：查询系统运行模式

u32 DJY_GetRunMode(void);

头文件：

os.h

参数：

无。

返回值：

CN_RUNMODE_SI：单进程单映像模式

CN_RUNMODE_DLSP：单进程动态加载映像模式

CN_RUNMODE_MP：多进程模式

CN_RUNMODE_SMP：对称多处理器模式

说明：略

5.7.14 DJY_QuerySch：查询是否允许调度

bool_t DJY_QuerySch(void)

头文件：

os.h

参数：无

返回值：

允许调度返回true，否则返回false。

说明：

检查当前是否允许调度，允许异步信号且运行事件处理函数时，将返回true。

5.7.15 DJY_IsMultiEventStarted：调度是否已经开始

bool_t DJY_IsMultiEventStarted(void)

头文件：

os.h

参数：无

返回值：

调度已经开始则返回true，否则返回false。

说明：

调度已经开始后，就返回true，与是否允许调度无关。本函数用于检查当前运行环境是否仍然在初始化过程中。

5.7.16 DJY_SetEventPrio：设置事件优先级

bool_t DJY_SetEventPrio (ufast_t new_prio)

头文件：

os.h

参数：

new_prio：设置的新优先级。

返回值：

设置成功返回true；失败则返回false。

说明：

设置当前事件的优先级。当前事件处理过程中，可以调用本函数，改变自身的优先级。本函数可能会产生系统调度，如果优先级被改低了，且有更高优先级的事件处于就绪态，将立即调度，阻塞本事件运行。

这个函数只能改变调用者自身的优先级，不能修改其他事件优先级，包括优先级在内，DJYOS没有任何直接改变其他事件的参数的函数。

5.7.17 DJY_RaiseTempPrio：继承事件优先级

bool_t DJY_RaiseTempPrio(u16 event_id);

头文件：

os.h

参数：

event_id：事件id。

返回值：

设置成功返回true；失败则返回false。

说明：

如果g_ptEventRunning的优先级较高，event_id临时以g_ptEventRunning的优先级运行，直到调用DJY_RestorePrio，否则不改变优先级。

5.7.18 DJY_RestorePrio：恢复事件优先级

bool_t DJY_RestorePrio(void);

头文件：

os.h

参数：无

返回值：

设置成功返回true；失败则返回false。

说明：

与RaiseTempPrio函数配套使用。

5.7.19 DJY_EventDelay：事件延时

u32  DJY_EventDelay(u32 u32l_uS)

头文件：

os.h

参数：

u32l_Us：延迟（阻塞）时间，单位是微秒。该值系统自动向上取CN_CFG_TICK_US(系统心跳)的整数倍。

返回值：

实际延时（阻塞）时间，微秒数。

说明：

将当前（正在执行）事件延时（阻塞）u32l_uS微秒后继续运行。

不能获得精度高于tick间隔的延时。注意设置u32l_uS为零时，如果系统存在其他同优先级的事件，则调度器会让其他同优先级的事件将先执行，不管轮转调度是否允许，如果没有相同优先级的就绪事件，则直接返回。

由于参数值取整处理、优先级抢占或关中断等因素，会附加额外的延时时间，函数的实际返回的延时（阻塞）时间要比设定值长。

5.7.20 DJY_EventDelayTo：事件定时

s64 DJY_EventDelayTo(s64 s64l_uS);

头文件：

os.h

参数：

s64l_uS：延时结束时刻。该时刻已开机时刻为基准，单位是微秒。非tickless模式下，参数值系统将自动向上取整CN_CFG_TICK_US的整数倍。

返回值：

实际延时时间，单位微秒。

说明：

将当前时间延时到s64l_uS时刻再继续执行。参数延时结束时刻是一个64位数，理论上需要29万年才会发生溢出，因此不考虑数据溢出问题。

5.7.21 DJY_WaitEventCompleted：等待事件完成

u32  DJY_WaitEventCompleted(u16 event_id,u32 timeout)

头文件：

os.h

参数：

event_id：目标事件ID。

timeout：参见第5.7.1节。

返回值：

CN_SYNC_SUCCESS：指定事件完成处理。

CN_SYNC_TIMEOUT：当前事件阻塞超时。

EN_KNL_CANT_SCHED：当前事件阻塞失败。

EN_KNL_EVENT_FREE：参数event_id出错（不存在）。

说明：

阻塞等待指定事件完成，当指定事件处理完成，或者异常退出，或者超时时间到，系统唤醒当前事件。事件完成的标准：1、事件处理函数返回；2、事件处理函数调用DJY_EventComplete；3、事件处理函数异常退出。

5.7.22 DJY_WaitEvttCompleted：等待事件类型完成

u32  DJY_WaitEvttCompleted(u16 evtt_id,u16 done_times,u32 timeout)

头文件：

os.h

参数：

evtt_id：目标事件类型ID。

done_times：完成次数，当前事件阻塞，直至evtt_id类型的事件处理完成done_times次后唤醒。若done_times == 0，则表示所有evtt_id类型的事件均处理完后，唤醒当前事件。

timeout：参见第5.7.1节。

返回值：

CN_SYNC_SUCCESS：指定事件类型的事件完成处理。

CN_SYNC_TIMEOUT：当前事件阻塞超时。

EN_KNL_CANT_SCHED：当前事件阻塞失败。

EN_KNL_EVTTID_LIMIT，事件类型ID出错（不存在）。

说明：

等待某事件类型的事件被处理完成指定次数，事件完成的标准：1、事件处理函数返回；2、事件处理函数调用DJY_EventComplete；3、事件处理函数异常退出。

5.7.23 DJY_GetEventResult：查询事件处理结果

ptu32_t  DJY_GetEventResult(void)

头文件：

os.h

参数：

无

返回值：

当前事件的处理结果。

说明：

一个事件在处理过程中，如果弹出了新事件，本函数可查询新事件的处理结果。要得到处理结果，必须满足两个条件：

1、调用DJY_EventPop函数的参数timeout !=0；

2、调用DJY_EventPop时返回了合法的事件ID，且* pop_result返回CN_SYNC_SUCCESS。

这个返回结果，就是事件处理函数的返回值，或者调用DJY_EventComplete函数时传入的参数。

5.7.24 DJY_GetEventPara：获取事件参数

void *DJY_GetEventPara (ptu32_t *Param1,ptu32_t *Param2)

头文件：

os.h

参数：

Param1：事件参数。

Param2：事件参数。

返回值：

无。

说明：

提取该事件最近一次弹出（DJY_EventPop）时，传递给当前事件的参数。

5.7.25 DJY_EventComplete：事件处理完成

void DJY_EventComplete(ptu32_t result)

头文件：

os.h

参数：

result：传递事件处理结果，将返回给弹出该事件的事件(如果设定了timeout != 0)

返回值：

无。

说明：

通知系统，事件已经处理完成，但未事件处理函数仍将继续运行，等待处理下一条时间,将激活正在等待本事件完成的事件。常见使用方法：

1、  A事件调用DJY_WaitEvttCompleted等待B类型事件完成n次，则B类型事件调用n次本函数后，将激活A事件。

2、  A事件调用DJY_WaitEventCompleted等待B事件完成，则B事件调用本函数，将激活A事件。

3、  A事件调用DJY_EventPop弹出B事件，且timeout != 0，则B事件调用本函数，将激活A事件。

5.7.26 DJY_GetMyEvttId：获取当前事件类型ID

u16  DJY_GetMyEvttId(void)

头文件：

os.h

参数：

无。

返回值：

查询成功返回事件ID，如果当前运行在异步信号ISR中，则返回CN_EVTT_ID_ASYN。如果在实时中断中调用，则返回进入中断前的状态。

说明：略

5.7.27 DJY_GetMyEventId：获取当前事件ID

u16  DJY_GetMyEventId(void)

头文件：

os.h

参数：

无。

返回值：

查询成功返回事件ID，如果当前运行在异步信号ISR中，则返回CN_EVENT_ID_ASYN。如果在实时中断中调用，则返回进入中断前的状态。

说明：略。

5.7.28 DJY_WakeUpFrom：查询当前事件唤醒原因

u32  DJY_WakeUpFrom(void)

头文件：

os.h

参数：

无。

返回值：

当前事件被唤醒原因。

说明：

查询当前事件被唤醒原因。在多线程环境下，事件处理过程可能被反复阻塞和唤醒，当前（正在执行中的）事件肯定是就绪态，调用本函数，可查询自己进入当前状态之前处于什么状态，可能值如下表（在djyos.h中定义）：

以上是位域定义，可能叠加，比如事件是因为同步超时而返回，则有两个bit会置1，一个是CN_STS_SYNC_TIMEOUT，表示超时，另一个表示更具体的原因，例如CN_STS_WAIT_SEMP=1表示在阻塞等待信号量时因超时而被唤醒。注意唤醒后并不一定立即投入运行，还得看优先级说话呢。

5.7.29 关闭调度

关闭调度和关闭异步信号是等同的操作，参见6.4。

关闭实时中断也将禁止调度，参见节6.4。

特别注意，如果是通过原子操作（int_low_atom_start或者int_high_atom_start）进入禁止中断的状态，调度将处于允许状态，你在这种时候如果调用可能引起阻塞的操作，结果将不可预知。因此，原子操作范围内，禁止访问敏感数据，也禁止调用系统服务。

5.7.30 DJY_GetEvttPopTimes：取事件弹出次数

u32 DJY_GetEvttPopTimes(u16 evtt_id);

头文件：

os.h

参数：

evtt_id：事件类型ID。

返回值：该类型事件累计弹出次数，超过32位数后，将回绕到0

5.7.31 DJY_GetEvttName：取事件类型名

bool_t DJY_GetEvttName(u16 evtt_id, char *dest, u32 len);

头文件：

os.h

参数：

evtt_id：事件类型ID。

dest：保存名字的缓冲区，内存由调用者提供。

len：缓冲区长度。

返回值：

成功执行返回true；否则返回false。

说明：略。

5.7.32 DJY_GetEventInfo：获取事件信息

bool_t DJY_GetEventInfo(u16 id, struct EventInfo *info);

头文件：

os.h

参数：

id：事件ID。

info：保存信息的结构指针，struct EventInfo在djyos.h中定义。

返回值：

成功执行返回true；否则返回false。

说明：获取指定事件的信息，如占用的CPU时间等。

第6章 中断系统

使用RTOS的场合，大多都对实时性有要求，甚至有些要求极端高的实时性。一般来说，设计者会把实时性要求很高的部分功能，用中断来实现，从这个意义上，对于RTOS来说，最坏情况下的中断响应延迟，几乎就是该系统的实时性指标。如果操作系统会带来额外的、甚至不确定的中断延时，那么对实时性要求很高的应用，就不能使用操作系统，或者需要增加额外的硬件来处理实时任务。DJYOS在最坏情况下，提供裸跑的中断延迟，实现无以伦比的实时性，使得一些原来只能裸跑的应用，也可以使用操作系统。

6.1 理解中断

中断如闲云野鹤，来去无踪，操作系统根本不知道什么时候会来中断；许多CPU响应中断后，会自动切换到特权级别，中断服务函数可以无法无天，根本不受控制。所有这些，都增加了中断系统的设计难度。很多操作系统，代码逻辑上，把中断视为虎狼，在执行临界代码时，一关了之；功能上，又把中断都看作“需要紧急处理的事件”，为了降低操作系统对实时性的影响，又千方百计地缩短持续关中断时间，为了讨好用户，又企图给用户的ISR函数提供更多的服务。这样，就把中断相关的代码，搞得很复杂。

中断，从形式上看，是一个异步到达的（通知）事件，异步是什么意思呢？异步是相对于代码执行序列的，即CPU根本不知道什么时间会来中断，也不知道中断达到时，自己运行到什么地方、处于什么状态。中断从形式上，并没有告诉我们，它是否需要处理，更没有说是否需要紧急处理。因此，把中断都看作“需要紧急处理的事件”，是没有依据的。

由于CPU是串行执行指令的，如果靠CPU执行指令的方式查询获得事件，比如查询IO口获得上升沿事件。从事件发生到CPU查询到的延迟时间，必然跟cpu的查询周期相关，查询间隔短了，CPU开销太大，间隔长了，又会错过中断，因此，紧急事件只能通过中断来获取。

所以，中断可以用三句话来概括：

1.中断是异步事件。

2.中断不一定是紧急事件。

3.紧急事件必须用中断来通知。

了解了中断的三个特性，我们就知道，并不是所有中断，都需要极速响应的，事实上，绝大多数情况下，只有极少量的中断需要很高实时性的。对不同需求的中断，不能一视同仁，更不能把中断都看成是一个需要紧急处理的事件。

在操作系统支持下，需要接近裸跑的中断延迟吗？

答案显然是肯定的，但是，人们对此似乎很宽容。为什么会宽容呢？当没有汽车时，人们能够容忍马车的速度；没有火车时，人们容忍汽车的速度；没有飞机时，人们容忍火车的速度。当所有操作系统都做不到近乎裸奔的中断延迟时，人们便容忍OS给中断响应带来额外延迟。当DJYOS实现了裸跑实时性的时候，你还会犹豫吗？

为什么要为一些不紧急的事件（例如键盘）分配中断号呢？

设计者经常为键盘分配中断号，对于台式PC来说，键盘也许勉强算紧急事件，因为PC中有很多慢速操作；但对于使用RTOS的嵌入式控制系统来说，却并非紧急事件。为什么呢？因为键盘是人手通过机械按钮实现的，操作系统的反映，只要比人的动作快就可以了，响应太快了，反而可能导致误触发，失去按键防抖功能。那为什么不少人会把按键挂在中断线上，使用中断来响应按键操作呢？答案是，一可以简化软件设计，不需要单独启动一个键盘扫描线程；二可以减轻cpu负担，不用定期扫描键盘；三是低功耗系统特有的，可以用键盘中断来唤醒休眠的cpu。

6.2 中断管理体系

理解了中断，我们就可以着手设计中断系统了。

1.能够为异步事件提供服务，既然是事件，就应该提供与普通事件一样的操作系统服务，使其编码更加容易。

2.为实时中断提供裸跑的中断延迟，即使在最坏情况下，也不能例外。

3.用户用中断处理异步事件，是希望简化系统设计，因此，不能因为异步事件而使调度系统更加复杂。

既企图对所有中断极速响应，又企图给中断响应函数以尽可能多的服务，是不是太贪婪了点？鱼和熊掌，选一样吧。更多更便利的服务，必然需要更多的关中断，直接导致中断延迟加长。最终的结果是：

1.异步事件得不到操作系统的充分支持，对编写ISR程序有诸多限制。

2.真正实时性要求很高的中断，却做不到很快响应。

3.调度器保护临界资源时，分为关调度和关中断两级，使系统更加复杂，完全违背了用户的用中断响应异步事件以简化软件的目的。

DJYOS系统设计中断管理模块时也体现了系统的“九九加一”原则：

1.日常大量存在的、实时性并不是特别高的工作，系统提供最大的便利，让程序员能够简洁地实现。

2.极少遇到的、高难度的、甚至挑战系统实时性和处理能力极限的工作，系统提供最大的灵活性，使问题的解决成为可能。

基于上述原则，在DJYOS系统中，中断被分为两大类，第一类是实时中断，对应现实世界中紧急程度非常高的中断信号，实时中断的响应与前后台系统无异，具有接近前后台系统的实时性，操作系统运行过程中，调度程序永远不会关闭实时中断，只是提供一个接口函数，使线程可以根据需要临时关闭实时中断。在实时中断里，程序员能够像在前后台系统中一样自由自在地编程，除了不能使用操作系统的系统调用外，没有太多的束缚，相应地，操作系统为实时中断提供的服务也最少。实时中断为用户的紧急突发事件提供绿色通道，它的实时性能要远高于其他操作系统的中断体系。

第二类是异步信号，对应紧急程度不是很高的中断信号，异步信号和普通事件没有实质性的差别，内核把他们等同看待。但因硬件特性，异步信号与普通事件还是有区别的，他们的相同点表现在：

1.禁止事件调度和禁止异步事件切换是等同的，也就是说，当禁止调度时，DJYOS把异步信号当作事件一样也禁止了。

2.异步信号ISR可以从堆中分配内存，可以释放和申请信号量，以及使用其他临界资源。

3.异步信号ISR可以使用所有的系统服务。

异步事件和普通事件的不同点表现在：

1.异步信号没有独立的上下文，故ISR不可以被阻塞。虽然允许调用所有的系统调用，但不会发生实际阻塞。例如malloc函数，如果在线程中调用，内存不足时，线程将被阻塞；如果在ISR中调用，线程不足时将直接返回NULL。

2.由于异步信号优先级高于所有普通事件，故其ISR不能像事件处理函数那样，做成死循环的形式。

图6‑1中断结构

一般cpu的中断控制器，都有许多中断输入线，每个中断线对应一个中断号，由一个独立的开关控制。

每个中断线，都允许独立设置为实时中断还是异步信号，该开关可能是硬件开关，也可能是软件开关，依赖于具体硬件以及移植者的选择。

异步信号有一个独立的总使能开关，也就意味着，异步信号是可以整体关断的。

实时中断没有独立总使能开关，异步信号和实时中断有一个公共的总使能开关，意味着，允许用户关闭所有中断。

DJYOS中，“异步信号使能开关”同时又是关调度开关，DJYOS没有独立的调度开关，使得DJYOS的临界区保护代码更加简洁，和用户希望通过“用中断实现异步信号”来简化软件设计的目的，是相适应的。简洁的调度器，也使DJYOS更加可靠。由于关异步信号和关中断等同，使得异步信号处理函数可以使用操作系统提供的全部服务，更加方便易用。

操作系统运行过程中，总中断使能开关时从来不会被关闭的，所以，DJYOS的实时中断处理能力，达到裸跑的速度，这是架构决定的，跟中断响应的代码是否精简无关。

DJYOS中断系统的特点

1.实时中断响应具有裸跑的实时性，使得有些原本不能使用操作系统的应用，可以享受操作系统的服务。

2.编写异步信号编程更加方便，像普通事件一样，允许使用所有操作系统服务。

3.系统更加简洁可靠，合并关闭调度和关闭异步信号的操作后，使系统临界区保护相关的代码大大简化。

6.3 中断使用步骤

6.3.1 CPU中断表

在文件“djysrc\bsp\cpudrv\nameofcpu\include\cpu_peri_int_line.h”中，定义了该cpu支持的所有中断源，用户直接使用即可。

特殊情况：有些cpu，例如ADI的adsp系列dsp，或者TI的C6000系列dsp，cpu支持的中断向量数少于外部中断源数，例如adsp的cpu只支持32个中断向量，而中断源却达到44个，这个表中就只能放32个。

6.3.2 实时中断编程模型

实时中断编程的ISR与落跑没有差异，其响应速度也与裸跑没有差异。

1.编写中断服务程序ISR，像普通C函数一样编写即可。

2.使用下列语句序列设置中断：

第一句，注册中断线到中断系统。

第二句，把ISR函数跟中断线联系起来。

第三句，把相应中断设置成实时中断。

第四句，清一下中断，以免受硬件的初始化状态影响。

第五句，使能中断

上述初始化过程，来自一个实际应用，该案例的MCU使用lpc1225，主频40Mhz，flash速度20Mhz，实际运行速度在20Mhz~40Mhz之间。但要实现2.5Mbps baud的串口通信，如果不能再接收中断发生5uS内响应中断的话，必然丢数据。因此，该应用使用了DJYOS的实时中断机制，实测下来，中断响应时间小于1.5uS，效果很理想。

6.3.3 异步信号的事件模式编程

这种模型的优点是，不需要编写ISR函数，而且在异步信号的处理事件中，编程与普通线程编程一样，没有额外限制。下面以串口服务为例：

1.编写事件处理函数。

2.登记事件类型，用于异步信号处理的事件，一般设为关联型事件。

4.      按照下列指令序列初始化中断号：

第一句，把事件类型与中断号联系起来。

第二句，把中断号设为异步信号。

第三句，设置清中断方式，不可以使用默认的CN_INT_CLEAR_USER。详见6.4.9节。

第四句，清一下中断，以免硬件的初始化状态影响。

第五句，使能中断。

完成以上3步，只要发生uart中断，就会自动弹出uart1_evtt类型的事件。第一次弹出事件后，uart1_event将被执行，处理完相应的事务后，将会在DJY_WaitEvttPop( )函数处阻塞，直到下一次中断的到来。应用程序完全不需要写ISR程序，由于uart1_event是普通的事件处理函数，它跟普通事件处理函数一样，可以得到所有OS服务。

要实现超时处理（即串口长时间收不到数据）也很简单，只需要把：

DJY_WaitEvttPop(djy_my_evtt_id(), NULL,CN_TIMEOUT_FOREVER);

中的CN_TIMEOUT_FOREVER换成具体的时间（微秒数）就可以了。

6.3.4 异步信号的ISR模式编程

这种编程模型，是大家非常熟悉的方式，不同的是，DJYOS的ISR可以调用全部系统服务，唯一的区别是，ISR中调用可能导致阻塞的系统服务时，不会发生实际阻塞。比如，在ISR中调用malloc，但如果内存不足，将返回NULL，不会被阻塞，而在线程中调用的话，将会被阻塞。只要养成良好的编程习惯，检查系统调用的返回值，就不会出错。

异步信号的ISR模式编程步骤如下：

1.编写中断服务程序ISR，像普通C函数一样编写即可。

2.使用下列语句序列设置中断：

第一句，把ISR函数跟中断线联系起来。

第二句，把相应中断设置成异步信号中断。

第三句，清中断，以免硬件的初始化状态影响。

第四句，使能中断。

这个过程，跟实时中断非常相似，就是函数名不一样而已，但实现过程是有很大差别的。这种方式下，__uart1_int函数可以调用全部系统服务，但中断响应延时可能比实时中断长。

6.3.5 异步信号的ISR和事件混合模式编程

这是一种类似把中断处理分为上半部和下半部编程的一种方法，在DJYOS中实现起来特别简单，步骤如下：

1.编写事件处理函数。

2.登记事件类型，用于异步信号处理的事件，一般设为关联型事件。

3.编写中断服务代码ISR，像普通C函数一样编写即可。

5.      按照下列指令序列初始化中断号：

第一句，把事件类型与中断号联系起来。

第二句，把ISR函数与中断号联系起来。

第三句，把中断号设为异步信号。

第四句，清中断，以免硬件的初始化状态影响。

第五句，使能中断。

此后，只要发生uart中断，就会先调用__uart1_int函数，然后自动弹出uart1_evtt类型的事件。可以在__uart1_int( )函数中处理比较紧急的事务，比如copy硬件缓冲区，把其他事情留给uart1_event( )做。第一次弹出事件后，uart1_event将被执行，处理完相应的事务后，将会在DJY_WaitEvttPop ( )函数处阻塞，直到下一次事件的到来。

6.4 中断API

6.4.1 Int_RestoreAsynSignal：使能异步信号

void Int_RestoreAsynSignal(void)

头文件：

os.h

参数：

无。

返回值：

无。

说明：

使能异步信号，Int_ SaveAsynSignal配对使用。

这是一对计数式的开关，Int_ SaveAsynSignal函数使计数器加1，Int_RestoreAsynSignal函数使计数器减1，当计数器减到0时，异步信号被使能，否则禁止。

另外注意，异步信号被使能/禁止等同于“禁止/使能调度”。禁止异步信号期间，如果是tickless模式，定时时钟中断也停止响应；在非tickless模式，心跳时钟也是通过异步信号实现的，系统心跳停止。

在禁止异步信号期间，如果调用可能会引起事件阻塞的函数，则阻塞作用是无效的，该函数会立即返回。例如某事件调用malloc函数时，内存不足且禁止异步信号，函数会立即返回NULL。

这是函数与Int_SaveAsynSignal配对使用，允许嵌套调用。

6.4.2 Int_SaveAsynSignal：禁止异步信号

void Int_SaveAsynSignal(void)

头文件：

os.h

参数：

无。

返回值：

无。

说明：

禁止异步信号，详见Int_RestoreAsynSignal函数。

这是函数与Int_RestoreAsynSignal配对使用，允许嵌套调用。

6.4.3 Int_CheckAsynSignal：查询异步信号状态

bool_t Int_CheckAsynSignal(void)

头文件：

os.h

参数：

无。

返回值：

允许异步信号返回true；禁止异步信号返回false。

说明：

查询异步信号是否允许，也即是否允许调度。注意，这里所查询是逻辑概念上的异步信号，而非实际硬件中断源的状况。调用Int_HighAtomStart或Int_LowAtomStart关闭中断的话，不影响本函数。

6.4.4 Int_RestoreLine：计数使能中断线

bool_tInt_RestoreLine(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

true表示成功操作，false表示操作失败。

说明：

DJYOS用计数器来控制中断线开关状态，允许嵌套调用，调用Int_SaveLine使计数器加1，调用Int_RestoreLine使计数器减1。因此，调用Int_SaveLine必定会使相关中断线禁止，但调用Int_RestoreLine则只有在计数器减至0才使能中断。

函数与Int_SaveLine成对使用，允许嵌套调用。

6.4.5 Int_SaveLine：计数禁止中断线

bool_t Int_SaveLine(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

true表示成功操作，false表示操作失败。

说明：

详情见函数Int_RestoreLine说明。

函数与Int_RestoreLine成对使用，允许嵌套调用。

6.4.6 Int_EnableLine：直接使能中断线

bool_t Int_ EnableLine (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

成功操作返回true；失败则返回false。

说明：

函数与Int_ DisableLine成对使用，不允许嵌套调用。这对函数直接使能或者禁止相应中断线，执行效率较高，是不允许嵌套调用的。

6.4.7 Int_DisableLine：直接禁止异步信号线

bool_t Int_ DisableAsynLine (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

成功操作返回true；失败则返回false。

说明：

函数与Int_ EnableLine成对使用，不允许嵌套调用。这对函数直接使能或者禁止相应中断线，执行效率较高，是不允许嵌套调用的。

6.4.8 Int_CheckLine：检查中断线状态

bool_t Int_CheckLine (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line，中断线号。

返回值：

true表示中断线使能，false表示禁止。

说明：

检查中断线ufl_line是否使能，不区分异步信号和实时信号。

6.4.9 Int_SetClearType：设置清中断方式

bool_t Int_SetClearType (ufast_t ufl_line,ufast_t clear_type)；

头文件：

os.h

参数：

ufl_line：中断线编号；

clear_type：设定清中断方式。

返回值：

设置成功返回true；失败则返回false。

说明：

中断响应后，绝大多数硬件都会暂时屏蔽本中断再次响应，直到调用Int_ClearLine清中断。在中断发生到清中断期间重复发生的同一个中断将被忽略，既不响应也不挂起。清中断后，再次发生的中断将会挂起，是立即响应还是等前一次中断返回后再响应，则取决于硬件以及软件设置。DJYOS提供三种清中断方式，任意中断线可根据自身需要设置：

只有异步信号可以设置清中断方式，实时中断必须由用户的ISR清中断。

6.4.10 Int_IsrConnect：注册中断响应函数

void Int_IsrConnect(ufast_t ufl_line, u32 (*isr)( ptu32_t ))

头文件：

os.h

参数：

ufl_line：中断线号。

isr：被关联的中断处理函数。

返回值：

操作成功返回true；失败则返回false。

说明：

为中断线ufl_line指定（注册）中断响应函数。中断发生后，系统将调用该响应函数。本函数不区分该中断线是实时中断还是异步信号。

ISR函数的参数，与Int_SetIsrPara函数配合使用，常用于多个中断线共用ISR函数的情景，例如，CPU有8个串口，driver使用同一个ISR处理8个串口中断，每个串口有独立的中断，如果没有参数，ISR函数将不知道是哪个串口请求中断。如果不使用Int_SetIsrPara函数设置参数，默认值是中断号；像前面所述的8个串口共用ISR的情况，可把参数设为串口号。

6.4.11 Int_IsrDisConnect：注销中断响应函数

voidInt_IsrDisConnect(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

无。

说明：

注销中断线ufl_line的中断响应函数。

6.4.12 Int_ SetIsrPara：设置ISR参数

void Int_SetIsrPara(ufast_t ufl_line,ptu32_t para);

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

无。

说明：

设置当编号为ufl_line的中断发生时，调用ISR函数的参数，参见6.4.10节。

6.4.13 Int_EvttConnect：注册异步事件

bool_t Int_EvttConnect(ufast_t ufl_line,uint16_t my_evtt_id)

头文件：

os.h

参数：

ufl_line：中断线号；

my_evtt_id：被关联的事件类型id。

返回值：

true = 成功连接事件类型 , false = 失败。

说明：

将中断线信号转化为系统的异步事件。即设置中断线触发的事件类型。当中断线信号发生后，系统首先调用中断响应函数（如果有）处理中断，然后弹出my_evtt_id的事件类型。同时，系统会将中断响应函数结果（u32类型）和中断线号（u32类型）作为输入参数传递给事件处理函数。

使用本函数，灵活使用DJY_WaitEvttPop函数的base _times参数，可以设定每次中断都激活事件处理函数，还是若干次中断才激活一次，详询第5.7.7节

警告：只有异步信号才能关联事件类型。

6.4.14 Int_EvttDisConnect：注销异步事件

void Int_EvttDisConnect (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线编号。

返回值：

无。

说明：

取消中断线与事件类型的关联关系。

6.4.14 Int_EvttDisConnect：注销异步事件

u32 Int_GetRunLevel(void)

头文件：

os.h

参数：

无。

返回值：

异步信号嵌套深度。

说明：

查询当前异步信号的嵌套深度。0 = 线程中，1=异步信号中断，大于1表示异步信号嵌套级数。

6.4.16 Int_AsynSignalSync：异步信号同步

bool_t Int_AsynSignalSync (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：被同步的中断线号，必须是异步信号类型。

返回值：

设置成功返回true；失败则返回false。

说明：

调用后，将阻塞正在处理的事件的线程，直到指定的中断线的中断发生、响应并返回，然后才激活线程。不管中断线原来状态如何，调用本函数将导致中断线被使能(是直接使能，不是调用Int_RestoreAsynLine)，并在线程被激活后恢复禁止状态。

只有异步信号才允许被同步，实时中断是不允许的。

调用前，应该确保相应中断线处于禁止状态。但可以连接ISR、evtt等。

如果连接了ISR且清中断类型设为CN_INT_CLEAR_USER的话，ISR中必须清中断。

如果调用本函数时，被等待的中断已经挂起，则：

1、  函数立即作为同步成功返回，不会被阻塞。

2、  该中断的ISR（用Int_IsrConnect设置）不会被调用。

3、  如果用Int_EvttConnect函数连接了事件类型，该事件类型不会被弹出。

4、  因此，不建议在被异步信号同步的中断线上挂接ISR和连接事件类型。

如果连接了ISR并被调用，则被阻塞事件从阻塞恢复运行后，g_ptEventRunning-> event_result将设置为ISR函数的返回值。

6.4.17 Int_Register：注册中断线

bool_t Int_Register (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：被注册的中断线号，必须小于或等于最大中断线号。

返回值：

注册成功或已经注册返回true；失败则返回false。

说明：

中断注册函数必须在优先于其他具体中断线操作函数之前被调用。

6.4.18 Int_UnRegister：注销中断线

bool_t Int_UnRegister (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：被注销的中断线号，必须小于或等于最大线号。

返回值：

注销成功返回true；失败则返回false。

说明：

原则上，中断函数一经注册，便不再注销，此外与Int_Register函数成对出现，在功能上面主要用于释放注册中断线分配的内存。

6.5 硬件相关API

以下API函数跟硬件相关，代码在BSP包中的int_hard.c中提供，平台移植时，必须实现，具体实现的细节硬件的中断控制器有关。

有些arch，有统一的中断架构，像cortex-m系列的cpu，系统已经提供了从m0~m7所有的int_hard.c，可直接使用。

有些arch，则是cpu核只提供了基本的中断功能，中断控制器是由个厂家提供的，例如ARM9，则需要在平台移植时，根据具体CPU和中断控制器芯片实现。

6.5.1 Int_SetPrio：设置中断线优先级

bool_t Int_SetPrio(ufast_t ufl_line,u32 prio)

头文件：

os.h

参数：

ufl_line：被操作的中断线编号；

prior：新的优先级。

返回值：

设置成功返回true；失败则返回false。

说明：

设定某中断线的抢占优先级。

不同的硬件，优先级的含义也不同，有些中断控制器的优先级是抢占式的，即高优先级的中断能嵌套低优先级中断，像cortex-m3；另一些中断控制器的优先级是查询式的，两个中断一起发生时，先服务高优先级的，例如s3c2440。如果硬件不支持抢占优先级，BSP设计时直接返回false即可。

6.5.2 Int_SettoAsynSignal：设置为异步信号

bool_t Int_SettoAsynSignal(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回：

设置成功返回true；失败则返回false。

说明：

将中断线ufl_line设置为异步信号。如果此中断线正在响应，则设置在系统处理完此次中断线后才会生效。

6.5.3 Int_SettoReal：设置为实时信号

bool_t Int_SettoReal (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回：

设置成功返回true；失败则返回false。

说明：

将中断线ufl_line设置为实时信号。如果此中断线正在响应，则设置在系统处理完此次中断线后才会生效。

6.5.4 Int_ContactAsynSignal：使能异步信号

void Int_ContactAsynSignal(void)

头文件：

int_hard.h

参数：无。

返回：无。

说明：

函数与Int_CutAsynSignal配对使用，直接允许异步信号，不能嵌套使用。

6.5.5 Int_CutAsynSignal：禁止异步信号

void Int_CutAsynSignal(void)

头文件：

int_hard.h

参数：无。

返回：无。

说明：

禁止所有异步信号类型的中断线。

函数与Int_ContactAsynSignal配对使用，直接禁止异步信号，不能嵌套使用。

6.5.6 Int_ContactTrunk：使能总中断

void Int_ContactTrunk(void)

头文件：

int_hard.h

参数：无。

返回：无。

说明：

本函数与Int_CutTrunk配对使用，直接使能总中断，不能嵌套使用。

6.5.7 Int_CutTrunk：禁止总中断

void Int_CutTrunk(void)

头文件：

int_hard.h

参数：无。

返回：无。

说明：

禁止系统的中断功能。

函数与Int_ContactTrunk配对使用。

本函数与Int_ContactTrunk配对使用，直接禁止总中断，不能嵌套使用。

6.5.8 Int_ContactLine：使能中断线

bool_t Int_ContactLine(ufast_t ufl_line)

头文件：

int_hard.h

参数：

ufl_line：中断线号。

返回：无。

说明：

本函数与Int_CutLine配对使用，直接使能选定中断线，不能嵌套使用。

6.5.9 Int_CutLine：禁止中断线

bool_t Int_CutLine(ufast_t ufl_line)

头文件：

int_hard.h

参数：

ufl_line：中断线号。

返回：无。

说明：

禁止中断线。

本函数与Int_ContactLine配对使用，直接禁止选定中断线，不能嵌套使用。

6.5.10 Int_ClearLine：清中断线

bool_tInt_ClearLine (ufast_t ufl_line);

头文件：

os.h

参数：

ufl_line，被清的中断线编号。

返回：

操作成功返回true；失败则返回false。

说明：

清中断线，中断pend后，须执行“清中断线”操作，才能响应后续中断。至于在什么时候执行清中断操作，并无一定的规律，视硬件功能逻辑而定。

中断引擎能够自动调用nt_ClearLine清中断，调用Int_SetClearType函数可以逐个中断设定其清中断方法，设为：

CN_INT_CLEAR_USER：表示系统不清中断，用户须在ISR中清中断，是默认状态。

CN_INT_CLEAR_PRE：表示由系统在调用ISR之前清中断。

6.5.11 Int_QueryLine：查询中断线状态

bool_t Int_QueryLine(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

中断线信号已发生返回true；否则返回false。

说明：

查询中断线信号是否已经发生，本函数用于查询式中断响应。

6.5.12 Int_TapLine：软中断

bool_t Int_TapLine(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

成功软件触发中断返回true；否则返回false。

说明：

用软件的方法触发一次中断，就像该中断真实发生了一样。这个功能依赖于CPU，绝大多数CPU的中断控制器允许软件触发，但也有些CPU不允许，例如freescale的p1020。

6.5.13 Int_EnableNest：使能中断线嵌套

bool_t Int_EnableNest(ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

使能成功返回true；失败则返回false。

说明：

使能中断线被嵌套功能。与Int_DisableNest配对使用。

使能后，相应的中断的ISR执行期间，可能会被别的中断线抢占。但是否支持嵌套功能，由BSP设计者根据硬件的支持情况和实际工程需要决定。

在使能嵌套的情况下，嵌套方式也可能有多种，例如三星的S3C2440，只要嵌套被允许，则低优先级的中断也可以嵌套高优先级的中断，而freescale的P1020，则只有更高优先级的才可以嵌套低优先级的。

这里所说的嵌套，可以是实时中断嵌套实时中断，也可以是异步信号嵌套异步信号，或者是实时中断嵌套异步信号，这些功能由BSP设计者保证。

6.5.14 Int_DisableNest：禁止中断嵌套

bool_t Int_DisableNest (ufast_t ufl_line)

头文件：

os.h

参数：

ufl_line：中断线号。

返回值：

使能成功返回true；失败则返回false。

说明：

禁止中断线嵌套功能。

与Int_EnableNest配对使用。使能后，相应的中断服务期间，可以会被别的中断线抢占。但是否支持嵌套功能，由BSP设计者根据硬件的支持情况和实际工程需要决定。注意，实时中断天生能够打断异步信号，这是无法禁止的。

在使能嵌套的情况下，嵌套方式也可能有多种，例如三星的S3C2440，只要嵌套被允许，则低优先级的中断也可以嵌套高优先级的中断，而freescale的P1020，则只有更高优先级的才可以嵌套低优先级的。

这里所说的嵌套，可以是实时中断嵌套实时中断，也可以是异步信号嵌套异步信号，或者是实时中断嵌套异步信号，这些功能由BSP设计者保证。

6.6 原子操作API

6.6.1 Int_HighAtomStart/Int_HighAtomEnd高级原子操作

进入高级原子操作：

atom_high_t Int_HighAtomStart(void)

离开原子操作：

void Int_HighAtomEnd(atom_high_t high)

头文件：

os.h

参数：

high：总中断的开关状态，是调用Int_HighAtomStart函数的返回值。

返回值：

Int_HighAtomStart函数的返回值表示总中断的开关状态。

说明：

高级原子操作是指期间不容许任何原因打断的操作，一般是因为特定的硬件要求，比如说用gpio产生一个1uS宽度的脉冲。从进入高级原子操作到离开的期间，所有中断被禁止。Int_HighAtomStart函数读当前总中断状态，然后禁止总中断。

Int_HighAtomStart和Int_HighAtomEnd是姊妹函数，必须配套使用。

原子操作的用法：

源码6-1使用高级原子操作

上述代码是典型的受硬件约束而需要使用高级原子操作的。

原子操作函数还可以嵌套使用，方法如下：

源码6-2嵌套使用原子操作

在原子操作包包围的代码内，不允许调用“Int_SaveAsynSignal——Int_RestoreAsynSignal”，也不允许调用任何可能导致阻塞的API。禁止总中断后，所有中断无法响应，调度也被禁止，因此禁止时间应该尽可能地短，最好不要在禁止期间调用任何API。

警告：原子操作是系统提供的快速高效手段，但却很暴力，通过原子操作（Int_HighAtomStart或者Int_LowAtomStart）进入禁止中断的状态，是不可以发生调度的，然而调度器却不知道，调用DJY_QuerySch将返回“允许”状态，你在这种时候如果调用可能引起阻塞的操作，是自讨苦吃，结果将不可预知。

1. 此函数实现与硬件环境相关，在系统移植时确定。

2. 在原子操作过程中，不要调用会引发事件阻塞的操作（函数），一旦发生阻塞，其结果将会不可预知。

6.6.2 Int_LowAtomStart/Int_LowAtomEnd：低级原子操作

低级原子操作进入

atom_low_t Int_LowAtomStart(void)

低级原子操作离开

void Int_LowAtomEnd(atom_low_t low)

头文件：

os.h

参数：

low：异步信号的开关状态，是调用Int_LowAtomStart函数的返回值。

返回值：

Int_LowAtomStart函数的返回值表示异步信号的开关状态。

说明：

函数使用方法参见高级原子操作部分，不再赘述。

低级原子操作跟高级原子操作类似，高级原子操作控制的是总中断开关，低级原子操作控制的是异步信号总开关，其他完全一样，使用方法也一样。

DJYOS中tick是通过异步信号实现的，低级原子操作期间tick自然也不走了。

6.6.3 原子加减法计算

原子加减法计算函数有这些，原型如下：

void atom_uadd32(u32 *base, u32 inc);

void atom_usub32(u32 *base, u32 sub);

void atom_sadd32(s32 *base, s32 inc);

void atom_ssub32(s32 *base, s32 sub);

void atom_uadd64(u64 *base, u64 inc);

void atom_usub64(u64 *base, u64 sub);

void atom_sadd64(s64 *base, s64 inc);

void atom_ssub64(s64 *base, s64 sub);

头文件：

os.h

参数：

base：被加数/被减数的地址。

inc/sub：加数或者减数

返回值：

无。

第7章 紧急代码

所谓紧急代码说起来也比较简单，就是在系统预加载之后执行的一部分代码，这段代码可以完成一些紧急资源的初始化，例如启动过程的喂狗，一些紧急的gpio状态等。

想当年，MCU普遍比较简单，内存容量不大，程序也比较短小，上电/复位后的初始化时间不长。这段时间内，即使系统对外界完全不响应，也关系不大，但是在一些实时控制的领域，比如要求系统上电后要求继电器是闭合或者是打开的状态，这个时候紧急代码就显得格外关键。

紧急代码如何编写想必是大家比较关心的，说起来也比较简单，就是将紧急代码写在critical/critical.c文件中，“void critical(void)”为紧急代码入口函数，这里代码要求用裸机的方式写，一些系统资源是不能用的。

第8章 内存管理

应用程序使用的内存，有两种来源。一种是静态分配，用户编程时定义全局或静态变量，它们由编译器在编译时确定和分配。另一种是动态分配，即程序在运行过程中申请内存，由系统的内存管理机制来确定和分配。前后两种的本质区别是应用程序获得内存的时刻前者是编译时，后者是运行时。

对于第二种来源，其核心内容是DJYOS的内存管理机制。DJYOS有3种动态内存分配策略，分别是：

1.“准静态”分配，这种分配方式虽然是系统运行时分配，但执行效率跟静态分配类似，比编译器静态分配多了对齐损耗而已。

2.“块相联”分配，它把整个内存划分为尺寸的块，一次申请可以分配连续的2的n次方块。

3.“固定块”分配，它把大块内存划分由规格化的小块组成的“内存池“，每次申请分配一个规划化的小块。

  “准静态”和“块相联”目前采用统一的用户接口，对应用程序或用户而言，这两种分配策略是透明的。那么，什么时候按照准静态方式，什么时候按照块相联方式分配内存呢？

图 8‑1DIDE中配置动态分配

准静态分配是系统默认支持的，不需要配置，在系统初始化阶段、多事件（线程）调度开始之前，malloc函数肯定是按照准静态分配模式工作的。

如果勾选了“全功能动态分配”选项（如图 8‑1），则多事件（线程）调度启动后，采用

图8-1显示了静态分配和DJYOS的“准静态”和“块相联”分配策略的不同。采用这种不同内存分配策略，申请两块101字节大小的内存，在内存分配上的异同点。其中在“准静态”分配方式中，假设系统要求内存按8字节对齐。

图 8‑2静态分配、准静态分配、块相联分配的效果

8.1 “准静态”分配

“准静态”分配是在系统初始化时，从堆中分配任意尺寸的内存。由于有些模块，在编译时无法确定要多少内存，需要模块运行初始化时才能确定。类似这种模块，虽然它自申请内存直至运行结束都不会释放内存，但让其使用静态定义的方式分配内存仍然是不合理的。相对而言，这种模块，采用准静态分配策略，既高效又快速。“准静态”分配法，从当前堆底开始切割，要多少内存就切多少，不浪费，无需查找空闲内存，执行速度很快，但释放时，如果地址“更高”的内存块没有被释放，则低地址的内存块即使被释放了，也不会被利用。

图 8‑3 准静态分配和释放示意图

如图 8‑3所示，P2虽然被释放了，但由于比它更高地址的P3还没有释放，所以堆底仍然在P3之上，再次执行malloc的话，还是从堆底向上分割，P2所在“空隙”不会得到利用。一旦P3被释放，堆底就立即降到P1之上。

8.2 “块相联”分配

“块相联”分配是将整个内存划分为若干固定大小的page，由2个n次方个page相联组成block，分配是以block为单位进行的。详细的内存分配机制详见《都江堰操作系统原理与实现》中内存管理章节介绍。虽然这样做会使内存的使用率低一些，但是这个分配策略的执行速度很快，而且最重要的是，它的执行时间是确定的，比如一个总共4GB，以1KB为一页的内存系统中，查找1个空闲页，在32位cpu中，最多需要5次搜索（共5次比较、5次乘法和5次加法）就可以完成。

“块相联”分配策略的对内存页的格式“损耗”虽然是不确定的，不过，悄悄告诉你一个秘密，这些所谓的“损耗”，其实就像一个呆板的银行，只能按整百取钱，你要取150，给你取200，多取的50块钱你也是可以花的，而且，Heap_CheckSize函数还能告诉你总共给了你多少钱。

8.2.1 多heap管理

djyos将不同性质的内存，分别组成不同的heap，在同一个heap内，地址不相连的内存，则可以组成多个cessions。在嵌入式系统中，你会同时面对各种不同性质的内存，例如一个双核系统，会有DDR内存、noncache的用于驱动的内存、双核共享内存、双核独享内存，分别为这些内存创建heap进行独立管理，应用程序就能够按照需要从指定的heap中分配内存。

heap划分为多个cessions，除了管理不连续的地址空间外，还可以用来提高内存利用率。举个例子：如果一个heap，只有一个cessions，其page尺寸是32bytes，那么，我要分配180字节的话，就只能向上取256字节。如果我把这个heap划分为两个cessions，两个cessions的page尺寸分别是24和32bytes，那么，内存分配程序就会计算，从32bytes的cessions中分配，就要分配256字节，从24bytes的cessions中分配，就只需要分配192字节。很明显，从page size=24字节的cessions中分配，划算得多。

djyos利用lds文件，把所有未被静态使用的内存，都划入heap，在lds文件中，你会看到图 8‑4这样一段代码，lds文件的语法，这里就不解析了，解析两个概念：

系统heap：即命名为“sys”的heap，在lds文件中必须排首位，也是malloc等没有指定heap的函数的默认heap。

“通用堆”和“专用堆”：当你调用Heap_MallocHeap函数分配内存时，是要指定从哪个heap中分配的。如果该指定的heap是专用堆，则只能从该heap中分配，分配不成功则返回NULL或者阻塞；如果是通用堆，则如果从该heap分配不成功的话，还会从别的heap分配。

cessions：可以看到，sys heap被分为两个cessions，因为他们都是片内ram，是同一性质的内存，其page size有意设置为24和32两个不同的值，可以提高内存利用率。

图 8‑4 lds中的heap描述代码

8.2.1 分配策略

带Heap后缀的分配函数：这些函数都有一个参数struct HeapCB *Heap，用于指定从哪个heap中分配内存。如果该heap是“通用堆”，则优先从该heap中分配，如果该heap内存不足，无法分配，就会转而从别的heap中分配；如果该heap是“专用堆”，则只能该heap分配。

不带Heap后缀的分配函数：相当于参数Heap是sys heap的带Heap后缀的函数。

包含多个cessions的堆：分配函数会自动查找从哪个cessions中分配时开销最小，只要该cessions仍然有内存，就从该cessions中分配。

8.3 “固定块”分配

“固定块”分配策略，是一种内存池分配技术。可以形象地描述为“批发”与“零售”的关系。不同于一般系统的固定块分配法，系统只允许“一次批发，卖完即止”。DJYOS允许卖完后，再次批发，甚至允许开店时（内存池初始化时）不进货，等有人买时再批发。零风险的买卖，值得做吧。

需要在DIDE中勾选并配置“固定块分配”模块才能使用，如下图：

图 8‑5 DIDE中配置固定块分配功能

8.4 “准静态”和“块相联”相关API

如上所述“准静态”和“块相联”内存管理策略均使用统一的用户接口。

8.4.1 malloc和Heap_Malloc：分配内存

#define malloc(x) Heap_Malloc(x,CN_TIMEOUT_FOREVER)

void *  (*Heap_Malloc)(ptu32_t size,u32 timeout);

头文件：

stdlib.h

参数：

size：申请内存块的大小，以字节计。

timeout：等待时间。申请内存（调用函数）时，内存不足，事件（调用者）将被阻塞并等待其他事件释放内存。如果直至timeout时间之后，内存仍不足则申请失败。在非tickless模式，等待时间系统自动向上取整为整数个ticks。

返回值：

申请成功返回内存首指针；失败则返回NULL。

说明：

从堆中分配size大小的全局内存空间。由于DJYOS系统使用块相联分配算法，size将被向上取整为一个规格化大小的块，规格化方法参见《都江堰操作系统原理与实现》中内存管理章节介绍。如果系统没有满足条件的内存块，且timeout不等于0，则阻塞线程，直到timeout时间到或者有其他线程释放内存致使有合适的内存块。

由于规格化，所获得的内存很可能超过size参数，调用Heap_CheckSize函数可获取实际申请到的内存的大小。

malloc是C标准规定的函数，用宏实现。

Heap_Malloc是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.2 realloc和Heap_Realloc：拓展内存

#define realloc(p,size) Heap_Realloc(p,size,CN_TIMEOUT_FOREVER)

void *(*Heap_Realloc) (void *, ptu32_t NewSize);

头文件：

stdlib.h

参数：

p：原内存首地址。

NewSize：申请内存块的新尺寸，以字节计。

Timeout：等待时间。申请内存（调用函数）时，内存不足，事件（调用者）将被阻塞并等待其他事件释放内存。如果直至Timeout时间之后，内存仍不足则申请失败。等待时间系统自动向上取整为整数个ticks。

返回值：

拓展成功返回内存首指针；失败则返回NULL。

说明：

先判断当前内存p大小是否已经满足新设定的尺寸要求。如果满足，直接返回原内存地址。如果不满足，则先按照NewSize指定的大小分配空间，将原有内存中的数据拷贝到新分配的空间，然后返回新申请内存首地址。

realloc是C标准规定的函数，用宏实现。

M_ Realloc是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.3 free和Heap_Free：释放内存

#define free(x) Heap_Free(x)

v void  (*Heap_Free)(void * pl_mem);

头文件：

stdlib.h

参数：

p：内存首地址。

返回值：

无。

说明：

释放申请的内存。

警告：在“准静态”内存管理策略中，必须等地址比被释放的内存更高的所有准静态分配的内存都释放了，新释放的内存空间才能重新得到利用。

M_ Free是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.4 Heap_FreeHeap：释放指定堆内存

void  (*Heap_FreeHeap)(void * pl_mem,pHeap_t Heap);

头文件：

stdlib.h

参数：

pl_mem：内存首地址。

Heap：堆句柄（控制块）。

返回值：

申请成功返回内存首指针；失败则返回NULL。

说明：

释放从指定的Heap句柄（控制块）指定的堆空间中申请的内存空间。

警告：在“准静态”内存管理策略中，必须等地址比被释放的内存更高的所有准静态分配的内存都释放了，新释放的内存空间才能重新得到利用。

M_ FreeHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.5 Heap_MallocHeap：从指定heap申请内存

void *(*Heap_MallocHeap)(ptu32_t size,pHeap_t Heap,u32 timeout);

头文件：

stdlib.h

参数：

size：申请内存大小。

Heap：堆句柄（控制块）。

timeout：等待时间。申请内存（调用函数）时，内存不足，事件（调用者）将被阻塞并等待其他事件释放内存。如果直至Timeout时间之后，内存仍不足则申请失败。在非tickless模式，等待时间系统自动向上取整为整数个ticks。

返回值：

申请成功返回内存首指针；失败则返回NULL。

说明：

优先从指定的Heap句柄（控制块）指定的堆空间中申请size大小的内存。如果Heap的属性是“专用”，则只能从该heap中申请内存；如果是“通用”，则优先从该heap申请，如果申请不到，则从其他heap中申请。

M_ MallocHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.6 Heap_MallocLc：申请局部内存

void *(*Heap_MallocLc)(ptu32_t size,u32 timeout);

头文件：

stdlib.h

参数：

size：申请内存大小。

timeout：等待时间。申请内存（调用函数）时，内存不足，事件（调用者）将被阻塞并等待其他事件释放内存。如果直至Timeout时间之后，内存仍不足则申请失败。在非tickless模式，等待时间系统自动向上取整为整数个ticks。

返回值：

申请成功返回内存首指针；失败则返回NULL。

说明：

申请局部内存。所谓局部内存，是指所申请的这种内存的生命周期与事件处理的生命周期是同步的，当事件消亡的时候，仍然没有释放的内存，将被强制释放避免内存泄漏。然而，强制释放是很消耗时间的，实时软件的设计者在内存使用完毕后，应该及时调用Heap_Free函数释放内存，必须避免强制释放这种事情发生。欲在事件生存期外继续使用分配的内存，请调用malloc或Heap_Malloc函数分配全局内存块。

M_ MallocLc是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.7 Heap_MallocLcHeap：从指定heap申请局部内存

void *(*Heap_MallocLcHeap)(ptu32_t size,pHeap_t Heap, u32 timeout);

头文件：

stdlib.h

参数：

size：申请内存大小。

Heap：堆句柄（控制块）。

Timeout：等待时间。申请内存（调用函数）时，内存不足，事件（调用者）将被阻塞并等待其他事件释放内存。如果直至Timeout时间之后，内存仍不足则申请失败。在非tickless模式，等待时间系统自动向上取整为整数个ticks。

返回值：

申请成功返回内存首指针；失败则返回NULL。

说明：

优先从指定的Heap句柄（控制块）指定的堆空间中申请size大小的局部内存。如果Heap的属性是“专用”，则只能从该heap中申请内存；如果是“通用”，则优先从该heap申请，如果申请不到，则从其他heap中申请。

局部内存含义参见Heap_MallocLc函数。

M_ MallocLcHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.8 Heap_FormatSize：换算“规格尺寸”

ptu32_t (*Heap_FormatSize)(ptu32_t size);

头文件：

stdlib.h

参数：

size：内存空间尺寸。

返回值：

规格尺寸。

说明：

将内存空间尺寸换算成系统heap的“规格尺寸”。所谓“规格尺寸”是指，如果你请求分配size尺寸的内存，系统实际分配给你的内存尺寸。

M_ FormatSize是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.9 Heap_FormatSizeHeap：换算指定堆“规格尺寸”

ptu32_t (*Heap_FormatSizeHeap)(ptu32_t size,pHeap_t Heap);

头文件：

stdlib.h

参数：

size：内存空间尺寸。

Heap：堆句柄（控制块）。

返回值：

规格尺寸。

说明：

将内存空间尺寸换算指定heap的“规格尺寸”。所谓“规格尺寸”是指，如果你请求分配size尺寸的内存，系统实际分配给你的内存尺寸。

M_ FormatSizeHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.10 Heap_GetMaxFreeBlock：查询最大块

ptu32_t (*Heap_GetMaxFreeBlockHeap)(pHeap_t Heap);

头文件：

stdlib.h

参数：

无。

返回值：

最大块尺寸（字节数）。

说明：

查询系统heap最大内存块尺寸。

M_ GetMaxFreeBlockHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.11 Heap_GetMaxFreeBlockHeap：查询指定堆最大块

ptu32_t (*M_ GetMaxFreeBlockHeap)(pHeap_t Heap);

头文件：

stdlib.h

参数：

Heap：堆句柄（控制块）。

返回值：

最大块尺寸（字节数）。

说明：

查询指定heap中最大内存块尺寸。

M_ GetMaxFreeBlockHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.12 Heap_GetHeapSize：查询指定堆尺寸

ptu32_t Heap_GetHeapSize (pHeap_t Heap);

头文件：

stdlib.h

参数：

无

返回值：

系统heap尺寸（字节数）。

说明：

如果系统heap由多个cessions组成，则累加起来。

8.4.13 Heap_GetHeapSizeHeap：查询指定堆尺寸

ptu32_t Heap_GetHeapSizeHeap(pHeap_t Heap);

头文件：

stdlib.h

参数：

Heap：堆句柄（控制块）。

返回值：

heap尺寸（字节数）。

说明：

如果指定heap由多个cessions组成，则累加起来。

8.4.14 Heap_FindHeap：查找heap

pHeap_t Heap_FindHeap(const char *HeapName);

头文件：

stdlib.h

参数：

HeapName：heap的名字。

返回值：

heap控制块指针，如果没找到则返回NULL。

说明：

系统中每个heap都是有名字的，可以凭名字找到heap，shell的“heap”命令可以列出所有的heap及名字。

8.4.15 Heap_GetFreeMem：查询sys heap内存总量

ptu32_t (*Heap_GetFreeMem)(void);

头文件：

stdlib.h

参数：

无。

返回值：

系统heap内存总量（字节数）。

说明：

如果sys  heap由多个cessions组成，则累加起来。

M_ GetFreeMem是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.16 Heap_GetFreeMemHeap：查询指定heap空闲内存量

ptu32_t (*Heap_GetFreeMemHeap)(pHeap_t Heap);

头文件：

stdlib.h

参数：

Heap：堆句柄（控制块）。

返回值：

可用内存总量（字节数）。

说明：

查询指定堆空间的可用内存总量（字节数）。

Heap_GetFreeMemHeap是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.4.17 Heap_CheckSize：查询内存块尺寸

#define malloc_usable_size(ptr) Heap_CheckSize(ptr)

ptu32_t (*Heap_CheckSize)(void * mp);

头文件：

stdlib.h

参数：

mp：内存首地址。

返回值：

分配给mp指针的实际内存大小（字节数）。

说明：

查询所申请的内存mp的实际大小。由于内存分配函数要对size参数做规格化调整，即将用户申请的内存换算大于且最接近size的“规格化”大小，再分配给用户，malloc函数实际获得的内存块可能比申请量大许多，本函数查询获得的内存块的实际可用尺寸。

malloc_usable_size是newlibc库要求的函数。

M_ CheckSize是个指针，在准静态分配阶段和块相联分配阶段，分别赋值为不同函数。

8.5 “固定块”相关API

8.5.1 Mb_CreatePool：创建内存池

struct MemCellPool *Mb_CreatePool(void *pool_original,u32 capacital,

                                u32 cell_size,u32 increment,

                                u32 limit,const char *name);

头文件：

os.h

参数：

pool_original：最初由用户提供的内存空间，不提供设为NULL。

capacital：原始内存池的尺寸，以块为单位，如果pool_original == NULL，则为0。

cell_size：内存块尺寸，若系统有对齐要求，必须为指针长度的整数倍，且最小为两倍指针长度。

increment：当本参数不为零时，所创建的内存池被一但被耗光，会从堆中补充获取increment个的内存块。直至内存池再被消耗完，再次获取。注意，内存池扩大后，即使用户调用mb_free释放了内存，但除非释放了内存池中的全部内存，否则新增的内存不会被收回。

limit：如果increment !=0，limit限制内存池的最大块数，以防其无限制地增加，导致内存耗尽。

name：设置内存池的名称，表示名称的字符串不能是局部变量，无名称则设置为NULL。

返回值：

指向所创建的内存池的指针。

说明：

创建一个内存池，pool_original一般是定义一个大数组，这个数组的大小是capacital乘以cell_size。如果系统有对齐要求，则起始地址至少要按照指针类型对齐，cell_size也要大于等于2倍指针长度。不要用char pool_original[n* cell_size]的方式定义内存，在要求对齐访问的系统中，创建内存池很可能失败，即使不失败，也存在内存访问对齐错误的可能。正确的方法是：struct tar pool_original[n];cell_size = sizeof(struct tar)。

可创建的内存池数量，受图 8‑5限制。

8.5.2 Mb_CreatePool_s：创建静态内存池

struct MemCellPool *Mb_CreatePool_s(struct MemCellPool *pool,

                                void *pool_original,u32 capacital,

                                u32 cell_size,u32 increment,

                                u32 limit,const char *name);

头文件：

os.h

参数：

pool：内存池指针（控制块）；

其他参数：参见8.5.1节。

返回值：

指向所创建的内存池的指针。

说明：

与mb_create_pool不同的是，内存池控制块pool由调用者提供，其他与mb_create_pool完全一致。高可靠性的应用中，不应该使用动态分配的方式，静态定义更可靠，然后把指针传递过来。内核中使用的内存池，都是使用静态定义的。

本函数创建的内存池数量，不受图 8‑5限制。

8.5.3 Mb_DeletePool：删除内存池

bool_t Mb_DeletePool(struct mem_cell_pool *pool)

头文件：

os.h

参数：

pool：内存池指针（空间块）。

返回值：

删除成功返回true；失败则为false。

说明：

删除一个内存池，当某内存池不再需要时，可调用本函数。本函数只清理了内存池的信号量和资源结点，内存池缓冲区是调用者提供的，理应由调用者清理。对于一个可扩容的内存池，如果发生了扩容行为，新增加的内存也将随之释放回堆中。

8.5.4 Mb_DeletePool_s：删除静态内存池

bool_t Mb_DeletePool_s(struct mem_cell_pool *pool)

头文件：

os.h

参数：

pool：内存池指针（控制块）。

返回值：

删除成功返回true；失败则为false。

说明：

本函数与Mb_CreatePool_s对应，功能与Mb_DeletePool一致。

8.5.5 Mb_Malloc：申请内存

void *Mb_Malloc(struct mem_cell_pool *pool,uint32_t timeout);

头文件：

os.h

参数：

pool：内存池指针。

timeout：参见第5.7.1节。

返回值：

申请成功返回内存地址；否则返回NULL。

说明：

从指定的内存池中申请一块内存。注意，连续调用本函数，并不能保证连续申请的内存地址是连续的。如果指定的内存池允许扩容，则该内存池耗尽时，将从堆中获取一块内存添加到内存池中。但从堆中扩容内存到内存池中的操作时单向的，一经扩容永不释放，直到内存池被删除。

8.5.6 Mb_Free：释放内存

void Mb_Free(struct mem_cell_pool *pool,void *block);

头文件：

os.h

参数：

block：待释放的内存块指针；

pool：目标内存池。

返回值：

无。

说明：

释放内存，把使用完毕的内存块放回指定的内存池，内存池和内存块必须匹配，否则会发生不可预料的错误，新释放的块链接到 free_list 队列中，而不是放回连续池，也不重新返回系统堆。

8.5.7 Mb_QueryFree：查询内存池空闲量

u32 Mb_QueryFree(struct mem_cell_pool *pool);

头文件：

os.h

参数：

pool：目标内存池。

返回值：

空闲内存块数。

说明：

查询内存池还有多少空闲内存块，对于一个不可扩容的内存池，返回结果就是可供分配的块数；对一个可扩容的，返回的是当前池中的空闲块数。

8.5.8 Mb_QueryCapacital：查询内存池总量

u32 Mb_QueryCapacital(struct mem_cell_pool *pool)

头文件：

os.h

参数：

pool：目标内存池。

返回值：

内存池总内存块数。

说明：

查询内存池总共有多少内存块，对于一个可扩容的内存池，其总容量也包括扩容部分，而不是允许扩容的上限。

第9章 锁

锁的用途是保证临界区数据的安全访问，或者线程与线程、线程与中断间的同步。临界区数据指的是不同线程或者中断可能同时访问的数据区。这里要注意并不是所有的共享数据区都是临界区，只有那些有可能被同时访问的区域，才称作临界区。DJYOS只支持线程之间、线程和异步信号间的同步，不支持线程和实时中断间的同步。另外，线程和异步信号间的同步还可以使用“异步信号同步”功能。DJYOS支持3种锁：

1.调度锁，锁住调度，等同于禁止中断。

2.信号量，适用于允许一个或者有限多个用户同时访问的场合。信号量允许线程之间或中断与线程间的交叉请求和释放，即A线程请求信号量——B线程释放信号量。

3.互斥量，适用于单一资源且需要优先级继承的场合。互斥量的请求者和释放者必须是同源，即同一事件（线程）或者中断处理函数。

信号量（互斥量）控制块使用相同的内存池，称为锁控制块，采用固定块动态分配法。创建信号或者互斥量时，信号或互斥量总数在DIDE中配置，如图 9‑1。另外，为了满足OSEK、MISRA等标准的要求，DJYOS还提供另一对函数用于创建信号或互斥量：Lock_SempCreate_s、Lock_MutexCreate_s，这对函数是静态地创建信号或者互斥量，即要求调用者提供（指定）锁控制块空间，其数量不受图 9‑1限制。

图 9‑1DIDE中配置锁模块

信号量和互斥量的共同点：

：

①相同上下文的意思是，在同一个线程中，或者在异步信号中。

②一个线程连续多次请求然后连续多次释放，称为嵌套请求。

信号量和互斥量有许多相似的特性，都能够提供临界区安全保护，有许多场合既可用信号量实现，又可以用互斥量实现，但他们在使用上，还是有区别的。

同步和线程间（线程与异步信号间）通信是信号量的拿手绝活，典型用途：

1.A线程阻塞于某信号量（pend），B线程（或异步信号）在合适的时机释放信号量（post），A线程得以继续运行。

2.A线程要访问某临界资源，先获取保护该资源的信号量，访问完毕后释放（post）。期间，如果B线程也来取该信号量，将会被阻塞，直到A释放该线程。

3.A线程要读取数据，但该数据尚未被生产出来，A线程将pend并阻塞在信号量上，B线程（或异步信号中断）生产数据后，释放（post）信号量。A线程解除阻塞并访问数据。

4.某资源允许n个入口，可使用信号量的计数功能，例如使用信号量保护内存池。

信号量的用途要比互斥量广泛得多，除优先级继承功能外，互斥量的所有功能，信号量都可以涵盖。

在对象序列中，信号量和互斥量各有一个目录，分别是“semaphore”和“mutex”。

9.1 锁调度和锁中断

参见6.4节和6.4.1节。

特别注意，原子操作并不锁调度，千万不能在原子操作期间调用可能发生调度的函数，原子操作期间最好不要调用任何系统API。

9.2 信号量API

9.2.1 Lock_SempCreate：创建信号量

struct SemaphoreLCB *Lock_SempCreate(s32 lamps_limit,s32 init_lamp,

                                   u32 sync_order,const char *name);

头文件：

os.h

参数：

lamps_limit：设定可用信号灯的上限，设定值不能为零，semp_limit = CN_LIMIT_UINT32则表示无上限，无限多。

init_lamp：初始可用信号灯数量，取值范围0~ lamps_limit；

sync_order：被信号阻塞事件的排列顺序。sync_order = CN_BLOCK_FIFO表示按申请获取信号的先后顺序排列，sync_order = CN_BLOCK_PRIO表示按事件的优先级排列；

name：信号量的名字，所指向的字符串不能定义为局部变量，无名称即为NULL。

返回值：

新创建的信号量。

说明：

建立一个信号量，信号量须先创建再使用。可以创建的信号量和互斥量的数量总和（两者之和），受图 9‑1限制。

9.2.2 Lock_SempCreate_s：创建静态信号量

struct SemaphoreLCB *Lock_SempCreate_s( struct SemaphoreLCB *semp,

                                              s32 lamps_limit,s32 init_lamp,u32 sync_order,

const char *name);

头文件：

os.h

参数：

semp：信号量控制块指针。

其他参数：同9.2.1节

返回值：

无。

说明：

可靠地创建一个信号量，与Lock_SempCreate函数不同的是，调用者须提供信号量控制块，然后把指针传递过来，高可靠性的应用中，不应该使用动态分配的方式，静态定义更可靠，本函数创建的信号量，不图 9‑1约束。

9.2.3 Lock_SempDelete：删除信号量

bool_t Lock_SempDelete(struct SemaphoreLCB *semp);

头文件：

os.h

参数：

semp：被删除的信号量

返回值：

删除成功返回true；失败返回false。

说明：

删除一个信号量，与Lock_SempCreate函数对应。

9.2.4 Lock_SempDelete_s：删除静态信号

bool_t Lock_SempDelete_s(struct SemaphoreLCB *semp)

头文件：

os.h

参数：

semp：被删除的信号量

返回值：

删除成功返回true；失败返回false。

说明：

删除一个信号量，与Lock_SempCreate_s函数对应。

9.2.5 Lock_SempPend：等待信号量

bool_t Lock_SempPend(struct SemaphoreLCB *semp,u32 timeout)

头文件：

os.h

参数：

semp：信号量指针

timeout：参见第5.7.1节。

返回值：

获取（申请）信号量成功返回true；获取信号量失败，返回false，如超时，信号量检查失败等。具体的错误类型，通过错误码来确定。

说明：

申请获取信号量的信号灯，如果信号量有效且有信号灯可用，则将可用信号灯总量减一，并成功返回true。如果同一个线程反复请求（pend）一个信号量，每次请求都会造成信号灯数量减一，减到零的时候，将被阻塞。这种情况下，由于被阻塞的原因，是本线程早先拿走了信号量，故只能等待自己释放，而自己又被阻塞不能运行，将造成死锁。假如timeout= CN_TIMEOUT_FOREVER，线程将永久失去响应。

9.2.6 Lock_SempPost：发送信号量

void Lock_SempPost(struct SemaphoreLCB *semp)

头文件：

os.h

参数：

semp：信号量指针。

返回值：

无。

说明：

释放一个信号灯，可用信号灯增一。注意，当可用信号灯数量大于lamps_limit后，就不会再增加。

9.2.7 Lock_SempQueryCapacital：查询信号量容量

u32 Lock_SempQueryCapacital(struct SemaphoreLCB *semp);

头文件：

os.h

参数：

semp：被查询的信号量。

返回值：

信号量包含的信号灯总数。

说明：

查询一个信号量包含信号灯的总数。

9.2.8 Lock_SempQueryFree：查询可用信号数

u32 Lock_SempQueryFree(struct SemaphoreLCB *semp)

头文件：

os.h

参数：

semp：被查询的信号量。

返回值：

信号灯总数。

说明：

查询一个信号量可用信号灯的数量，如果大于0，调用Lock_SempPend函数能取得信号量。

9.2.9 Lock_SempCheckBlock：查询是否存在被阻塞事件

bool_t Lock_SempCheckBlock(struct SemaphoreLCB *Semp)

头文件：

os.h

参数：

Semp：信号量指针。

返回值：

存在等待同步的事件返回true；否则fasle。

说明：

查询信号量的同步队列中是否有事件在等待。

9.2.10 Lock_SempSetSyncSort：设置信号量阻塞方式

void Lock_SempSetSyncSort(struct SemaphoreLCB *semp,u32 order)

头文件：

os.h。

参数：

semp：被设置的信号量；

order：被信号阻塞事件的排列顺序。sync_order = CN_BLOCK_FIFO表示按申请获取信号的先后顺序排列，sync_order = CN_BLOCK_PRIO表示按事件的优先级排列。

返回值：

无。

说明：

设置被信号量阻塞的事件，在该信号量同步队列中的排队方式。该设置只影响设置之后新加入的事件，已在队列中的事件不受影响。

9.3 互斥量API

9.3.1 Lock_MutexCreate：创建互斥量

struct MutexLCB *Lock_MutexCreate(char *name)

头文件：

os.h。

参数：

name：互斥量名称，所指向的字符串不能定义为局部变量。无名称则为NULL。

返回值：

新创建互斥量的指针。

说明：

信号量所占内存由系统从锁内存池中分配。互斥量须先创建再使用。可以创建的信号量和互斥量的数量总和（两者之和），受图 9‑1限制。

9.3.2 Lock_MutexCreate_s：创建静态互斥量

struct MutexLCB *Lock_MutexCreate_s(struct MutexLCB *mutex,

char *name)

头文件：

os.h

参数：

mutex：互斥量控制块指针。

name：互斥量名称，所指向的字符串不能定义为局部变量。无名称则为NULL。

返回值：

新创建互斥量的指针。

说明：

静态地创建一个互斥量，与mutex_create函数不同的是，调用者须提供互斥量控制块，然后把指针传递过来，高可靠性的应用中，不应该使用动态分配的方式，静态定义更可靠。内核中使用的互斥量，都是使用Lock_MutexCreate_s创建的。本函数创建的信号量和互斥量的数量总和（两者之和），不受图 9‑1限制。

9.3.3 Lock_MutexDelete：删除互斥量

bool_t Lock_MutexDelete(struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：被删除信号量的指针。

返回值：

删除成功返回true；否则返回false。

说明：

删除一个信号量，与mutex_create函数对应。

9.3.4 Lock_MutexDelete_s：删除静态互斥量

bool_tLock_MutexDelete_s(struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：被删除信号量的指针。

返回值：

删除成功返回true；否则返回false。

说明：

删除一个信号量，与mutex _create_r函数对应。

9.3.5 Lock_MutexPend：等待互斥量

bool_t Lock_MutexPend(struct MutexLCB *mutex,u32 timeout)

头文件：

os.h

参数：

mutex：互斥量指针。

timeout：参见第5.7.1节。

返回值：

获取（申请）互斥量成功返回true；获取信号量失败返回false，如超时，信号量检查失败等。具体的错误类型，通过错误码来确定。

说明：

由于mutex只能被一个事件拥有，owner成员保存了该事件指针，因此嵌套请求是允许的。即如果请求一个处于忙状态的互斥量，如果请求者是拥有者，则不会被阻塞，否则将被阻塞。

9.3.6 Lock_MutexPost：发送互斥量

void Lock_MutexPost(struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：互斥量指针。

返回值：

无。

说明：

释放互斥量，再次强调，互斥量只能被拥有者释放，所以互斥量不适用于线程间或线程与异步信号中断间同步。

9.3.7 Lock_MutexCheckBlock：查询是否存在被阻塞事件

bool_t  Lock_MutexCheckBlock (struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：互斥量指针。

返回值：

存在等待同步的事件返回true；否则fasle。

说明：

查询互斥量的同步队列中是否有事件在等待。

9.3.8 Lock_MutexGetOwner：查询占用者

u16 Lock_MutexGetOwner(struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：互斥量指针。

返回值：

互斥量被事件占有，返回该事件ID；否则返回CN_EVENT_ID_INVALID。

说明：

获取占有互斥量mutex的事件的ID。

9.3.9 Lock_MutexQuery：查询互斥量状态

bool_t Lock_MutexQuery(struct MutexLCB *mutex)

头文件：

os.h

参数：

mutex：被查询的互斥量。

返回值：

互斥量可用返回true；不可用则返回false。

说明：

查询互斥量是否可用。

第10章 GUI

见《DJYOS图形编程（上）》和《DJYOS图形编程（下）》。

第11章 对象系统

11.1 对象树

djyos的IO系统依托对象系统构建。

内存中构建了一个对象管理系统，对象可能对应文件，也可能对应目录。所有文件均已对象为基础，对象作为软件所要操作的数据集合的高层次抽象，实现了一些公共的管理功能，并为此定义了一套外部接口。对象系统并不知道它如何被用户使用，一个对象，究竟是文件还是目录，是套接字还是SPI总线，是内存池还是信号量，……，对象系统并不知道。特别提示，不能以是否拥有子对象来区分文件与目录，文件也可以有子文件，典型代表是djygui的窗口，窗口和子窗口都是文件。

那怎么区分不同性质的对象呢？在于 struct Object的ObjOps成员，一组性质相同的对象，会用继承的方式共享ObjOps，例如yaffs2，mount点（一个对象）的ObjOps，会被所有被加载的文件或目录对象继承。object.h 中定义了完整的命令集，而具体对象，则根据自己的需要，选择性地实现。例如“lock”对象，就不实现“write”方法。

由此可见，djyos的对象系统，也有面向对象编程的含义。

图 11‑1 对象树组织图

数据结构：

各成员说明：

prev，next，Parent，Child四个指针：构成如图 11‑1树形数据结构。

ObjPrivate：对象私有数据，用来描述该对象的某些属性，有些简单对象可能不使用，也有些对象不太复杂，用一个32位的整数就能表达；复杂些的对象，就要定义私有数据结构，此时，ObjPrivate是指向该结构的指针。

ObjOps：对象操作函数，这里定义了一系列操作对象的命令，与ObjPrivate共同构成该对象的功能。对象系统本身不管对象用途，对象的实际使命，全系于ObjOps。

inuse：对象的引用次数，与图 11‑1中“port”的数量一致。

handles：指向对象的访问句柄的链表。对象本身并不能用“read/write”等函数直接访问，APP要读写对象，必须通过句柄结构。句柄结构参见11.2.38。

11.2 对象API说明

11.2.1 OBJ_GetPrivate取对象私有数据

ptu32_t OBJ_GetPrivate(struct Object *obj);

头文件：

os.h

参数：

obj：目标对象指针。

返回值：

对象的私有指针。

11.2.2 OBJ_SetPrivate设置对象私有数据

void OBJ_SetPrivate(struct Object *obj, ptu32_t Private);

头文件：

os.h

参数：

obj：目标对象指针。

Private：新的私有数据

返回值：

无。

11.2.3 OBJ_GetOps取对象操作函数

fnObjOps  OBJ_GetOps(struct Object *obj);

头文件：

os.h

参数：

obj：目标对象指针。

返回值：

对象的操作函数指针。

11.2.4 OBJ_SetOps设置对象操作函数

s32 OBJ_SetOps(struct Object *obj, fnObjOps ops);

头文件：

os.h

参数：

obj：目标对象指针。

ops：新的操作函数指针

返回值：

无。

11.2.5 OBJ_GetCurrent：取当前对象

struct Object * OBJ_GetCurrent(void);

头文件：

os.h

参数：无

返回值：

当前对象指针。

11.2.6 OBJ_SetCurrent ：设置当前对象

void OBJ_SetCurrent(struct Object * obj);

头文件：

os.h

参数：

obj：新的当前对象指针。

返回值：

无。

11.2.7 OBJ_GetName：查询对象名

const char *OBJ_GetName(struct Object *Obj);

头文件：

os.h

参数：

Obj：对象指针。

返回值：

成功则返回对象名指针，失败返回false。

说明：略。

11.2.8 OBJ_ReName：修改对象名

char *OBJ_ReName(struct Object * Obj,char *NewName);

头文件：

os.h

参数：

Obj：被修改的资源节点的指针。

NewName：节点新名称的指针。

返回值：

执行成功返回true；失败返回false。

说明：

修改对象名称，本函数执行过程拷贝数据，而是直接使用NewName提供的buffer，因此，NewName应该提供永久buffer，不允许局部数组，也不允许用过就释放的临时空间。

11.2.9 OBJ_CheckName：检查对象名

s32 OBJ_CheckName(const char *name);

头文件：

os.h

参数：

name：被检查的字符串指针。

返回值：

合法（0）；非法（-1）。

说明：

检查一个字符串是否合法的对象名：不允许存在'/'、'\'字符，长度不允许超过规定；

11.2.10 OBJ_NewPrev：创建前导对象

struct Object *OBJ_NewPrev (struct Object *loc, fnObjOps ops,

                        ptu32_t ObjPrivate, const char *name);

头文件：

os.h

参数：

loc：基准对象，新对象是插入在这个节点的previous位置。

ops：新对象的操作函数，可以是NULL。

ObjPrivate：对象的私有数据，与ops共同决定对象功能。

name：对象名称，所指向的字符串不能定义为局部变量，无名称即为NULL。

返回值：

指向新插入对象的指针。

说明：略

11.2.11 OBJ_NewNext：创建后继对象

struct Object *OBJ_NewNext(struct Object *loc, fnObjOps ops,

                        ptu32_t ObjPrivate, const char *name);

头文件：

os.h

参数：

loc：基准对象，新对象是插入在这个节点的next位置。

ops：新对象的操作函数，可以是NULL。

ObjPrivate：对象的私有数据，与ops共同决定对象功能。

name：对象名称，所指向的字符串不能定义为局部变量，无名称即为NULL。

返回值：

指向新插入对象的指针。

说明：略

struct Object *OBJ_NewHead(struct Object *loc,fnObjOps ops,

                           ptu32_t ObjPrivate, const char *name);

11.2.12 OBJ_NewChild：创建子对象

struct Object *OBJ_NewChild (struct Object *loc, fnObjOps ops,

                        ptu32_t ObjPrivate, const char *name);

头文件：

os.h

参数：

loc：基准对象，新对象成为这个对象的子对象，位于子对象的队列尾部。

ops：新对象的操作函数，可以是NULL。

ObjPrivate：对象的私有数据，与ops共同决定对象功能。

name：对象名称，所指向的字符串不能定义为局部变量，无名称即为NULL。

返回值：

指向新插入对象的指针。

说明：略

11.2.13 OBJ_NewHead：创建头对象

struct Object *OBJ_NewHead (struct Object *loc, fnObjOps ops,

                        ptu32_t ObjPrivate, const char *name);

头文件：

os.h

参数：

loc：基准对象，新对象成为它的兄弟对象，位于队列头部。

ops：新对象的操作函数，可以是NULL。

ObjPrivate：对象的私有数据，与ops共同决定对象功能。