ucosIII内核研究之Pend Lists
- 格式:pdf
- 大小:134.08 KB
- 文档页数:1
ucosiii移植原理
uCOSIII(MicroC/OS-III)是一款开源的实时操作系统(RTOS),适用于各种嵌入式系统和实时应用。
uCOSIII的移植原理主要包括以下几个方面:
1. 硬件抽象层(HAL):首先,需要针对特定硬件平台(如STM32、ARM、AVR等)编写硬件抽象层代码。
硬件抽象层的作用是将硬件平台的特性和接口抽象成统一的、易于操作的接口,以便于上层应用程序和实时操作系统进行调用。
2. 移植uCOSIII内核:将uCOSIII内核代码移植到目标硬件平台,主要包括以下几个步骤:
a. 配置uCOSIII内核:根据目标硬件平台的特性,配置uCOSIII内核的参数,如内存大小、任务数量等。
b. 修改内核代码:根据目标硬件平台的实际情况,修改内核代码,以适应不同硬件平台的需求。
这可能包括:修改内存管理代码、时钟管理代码、中断处理代码等。
c. 编写初始化代码:编写初始化代码,用于在系统启动时初始化
内核及其相关组件。
3. 移植uCOSIII的应用实例:根据项目需求,编写基于uCOSIII的应用实例。
这可能包括:编写驱动程序、编写通信协议、编写应用程序等。
4. 集成测试:将编写好的硬件抽象层、内核及应用实例集成到一起,进行系统测试和调试,确保整个系统的稳定性和可靠性。
5. 优化与调试:根据实际运行情况,对系统进行优化和调试,以提高系统的性能和资源利用率。
总之,uCOSIII的移植原理主要包括硬件抽象层的编写、uCOSIII内核的移植、应用实例的编写、集成测试以及优化与调试。
通过这些步骤,可以将uCOSIII成功移植到不同的硬件平台,并应用于各种实时系统。
ucosiii操作系统工作原理ucosiii是一种常用的嵌入式实时操作系统,它具有高度可靠性和高实时性的特点。
本文将介绍ucosiii操作系统的工作原理。
ucosiii操作系统是由美国Micrium公司开发的一种实时操作系统,它是用C语言编写的,可以运行在各种嵌入式系统中。
ucosiii采用了一种基于内核对象的任务管理机制,可以有效地管理系统中的各个任务,并提供了丰富的服务功能,如任务间通信、时间管理、内存管理等。
在ucosiii中,任务是操作系统的基本执行单元,每个任务都有自己的优先级和堆栈空间。
ucosiii使用了一种优先级抢占式的调度算法,即优先级高的任务可以抢占优先级低的任务的执行权。
这种调度算法可以保证高优先级任务的及时响应,并提高系统的实时性。
ucosiii的任务管理机制是通过任务控制块(TCB)来实现的。
每个任务都有一个对应的TCB,其中包含了任务的状态、优先级、堆栈指针等信息。
ucosiii通过不同的系统调用函数来管理任务的创建、删除、挂起、恢复等操作。
任务的切换是通过ucosiii的任务调度器来完成的,任务调度器会按照任务的优先级进行任务切换。
ucosiii提供了丰富的服务功能,其中包括任务间通信、时间管理、内存管理等。
任务间通信是通过信号量、邮箱、消息队列等机制来实现的,可以实现任务之间的数据共享和同步。
时间管理功能可以实现任务的定时执行和延时操作,可以满足实时系统对时间要求的需要。
内存管理功能可以对系统的内存进行分配和释放,提高系统的资源利用率。
ucosiii的内核对象是操作系统提供的一种资源管理机制,包括信号量、邮箱、消息队列等。
这些内核对象可以用于任务间的同步和通信,可以有效地避免资源竞争和数据冲突的问题。
ucosiii的工作原理可以总结为以下几个步骤:1. 初始化ucosiii操作系统,包括初始化任务控制块、任务堆栈等。
2. 创建任务,包括创建任务控制块、任务堆栈等。
实时多任务操作系统uCOS-III的特点实时多任务操作系统uCOS-III的特点uCOS-III是一个全新的实时内核,源于世界上最流行的实时内核uC/OS-II,除了提供熟悉的一系列系统服务,全面修订了API接口,使uC /OS-III更直观,更容易使用。
该产品可以广泛应用于通信,工业控制,仪器仪表,汽车电子,消费电子,办公自动化设备等的设计开发。
uCOS-III是一个抢占的多任务内核,支持优先级相同的任务轮询调度。
它可以移植到许多不同的CPU架构。
uC/OS-III是专为嵌入式系统设计,可以与应用程序代码一起固化到ROM中。
uCOS-III可在运行时配置实时操作系统。
所有内核对象,如任务,堆栈,信号量,事件标志组,消息队列,消息数量,互斥信号量,内存分区和定时器,由用户在运行时进行分配。
这可以防止在编译的时候分配过多资源。
uCOS-III允许有任意数量的任务,信号量,互斥信号量,事件标志,消息队列,定时器和内存分区(仅受限于处理器可用的RAM大小)。
uCOS-III添加了许多非常有用的功能,如:可嵌套互斥信号量,可嵌套任务暂停,不需要信号量可发信号给任务,不需要消息队列可发送消息给任务,等待多个内核对象,针对'errno'或其他任务的特定状况的任务注册,内置的性能测量,死锁预防,用户定义的钩函数等。
uCOS-III还内置了支持内核感知调试。
允许内核感知调试器以用户友好的方式检测和显示uC/OS-III的变量和数据结构,也允许uC/Probe在运行时显示和改变变量。
μCOS-III是可以抢占的多任务内核,始终运行进入就绪态的最重要的任务。
μC/OS-III支持无限数量的任务,并允许在运行时,监测堆栈增长的任务。
它还支持无限数量的优先级。
然而,通常情况下,对于大多数应用,32至256个不同的优先级是足够的。
对于今天的设计,特别有用的是具有同等优先级的轮转调度的任务。
μC/OS-III允许多个任务运行在同一优先级,每一个任务运行由用户指定的时间片。
UCOSIII(⼀)⼀,前后台系统和RTOS1,前后台系统早期嵌⼊式开发没有嵌⼊式操作系统的概念,直接操作裸机,在裸机上写程序,⽐如⽤51单⽚机基本就没有操作系统的概念。
通常把程序分为两部分:前台系统和后台系统。
简单的⼩系统通常是前后台系统,这样的程序包括⼀个死循环和若⼲个中断服务程序:应⽤程序是⼀个⽆限循环,循环中调⽤API函数完成所需的操作,这个⼤循环就叫做后台系统。
中断服务程序⽤于处理系统的异步事件,也就是前台系统。
前台是中断级,后台是任务级。
2,RTOSRTOS全称为: Real Time OS,就是实时操作系统,强调的是:实时性。
实时操作系统⼜分为硬实时和软实时。
硬实时要求在规定的时间内必须完成操作,硬实时系统不允许超时,在软实时⾥⾯处理过程超时的后果就没有那么严格。
在实时操作系统中,我们可以把要实现的功能划分为多个任务,每个任务负责实现其中的⼀部分,每个任务都是⼀个很简单的程序,通常是⼀个死循环。
RTOS操作系统: UCOS, FreeRTOS, RTX, RT-Thread, DJYOS等。
RTOS操作系统的核⼼内容在于:实时内核。
3,可剥夺型内核RTOS的内核负责管理所有的任务,内核决定了运⾏哪个任务,何时停⽌当前任务切换到其他任务,这个是内核的多任务管理能⼒。
多任务管理给⼈的感觉就好像芯⽚有多个CPU,多任务管理实现了CPU资源的最⼤化利⽤,多任务管理有助于实现程序的模块化开发,能够实现复杂的实时应⽤。
可剥夺内核顾名思义就是可以剥夺其他任务的CPU使⽤权,它总是运⾏就绪任务中的优先级最⾼的那个任务UCOS系统简介UCOS是Micrium公司出品的RTOS类实时操作系统, UCOS⽬前有两个版本:UCOSII和UCOSIII。
UCOSIII是⼀个可裁剪、可剥夺型的多任务内核,⽽且没有任务数限制。
UCOSIII提供了实时操作系统所需的所有功能,包括资源管理、同步、任务通信等。
UCOSIII是⽤C和汇编来写的,其中绝⼤部分都是⽤C语⾔编写的,只有极少数的与处理器密切相关的部分代码才是⽤汇编写的, UCOSIII结构简洁,可读性很强!最主要的是⾮常适合初次接触嵌⼊式实时操作系统学⽣、嵌⼊式系统开发⼈员和爱好者学习。
任务堆栈:存储任务中的调用的函数、局部变量、中断服务程序和CPU寄存器的值。
全局变量的保护:1.如果只在一个任务中写(或只有一个数据),而在其他任务中只是读取,则可以不用互斥型信号量,最多会造成读取的数据未被完全写完。
2.如果全局变量在多个任务中写,则需要用互斥型信号量保护,这样当有任务申请到互斥型信号量(保护不可重入的程序段)写数据时,其他任务的同一个互斥型信号量必须等待上一个任务的释放才可进行写。
3.如果全局变量在中断中写,则在其他任务中的全局变量的写操作要用临界段(禁止中断和禁止调度:保护不可被分割的程序段)保护。
(因为如果不关中断相当于中断的优先级最高,而且不能被像其他任务那样挂起。
)OS_CFG_ISR_POST_DEFERRED_EN为1临界段使用锁调度器方式;为0临界段使用禁中断方式(CPU_SR_ALLOC();OS_CRITICAL_ENTER();OS_CRITICAL_EXIT();OS_CRITICAL_EXIT_NO_SCHED(); OSSchedLockNestingCtr记录调度器被锁的次数)。
检测任务堆栈的使用情况:OS_CFG_STAT_TASK_STK_CHK_EN使能OS_ERRerr;CPU_STK_SIZE stk_free;CPU_STK_SIZE stk_used;OSTaskStkChk(&TaskBStkTCB,&stk_free,&stk_used,&e rr);中断中使用OSIntEnter();和OSIntExit();是为了退出中断后执行中断调度操作,如果中断中并未用到OSSemPost();等系统函数,则退出中断服务程序后不需要进行任务调度,就可以不在中断服务程序中使用OSIntEnter(); 和OSIntExit();。
(有时候用:CPU_CRITICAL_ENTER();OSIntNestingCtr++; CPU_CRITICAL_EXIT();替代OSIntEnter();)一、变量类型在cpu.h中是有关cpu变量的重新定义,还包括CPU_STK(CPU堆栈类型),和CPU_STK_SIZE(CPU堆栈类型的大小)的定义,CPU_SR(CPU状态寄存器的定义)。
ucosiii环境下事件组的使用方法
在使用ucosiii环境下的事件组时,我们需要了解其基本使用方法和操作步骤。
事件组是一种用于任务间通信和同步的机制,能够确保任务按照特定的顺序执行。
首先,我们需要创建一个事件组对象。
可以使用`OS_EVENT_GRP`类型的变量来定义事件组对象,并使用`OSEventCreate()`函数来创建事件组。
该函数会返回一
个指向事件组对象的指针。
接下来,我们可以使用`OSEventPend()`函数来等待事件组的某个特定事件发生。
该函数会挂起当前任务,直到指定的事件发生为止。
可以通过设置参数来指定等待的事件,如事件组对象指针、事件位掩码以及等待方式。
在其他任务中,我们可以使用`OSEventPost()`函数来触发事件组的特定事件。
该函数根据传入的事件位掩码,将对应的事件置为就绪状态。
然后,等待中的任务将会被唤醒,继续执行。
需要注意的是,在使用事件组时要考虑到任务的优先级。
高优先级任务可能会
抢占低优先级任务的资源,因此可能需要禁止任务抢占或者使用优先级继承来避免优先级翻转问题。
另外,为了确保事件组的正确使用,我们需要及时删除不再使用的事件组对象。
可以使用`OSDestoryEvent()`函数来销毁事件组对象,并释放相关的资源。
总之,通过了解ucosiii环境下事件组的使用方法,我们可以实现任务之间的同步和通信。
使用事件组可以有效地控制任务的执行顺序,并且能够提高系统的可靠性和响应性。
uCOSIII的消息队列处理机制(红黑联盟)在uC/OSIII中没有邮箱这个概念,而是统一合并到了消息队列MSG_Q。
因为消息队列可以看作是很多邮箱的集合,邮箱只是包含单个消息的消息队列。
在分析消息队列之前,必须要对消息的数据结构做一个彻底的分析。
消息队列对象和其他内核对象一样,它的结构定义很简单:下面看一下消息队列的结构体,记住这个结构体名字叫OS_Q:struct os_q { /* Message Queue */OS_OBJ_TYPE Type; /* Should be set to OS_OBJ_TYPE_Q */ CPU_CHAR *NamePtr; /* Pointer to Message Queue Name (NUL terminated ASCII) */OS_PEND_LIST PendList; /* List of tasks waiting on message queue */OS_MSG_Q MsgQ; /* List of messages */};typedef struct os_q OS_Q;在应用程序中创建消息队列的时候,就是要定义这样的一个结构体变量:举例创建过程如下:OS_Q taskq;void main(){OS_ERR err;OSQCreate ((OS_Q *)&p_q,(CPU_CHAR *)"my task Q",(OS_MSG_QTY) 10,(OS_ERR *)&err );}这样一个消息队列就创建好了。
这里要注意:OS_Q taskq;这句话应该是全局变量,因为通常都要在其他函数中访问。
有时不注意,很容易依照OSQCreate 的参数创建成这样的队列变量:OS_Q * taskq;注意这样创建的只是个指针,并没有实体,这样的定义在OSQCreate中参数传入时不会出错,但一运行就会进入hard fault,因为指针跑飞了。
【ucos-III教程】第11章 uCOS-III内核函数分析(上)第11章 uCOS-III内核函数分析(上)本期教程开始分析µCOS-III的内核函数,源码的分析采⽤先对源码进⾏注释,然后讲解函数实现的功能和相关的原理分析,最后是举⼀个例⼦(如果这个函数是供外部函数调⽤的)。
内核函数很重要,是学习任务管理,任务间通信机制的基础。
希望初学的同学认真学习,这部分应该算是µCOS-III的核⼼代码。
11.1系统配置⽂件11.2源码⽂件11.3µCOS-III初始化11.4µCOS-III启动11.5获取系统版本11.6空闲任务11.7临界段11.8安全关键IEC6150811.9任务切换11.10调度锁11.11 Round-Robin调度11.12总结11.1 系统配置⽂件下⾯先简单说明下µCOS-III中⼏个配置⽂件的作⽤,⽅便分析源码的时候查看,配置⽂件主要有以下⼏个:11.1.1 lib_cfg.h配置⽂件lib_cfg.h⽂件内容如下:#ifndef LIB_CFG_MODULE_PRESENT#define LIB_CFG_MODULE_PRESENT#define LIB_MEM_CFG_ARG_CHK_EXT_EN DEF_ENABLED#define LIB_MEM_CFG_OPTIMIZE_ASM_EN DEF_ENABLED#define LIB_MEM_CFG_ALLOC_EN DEF_ENABLED#define LIB_MEM_CFG_HEAP_SIZE 23u * 1024u#endiflib_cfg.h是⽤于给uC/LIB做配置的头⽂件。
如果程序中使⽤uC/LIB的话,需要调⽤函数Mem_Init()进⾏初始化。
11.1.2 os_cfg.h配置⽂件os_cfg.h⽂件中的内容如下:#ifndef OS_CFG_H#define OS_CFG_H#define OS_CFG_APP_HOOKS_EN 1u#define OS_CFG_ARG_CHK_EN 1u#define OS_CFG_CALLED_FROM_ISR_CHK_EN 1u#define OS_CFG_DBG_EN 1u#define OS_CFG_ISR_POST_DEFERRED_EN 0u#define OS_CFG_OBJ_TYPE_CHK_EN 1u#define OS_CFG_TS_EN 1u#define OS_CFG_PEND_MULTI_EN 1u#define OS_CFG_PRIO_MAX 64u#define OS_CFG_SCHED_LOCK_TIME_MEAS_EN 0u#define OS_CFG_SCHED_ROUND_ROBIN_EN 0u#define OS_CFG_STK_SIZE_MIN 64u#define OS_CFG_FLAG_EN 1u#define OS_CFG_FLAG_DEL_EN 1u#define OS_CFG_FLAG_MODE_CLR_EN 1u#define OS_CFG_FLAG_PEND_ABORT_EN 1u#define OS_CFG_MEM_EN 1u#define OS_CFG_MUTEX_EN 1u#define OS_CFG_MUTEX_DEL_EN 1u#define OS_CFG_MUTEX_PEND_ABORT_EN 1u#define OS_CFG_Q_EN 1u#define OS_CFG_Q_DEL_EN 1u#define OS_CFG_Q_FLUSH_EN 1u#define OS_CFG_Q_PEND_ABORT_EN 1u#define OS_CFG_SEM_EN 1u#define OS_CFG_SEM_DEL_EN 1u#define OS_CFG_SEM_PEND_ABORT_EN 1u#define OS_CFG_SEM_SET_EN 1u#define OS_CFG_STAT_TASK_EN 1u#define OS_CFG_STAT_TASK_STK_CHK_EN 1u#define OS_CFG_TASK_CHANGE_PRIO_EN 1u#define OS_CFG_TASK_DEL_EN 1u#define OS_CFG_TASK_Q_EN 1u#define OS_CFG_TASK_Q_PEND_ABORT_EN 1u#define OS_CFG_TASK_PROFILE_EN 1u#define OS_CFG_TASK_REG_TBL_SIZE 1u#define OS_CFG_TASK_SEM_PEND_ABORT_EN 1u#define OS_CFG_TASK_SUSPEND_EN 1u#define OS_CFG_TIME_DLY_HMSM_EN 1u#define OS_CFG_TIME_DLY_RESUME_EN 1u#define OS_CFG_TMR_EN 1u#define OS_CFG_TMR_DEL_EN 1u#endif这个配置⽂件⽐较的重要,主要⽤于µCOS-III源码中相关函数的配置。
UC/OS—III的常用资料整理任务堆栈:存储任务中的调用的函数、局部变量、中断服务程序和CPU寄存器的值。
全局变量的保护:1.如果只在一个任务中写(或只有一个数据),而在其他任务中只是读取,则可以不用互斥型信号量,最多会造成读取的数据未被完全写完。
2.如果全局变量在多个任务中写,则需要用互斥型信号量保护,这样当有任务申请到互斥型信号量(保护不可重入的程序段)写数据时,其他任务的同一个互斥型信号量必须等待上一个任务的释放才可进行写。
3.如果全局变量在中断中写,则在其他任务中的全局变量的写操作要用临界段(禁止中断和禁止调度:保护不可被分割的程序段)保护。
(因为如果不关中断相当于中断的优先级最高,而且不能被像其他任务那样挂起。
)OS_CFG_ISR_POST_DEFERRED_EN为1临界段使用锁调度器方式;为0临界段使用禁中断方式(CPU_SR_ALLOC();存放中断的变量OS_CRITICAL_ENTER();OS_CRITICAL_EXIT();OS_CRITICAL_EXIT_NO_SCHED();OSSchedLockNestingCtr记录调度器被锁的次数)。
检测任务堆栈的使用情况:OS_CFG_STAT_TASK_STK_CHK_EN使能OS_ERRerr;CPU_STK_SIZE stk_free;CPU_STK_SIZE stk_used;OSTaskStkChk(&TaskBStkTCB,&stk_free,&stk_used,&err);中断中使用OSIntEnter(); 和OSIntExit();是为了退出中断后执行中断调度操作,如果中断中并未用到OSSemPost();等系统函数,则退出中断服务程序后不需要进行任务调度,就可以不在中断服务程序中使用OSIntEnter(); 和OSIntExit();。
(有时候用:CPU_CRITICAL_ENTER();OSIntNestingCtr++;CPU_CRITICAL_EXIT();替代OSIntEnter();)一、变量类型在cpu.h中是有关cpu变量的重新定义,还包括CPU_STK(CPU堆栈类型),和CPU_STK_SIZE(CPU堆栈类型的大小)的定义,CPU_SR(CPU状态寄存器的定义)。
uC/OS iii对消息队列的改进摘要:在uc/os-ii的基础上,uc/os-iii对消息队列做了较大的改进,并新增一项特有的功能:任务内建消息队列。
任务内建消息队列不仅可以降低消息队列占用的存储空间、提高消息与任务间的通信效率,还能实现消息与任务的相互一一对应,从而保证了系统的健壮性。
关键词:消息队列;任务内建消息队列;嵌入式操作系统depth analysis of uc/os-iii’s message queue and task built-in message queuequ huan-yu,chen li-ping, tang xiao-mei(school of mathematics,physics and informaiton engineering, jiaxing university,jiaxing 314001,china)abstract: on the basis of uc/os-ii, uc/os-iii has made a great improvement on it’s message queue function,and add a unique function: the task built-in message queue.task built-in message queue can not only reduce the occupancy storage space of message queue、improve the communication efficiency of messages and tasks, but also can realize one-to-one correspondence between tasks and messages,ensure the system’s robustnesskey words: message queues;task built-in message queue;embedded operation system多任务调度系统中,任务间互相通信的方法可以是共享全局变量、共享内存、信号量等。
什么是PendSV?PendSV是可悬起异常,如果我们把它配置最低优先级,那么如果同时有多个异常被触发,它会在其他异常执行完毕后再执行,而且任何异常都可以中断它。
更详细的内容在《Cortex-M3 权威指南》里有介绍,下面我摘抄了一段。
OS 可以利用它“缓期执行”一个异常——直到其它重要的任务完成后才执行动作。
悬起PendSV 的方法是:手工往NVIC的PendSV悬起寄存器中写1。
悬起后,如果优先级不够高,则将缓期等待执行。
PendSV的典型使用场合是在上下文切换时(在不同任务之间切换)。
例如,一个系统中有两个就绪的任务,上下文切换被触发的场合可以是:1、执行一个系统调用2、系统滴答定时器(SYSTICK)中断,(轮转调度中需要)让我们举个简单的例子来辅助理解。
假设有这么一个系统,里面有两个就绪的任务,并且通过SysTick异常启动上下文切换。
但若在产生SysTick 异常时正在响应一个中断,则SysTick异常会抢占其ISR。
在这种情况下,OS是不能执行上下文切换的,否则将使中断请求被延迟,而且在真实系统中延迟时间还往往不可预知——任何有一丁点实时要求的系统都决不能容忍这种事。
因此,在CM3 中也是严禁没商量——如果OS 在某中断活跃时尝试切入线程模式,将触犯用法fault异常。
为解决此问题,早期的OS 大多会检测当前是否有中断在活跃中,只有在无任何中断需要响应时,才执行上下文切换(切换期间无法响应中断)。
然而,这种方法的弊端在于,它可以把任务切换动作拖延很久(因为如果抢占了IRQ,则本次SysTick在执行后不得作上下文切换,只能等待下一次SysTick异常),尤其是当某中断源的频率和SysTick异常的频率比较接近时,会发生“共振”,使上下文切换迟迟不能进行。
现在好了,PendSV来完美解决这个问题了。
PendSV异常会自动延迟上下文切换的请求,直到其它的ISR都完成了处理后才放行。
为实现这个机制,需要把PendSV编程为最低优先级的异常。
ucosIII内核研究之TickListMAGIC 710B5A701Ticklist 采用轮辐方式,管理在OSCfg_TickWheel 中OS_TICK_SPOKE OSCfg_TickWheel [OS_CFG_TICK_WHEEL_SIZE];OS_CFG_TICK_WHEEL_SIZE = 11u = OSCfg_TickWheelSize OS_TICK_SPOKE2任务TCB与TickWheel关系OSTickCtr 当前Tick数,时基中断产生以后自增加数据类型CPU_INT32U,以1s = 1000Tick,最大值4294967296 tick /1000/60/60/24 = 49.7day(溢出)p_tcb->TickCtrMatch 延时等到的Tickp_tcb->TickRemain 延时剩余Tick,插入的任务,计算出最后等到的Tick点,取模找到对应的wheel 组,再插入任务到list中p_tcb->TickCtrMatch % OSCfg_TickWheelSize);3Spoke0123456789101101234567Time 1234567891011121314151617181920每一个时间tick都有对应的spoke,所以添加任务到对应wheel 组中,到等待的tick来临就会进入该spoke处理相当于将所有Tick分组,也对等待的任务TCB分组并且uCOSIII在插入任务TCB时候,采用按序排列插入,先发生的事件在前,即按TICK从小到大排列,* FirstPtr指向等待时间最短的任务,在更新时,每次只扫描查询第一个任务,以便提高效率4调用关系Ticklist机制OS_TCB * FirstPtr;OS_OBJ_QTYNbrEntriesMax;OS_OBJ_QTY NbrEntries;OS_TickListUpdate() OSTickCtr++;计数增加从OSCfg_TickWheel[]中找到spokewhile (list 中是否有TCB 时间到)spoke->FirstPtr;获取TCBswitch (p_tcb->TaskState)case 根据任务状态作做处理p_tcb = list 中下一个TCB返回void OS_TickT ask(void *p_arg)OS_TickListUpdate OS_TickListInsert OS_TaskBlockOSTimeDlyOSTimeDlyHMSMOS_PendMultiWaitOS_PendOS_FlagBlockOSMutexPendOSQPendOSSemPend OSTaskQPend OSTaskSemPend OSFlagPend voidOS_TickListRemove(OS_TCB *p_tcb)OSTimeDlyResumeOS_TickListUpdateOSTaskDelOS_TaskRdyOS_Post OS_PendObjDelOS_PendAbort void OS_TickTask(void *p_arg)OSMutexPost OS_QPost OS_SemPost OS_TaskQPostOS_TaskSemPostOSFlagDelOSMutexDelOSQDelOSSemDel OSFlagPendAbort OSMutexPendAbort OSQPendAbort OSSemPendAbort OSTaskQPendAbort OSTaskSemPendAbort。
uC/OS—III外建消息队列及任务内建消息队列深度解析作者:屈环宇陈丽萍唐晓媚来源:《电脑知识与技术》2013年第04期摘要:在uC/OS-II的基础上,uC/OS-III对消息队列做了较大的改进,并新增一项特有的功能:任务内建消息队列。
任务内建消息队列不仅可以降低消息队列占用的存储空间、提高消息与任务间的通信效率,还能实现消息与任务的相互一一对应,从而保证了系统的健壮性。
关键词:消息队列;任务内建消息队列;嵌入式操作系统中图分类号:TP313 文献标识码:A 文章编号:1009-3044(2013)04-0908-03Depth Analysis Of uC/OS-III's Message Queue and Task Built-in Message QueueQU Huan-yu,CHEN Li-ping, TANG Xiao-mei(School of Mathematics,Physics and Informaiton Engineering, Jiaxing University,Jiaxing 314001,China)Abstract: On the basis of uC/OS-II, uC/OS-III has made a great improvement on it's message queue function,and add a unique function: the task built-in message queue.Task built-in message queue can not only reduce the occupancy storage space of message queue、improve the communication efficiency of messages and tasks, but also can realize one-to-one correspondence between tasks and messages,ensure the system's robustnessKey words: message queues;task built-in message queue;embedded operation system多任务调度系统中,任务间互相通信的方法可以是共享全局变量、共享内存、信号量等。
目录第一部分:μC/OS-III 实时内核μC/OS-III的演变—Jack Ganssle前言第1章概述1-1前后台系统1-2实时内核1-3RTOS(实时操作系统)1-4μC/OS-III1-5μC/OS,μC/OS-II,μC/OS-III特性比较1-6关于本书1-7μC/Probe 调试软件工具1-8本书的常用约定1-9各章内容第2章目录和文件2-1 应用代码2-2 CPU2-3 板级支持包(BSP)2-4 μC/OS-III,与CPU无关的源代码2-5 μC/OS-III,与CPU相关的源代码2-6 μC/CPU,与CPU相关的源代码2-7 μC/LIB,可移植的库函数2-8 小结第3章初识μC/OS-III3-1 单任务应用程序3-2 有内核对象参与的多任务应用程序第4章临界段代码4-1 关中断4-1-1 测量中断关闭时间4-2 给调度器上锁4-2-1 测量调度器锁定时间4-3 μC/OS-III的某些功能会导致临界段代码长度增加4-4 小结第5章任务管理5-1 任务优先级的分配5-2 栈空间大小的确定5-3 任务栈溢出检测5-4 任务管理函数5-5 任务管理的内部原理5-5-1 任务状态5-5-2 任务控制块TCB5-6 系统内部任务5-6-1 空闲任务(OS_IdleTask(),os_core.c)5-6-2 时钟节拍任务(OS_TickTask(), os_tick.c)5-6-3 统计任务(OS_StatTask(),os_stat.c)5-6-4 定时任务(OS_TmrTask(),os_tmr.c)5-6-5 中断服务管理任务(OS_IntQTask(),os_int.c)5-7小结第6章任务就绪表6-1 优先级6-2 就绪任务列表6-3 向就绪任务列表中增加任务6-4小结第7章任务调度7-1 可剥夺型调度7-2 调度点7-3 时间片轮转调度7-4 调度的实现细节7-4-1 OSSched()7-4-2 OSIntExit()7-4-3 OS_SchedRoundRobin()7-5 小结第8章任务切换8-1 OSCtxSw()8-2 OSIntCtxSw()8-3小结第9章中断管理9-1 CPU的中断处理9-2 典型的μC/OS-III中断服务程序9-3 无需内核参与的中断服务程序9-4 多中断优先级的处理器9-5 所有中断源共用中断服务程序9-6 每个中断源都有专用中断服务程序9-7 直接发布和延时发布9-7-1 直接发布9-7-2 延迟发布9-8 直接发布模式和延迟发布模式的对比9-9 时钟节拍(也称为系统节拍)9-10小结第10章任务挂起表10-1 小结第11章时间管理11-1 OSTimeDly()11-2 OSTimeDlyHMSM()11-3 OSTimeDlyResume()11-4 OSTimeSet() 和OSTimeGet()11-5 OSTimeTick()11-6 小结第12章定时器管理12-1 单次定时器12-2 周期定时器(无初始延迟)12-3 周期定时器(有初始延迟)12-4 定时器管理内部机制12-4-1 定时器管理内部机制——定时器状态12-4-2 定时器管理内部机制——OS_TMR12-4-3 定时器管理内部机制——定时器任务12-4-4 定时器管理内部机制——定时器列表12-5 总结第13章资源管理13-1 关中断/开中断13-2 给调度器上锁/开锁13-3 信号量13-3-1 二进制信号量13-3-2 计数型信号量13-3-3 使用信号量的注意事项13-3-4 (用来共享资源的)信号量内部结构13-3-5 优先级反转13-4 互斥型信号量(MUTEX)13-4-1 互斥型信号量内部结构13-5 何时可以用普通信号量替代互斥型信号量13-6 死锁(或称抱死)13-7 小结第14章任务同步14-1 信号量14-1-1 单向同步14-1-2 信用记录14-1-3 多个任务等待同一个信号量14-1-4 信号量的内部结构(以同步为目的)14-2 任务信号量14-2-1 等待任务信号量14-2-2 发布任务信号量14-2-3 双向同步14-3 事件标志组14-3-1 使用事件标志14-3-2 事件标志的内部结构14-4 与多任务同步14-5 小结第15章消息传递15-1 消息15-2 消息队列15-3 任务内建的消息队列15-4 双向同步15-5 流量控制(flow control)15-6 保持数据的可见性15-7 使用消息队列15-8 客户端和服务器15-9 消息队列内部的细节15-10 小结第16 章同时等待多个内核对象16-1 小结第17章存储管理17-1 创建存储分区17-2 从分区中获得存储块17-3 将存储块归还到分区中17-4 使用存储分区17-5 小结第18章移植µC/OS-Ⅲ18-1 约定18-2 μC/CPU18-2-1 CPU_BSP.H18-2-2 CPU_DEF.H18-2-3 CPU_CFG.H18-2-4 CPU_CORE.C18-2-5 CPU_CORE.H18-2-6 CPU.H18-2-7 CPU_C.C18-2-8 CPU_A.ASM18-3 μC/OS-III移植18-3-1 OS_CPU.H18-3-2 OS_CPU_C.C18-3-3 OS_CPU_A.ASM18-3-4 OS_CPU_A.INC18-4 板级支持包(BSP)18-4-1 BSP.C和BSP.H18-4-2 BSP_INT.C和BSP_INT.H18-5 移植的测试18-5-1 创建一个简单的测试工程18-5-2 验证任务级任务切换18-5-3 验证中断级任务切换18-6 小结第19章程序运行时的各类统计信息19-1程序运行时的总体统计19-2 任务运行时的统计19-3 程序运行时和内核对象相关的统计信息19-4 OS_DBG.C –统计19-5 OS_CFG_APP. C –统计19-6 小结附录A μC/OS-III API参考手册A-1 任务管理A-2 时间管理A-3 互斥型信号量——资源管理A-4 事件标志组——同步A-5 信号量——同步A-6 任务信号量——同步A-7 消息队列——消息传递A-8 任务消息队列——消息传递A-9 等待多个对象A-10 定时器A-11 固定大小的存储分区——存储管理A-12 OSCtxSw()A-13 OSFlagCreate()A-14 OSFlagDel()A-15 OSFlagPend()A-16 OSFlagPendAbort()A-17 OSFlagPendGetFlagsRdy()A-18 OSFlagPost()A-19 OSIdleTaskHook()A-20 OSInit()A-21 OSInitHook()A-22 OSIntCtxSw()A-23 OSIntEnter()A-24 OSIntExit()A-25 OSMemCreate()A-26 OSMemGet()A-27 OSMemPut()A-28 OSMutexCreate()A-29 OSMutexDel()A-30 OSMutexPend()A-31 OSMutexPendAbort()A-32 OSMutexPost()A-33 OSPendMulti()A-34 OSQCreate()A-35 OSQDel()A-36 OSQFlush()A-36 OSQPend()A-38 OSQPendAbort()A-32 OSQPost()A-41 OSSched()A-42 OSSchedLock()A-43 OSSchedRoundRobinCfg() A-44 OSSchedRoundRobinYield() A-45 OSSchedUnlock()A-46 OSSemCreate()A-47 OSSemDel()A-48 OSSemPend()A-49 OSSemPendAbort()A-50 OSSemPost()A-51 OSSemSet()A-52 OSStart()A-53 OSStartHighRdy()A-54 OSStatReset()A-55 OSStatTaskCPUUsageInit() A-56 OSStatTaskHook()A-57 OSTaskChangePrio()A-58 OSTaskCreate()A-59 OSTaskCreateHook()A-60 OSTaskDel()A-61 OSTaskDelHook()A-62 OSTaskQFlush()A-63 OSTaskQPend()A-64 OSTaskQPendAbort()A-65 OSTaskQPost()A-66 OSTaskRegGet()A-67 OSTaskRegSet()A-68 OSTaskReturnHook()A-69 OSTaskResume()A-70 OSTaskSemPend()A-71 OSTaskSemPendAbort()A-72 OSTaskSemPost()A-73 OSTaskSemSet()74 OSStatTaskHook()A-75 OSTaskStkChk()A-76 OSTaskStkInit()A-77 OSTaskSuspend()A-78 OSTaskSwHook()A-79 OSTaskTimeQuantaSet()A-80 OSTickISR()A-81 OSTimeDly()A-82 OSTimeDlyHMSM()A-83 OSTimeDlyResume()A-84 OSTimeGet()A-85 OSTimeSet()A-86 OSTimeTick()A-87 OSTimeTickHook()A-88 OSTmrCreate()A-89 OSTmrDel()A-90 OSTmrRemainGet()A-91 OSTmrStart()A-92 OSTmrStateGet()A-93 OSTmrStop()A-94 OSVersion()附录B μC/OS-III配置手册B-1 μC/OS-III的功能(os_cfg.h)B-2μC/OS-III的数据类型(os_type.h)B-3 μC/OS-III的堆栈、池和其他数据类型(os_cfg_app.h)附录C从μC/OS-II 迁移到μC/OS-IIIC-1源文件名称和内容的差异C-2编程约定的变化C-3变量名称的变化C-4 API的变化C-4-1事件标志C-4-2消息邮箱C-4-3存储管理C-4-4互斥型信号量C-4-5消息队列C-4-6信号量C-4-7任务管理C-4-8时间管理C-4-9定时器管理C-4-10其他C-4-11介入函数与系统移植附录D MISRA-C:2004和μC/OS-III D-1 MISRA-C:2004,规则8.5 (强制)D-2 MISRA-C:2004,规则8.12(强制)D-3 MISRA-C:2004,规则14.7 (强制)D-4 MISRA-C:2004,规则15.2 (强制)D-5 MISRA-C:2004,规则17.4 (强制)附录E 参考文献附录F μC /OS-III许可政策致中国读者这本书是很多人多年辛勤劳动的结晶,讲述的是一个最早于1992年发布的实时内核的第三代。
目录第一部分:μC/OS-III 实时内核μC/OS-III的演变—Jack Ganssle前言第1章概述1-1前后台系统1-2实时内核1-3RTOS(实时操作系统)1-4μC/OS-III1-5μC/OS,μC/OS-II,μC/OS-III特性比较1-6关于本书1-7μC/Probe 调试软件工具1-8本书的常用约定1-9各章内容第2章目录和文件2-1 应用代码2-2 CPU2-3 板级支持包(BSP)2-4 μC/OS-III,与CPU无关的源代码2-5 μC/OS-III,与CPU相关的源代码2-6 μC/CPU,与CPU相关的源代码2-7 μC/LIB,可移植的库函数2-8 小结第3章初识μC/OS-III3-1 单任务应用程序3-2 有内核对象参与的多任务应用程序第4章临界段代码4-1 关中断4-1-1 测量中断关闭时间4-2 给调度器上锁4-2-1 测量调度器锁定时间4-3 μC/OS-III的某些功能会导致临界段代码长度增加4-4 小结第5章任务管理5-1 任务优先级的分配5-2 栈空间大小的确定5-3 任务栈溢出检测5-4 任务管理函数5-5 任务管理的内部原理5-5-1 任务状态5-5-2 任务控制块TCB5-6 系统内部任务5-6-1 空闲任务(OS_IdleTask(),os_core.c)5-6-2 时钟节拍任务(OS_TickTask(), os_tick.c)5-6-3 统计任务(OS_StatTask(),os_stat.c)5-6-4 定时任务(OS_TmrTask(),os_tmr.c)5-6-5 中断服务管理任务(OS_IntQTask(),os_int.c)5-7小结第6章任务就绪表6-1 优先级6-2 就绪任务列表6-3 向就绪任务列表中增加任务6-4小结第7章任务调度7-1 可剥夺型调度7-2 调度点7-3 时间片轮转调度7-4 调度的实现细节7-4-1 OSSched()7-4-2 OSIntExit()7-4-3 OS_SchedRoundRobin()7-5 小结第8章任务切换8-1 OSCtxSw()8-2 OSIntCtxSw()8-3小结第9章中断管理9-1 CPU的中断处理9-2 典型的μC/OS-III中断服务程序9-3 无需内核参与的中断服务程序9-4 多中断优先级的处理器9-5 所有中断源共用中断服务程序9-6 每个中断源都有专用中断服务程序9-7 直接发布和延时发布9-7-1 直接发布9-7-2 延迟发布9-8 直接发布模式和延迟发布模式的对比9-9 时钟节拍(也称为系统节拍)9-10小结第10章任务挂起表10-1 小结第11章时间管理11-1 OSTimeDly()11-2 OSTimeDlyHMSM()11-3 OSTimeDlyResume()11-4 OSTimeSet() 和OSTimeGet()11-5 OSTimeTick()11-6 小结第12章定时器管理12-1 单次定时器12-2 周期定时器(无初始延迟)12-3 周期定时器(有初始延迟)12-4 定时器管理内部机制12-4-1 定时器管理内部机制——定时器状态12-4-2 定时器管理内部机制——OS_TMR12-4-3 定时器管理内部机制——定时器任务12-4-4 定时器管理内部机制——定时器列表12-5 总结第13章资源管理13-1 关中断/开中断13-2 给调度器上锁/开锁13-3 信号量13-3-1 二进制信号量13-3-2 计数型信号量13-3-3 使用信号量的注意事项13-3-4 (用来共享资源的)信号量内部结构13-3-5 优先级反转13-4 互斥型信号量(MUTEX)13-4-1 互斥型信号量内部结构13-5 何时可以用普通信号量替代互斥型信号量13-6 死锁(或称抱死)13-7 小结第14章任务同步14-1 信号量14-1-1 单向同步14-1-2 信用记录14-1-3 多个任务等待同一个信号量14-1-4 信号量的内部结构(以同步为目的)14-2 任务信号量14-2-1 等待任务信号量14-2-2 发布任务信号量14-2-3 双向同步14-3 事件标志组14-3-1 使用事件标志14-3-2 事件标志的内部结构14-4 与多任务同步14-5 小结第15章消息传递15-1 消息15-2 消息队列15-3 任务内建的消息队列15-4 双向同步15-5 流量控制(flow control)15-6 保持数据的可见性15-7 使用消息队列15-8 客户端和服务器15-9 消息队列内部的细节15-10 小结第16 章同时等待多个内核对象16-1 小结第17章存储管理17-1 创建存储分区17-2 从分区中获得存储块17-3 将存储块归还到分区中17-4 使用存储分区17-5 小结第18章移植µC/OS-Ⅲ18-1 约定18-2 μC/CPU18-2-1 CPU_BSP.H18-2-2 CPU_DEF.H18-2-3 CPU_CFG.H18-2-4 CPU_CORE.C18-2-5 CPU_CORE.H18-2-6 CPU.H18-2-7 CPU_C.C18-2-8 CPU_A.ASM18-3 μC/OS-III移植18-3-1 OS_CPU.H18-3-2 OS_CPU_C.C18-3-3 OS_CPU_A.ASM18-3-4 OS_CPU_A.INC18-4 板级支持包(BSP)18-4-1 BSP.C和BSP.H18-4-2 BSP_INT.C和BSP_INT.H18-5 移植的测试18-5-1 创建一个简单的测试工程18-5-2 验证任务级任务切换18-5-3 验证中断级任务切换18-6 小结第19章程序运行时的各类统计信息19-1程序运行时的总体统计19-2 任务运行时的统计19-3 程序运行时和内核对象相关的统计信息19-4 OS_DBG.C –统计19-5 OS_CFG_APP. C –统计19-6 小结附录A μC/OS-III API参考手册A-1 任务管理A-2 时间管理A-3 互斥型信号量——资源管理A-4 事件标志组——同步A-5 信号量——同步A-6 任务信号量——同步A-7 消息队列——消息传递A-8 任务消息队列——消息传递A-9 等待多个对象A-10 定时器A-11 固定大小的存储分区——存储管理A-12 OSCtxSw()A-13 OSFlagCreate()A-14 OSFlagDel()A-15 OSFlagPend()A-16 OSFlagPendAbort()A-17 OSFlagPendGetFlagsRdy()A-18 OSFlagPost()A-19 OSIdleTaskHook()A-20 OSInit()A-21 OSInitHook()A-22 OSIntCtxSw()A-23 OSIntEnter()A-24 OSIntExit()A-25 OSMemCreate()A-26 OSMemGet()A-27 OSMemPut()A-28 OSMutexCreate()A-29 OSMutexDel()A-30 OSMutexPend()A-31 OSMutexPendAbort()A-32 OSMutexPost()A-33 OSPendMulti()A-34 OSQCreate()A-35 OSQDel()A-36 OSQFlush()A-36 OSQPend()A-38 OSQPendAbort()A-32 OSQPost()A-41 OSSched()A-42 OSSchedLock()A-43 OSSchedRoundRobinCfg() A-44 OSSchedRoundRobinYield() A-45 OSSchedUnlock()A-46 OSSemCreate()A-47 OSSemDel()A-48 OSSemPend()A-49 OSSemPendAbort()A-50 OSSemPost()A-51 OSSemSet()A-52 OSStart()A-53 OSStartHighRdy()A-54 OSStatReset()A-55 OSStatTaskCPUUsageInit() A-56 OSStatTaskHook()A-57 OSTaskChangePrio()A-58 OSTaskCreate()A-59 OSTaskCreateHook()A-60 OSTaskDel()A-61 OSTaskDelHook()A-62 OSTaskQFlush()A-63 OSTaskQPend()A-64 OSTaskQPendAbort()A-65 OSTaskQPost()A-66 OSTaskRegGet()A-67 OSTaskRegSet()A-68 OSTaskReturnHook()A-69 OSTaskResume()A-70 OSTaskSemPend()A-71 OSTaskSemPendAbort()A-72 OSTaskSemPost()A-73 OSTaskSemSet()74 OSStatTaskHook()A-75 OSTaskStkChk()A-76 OSTaskStkInit()A-77 OSTaskSuspend()A-78 OSTaskSwHook()A-79 OSTaskTimeQuantaSet()A-80 OSTickISR()A-81 OSTimeDly()A-82 OSTimeDlyHMSM()A-83 OSTimeDlyResume()A-84 OSTimeGet()A-85 OSTimeSet()A-86 OSTimeTick()A-87 OSTimeTickHook()A-88 OSTmrCreate()A-89 OSTmrDel()A-90 OSTmrRemainGet()A-91 OSTmrStart()A-92 OSTmrStateGet()A-93 OSTmrStop()A-94 OSVersion()附录B μC/OS-III配置手册B-1 μC/OS-III的功能(os_cfg.h)B-2μC/OS-III的数据类型(os_type.h)B-3 μC/OS-III的堆栈、池和其他数据类型(os_cfg_app.h)附录C从μC/OS-II 迁移到μC/OS-IIIC-1源文件名称和内容的差异C-2编程约定的变化C-3变量名称的变化C-4 API的变化C-4-1事件标志C-4-2消息邮箱C-4-3存储管理C-4-4互斥型信号量C-4-5消息队列C-4-6信号量C-4-7任务管理C-4-8时间管理C-4-9定时器管理C-4-10其他C-4-11介入函数与系统移植附录D MISRA-C:2004和μC/OS-III D-1 MISRA-C:2004,规则8.5 (强制)D-2 MISRA-C:2004,规则8.12(强制)D-3 MISRA-C:2004,规则14.7 (强制)D-4 MISRA-C:2004,规则15.2 (强制)D-5 MISRA-C:2004,规则17.4 (强制)附录E 参考文献附录F μC /OS-III许可政策致中国读者这本书是很多人多年辛勤劳动的结晶,讲述的是一个最早于1992年发布的实时内核的第三代。
任务堆栈:存储任务中的调用的函数、局部变量、中断服务程序和CPU寄存器的值。
全局变量的保护:1.如果只在一个任务中写(或只有一个数据),而在其他任务中只是读取,则可以不用互斥型信号量,最多会造成读取的数据未被完全写完。
2.如果全局变量在多个任务中写,则需要用互斥型信号量保护,这样当有任务申请到互斥型信号量(保护不可重入的程序段)写数据时,其他任务的同一个互斥型信号量必须等待上一个任务的释放才可进行写。
3.如果全局变量在中断中写,则在其他任务中的全局变量的写操作要用临界段(禁止中断和禁止调度:保护不可被分割的程序段)保护。
(因为如果不关中断相当于中断的优先级最高,而且不能被像其他任务那样挂起。
)OS_CFG_ISR_POST_DEFERRED_EN为1临界段使用锁调度器方式;为0临界段使用禁中断方式(CPU_SR_ALLOC();OS_CRITICAL_ENTER();OS_CRITICAL_EXIT();OS_CRITICAL_EXIT_NO_SCHED();OSSchedLockNestingCtr记录调度器被锁的次数)。
检测任务堆栈的使用情况:OS_CFG_STAT_TASK_STK_CHK_EN使能OS_ERRerr;CPU_STK_SIZE stk_free;CPU_STK_SIZE stk_used;OSTaskStkChk(&TaskBStkTCB,&stk_free,&stk_use d,&err);中断中使用OSIntEnter();和OSIntExit();是为了退出中断后执行中断调度操作,如果中断中并未用到OSSemPost();等系统函数,则退出中断服务程序后不需要进行任务调度,就可以不在中断服务程序中使用OSIntEnter(); 和OSIntExit();。
(有时候用:CPU_CRITICAL_ENTER();OSIntNestingCtr++;CPU_CRITICAL_EXIT();替代OSIntEnter();)一、变量类型在中是有关cpu变量的重新定义,还包括CPU_STK (CPU堆栈类型),和CPU_STK_SIZE(CPU堆栈类型的大小)的定义,CPU_SR(CPU状态寄存器的定义)。
浅谈基于STM32的μCOS-Ⅲ系统移植的设计论文uC/OS-III(Micro C OS Three 微型的C 语言编写的操作系统第3版)是一个可升级的,可固化的,基于优先级的实时内核。
它对任务的个数无限制。
uC/OS-III 是一个第3 代的系统内核,支持现代的实时内核所期待的大部分功能。
例如资源管理,同步,任务间的通信等等。
然而,uC/OS-III 提供的特色功能在其它的实时内核中是找不到的,比如说完备的运行时间测量性能,直接地发送信号或者消息到任务,任务可以同时等待多个内核对象等。
以下是店铺为大家精心准备的:浅谈基于STM32的μCOS-Ⅲ系统移植的设计相关论文。
内容仅供参考,欢迎阅读!浅谈基于STM32的μCOS-Ⅲ系统移植的设计全文如下:引言随着人类社会经济的不断发展,科研领域不断的拓宽,嵌入式系统产品渐渐完善,并在全世界各行业得到广泛应用。
通过移植嵌入式操作系统,计算机可以更好的管理内存,并且在很大程度上实现了系统的实时性。
μCOS-Ⅲ作为一个微型实时操作系统,包括了一个操作系统最基本的特性,使用汇编语言和C 语言编写的μCOS-Ⅲ的构思巧妙,结构简洁精炼,可读性很强,作为一个源码开放的嵌入式操作系统,用户只要做很少的工作就可以把它进行移植和维护。
1 实时操作系统μCOS-Ⅲ和STM32 处理器1.1 实时操作系统μCOS-ⅢμCOS-Ⅲ的前身是由美国嵌入式系统专家Jean brosse 于1992 年推出的嵌入式操作系统μCOS,经过了不断的完善和扩充,形成现在的μCOS-Ⅲ。
μCOS-Ⅲ是一个可以基于ROM 运行的、可裁减的、抢占式、实时多任务内核,具有高度可移植性。
所谓的移植,在一个平台环境能够成功运行的程序,将它搬运到另一个平台环境,并且使其成功运行。
发展至今的μCOS-Ⅲ,特别适合于微处理器和控制器,并且已经移植到近40 多种处理器体系上,涵盖了从8 位到64 位的各种CPU。