实时操作系统微内核的是与非

我觉的我自己从来都不擅长去解释与描述一个东西，口才没有，文采也没有，但又想故作高雅与知识渊博，去写些什么，我觉的很有可能招至别人的嘲笑，“写的什么玩意”。但管他呢，哥就是个屌丝，就这么点水平，就这么着了。好吧，在这里已记录下今天我的状况，今天第一次学车，练习倒车入库，各种不在状态，内心受到了极大的打击，自己笨死了，比别人差的太远，所以下午回到家真的是感到身心俱疲，倒头就睡了２个多小时.

好了，不扯这些不着边际每日的幻想，有人说双鱼座的人爱幻想，仔细想想，耶，也还说的蛮对的吗。

说到操作系统，第一个接触的当然是微软ＸＰ操作系统，当年我用的是盗版，现在有了正版ｗｉｎ１０，但我不乐意用了，编程开发写博客还是ｕｂｕｎｔｕ来的爽快，ｓｕｄｏ　ａｐｔ-ｇｅｔ 缺啥补啥全免费。当然，我要说的操作系统不是ｗｉｎｄｏｗｓ也不是ｌｉｎｕｘ，而是微内核实施操作系统。其实我也一直在想，像ucOS／FreeRTOS／rtThread／ut-kernel这些个实时操作系统到底能不能算作操作系统的范畴，因为当你你宏观认为像ＸＰ／ＷＩＮ７／ｕｂｕｎｔｕ那样的系统才叫操作系统之后，我认为他们更恰当的名称应该是微内核实时任务调度系统，因为他们都没有文件系统／视窗系统和音频系统，他们的代码总量也是相当的少，不过就几个Ｃ文件而已，不用一周时间你基本可以将他们的代码通读一遍，之后你会发现，他们的设计思想惊人的相似，万变不离其宗。

有兴趣想去了解微内核的人真的可以好好的去看两本书，第一本邵贝贝译《嵌入式实时操作系统uCOS-II》，第二本于渊著《自己动手写操作系统》。第二本其实偏向于微内核和宏内核之间，该书很好的讲解的ｘ８６架构，并会教你一步步怎样写一个操作系统，正是此书让我对宏内核虚拟页表有了了解，大致了解了ｌｉｎｕｘ的应用是如何被加载到内存并开始执行的，以及缺页机制是如何用来给应用分配内存的，但这只是冰山一角，我也仅是浅尝辄止，ｌｉｎｕｘ水太深。

我在汽车电子行业已有三年有余，说实话，不知道这算不算是泄密，我还真没有参与过使用似ｕｃＯＳ／ＦｒｅｅＲＴＯＳ那般的实时操作系统的项目，但是在各大论坛闲逛时，了解到汽车行业发动机控制系统是的的确确有使用实施操作系统的，还一般都是飞思卡尔ＭＰＣ５６系列的ＭＣＵ，英飞凌TriCore系列则多用于电动机控制系统，可能也多半会使用实时操作系统。所以，纠结的地方来了，什么样的应用该使用操作系统，是不是所有的嵌入式产品都应该使用实时操作系统。其实在我学习过ｕｃＯＳ，以及我在普华的第一年我业余时间自己开发符合ＯＳＥＫ规范的实时操作系统时和学习ＡＵＴＯＳＡＲ时，我那时认为ＯＳＥＫ／ＡＵＴＯＳＡＲ是绝对应该被推广的，使用该系统架构来做应用开发绝对的是百利而无一害。现在想想，那时候好傻。所以在普华工作一年后，海拉面试时，我对面试官说，我很懂ＡＵＴＯＳＡＲ　ＲＴＥ以下的东西，我很了解ＯＳＥＫ　ＯＳ，然后面试官问了我一个问题，为什么要使用ＡＵＴＯＳＡＲ／ＯＳＥＫ？我顿时傻掉了，我操，我从来没想过这个问题，面试官你不觉得ＡＵＴＯＳＡＲ／ＯＳＥＫ的软件架构思想不是很好吗？所以我答，使用ＯＳＥＫOS可以简化你的应用设计，任务响应更加迅速，实时性好，使用AUTOSAR软件结构清晰，因为有MCAL，所以你的应用可以很方便的从一个MCU迁移到另外的MCU，这不是很好吗？面试完，我就知道肯定被鄙视了，有了此教训，我低调了，面试江森自控和延峰伟世通时不在强调我很懂什么了，毕竟只有一年工作经历谁信你啊。

之后进入江森自控，一干就是两年，正式在做仪表产品的过程中，我渐渐明白，不管什么东西，必须摆在正确的位子上，他才会是有价值的。那时起才渐渐明白OSEK OS为什么分为4个等级，BCC1/BCC2/ECC3/ECC4，其目的就是为了满足不同的需求让汽车电子各供应商选择一个合适的等级使用，充分的发挥其作用，并使产品性价比做到最高，省成本的同时也要保证产品的质量。

好吧，简单描述下OSEK OS的四个等级，如下图所示：

BCC1：仅有基本任务（基本任务不支持事件），每一个任务的优先级必须不同，并且每个任务只能被激活一次。又可划分为支持任务可以被高优先级抢占和不可抢占两种。 例如as-smallos既是我实现的一个很简单的BCC1不可抢占式任务调度系统，其可做到所有任务和中断共享一个堆栈，大大的节省了堆栈资源的开销，并且在一定程度上保证了高优先级任务能及时的被调度，从而保证了任务的实时性。以我的经验和估计，其实目前大多数的车上ECU都选用此种或类似的任务调度器，因为在实时性要求不高的情况下，其已经能满足绝大多数的需求，因为毕竟车上绝大多数ECU功能单一，不会太复杂，一个while后台轮询加中断的前后台调度的方式，其实已经可以将实时性做的很好了，真的没有太大必要去使用ucOS/FreeRTOS这样的操作系统，因为会增加更多的资源开销成本会大大提高，所以这是我为什么目前短期不太看好AUTOSAR的原因，除非说哪天芯片白菜价，资源丰富的像土豪似得，那时候水到渠成，那时不使用AUTOSAR说不过去啊！好吧，又扯远了。

BCC2：和BCC1类似，但不同任务可具有相同优先级，并且任务可以被多次激活。

ECC1：和BCC1类似，但增加扩展任务（即任务可等待事件）

ECC2：和ECC1类似，但不同任务可具有相同优先级，并且基本任务可以被多次激活。

从上可知，BCC1和BCC2是比较轻量级的调度器，在所有任务不可被抢占的情况下，可以做到所有任务共享堆栈。理论上将，即使任务可以被高优先级抢占，其也可以做到所有任务的堆栈的共享，这是因为OSEK OS和其他例如ucOS/FreeRTOS等实时操作系统有着本质的区别，如下代码所示，分别为OSEK OS和FreeRTOS通常的样子：

TASK(AN_OSEK_TASK_SAMPLE)
{
	/* TODO: add the task action code below */
	...
	TerminateTask(); /* The end of this TASK */
}

void AN_FreeRTOS_TASK_SAMPLE(void* pParam)
{
	for(;;)
	{
		/* TODO: add the task action code below */
		...
		vTaskDelay(PERIOD_TICK_OF_THIS_TASK);
	}
}

从上可知，一个 OSEK OS任务通常在其调度结束后会结束自己，但一个FreeRTOS通常再被创建之后，就不会结束自己，在执行相应任务操作之后，会释放CPU资源等待下一个事件的到来，如上任务所示，其将等待该任务下一个周期时刻的到来。所以，一个简单的BCC1或者BCC2 OS就是一个符合OSEK OS规范的前后台式任务调度系统。

从上所述，使用RTOS又好处有坏处，不能绝对的认为使用RTOS就一定的好，前后台式的任务调取机制就一定的老掉牙，只要有好的正确的思想指导，都可以用来设计出好的产品。