Merge pull request '修正文档中的一些词语、标点、空格的使用不当' (#41) from RobertYuan/xuos-web:master into master
This commit is contained in:
caodg
commit
32a2e231da
|
|
@ -251,7 +251,7 @@ int BusUnregister(struct Bus *bus)
|
|||
}
|
||||
```
|
||||
|
||||
* DRIVER注册到BUS函数
|
||||
* DRIVER注册并挂接到BUS函数
|
||||
```c
|
||||
/**
|
||||
* @Description: support to register driver pointer to bus pointer
|
||||
|
|
@ -273,7 +273,7 @@ int DriverRegisterToBus(struct Bus *bus, struct Driver *driver)
|
|||
}
|
||||
```
|
||||
|
||||
* DRIVER从BUS中删除函数
|
||||
* 将DRIVER从BUS中删除函数
|
||||
```c
|
||||
/**
|
||||
* @Description: support to delete driver pointer from bus pointer
|
||||
|
|
@ -296,7 +296,7 @@ int DriverDeleteFromBus(struct Bus *bus, struct Driver *driver)
|
|||
}
|
||||
```
|
||||
|
||||
* DEVICE注册到BUS函数
|
||||
* DEVICE注册并挂接到BUS函数
|
||||
```c
|
||||
/**
|
||||
* @Description: support to register dev pointer to bus pointer
|
||||
|
|
@ -318,7 +318,7 @@ int DeviceRegisterToBus(struct Bus *bus, struct HardwareDev *device)
|
|||
}
|
||||
```
|
||||
|
||||
* DEVICE从BUS中删除函数
|
||||
* 将DEVICE从BUS中删除函数
|
||||
```c
|
||||
/**
|
||||
* @Description: support to delete dev pointer from bus pointer
|
||||
|
|
|
|||
|
|
@ -17,17 +17,17 @@ shell的运行过程：
|
|||
* 执行相应的操作
|
||||
|
||||
建立一个命令与函数的一一对应的关系，定义结构体。
|
||||
根据定义建立一个表，将所有的命令以及对应的函数进行声明
|
||||
根据定义建立一个表，将所有的命令以及对应的函数进行声明。
|
||||
获得输入的命令，并将其和命令表中的命令进行匹配，然后执行相应的函数。
|
||||
|
||||
使用串口进行命令的输入和输出，在输入命令并回车之后，程序解析命令，根据空格将输入分开为命令和参数，对命令进行匹配，匹配到命令之后，执行函数。伪代码如下：
|
||||
```c
|
||||
#define TRUE 1
|
||||
|
||||
while(TRUE) { /* repeat forever */
|
||||
type_prompt(); /* display prompt on the screen */
|
||||
read_command(command, parameters); /* read input from terminal */
|
||||
execve(command,parameters,0); /* execute command */
|
||||
while(TRUE) { /* repeat forever */
|
||||
type_prompt(); /* display prompt on the screen */
|
||||
read_command(command, parameters); /* read input from terminal */
|
||||
execve(command, parameters, 0); /* execute command */
|
||||
}
|
||||
```
|
||||
### 总结
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Newlib
|
||||
|
||||
[Newlib](https://sourceware.org/newlib/)是一个由Red Hat公司维护的面向嵌入式设备的开源C标准库实现，并且是许多ARM、RISC-V架构交叉编译工具链的默认C标准库版本。
|
||||
[Newlib](https://sourceware.org/newlib/)是一个由Red Hat公司维护的面向嵌入式设备的开源C标准库实现，是许多ARM、RISC-V架构交叉编译工具链的默认C标准库版本。
|
||||
|
||||
当XS_USING_LIBC选项打开时，XiUOS将使用Newlib提供C标准库函数。Newlib的正常工作依赖于XiUOS内核提供的一系列服务接口，这些接口定义在framework/lib/newlib/syscalls.c文件中。关于Newlib标准库函数与服务接口间的依赖关系可以参考[Newlib文档的Syscalls部分](https://sourceware.org/newlib/libc.html#Syscalls)。
|
||||
|
||||
|
|
@ -14,4 +14,4 @@ XiUOS使用bzip2工具提供对bz2文件格式的支持：当文件系统功能
|
|||
|
||||
## MicroPhython
|
||||
|
||||
敬请期待
|
||||
敬请期待
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ enum SensorQuantityType {
|
|||
};
|
||||
```
|
||||
|
||||
value成员记录与该SensorQuantity相关的值，包括结果的小数位数、采集历史的最大值和最小值、国家标准的最大值和最小值、最近一次采集的值。取值时需要注意处理小数点，用变量的值除以小数位数乘以10。如果某一个值不存在，则为SENSOR_QUANTITY_VALUE_ERROR。
|
||||
value成员记录与该SensorQuantity相关的值，包括结果的小数位数、采集历史的最大值和最小值、国家标准的最大值和最小值、最近一次采集的值。取值时需要注意处理小数点，用变量的值除以十的小数位数次幂。如果某一个值不存在，则为SENSOR_QUANTITY_VALUE_ERROR。
|
||||
|
||||
```c
|
||||
#define SENSOR_QUANTITY_VALUE_ERROR ((uint32)0xffffffff)
|
||||
|
|
@ -83,7 +83,7 @@ struct SensorDevice {
|
|||
};
|
||||
```
|
||||
|
||||
name成员记录传感器设备在系统中的名字，用于唯一标识一个SensorDevice结构
|
||||
name成员记录传感器设备在系统中的名字，用于唯一标识一个SensorDevice结构。
|
||||
|
||||
info成员记录传感器设备的一些属性信息，包括传感器的采集能力ability、厂家名vendor name与产品型号model name，其中ability用一个位图表示该传感器设备可以测量的物理量：
|
||||
|
||||
|
|
@ -202,7 +202,7 @@ int SensorQuantityClose(struct SensorQuantity *quant);
|
|||
int32 SensorQuantityRead(struct SensorQuantity *quant);
|
||||
```
|
||||
|
||||
在获取数据前需要先获取并打开要使用的物理量,打开后可以随时对传感器数据进行读取,使用完毕必须关闭传感器。完整的使用过程示例如下：
|
||||
在获取数据前需要先获取并打开要使用的物理量，打开后可以随时对传感器数据进行读取，使用完毕必须关闭传感器。完整的使用过程示例如下：
|
||||
|
||||
```c
|
||||
void Co2Zg09(void)
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ enum xs_plc_transport{
|
|||
```
|
||||
|
||||
:::tip
|
||||
注意两者间有对应关系而不是随意组合，如S7(STEP 7)只能采用TCP协议，而Modbus支持tcp/serial/raw socket/pcap replay,可以定义一个函数检查类型：
|
||||
注意两者间有对应关系而不是随意组合，如S7(STEP 7)只能采用TCP协议，而Modbus支持tcp/serial/raw socket/pcap replay，可以定义一个函数检查类型：
|
||||
xs_PlcProtocolCheck(struct xs_PlcDevice*);
|
||||
:::
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ struct xs_AdapterInfo{
|
|||
};
|
||||
```
|
||||
|
||||
ops成员包含统一的、类似文件系统的API，用于对网络适配器进行实际的数据读写。在使用一个网络适配器前后需要打开（open）/关闭（close）该网络适配器，send、receive分别用与从网络适配器接收数据与向网络适配器发送数据，ioctl用于配置Adapter属性：
|
||||
ops成员包含统一的、类似文件系统的API，用于对网络适配器进行实际的数据读写。在使用一个网络适配器前后需要打开（open）/关闭（close）该网络适配器，send、receive分别用于从网络适配器接收数据与向网络适配器发送数据，ioctl用于配置Adapter属性：
|
||||
|
||||
```c
|
||||
struct xs_AdapterOps {
|
||||
|
|
@ -101,7 +101,7 @@ struct xs_AdapterOps lora_example_ops = {
|
|||
};
|
||||
```
|
||||
|
||||
填充xs_AdapterLora,并将其注册。
|
||||
填充xs_AdapterLora，并将其注册。
|
||||
|
||||
```c
|
||||
int xs_AdapterRegister(struct xs_Adapter *sadapter);
|
||||
|
|
@ -178,4 +178,4 @@ int ret;
|
|||
2、去中心化
|
||||
自组网内无中心节点，节点之间可进行自主路由协商，以此来实现跳转通信，相比传统中心化网络，有效分摊网络流量，进而分散节点运算压力。自组网具有良好的健壮性，任何一个节点发生崩溃，其所承载的传感器会自动寻找其他上传节点，不会造成大面积的掉线事故。
|
||||
3、不依赖现有网络
|
||||
节点之间通信，不依赖现有的网络基础设施，自组网内部实现网络自治，以此应对通信地点和时间的不确定性。
|
||||
节点之间通信，不依赖现有的网络基础设施，自组网内部实现网络自治，以此应对通信地点和时间的不确定性。
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## 基本框架
|
||||
|
||||
传统嵌入式场景下，节点端主要负责数据采集和简单处理，复杂的任务放在边缘或者云端完成。而随着嵌入式芯片性能越来越强，在端侧承担更多的计算也成了目前的一个趋势，比如ST 推出的针对 STM 平台的神经网络加速库 STM32 Cube.AI。最近，部分厂商开始在嵌入式平台上引入神经网络加速模块，比如 ARM 即将发布的针对嵌入式场景的 Ethos-U55 神经网络处理器，以及 勘智 K210 平台嵌入了一颗卷积网络加速器 KPU，使得端侧算力进一步增强，从而使我们可以在端侧做更多的计算和任务，从而相比传统解决方案有更好的延时、更低的成本。
|
||||
传统嵌入式场景下，节点端主要负责数据采集和简单处理，复杂的任务放在边缘或者云端完成。而随着嵌入式芯片性能越来越强，在端侧承担更多的计算也成了目前的一个趋势，比如 ST 推出的针对 STM 平台的神经网络加速库 STM32 Cube.AI。最近，部分厂商开始在嵌入式平台上引入神经网络加速模块，比如 ARM 即将发布的针对嵌入式场景的 Ethos-U55 神经网络处理器，以及 勘智 K210 平台嵌入了一颗卷积网络加速器 KPU，使得端侧算力进一步增强，从而使我们可以在端侧做更多的计算和任务，从而相比传统解决方案有更好的延时、更低的成本。
|
||||
|
||||
我们提供了端侧的智能框架，将部分 AI 计算下沉到端侧，可以在端侧完成部分 AI 计算，从而为工业场景下的图像、声音等数据采集和感知提供更丰富的解决方案。比如 对于工业环境下的机械仪表读数识别，我们在初始化时通过边缘或者云端完成仪表数字分析，后续运行中我们在节点端完成仪表指针识别并计算仪表读数，从而在运行中不需要和边缘或者云端通信就可以完成读数识别，提供了更低的延时。
|
||||
我们提供了端侧的智能框架，将部分 AI 计算下沉到端侧，可以在端侧完成部分 AI 计算，从而为工业场景下的图像、声音等数据采集和感知提供更丰富的解决方案。比如，对于工业环境下的机械仪表读数识别，我们在初始化时通过边缘或者云端完成仪表数字分析，后续运行中我们在节点端完成仪表指针识别并计算仪表读数，从而在运行中不需要和边缘或者云端通信就可以完成读数识别，提供了更低的延时。
|
||||
|
||||
端侧智能框架基本结构如下：
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ XiUOS (X Industry Ubiquitous Operating System) 矽璓工业物联操作系统是
|
|||
|
||||
XiUOS诞生于浙江省北京大学信息技术高等研究院，其研发获得了杭州市萧山区政府的大力支持。萧山是浙江乃至中国的制造业重镇，工业基础雄厚，正在谋求传统制造业数字化转型升级、实现新旧动能转换，寻求工业互联网和物联网等信息技术的助力。XiUOS矽璓工业物联操作系统正是在这样的背景下应运而生，希望通过研发的工业物联网软硬件系统为助力，促进先进计算技术和工业场景的深度融合，助推工业企业的数字化转型，是产业应用需求和学术研究计划结合的产物。
|
||||
|
||||
关于"矽璓"，"矽"即硅，"璓"类玉，寓意从沙子到美石的演进升华之路。在开源社区的帮助下，未来矽璓去瑕，玉汝于成。
|
||||
关于"矽璓"，"矽"即硅，"璓"类玉，寓意从沙子到美石的演进升华之路。在开源社区的帮助下，未来矽璓去瑕，玉成其事。
|
||||
|
||||
## 定位
|
||||
|
||||
|
|
@ -19,7 +19,7 @@ XiUOS是一种工业物联网操作系统，目标是通过工业物联网的部
|
|||
|
||||
其中，**感** 和 **联** 主要在物联网节点级设备、传感器等设备上实现，**知**
|
||||
和 **控** 的核心主要在边缘计算设备和数据中心设备上实现。面向物联网节点级设备的
|
||||
矽璓工业物联操作系统，主要定位于**感**、**联**和**控**的层次，具备相当的节点级智能，将感知获得的数据传递给边缘设备和数据中心设备，具有对PLC等的控制能力，能对**知**提供支持，如下图所示。
|
||||
矽璓工业物联操作系统，主要定位于**感**、**联**和**控**的层次，支持接入市面上各种传感器，将感知获得的数据传递给边缘设备和数据中心设备，具有对PLC等的控制能力，能对**知**提供支持，如下图所示。
|
||||
|
||||
|
||||
|
||||
|
|
@ -44,8 +44,7 @@ XiUOS是一种工业物联网操作系统，目标是通过工业物联网的部
|
|||
|
||||
### 部署
|
||||
|
||||
XiUOS是面向工业领域多节点设备的网络化OS，其部署主要包括节点端的多节点集
|
||||
群和边缘端/云端的计算设施，如下图所示。
|
||||
XiUOS是面向工业领域多节点设备的网络化OS，其部署主要包括节点端的多节点集群和边缘端/云端的计算设施，如下图所示。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -554,7 +554,7 @@ int TestRealtime(int argc, char * argv[])
|
|||
* XiUOS在RISC-V K210 400MHz CPU主频上中断响应时间为 2.6 us低于sylixos的 3.612 us
|
||||
* 若进行同等1GHz主频换算，K210上的中断响应时间应为 1.016 us，XiUOS中断响应的效率比sylixos提高 2.5倍
|
||||
* 在ARM stm32f407 168MHz CPU主频中断响应时间 11.9 us高于1GHz主频测试的sylixos
|
||||
* 若进行同等1GHz主频换算,STM32F407上的中断响应时间应为 1.952 us，XiUOS的中断响应的效率比sylixos提高 0.8倍
|
||||
* 若进行同等1GHz主频换算，STM32F407上的中断响应时间应为 1.952 us，XiUOS的中断响应的效率比sylixos提高 0.8倍
|
||||
|
||||
由于XiUOS优化了中断响应的流程，减少了执行指令数量，因此，同等主频条件下，中断响应时间更短。
|
||||
|
||||
|
|
|
|||
|
|
@ -31,11 +31,11 @@ XiUOS 操作系统提供了独特的内存管理分配算法进行内存管理
|
|||
<span id="mm_heap_static_split"></span>
|
||||
|
||||
#### 静态内存划分
|
||||
静态内存包含2个链表，其中，每个链表都具有 block_size、total_count、free_count和free_list 这四个属性。
|
||||
静态内存包含2个链表，其中，每个链表都具有 block_size、total_count、free_count 和 free_list 这四个属性。
|
||||
* block_size 记录了当前链表中每个静态内存块的大小
|
||||
* total_count 记录了系统初始化之后分配给该链表中静态内存块的总个数
|
||||
* free_count 记录了该链表中还可以分配给用户静态内存块的个数
|
||||
* free_list 则真正指向各个空闲静态内存块
|
||||
* free_list 指向各个空闲静态内存块
|
||||
|
||||
下图为静态内存链表的具体情况，图中包括两个静态链表1和2。静态链表头1指向的内存池中存放的静态内存块的大小都是32字节，静态链表头2所指向的内存池中存放的静态内存块的大小都是64字节。此外，系统分别配置了静态链表头1和静态链表头2中静态内存块的total_count个数为256和128。因此，静态链表头1最多可以响应用户256次的小于32字节的内存请求，静态链表头2最多可以响应用户128次的介于33-64字节之间的内存请求，一旦对应的静态内存块分配完了，系统会向动态内存区域寻求内存空间分配。
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@
|
|||
|
||||
### 任务状态
|
||||
|
||||
XiUOS 中的任务在任意时刻都处于就绪（ready）、运行（running）、阻塞/挂起（suspend）、退出（quit）四种状态之一。状态之间的变化关系如下图所示。
|
||||
XiUOS 中的任务在任意时刻都处于就绪（ready）、运行（running）、阻塞/挂起（suspend）、退出（close）四种状态之一。状态之间的变化关系如下图所示。
|
||||
|
||||
<img src="./imagesrc/task_status.png" width =100%/>
|
||||
|
||||
|
|
@ -78,7 +78,7 @@ struct TaskDescriptor
|
|||
};
|
||||
```
|
||||
|
||||
其中，stack_point 指向任务堆栈的起始地址，task_dync_sched_member 包含与任务调度相关的信息，task_base_info 记录任务的基本信息，task_smp_info 统计与多处理器相关的信息，event_id_trigger / event_mode 用于实现事件集机制（详见[任务通信](#communication)），exstatus为任务调用内核接口时最近的错误码，即用户线程在使用内核接口时可能会执行失败，此时内核接口返回-1，具体的错误码被保存在exstatus成员中，且在下一次调用内核接口失败时被覆盖，link 用于组织内核中所有的任务。id 用于表示一个线程，Done提供所有的线程的操作函数，各复合成员的详细定义如下。
|
||||
其中，stack_point 指向任务堆栈的起始地址，task_dync_sched_member 包含与任务调度相关的信息，task_base_info 记录任务的基本信息，task_smp_info 统计与多处理器相关的信息，event_id_trigger / event_mode 用于实现事件集机制（详见[任务通信](#communication)），exstatus为任务调用内核接口时最近的错误码，即用户线程在使用内核接口时可能会执行失败，此时内核接口返回-1，具体的错误码被保存在成员变量exstatus中，且在下一次调用内核接口失败时被覆盖，link 用于组织内核中所有的任务。id 用于表示一个线程，Done提供所有的线程的操作函数，各复合成员的详细定义如下。
|
||||
* struct TaskDyncSchedMember
|
||||
```c
|
||||
struct TaskDyncSchedMember {
|
||||
|
|
@ -113,7 +113,7 @@ struct TaskDyncSchedMember {
|
|||
#define KTASK_CLOSE 0x04
|
||||
```
|
||||
|
||||
struct TaskDyncSchedMember结构用于记录与调度相关的信息。stat记录任务的当前状态，可以为初始化（KTASK_INIT）挂起（KTASK_SUSPEND）、就绪（KTASK_READY）、运行（KTASK_RUNNING）或退出（KTASK_CLOSE）。advance_cnt表示在配置成短作业预先调度时优先处理的时间片周期个数。cur_prio表示任务当前的优先级，用于优先级反转，该优先级可以高于任务创建时配置的优先级。origin_timeslice表示在时间片轮转调度时，任务每次运行的时间片。isolation_flag变量和指针isolation支持地址空间隔离，isolation_status用于标志内核服务的过程（1表示进入内核服务上下文）。sched_link和sched_avl构成的联合体为就绪队列节点，XiUOS中就绪队列可以组织为双链表（sched_link）或平衡二叉树（sched_avl）。task_timer为任务睡眠的计数器。
|
||||
TaskDyncSchedMember结构用于记录与调度相关的信息。stat记录任务的当前状态，可以为初始化（KTASK_INIT）挂起（KTASK_SUSPEND）、就绪（KTASK_READY）、运行（KTASK_RUNNING）或退出（KTASK_CLOSE）。advance_cnt表示在配置成短作业预先调度时优先处理的时间片周期个数。cur_prio表示任务当前的优先级，用于优先级反转，该优先级可以高于任务创建时配置的优先级。origin_timeslice表示在时间片轮转调度时，任务每次运行的时间片。isolation_flag变量和指针isolation支持地址空间隔离，isolation_status用于标志内核服务的过程（1表示进入内核服务上下文）。sched_link和sched_avl构成的联合体为就绪队列节点，XiUOS中就绪队列可以组织为双链表（sched_link）或平衡二叉树（sched_avl）。task_timer为任务睡眠的计数器。
|
||||
* struct TaskBaseInfo
|
||||
```c
|
||||
struct TaskBaseInfo {
|
||||
|
|
@ -126,7 +126,7 @@ struct TaskBaseInfo {
|
|||
};
|
||||
```
|
||||
|
||||
struct TaskBaseInfo结构记录了任务的基本属性，包括任务的名称（name）、入口函数（func_entry）和参数（func_param）、栈大小（stack_depth）、初始优先级（origin_prio）。
|
||||
TaskBaseInfo结构记录了任务的基本属性，包括任务的名称（name）、入口函数（func_entry）和参数（func_param）、栈大小（stack_depth）、初始优先级（origin_prio）。
|
||||
* struct TaskSmpInfo
|
||||
```c
|
||||
struct TaskSmpInfo {
|
||||
|
|
@ -135,7 +135,7 @@ struct TaskSmpInfo {
|
|||
uint16 critical_lock_cnt;
|
||||
};
|
||||
```
|
||||
struct TaskSmpInfo结构包含多处理器相关的信息，其成员分别表示该任务绑定的CPU ID与正在运行的CPU ID。
|
||||
TaskSmpInfo结构包含多处理器相关的信息，其成员分别表示该任务绑定的CPU ID与正在运行的CPU ID。
|
||||
<span id="api"></span>
|
||||
|
||||
### 任务函数接口
|
||||
|
|
@ -154,7 +154,7 @@ typedef struct utask UtaskType;
|
|||
int32_t UserTaskCreate(UtaskType task);
|
||||
```
|
||||
|
||||
该函数用于用户态的任务创建。任务的各个属性由struct utask结构表示，包括任务的名称、入口函数及参数、栈大小和优先级，在调用该函数时需要传入该结构的实例用于配置任务属性。任务创建成功后，内核会为其分配指定大小的栈及其他结构（如struct TaskDescriptor），并返回任务id。
|
||||
该函数用于用户态的任务创建。任务的各个属性由utask结构表示，包括任务的名称、入口函数及参数、栈大小和优先级，在调用该函数时需要传入该结构的实例用于配置任务属性。任务创建成功后，内核会为其分配指定大小的栈及其他结构（如struct TaskDescriptor），并返回任务id。
|
||||
|
||||
| 参数 | 描述 |
|
||||
| --- | --- |
|
||||
|
|
@ -205,7 +205,7 @@ x_err_t UserTaskCoreUnCombine(int32_t id);
|
|||
x_err_t UserTaskDelay(int32_t ms);
|
||||
```
|
||||
|
||||
该函数用于将当前任务挂起一定时间，单位为tick。挂起时间结束后，任务会进入就绪状态，等待系统调用。
|
||||
该函数用于将当前任务挂起一定时间，单位为ms。挂起时间结束后，任务会进入就绪状态，等待系统调用。
|
||||
|
||||
| 参数 | 描述 |
|
||||
| --- | --- |
|
||||
|
|
@ -294,7 +294,7 @@ x_err_t UserMsgQueueSendwait(int32_t mq, const void *buffer, size_t size, int32_
|
|||
x_err_t UserMsgQueueSend(int32_t mq, const void *buffer, size_t size);
|
||||
```
|
||||
|
||||
该函数用于向消息队列发送一个消息。若消息发送成功则返回EOK，若不成功（等待超时）则返回-ETIMEOUT。
|
||||
该函数用于向消息队列发送一个消息。若消息发送成功则返回EOK，若不成功则返回-ETIMEOUT。
|
||||
|
||||
| 参数 | 描述 |
|
||||
| --- | --- |
|
||||
|
|
@ -306,7 +306,7 @@ x_err_t UserMsgQueueSend(int32_t mq, const void *buffer, size_t size);
|
|||
x_err_t UserMsgQueueUrgentSend(int32_t mq, const void *buffer, size_t size);
|
||||
```
|
||||
|
||||
该函数用于向消息队列y优先发送一个消息。若消息发送成功则返回EOK，若不成功（等待超时）则返回-ETIMEOUT。
|
||||
该函数用于向消息队列优先发送一个消息。若消息发送成功则返回EOK，若不成功（等待超时）则返回-ETIMEOUT。
|
||||
|
||||
| 参数 | 描述 |
|
||||
| --- | --- |
|
||||
|
|
@ -359,7 +359,7 @@ struct Semaphore
|
|||
| --- | --- |
|
||||
| id | 信号量ID，用于唯一标识一个信号量 |
|
||||
| value | 信号量的当前值 |
|
||||
| pend_link | 挂起任务链表 |
|
||||
| pend_list | 挂起任务链表 |
|
||||
| link | 系统中所有信号量构成的链表 |
|
||||
|
||||
#### 信号量函数接口
|
||||
|
|
@ -581,7 +581,7 @@ x_err_t UserEventReinit(EventIdType event);
|
|||
|
||||
XiUOS 是一个支持多任务的操作系统，对任务的数量没有限制。在 XiUOS 中，每个任务都需要自己的堆栈，同时也可能会动态申请内存资源。任务在运行过程中发生内存溢出是 RTOS 系统中最常见的问题，所以限制任务的内存空间访问是保证 RTOS 稳定运行的关键。
|
||||
|
||||
ARM 和 RISC-V 在体系架构上都提供了内存访问的保护功能，可以通过对特定寄存器的硬编程实现对指定内存区域访问权限的设置。然而，现有的大多数物联网操作系统并没有使用体系结构提供的内存保护功能来对任务运行的地址空间进行隔离保护。XiUOS 充分考虑任务运行的安全问题，在不影响任务正常执行的情况下，对每个任务所允许访问的内存地址空间进行限制。除此之外，任务在动态申请内存、释放内存、内存共享时也提供隔离服务。
|
||||
ARM 和 RISC-V 在体系架构上都提供了内存访问的保护功能，可以通过对特定寄存器的硬编程实现对指定内存区域访问权限的设置。然而，现有的大多数物联网操作系统并没有使用体系结构提供的内存保护功能来对任务运行的地址空间进行隔离保护。XiUOS 充分考虑任务运行的安全问题，在不影响任务正常执行的情况下，对每个任务所允许访问的内存地址空间进行限制。除此之外，任务在动态申请内存、释放内存、内存共享时，XiUOS也将提供隔离服务。
|
||||
|
||||
XiUOS 任务隔离的总体设计思想是将物理内存地址空间划分为信任地址空间和非信任地址空间。XiUOS 的内核任务运行在信任地址空间，可以访问所有信任地址空间和非信任地址空间；XiUOS 的用户程序运行在非信任地址空间，通过”内核服务表“的方式访问内核任务提供的功能。
|
||||
|
||||
|
|
@ -987,7 +987,7 @@ int TestRealtime(int argc, char * argv[])
|
|||
```
|
||||
|
||||
|
||||
初始化GPIO18为输出模式，并初始化为低电平；在while（1）当中调用delay函数，每隔1个时间片发生一次调度。在下面的switch函数入口和出口位置操作GPIO。
|
||||
初始化GPIO18为输出模式，并初始化为低电平；在while(1)当中调用delay函数，每隔1个时间片发生一次调度。在下面的switch函数入口和出口位置操作GPIO。
|
||||
|
||||
```c
|
||||
void __attribute__((naked)) SwitchKtaskContext(x_ubase from, x_ubase to, struct TaskDescriptor *to_task)
|
||||
|
|
@ -1121,4 +1121,4 @@ void __attribute__((naked)) SaveMpie()
|
|||
## 使用场景
|
||||
|
||||
* 在多处理器设备上，多个任务可以并行运行，从而提高处理器的利用率。
|
||||
* 在一些中断驱动的应用中，如果中断需要处理的工作过于复杂，则可以创建一个任务专门用于处理相关工作，从而改善中断延迟。
|
||||
* 在一些中断驱动的应用中，如果中断需要处理的工作过于复杂，则可以创建一个任务专门用于处理相关工作，从而改善中断延迟。
|
||||
|
|
|
|||
Loading…
Reference in New Issue