关于国内实时操作系统的接口标准统一

ti

目前国内的实时操作系统正在如春天般的万物发展趋势一样，充满蓬勃生机。但是多数情况下，各自为战，开发的软件大家得不到有效的共享。有的时候某位作者开发出来了协议栈，但是其他作者却无法使用，或者要使用带来了很大的难度。

协议栈的移植究其根本从3方面考虑来移植。

1 完成协议栈底层驱动的接口。

2 对编译器的移植。

3 对操作系统的接口移植。

对于驱动接口和编译器的移植，是做不了什么的，这个是硬性规定。但是对于操作系统接口的移植，由于大家的实时系统各异，就要花费很多的工作再去封装。这样就浪费了很多的时间。如果各位实时操作系统作者能统一操作系统层面的接口的话，对于软件的共享，以及测试有百利而无一害。具体说明如下：

1 定义一套实时操作系统的抽象层接口。这套抽象层接口首先要能满足国外的一些主流实时系统的封装。比如：

task_create_cn(……….)

{

Ucos3_task_create(……);

}

task_create_cn(……….)

{

threadx_task_create(……);

}

Task_create_cn()

{

Free_rtos_task_create(…….);

}

其它api类推。

2 api 的类型定义不允许使用RAW_U32 或者U32等等类似的类型定义，举例如下：

RET_TYPEtask_sleep_cn(tiCK_TYPE time_sleep)

其中的RET_TYPE 和TICK_TYPE需要再次定义。比如：

typedefRET_TYPE TYPE_U32

typedefTICK_TYPE TICK_U32

TYPE_U32和TICK_U32根据不同的编译器再次定义数据类型。

这样做的好处是，这套api可以充分和编译器脱离关系，也可以兼容不同的操作系统api,也可以同时兼容32位和64位系统。

3 函数的命名规则比如可以是名词+动词+后缀名（cn）

4 对于操作系统共通的特性，这套api需要完全支持，对于各操作系统特殊的api，可以实现扩展式的api,这些api是可选的，协议栈移植时不允许使用这些api，用户上层逻辑开发时可以使用这些api。

5 这套api 的价值在于，各家rtos只要封装了这套接口后，协议栈以及驱动这边可以达到高度的统一，如果应用程序也遵循这套api的话，他家rtos也可以瞬间上去。

6 对于api 的功能会有一本手册详细定义各api的功能。

目前操作系统接口比较广泛点的是posix接口，但是这套接口不太适合于rtos开发，比如进程这个概念，目前市场主流rtos 都是不支持的，那进一步比如进程通讯，设置这些api对于rtos都是浮云了。所以跑在老外前面，制定这一套api,对于提高国内rtos的普及以及学习是强有力的直接性的帮助。学习rtos的学者，只需要学习一套api就可以了。开发的工程师只要使用这一套api，就可以达到各rtos的通用,不用再存门户之见。

综上所述只是一家之言，希望大家多多参与，给出意见。欢迎各位rtos大侠，积极交流，争取早日这套api出师。