关于国内实时操作系统的接口标准统一
2013-06-03 13:51
597 查看
目前国内的实时操作系统正在如春天般的万物发展趋势一样,充满蓬勃生机。但是多数情况下,各自为战,开发的软件大家得不到有效的共享。有的时候某位作者开发出来了协议栈,但是其他作者却无法使用,或者要使用带来了很大的难度。
协议栈的移植究其根本从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出师。
协议栈的移植究其根本从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出师。
相关文章推荐
- 关于实时数据库接口标准的讨论[中]
- 各数据库关于显示成男女各有不同的sql语句,有没有什么统一的标准写法呢???
- java集合框架集合框架是为表示和操作集合而规定的一种统一的标准的体系结构。任何集合框架都包含三大块内容:对外的接口、接口的实现和对集合运算的算法。
- 工具接口标准(TIS)可执行链接格式(ELF)规范-卷III-操作系统特性-程序加载和动态链接(一)
- 不同的浏览器之间的标准不统一给人们很大不便, 操作系统也是
- 操作系统标准接口设计POSIX
- 关于接口的统一验证
- 前言 我们知道不同的操作系统有各自的文件系统,这些文件系统又存在很多差异,而Java 因为是跨平台的,所以它必须要统一处理这些不同平台文件系统之间的差异,才能往上提供统一的入口。 关于FileSy
- 工信部要求国内 Android 统一消息推送标准(里面有进程包活)
- 工具接口标准(TIS)可执行链接格式(ELF)规范-卷III-操作系统特性(Operating System Specific)-对象文件
- 工具接口标准(TIS)可执行链接格式(ELF)规范-卷III-操作系统特性-程序加载和动态链接(二)
- 在龙芯1c上使用RT-Thread统一标准的gpio接口
- 第二次作业:关于打造国内最权威的操作系统博客的一些想法
- 工具接口标准(TIS)可执行链接格式(ELF)规范-卷III-操作系统特性-程序加载和动态链接(三)
- 在龙芯1c上使用RT-Thread统一标准的i2c接口
- 安卓党福音:国内安卓将统一消息推送标准
- 第二次作业:关于建立国内最大最权威的操作系统博客的一些想法
- 关于MIPI CSI-2 接口标准的资料翻译
- 工信部要求国内安卓统一消息推送标准,约束流氓App |价值早报
- 我国手机三统一:充电器;耳机;电话簿都要求统一接口、标准。