jorya_txj的专栏

Raw-OS 操作系统特性内核最大关中断时间无限接近0us, s3c2440系统最大关中断时间实测0.8us。支持idle任务级别的事件驱动，基于状态机机制(fsm+hsm),所有idle 级别的事件任务共享一个栈！支持轻量级线程protothread。支持普通任务级别的状态机和事件驱动机制。支持tasklet以及workqueue，轻松降低系统最大

目前国内的实时操作系统正在如春天般的万物发展趋势一样，充满蓬勃生机。但是多数情况下，各自为战，开发的软件大家得不到有效的共享。有的时候某位作者开发出来了协议栈，但是其他作者却无法使用，或者要使用带来了很大的难度。 协议栈的移植究其根本从3方面考虑来移植。 1  完成协议栈底层驱动的接口。 2  对编译器的移植。 3  对操作系统的接口移植。  对于驱动接

消息系统是任务与任务之间通讯的最重要的手段。首先第一个问题是，为什么需要消息系统？对于任务与任务之间全局变量是共享的，是不是可以通过维护全局变量来实现任务之间的通讯呢？ 任务和任务之间的地址空间是可见的，通过全局变量去通讯的话，也是无可厚非的。关键问题是通过全局变量的通讯很复杂，根本无法去维护，必须有一个手段把最底层的全局变量这些逻辑封装起来。这样就产生了消息机制。在操作系统中最常见的消息机制

中断一般可以分成上半部以及下半部,所谓中断上半部cpu通常是关中断的，这个时候主要是从硬件那里接收一些数据，然后触发中断下半部。一出中断后，根据相应的中断下半部的优先级去执行相应的中断下半部。中断下半部主要用于数据的处理，这个时候中断往往是打开的。为什么要有中断上下半部的原因主要有两点:1 如果中断函数内处理的事情非常多的话，因为这个时候cpu 是关中断的，这样会无法及时相应其它的中断，对实时

中断一般可以分成上半部以及下半部,所谓中断上半部cpu通常是关中断的，这个时候主要是从硬件那里接收一些数据，然后触发中断下半部。一出中断后，根据相应的中断下半部的优先级去执行相应的中断下半部。中断下半部主要用于数据的处理，这个时候中断往往是打开的。为什么要有中断上下半部的原因主要有两点:1 如果中断函数内处理的事情非常多的话，因为这个时候cpu 是关中断的，这样会无法及时相应其它的中断，对实时

内存管理往往是一个复杂的过程，raw os 目前支持5种内存分配方法，分别是block,byte,page,malloc,slab。以下会讲解这5种基本原理以及适用场合。这5种里面只有block和slab 是没有内存碎片的，其余的都会有一定的内存碎片。这5种里面只有block和byte能用于中断内内存分配，推荐使用中断内采用block内存分配。 block内存分配顾名思义是一块块的分配内存

由于raw os 针对市场是目前中低端的cpu,所谓的中低端cpu 一般以arm 9 划分，arm9 级别的或者类似速度的cpu 为中端cpu, 以上的比如arm 11为高端cpu, 以下的为低端cpu,比如cortex-m0,cortex-m3,cortex-m4等等。 rawos的市场既然已经决定在中低端cpu, raw os 力争做到世界上所有实时操作系统之中的体积最小以及速度最快者。基

操作系统的调度方法有很多种，这里主要介绍主流的调度算法，像EDF这种调度算法就不表述了。目前几乎所有的商业实时操作系统的调度理论都基于RMS理论.以下是基于RMS的一些假设理论:1 各个任务之间没有资源共享，没有忙等，没有mutex, 也没有semaphore.2 每个任务的最后期限是周期性的。3 基于优先级抢占的，即高优先级任务一旦就绪的话，会立马抢占低优先级任务。4 任务优

临界区问题是嵌入式软件编程一个不得不面对的关键性问题。特别对于底层驱动，代码在内存中只有一份，上层的多任务或者多进程，都会对同一个驱动去访问，这样不可避免的遇到了任务之间打架的问题，处理好这个问题是区分一个菜鸟和老鸟的根本性关键之一。接下来谈谈临界区产生的原因：假设有以下代码:int x; void process_data(){ x++; }假如在一个

前后台系统的架构用一句话来形容的话，就是一个大的循环，加上中断，就形成了一个整的体系。具体的流程图如下:可以看到图里面处理了模块功能3 之后又返回处理模块功能1.一般的单片机系统大多是采用了此种模式编程，优点是简洁，明了，新手的上手速度很快，特别是专注用来做一件事情的时候，一个while循环基本是无敌的。比如实现一个i2c slave ，完全可以用一个while 来模拟实现

近来发现陆陆续续有个人以及公司技术人员在开始尝试用raw os 做项目，虽然刚起步但是非常难能可贵。希望更多的个人或者公司大胆的使用raw os, 有以下好处： 1 一个高效的实时操作系统2 免费的技术服务。一切使用raw os 做项目或者产品的公司技术人员，本人免费帮助设计软件架构，只限于网上在线支持或者联合调试。软件架构包括系统的移植，内核的裁剪，任务的划分，优先级的确定，

很多人一直会问一个问题，世界上有这么多的RTOS存在，有开源的也有收费的。为什么还需要写一个RTOS, 2012年之前我也不断问自己这个问题。我是这样认为的世界上的确有很多RTOS,但是目前国内的RTOS并不多，能在国际上有影响力的更少。如果说能够承上启下，融合众多世界上众多RTOS 的优势，加以创新糅合，或许可以创造一个全新的RTOS. 一个实时系统的推出，需要有以下几点考虑因素。

raw os 采用了特殊的机制, 可以降低整个系统的最大关中断时间无限接近0us.其主要实现原理是原先系统关中断的地方改为关抢占，这样就可以把系统最大中断时间降为最低了。 读者可以看到RAW_CRITICAL_ENTER()的实现有两种实现方式，第一种是传统的关中断形式：#define  RAW_CRITICAL_ENTER()                     RAW_CP

状态机编程的历史很可能久于传统的操作系统, 传统的一个大while 循环模式普遍用到了状态机模式编程， 状态机一般是基于fsm 的有限状态机，或者更先进点的是hsm 分层的状态机。具体的fsm 以及hsm 状态机的概念读者自行参考有关概念学习，这里不再表述。推荐看Practical UML Statecharts in c/c++这本书。raw os的状态机理念，很大部分参考了它，和著名的面向

mutex的出现是为了解决优先级反转的问题，由于优先级反转对实时性影响太大，所以mutex 的稳定性直接影响了实时性。纵观目前多种实时操作系统mutex 的设计原理是多多少少有一点问题的，raw os 的mutex 模块成功弥补了其它实时系统在这方面的不足。raw os 的mutex同时支持优先级置顶和优先级继承的方式来解决优先级反转的问题。raw os 的mutex比较其它实时系统，比如

rawos 由于采用了特殊的系统处理方式，可以把系统最大关中断时间降到0us.影响一个系统实时性最客观的参数是其系统的最大关中断时间。 在2440 板子上空跑一个实时操作系统的话，vxworks 的官方系统最大关中断时间为6us 以上， ucos 的话可以达到20us以上。但是raw os 是0.8us.所以其实时性毫无疑问是超越这些系统的。 中断的处理对于实时性的提高也是

Raw os的事件触发系统有以下特点: 1 基于UML的状态机理念设计，实现了有限状态机(fsm)以及层次状态机(HSM)。 2 实现了活动对象(ACTIVE OBJECT)的特性，一个活动对象包含了一个消息队列以及一个状态机。活动对象是具有优先级的，这样任务的实时性能够得到保证。消息队列的设计能够保证即时信号不丢失。 3活动对象(ACTIVE OBJECT)一共有64个优