文章详情

登录

短信预约-IT技能 免费直播动态提醒

选择考试省份

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团

请输入下面的图形验证码

提交验证

短信预约提醒成功

中国移动 Oneos 框架基础及其组件解析

2024-12-02 18:41

关注

移动官网提供完善的oneos开发文档 https://os.iot.10086.cn/v2/doc/homePage

也可参考RT-Thread的资料，https://www.rt-thread.org/document/site/#/

1.2 开发工具

OneOS开发环境是基于命令行的OneOS-Cube，在对应工程目录下，执行menuconfig配置系统，scons编译构造。具体操作说明：https://os.iot.10086.cn/v2/doc/detailPage/documentHtml?idss=157071776529260544&proId=156799478777782272

1.3 软件框架

OneOS总体架构采用分层设计，主体由驱动、内核、组件、安全框架组成，采用一个轻量级内核加多个系统组件的模式。

与freeRTOS只包括内核相比，oneos支持通用组件或第三方库，尤其对接移动平台方便，遵循 Apache 2.0 license 开源协议，任意使用。

1.4 内核

Oneos内核提供任务管理调度、任务间同步与通信、定时器、内存管理等常用RTOS功能，与常规的RTOS如freeRTOS相比，仅有几点小区别：

任务，创建task后需要额外调用才启动，不同于freeRTOS创建所有的task后统一启动调度，全部task都开始执行。这种各task独立启动的，需要注意先后关系，不能task1启动后就向task2的队列发消息，此时队列可能为NULL且发送前没有判断，会导致重启。

消息队列，其动态创建和发送接口类似，但接收队列消息需要传入的参数不同，需要传入期望接收的字节大小。巧合的是项目使用的消息队列都是同一个结构体，如果不一致，需要特殊处理。

工作队列，将task进行了一定封装，不需要为处理某个事件而新建task，交给系统提前创建的task统一执行，执行结束后触发回调函数，这样多个长时间运行但不经常触发的，可以交给工作队列处理，该功能在UIS8910中系统自带。

邮箱，Oneos特有的，可理解为简化版的消息队列。

如果对freeRTOS不熟悉的，可以参考入门文章

1.5 组件

正如前面提到，如何使用oneos，移动官网有详细的说明，本文只是介绍oneos的基本开发流程，分析其部分功能的实现方式，后续以其设备框架、SHELL和单元测试三部分为主。

2、系统移植

2.1 开发流程

基于oneos的开发方式和以往不同，先将原始工程编译生成库，全部复制到oneos工程，再基于oneos系统开发业务逻辑，其开发环境和原始工程开发环境无关。Oneos工程编译生成的bin文件下载到设备，完整版本支持microPython，可以导入python文件直接运行。

可能部分功能比较特殊，使用原始库文件无法实现，例如获取系统某个参数。在原始工程开发，可以直接将客制化代码插入某个接口拦截，基于oneos开发时尽量避免，但是实在不行也只能这样。这样操作后，原始工程编译成功，但链接肯定失败，但不影响结果，只要输出lib库即可。

2.2 操作系统适配

如果没有原始SDK，要运行oneos，直接将原始库，例如STM32原厂HAL库复制到oneos/thirdparty即可;但是有基础SDK，且SDK是基于其它RTOS开发，则其库要在oneos运行，需要进行适配转换，存在两种方式。

以目前支持cat1网络比较火的两个芯片平台为例。紫光展锐UIS8910平台使用freeRTOS，且基本开源，因此可以将UIS8910工程中的freeRTOS系统接口，其函数内容替换使用oneos的接口实现。

翱捷ASR1603平台使用threadX，且已封库，因此是在oneos工程，将oneos的系统内核接口函数内容使用ASR1603提供的库实现。

<公众号：嵌入式系统>

前者UIS8910是oneos直接在底层替换了freeRTOS，相当于只运行了一套较为干净的oneos;后者完全是将两套RTOS的接口互相匹配，且中间并不是一对一替换。

2.3 风险与限制

原始工程开发函数是直接调用，引入oneos框架后，内核适配、驱动框架增加了代码量，运行效率也存在一定损失。对网络modem相关的操作，oneos使用AT通信，其阻塞方式对原有应用逻辑存在较大影响，不如原始API便捷。

3、系统组件

3.1 编译器关键字

重点介绍section关键字，后续章节都与其有关，section主要作用是将函数或者变量放在指定段中，可在指定的地方取函数执行。

  1. //main.c   
  2. //section demo   
  3. #include "stdio.h"   
  4.     
  5. int __attribute__((section("my_fun"))) test1(int a,int b)   
  6. {   
  7.  return (a+b);   
  8. } 
  9.  
  10. int test(int b)   
  11. {   
  12.  return 2*b;   
  13. } 
  14.  
  15. int __attribute__((section("my_fun"))) test0(int a,int b)   
  16. {   
  17.  return (a*b);   
  18. }   
  19.     
  20. int __attribute__((section("my_val"))) chengi;   
  21. int __attribute__((section("my_val"))) chengj;   
  22.     
  23. int main(void)   
  24. {   
  25.  int sum,c,j;     
  26.  chengi=1,chengj=2;   
  27.     
  28.  sum=test1(chengi,chengj);   
  29.  c=test(100);   
  30.  j=test0(chengi,chengj);   
  31.         
  32.   printf("sum=%d,c=%d,j=%d\r\n",sum,c,j);   
  33.  
  34.   return 0;   
  35. }   

编译生成map文件：

  1. gcc -o main.exe main.c -Wl,-Map,my_test.map 

my_test.map 文件片段如下：

  1. .text  0x00401460 0xa0 C:\Users\think\ccmGLaeH.o0x00401460 test0x0040146a main 
  2. .text 0x00401500 0x0 c:/mingw/bin/../libmingw32.a(CRTglob.o) 
  3. ...... my_fun 0x00404000 0x200 [!provide] PROVIDE (___start_my_fun, .) 
  4. my_fun  0x00404000 0x1c C:\Users\think\ccmGLaeH.o 
  5. 0x00404000 test10x0040400d test0 
  6. [!provide] PROVIDE (___stop_my_fun, .) 
  7. .data 0x00405000 0x200 
  8. 0x00405000 _data_start_ = . ...... *(.data_cygwin_nocopy) my_val 0x00406000 0x200 
  9. [!provide] PROVIDE (___start_my_val, .) 
  10. my_val  0x00406000 0x8 C:\Users\think\ccdMcTrl.o0x00406000    chengi0x00406004 chengj 
  11. [!provide] PROVIDE (___stop_my_val, .) 
  12. .rdata 0x00407000 0x400 

分析可见，使用section修饰的函数和变量在自定义的片段，而且是连续存放，这样可根据变量的地址得出与其同段变量的地址，为后续自动初始化等功能提供了基础。

3.2 自动初始化

基于前面section的作用，可以将同类函数指针全部使用同一个段名修饰，然后开机后系统自动检索段内函数指针，逐个执行，对上层应用就是无需主动调用，系统自动初始化。考虑到硬件初始化与应用功能初始化的先后顺序，可以对段名进行分配，map文件按段名排序。自动初始化主体是OS_INIT_EXPORT宏。

  1. typedef os_err_t (*os_init_fn_t)(void); 
  2.  
  3. #define OS_INIT_EXPORT(fn, level) \ 
  4. const os_init_fn_t __os_call_##fn OS_SECTION(".init_call."level) = fn 
  5.  
  6. #define OS_BOARD_INIT(fn) OS_INIT_EXPORT(fn, "1") 
  7.  
  8. #define OS_PREV_INIT(fn) OS_INIT_EXPORT(fn, "2") 
  9.  
  10. #define OS_DEVICE_INIT(fn) OS_INIT_EXPORT(fn, "3") 
  11.  
  12. #define OS_CMPOENT_INIT(fn) OS_INIT_EXPORT(fn, "4") 
  13.  
  14. #define OS_ENV_INIT(fn) OS_INIT_EXPORT(fn, "5") 
  15.  
  16. #define OS_APP_INIT(fn) OS_INIT_EXPORT(fn, "6") 

例如shell初始化函数，定义如下：

  1. OS_APP_INIT(sh_system_init); 

将宏定义展开

  1.  
  2. const os_init_fn_t __os_call_sh_system_init 
  3.     __attribute__((section((".init_call.6")))) = sh_system_init 

系统自身也有自定义函数，用来标记起止点函数

  1. OS_INIT_EXPORT(os_init_start, "0"); 
  2. OS_INIT_EXPORT(os_board_init_start, "0.end"); 
  3. OS_INIT_EXPORT(os_board_init_end, "1.end"); 
  4. OS_INIT_EXPORT(os_init_end, "6.end"); 

最终生成的map文件如下图：

//系统底层在合适的时机调用如下两函数，将指定段区间内的所有函数自动执行

  1. //系统底层在合适的时机调用如下两函数，将指定段区间内的所有函数自动执行 
  2.  
  3. void os_board_auto_init(void) 
  4. { 
  5.     const os_init_fn_t *fn_ptr_board_init_start; 
  6.     const os_init_fn_t *fn_ptr_board_init_end; 
  7.     const os_init_fn_t *fn_ptr; 
  8.  
  9.     fn_ptr_board_init_start = &__os_call_os_board_init_start + 1; 
  10.     fn_ptr_board_init_end   = &__os_call_os_board_init_end - 1; 
  11.  
  12.     for (fn_ptr = fn_ptr_board_init_start; fn_ptr <= fn_ptr_board_init_end; fn_ptr++) 
  13.     { 
  14.         (void)(*fn_ptr)(); 
  15.     } 
  16.  
  17.     return; 
  18. } 
  19.  
  20. static void os_other_auto_init(void) 
  21. { 
  22.     const os_init_fn_t *fn_ptr_other_init_start; 
  23.     const os_init_fn_t *fn_ptr_other_init_end; 
  24.     const os_init_fn_t *fn_ptr; 
  25.  
  26.     fn_ptr_other_init_start = &__os_call_os_board_init_end + 1; 
  27.     fn_ptr_other_init_end   = &__os_call_os_init_end - 1; 
  28.  
  29.     for (fn_ptr = fn_ptr_other_init_start; fn_ptr <= fn_ptr_other_init_end; fn_ptr++) 
  30.     { 
  31.         (void)(*fn_ptr)(); 
  32.     } 
  33.  
  34.     return; 
  35. } 

系统执行os_other_auto_init时实现了sh_system_init的自动执行，即使应用层没有显示的去调用它。使用符号段的方式实现初始化函数自动执行，应用层修改软件，增加功能启动或者裁剪，对底层代码无需任何改动。

3.3 设备框架

3.3.1 设备模型

一般HAL包括GPIO、UART、ADC等，每个设备节点的类型和控制接口、参数个数及含义完全不同，即使都是GPIO，不同原厂提供的接口也各不相同。设备框架就是在底层封装原始API，然后统一注册到设备节点表，使用时获取节点及其对应的操作接口，这样应用层的代码在风格上比较统一。

应用层需要操作设备时，根据名称查找设备，再使用该提供的API进行操作，无需关注该设备具体对应的端口、状态等细节信息;其风格与linux驱动接近。

3.3.2 设备注册

以I2C设备为例：

  1. #define OS_DEVICE_INFO static OS_SECTION("device_table") const  os_device_info_t 
  2.  
  3. OS_DEVICE_INFO asr1603_i2c1_device = { 
  4.  .name = "i2c1", 
  5.  .driver = "ASR1603_I2C_DRIVER", 
  6.  .info = OS_NULL, 
  7. }; 
  8.  
  9.  OS_DEVICE_INFO asr1603_i2c2_device = { 
  10.  .name = "i2c2", 
  11.  .driver = "ASR1603_I2C_DRIVER", 
  12.  .info = OS_NULL, 
  13. }; 

所有的设备信息存在device_table段，只是分配设备驱动类型和名称。

  1. OS_DRIVER_INFO asr1603_i2c_driver = { 
  2.  .name = "ASR1603_I2C_DRIVER", 
  3.  .probe = asr1603_i2c_probe, //I2C设备初始化和注册 
  4. }; 
  5.  
  6. OS_DRIVER_DEFINE(asr1603_i2c_driver, "2"); 
  7.  
  8. #define OS_DRIVER_DEFINE(_driver_, sequence)            \ 
  9.     static os_err_t __driver_##_driver_##_init(void)    \ 
  10.     {                                                   \ 
  11.         return driver_match_devices(&_driver_);         \ 
  12.     }                                                   \ 
  13.     OS_INIT_EXPORT(__driver_##_driver_##_init, sequence) 
  14. //OS_INIT_EXPORT即为前面提到的开机自启动定义宏 

开机后自动执行_asr1603_i2c_driver_driver__init，也就是自动将device_table段设备对应的驱动程序asr1603_i2c_probe自动执行，实现了所有设备的初始化，

  1. static int asr1603_i2c_probe(const os_driver_info_t *drv, const os_device_in 
  2.                              fo_t *dev) 
  3. { 
  4.     ... 
  5.  //所有的 I2C 设备（一种设备有多个）进行初始化 
  6.     if(!strcmp(dev->name, "i2c1")) 
  7.     { 
  8.         g_i2c1.id = ASR1603_DEV_I2C1; 
  9.         i2c_p = &g_i2c1; 
  10.     } 
  11.     else if(!strcmp(dev->name, "i2c2")) 
  12.     { 
  13.         g_i2c2.id = ASR1603_DEV_I2C2; 
  14.         i2c_p = &g_i2c2; 
  15.     } 
  16.     .... 
  17.  
  18.     asr1603_wrap_i2c_init(i2c_p->id); 
  19.  
  20.     i2c_p->i2c_bus.ops = &i2c_bus_ops; //底层操作 I2C 的接口，与实际硬件绑定 
  21.     i2c_p->i2c_bus.priv = i2c_p; 
  22.  
  23.     ret = os_i2c_bus_device_register(&(i2c_p->i2c_bus), dev->name, OS_DEVICE 
  24.                                      _FLAG_RDWR, &(i2c_p->i2c_bus)); 
  25.  
  26.     return ret; 
  27. } 

os_i2c_bus_device_register将I2C设备注册到系统设备列表os_device_list，包括其对外接口i2c_ops。

  1. struct os_device_ops 
  2. { 
  3.     os_err_t  (*init)   (os_device_t *dev); 
  4.     os_err_t  (*open)   (os_device_t *dev, os_uint16_t oflag); 
  5.     os_err_t  (*close)  (os_device_t *dev); 
  6.     os_size_t (*read)   (os_device_t *dev, os_off_t pos, void *buffer, os_size_t size); 
  7.     os_size_t (*write)  (os_device_t *dev, os_off_t pos, const void *buffer, os_size_t size); 
  8.     os_err_t  (*control)(os_device_t *dev, os_int32_t cmd, void *args); 
  9. }; 

所有设备对外提供接口都类似，部分不支持的为NULL，风格和linux设备驱动一致，这些接口是封装前面i2c_bus_ops提供的硬件特有驱动，这样完成了I2C设备框架与硬件驱动绑定以及自动初始化。

3.3.3 框架应用

应用层使用I2C设备：

  1. os_device_find("i2c1"); 

获取成功后，正常流程是使用i2c_ops提供的接口操作设备，实际调用也基于i2c_bus_ops封装的接口，可见oneos也不太标准;最佳操作可以参考UART的用法。

3.4 模组连接套件

模组连接套件 Molink (Module link kit)，设备通过AT与网络模组交互的接口，内置基带的使用虚拟AT通道。

Molink对单片机加模组的方案非常合适，对内置基带的芯片，反而影响效率，因为其AT是阻塞方式实现，例如扫描周围wifi热点，会导致当前task阻塞几秒钟，这样处理只是为统一API接口，实现MCU+模组和内置基带两种硬件方案的应用代码无缝迁移。

名称高大上，其实就是开机初始化一个大数组，在module_asr1603_create()，不同作用的AT分类，封装AT收发、解析接口。

使用mo-link先获取数组中对应项，使用其支持的API操作AT指令，以阻塞方式运行。对于ASR1603内置基带的，socket没有使用AT方式，而是LWIP接口，这种效率高。

3.5 Shell工具

和linux中shell类似，以命令行触发函数运行，在shell控制口，默认是OS_CONSOLE_DEVICE_NAME输入命令，shell task会解析并自动扫描内部函数表，执行函数后输出回应，将结果显示在控制终端上。

Shell对软件调试非常方便，例如调试I2C接口，只需定义：

  1. SH_CMD_EXPORT(test, test_i2c, "test i2c api"); 

开机后串口输入test字符串，设备即运行test_i2c()函数，其原理如下：

  1. #define SH_CMD_EXPORT(cmd, func, desc)      SH_FUNCTION_EXPORT_CMD(func, __cmd_##cmd, desc) 
  2.  
  3. #define SH_FUNCTION_EXPORT_CMD(func, cmd, desc)                         \ 
  4.     const char __fsym_##cmd##_name[] = #cmd;                            \ 
  5.     const char __fsym_##cmd##_desc[] = desc;                            \ 
  6.     OS_USED const sh_syscall_t __fsym_##cmd OS_SECTION("FSymTab") =     \ 
  7.     {                                                                   \ 
  8.         __fsym_##cmd##_name,                                            \ 
  9.         __fsym_##cmd##_desc,                                            \ 
  10.         (syscall_func_t)func                                            \ 
  11.     }; 

SH_CMD_EXPORT宏将前面i2c提供的参数转换，在FsymTab段创建一个名为__fsym___cmd_test的结构体，其3个成员分别是字符名，描述和函数体。

  1. OS_APP_INIT(sh_system_init); 

开机自启动sh_system_init，创建gs_shell_task任务，接收shell控制口的字符数据，满足一定条件后进入sh_exec，搜索FsymTab段区间变量名，sh_get_cmd_func找到对应函数再执行。

shell工具便于调试，调试复杂功能注意栈空间;但其在数据安全方面存在较大隐患，且占用独立的task和串口，浪费硬件资源，正式发布的软件务必关闭。

3.6 单元测试

类比assert的作用，判断条件为假时触发异常，单元测试与其类似，统计判断结果导致报告。OneOS 开发的单元测试框架atest(and test)，和网上开源的差不多。

  1. #define ATEST_TC_EXPORT(name, testcase, init, cleanup, priority)                            \ 
  2.     OS_USED static const atest_tc_entry_t gs_atest##testcase OS_SECTION("AtestTcTab") =     \ 
  3.     {                                                                                       \ 
  4.         #name,                                                                              \ 
  5.         init,                                                                               \ 
  6.         testcase,                                                                           \ 
  7.         cleanup,                                                                            \ 
  8.         priority                                                                            \ 
  9.     }; 

其原理就是软件自动执行某一段代码，将运行结果和期望值进行比较并统计，对软件质量的检测效果，取决于单元测试用例的设计水平。该功能与平台无关，适用于新平台首次使用时测试API。

4、 Python开发

基于前面shell的原理，可以按输入的字符串执行与之绑定的函数，如果对字符串进行一定的规则定义，支持自动解析执行，即可实现函数按提供的文本执行。这套文本规则就是python语法，解析器就是MicroPython内核，这样就能实现在嵌入式平台使用python开发。

MicroPython对软件进行天然的分层，严格区分驱动层和应用层，实现应用软件的跨平台移植。Oneos集成的就是开源的MicroPython，其源码下载地址是：https://github.com/micropython/micropython

OneOS-MicroPython开发环境：VsCode+NODE+Pymakr ，其中.mpy文件混淆加密的工具在MicroPython源码mpy-cross中自行编译。

短期内Python不会成为嵌入式的主流开发语言，但掌握其基础也有大有裨益。

 

来源：嵌入式系统内容投诉

免责声明：

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析（完整版）

    难度     813人已做
    查看

  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看

  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看

  • 2024年上半年软考高项第一、二批次真题考点汇总（完整版）

    难度     435人已做
    查看

  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机

中国移动 Oneos 框架基础及其组件解析

后端开发Oneos框架2024-12-02
位置：首页-资讯-后端开发
咦！没有更多了？去看看其它编程学习网 内容吧
首页课程
资料下载问答资讯